Vulnerability Management Policy Template

このテンプレートの使用方法：

このテンプレートの理解と使用を案内するコメントは角括弧「[…]」で囲み、文書全体で「会社」は[eSecurity Planet]と記載しています。このテンプレートを実際に運用するポリシーに変換する際は、角括弧で囲まれた部分を削除し、「[eSecurity Planet]」を組織名に置き換えてください。

このポリシーは、一般的なITインフラとニーズを想定しています。特定の企業のITインフラとニーズを反映するよう、必要に応じて変更できます。

このテンプレートを使用するには、ウェブサイトのテキストをコピーして貼り付けるか、下記のMicrosoft Wordテンプレートをダウンロードしてください。

1. 概要

セキュリティ脆弱性によって、攻撃者はリソースやデータを侵害できます。脆弱性は、製品の欠陥、設定ミス、セキュリティおよびITシステムの不備によって発生します。

脆弱性は、計画外と計画済みの2種類に分類されます。計画外の脆弱性には、ゼロデイ脆弱性、設定ミス、その他のセキュリティ上の誤りが含まれます。計画済みの脆弱性は、修正できない、または修正されない既知の脆弱性です。

この脆弱性管理ポリシーは、未知および既知の脆弱性による許容できないリスクから会社のリソースを保護するために、[eSecurity Planet]のITチームおよびセキュリティチームが満たすべき要件を定めます。この脆弱性管理ポリシーは、次の事項を定めます。

• 次の事項に関する期待事項、要件、基本手順の概要を示します。
• • 脆弱性の特定
  • 脆弱性の評価
  • 脆弱性の緩和
  • 脆弱性の追跡
• このポリシーへの準拠を確認するためのレポートを定義します
• このポリシーに違反した場合の罰則を定めます

［このセクションの目的は、読者にポリシーの目的と、文書の後半で説明される内容を紹介することです。ポリシーでは、実施すべきこと（MUST）を定めますが、その方法を定めるものではありません。ITおよびセキュリティの管理者は、保有するリソースの範囲内で、適切と考える方法により目標を達成できる柔軟性を必要とします。］

2. 適用範囲

このポリシーは、組織のネットワークに接続する、リソース間の接続を提供する、リソースを保護する、組織の使命を実現する、または組織のデータをホスティングする、[eSecurity Planet]のすべてのリソースに適用されます。組織は、このポリシーの適用範囲に含まれるリソースの正式な一覧を、定義に従って管理・追跡します。付録I：ITリソース資産一覧。

脆弱性管理は、既存のシステム、ソフトウェア、接続、セキュリティに関する正確な一覧に依存します。すべての資産を正確に評価し、脆弱性を特定するテストを実施できるよう、適用範囲は［資産管理ポリシーに従って／毎月／四半期ごとに］確認する必要があります。

他の部門が所有・管理していないウェブサイトやアプリケーションも、脆弱性スキャンの対象にする必要がある場合があります。IT部門は、脆弱性管理に抜け漏れが生じないよう、各アプリケーションおよびウェブサイトの責任の所在を確認する必要があります。

脆弱性管理における重要な要素ではありますが、パッチ管理と変更管理については、それぞれ個別のポリシーで別途扱います。

［これは適用範囲の一般的な例であり、脆弱性特定のために監視・テストする対象を定義する必要があります。組織は、付録で必要に応じて適用範囲を広くも狭くも設定できます。リスクを管理するには広い範囲が常に望ましいものの、コストが増える可能性があります。］

3. 脆弱性管理ポリシーおよび手順

A. 脆弱性管理責任者

[eSecurity Planet]の最高情報セキュリティ責任者（CISO）を脆弱性管理責任者に指定します。脆弱性管理責任者は、このパッチ管理ポリシーおよび手順のあらゆるセクションを計画、実行、承認し、または社内のリソース、サードパーティ製ツール、ベンダーに委任する最終的な責任と権限を持ちます。

脆弱性管理責任者が最終的な責任を負う一方で、脆弱性管理ポリシーに準拠するため、通常は［ITセキュリティ部門］が脆弱性管理責任者の計画を実行するものとします。本ポリシーの別の箇所で使用する「IT部門」は、脆弱性管理責任者、［ITセキュリティ部門］および委任された担当者を指します。

