脆弱性管理プログラムのベストプラクティス–パート1

avatar

 2016.04.12  Japanブログ編集部

企業の脆弱性管理プログラムは、基本的なゴールが明確にされ、それに基づいて構築されているときに、その存在能力と価値をフルに発揮します。 それらは、ステークホルダーのすべてが必要とする情報を扱うこと、そこから生じるアウトプットが企業の目的と一致すること、そして組織全体のリスクを取り除くことです。
脆弱性管理のテクノロジはリスクを検出することができますが、そのプログラムを確実に成功させるためには土台となる人とプロセスが必要不可欠です。
一般的に脆弱性管理プログラムでは以下の4つのステージがあります:

  • 資産の緊急度、資産の所有者と脆弱性検査頻度を決定する、また修正のスケジュールを決定する作業
  • ネットワーク上の資産の検出と一覧化
  • 検出した資産上の脆弱性の検査
  • 発見した脆弱性の報告と修正

最初のステージは測定可能で繰り返し可能なプロセスの構築に注力しています。 2から4のステージは、継続した改善に重点を置きステージ1でまとめたプロセスを実行することに注力します。
この記事は3つのパートからなるシリーズです。 脆弱性管理プログラムを成功裏に構築するため、各ステージを検証します。 [i]
このパート1の記事では、まず第1ステージを検証します。

ステージ1:脆弱性検査プロセスの決定

1. 1ステップは、組織の資産の重要度を特定すること

有効なリスクマネジメントプログラムを構築するために、まず組織が守る必要のある資産を決定しなければなりません。これは、コンピュータシステム、ストレージデバイス、ネットワーク、データ・タイプだけでなくネットワークで利用しているサードパーティシステムも含まれます。資産は組織における真のリスク、固有のリスクに基づいて分類しランクづけを明確に行うべきです。

資産固有のリスクレベルを決定する時には多くの面を考慮する必要があります。上位に分類される資産への物理的あるいは論理的な接続、ユーザアクセスやシステム可用性等です。

例えば、アカウント情報を保有するデータベースへの論理アクセスを伴うDMZ内の資産は、テスト環境の資産よりも重要度が高くなるでしょう。 また、本番で稼動している業務システムの資産はテスト環境の資産よりも重要度が高いはずです。ルーティングに対応するインターネットウェブサーバは、社内のファイルサーバよりも高い重要度になります。

しかし、資産の重要度が低いというだけで、その資産に対する対応を無視するべきではありません。その対応作業は常にリスク全体を考慮し行うべきでしょう。

2. 2ステップは、各システムのシステム所有者を特定すること

システム所有者は、資産に障害が起きた場合、最終的に資産とそれに関するリスクや障害に責任があります。 所有者を特定するステップは脆弱性管理プログラムを成功させるために重要です。これが組織内で説明責任と修正作業を推し進めるからです。誰もリスクの責任を取らなかったら、誰もリスクへの対応を進めることができません。

3. 3ステップは、検査頻度を設定することです。

米国インターネット・セキュリティ・センター(CIS: Center for Internet Security)はTop 20 Critical Security Controlsの中で、組織は『ネットワーク上の全システムに対し週に1回あるいはそれ以上の頻度で脆弱性自動検査ツールを起動』することを推奨しています。トリップワイヤは毎週脆弱性の定義アップデート (ASPL) を発表しています。

この頻度で診断すれば、資産所有者は修正作業の進行の追跡、新しいリスクの特定はもちろん、新しい脆弱性情報(インテリジェンス)を基に脆弱性の修正の優先順位を入れ替えることができます。

脆弱性が最初に明らかになった時は、既知のエクスプロイトが存在しないため、脆弱性スコアは低いかもしれません。 しばらくしていったん脆弱性が広まると、自動化されたエクスプロイトキットが利用されるようになり、その脆弱性のリスクは高まるでしょう。前は脆弱ではないと考えられていたシステムも、新しいソフトウェアのインストールやパッチのロールバックが理由で、1つの脆弱性や複数の脆弱性に晒されるかもしれません。

資産のリスク状況の変化には多くの要因が関係しているかもしれません。診断を頻繁に行うことで、資産の所有者は最新情報によって最新の状態を保つことができます。最低限度としては、脆弱性検査は月に1回以上は行うべきでしょう。

4. 第4ステップは、対応のタイムラインとしきい値を確立し書面化すること

自動的に弱点を攻撃できる脆弱性は、攻撃者に特権的なコントール権限を与えてしまうので早急に修正すべきです。弱点を攻撃することが難しく、今のところ理論上のセキュリティホールでしかない、特権コントールを得ようとする脆弱性も、30日以内には修正すべきです。これより低い脆弱性は90日以内に修正しましょう。

システム所有者が適切な期限内に脆弱性に対応することができなかった場合、例外的措置プロセスを利用することができます。

このプロセスの一部として、システム所有者は一定の期限までに脆弱性に対応するという受け入れ可能な実行計画と共に、そのリクスの理解とリスクの受容について書面化するべきでしょう。例外扱いとした脆弱性については、常に期限を持つべきです。

パート2はこちら
[i]クリス・バンタ (CISSP、ITIL) と リック・ウォルフォード(CISSP)の貢献に心から感謝します。

Title image courtesy of ShutterStock

 

元の記事はこちらからご覧いただけます。

ギャップにご用心サーバー脅威対応までの感覚

RECOMMEND関連記事


RECENT POST「脆弱性管理」の最新記事


この記事が気に入ったらいいねしよう!