Skip to main content

CVSS 4.0の新機能

blog feature parlay announcement

2023年11月8日

0 分で読めます

このブログでは、2023年11月1日に公開された新しい脆弱性スコアリングフレームワーク「CVSS 4.0」に対するSnykの見解をご紹介します。

なぜ改定が必要だったのか?

今回の改定は、サイバーセキュリティの脆弱性を取り巻く状況が必然的に進化したことを受け、従来の手法の弱点を克服するために行われました。2016年の公開以来、CVSS 3は、さまざまな脆弱性がもたらす潜在的な影響とリスクレベルを示す堅牢な評価ツールとして、専門家に活用されてきました。これにより、組織や個人はサイバー脅威からより適切に身を守ることができました。

その7年後に登場したCVSS 4.0は、次のバージョンとして、より詳細な評価を可能にし、スコアリング手法をさらに洗練させることを目指しています。進化し続けるサイバーセキュリティ脅威とデジタル環境の動向に、より適切に対応するためです。

何が変わるのか?

3.1と4.0のフレームワークを技術的に比較し、導入される変更点を見ていきましょう。

注:各定性的な深刻度の値に対応するスコアの深刻度レベル/範囲(Low、Medium、High、Critical)は変更されません。

攻撃ベクターパラメーター

CVSS 3.1とCVSS 4.0の攻撃ベクトル指標を比較する図

新しい攻撃ベクターパラメーターは、より包括的な仕様を示すための意味上の変更(例:コンポーネントとシステム、物理的と近接)をいくつか含みますが、従来と同じ目的で使用されます。

そのため、CVSS 4.0で脆弱性を評価する際、このパラメーターの使い方に変更はないと考えています。

攻撃の複雑さパラメーター

CVSS 3.1とCVSS 4.0の比較図:CVSS 3.1の攻撃の複雑さは、CVSS 4.0の攻撃の複雑さと攻撃要件に対応します。

CVSS 3.1の攻撃の複雑さパラメーターは、より詳細な評価を可能にするため、攻撃の複雑さと攻撃要件に分割されます。

新しい「攻撃の複雑さ」パラメーターは、「セキュリティ強化技術の回避または迂回」を伴う高度に専門化された攻撃に用いることを想定しています。

一方、「攻撃要件」は、脆弱なシステムの特定の展開条件や実行条件が攻撃を可能にする場合に、攻撃の成功が「それらの条件の存在に依存する」ケースを対象とします。

攻撃の複雑さと攻撃要件の主な違いは、攻撃を可能にする特定の条件がどのような目的を持つかにあります。仕様書によると、攻撃要件は、新しい攻撃の複雑さパラメーターでは対象とならないシナリオのみを捉えるために使用されます(つまり、エクスプロイト緩和技術を回避するシナリオには使用しません)。

オープンソースのエコシステムでは、攻撃の複雑さは高度に専門化された攻撃にのみ使用されるため、このパラメーターの使用は減少すると予想しています。一方、攻撃要件は「脆弱なシステムの展開や実行の結果として自然に生じる」条件を含むため、使用が増える可能性があります。

必要な特権パラメーター

CVSS 3.1とCVSS 4.0を比較する図。両バージョンで「必要な特権」を表示

新しい必要な特権パラメーターには、表現をより明確かつ簡潔にするための小規模な変更のみが加えられています。パラメーターの値に変更はありません。

脆弱性評価におけるこのパラメーターの使い方に変更はないと予想しています。

ユーザー関与パラメーター

CVSS 3.1とCVSS 4.0を比較する図。両側に「ユーザーインタラクション」が示され、その間に双方向の矢印が描かれている

CVSS 4.0の仕様書では、新しいユーザー関与パラメーター、特にその値に顕著な変更が見られます。これにより、攻撃条件をより正確に評価できます。

ユーザー関与の値は、CVSS 3.1の2つから3つに増えます。

  • なし — 人間のユーザーを重視した定義に改善されました。「攻撃者以外の人間のユーザーによる操作なしに、脆弱なシステムを悪用できる」場合にこの値を使用します。

  • 受動的 — 被害者の意図しない操作を通じて実行できる攻撃を対象とします。

  • 能動的 — 前述のケースとは異なり、攻撃の成功に被害者が「脆弱なシステムおよび攻撃者のペイロードに対して、特定の意識的な操作を行う」必要がある場合に使用します。また、被害者の「操作が保護メカニズムを能動的に無効化し、脆弱性の悪用につながる」場合にも該当します。