脆弱性管理責任者は、次の事項についても確認・承認します。

• 脆弱性管理ポリシーの適用範囲
• 脆弱性の優先度
• 脆弱性テストおよび侵入テスト
• 変更または緩和に必要なメンテナンス停止
• 必要な例外
• 脆弱性管理レポート
• 実施・執行

［このセクションでは、予算を承認し、脆弱性管理プロセスを管理する責任者を定義します。担当者が変わるたびにポリシーを改訂する必要がないよう、個人名ではなく役職名を使用するのが最適です。］

B. 脆弱性の特定

IT部門は、セキュリティに脆弱性がないと仮定してはなりません。リソースが、セキュリティ上の誤りや不備なく導入、設定、統合、保護されていることを確認するため、テストを実施する必要があります。

i. アクティブな脆弱性検出

未知の脆弱性を検出するため、脆弱性スキャンと侵入テストを［四半期ごと］に、またリソースに重大な変更を加えた後に実施します。価値の高いデータを含む、または業務上の重要性が高い高リスクシステムについては、［毎月］スキャンを実施する必要があります。

脆弱性スキャンは、対象リソースに関連する具体的な潜在脆弱性をテストできる限り、自動化し、市販ツールを使って実施できます。未認証の脆弱性スキャンは外部の攻撃者の視点でシステムを確認するために、認証済みの脆弱性スキャンは、盗まれた認証情報を持つ攻撃者の視点でシステムを確認するために実施します。

特定の脆弱性やゼロデイ脅威が発見された場合、必要に応じて、特定の脆弱性を対象としたスキャンを臨時に実施することがあります。これらのスキャンは必要に応じて実施し、通常のスキャンスケジュールに制限されないものとします。

ii. 情報および脅威の監視

IT部門は、テストに加えて、さまざまな情報源を継続的に監視・スキャンし、新たな攻撃手法やリソースの脆弱性に関する情報を入手します。リソースの更新とパッチはパッチ管理ポリシーの適用範囲に含まれますが、未適用のパッチによる脆弱性は、本脆弱性管理ポリシーの適用範囲内で対処する必要があります。情報源には、セキュリティメーリングリスト、ベンダーからの通知、ウェブサイトなどが含まれますが、これらに限定されません。

iii. サードパーティシステム

組織では、次のようなサードパーティのエンドポイントやシステムとの統合が必要になる可能性があります。

• リースした産業用制御システム（エレベーターシステム、消火システムなど）
• リースした業務用機器
• 従業員、コンサルタント、顧客、ゲストが持ち込む個人所有デバイス（BYOD）
• クラウドベンダーと組織が共同で監視・管理するクラウドインフラ

脆弱性スキャンには、組織に接続されたアクセス可能なすべてのシステムを含める必要があり、これらのサードパーティシステムを含める場合もあります。ただし、検出された脆弱性が、解決のための社内リソースの対象範囲を超える可能性があります。企業パートナーとの正式な契約により、さまざまな種類の脆弱性について、当事者間の責任を定義できます。

ただし、正式な責任の所在にかかわらず、IT部門は脆弱性を緩和するための補完的対策を準備する必要がある場合があります。例えば、組織はネットワークアクセス制御または同等のソリューションを使用して継続的にスキャンを実施し、脆弱性のあるエンドポイントが組織のネットワークへの接続を試みた時点で検出し、隔離する必要があります。

iv. 文書化

IT部門は、情報収集のために監視するすべてのスキャン、テスト、情報源を一覧化し、脆弱性特定プログラムを設計・文書化する必要があります。これは本ポリシーに追加する付録として利用できるようにし、必要に応じて更新します。組織の中で最もリスクの高い資産は、状態を確認するために実施するテストとともに、具体的に一覧化して記録する必要があります。

［スキャンツール、侵入テスト、脅威情報源の種類を列挙するだけで十分な場合も多い一方、主要資産の表を追加すると、さらなる保護になります。組織によっては、最も重要なシステムを実際にテストできるかを考慮せず、安価なツールで形式的なスキャンを実施しています。］

