脆弱性管理ポリシーは、脆弱性管理のプロセス、最低限の基準、報告要件に関する基本ルールを定める。
効果的な脆弱性管理ポリシーは、ITハードウェア、ソフトウェア、システム内で発見された脆弱性を検出・管理する循環的なプロセスに役立つ。文書化されたポリシーによって、ITチームは追跡可能で再現性のあるプロセスを構築でき、経営幹部の期待に応え、コンプライアンス要件にも準拠できる。
本記事では、基本的な概要とダウンロード可能なテンプレートを通じて、あらゆる規模の組織がポリシー策定を始めるための情報を提供する。
- 無料の脆弱性管理ポリシーテンプレート
- 脆弱性管理ポリシーを4つのステップで作成する方法
- 脆弱性管理ポリシーの一般的な項目
- 脆弱性管理ポリシーのベストプラクティス5選
- 効果的な脆弱性管理ポリシーの主なメリット6つ
- まとめ：メリットを得るため、今すぐ脆弱性管理ポリシーを導入しよう
無料の脆弱性管理ポリシーテンプレート
eSecurity Planetは、事例および出発点として、組織がダウンロードし、ニーズに合わせて変更して利用できる無料の脆弱性管理ポリシーテンプレートを作成した。説明やテンプレートの使用方法に関する注記は[角括弧内]に記載しており、最終稿ではこれらのセクションを削除する必要がある。
サンプルのパッチ適用ポリシーには多数の項目が含まれているが、すべての組織にすべての項目が必要とは限らず、さらに詳しい説明が必要な場合もある。詳細については、以下の脆弱性管理ポリシーの一般的な項目を参照されたい。
脆弱性管理ポリシーを4つのステップで作成する方法
すべてのセキュリティポリシーの策定には、共通する4つの主要ステップがあり、詳細はITセキュリティポリシー：重要性、ベストプラクティス、主なメリットで解説している。実用的なパッチ管理ポリシーについては、これらのステップを次のようにまとめられる。
- 脆弱性管理ポリシーを策定する： 責任者、対象となる人または物、基本的なプロセス、検証方法、報告書を決定する。
- 脆弱性管理ポリシーを検証する： ステップ1で作成した基本ポリシーが、組織の完全なニーズとコンプライアンス要件を満たしていることを正式に確認する。
- 脆弱性管理ポリシーを承認する： 正式な文面を作成し、関係するステークホルダーと経営幹部に回覧して承認を得る。
- 脆弱性管理ポリシーを見直し、変更する： ポリシーが常に最新で、組織の変化するニーズを満たし続けていることを確認するため、定期的に見直す。
どこから始めればよいかわからない？現在の運用を書き出そう。 多くのITチームには、たとえ文書化や監視が行われていなくても、更新プログラムやパッチを取得して適用するための、少なくとも非公式なプロセスが存在する。
更新とパッチ適用は脆弱性管理の一部にすぎないが、より包括的なポリシーの出発点にはなる。組織がすでにネットワーク機器の設定やサーバーファイアウォールの開放ポートを再確認するプロセスを備えている場合、それらを追加・拡張して、より多くのITシステムを対象とする包括的なポリシーにすることもできる。
すべてのITセキュリティポリシー策定の基本は同じだが、脆弱性管理は規制対象となることが多い要件であり、組織はコンプライアンス要件の検証に際して特に注意を払う必要がある。さらに、組織はコンプライアンスフレームワーク（NIST、PCI DSSなど）や業界標準への準拠を義務付けられたり、自ら選択したりする場合がある。ポリシー策定チームは、これらの外部規制を確認し、コンプライアンス要件を満たさないルールを改訂する必要がある。
コンプライアンス基準には、範囲が広く曖昧なものもあれば、詳細なものや具体的な要件を定めたものもある。例えば、CISクリティカルセキュリティコントロールでは、要件は広範だ。
- 7.1 脆弱性管理プロセスを確立・維持する： エンタープライズ資産向けの、文書化された脆弱性管理プロセスを作成・維持する。このセーフガードに影響を与える重大なエンタープライズ変更が発生した場合、または毎年、文書を見直して更新する。
- 7.2 修復プロセスを確立・維持する： 毎月、またはそれ以上の頻度で見直す修復プロセスに、リスクベースの修復戦略を文書化して確立・維持する。
CISの要件は、脆弱性管理プロセスの存在を求めているが、そのプロセスやリスクベースの修復戦略に含めるべき内容や要件までは定めていない。
クレジットカード業界のPCI DSS要件は、より具体的である。例えば、あるレストランチェーンが、コンピューターを対象とするパッチ適用プロセスとポリシーをすでに備えているとする。しかしPCI DSSでは、ネットワークの脆弱性スキャン、販売時点情報管理（POS）端末の評価、定期的なペネトレーションテストが求められる場合がある。
実務上の制約もある。上記のレストランチェーンの例では、現在のパッチ管理ポリシーを管理するパッチ管理ツールが、ネットワークの脆弱性やPOS端末の更新をスキャンできない可能性がある。現在のパッチ適用ツールは、脆弱性管理ツール、脆弱性管理サービス、またはPCI DSSの規制要件を満たせるペネトレーションテストサービスによって、アップグレードまたは補完する必要がある。
脆弱性管理ポリシーの一般的な項目
最も効果的な脆弱性管理ポリシーには、必須項目、推奨項目、追加項目（あると便利な項目）がある。
必須項目
以下の主要項目は、脆弱性管理に関するすべてのポリシーに含めるべきだ。
- 対象範囲： ポリシーの対象となるIT資産とシステム。
- 脆弱性管理の権限： 脆弱性管理ポリシーとその実行を統括し、責任を負う人物。
- 脆弱性の特定： 脆弱性を特定して緩和するために必要な脆弱性スキャン、ペネトレーションテスト、その他の手法の種類を決定する。
- 脆弱性の評価： 発見した脆弱性の深刻度を検証、評価、ランク付けする方法。
- 脆弱性の優先順位付け： 露出した資産のリスクを踏まえて脆弱性に優先順位を付ける方法。
- 脆弱性緩和ガイドライン： 緩和策の設計・テストから、緩和策のスケジュール設定、緩和が成功したことの検証まで、脆弱性緩和プロセスを定義する。
- 緩和策の追跡と例外： 新たに発見した脆弱性、無視した脆弱性、緩和した脆弱性を追跡するための要件。
- 脆弱性管理の報告： 報告書によって脆弱性管理の成功とコンプライアンスを測定する方法、および何をどのように報告するか。
推奨項目
以下の項目は、組織を保護するための追加ルールと、IT部門の準備に役立つ情報によって、脆弱性管理ポリシーをより充実させる。
- 資産一覧： パッチ適用と更新の対象となるシステムやソフトウェアの範囲を定義するのに役立つ、リソースの一覧または資産一覧へのリンク。
- 監査管理と統制： 脆弱性管理の成功を追跡し、脆弱性が正常に緩和されたことを検証するために、内部・外部監査人が確認できる報告書、ログ、情報の概要。
- 執行： 脆弱性管理プロセスを実行しなかった場合に、IT部門が受ける可能性のある罰則。
- 配布： 脆弱性管理ポリシーを受け取らなければならない、または受け取るべき人物。
- ポリシーのバージョン： 脆弱性管理ポリシーのバージョンと承認を追跡する。
セキュリティ向けIT資産管理ツールのトップ製品ITAMソフトウェアの最適な製品と主な機能を確認するには、を参照されたい。
追加項目／あると便利な項目： これらの項目は脆弱性管理ポリシーの中核要素を変えるものではないが、ポリシーをより使いやすく、包括的にすることができる。
- 概要： ポリシーに対する期待と目標を定める。
- 定義： 技術用語や略語の定義は、技術に詳しくない読者がポリシーを理解するのに役立つ。また、明確化のために一般的な用語を定義してもよい。
- コンプライアンス付録： 組織が準拠しなければならない関連するコンプライアンスフレームワークのコピーまたはリンク。
脆弱性管理ポリシーのベストプラクティス5選
すべてのセキュリティポリシーの策定には、共通する5つのベストプラクティスがあり、詳細はITセキュリティポリシー：重要性、ベストプラクティス、主なメリットで解説している。実用的なパッチ管理ポリシーについては、これらを次のようにまとめられる。
- 方法ではなく、実施内容に焦点を当てる： 目標と目的に焦点を当てることで、ポリシーは基準を定めつつ、脆弱性管理チームが目標達成に最適なソリューションを柔軟に決定できるようにする。
- 実用的なポリシーにする： 脆弱性管理チームがポリシーを理解し、実行できなければならない。
- 適切な長さにする： 短すぎると検証に必要な要件が不足する可能性があり、長すぎると規定が細かくなりすぎたり、理解しにくくなったりする。
- ポリシーを明確に分ける： 重複するポリシーは、矛盾を生じさせたり、最新の状態に保つことを難しくしたりする。
- 検証可能なポリシーにする： 効果的なポリシーには、そのポリシーが導入され、実効性を発揮していることを証明する報告書が必要である。
eSecurity Planetのテンプレートは、一部の組織には必要以上に包括的な内容となっている可能性があるため、各組織はテンプレートを確認し、自らのニーズに合わせて内容を追加・削除すべきである。
標準的なベストプラクティスに加え、脆弱性管理では追加の考慮事項も重要になる。例えば、実用的なポリシーを維持するため、ポリシー自体よりも頻繁に変更する必要がある詳細情報を示す目的で、補足資料や追加の報告書を利用できる。例えば、サンプルテンプレートでは、ITチームは、潜在的な脆弱性の検出に使用する脆弱性スキャナーの種類の一覧を維持することが求められる。
すべての組織は、既存の運用と能力に基づいてポリシーの策定を始めるべきだが、これによって不完全なプロセスを文書化したポリシーに残してしまう落とし穴に陥る可能性がある。組織は自らの環境を慎重に検討し、ポリシーが本当のニーズを反映していることを確認すべきである。
例えば、ある病院のITチームが商用ツールを使ってIT環境の脆弱性スキャンを実施しているとする。しかし、そのツールがスキャンできるのはPC、ネットワーク機器、サーバーだけで、脆弱性がスキャンされないヘルステック機器が広範囲に残されている可能性がある。この場合、ポリシー要件は現在スキャンしている機器の範囲ではなく、脆弱性管理プロセスに含める必要があるすべての機器を反映すべきである。
効果的な脆弱性管理ポリシーの主なメリット6つ
あらゆる規模の組織は、文書化という作業が圧倒的で退屈、かつ制約が多いように思えるため、その手間を避ける傾向がある。しかし、効果的なセキュリティポリシーには、6つの主なメリットがある。
- IT環境の強化：セキュリティポリシーを作成して見直すことで、ITチームとセキュリティチームはセキュリティ対策を評価し、改善できる可能性がある。
- 雇用上の防御：侵害が発生した場合でも、ITチームとセキュリティチームは、経営幹部が承認した書面のポリシーを遵守していたことを示せれば、身を守ることができる。
- 経営幹部と取締役会メンバーの安心：効果的なポリシーで求められる平易な言葉による報告書は、組織のセキュリティ態勢を経営幹部や取締役会に明確に示すことができる。
- 訴訟からの保護：侵害は起こり得るが、合理的なセキュリティ対策を含むポリシーを遵守していたことを示す報告書やその他の証拠を組織が提示できれば、訴訟や規制当局への対応が問題になる可能性は低くなる。
- コンプライアンスの簡易化：ポリシーにコンプライアンス要件を盛り込めば、ポリシーで求められる報告書が監査人向けに自動的に用意される。
- 運用効率とレジリエンスの向上：効果的なポリシーは、より強固なセキュリティ態勢を確保し、設定上の問題をなくし、攻撃者が業務を妨害する機会を減らす。
まとめ：メリットを得るため、今すぐ脆弱性管理ポリシーを導入しよう
完璧なポリシーは存在しないが、IT環境の強化やコンプライアンスの簡素化といったメリットを得始められるよう、組織はできるだけ早く脆弱性管理ポリシーの策定に着手すべきである。どのようなポリシーの導入も反復的なプロセスとなるため、まずは適切なバージョン1.0を整備し、現実の状況に合わせて改訂する準備をしておくとよい。
脆弱性管理と関連トピックの詳細情報：