脆弱性対応は「点数」から「リスク」へ――CVSS、KEV、BOD 26-04を踏まえた優先順位の付け方：辻伸弘の「投げます。一石、」（5）（2/2 ページ）

[辻伸弘，ソフトバンク株式会社]

　筆者がまとめた、年別のCVE公開件数とKEV登録件数のグラフを参照してほしい。2022年まではそれ以前の脆弱性もKEVに登録されていたため、2023年以降の数字に注目すると、CVEは年々増加しているが、KEVに登録されるのはその1％未満であり、対処すべき脆弱性を絞り込む、強力な指標になることが分かるだろう。一方で、KEV掲載までのタイムラグや、CVSS 7.0未満でも悪用される脆弱性が約2割存在する問題があることにも注目したい。

CVE公開件数とKEV登録率の推移（筆者まとめ）

　CVSSベースでの対応には、2つの盲点がある。

　1つは、CVSS基本値が高いという理由だけで、実際には悪用されておらず、リスクベースで見ると緊急性の低い脆弱性にリソースを割いてしまうことだ。もう一つは、CVSS基本値が低くても、実際に悪用されているなど緊急性の高い脆弱性への対応が漏れたり、後回しになったりすることだ。CVSSは脆弱性そのものの技術的深刻度を評価するには有用だが、それだけで組織にとっての対応優先度が決まるわけではない。

　脆弱性対応はこの「悪用されているかどうか」、つまりリスクベースで考える必要がある。

CISA「BOD 26-04」に学ぶ、4つの判断基準と決定木型リスク評価

　そこで紹介したいのが、CISAがアメリカの政府機関向けに出している、強制力のある運用指令「BOD 26-04: Prioritizing Security Updates Based on Risk」だ。これは、4つの判断材料から、リスクに基づく決定木をたどることにより対応期限を決めるという内容となっている。

BOD 26-04: Prioritizing Security Updates Based on Risk | CISA

　判断材料は以下の4つだ。

• 資産の露出（Asset Exposure）：インターネットなどの公衆ネットワークからアクセスできる状態（公開資産）かどうか
• 悪用の確認（Known Exploitation / KEV）：悪用が確認されている脆弱性のカタログ（KEV）に掲載されているかどうか
• 攻撃の自動化（Attack Automation）：攻撃のステップが全て自動化可能かどうか
• 技術的影響（Technical Impact）：システムを実質的に掌握できる「完全」か、攻撃者が得られる能力や影響範囲が限定される「部分」か。

パターン	資産の露出	悪用の有無（KEV掲載）	自動化可能	技術的影響	対応
1	はい	はい	はい	完全	3 日 & 侵害調査
2	はい	はい	はい	部分	3 日
3	はい	はい	いいえ	完全	3 日 & 侵害調査
4	はい	はい	いいえ	部分	14 日
5	はい	いいえ	はい	完全	3 日
6	はい	いいえ	はい	部分	14 日
7	はい	いいえ	いいえ	完全	14 日
8	はい	いいえ	いいえ	部分	60 日
9	いいえ	はい	はい	完全	3 日 & 侵害調査
10	いいえ	はい	はい	部分	14 日
11	いいえ	はい	いいえ	完全	14 日
12	いいえ	はい	いいえ	部分	14 日
13	いいえ	いいえ	はい	完全	60 日
14	いいえ	いいえ	はい	部分	60 日
15	いいえ	いいえ	いいえ	完全	システムアップグレード時に修正
16	いいえ	いいえ	いいえ	部分	システムアップグレード時
BOD 26-04の判断材料と修正スケジュール

　これはかなり有用な指針だと考えている。対応日数は脆弱性のリスクにより変化し、現実的な方法で決定される。例えば、KEVに載っているかどうかに一喜一憂しがちな従来の対応に対し、BOD 26-04では「公開資産であり、攻撃が自動化可能で、技術的影響が完全」であれば、KEVに未掲載であっても3日以内の対応が命じられる。加えて、同じ条件であっても「非公開資産」であれば期限が60日以内になることにも注目したい。「KEVに載っていなくても、他の条件が危険であれば迅速に対応させる」という決め方は非常に興味深く、大きな学びがあった。

　加えて、最も緊急度の高い条件では、更新に加えて、「パッチ適用前に既に侵害されていないか」を確認する侵害調査も求められている点に注目したい。パッチを適用して安心していたものの、実はその前に侵害されていたという事例は後を絶たない。CISAがログ調査などの侵害調査とセットで対応期限を設けていることは、現場の実態に即した極めて実践的なアプローチだと評価できる。