脆弱性が特定された場合、IT部門がチケットを発行し、脆弱性管理追跡リストで脆弱性を追跡します。

［このセクションは、利用可能な更新やパッチに対する警戒と迅速な認識を徹底するためのものです。ベストプラクティスでは、更新やパッチの情報源を調査、特定、検証する担当者を具体的に割り当てることが推奨されています。］

C. 脆弱性の評価

脆弱性を特定したら、組織に対する潜在的なリスクを検証・評価する必要があります。脆弱性は、検出したリソースとは異なる担当者と独立したツールを使用して検証する必要があります。場合によっては、脆弱性を検証したりリスクを評価したりするため、脆弱性の悪用を積極的に試みる必要があります。

脆弱性は、次の基準に基づいて評価します。

• 共通脆弱性評価システム（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）は、実際に悪用されているかを確認するために参照できる既知の悪用された脆弱性の一覧を管理しています。

同様に、IT部門は現在の環境、ITアーキテクチャ、脆弱性の性質を評価し、悪用される可能性を判断する必要があります。この可能性も、1（可能性が低い）から10（可能性が高い）の尺度で評価します。可能な場合は、類似の脆弱性の悪用に関する脅威インテリジェンス情報を組み込み、悪用可能性の評価を裏付ける必要があります。これら3つの要素を合算すると、脆弱性を緩和するための1（優先度が低い、または対応不要）から20（緊急対応が必要）までの値が得られます。

［多くの組織は、プロセスで数値によるランキングを使用することを好みません。特に導入初期は、値の割り当てに時間がかかる可能性があります。しかし、数値はIT部門外にリスクと緊急性を伝えやすくし、レポート作成とコンプライアンスを促進します。］

脆弱性によって既存または新たな別の脆弱性が露呈する場合は、それらの関連する脆弱性を記録する必要があります。脆弱性に関連するシステム、ソフトウェア、プロセスも記録します。

影響を受けるシステムの一覧が膨大になる場合は一般化しても構いませんが、可能な限り具体的に記載する必要があります。例えば、次のようにします。

• すべてのオフィスで使用されているファイアウォールモデルの脆弱性は、「組織内のすべてのオフィス、システム、プロセス」に該当すると一般化して記載します。
• 特定のネットワークセグメントにある特定のルーターの脆弱性については、次の項目を具体的に記載します。
• • 影響を受けるIPアドレスの範囲
  • 影響を受ける人（例：ポルトの財務部門のユーザー）
  • 影響を受けるデバイス（例：財務サーバー、会計用PC、財務部門のPC、ローカルプリンター）
  • 影響を受ける注目すべき、または価値の高いプロセスやシステム（例：会計システム、買掛金、売掛金など）

［このセクションでは、組織に対する潜在的なリスクを推定するための評価基準を概説します。特定の脆弱性が特定のシステムに影響を及ぼす場合でも、組織への潜在的な影響を判断するには、他の影響を受けるシステムやプロセスとの関係を考慮する必要があります。］

D. 脆弱性の優先度

テスト中またはゼロデイ脆弱性の発表時に、複数の脆弱性が特定されることがあります。必要に応じて、IT部門は、次の項目に基づく階層を使用し、他の既存の脆弱性との関係を踏まえて、これらの脆弱性を緩和する優先度を決定します。

• 脆弱性評価値（上記の）脆弱性評価で決定された値
• リスク評価値脆弱性の影響を受ける組織のリソース（データ、システム、プロセスなど）の値

リスク評価値：[eSecurity Planet]はリスク分析を使用して内部システムのリスク評価を作成し、リスク登録簿に1（影響・価値が低い）から10（影響・価値が最大）までの尺度で記録・更新します。ただし、1つの脆弱性が複数のシステム、ソフトウェア、プロセスに影響を及ぼす場合があるため、リスク値には、影響を受けるすべてのリソースの合計、または影響を受けるリスク値の最大値のうち、大きい方を反映させる必要があります。

