脆弱性対処の優先順位を決める"脱CVSS"のススメ

3行でわかる本記事のサマリ

  • 脆弱性が爆発的に増加しているため、CVSSスコアからリスクベースの優先順位付けに移行が必要
  • 現実的なリスクを検討し、さらに脆弱性を抱える資産の性質も加味すべき時代
  • 注目のフレームワークとスコアリングシステム:SSVC、CVSS 4.0、EPSS

脆弱性対処の優先度を決めるにあたっては、多くの企業がCVSSのスコアを参照してきましたが、今はリスクベースで決めていく必要になってきています。その理由はどんなところにあるのか、どのような指標で優先順位を決めていけばいいのかなど、脆弱性への対処が求められる担当者に必要なリスクベースへ移行するためのポイントについて見ていきます。

目次

  1. 急増する脆弱性件数、脆弱性対処の常識が変わりつつある
  2. 脆弱性に関する2つの大きな誤解
  3. 注目すべき「PoC(Proof of Concept)」と「ITW(In The Wild)」
  4. 脆弱性を持つ資産の質も加味する時代へ
  5. 新たなトレンド「SSVC」「CVSS 4.0」「EPSS」

1. 急増する脆弱性件数、脆弱性対処の常識が変わりつつある

もともと企業における脆弱性対処の優先順位を決める際の指標としてよく利用されてきたのが、共通脆弱性評価システムと呼ばれるCVSS(Common Vulnerability Scoring System)のスコアです。このスコアで7点以上の脆弱性には対処する、または、報告された脆弱性にはできる限り全てにパッチを当てることを目指すといった形で運用することが一般的でした。

この考え方は、脆弱性の件数がさほど多くない時代だからこそ成り立っていました。もともと脆弱性に対する危機意識が大きくなったと考えられるのが2014年あたりのことで、当時はOpenSSLとBashの、リモートから容易に悪用できるHeartbleedやShell Shockという脆弱性によって被害が多発しました。そこで、脆弱性対処の重要性が広く認識され、その対処に向けてパッチ適用が求められるようになったわけです。

それから数年は脆弱性件数が落ち着いていたことで、全ての脆弱性に対処するという運用が成り立っていましたが、2017年ごろから脆弱性件数が爆発的に増加し、更に2019年にはランサムウェアの脅威が本格化することに。脆弱性に対処しないと致命的なインシデントにつながってしまいますが、今ではその数が多すぎて対処が間に合わないなど混乱している企業も少なくないでしょう。

脆弱性対処12.png

CVSSを基準とした脆弱性対処ルールは、2014~2016年頃に定められたものが多いと考えられますが、件数やその増加率を見ても当時とはまったく状況が変わってきていると見て間違いありません。

そんな状況下において、脆弱性対処の常識が今変わりつつあります。これまでのように、可能な限り全ての脆弱性に対処する、または、CVSSの点数が7以上のものについて優先順位を上げていくといったものから、「リスクの高い脆弱性」だけを最優先で対処していこうという考え方への変化です。加えて、資産が設置されている場所やビジネス上の価値といった資産の性質を加味すること、それらの情報を整理するための専用ソリューションを活用するなど、限られたリソースのなかでも効果的に対処しようという発想に変わってきています。

2. 脆弱性に関する2つの大きな誤解

ここで、最優先で対処すべき「リスクの高い脆弱性」とは何なのかについて考える前提として、脆弱性に関するよくある2つの誤解を紹介します。

【誤解1】どんなリスクでも危険性をはらんでおり、全て対処すべき

現在は年間3万件近い脆弱性が公表されていますが、この多くが脆弱性を悪用するための条件や攻撃手法が公には未実証、もしくはあくまで理論上の存在です。ごく一部の脆弱性だけが、現実世界のリスクとして悪用される可能性があるのが現実なのです。