　さらに言えば、評価軸から「CVSS基本値が幾つ以上か」という概念が完全に消え、技術的影響は、システムを実質的に掌握できる「完全」か、攻撃者が得られる能力や影響範囲が限定される「部分」かの二択に整理されている。CVSSの小数点の上下や区分に振り回されることなく、「悪用された場合に何ができるのか」という実際の影響に着目して判断できる点にも、シンプルかつ実践的な設計思想が感じられる。

　もちろん、「BOD 26-04」で示される3日、14日、60日といった日数はアメリカの連邦政府機関に向けられた基準であるため、われわれはこれに完全に従う必要はない。自分たちの組織で想定するリスクと実現可能性を加味して変更することになるだろう。

「Vulnrichment」でさらに先回りを

　KEVは米国政府が悪用を確認し、緩和策を含む対策が明らかになったタイミングで掲載される。つまり、どうしても悪用からKEV登録までの「すき間」が存在する。

　そのすき間に対応できるかもしれない、もう1つの有用な情報を紹介しよう。同じくCISAが公開しているプロジェクト「Vulnrichment」は、公開されているCVEに対し、さまざまな情報をGithubにて、誰にでも参照可能な形で公開している。前述したBOD 26-04にある「悪用の有無」「自動化可能」「技術的影響」についてもここで参照可能である。

GitHub - cisagov/vulnrichment: A repo to conduct vulnerability enrichment

　注目してほしいのは、CVEごとに用意されたjsonファイルに含まれる「Exploitation（悪用状況）」フィールドだ。ここには、悪用されたことが観測済みの「Active」、実証コードがある「POC」、何もない「None」の3つの値が入る。

　これをうまく使おう。「Active」であれば、KEV掲載前であっても実際の悪用が観測されているため、優先度を引き上げる材料になり得る。一方、「PoC」は実証コードが存在することを示すにすぎず、直ちに実悪用へ移行することを意味しない。

　PoCの存在だけで一律に対応優先度を上げるのではなく、資産の露出や技術的影響など、他の条件と組み合わせて判断する必要がある。

基礎工事という「資産管理」から始める現実的な防御

　今回の内容でぜひ知っておいていただきたいのは、米国政府もこの「BOD 26-04」を一足飛びに作り上げたわけではないということだ。その背景には、2021年11月に悪用が確認された脆弱性を集約するKEVカタログを創設し、期限内の対応を求めた「BOD 22-01」、資産の可視化と脆弱性検出の強化を求めた「BOD 23-01」、インターネットに露出した管理インターフェースのリスク低減を求めた「BOD 23-02」といった、長年の積み重ねがある。

　上澄みの優先順位付けだけを付け焼き刃で真似しても、うまくはいかない。基礎工事が不十分な場所にマンションを建てることができない、寝てない、食べてない、運動してないのにサプリメントだけで健康になれないのと同じだ。まず必要なのは、自組織の「どこに何があるのか」を把握し、その上で「そこにどのような脆弱性があるのか」を把握できる土台を作ること。「情報セキュリティは情報資産管理の上にしか成り立たない」と筆者は強く強く思っている。

　これまでの推移を考えると、今後も脆弱性の公表件数は増え続けると予想される。しかし、CVE公開件数に占めるKEV登録件数の割合は、近年1％未満で推移している。だからこそ、リスクベースでの選別が不可欠であり、現実的な対応となるだろう。

　誰かが決めた「ルール」を満たすためだけの脆弱性対応から脱却し、自組織の資産状況と悪用リスクを掛け合わせ、自分たちで優先順位を決められる運用へ移行する。そのための一歩目は、新しいツールの導入でも、新しい評価基準の策定でもない。まず「どこに何があるのか」を知ることから始まる。

筆者紹介

辻伸弘

ソフトバンク株式会社

セキュリティリサーチャー

https://x.com/ntsuji

コンピュータの専門学校に通いながら、サイバーセキュリティを手探りで学び、侵入テストの仕事に就きたくて上京。現在は、侵入テストだけでなく、事件・事故を調査するセキュリティリサーチの仕事にも携わっている。侵入テストで培った攻撃者視点や分析力と、リサーチで得た情報・知識を基に、執筆や講演などのエバンジェリストとしても幅広く活動する。