1～10のリスク評価スコアと1～20の脆弱性評価値を組み合わせると、脆弱性の優先度スコアは2（対応不要）から30（即時対応が必要）の範囲になります。この優先順位付けにより、通常はIT部門が対処すべき脆弱性の階層が設定されます。

［このセクションでは、脆弱性管理プロセスでどの脆弱性から対処すべきかを判断するための優先度を割り当てます。脆弱性への対応を避けたり、影響が小さく実装しやすい低リスクの緩和策を選択したりするために、悪用リスクや資産価値を都合よく操作しないよう注意してください。

このセクションでは、リスク評価とリスク登録簿を参照しています。規模を問わず、すべての組織がリスク登録簿を作成できますし、作成すべきです。リスク登録簿では、リソースの価値と、そのリソースが機能低下、侵害、または障害に陥った場合に組織に生じ得る影響の大きさを評価します。

直接的なリスクと間接的なリスクの両方を考慮する必要があります。例えば、Wi-Fiルーターのファイアウォール設定の脆弱性によって、製造設備の稼働に必要なWindows 95マシンが露出する可能性があります。露出したルーターのリスクには、露出したWindows 95マシンのリスクと、製造設備が侵害された場合の業務上のリスクも含まれます。

リスク登録簿がない場合、組織はリソースの価値を定性的に推定する必要があります。］

E. 脆弱性緩和ガイドライン

脆弱性を特定、評価、優先順位付けしたら、その脆弱性に対処するための緩和策を設計、テスト、準備、スケジュール設定、適用、検証、再テストする必要があります。

i. 脆弱性緩和策の設計

パッチ管理の下位カテゴリでは、市販製品に対して市販の緩和策、すなわちパッチを適用します。この内容はパッチ管理ポリシーで包括的に扱います。より広範な脆弱性管理では、設定のカスタマイズ、ITアーキテクチャの調整、追加のセキュリティツールや制御の導入が必要になります。

脆弱性を直接的または間接的に緩和する方法は、複数存在することがよくあります。多くの場合、必要な緩和策にかかるコストや複雑さのため、脆弱性を完全に排除することは不可能です。

ただし、コストや難しさを脆弱性無視の言い訳にしてはなりません。リスクレベルに応じた期間内に、一時的な緩和策や部分的な緩和策（補完的対策）を設計、テスト、適用する必要があります。

一般的な緩和策には、次のものが含まれますが、これらに限定されません。

• 新しいセキュリティツール（ファイアウォールなど）といった緩和用のセキュリティ制御を導入する
• パッチを適用する
• セキュリティ制御に多要素認証を追加する
• 脆弱なITリソースをアップグレードまたは交換する
• 脆弱なITリソースを隔離・保護する（ネットワークセグメンテーション、無線アクセスの切断など）
• ITリソースの使用を停止または中止する
• 設定変更を導入する

複雑な緩和策では、複数の補完的対策または複数の手順が必要になる場合があります。より複雑な緩和策については、導入の進捗を確認できるよう、マイルストーンを設定する必要があります。

場合によっては、緩和策として多要素認証（MFA）など、ユーザーに影響を及ぼす技術的対策の導入が必要になります。これらのツールに関するトレーニングは、緩和策の設計の一部として検討する必要があります。ただし、通常、トレーニングを脆弱性緩和の最短スケジュール期間内に完了する必要はありません（下記参照）。

ii. 脆弱性緩和策のテスト

価値の高いリソースについては、IT部門は、業務の中断やその他の問題が発生する可能性を確認するため、テスト環境で緩和策をテストすることを決定できます。テストプロセスに失敗した緩和策は、再設計して再テストする必要があります。

［テスト環境で緩和策をテストすると、IT部門は業務プロセスに影響を及ぼさない環境で問題を発見できます。ただし、価値の低いリソースのテストを実施するためのリソースを、すべての組織が持っているわけではありません。］

iii. 脆弱性緩和策の準備

すべての緩和策が問題なく正常に適用されるとは限りません。緩和策によってシステムが使用不能になったり、他のITシステムやソフトウェアに連鎖的な問題が発生したりする場合があります。この可能性に備えるため、IT部門は、［パッチ管理プロセスの前に、災害復旧ポリシーが実行されていることを確認する必要があります。

