パッチの順番は深刻度だけでは決まらない。悪用実績・資産の露出・代替策を分けて運用する

編集部の実務提案

深刻度スコアは「悪用されているか」を教えてくれない

CVSSのような深刻度スコアは、脆弱性そのものの性質、攻撃のしやすさや影響の大きさを評価する。しかしCISAの拘束的運用指令（BOD 22-01）の解説が指摘するように、CVSSの基本スコアは、その脆弱性が実際に攻撃に使われているかどうかを考慮しない。高スコアでも実験環境でしか再現されていないものもあれば、中スコアでも大規模な攻撃に使われているものもある。

数字の裏付けもある。同指令の解説によれば、公開され実際に悪用されたCVEは全体の4%未満にとどまる。つまり、深刻度順に上から潰す運用は、残り96%の「使われていない穴」にも同じ労力を配ってしまう。限られた保守時間の中で順序を誤ることは、そのまま露出期間の延長になる。

一方で、悪用されるものは速い。同じ解説では、悪用が確認されたCVEのうち42%が公開当日に、50%が2日以内に、75%が28日以内に悪用されているとする。攻撃者の初動は、こちらの月次パッチサイクルより速い。順序付けの基準が「悪用実績」であるべき理由は、この速度差にある。

深刻度スコアが無用なのではない。悪用実績のある脆弱性の中で優先度を付ける補助軸として、また悪用実績が未知の段階での初期評価として、スコアには役割がある。問題は、スコア単独を順序の決定者にしてしまうことである。本稿の設計では、悪用実績を第1キー、露出と深刻度を第2キーに置く。

運用の現場では、この転換は一覧の並び替えから始まる。スキャン結果にKEV掲載の有無を突き合わせ、先頭にKEV該当を持ってくる。それだけでも、対応の初動は大きく変わる。道具の買い替えは要らない。既存のスキャン結果と公開カタログの突合が第一歩である。

現場でよくある誤解に、「スキャナが緊急と出すものは全部危ない」という前提がある。スキャナの深刻度は網羅性のためのもので、順序付けのためのものではない。網羅と順序を分業させる、つまりスキャナは「見つける」、KEV突合と露出評価は「並べる」という役割分担を明文化するだけでも、会議の議論は前に進むようになる。

なお、深刻度の見直しはベンダー側でも続いている。スコアの改版や、悪用可能性の指標を併記する動きもある。いずれにせよ、自社の運用としては「外部の評価」と「実際の悪用事実」を分けて持ち、後者を順序の先頭に置くという設計は揺らがない。外部指標の進化は、補助軸の精度向上として取り込めばよい。

出典：[1][2]

編集部の実務提案

KEVカタログを、優先順位付けの入力として組み込む

KEVカタログは、CISAが「実際に悪用された証拠がある」と判断した脆弱性のリストである。解説によれば、掲載の条件は、CVE IDが割り当てられていること、実際に悪用されている信頼できる証拠があること、ベンダーの更新など明確な是正手段が存在することの3点である。つまり掲載された時点で、「悪用されており、直し方もある」ことが確認されている。

カタログはCSVやJSONでも提供され、自社の資産台帳やスキャン結果と機械的に突き合わせられる。運用としては、週次でカタログの差分を取得し、自社で使っている製品に該当する新規掲載を拾う仕組みを作る。人の目でカタログを眺める運用は続かない。差分と突合の自動化が前提である。

BOD 22-01は連邦機関向けの指令だが、その期限設計は民間の中小組織にも転用できる考え方を示している。カタログ掲載の脆弱性には是正期限が設定され、既定では2021年より前にCVEが割り当てられたものは6か月以内、それ以外は2週間以内の是正が求められる。自社向けには、この「悪用実績のあるものは週単位の期限」という感覚を取り入れる。

CISA自身も、KEVを脆弱性管理の優先順位付けフレームワークへの入力として使うよう組織に求めている。KEVだけが全てではなく、自社の資産構成や露出と組み合わせる材料である、という位置付けである。この「入力として」という表現が重要で、カタログの掲載順がそのまま自社の対応順になるわけではない。

