CVE IDの付与可能範囲が拡大、従来出来なかったクラウドサービスもOKに: NECセキュリティブログ

Tweet
Share

2024年11月29日

NECサイバーセキュリティ戦略統括部　セキュリティ技術センターの郡です。最近、MicrosoftやGoogleなど、クラウドベンダーが自社のクラウドに関する脆弱性に対してCVE ID付与を開始するとの報道がありました new window [1] [2]。このニュースを見て、「そういえばクラウド関係の脆弱性にはCVEが無かったな」と気づかれた方もいらっしゃると思います。実は、以前はクラウド関係の脆弱性にCVE IDを付与することはそもそも許可されていませんでした。2024年8月に発行された新ルールにより、この制限が撤廃されるなど大きな変化を迎えています。今回はこの変更点に関して簡単に紹介いたします。

CVE付与の決まりを定めたCVE Numbering Authority (CNA) Operational Rulesとその変更

CVE(Common Vulnerabilities and Exposures)は、非営利団体MITREが管理する脆弱性識別の仕組みで、個別の脆弱性に対して一意の識別子を付与することにより、脆弱性の情報共有や相互参照などを円滑に行うことを目的にしています。CVEプログラムは今年で25周年を迎え、自社製品やサービスに発見された脆弱性に対して、CVE IDを採番可能と認定された組織であるCNAの数は2024年9月末時点で400を超えているなど、大半のCVE ID付与はそれぞれの企業や組織によって実施されるようになりました PDF [3]。このように、CVE ID付与の仕組みは段々と脱中央集権化しています。(NECもCNAとして活動しています。)
ただ、それぞれの組織が好き勝手にCVE IDを付与しては混乱を生みますので、付与やCNAの決まりごとを定義したルールが存在しています。これがCVE Numbering Authority (CNA) Operational Rulesです。このルールはたびたび改訂されており、2024年5月に承認されたバージョン4.0が、8月に正式発効されました new window [4]。様々な変更点がありますが、最も大きな点の一つは、CVEプログラムでも強調されている以下の部分と思われます [5]。

ルールは現在、技術の種類に依存しません：
4.2.2.4 CNAは技術の種類（例：クラウド、オンプレミス、ハイブリッド、人工知能、機械学習）のみを基準として割り当てを決定してはなりません。
(原文：The rules are now agnostic to the type of technology:
4.2.2.4 CNAs MUST NOT consider the type of technology (e.g., cloud, on-premises, hybrid, artificial intelligence, machine learning) as the sole basis for determining assignment.)

上記の通り、4.0ではクラウドやオンプレミス、人工知能などによる技術観点でのCVE ID付与基準は撤廃されました。では、以前のバージョンではどのような記述だったのでしょうか。4.0で削除された記述を見てみましょう PDF [6]。

7.4.5 CNAは、影響を受ける製品やサービスが以下の条件を満たす場合に脆弱性にCVE IDを割り当ててはなりません:
a. CNAが所有していない
b. 顧客によって管理されていない
(原文：7.4.5 CNAs MUST NOT assign a CVE ID to a vulnerability if the affected product(s) or service(s):
a. Are not owned by the CNA, and
b. Are not customer controlled.)

当該CNAのスコープ外に割り当てられないのは当然として、顧客による管理とは何を指していたのでしょうか。これは当該製品の利用者がその製品をアップデートするなど、能動的な修正を要することを意味していました。つまり、SaaSのようなクラウド製品で、ベンダーが修正を適用すると自動的に顧客の環境も最新となる場合、CVEを付与してはならないと以前は決まっていたのです。
ただし、CVEの半分近くをMITREが付与していた当時に、技術の線引き無しのID付与の仕組みを構築することは非現実的だったと思われ、前述したCNA数の増加がこのルール改訂を手助けしたと考えています。
なお、冒頭触れたMicrosoftの決定も、このルール変更によるものと発表されています new window [7]。

CVEの範囲外となるセキュリティ上の問題

ここで気になるのは、近年注目が集まっているAI関連の脆弱性はどうなるのだろうか、という点です。CVEプログラムは次のように脆弱性を定義していますが new window [4]、

1. 機密性、完全性、または可用性に悪影響を及ぼす形で悪用される可能性のある、製品内の一つ以上の弱点の事例
2. 明示的または暗黙的なセキュリティポリシーの違反を許す条件や行動の集合
(原文：
1. An instance of one or more weaknesses in a product that can be exploited, causing a negative impact to confidentiality, integrity, or availability
2. A set of conditions or behaviors that allows the violation of an explicit or implicit security policy)

AI特有の一部問題はCVEの範囲外にある可能性が指摘されています new window [8]。