少なくとも］：

• 更新プログラムを適用する前に、システム全体のバックアップが実行されていること
• 更新プログラムを適用する前に、データ全体のバックアップが実行されていること

業務を中断させる緩和策が正常に適用されなかった場合、IT部門は、機能を回復するため、システムまたはソフトウェアを以前のバージョンにロールバックすることを試みます。ロールバックできないシステムは、速やかにバックアップから復元するか、交換する必要があります。場合によっては、中断が発生してもシステム自体は維持され、業務を復旧するために緩和策の計画変更が必要になることがあります。このような変更は、中断を最小限に抑えるため、可能な限り迅速に実施する必要があります。

IT部門は、緩和策の導入を複数回試みることができます。正常に適用できない緩和策については、IT部門は下記の例外および緩和プロセスに従う必要があります。

［このセクションでは、すべての緩和策が意図したとおりに機能するとは限らず、IT部門は、どのようなパッチを適用する場合でも、その前にこの可能性に備える必要があることを示しています。バックアップと復旧システムを詳細に規定した既存の災害復旧ポリシーを参照することを推奨します。ただし、そのようなポリシーがない組織では、この文言を削除し、単にバックアップの実行を義務付けることもできます。］

iv. 脆弱性緩和スケジュール

脆弱性管理一覧のランキングに基づき、IT部門は次の期限で緩和策に取り組む必要があります。

• 20以上：5営業日以内
• 14.0～20：10営業日以内
• 8.0～13.9：30営業日以内
• 8.0未満の脆弱性：90日以内

［脆弱性への対応にかかる時間は、潜在的なリスクによって異なります。銀行、病院、その他、組織に対する高いリスクと影響が生じる可能性のある組織では、最上位の区分を日単位ではなく時間単位（例：72時間）に設定できます。］

脆弱性緩和は、発見された脆弱性のリスクを低減するために必要なセキュリティツール、設定の調整、ITアーキテクチャの変更、その他の手順で構成されます。

脆弱性の優先度に影響を与えるその他の要素には、次のものがあります。

• 必要な緩和策脆弱性に対処するための
• 潜在的な緩和策またはセキュリティ制御が複数の脆弱性に対処するかどうか
• 業務に混乱をもたらす可能性必要な緩和策による

必要な緩和策は、脆弱性に対処するための単純なファイアウォールポートの調整から、複数の新しいセキュリティツールや制御の複雑な導入まで多岐にわたります。一般に、導入とテストのコストを考慮して、単純な解決策が優先されます。ただし、緩和策によって露呈した脆弱性のリスクを十分に低減できなければなりません。

解決策が複雑であっても、脆弱性を緩和する緊急性が低下するわけではありません。ただし、初期リスクを低減するために一時的な対策を適用できる場合は、脆弱性の全体的な優先度と評価を見直すことができます。

緩和策またはセキュリティ制御で、複数の脆弱性に対処するものは、緩和策がより緊急性の高い脆弱性緩和策の導入を妨げない限り、IT部門の裁量で優先することができます。効率性は重要ですが、露呈したリスクによる潜在的な損害を上回るものではありません。

業務に混乱をもたらす可能性は、必要な緩和策によって生じる場合があります。可能な限り、業務への影響は回避・最小化する必要があります。

過度な中断を避けるため、このような業務を中断させる緩和策には、メンテナンス時間を設定し、脆弱性管理責任者の事前承認を得る必要があります。中断の影響を受ける適切な業務マネージャーの同意も得ることが望ましいでしょう。

承認を得るため、IT部門は、メンテナンス時間の申請に次の情報を記載した［チケットを発行／フォームに記入／メールを送信］し、パッチ管理責任者に提出する必要があります。

• 影響を受けるシステムの詳細
• 脆弱性の緊急性とリスクの詳細
• 希望するメンテナンス時間と、少なくとも1つの代替時間
• 緩和策が失敗した場合のロールバック手順の詳細

脆弱性管理責任者が不在の際に必要となる緩和策については、組織図上で次に位置する役員がメンテナンス時間を承認できます。