突合の結果は、資産ごとに「KEV該当あり・なし」「該当するCVE」「掲載日」「自社側の期限」を持つ表にする。この表が、パッチ運用の台帳の中核になる。スキャンツールの画面の中にだけ存在する情報は、期限管理にも経営報告にも使えない。

突合の自動化では、カタログ側の更新形式に注意する。新規掲載だけでなく、期限の変更や掲載内容の修正も差分として現れる。自社に該当する変更があった週は、台帳側の期限も連動して見直す。カタログは静的な一覧ではなく、生きている入力として扱うのが正しい。

突合表は、ベンダー製品の棚卸しとも連動させる。使っている製品とバージョンが台帳に正確に載っていなければ、KEVの該当判定そのものが漏れる。製品棚卸しの精度が、悪用実績ベースの順序付けの入口の精度を決める。

出典：[1][2]

編集部の実務提案

自社資産の露出で、同じKEVでも順序が変わる

同じKEV該当の脆弱性でも、置かれている資産によって急ぎ具合は違う。インターネットに直接公開されたサーバーやVPN装置と、社内ネットワークの奥にある検証用端末では、攻撃者の到達可能性がまるで異なる。優先順位の第2キーは、この露出の度合いである。

露出の評価には、資産台帳の属性を使う。外部公開の有無、到達できる利用者の範囲、扱うデータの重要度、その資産が止まった場合の業務影響。台帳にこれらの属性がない組織では、KEV突合の前に台帳の整備が先行課題になる。順序付けの精度は、台帳の精度で決まる。

境界装置は特に優先する。VPN、リモートアクセス、メール、公開Webサーバー。これらは攻撃者の最初の到達点であり、悪用実績のある脆弱性の標的として繰り返し狙われる領域である。自社に境界装置のKEV該当があれば、他の予定を繰り上げてでも先に処理する、という原則を先に決めておく。

逆に、露出が低く業務影響も小さい資産については、通常の保守サイクルに載せる判断も正当である。全てのKEV該当を緊急扱いにすると、緊急という言葉が摩耗し、本当の緊急時に人が動かなくなる。順序付けとは、急ぐものを決めることであると同時に、急がないものを堂々と後ろに置くことでもある。

露出の評価は一度きりではない。新しい公開、構成変更、テレワーク拡大のような変化のたびに、資産の露出は変わる。台帳の見直しを構成変更の手順に組み込み、KEV突合の表を月次で更新する。静的な表は、数か月で現実とずれる。

台帳の属性整備では、まず「外部公開フラグ」と「境界装置フラグ」の2つだけでも揃える価値がある。属性を増やしすぎると保守が続かない。順序付けに実際に使う属性だけを台帳に残し、使わない属性は思い切って捨てる。台帳は詳しさよりも、更新され続けることの方が重要である。

出典：[1][2]

編集部の実務提案

期限は脆弱性の種類で分け、監視は期限超過で拾う

期限設計は、脆弱性の区分ごとに置く。KEV該当かつ外部露出ありは最短（たとえば2週間以内を上限に、境界装置はさらに短く）、KEV該当だが露出なしは次の区分、KEV非該当は通常サイクル、という具合である。BOD 22-01が「古いCVEは6か月、それ以外は2週間」という既定を示したように、区分で期限を変える発想自体は公的な基準にもある。

期限は設定するだけでは機能しない。台帳上で期限までの残日数を数え、超過と超過予備軍を週次で拾う仕組みが要る。期限超過を「担当者の遅れ」としてではなく「順序付けか資源配分の問題」として扱うために、超過件数とその理由分類を定例で見る。理由が蓄積されれば、区分や期限そのものの現実性も検証できる。

