脆弱性評価のお話

CVE、CVSS…とはなんぞや?
毎月Windowsのアップデートやセキュリティに関するニュースを見ていると各種製品やソフトウェアの脆弱性情報と共に「CVE…」や「CVSS…」のような文字列を見かけることがあると思います。

今回は脆弱性評価のお話というテーマで、これらのよく分からない文字列が表す意味、見方、加えて具体的にどのように活用するかを併せて見ていきたいと思います。
それぞれの概要
まずはこれら謎の文字列の正式名称と概要について簡単に説明します。
・CVE
共通脆弱性識別子(Common Vulnerabilities and Exposures)の略で、
「世の中の脆弱性情報を重複なく、一意に管理するための識別番号」です。
別々の組織が偶然同じ脆弱性情報を発見した場合に、それらが重複するのを防いだり、あるいは関連する別の脆弱性と参照し合えるように管理するための番号です。
・CVSS
共通脆弱性評価システム(Common Vulnerability Scoring System)の略で、
「脆弱性がどれだけ深刻かを示す評価指標」です。
製品の製造元やベンダーに依存しない共通の評価方法で脆弱性の深刻度について「0.0~10.0」の数値で表現しており、数値が大きいほど危険性が高いと判断して以下のように対策の緊急度を定義しています。
9.0~10.0:緊急 / 7.0~8.9:重要 / 4.0~6.9:警告 / 0.1~3.9:注意 / 0:なし
運用団体と管理方法
CVEやCVSSは「世界でひとつの識別番号」であったり、「世界で共通した評価基準」のため、運用管理するには専門性を持った組織が幅広く連携、相互協力することが必要になってきます。
・CVEの運用と管理
CVEはMITRE Corpration(米国政府向けの技術支援や研究開発を行う非営利組織)がIBMやRed Hat、Symantecといった主要な脆弱性情報サイトと連携して、脆弱性情報の収集と重複しないよう採番を管理しています。
・CVSSの運用と管理
CVSSはFIRST(Forum of Incident Response and Security Teams、世界中の情報セキュリティを専門に研究、対応している組織同士が情報交換やインシデント対応の協力関係を構築するフォーラム)で管理されており、世間的な技術の移り変わりに応じて評価基準の見直し、仕様検討を行っています。
その他、関連性のある識別番号について
CVEやCVSSおよび共に見かけることがあるその他の識別番号について、それぞれどのような関連性があるかを簡単に紹介します。
・JVN
Japan Vulnerability Notesの略で、これは日本国内で利用されている製品に対する脆弱性情報と対策を提供するポータルサイトで、IPA(独立行政法人)とJPSCERT/CC(コンピューターインシデントに対応する社団法人)が共同で運用管理しています。中にはCVEに含まれていたり、関連している脆弱性情報もあります。
・NVD
脆弱性情報データベース(National Vulnerability Database)の略で、ユーザーへ脆弱性の詳細な内容、対策方法を発信するためのデータベースで、NIST(米国立標準技術研究所)が運用管理しています。
CVEの情報だけ見ても識別番号と関連する情報サイトや出典が羅列されているだけですが、
ユーザー向けにCVSSに基づいた脆弱性の評価スコアや、脆弱性に関する各種参考リンクを集約しています。
結論、何を見るべきなのか?
ここまでつらつらと識別番号や用語の説明をしてきましたが、結論としては
- CVEで脆弱性の識別番号を確認し、既知のリスクか新たなリスクか確認する
- NVDで参考情報やCVSSの具体的な評価指標を確認して対策するか否かを検討する
といった使い方が有効的ではないかと考えられます。
以下はそれぞれの関連性について簡単なイメージとなります。

どうやって活用するのか?
ここからは脆弱性管理において実際の脆弱性情報に対して、CVEの見方、CVSSを用いた評価スコアの付け方を見ていき、加えて自組織にどう影響があるのかをシミュレーションしてみます。
・今回シミュレーションする脆弱性
直近、2024年6月のWindows月例アップデートで公表された脆弱性「CVE-2024-30101」を例にして、この脆弱性が自組織に影響があるかないかを判断してみます。
・CVEの見方
命名規則は何となくお気づきになるかと思いますが、「CVE-YYYY-XXXX」となっており、YYYY部分は概ね発見された年号となり、XXXXは一意の番号になっています。
実際にCVEのサイトにこの脆弱性識別番号が存在しているか見てみましょう。

「Microsoft Office のリモートコード実行の脆弱性」という脆弱性の概要に加えて、ベンダーや製品の情報、影響のあるバージョンについて書かれています。
JSON形式でCVE識別番号以外にもCVSS評価情報等が取得できるようですが、話が広がり過ぎてしまうのでここでは割愛いたします。

ページを下にスクロールしていくと「参考文献」として開発、製造元ベンダーのサイトにおける詳細情報のリンクやNVDサイトのリンクがあるのでアクセスしてみます。