緊急の緩和策を適用する必要があり、脆弱性の緊急性に応じた必要な時間内に、役員が緩和策を承認できず、または妥当な代替メンテナンス時間を提案できない場合、IT部門は次の条件で実施できます。

• 承認を得るための取り組みを文書化していること
• 役員以外の影響を受ける関係者（顧客、従業員など）にメンテナンス時間を通知すること
• 正式な承認なしに緩和策を実施すること

緊急の緩和策やメンテナンスによる中断が必要になる場合があることは認識されていますが、IT部門は常に中断を最小限に抑える必要があります。

［このパッチ適用プロセスの正式な規定では、緩和策の実施責任者に対し、ソフトウェア更新によって使用中のユーザーまたはシステムにダウンタイムが発生する場合のメンテナンス時間を申請するよう求めています。一方で、業務部門の役員が妥当な方法でダウンタイムを承認できない、または承認する意思がない場合には、業務よりもセキュリティを優先します。

正確な評価システムと緊急性は、組織が決定します。優先度に基づくスケジュールでは、最も重要なリソースに対する最も重要なパッチと更新に迅速に対応できるようにする必要があります。緩和策の適用期限を最長30日とすることで、システムやソフトウェアが見落とされたり完全に放置されたり、更新が蓄積したりすることを防げます。］

v. 脆弱性緩和策の適用

脆弱性緩和には通常、手動のプロセスが必要です。IT部門は、想定された期間内に緩和策を適切に確立するため、十分なリソースを確保して導入することが期待されます。必要に応じて、大規模な緩和策や高リスク資産への緩和策を実施するため、外部の専門知識を調達できます。

［このパッチ適用プロセスの正式な規定では、緩和策の実施責任者に対し、導入のために追加のリソースを雇用する必要がある場合でも、緩和策を期限内に提供するよう求めています。この文言では、予算管理よりもセキュリティを優先しているため、組織のニーズに合わせて変更が必要になる場合があります。］

vi. 脆弱性緩和策の検証とテスト

緩和策の適用が完了したら、IT部門は、緩和策が想定どおりに機能し、意図したとおりにリスクを低減していることを確認する必要があります。成功を検証し、または失敗した緩和策を特定して報告するため、侵入テストと脆弱性スキャンを再度実施する必要があります。露呈したままの脆弱性には、下記の「緩和策の追跡と例外」（第3.F項）で定めるとおり対処する必要があります。

F. 緩和策の追跡と例外

緩和策によって脆弱性が必ず解決されるとは限りません。多くの場合、脆弱性を緩和するために導入された補完的対策は、脆弱性そのものに直接対処することなく、追加のセキュリティ層の背後に脆弱性を隠します。

未解決の脆弱性と関連する緩和制御はすべて、脆弱性管理の追跡一覧で、将来発生する可能性のある脆弱性として引き続き追跡・監視します。緩和された脆弱性については、［四半期ごとに］確認し、時間、保守費用を節約できる、またはリスクをさらに低減できる、より効率的な緩和策を導入できるか判断する必要があります。

パッチ適用またはメンテナンスについて、失敗したシステム、業務を中断させるシステム、またはパッチ未適用のシステムは例外となり、本ポリシーに基づく脆弱性として対処されます。ただし、失敗した緩和策や業務を中断させる緩和策の大半は、例外として残ることはありません。失敗した緩和策や業務を中断させる緩和策は、解決に向けて修正し、脆弱性管理プロセスに再投入します。まれに、低リスクの脆弱性と補完的対策の高コストが組み合わさることで、組織が特定の脆弱性のリスクを受容する場合があります。これらの例外は、脆弱性一覧内で追跡・報告する必要があります。

［ほとんどの組織は、この文書に概説されているとおり、四半期ごとのレビューを実施できます。ただし、規模の小さい組織では、半年ごとまたは年1回のレビューを実施するだけのリソースしかない場合があります。また、規模の大きい組織では、より積極的に、高リスクまたは価値の高いシステムについて月次または週次のレビューを実施したいと考える場合があります。］

G. 脆弱性管理の報告

IT部門は、パッチ適用と更新について［月次］レポートを発行します。レポートには次の内容を含める必要があります。