適用作業の段取りも期限に含める。パッチには検証、業務部門との日程調整、再起動の窓、切り戻し手順の準備が伴う。期限の逆算は「適用日」からではなく「検証開始日」から行う。期限直前に検証で問題が見つかれば、代替策の検討時間は残っていない。余裕は期限内ではなく、工程の前倒しで作る。

自動更新が効く範囲は先に広げておく。OSや主要ミドルウェアの自動更新、SaaS側で完結する更新は、人の順序付けの対象から外す。自動化できるものを自動化した残りが、本当に判断を要する適用作業である。小規模な運用チームほど、この切り分けが効く。

期限の例外は次の節で扱うが、ここでも原則だけは固定する。例外は「期限を延ばす申請」ではなく「期限内に代替策で露出を下げる計画」とセットで初めて成立する。

週次の確認では、期限までの残日数が短い順に並べた一覧をそのまま議題にする。資料を作り替える手間を省くことで、定例そのものの継続率が上がる。確認の場で決めるのは、各項目の「適用日程」「代替策への切り替え」「期限区分の見直し」の3つのどれかであり、それ以外の議論は持ち越す。この単純さが、小規模チームで運用を回す鍵になる。

期限の区分は、監査や取引先のセキュリティ質問への回答とも整合させる。自社の区分と期限が文書として存在すれば、質問票への回答は台帳からそのまま書ける。逆に、頭の中にだけある運用は、回答のたびに作り直しになる。期限設計は対外説明の資産でもある。

出典：[1][2]

編集部の実務提案

当てられないときは、代替策で露出を下げる

現実には、期限内にパッチを当てられない場面がある。ベンダーの修正が未提供、業務システムの都合で再起動できない、適用検証で不具合が出た。このとき取るべき行動は「待つ」ではなく「露出を下げる」ことである。BOD 22-01の解説でも、期限内に更新できない資産についてはネットワークからの隔離などの緩和策が示され、隔離はネットワークからの除去の一形態として説明されている。

代替策の候補は、影響範囲の小さい順に並べる。対象機能の無効化、アクセス元の制限、ネットワークの分離、監視の強化、資産そのものの一時停止。どれも恒久策ではないが、攻撃者の到達可能性か、悪用された場合の影響を下げる。代替策ごとに「何のリスクがどれだけ下がるか」を一言で記録しておく。

代替策には必ず期限を付ける。パッチ適用の再予定日とセットで台帳に載せ、期限到来時に自動で再掲されるようにする。代替策のまま放置された資産は、「対策済み」の顔をして残り続ける。四半期の棚卸しで代替策のままの資産を洗い出す工程も要る。

代替策の実施は、業務側との合意文書に残す。露出が残る期間、業務への影響、判断した人の名前。後から事故が起きた場合に、この記録が「放置」と「管理されたリスク受容」を分ける。セキュリティ部門の独断にせず、業務責任者とリスクを共有する手続きとして設計する。

ベンダー起因で当てられない場合は、ベンダーへの確認結果も記録する。修正提供の予定、回避策の有無、公式の推奨。確認した事実があれば、社内の期限判断も監査への説明も具体的になる。「ベンダー待ち」という言葉だけで止めないことが、運用の質を分ける。

代替策の評価では、実施コストと効果の対応も記録しておくと、後の判断が速くなる。たとえばアクセス元制限は低コストで到達可能性を大きく下げる一方、ネットワーク分離は効果が高いが設計と検証に時間がかかる。過去の代替策の実績が台帳に残っていれば、新しい脆弱性が出たときに「前回と同じ手が使えるか」を即座に判断できる。

代替策を選ぶ際は、業務影響の小さいものから試し、効果を確認してから強い策へ進む段階性も意識したい。最初から最も強い隔離に寄せると、業務側の合意が得られず、結果として何もしない期間が延びることがある。

出典：[1][2]

編集部の実務提案

例外と記録:台帳が監査と引き継ぎに耐える形にする

