脆弱性はどれから修正する？ 深刻度・悪用実績・自社への影響
脆弱性の一覧を点数の高い順に並べると、対応計画は作りやすい。しかし、上から修正したという説明だけで、重要な危険から減らしたと言えるだろうか。技術的には深刻でも利用条件が違う問題と、既に悪用され、自社の公開システムにも当てはまる問題では、待たせる意味が違う。
深刻度を入口にしつつ、悪用の証拠、自社の影響範囲、到達経路、業務上の影響を確かめて対応順を決める。 ただし、情報が見つからないことを安全の証拠にしない。監査で見るべきなのは、並べ替えた表だけでなく、その順番を支える事実と、保留を見直す条件である。
この記事の目次
CVSSの基本値は、自社が被害に遭う確率ではない
FIRSTのCVSS v4.0利用ガイドは、基本値が脆弱性の深刻度を測るもので、単独でリスクの評価に使うべきではないと明示する。脅威や利用環境の情報を加える仕組みもあるため、「CVSSには環境を扱う方法がない」という理解も正しくない。FIRSTの利用ガイド
基本値が高いことは重く受け止める必要がある。それでも、その値だけから自社のどの資産に影響するか、今日攻撃されているか、停止すると何が起きるかは分からない。評価表には値の出所や種類を残し、違う条件で算定した点数を同じ意味として扱わない方がよい。
ここでの目的は、高得点の問題を放置する口実を作ることではない。限られた作業時間で、先に下げるべき危険を説明するために、技術的な特徴へ自社の条件を加えることである。
悪用の実績と予測も、別の情報である
米国CISAのKEVカタログは、現実に悪用されたことが確認された脆弱性を扱い、優先順位付けの入力として利用するよう案内している。掲載があれば、技術的な可能性だけでなく、悪用の証拠がある点を判断に反映できる。CISAのカタログ
一方、FIRSTのEPSSは、公開された脆弱性について、今後30日間に悪用が観測される可能性を推定する。これは自社のサーバーが侵害される確率でも、被害金額でもない。FIRSTも、完全なリスク指標や深刻度の値とは区別している。EPSSの使い方
既に悪用が確認されている情報と、将来の悪用を予測する情報を取り違えない。予測値が低いから確認済みの悪用を軽く扱う、カタログにないから悪用がないと断定する、といった読み方は避ける。外部で得られる情報には観測範囲と更新時点がある。
また、複数の値を掛け合わせれば自社の期待損失になるわけではない。尺度の意味が違うまま計算しても、見た目の精密さが増すだけである。最初は、何が事実で何が予測かを別の欄に残す方が、判断を点検しやすい。
資産への該当を確かめてから、対応を選ぶ
以下は公的・標準化団体の資料を踏まえた編集上の提案である。最初に製品名だけでなく、利用している版や設定が対象に当てはまるかを確認する。対象の把握が曖昧なまま、点数だけで作業を依頼すると、必要な場所を見落とし、不必要な作業も増える。
次に、その問題へ至る経路を確認する。外部公開かどうかだけでは十分ではない。内部の利用者や他システムから到達する可能性もあり、「社内だから安全」と一括で保留にはできない。到達しないと判断するなら、その根拠となる構成や制御が実際に維持されているかを確かめる。
最後に、影響を受ける仕事を特定する。利用者へのサービス、重要な情報、復旧のために必要な基盤のどこへ影響するかを、業務担当者と確認する。この情報があれば、修正を急ぐべき理由と、変更時に守るべき条件を同時に議論できる。
CERT/CCのSSVCは、関係者ごとの状況に応じて脆弱性への対応を判断する枠組みである。共通の点数を全組織へ当てはめるより、役割や影響を踏まえた意思決定を重視する。SSVCの公式解説
点数の大小と対応順が逆転する例
架空の会社で、二つの問題が報告されたとする。一方は高い基本値だが、対象とされた機能を使っておらず、その条件を構成記録と実環境で確認できている。もう一方は点数が低めでも、公開中の対象製品に該当し、悪用が確認されている。この場合、後者への対応を先に進める理由がある。
条件を変え、高得点の方も影響する設定になっており、重要な情報へ到達できると判明したらどうか。未使用という前提が崩れたので、優先順位を再評価する。先に付けた順位を守ることより、判断の前提を更新することが重要になる。
さらに、利用の有無を確認できる担当者も資料もない場合を考える。それは対象外と確認された状態ではない。優先的に事実確認を進め、確認までの露出を抑える措置が必要かを判断する。情報不足をゼロ点に換算すると、分からない資産ほど後回しになってしまう。
この例に一律の修正期限は置いていない。期限は組織の条件と適用される要求で決めるものであり、研究が示していない日数を安全の境界として作れないためだ。
直せない期間に、何をするかを残す
対応を急ぎたくても、修正の提供を待つ場合や、変更で重要な業務が止まる場合がある。そのときは「次の更新まで待つ」という記載だけで終えない。利用を止める、影響する機能を制限する、経路を狭めるなど、利用環境で実施可能な対処を専門担当者が検討する。
仮の対処を置いた場合は、その成立条件と残る危険を記録する。監視を強めたことは修正を完了したことと同じではない。検知できる範囲が限定的なら、その限界を残したうえで、恒久対応へ進む日程や判断者を決める。
NISTの2022年のパッチ管理計画ガイドは、更新を技術の予防保全として位置付け、特定・優先付け・導入・確認までの組織的な計画を扱っている。これは対策の効果率を示す実験ではなく、運用を設計するための指針である。NIST SP 800-40 Rev.4
保留を固定しないための記録
保留には、確認した事実、確認した日、判断者、次に見直す条件を残す。例えば、対象機能を停止しているため露出を抑えたなら、その機能を再開する変更が再評価のきっかけになる。悪用情報が新たに出たときも、前回の判断をそのまま使わない。情報が増えるたびに全件を最初から議論するのではなく、どの前提が変わったかを特定するための記録である。
優先順位を変える判断と、修正対象から永久に除外する判断も分けたい。低い優先度でも通常の更新計画には含め、対象外とする場合は版や設定などの根拠を残す。緊急対応だけへ人員を使い続けて通常の更新が止まれば、管理すべき対象が後から積み上がる。
一方、全ての資産に同じ精密な分析を課すと、分析自体が修正を遅らせかねない。共通の構成はまとめて扱い、例外や影響の大きい資産へ確認を厚くする。細かい点数を増やすことより、必要な対処へ進むための事実がそろうことを優先する。
保留の根拠には、稼働版・利用機能・到達経路を残します。CVSS、KEV、EPSS、SSVCは答える問いが違うため、共通の危険点数として足し合わせられません。製品の順位だけでなく自社の業務へ届く経路を説明し、構成変更や新たな通知でその前提が変わったら確認し直します。
監査では、期限内の件数だけを追わない
修正件数が増えても、悪用され得る重要な資産が残っていれば、優先順位の目的を果たしていない可能性がある。対応済みの件数に加えて、影響する資産の特定漏れ、保留理由の期限切れ、暫定措置の確認状況を点検する。
更新作業の実施と、対象への反映も別である。作業依頼を閉じた記録だけでなく、該当する版や設定が変わったことを確かめる。停止させた機能を後から戻す際には、保留の前提が変わらないか再確認する。
深刻度は捨てず、単独では順番を決めない。悪用の証拠と自社の到達性・影響を重ね、直せない場合も対処と見直しを具体化する。その説明が残って初めて、監査は「高い点数から処理した」以上の判断を確かめられる。