• 最後に資産スキャンを実施した日付と、追跡対象の資産数
• 脆弱性の積極的なテストを実施したシステムの割合、および積極的なテストで使用した脆弱性スキャンと侵入テストの種類
• スキャンで検出された脆弱性の数
• 緩和策によって修正された脆弱性の数（次の分類別）
• • 脆弱性のリスク
  • 全体的な優先度
  • 解決までの時間（概要および詳細）
• 適切な導入を検証するため、各緩和策について実施した脆弱性スキャンまたは侵入テスト（テストがまだ進行中の場合は保留中と記載）
• 緩和されていない残存脆弱性の数
• 資産のリスクおよび価値のカテゴリ別に見た、脆弱性の検出から緩和までの平均経過時間
• 例外レポートに追加された脆弱性の例外数
• 脆弱性追跡一覧に含まれる脆弱性と緩和策の総数

［IT部門は、組織が脆弱性管理手順に適切に従っていること、および緩和策が適時に実施されていることを確認できるよう、レポートを発行する必要があります。定期レポートによって、コンプライアンスのための特別レポートが不要になる場合があります。

レポートのデータは、脆弱性管理プロセスの改善にも使用する必要があります。例えば、脆弱性緩和策によってヘルプチケットが発生した件数を使用して、導入前に追加のテストが必要かどうかを判断できます。］

4. 監査の対策と管理

[eSecurity Planet]の役員および監査担当者は、必要に応じて、文書化された手順と脆弱性管理業務の証拠を要求できます。文書化された手順と証拠の例には、次のものがあります。

• 承認済みメンテナンス時間申請
• 承認済み例外一覧
• 脆弱性管理の追跡一覧またはシステムの全体または一部のエクスポート
• 脆弱性の発見または緩和策の検証を目的に実施した脆弱性スキャンと侵入テストの全体または一部のコピー
• 脆弱性管理レポート

［このセクションでは、脆弱性管理プロセスについて、役員や監査担当者が予定外のレポートを必要とする場合があることを示しています。脆弱性管理レポートを検証するため、一部の監査担当者は、システムまたはソフトウェアの更新が正常に行われたことを確認できるシステムログも要求する場合があります。］

5. 適用

故意にポリシーに違反したことが判明した従業員は、解雇を含む懲戒処分の対象となる場合があります。IT部門のスタッフのうち、本ポリシーの実行責任を負う者の業務遂行能力は、本ポリシーの要件を満たす能力を一部または全面的に基準として評価されます。

IT部門がこの脆弱性管理ポリシーの要件を継続的に満たせない場合は、過失とみなされ、懲戒処分につながる可能性があります。虚偽のレポートや実行における重大な過失は、即時解雇または懲戒処分の理由となる場合があります。

［ポリシーを有効にするには、違反に対する罰則が必要です。この文書では、リソース不足によって更新基準を満たせない場合、過重労働や業務過多に陥ったIT部門の責任を組織は問わないことを想定しています。過度に無理な期待を設定する組織では、IT部門の離職率が高くなり、経験豊富または有能なスタッフの維持が困難になる可能性があります。］

6. 配布

本ポリシーは、[eSecurity Planet]のすべての役員、およびパッチ管理ポリシーのサポートと管理を担当するIT部門のスタッフに配布します。

［パッチ管理に携わる必要がある人（IT部門のスタッフ）や、ポリシーの影響を受ける人（少なくとも役員、および場合によってはその他の関係する従業員）には、本ポリシーを配布する必要があります。実行責任を負う従業員には、受領を正式に確認してもらう必要がある場合があります。］

7. ポリシーのバージョン

バージョン1.0
承認日：2023年5月12日
説明：初回ポリシー案

［このセクションは、以前のバージョンと承認を一覧にしたポリシーバージョン履歴にすることもできます。］

8. 署名

承認者：____________________________________________
［パッチ管理責任者の署名］

承認者：____________________________________________
［CEOまたはその他の該当する役員］

