まず、自社のシステムが対象かを確認する
注意喚起に製品名が載っていることは、確認の出発点です。実際の導入バージョン、影響を受ける構成要素、ベンダーが示す前提条件によって、対象かどうかが決まります。Web サイト上のバージョン表示が古い場合も、製品台帳から稼働中のサービスが漏れている場合もあります。運用担当やサービス提供者と、最新の台帳を照合してください。
本番、テスト、拠点、顧客環境ごとに、対象のインスタンスを分けて記録します。IT サービス事業者の場合、複数の顧客が同じ製品を使っているという情報だけでは不十分です。バージョンが不明なら、影響の有無も未確認のままです。これは具体的な確認課題であり、安全という証拠ではありません。
三つの問いで緊急度を整理する
下の判断図は、当社の編集上の分析です。技術的な事実を企業の状況に結び付けます。何が対象か、誰が到達できるか、悪用の証拠はあるか。さらに、そのシステムに依存するデータ、権限、業務を確認します。
インターネットからアクセスできるシステムは、特に注意が必要です。内部システムも評価対象です。認証済みの利用者や侵害された端末が、別のアクセス経路になる場合があります。防御策をリスク低減の根拠にできるのは、該当する攻撃経路を実際に遮断している場合です。
影響の有無
製品、バージョン、前提条件を照合。
到達可能性
アクセス経路と有効な防御策を確認。
悪用の証拠
ベンダー情報、KEV、自社の証拠を評価。
対応を決める
業務への影響、担当者、期限を結び付ける。
再確認
稼働バージョンと修正の効果を確認。
編集上の判断図です。三つの確認項目を業務の状況と合わせて評価し、リスク点数を自動算出するものではありません。
CVSS、EPSS、KEV は異なる問いに答える
これらの値を足し合わせ、見かけ上精密な総合点を作らないでください。情報源と確認日を残し、判断とその根拠となる情報を分けて記録します。 [1] [2] [3] [4]
表は左右にスクロールできます。
| 判断材料 | 何を示すか | それだけでは判断できないこと |
|---|---|---|
| CVSS 基本値（CVSS-B） | 脆弱性に固有の性質に基づく技術的な深刻度。自社の運用環境には依存しません。 | チームがどの脆弱性から修正すべきか。対象システムと業務の状況を合わせて判断する必要があります。 |
| EPSS | 公開済み CVE の悪用が、今後 30 日間に実際の攻撃で観測される確率の推定値。 | 自社が攻撃される確率や、既に攻撃が進行していることの証明。 |
| CISA KEV | 悪用が確認されている脆弱性のカタログ。掲載は、対象システムを確認する重要な判断材料です。 | 未掲載であることは、安全や攻撃がないことの証明にはなりません。 |
順位だけでなく、具体的な対応を決める
実際に影響を受け、利用可能なアクセス経路があり、信頼できる悪用情報もある場合は、関係する責任者に直接判断を求めます。ベンダーの修正プログラムや、機能の停止、アクセス制限などの推奨される暫定策を検討してください。対策は実際の構成に適合する必要があります。
単純化した例では、同じ製品でも、影響を受けている公開の従業員向けアクセスポータルは、隔離されたテスト環境より優先され得ます。判断の理由は、到達可能なアカウントや業務への影響であり、製品名だけではありません。別のシステムでは、データの喪失、生産停止、広範な権限が順序を左右します。
必要な機能テスト、メンテナンス時間帯、ロールバック手順も計画します。更新を延期する場合は、担当者と再判断する日付を明確にします。
再確認してから対応を完了する
パッチ管理には、インストールの確認も含まれます。結果を追跡できるよう、変更したインスタンス、現在稼働しているバージョン、修正を確認した方法を記録します。機能テストを行い、システム台帳も更新してください。
暫定策には、その限界と恒久対策に置き換える時期も記載します。以前の侵害を疑う証拠がある場合は、インシデント対応で調べる必要があります。パッチを適用しただけでは、既に侵害されたかどうかは分かりません。 [5]