パッチ運用の台帳には、脆弱性ごとに、該当資産、区分、期限、適用日または代替策、例外の理由と承認者、確認結果を残す。これがあれば、担当者が替わっても運用は続くし、監査や取引先からの質問にも、台帳そのもので答えられる。記録は運用の副産物ではなく、順序付けの判断を再現可能にする本体である。

例外承認の水準も決めておく。期限の延長は誰が承認するか、代替策なしの延長は認めるか、延長の上限はあるか。例外が常態化している区分については、例外の多さ自体を問題として扱い、区分設計や資源配分を見直す。例外の集計は、運用の自己点検として機能する。

経営層への報告は、件数の羅列ではなく傾向で示す。KEV該当の残件数、期限超過の件数と理由、境界資産の状態、代替策で保持している資産の数。セキュリティの専門用語を減らし、「悪用が確認されている穴が、外部から届く場所に何件残っているか」という形に翻訳すると、判断に使える報告になる。

スキャン結果の扱いにも注意する。スキャンで見つからない資産には、そもそも順序付けが届かない。資産台帳とスキャン対象の突合、エージェント未導入の端末の把握、シャドーITの棚卸し。順序付けの仕組みは、その前提である「見えている範囲」の管理とセットで初めて意味を持つ。

最後に、緊急対応の経路を用意しておく。大規模な悪用が報じられた脆弱性については、週次のサイクルを待たずに突合と期限設定を行う臨時の手順を決めておく。平時の仕組みが整っていれば、緊急時はその仕組みを速く回すだけで済む。

報告の場面では、期限超過を隠さない文化も重要である。超過を責める材料にすると、現場は期限そのものを緩く設定するようになる。超過は「順序付けと資源の調整材料」として扱い、必要なら区分や期限を実態に合わせて見直す。数字の正直さが、運用の改善速度を決める。

台帳の保管場所とアクセス権も決めておく。脆弱性の残存情報は、それ自体が攻撃者にとって価値のある情報である。台帳は業務に必要な範囲でのみ共有し、外部への提出時は集計値に加工する。防御のための記録が、新たな露出にならないようにする配慮も、運用設計の一部である。

出典：[1][2]

編集部の実務提案

小さく始める:今週できる突合から運用を作る

この運用は、大がかりな導入なしに始められる。最初の工程は、KEVカタログのJSONを取得し、自社の主要製品と突き合わせて、該当するものを台帳に起こすことである。対象をまず境界装置と公開サーバーに絞れば、初回の突合は数時間で終わる。完璧な台帳を待たず、範囲を絞って回し始めることが先である。

次の工程で、区分と期限を暫定で置き、週次の確認を定例に組み込む。期限の数値は最初から正解でなくてよい。運用しながら、超過理由の蓄積を見て現実的な値へ寄せていく。期限は「守らせるための数字」ではなく「順序と資源を調整するための数字」として扱うと、現場の協力が得られやすい。

月次では、台帳の棚卸しと代替策の見直しを行い、四半期では区分と期限そのものを点検する。この3つのリズム、週次の突合と期限確認、月次の台帳整備、四半期の設計点検が回り始めれば、パッチ運用は「届いた順に処理する作業」から「順序を説明できる運用」へ変わる。

効果の測り方も決めておく。KEV該当の平均是正日数、期限超過率、境界資産の該当残数。数字が下がっていく過程そのものが、運用が機能している証拠になる。逆に数字が動かない区分は、設計か資源のどちらかに問題があるという信号である。

脆弱性は今後も増え続ける。CISAの解説も、新規CVEの増加に伴いKEVの件数は拡大していく見通しを示している。増える前提の世界では、「全部は追えない」ことを認めたうえで、悪用実績という最も確かな信号に資源を寄せる設計が、最も防御として効く。

緊急対応の訓練も一度は行っておきたい。悪用が報じられたという想定で、突合から期限設定、業務側への連絡までを通しで実施する。訓練で詰まる箇所は、台帳の所在や連絡経路といった地味な部分であることが多い。本番の前に、その地味な詰まりを取り除いておく。

出典：[1][2]