悪用可能性のある脆弱性については、攻撃手法の情報や実証するためのコードとしてのPoC(Proof of Concept code)が存在するものから、特定の条件下であればまれに攻撃が成立するものなど、リスクレベルもいくつかに分けることが可能です。ごくまれに、誰でも簡単に攻撃が可能という脆弱性もでてきますが、ほとんどはそういった状態になることはありません。あくまで理論上の存在にとどまっているケースが圧倒的に多いことを理解しておくべきでしょう。実際のリスクとなる割合は、さまざまな研究機関からの情報を平均すると3%程度と見ています。

脆弱性対処22.png

年間3万件ある脆弱性のうち、本当に対処すべきリスクは3%であり、それ以外の大部分の脆弱性に関しては、悪用が現実的に起こりえないことが考えられるため、急いで対処する必要がないというのが、最近の脆弱性管理における考え方のベースになっています。全ての脆弱性に対処できる潤沢なリソースがあれば別ですが、膨大な業務を抱える担当者には難しく、できる限りリソースを温存しながら、現実的なリスクにのみ迅速に対応することが必要になってくるでしょう。

【誤解2】CVSSの点数を基準に、対処すべき脆弱性かどうかを判断すべき

もう1つの誤解は「対処すべき脆弱性とそうではないものを選別する際に有効なのはCVSSの点数だ」というものです。よく見受けられるのが、CVSSスコアで7点を基準にして対処するかどうかを判断するというものですが、CVSSを基準にした優先順位付けについては、CVSSを策定する関係団体から2018年に公開されたホワイトペーパーにて、CVSSの誤用だと指摘されています。

CVSSは、あくまでその脆弱性の理論上の深刻度であって、現実的なリスクではありません。過去に出ている脆弱性を見ても、数年間で半数以上が7点以上になっており、CVSSを基準に考えてしまうと、結局ほぼ全部の脆弱性に急いで対処する必要が出てきてしまいます。逆に、CVSSが7未満の脆弱性であっても攻撃で利用されるなど、高いリスクの脆弱性が対象から漏れてしまうケースもあります。CVSSという仕組み自体は有用ですが、優先順位付けの指標としては機能していないということを知っておきましょう。

リスクの高い脆弱性を優先して対処するという考え方については、2021年に米国サイバーセキュリティインフラ庁であるCISA(Cybersecurity and Infrastructure Security Agency)によるKEVカタログの運用開始の事例も参考になります。CISAは、米国の連邦政府全体のセキュリティ対策を推進する機関ですが、2021年に脆弱性対応指針の大きな転換を発表しました。全ての脆弱性に対応するのではなく、前述したような全体の3%にあたる、特に悪用された脆弱性にフォーカスを当てて対応するという方針変更です。

脆弱性対処32.png

そのために、KEV(Known Exploited Vulnerabilities catalog)カタログと呼ばれるものの運用を開始しています。KEVカタログは、過去に悪用されたことが判明している脆弱性をCISAが日々まとめているリストで、2021年以降はこのカタログに記載されている脆弱性を最優先で対応することを求めています。このカタログに記載された脆弱性の対処は、米国内で法的拘束力を持つものになっており、連邦政府の関係機関は原則3週間以内にこれを対応する必要があります。サイバーセキュリティ先進国である米国において、政府機関を守る総本山のような役割を担うCISAがこのような方針を示したことは、非常に印象深いと言えるでしょう。

▼KEVカタログ
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

3. 注目すべき「PoC(Proof of Concept)」と「ITW(In The Wild)」

次に、Webメディアをはじめとして世の中に出てくる脆弱性情報を見る際には、どんな情報に注目すべきなのでしょうか。ここで注目したいのが、「PoC」と「ITW」という2つのキーワードです。

脆弱性対処42.png

