脆弱性管理の進め方
脆弱性管理とは、自組織で利用するソフトウェアや機器に含まれる脆弱性を、資産の把握、検出、評価、対応、確認まで継続的に行う管理の仕組みである。すべての脆弱性を同時に修正することは困難なため、深刻度や悪用の状況、資産の重要性に基づいて対応の優先度を決めることが不可欠である。本単元では、資産管理、評価、優先度の判断、対応主体、開発段階での反映を順に整理する。
資産の把握と構成の管理
脆弱性管理は、どの資産が存在するかを把握することから始まる。IT資産の管理台帳が整備されていなければ、脆弱性の情報を受け取っても対象機器を特定できず、修正の対象を見落とす原因となる。未把握の資産を見つけるための調査方法を具体的に定めておくことが重要である。
資産を識別するには、機器を特定できる属性を組み合わせて台帳に持たせる。名称やIPアドレスに加えて、ポート番号や担当者の識別情報を管理しておくと、脆弱性情報と資産を照合しやすくなる。
設定を変更した機器を把握することも欠かせない。設定変更があったサーバを特定し、変更内容を記録しておけば、変更によって生じた新たな脆弱性を見逃さずに済む。
脆弱性の評価と優先度の判断
評価には、CVSSの基本値、現状値、環境値を用いる。現状値は、悪用の状況などを手間をかけて調べる必要がある一方で、EPSS値は手間をかけずに得られるという違いがある。評価に要する手間と得られる情報の性質を理解して、評価方法を選ぶことが求められる。
EPSS(Exploit Prediction Scoring System)は、今後悪用される可能性を予測するスコアである。一方、KEVカタログ(Known Exploited Vulnerabilities)は、既に悪用が確認された脆弱性を一覧にしたものである。予測と実績は性質が異なるため、どちらを優先度の根拠とするかを明確にする必要がある。
CVSSは版の改訂が続いているため、評価に用いる版を明確にして運用することが求められる。評価の基準が変われば同じ脆弱性でも数値が変わるため、古い版で算出した結果を現在の判断に使わないよう注意する。
攻撃条件の複雑さ(AC)も、優先度の判断に影響する。Webアプリケーションの診断で検出された脆弱性では、ACの評価根拠を具体的に示すことが求められる。攻撃に特別な条件を要しない脆弱性ほど、攻撃されやすく対応の優先度が高くなる。
この節の続き
- 実際の場面での診断と対応
- 対応を担う組織と自動化の基準
- 試験で問われやすい区別
ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。
アプリでこの節を読む