NVDのサイトへ行くとデフォルトで「CVSS Version 4.0」のタグが選択されていますが、これはまだ仕様検討中の評価指標バージョンなので「CVSS Version 3.x」にして確認します。

するとこのように評価指標のスコアが表示され、かつ下の方にベンダーであるMicrosoft公式の情報リンクも確認することができます。
※補足:「AWAITING ANALYSIS(解析待ち)」と表示されていますが、本ブログ記載の2024年7月時点でCVEとNVDの整合性を取るための人手やリソース不足が原因と言われており、運用団体にて相互連携して改善している途中とのことです。
続いて Microsoft公式サイト にもアクセスしてみます。すると、同じ評価指標で「CVSS:3.1 7.5」のように表示されていますが、NVDの表示と違い7.5 / 6.5のように表示されています。

これらの違いは何なのか、実際にCVSSで利用される評価指標の内容を調べながら見ていきましょう。
・CVSSの見方
現行の評価バージョンCVSS v3.1に基づいて実際に「CVE-2024-30101」を評価してみます。
まずは、NVDにある「Base Score」および「Vector」の部分について見ていきます。
・基本評価基準
Base Scoreは基本評価基準の基本値で、Vectorから算出した値によって脆弱性の緊急度レベルを表した数値です。
この脆弱性については「7.5」ということなので緊急度としては「重要」に定義されます。
なお、評価基準には基本評価基準の他に、現状評価基準、環境評価基準があり以下のように評価内容が変わってきます。NVDには基本評価基準のスコアだけが記載されています。
- 基本評価基準 … 脆弱性評価にあたって必須となる指標。脆弱性の基本値となる
- 現状評価基準 … 対策方法や攻撃手法が確立されているか等の評価基準、任意で評価する
- 環境評価基準 … 組織ごとに影響があるかの評価基準、任意で評価する
・評価基準
Vectorは各評価基準の根拠となる指標で、詳細なスコアや具体的な内容を記すと情報量が多くなってしまうので、ここではそれぞれの略語の意味だけ説明します。気になる方はIPAの紹介ページを見てください。
基本評価基準の指標
・AV(Attack Vector)
どこから(ネットワーク、ローカル、物理等)攻撃可能であるかを評価します。
ネットワークを経由して攻撃可能であれば「高」と評価され、物理的、例えばUSBメモリを接続する等であれば「低」と評価します。
・AC(Attack Complexity)
攻撃するために必要となる条件の複雑さを評価します。
攻撃するために特に何も必要なければ「高」、特別な環境を用意したり権限昇格が必要であれば「低」と評価します。
・PR(Privileges Required)
攻撃に必要な権限のレベルを評価します。
特に権限などが必要ない場合は「高」、管理者権限が必要であれば「低」と評価します。
・UI(User Interaction)
攻撃する際にユーザー側で何かしらのアクションが必要か、そうでないかを評価します。
ユーザーが何もしなくても攻撃されれば「高」、ユーザーのリンククリックやファイル操作といった動作を必要とする場合は「低」と評価します。
・Scope(S)
攻撃によって広範囲に影響があるかないかを評価します。
少し説明が難しいですが、平たく言ってしまうと攻撃による影響が外部のアプリやリソースにも影響が出るなら「高」、特定のアプリやリソースの範囲内にしか出ないなら「低」と評価します。
・Confidentiality Impact(C)
情報漏洩の可能性といったいわゆる「機密性への影響度合い」を評価します。
・Integrity Impact(I)
情報改ざんの可能性といったいわゆる「完全性への影響度合い」を評価します。
・Availability Impact(A)
業務遅延・停止の可能性といったいわゆる「完全性への影響度合い」を評価します。
今回の「CVE-2024-30101」Microsoft Officeでリモートコードが実行される脆弱性は、NVDに記載されている評価指標を見ると以下のようになっています。
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
これを紹介した評価指標になぞって分かりやすく表記すると以下のようになります。
評価CVSSバージョン/攻撃可能な場所:ネットワーク/攻撃条件:複雑/攻撃に必要な権限:不要/ユーザー操作:要/スコープ:変更なし/機密性影響:高/完全性影響:高/可用性影響:高
各評価指標のスコアをCVSSで定められた定数などを用いた計算式に当てはめると結果として「7.5」という評価スコアが出てきます。
ざっくりどのような計算式か紹介しますと、
「影響度」「攻撃容易性」を算出して「基本値」を出すといった流れとなります。
調整前影響度 = 1-(1-C)×(1-I)×(1-A)
※基本評価基準のC、I、Aの値から算出
影響度 = 調整前影響度×6.42(スコープ無しの場合の定数)
※スコープ有り、無しの場合で計算式は変わりますが、スコープ有りの方が高い値になります。
攻撃容易性 = 8.22(定数)×AV×AC×PR×UI
※攻撃可能な方法、複雑さ、権限などから算出
基本値 = 影響度+攻撃容易性と「10」を比較して小さい値の小数点第2位以下切り上げ)
※もし基本値が「0」なら「0」とし、スコープ有り、無しで計算式は変わり、スコープ有りの方が高い値になります。
※詳しい計算式はこちら
現状評価基準の指標
ではMicrosoft公式のサイトで表示されている「6.5」とは何かというと前述した「現状評価基準」の値になります。
今回はMicrosoft Officeの脆弱性であるため、開発元であるMicrosoftが自ら現状評価基準を算出しているということですね。
・E(Exploit Code Maturity)
攻撃される可能性を指しており、攻撃の方法が実在して利用できるか、そうでないかで評価します。攻撃方法が確立、実在している場合は当然ながら「高」と評価されます。
・RL(Remediation Level)
利用可能な対策のレベルを指し、これは開発元が正式な対策を用意しているか、そうでないかで評価します。セキュリティパッチが既に公開されていれば「低」、パッチや対策方法が全くなければ「高」となります。
・RC(Report Confidence)
脆弱性情報の信頼性を指し、開発元が脆弱性について把握、情報を確認しているかで評価します。脆弱性の全貌について開発元が十全に把握している、ある程度世間が認識しているなら「低」ですが、未知の状態である場合は「高」と評価されます。
基本評価基準で算出した基本値とこれらのスコアの積を小数点第2以下切り上げで求めた値が現状評価基準の指標の値となります。
「CVE-2024-30101」においては以下のような計算となります。
7.5(基本値)×0.91(E)×0.95(RL)×1.00(RC) = 6.48375 = 6.5
この値がMicrosoft公式サイトで表示されているスコアの正体です。
環境評価基準の指標
最後に、それが自社環境にどれほど影響あるかを評価するための環境評価基準を追加評価してみます。
例として「Officeソフトであまり重要情報を管理していない組織」と「Officeソフトで重要情報を管理している組織」のパターンに分けて評価してみましょう。
環境評価基準の評価指標は基本評価基準の指標である「AV/AC/PR/UI/S/C/I/A」を再評価する形になります。
影響度となる「C/I/A」はその組織にとって「要求度(Requirements)」を再評価するという意味から「CR/IR/AR」となり、攻撃容易性となる「AV/AC/PR/UI/S」はそれぞれ「Modified(修正された/対策が施された)」という意味から「MAV/MAC/MPR/MUI/MS/MC/MI/MA」となります。
詳しい計算式は情報量の関係から割愛しますが、ここで一例として前述した2つのパターンで評価してみます。
・Officeソフトであまり重要情報を管理していない組織 の場合
機密情報や業務に必要な情報をOfficeソフトであまり管理していない場合、CR、IR、ARを「低」と仮定して良さそうです。
緩和策調整前影響度 = min[1 – (1 – 0.56×0.5)×(1 – 0.56×0.5)×(1 – 0.56×0.5),0.915] = 0.626752
スコープ無しなので
緩和策調整後影響度 = 6.42×0.626752 = 4.02374784
攻撃容易性 = 8.22×0.85×0.44×0.85×0.62 = 1.62014556
環境評価基準を加味した値 = 影響度+攻撃容易性と「10」を比較して小さい値の小数点第2位以下切り上げ) = RoundUp1(min [(4.02374784+1.62014556), 10]) = 5.7
となり、元々の基本値「7.5」から2ポイント近く下がり緊急度も「重要」から「警告」に下がったことが分かります。
・Officeソフトで重要情報を管理している組織 の場合
このパターンであればCR、IR、ARいずれも「高」と仮定できます。
緩和策調整前影響度 = min[1 – (1 – 0.56×1.5)×(1 – 0.56×1.5)×(1 – 0.56×1.5),0.915] = 0.915
スコープ無しなので
緩和策調整後影響度 = 6.42×0.915 = 5.8743
攻撃容易性 = 8.22×0.85×0.44×0.85×0.62 = 1.62014556
環境評価基準を加味した値 = 影響度+攻撃容易性と「10」を比較して小さい値の小数点第2位以下切り上げ) = RoundUp1(min [(5.8743+1.62014556), 10]) = 7.5
となり、ベンダーが公開しているセキュリティパッチを適用しても元々の「7.5」になってしまっているため、何かしらの追加対策が必要になりそうと判断できるかと思います。
まとめ
今まで脆弱性評価について筆者はざっくりと「社内利用があるか?」「ベンダーなどから情報収集」のうえ対応を検討して報告していましたが、このように「数値」として表現できると会社として「対策すべきか」「どこまで実施すべきか」の判断がしやすくなると思います。
脆弱性に対してセキュリティ担当としては正確な情報を共有して、適切に対応を行う必要があります。
そういった活動の精度を向上させるためには多いに役立つ仕組みだと感じました。
ただ、実際に実務でここまで細かい計算をして脆弱性評価するとなると、工数がかかるため自動計算してくれるツール等を検討した方が良いですね。