PoCは、脆弱性の存在や悪用の可能性を実証するための詳細な解説情報で、脆弱性を実際に発現させるための行動のことを指します。脆弱性の存在と、その利用可能性が実証されるPoCが公開されることの間には非常に大きなリスクの隔たりがあります。PoCが出ることで、脆弱性の使い方に関する情報が出回り、攻撃活動に転用されるリスクが格段に上がってくることになるため、十分な注意が必要になります。

ITWは、exploit in the wildと呼ばれるもので、脆弱性を使った実際の攻撃活動が観測されたことを意味しています。すでに英語圏では慣用句のような決まり文句として使われています。PoCが出ていても、悪用するためにはシステムの管理者を騙して特定の操作をさせる必要があったり、脆弱性悪用のための設定がデフォルトで有効になっていない場合が多かったりなど、現実的には利用しづらいことがあるため、必ず攻撃に使われるわけではありません。しかし、実際に攻撃で使われたことを示すITWの情報がメーカやメディアから出た場合は、すでに現実の攻撃で使われたことになるため、最大限警戒と迅速な対処をする必要があります。

4. 脆弱性を持つ資産の質も加味する時代へ

脆弱性対処については、現実的なリスクを検討したうえで対処すべきという考え方に加えて、最近では脆弱性を抱える資産の性質も加味すべきという考えも広まりつつあります。

例えば、脆弱性を持つサーバーがインターネットから直接アクセス可能な場所に設置されていれば、攻撃者はいつでも好き勝手にアクセスができるため、非常にリスクが高いのは当然でしょう。社内からしかアクセスできないサーバーであれば、攻撃者も社内に侵入する手間がかかるため、リスクは一段低く考えることができます。スタンドアロンで稼働し、ネットワークに繋がっていない機器であれば、攻撃を受けるリスクは限りなくゼロに近づくことになります。

また、資産が持つビジネス上の価値についてもしっかり考慮する必要があります。例えば、自社の重要な機密情報を含む資産かどうか、個人情報を含んでいるのかどうか、単なるテストサーバーなのかによって、考慮すべきリスクは大きく異なってきます。資産の性質もしっかり加味したうえで、脆弱性対処の優先順位は考えておきましょう。

脆弱性対処52.png

5. 新たなトレンド「SSVC」「CVSS 4.0」「EPSS」

前述したようなトレンドを受け、ここ数年で注目されている3つのキーワードがあります。「SSVC」「CVSS 4.0」「EPSS」です。これらについても見ていきましょう。

SSVC

前半で説明したような、"現実のリスクや資産の性質を加味して脆弱性対処の優先順位を決めるべき"ということは理屈で理解できたとしても、自組織の運用やルールにどうやって落とし込めばいいのか、イメージしづらい方もいるでしょう。そんな落とし込みを手助けしてくれるのが、SSVC(Stakeholder-Specific Vulnerability Categorization)と呼ばれるフレームワークです。CVSSのスコアで優先順位を決めてしまうとほぼ全て対処せざるを得ないという世界共通の課題に応えるべく開発されたもので、脆弱性への対処の優先度を決定木に沿って決めていくようなものになっています。

決定木は、使う人の立場によって「サプライヤー決定木」「デプロイヤー決定木」「コーディネーター決定木」の3種類が準備されています。一般的な企業が利用するのが、デプロイヤー決定木で、大まかには4つの評価項目があります。具体的には攻撃コードの有無やPoCが出ているかどうか、資産の設置場所はどこか、攻撃者にとっての有用性、そして資産が攻撃を受けた場合の影響はどの程度か等を選択していくことで、脆弱性の対処の優先度が4段階でアウトプットされます。SSVCはあくまでフレームワークであり、何かツールが必要になるわけではないですが、決定木の構造をグラフィカルに見せてくれる理解しやすいサイト等も存在しており、ぜひ参考にしてもらいたいです。

▼SSVCデモサイト
https://certcc.github.io/SSVC/ssvc-calc/

脆弱性対処63.png

脆弱性対処72.png

