このテンプレートの使い方：
このパッチ管理ポリシーのテンプレートの理解と利用を guide するコメントは角括弧「[…]」で囲み、文書全体で「会社」は[eSecurity Planet]と記載しています。このテンプレートを実際のポリシーに変換する際は、角括弧で囲まれた部分を削除し、「[eSecurity Planet]」を「YourCompanyName」に置き換えてください。
このポリシーは、一般的なITインフラとニーズを想定しています。特定の企業のITインフラやニーズに合わせて、必要に応じて変更できます。
このテンプレートを使用するには、Webサイトのテキストをコピーして貼り付けるか、以下のMicrosoft Wordテンプレートをダウンロードしてください。
この記事は、Windows、MacOS、Linuxのデバイスや、Chrome、Adobe、Slackなどのサードパーティーアプリケーションのパッチ適用と構成管理を自動化するAutomoxの提供です。Automoxの
’
「2023年IT運用状況レポート」を読み、何が
’
機能しているのか、何が機能していないのか
’
を確認してください。
[eSecurity Planet（またはここに自社名を記入）] パッチ管理ポリシー
1. 概要
ベンダーは、製品の性能向上とセキュリティ脆弱性の排除を目的として、機能更新、障害修正、セキュリティパッチを定期的に提供します。こうした更新を速やかに適用することで、脅威から保護できるだけでなく、ユーザー体験や組織の生産性が向上する可能性があります。
パッチが適用されていないリソースは、ユーザー、データ、その他の企業リソースを許容できないリスクにさらします。このパッチ管理ポリシーは、次の事項を定めます。
- [eSecurity Planet]のシステムおよびソフトウェアを維持するための期待事項、要件、基本手順を概要化する
- このポリシーへの準拠を確認するための報告書を定義する
- このポリシーに違反した場合の罰則を定める
[このセクションでは、ポリシーの目的と、文書の後半で説明する内容を読者に紹介します。ポリシーでは何を実施しなければならないかを定めますが、どのように実施するかまでは定めません。ITマネージャーは、組織のリソースの範囲内で目標を達成する方法を柔軟に決定できる必要があります。]
パッチ管理ポリシーの詳細を確認してください。
2. 適用範囲
このポリシーは、組織のネットワークに接続する、組織の使命を支える、または組織のデータをホストする、[eSecurity Planet]のすべてのリソースに適用されます。組織は、ダウンロード可能なテンプレートの付録I「ITリソース資産リスト」に定めるとおり、このポリシーの適用範囲に含まれるリソースの正式な一覧を維持・追跡します。
パッチ管理では、更新対象となる既存のシステムとソフトウェアの正確な一覧が必要です。すべての資産を正確に評価してパッチ適用や更新を行えるよう、適用範囲は[資産管理ポリシーに従って／毎月／四半期ごとに]確認する必要があります。
[これは適用範囲として最も積極的なバージョンです。ネットワークに接続された従業員のデバイスの更新や監視を行わなかったり、IoT（モノのインターネット）デバイスを無視したりする組織もあります。これはリスクを伴いますが、簡素化やリソースの制約（予算、IT担当者、時間など）を理由に、こうしたリスクを暗黙に受け入れる組織もあります。
適用範囲では、更新やパッチ適用の対象として監視するものを定義する必要があります。IT部門がサーバーとエンドポイントのOSだけにパッチを適用する場合は、そのように適用範囲を編集し、監視対象外のシステムに伴うリスクを受け入れてください。]
3. パッチ管理ポリシーおよび手順
A. パッチ管理責任者
[eSecurity Planetの最高情報責任者（CIO）]をパッチ管理責任者に指定します。パッチ管理責任者は、このパッチ管理ポリシーおよび手順のすべての項目を計画、実行、承認し、または社内リソースやサードパーティーのツール、ベンダーに委任する最終的な責任と権限を持ちます。
パッチ管理責任者が最終的な責任を負う一方で、通常は[IT部門]が、パッチ管理ポリシーに従うためにパッチ管理責任者の計画を実行するものとします。このポリシーで「IT部門」と記載する場合は、パッチ管理責任者、[IT部門]、および委任された担当者を指します。
パッチ管理責任者は、次の事項も確認し、承認します。
- パッチ管理ポリシーの適用範囲
- パッチ適用の優先順位
- パッチ適用のテストと承認
- パッチや更新の適用に必要なメンテナンスによる停止
- 必要な緩和策または例外
- パッチ管理報告書
- 強制措置
[このセクションでは、予算を承認し、パッチ管理プロセスを管理する責任者を定義します。担当者は変わることがあるため、ポリシーを人事異動のたびに改訂せずに済むよう、役職名を使用するのが最善です。]
B. パッチおよび更新の取得
IT部門は、このポリシーの適用範囲に含まれるすべての資産について、更新やパッチのリリース情報を得るため、さまざまな情報源を継続的に監視・スキャンします。情報源には、セキュリティメーリングリスト、ベンダーからの通知、Webサイトなどが含まれますが、これらに限定されません。
パッチまたは更新が利用可能になった場合、IT部門は更新をダウンロードする前に、情報源の正当性を確認します。推奨される方法は、提供元ベンダー（更新対象のリソースを開発した企業または組織）から直接、または提供元ベンダーから直接更新を取得するサービスプロバイダーからパッチを入手することです。
その他の情報源から取得したパッチや更新は、組織の環境に導入する前に、慎重に精査・テストする必要があります。
[このセクションは、利用可能な更新やパッチを常に警戒し、速やかに認識することを徹底するためのものです。ベストプラクティスでは、更新やパッチの調査、所在確認、情報源の検証を特定の担当者に割り当てることが推奨されています。]
C. パッチ適用の優先順位
複数のパッチや更新が同時に利用可能になる場合があります。必要に応じて、IT部門はパッチや更新の適用優先順位を決定し、次の事項に基づいて階層化します。
- パッチが適用する脆弱性の共通脆弱性評価システム（CVSS）スコア
- 資産のリスク値
- 悪用される可能性
CVSSは、脆弱性に1から10までのスコアを付与します。CVSSバージョン3.0の評価は次のとおりです。
- 9.0～10.0＝重大
- 7.0～8.9＝高
- 4.0～6.9＝中
- 0.1～3.9＝低
- 0.0＝なし（情報提供）
これらのスコアは悪用される可能性を示すものではありませんが、攻撃者がシステムに及ぼし得る影響の大きさや、必要となる労力の程度を示します。米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は、実際に悪用されているかを確認できる既知の悪用された脆弱性の一覧を管理しています。
[eSecurity Planet]はリスク分析を用いて社内システムのリスク評価を作成し、1（影響・価値が低い）から10（影響・価値が最も高い）までの尺度でリスク台帳に記録・更新します。同様に、IT部門は現在の環境、ITアーキテクチャ、脆弱性の性質を評価して、悪用される可能性を判断する必要があります。この可能性も1（可能性が低い）から10（可能性が高い）までの尺度で評価します。これら3つの要素を合計すると、パッチ適用の優先度を2（優先度が低い、または対応不要）から30（緊急対応が必要）までの値で表せます。
サービスプロバイダーに外部委託する場合やパッチ適用ツールを使用する場合、一部のパッチ適用は自動的に実行され、優先順位が不要なことがあります。次の更新やパッチについては、適用の優先順位を設定する必要があります。
- メンテナンスのためリソースの停止が必要なもの
- 他のパッチや更新と競合するもの
- 他のシステムや業務プロセスに問題を引き起こすもの
手動パッチ適用のキューには、古く緊急性の低いパッチが含まれている場合があります。新しくリリースされたパッチは、キュー内の古いパッチに置き換える必要があります。置き換え後のパッチには古いパッチと同じ優先順位を付けることも、IT部門の判断で再設定することもできます。
[このセクションでは、パッチ管理プロセスでどのパッチを先に適用するかを判断するための優先順位を定めます。CVSSに基づいてパッチの優先順位に重み付けする方法が最も一般的であり、この方法だけを厳格に使用する組織もあります。
優先順位を決める際には、企業にとっての価値と悪用される可能性も考慮する必要があります。ただし、更新への対応を避けるために、都合よく誰かが悪用リスクや資産価値を操作しないよう注意してください。
管理型のパッチ適用サービスやツールでは、具体的な数値であり、サービスやツールが組織にとっての資産価値を把握していないことが一般的であるため、CVSS値が使われる可能性が高いでしょう。
このセクションでは、リスク評価とリスク台帳について説明しています。規模を問わず、すべての組織がリスク台帳を作成できますし、作成すべきです。リスク台帳では、リソースの価値と、そのリソースが損なわれたり、侵害されたり、障害を起こしたりした場合に組織へ及ぶ影響の大きさを評価します。リスク台帳がない組織は、リソースの組織にとっての価値を定性的に見積もる必要があります。]
D. パッチおよび更新のスケジュール
IT部門は、2～30のパッチ適用優先度に基づき、次の期限内にパッチを適用する必要があります。
- 24.0～30：パッチリリースから[7]日以内
- 18.0～23.9：パッチリリースから[14]日以内
- 18.0未満のセキュリティパッチ：リリースから[30]日以内
セキュリティ以外のパッチ（アップグレードやバグ修正）は、通常のシステム保守・サポート手順で定められた通常のメンテナンススケジュールに従って適用します。ただし、[90]日を超えてはなりません。優先度の低いパッチや更新は、IT部門の判断で、優先度の高いパッチや更新と同時に適用できます。
例：
- 深刻度8.4の重大ではないソフトウェアバグ修正は、深刻度25.3および28.0の他の脆弱性修正と同時にインストールできます。
- 深刻度15.4のルーター向けの重大ではない機能アップグレードは、IT部門が深刻度13.0のセキュリティ脆弱性に対応するため50台超のルーターを手動で更新する必要があり、同時にアップグレードできない場合、インストールを延期できます。
実務上、サーバーとエンドポイントには毎月パッチを適用し、重大な脆弱性、特に攻撃方法が公表されているものには、前倒しでパッチを適用します。すべてのシステムにセキュリティ更新をインストールし、必要に応じて、定められた期限内にシステムを再起動する必要があります。
[正確な評価方式と緊急度は組織が決定します。優先度に基づくスケジュールは、最も重要なリソースに存在する最も重大なパッチや更新に速やかに対応できるものでなければなりません。アップグレードやパッチの適用期限を最長90日とすることで、システムやソフトウェアが見落とされたり完全に放置されたり、更新が蓄積したりするのを防げます。]
E. パッチ適用ガイドライン
パッチを取得して優先順位を設定したら、次の手順に従います。
i. パッチのテスト
高価値のリソースについては、IT部門がテスト環境でパッチをテストし、業務の中断やその他の問題が発生しないか確認することがあります。テストに失敗したパッチは、IT部門が例外および緩和プロセス（下記の第3.F項を参照）に従う限り、パッチ適用の対象から除外できます。
[サードパーティーベンダーやパッチ管理サービス・ツールは、一般的な環境でパッチをテストします。しかし、特定のITアーキテクチャや依存システムでは、意図しない影響が発生する可能性があります。
テスト環境でパッチをテストすると、業務プロセスに影響を与えない環境でIT部門がこうした問題を発見できます。すべての組織にパッチテストを実施するリソースがあるとは限らず、低価値のリソースのパッチテストは時間やリソースの費用対効果が合わない場合があります。]
ii. パッチ管理の準備
すべてのパッチが問題なく適用できるとは限りません。パッチによってデバイスが使用不能になったり、他のITシステムやソフトウェアに連鎖的な問題が発生したりすることがあります。この可能性に備え、IT部門は、[パッチ管理プロセスの前に災害復旧ポリシーが実行されていることを確認しなければなりません。
少なくとも次のことを実施します。]
- 更新を適用する前に、システム全体のバックアップを実行する
- 更新を適用する前に、データ全体のバックアップを実行する
重要なシステム（ルーター、サーバーなど）のファームウェアを更新する場合、更新によって元のデバイスが機能しなくなったときに備え、バックアップシステムを用意しておく必要があります。
更新に失敗した場合、IT部門は機能を回復するため、システムまたはソフトウェアを以前のバージョンにロールバックします。ロールバックできないシステムは、バックアップから速やかに復元するか、交換する必要があります。
IT部門は、パッチや更新の適用を複数回試行できます。正常に適用できないパッチや更新については、IT部門は以下の例外および緩和プロセスに従わなければなりません。
[このセクションでは、すべてのパッチが意図どおりに機能するわけではなく、IT部門はあらゆる種類のパッチを適用する前に、その可能性に備えなければならないことを認めています。バックアップと復旧システムを詳しく定めた既存の災害復旧ポリシーを参照することを推奨します。そのようなポリシーがない組織は、この文言を削除して、バックアップの実行だけを必須にすることもできます。]
iii. パッチおよび更新の自動管理
多くのベンダーは、自社アプリケーション向けに自動パッチ適用手順を提供しています。さらに、パッチ管理プロセスを支援するサードパーティー製のツールやサービスプロバイダーも数多く存在します。
実用的かつ可能な場合、IT部門は適切な選択肢を使用してパッチ管理プロセスを自動化する必要があります。自動化サービスによってIT部門の負担を軽減し、遅延なくIT環境全体にパッチを速やかに適用できます。
IT部門は、自動プロセスを開始する前に、すべてのパッチ管理準備（上記第3.E.ii項を参照）が正常に完了していることを確認しなければなりません。
ファームウェア、ITアプライアンス（ルーターなど）、ソフトウェアのベンダーでは、手動でのパッチ適用や更新が必要になる場合があります。自動パッチ適用に使用するベンダーやツールは、パッチ適用や更新の対象とするもの、対象外とするものを明確に示す必要があり、資産リストには手動更新が必要な項目を反映させます。
iv. 手動パッチ管理
一部のパッチや更新（特にファームウェア）には手動作業が必要です。業務プロセスを中断しない更新については、IT部門が、パッチや更新の緊急度に応じて定められた期間内で、裁量により適用できます。
一部のパッチでは、重要な業務システムを停止しなければならない場合があります。過度な中断を避けるため、こうしたメンテナンス時間帯は事前にスケジュールを設定し、パッチ管理責任者の承認を得る必要があります。中断の影響を受ける適切な業務責任者の同意も得ることが望まれます。
承認を得るため、IT部門は次の情報を記載したメンテナンス時間帯の申請を、パッチ管理責任者に[チケットを発行／フォームに記入／メールを送信]して提出しなければなりません。
- 影響を受けるシステムの詳細
- パッチの緊急度とリスクに関する詳細
- 希望するメンテナンス時間帯と、少なくとも1つの代替時間帯
- パッチが失敗した場合のロールバック手順の詳細
パッチ管理責任者が不在の際に緊急パッチが必要となった場合は、組織図上で次に権限を持つ役員がメンテナンス時間帯を承認できます。
緊急パッチを適用する必要があり、パッチの緊急度を踏まえた合理的な時間内に、承認できる、または承認する意思のある役員がいない場合、IT部門は承認を得ようとした対応を記録したうえで、正式な承認なしにパッチや更新を適用できます。緊急パッチやメンテナンスによる中断が必要になる場合もありますが、IT部門は常に中断を最小限に抑える必要があります。
[このパッチ適用プロセスの正式な記述では、ソフトウェア更新によって利用中のユーザーやシステムにダウンタイムが生じる場合、パッチの実施担当者がメンテナンス時間帯を申請することを求めています。]
v. パッチの検証とテスト
パッチ適用と更新のプロセスが完了したら、IT部門はパッチが正常に適用されたことを確認し、適用に失敗したパッチを報告して修正する必要があります。また、パッチが対象とした脆弱性が、実際にパッチによって緩和または排除されたことも確認します。
依然として露出している脆弱性には、例外および緩和策（下記の第3.F項）に従って対処する必要があります。
F. 例外および緩和策
パッチ適用および更新のプロセスでは、例外が発生することがあります。これらの例外は、次のように分類します。
- 適用に失敗したパッチ：正常にインストールできないパッチや更新
- 業務を中断するパッチ：インストールすると、許容できない業務中断を引き起こすパッチや更新
- 不要なパッチ：不要または望ましくない機能を有効にしたり修正したりする、セキュリティ以外のパッチや更新
- 未適用の脆弱性：サポート終了やベンダーの廃業など、さまざまな理由により、ベンダーによるパッチが未提供のまま脆弱性が残っている資産もあります
すべてのカテゴリを例外リストに記録しなければなりません。不要なパッチは単に記録し、[四半期ごと]に確認して、引き続き不要であることを確認します。
適用に失敗したパッチ、業務を中断するパッチ、未適用の脆弱性には、緩和策が必要です。IT部門は、未適用の脆弱性が組織にもたらすリスクと潜在的な損害を抑えるため、適切な緩和策を策定して提案します。各緩和計画は、パッチ管理責任者の承認を受け、次の内容を含めなければなりません。
- 影響を受けるシステムの詳細
- 未適用の脆弱性の緊急度に関する詳細
- 緩和策の詳細と、それによって未適用の脆弱性にどう対処するか
- 希望する適用時間帯と、少なくとも1つの代替時間帯。緩和策を実施するために業務システムを停止する必要がある場合は、その旨を記載します。
緩和策および例外リストは、次の事項を判断するために、[四半期ごと]に見直します。
- 緩和策を終了できるよう、パッチがリリースされているか
- 緩和策を終了できるよう、資産を廃止または交換すべきか、または廃止・交換済みか
- 緩和策を何らかの方法で改善できるか
パッチ管理責任者は、緩和策および例外リストの[四半期ごと]の見直しを承認しなければなりません。
[パッチを適用できない場合は、リスクを緩和するための別のアプローチを策定し、書面で承認を得なければなりません。ほとんどの組織では、この文書に記載されたとおり、四半期ごとの見直しを実施できます。ただし、小規模な組織では半年ごと、または年1回の見直しを行うだけのリソースしかない場合があります。一方、大規模な組織では、より積極的に対応し、月次または週次の見直しを希望する場合があります。]
G. パッチおよび更新の報告
IT部門は、パッチ適用および更新について[月次]レポートを発行します。月次レポートには、次の内容を含めなければなりません。
- 最後に資産をスキャンした日付と、追跡対象資産の数
- 自動パッチ管理の対象となっているシステムの割合
- パッチ適用状況を監視しているシステムの割合
- 期間中にベンダーが発行した、または組織が取得したパッチの数
- 期間中に品質チェックに失敗したパッチの数
- 正常にインストールできなかったパッチの数
- インシデントチケットの発行につながったパッチの数
- パッチの適用に成功した件数と、失敗したパッチの件数の比較
- CSV評価および資産のリスクまたは価値カテゴリ別の、パッチの利用可能時点から適用までの平均経過時間
- 例外レポートに追加された例外の数
- 例外レポートに記載されている例外の合計数
[IT部門は、組織がパッチ管理手順が適切に守られ、パッチや更新が適時に適用されていることを検証できるよう、レポートを発行しなければなりません。定期的なレポートにより、コンプライアンス確認のための特別なレポートが不要になる場合があります。
レポートのデータは、パッチ管理プロセスの改善にも活用すべきです。例えば、チケットの発行につながったパッチの数から、追加のパッチテストが必要か、または現在のテストに改善が必要かを判断できます。
より成熟した組織では、パッチが適切にインストールされたことを確認するため、定期的な脆弱性テストやペネトレーションテストも実施する場合があります。これらのテストレポートを、通常のパッチおよび更新レポートに追加することもできます。]
4. 監査管理策と管理
[eSecurity Planet]の経営幹部や監査担当者は、パッチ管理の実施に関する文書化された手順や証拠を、必要に応じて要求することがあります。文書化された手順や証拠の例には、次のものがあります。
- 承認済みメンテナンス時間帯申請
- 承認済み例外リスト
- 主要なシステムおよびユーティリティの全カテゴリに関する、システム更新およびパッチのログ
- ログには、システムID、パッチ適用日、パッチのステータス、例外、および例外の理由を含める必要があります
- システム、アプリケーション、デバイス全体にわたるエンタープライズパッチ管理を支えるインフラストラクチャの実証
- パッチ管理レポート
[このセクションでは、経営幹部や監査担当者が、パッチ管理プロセスについて予定外のレポートを必要とする場合があることを認めています。パッチ管理レポートを検証するため、監査担当者によっては、システムまたはソフトウェアの更新が成功したことを確認するシステムログも求める場合があります。]
5. 適用と執行
意図的なポリシー違反が認められた従業員は、解雇を含む懲戒処分の対象となる場合があります。IT部門のスタッフのうち、このポリシーの実施を担当する者の業務遂行は、このポリシーの要件を満たす能力の一部または全部に基づいて評価されます。
IT部門がこのパッチ管理ポリシーの要件を恒常的に満たせない場合、過失とみなされ、懲戒処分につながることがあります。虚偽のレポートや実施における重大な過失は、即時解雇または懲戒処分の理由となる場合があります。
パッチ適用要件に準拠しないオペレーティングシステム、ソフトウェア、ファームウェアを含むデバイスは、価値または機能の面で重要なリソースへのアクセスをDMZまたは分離されたネットワークセクションに限定すべきです。
[ポリシーを有効にするには、コンプライアンス違反に対する罰則を設ける必要があります。ここでは簡単に触れているだけですが、ネットワークセキュリティポリシーでは、準拠しないデバイスが組織内でどのリソースに、どのようにアクセスできるかを明確に定めるべきです。
この文書では、リソース不足により更新基準を満たせない組織は、IT部門が過重労働や業務過多の状態にある場合、その責任を問わないことを想定しています。過度な期待を課す組織では、IT部門の離職率が高まり、経験豊富または有能なスタッフの維持が困難になる可能性があります。]
6. 配布
このポリシーは、パッチ管理ポリシーのサポートおよび管理を担当する[eSecurity Planet]の全経営幹部とIT部門スタッフに配布します。
[パッチ管理に携わる必要がある人（IT部門スタッフ）や、ポリシーの影響を受ける人（少なくとも経営幹部、および場合によってはその他の関係従業員）には、このポリシーを渡す必要があります。実施を担当する従業員には、受領を正式に確認してもらう必要がある場合があります。]
7. ポリシーバージョン
バージョン1.0
承認日：2022年11月15日
説明：初版ポリシー策定
[このセクションは、以前のバージョンと承認の一覧表を含むポリシーバージョン履歴にすることもできます。]
8. 署名
承認者：____________________________________________
[パッチ管理責任者の署名]
承認者：____________________________________________
[CEOまたは該当するその他の経営幹部]
[パッチ管理責任者が署名することで、ポリシーの要件を認識し、その要件を満たすことを事実上誓約したことになります。CEOまたはその他の経営幹部が署名することで、そのポリシーが組織のニーズを満たしていることを認識したことになります。署名する経営幹部は、その署名によって他部門にポリシーを遵守させられる程度に上位の役職者であるべきです。]
付録
I. ITリソース資産リスト
[資産管理ポリシーに従い、]組織の資産リストには、組織のすべてのシステム、ソフトウェア、ファームウェア、デバイスを含める必要があります。資産リストには、BYOD、アクセス権を持つリース機器、請負業者の機器など、組織の管理外にあるもののネットワークに接続されているデバイスを含めることもできます。
資産リストに含めるリソースの例には、次のものがあります。ただし、これらに限定されません。
- ネットワーク機器
- ファイアウォール（インストール済みのソフトウェア、ファームウェア、更新が必要なセキュリティ機能を含む）
- ネットワークスイッチ（インストール済みのソフトウェア、ファームウェアを含む）
- ルーター（インストール済みのソフトウェア、ファームウェアを含む）
- サーバー（Webサイト、アプリケーションホスト、仮想化プラットフォームなど）およびインストール済みのオペレーティングシステム
- インストール済みのオペレーティングシステム、インストール済みのソフトウェア、ファームウェア）
- ワークステーション
- タブレット
- ノートパソコン
- 携帯端末
- モノのインターネット（IoT）およびインストール済みのソフトウェアとファームウェア
- インターネット電話（VoIP）
- セキュリティカメラ
- Wi-Fi接続テレビ
- Wi-Fiプリンター
- ネットワークプリンター
- ストレージエリアネットワーク（SAN）
- 音声操作デバイス（Amazon Alexaなど）
- [心拍モニターなどの医療機器]
- 太陽光パネルシステム
- ドアセキュリティ用バッジリーダー
- 運用技術（OT）、接続されたインフラストラクチャ、およびインストール済みのソフトウェアまたはファームウェア
- 5G接続コンベヤーベルト
- 接続されたHVAC機器
資産リストには、次の項目を含める必要があります。
- 資産の種類（サーバー、PC、ソフトウェア、ルーターなど）
- デバイスの割り当て所有者（共有リソースの場合は、関連部門の責任者を事実上の割り当て所有者とする）
- 主要OS、ファームウェア、またはソフトウェアのバージョン
[注：特定のバージョンを追跡・維持することは有用ですが、手動追跡システムを使用する組織にとっては負担になる可能性があります。] - 手動更新か自動更新か
- IT部門、自動ソフトウェア更新、サードパーティー製ツール、またはサードパーティーサービスプロバイダーのいずれによって更新されたか
- 最終更新日
- 更新成功（はい／いいえ）
- 関連デバイス（例：Adobe Acrobatソフトウェアの場合、関連デバイスであるPC4362にインストール）
[IT部門]が資産リストの維持に責任を負う一方で、部門責任者は、新たに導入した資産（デバイス、インストール済みソフトウェアなど）についてIT部門に通知しなければなりません。IT部門に通知せずに導入されたデバイスやソフトウェアは、不正デバイスとみなされ、ブロックおよび削除の対象となります。
[IT部門]は、資産リストが最新の状態に保たれていることを確認し、不正なデバイスやソフトウェアを検出するため、IT環境を[継続的／月次／日次／四半期ごと]にスキャンします。
現在の資産リストの保存場所：
[資産データベース、Excelスプレッドシート、資産管理ツールをここに記載します。
注：Excelスプレッドシートは、偶発的または意図的な破損や変更に対して脆弱になる可能性があります。バージョン管理されたGoogleスプレッドシート、またはOneDriveやSharePointに保存されたExcelファイルの方が適しています。]
組織は、資産管理ポリシーを策定し、維持すべきです。ポリシーの策定と資産リストの例は、このサンプル文書の対象範囲外です。
BYODデバイスは資産リストで追跡すべきではありません。BYODデバイスの管理は、デバイスの最低限許容されるセキュリティプロファイルを確認するネットワークアクセス制御機能またはツールを使用して適用します。]