これらの値の追加により、従来のユーザー関与の値が置き換わり、脆弱性の深刻度をより適切に分布できます。そのため、脆弱性評価プロセスにおけるこのパラメーターの使い方は変わります。

CIAトライアド

CVSS 3.1とCVSS 4.0の機密性、完全性、可用性の指標を比較し、脆弱なシステムへの影響指標も示した図。

CIAトライアドに目立った変更はありません。仕様書内の定義に一貫性を持たせるため、表現がわずかに修正されています。

これらのパラメーターの使い方は、ほぼ変わらないでしょう。

スコープパラメーター

CVSS 3.1とCVSS 4.0を比較した図。スコープが拡大し、機密性、完全性、可用性への影響指標が追加されています。

スコープパラメーターは後続システムへの影響メトリクスに置き換えられます。これにより、脆弱性の影響を評価する際の精度が向上し、深刻度の分布もより均等になります。

この変更では、スコープの変化をパラメーター化するだけでなく、後続システムへの影響も明確にします。

新しいアプローチにより、脆弱性評価のプロセスが変わり、影響をより正確に評価できるようになります。

脅威メトリクス

CVSS 3.1とCVSS 4.0の比較。どちらのバージョンでも、Exploit Code Maturityがスコアリング要素として示されています

以前は「時間的スコア」と呼ばれていた脅威メトリクスにも大きな変更がありますが、ここではエクスプロイトコードの成熟度のみを取り上げます。このパラメーターはエクスプロイトの成熟度に名称が変更され、値は5つから4つになります(Functionalの値は廃止)。エクスプロイトの成熟度に関する新しい定義は改善され、各値を使用する根拠となる具体的な要件が含まれています。

未定義 — 「エクスプロイトの成熟度の特性を判断するための信頼できる脅威インテリジェンスがない」場合に使用します。

攻撃済み(旧High) — 1) 攻撃が報告されている、または2) エクスプロイトが、さまざまなソリューションに組み込める成熟度に達している場合に使用できます。たとえば、悪用を簡素化・自動化することを目的としたエクスプロイトキットなどが該当します。

PoC — 以下のいずれかの要件に当てはまる場合に使用します。

  • 「概念実証(PoC)が公開されている。」

  • 「この脆弱性を悪用しようとする試みが報告されたという情報がない。」

  • 「脆弱性の悪用を簡素化するために使用される、公開済みのソリューションに関する情報がない。」

未報告 — PoCでも攻撃済みでもなく、未定義とも異なります(脅威インテリジェンスが利用できるシナリオで使用)。

これらの変更により、エクスプロイトの成熟度パラメーターの使い方が変わります。

変更はユーザーにどのような影響を与えるのか?

前のセクションで説明した内容に加えて、3つの脆弱性の例を確認し、CVSS 4.0で評価を試みながら、そのプロセスを解説します。

microsoft.chakracoreパッケージ バージョン1.10.1に影響するリモートコード実行

  • CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H — 7.5 High

  • CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:L/SI:L/SA:L — 7.6 High

攻撃はネットワーク経由で実行できるため、AV:Nです。仕様に従うと、ASLRなどの保護を回避する場合はAC:Hを使用します。この脆弱性について入手できる情報から、該当するケースだと考えます。低い特権または高い特権が必要であることを示す情報はないため、PR:Nです。悪用の成功には、別の人間のユーザーが存在する必要があります。ただし、そのユーザーが攻撃者のペイロードに能動的に関与する必要があるという十分な根拠はないため、UI:Pです。「脆弱性の悪用に成功した攻撃者は、影響を受けるシステムを制御できる」ため、機密性と完全性の両方が影響を受けます。したがって、VC:H、VI:H、VA:Nとなります。さらに、後続システム(このケースでは被害者のマシン)にも影響が及ぶと考えられます。ただし、その影響は攻撃者が被害者のマシンで持つ権限に依存するため、SC:L、SI:L、SA:Lとなります。

ipythonパッケージ バージョン8.10.0に影響するリモートコード実行

  • CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L — 4.2 Medium

  • CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N — 1.0 Low