［パッチ管理責任者の署名は、ポリシーの要件を認識し、その要件を満たすことを事実上誓約するものです。CEOまたはその他の役員の署名は、ポリシーが組織のニーズを満たしていることを認識するものです。署名する役員は、その署名によって他部門にポリシーの遵守を促せるだけの上位職である必要があります。］

付録

I. ITリソース資産一覧

［資産管理ポリシーに従い、］組織の資産一覧には、組織のすべてのシステム、ソフトウェア、ファームウェア、デバイスを含める必要があります。資産一覧には、BYOD、アクセス権のあるリース機器、請負業者の機器など、組織の管理外にあるもののネットワークに接続されているデバイスを含めることもできます。

資産一覧に含めるリソースの例には、次のものがありますが、これらに限定されません。

• ネットワーク機器
• • ファイアウォール（および、更新が必要なインストール済みソフトウェア、ファームウェア、セキュリティ機能）
  • ネットワークスイッチ（およびインストール済みソフトウェア、ファームウェア）
  • ルーター（およびインストール済みソフトウェア、ファームウェア）
• サーバー（Webサイト、アプリケーションホスト、仮想化プラットフォームなど）およびインストール済みオペレーティングシステム
• インストール済みオペレーティングシステム、インストール済みソフトウェア、ファームウェア
• • ワークステーション
  • タブレット
  • ノートパソコン
  • 携帯端末
• モノのインターネット（IoT）およびインストール済みソフトウェアとファームウェア
• • ボイスオーバーIP（VoIP）
  • セキュリティカメラ
  • Wi-Fi接続テレビ
  • Wi-Fiプリンター
  • ネットワークプリンター
  • ストレージエリアネットワーク（SAN）
  • 音声で操作するデバイス（Amazon Alexaなど）
  • ［心拍モニターなどの医療機器］
  • 太陽光パネルシステム
  • ドアセキュリティバッジリーダー
• 運用技術（OT）、接続インフラストラクチャ、およびインストール済みソフトウェアまたはファームウェア
• • 5G接続コンベヤーベルト
  • 接続されたHVAC機器

資産一覧には、次の項目を含める必要があります。

• 資産の種類（サーバー、PC、ソフトウェア、ルーターなど）
• デバイスの割り当て所有者（共有リソースの場合、関連部門の責任者を実質的な割り当て所有者とする）
• コアOS、ファームウェア、またはソフトウェアのバージョン
  ［注：特定のバージョンを追跡・維持することは有用ですが、手動追跡システムを使用する組織にとっては負担になる可能性があります。］
• 手動更新か自動更新か
• IT部門、ソフトウェアの自動更新、サードパーティー製ツール、またはサードパーティーのサービスプロバイダーのいずれによって更新されたか
• 最終更新日
• 更新成功（Y/N）
• 関連付けられたデバイス（例：Adobe Acrobatソフトウェアの場合、関連付けられたデバイスにインストール：PC4362）

［IT部門］が資産一覧の維持に責任を負う一方で、部門責任者は、導入した新しい資産（デバイス、インストール済みソフトウェアなど）についてIT部門に通知する必要があります。IT部門に通知せずに導入されたデバイスやソフトウェアは、不正デバイスとみなされ、ブロックおよび削除の対象となります。

［IT部門］は、資産一覧が最新の状態に保たれていることを確認し、不正なデバイスやソフトウェアを検出するため、IT環境を［継続的／毎月／毎日／四半期ごとに］スキャンします。

現在の資産一覧の保存場所：

［資産データベース、Excelスプレッドシート、資産管理ツールをここに記載します。
注：Excelスプレッドシートの使用は、偶発的または意図的な破損や変更に対して脆弱になる可能性があります。バージョン管理されたGoogleスプレッドシート、またはOneDriveやSharePointに保存されたExcelファイルのほうが適切な選択肢です。

組織は、資産管理ポリシーを策定し、維持する必要があります。ポリシーの策定および資産一覧の例は、このサンプル文書の範囲外です。BYODデバイスは資産一覧で追跡しないでください。BYODデバイスの保守にはネットワークアクセス制御の機能または、デバイスのセキュリティプロファイルが最低限許容可能な基準を満たしているかを確認するツールを適用して、これを徹底する必要があります。］