ただし、このSSVCにはメリットだけでなくデメリットも存在します。メリットは、対処の優先度を絞り込むことができるため、早急に対処すべき脆弱性の数をかなり減らすことができるようになることです。また、決定木に沿って意思決定されるため、脆弱性対処の優先度を決める際の判断のふらつきや属人的な判断を回避しやすく、組織適用しやすい点も見逃せません。

一方でデメリットは、SSVCの初版策定は2019年で、認知され始めたのも割と最近であるため、運用にうまく乗せることができている企業はまだ少なく、一部の先進的な企業がトライアルを実施している段階にあり、現場で利活用するためのノウハウが十分流通していないことです。また、決定木の項目を選択する際に、ある程度知識が必要だということもあります。その脆弱性を悪用した攻撃が実際に行われているのかについては、別の情報源から探してくる必要があり、その脆弱性が攻撃への転用時に自動化可能なものかどうかなどは知識がないと判断できないものになってきます。

なお、つい最近上記課題の解決につながるVulnrichmentプロジェクトと呼ばれるものをCISAが開始しており、重要な脆弱性に関しては、SSVC運用時に必須となる攻撃の発生状況や自動化可否の状況などの情報が無償で提供されています。

▼Vulnrichment
https://github.com/cisagov/vulnrichment

CVSS 4.0

2023年の11月にリリースされたCVSSは、そもそも2005年から運用が始まるなど歴史が古いものになりますが、過去何度かバージョン変更があり、その都度スコアの算出のロジックや算出項目が少しずつ調整されています。

もともとCVSSには多くの方が目にする基本評価基準値以外にも、現状評価基準値や環境評価基準値といった指標が存在しています。今回のバージョン4.0では基本評価基準値の項目が微調整されたこと、そしてどこまでの範囲でスコアが算出されたのかが把握しやすいように各基準値に名称がつけられるようになったという2つが、主な変更です。今後数年はCVSS3.1との並行運用が行われ、徐々に社会に浸透していくと考えられます。

脆弱性対処82.png

EPSS

EPSS(Exploit Prediction Scoring System)は、CVSSを管理している団体と同じFIRSTが開発し、各脆弱性に対して独自の機械学習モデルで計算され、脆弱性が今後30日以内に実際に悪用される可能性(Probability)がスコアとして示されているものです。これは脆弱性の天気予報のようなイメージでとらえると分かりやすく、スコアを参照する際には、CVEDetailsと呼ばれるWebサイトが参考になります。EPSSの指標ではpercentileと呼ばれる、全体のなかでのEPSSのランクを示す数字がありますが、例えばある脆弱性が85%と示されていると、上位15%に入る危険度という見方ができます。この数が99%であれば、上位1%に相当するかなり危険な脆弱性だということが分かります。

https://www.cvedetails.com/

脆弱性対処92.png

ただし、このEPSSは悪用の確率が実態に即していないケースも見受けられ、このスコアをもとに意思決定をするというのは現状は避けたほうが無難と考えられます。機械学習のモデルも日々調整が行われているため、将来的には精度が向上するなど実運用に適用できる時代もやってくることが期待されているため、動向を見守っていただきたいです。

最後に、改めてではありますが、現在リスクベースの優先順位付けが大きなトレンドになっており、SSVCやEPSSといった注目されるワードも登場しています。現時点で全ての脆弱性に余裕をもって対処できるという企業は別にして、CVSSだけで優先順位を決めており脆弱性管理に課題を感じている方は、勇気をもってリスクベースでの判断に移行することをぜひ検討してもらいたいと思います。

なお、マクニカではリスクベースの脆弱性管理に基づく考え方で、お客様環境のハイリスク資産の網羅的な把握と、リスクの高い脆弱性の通知が可能なMacnica Attack Surface Managementを提供しています。ぜひご確認ください。

資料のダウンロードはこちら.png

メルマガ登録バナー(セキュリティ).jpg

ランキング