脆弱性の優先度はCVSSだけで決める？KEV・公開範囲・業務影響の比較

脆弱性対応では、技術的な深刻度を示すCVSSと、自社が優先して対処すべき順序を分けます。公開範囲、到達経路、重要な情報、既存の制御、実際の悪用の情報によって業務のリスクは変わります。点数が最大のものから機械的に進めるだけでは、現在狙われている重要な入口を後回しにする可能性があります。

CISAのKEVは実際に悪用された脆弱性に関する情報を確認する材料です。掲載されていないことを悪用されない保証とすることも、掲載だけで自社の全対象が同じリスクとすることも不適切です。CISAの米国連邦機関向けの要求を、日本の全企業の法的期限として扱わず、自組織の対象と対応条件を確認します。

技術的な点数、悪用の証拠、自社での到達性、業務影響は違う視点です。同じ製品名でも版や構成が対象かを確認します。

資産台帳と脆弱性の一覧を結び付け、未確認の版や設定を確定対象と混ぜないようにします。優先度を決めた理由と実施後の確認を残します。

期限の根拠と承認者を記録します。外部の要求、社内の目標、実際の完了日時を区別してください。

対象製品の版が不明なら、影響を受けないと断定せず確認を割り当てます。台帳の古い版を現在の版とみなすと対象外の判断を誤ります。外部の情報が新しくても、自社の構成を照合できなければ対応の完了は確認できません。

すぐ対処した項目だけの件数を成果にすると、重要で難しい対象が残る場合があります。対応の時間、重要業務の未解決、例外と期限を合わせて報告します。優先度は固定せず、新しい悪用情報や構成変更で見直します。

サイバーセキュリティの学習ガイドで、このテーマをクラウド・脆弱性と供給網の中に位置付けてください。関連する前提はセキュリティリスク台帳とは、パッチをすぐ適用できない時の判断で確認できます。

資格対策との接点は情報・サイバーセキュリティ管理士の概要へ。用語を理解した後は登録不要の無料お試し20問で、別の状況でも判断できるか確かめてください。記事のテーマを全て公式の出題項目とする説明ではありません。