ラックは2026年10月20日、脆弱性対応の優先順位をリスクに基づいて決める考え方を解説しました。深刻度を示すCVSS基本値だけでなく、悪用の可能性や事業への影響も評価するよう提言しています。情シスには、点数順に対応するだけでなく、自社の資産と対応体制に合った判断ルールの整備が求められます。
点数に加え、悪用状況と公開範囲を確認
ラックが挙げた評価軸は、深刻度、悪用状況、システムの公開状況、資産の重要度の4つです。緊急対応の可能性がある脆弱性は、CVSS基本値の総点だけでなく、評価項目の内訳も確認するよう勧めています。
悪用状況の確認材料には、米国のCISAが実際の攻撃で悪用を確認した脆弱性をまとめる「KEV」があります。また、「EPSS」は今後30日以内に攻撃で悪用される可能性をスコアで示す指標です。攻撃コードや、脆弱性を実証するコードであるPoCについても、公開の有無だけでなく、信頼性や実際の利用状況を確認するとしています。
公開範囲も判断を左右します。インターネットからアクセスできる外部公開資産は、優先対応を検討する対象です。一方、社内限定やVPN経由のシステムも、利用者やアクセス経路を踏まえて判断する必要があります。外部公開ではないことだけで、対応を後回しにする考え方ではありません。
対応期限と停止基準は自社で決める
資産の重要度は、情報を守る機密性、正しい状態を保つ完全性、必要なときに使える可用性の観点で整理します。ラックは、データの重要度や、業務が止まった場合の事業影響などを評価項目に挙げています。公開状況と重要度は、平時から資産管理台帳などに記録し、定期的に棚卸しするよう提言しました。
参考となる判断の枠組みとして、CISAの連邦政府機関向け指令「BOD 26-04」と「SSVC」も紹介しています。SSVCには、製品開発者やシステム運用者など、立場別の判断モデルがあります。ただし、既存の枠組みをそのまま使わず、自組織の構成や対応体制に合わせることが前提です。
ラックは、システムの重要度と脆弱性の危険度を組み合わせ、対応レベルを決める流れも例示しました。示された対応レベルや期限は参考例であり、全社共通の必須期限ではありません。実際の基準は組織ごとに定めます。
緊急の更新が難しい場合は、ベンダーの緩和策や、導入済みのWAF・IPSといった攻撃を防ぐ仕組みによる暫定策を提案しています。対策できず重大な影響が見込まれる場合に備え、システムを停止する判断基準も必要としています。
影響する会社・しない会社
- 影響する: 外部公開システムを運用する会社です。脆弱性の点数に加え、悪用状況と公開範囲を照らし合わせる必要があります。
- 影響する: 社内限定やVPN経由のシステムを持つ会社です。利用者、アクセス経路、扱うデータ、停止時の影響が判断材料になります。
- 影響しない: 特定製品の更新や提供条件の変更を知らせる発表ではありません。対象外となる製品、版、企業規模、業種は発表には書かれていません。
情シスが今日やること
以下は、提言を社内の作業に落とし込むための手順です。作業期限はラックが指定したものではなく、自社で決めるための進め方です。
- 今日、資産管理台帳を開き、公開範囲と重要度の記録欄を確認します。外部公開、社内限定、VPN経由の別に加え、扱うデータと停止時の事業影響が分かるかを点検し、不明な項目はシステム担当者に確認を依頼します。
- 次の対応順位を決める前に、未対応の脆弱性一覧へ悪用状況を追記します。KEV、EPSS、攻撃コードやPoCの情報を確認し、CVSS基本値だけで並べた一覧と分けて判断材料を残します。
- 次の更新計画を確定する前に、システム担当者と業務責任者へ優先順位案を共有します。公開状況と事業影響を踏まえ、対応レベル、担当者、期限を社内ルールとして決めます。
- 更新を延期する判断の前に、ベンダーの緩和策と導入済みのWAF・IPSで可能な暫定策を確認します。重大な影響を避けられない場合は誰が停止を判断するか、経営側と業務責任者に確認し、判断基準を記録します。