機密性、完全性、または可用性に影響を及ばさず、セキュリティポリシーで許可されている行動であるならCVEの範囲外となります。CVEプログラムが指摘するように [8]、人種や性別に偏見を持った回答が得られるケースは無問題ではありませんが、CVEには対応していません。
CVEプログラムは、今後議論を深めるとともに、AI関連のCVE付与に関する考慮事項などを提供していくと発表しており new window [8]、AIとCVEの関係はもう少し見守る必要があるかもしれません。

その他4.0で追加されたCVE付与に関する記述

4.0では、具体的な脆弱性判定事例が複数追加され、「この場合はCVE IDをゲット出来るのか？」という疑問に答えるよう記述がなされています。いくつか見ていきましょう。

4.1.4 安全でないデフォルト設定は脆弱性と見なされるべきです。
(原文：4.1.4 Insecure default configuration settings SHOULD be determined to be Vulnerabilities.)

デフォルトの設定に関しても、不備があれば脆弱性として判断するよう推奨されています。「仕様です。」対策でしょうか。

4.1.5物理攻撃は、特定のセキュリティ機能、サポートされている主張、または物理攻撃に対して製品を防御するポリシーがない限り、脆弱性として判断されるべきではありません。
(原文：4.1.5 Physical attacks SHOULD NOT be determined to be Vulnerabilities unless there is a specific security feature, supported claim, or policy that defends the Product against the physical attack.)

物理的な攻撃に関して、保護をバイパスするといった過程などがないならば、脆弱性と判定しないとされています。管理用シリアルコンソールに物理接続出来るだけでは、脆弱性とは言い切れません。

4.1.8一般的な目的で故意に作成された悪意のあるコードは、脆弱性として判断してはなりません。
(原文：4.1.8 General purpose deliberately malicious code MUST NOT be determined to be a Vulnerability.)

悪意を持って作成されたコードはCVE IDのスコープ外です。
ただし、

4.1.9トロイの木馬、バックドア、または類似のサプライチェーンの侵害など、悪意のある形に改変された製品は、脆弱性であると判断される可能性があります。
(原文：4.1.9 Products that have been modified to become malicious, for example, trojan horses, backdoors, or similar supply chain compromises, MAY be determined to be a Vulnerability.)

とあり、正常に動作していた製品が何らかの意図しない改変を受けた場合は、脆弱性として判断できる場合があります。

4.1.12 製品の依存関係の更新行為は、依存関係に脆弱性があるかどうかにかかわらず、脆弱性と判断されてはなりません。例えば、ライブラリ内の脆弱性に対処するためにライブラリを更新することは、そのライブラリを使用する製品において新たな脆弱性とされてはならず、製品の脆弱性アドバイザリはライブラリ内の脆弱性のCVE IDを参照するべきです。4.2.13を参照してください。
(原文：4.1.12 The act of updating Product dependencies MUST NOT be determined to be a Vulnerability, regardless of whether the dependencies have Vulnerabilities. For example, updating a library to address a Vulnerability in that library MUST NOT be determined to be a new Vulnerability in a Product that uses the library, and a Vulnerability advisory for the Product SHOULD reference the CVE ID for the Vulnerability in the library. See 4.2.13.)

使用しているライブラリに脆弱性があって、そのコンポーネントをアップデートすれば解決するような場合は、新たな脆弱性として識別してはいけないとされています。4.2.13によると、これは脆弱なコードを共有しているかを基準に判断します。

いくつか抜粋して追加された記述を見てみました。本ルールはあくまでCVE ID付与に関する決まりであって、組織によっては脆弱性のスコープをより広く設定している場合もあると思われます。バグバウンティでCVE IDのゲットを狙っている人は、一度CNAルールを参照してみてください。

まとめ

今回はCNAルールが4.0に改訂され、クラウドサービスがCVE ID付与可能になったなど、CVEプログラムに大きな変更があったことをお伝えしました。記事中言及したように、AIのような問題もまだ残っていますが、CVEに無関係と言い切れるベンダーはほとんどないのが現状と考えます。これまでCVEを考える必要のなかったベンダーが、対処を必要とする場面も出てくるでしょうし、対象が拡大したため、右肩上がりに増加していたID数の傾向もこのまま同様に推移していくと予想されます。
今回の変更では他にも様々な点がより分かりやすく明確になりました。これらは今回省略しましたが、気になる方は是非CVEプログラムのサイトにアクセスしてみてください new window [4]。脆弱性研究者やバグバウンティ関係者だけでなく、CVEの仕組みを改めて考える契機にしていただけると幸いです。