パッケージの用途上、攻撃はローカルでしか実行できないため、AV:Lです。悪用にセキュリティメカニズムの回避は必要ありませんが、OSと特定の展開条件に左右されます(Pythonのインストールにデフォルトで含まれる`ctypes`ライブラリを無効にする必要があります)。このケースはAC:LおよびAT:Pに該当します。攻撃者はローカル環境へのアクセスも必要とするため、PR:Lです。被害者は「`ctypes`が利用できないWindows上のPython環境」で脆弱な関数を呼び出すことで、攻撃者のペイロードに能動的かつ意識的に関与する必要があります。したがって、UI:Aです。この脆弱性に関して入手できる情報に基づくと、脆弱なシステム内のCIAトライアドには影響せず、後続システムのみに影響すると考えられます。コマンドがホストシステム上で実行され、Pythonのインストール自体は直接影響を受けないためです。また、シェルコマンドは「現在のプロセスの範囲に限定」されるため、SC:LおよびSI:Lとなります。後続システムの可用性への影響を示す証拠はないため、SA:Nです。

org.jenkins-ci.plugins:rundeckパッケージ バージョン3.6.11に影響するクロスサイトスクリプティング

  • CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N — 5.4 Medium

  • CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N — 5.1 Medium

攻撃はネットワーク経由で実行でき、成功するために「エクスプロイト緩和技術」の回避や特別な展開設定は必要ありません。そのため、AV:N、AC:L、AT:Nです。ただし、攻撃者がエクスプロイトを実行するには有効なアカウントが必要です。保存型XSSであるため、被害者がペイロードに対して特定の操作を行う必要はなく、UI:Pとなります。攻撃者は被害者のブラウザー内のデータを読み取ったり変更したりできるため、後続システムに影響が及び、VC:N/VI:N/VA:N/SC:L/SI:L/SA:Nとなります。

公式の例は first.orgによって公開されています。

まとめ

CVSS 4.0によって、脆弱性評価プロセスが改善されることがすぐにわかります。ユーザーはセキュリティへの影響をより正確に特定できるようになり、セキュリティ課題の優先順位付けが改善されます。深刻度の分布については、評価の粒度が高まるため、CVSS 4.0によってよりバランスの取れた分布になると考えられます。このバランスにより、特定の深刻度範囲に脆弱性が過度に集中するのを防げます。また、特にCVSS 4.0では「各定性的な深刻度の値に対するスコア範囲がCVSS 3.1と同じに保たれる」ため、深刻度スコアが高い脆弱性は減少すると予想されます。

CVSS v4.0はいつ利用可能になるのか?

6月18日、Snyk Security Teamは、Snyk Open Sourceが新たに特定したすべてのセキュリティ脆弱性にCVSSバージョン4.0を割り当て始めました。新たな問題の深刻度をCVSS v4.0に基づいて評価するだけでなく、Snykはさまざまな製品ラインのワークフローで新しいベクター属性を段階的に公開し、新しい情報を直接利用する方法も順次更新していきます。

脆弱性の深刻度を評価する際のCVSSフレームワークの活用方法について詳しく知りたい方は、セキュリティ脆弱性のスコアリング入門ブログ記事をご覧ください。

参考資料:

CVSS 4.0:

CVSS 3.1:

続きを読む

blog feature ai lilac
Blog

エージェント型修正で脆弱性バックログをプルリクエストに変える

Evo Remediation Agentがオープンプレビューで利用可能になり、Evo Agentic AppSecに依存関係の自動解決機能が加わりました。AppSecチームは継続的な修正キャンペーンを実施できるようになりました

AI Background min crop
Blog

AIが、あなたが受け入れてきたあらゆるリスクを一気に顕在化させる:AI Security Panel: Unfilteredから得た7つの洞察

AIによって攻撃はより安価かつ高速になり、組織がすでに抱えているリスクが露呈しています。4人のセキュリティリーダーが、機械の速度に対応する防御と迅速な修復が今不可欠である理由を語ります。

blog feature snyk container custom base recommendations
Blog

Evo Agentic AppSecのご紹介:AI開発のスピードに追随するセキュリティ

AIを活用した開発は、従来のセキュリティワークフローを上回るスピードで進んでいます。SnykのAgentic AppSecは、セキュリティエージェントが脆弱性を継続的に検出、修正、検証し、人が基準を定められるようにします。