CVE と NVD：脆弱性の正規の情報源は分断されている？

CVE and NVD – A Weak and Fractured Source of Vulnerability Truth

2024/04/03 SecurityWeek — 共通脆弱性識別子 CVE (Common Vulnerabilities and Exposures) のリストと、それに関連する NVD (National Vulnerability Database) だが、脆弱性において一番に信頼すべき情報源とは、もはや考えられなくなっている。現在の CVE システムには改善の余地があり、また、改善すべきものであることを疑う者はいない。米国の DHS (Department of Homeland Security) に支援される、MITRE が管理する CVE リストを、NIST が NVD に統合し、その詳細データを充実させてきた。MITRE が CVE ID の採番や管理を行う一方で、サイバー防衛者たちが脆弱性を評価する上で、拠り所としてきたのが NVD である。


2024年2月の中旬以降から、NVD エントリーのトップに表示されるようになったメッセージは、「現時点において NIST は、NVD プログラムの課題に取り組み、改善されたツールや手法を開発するためのコンソーシアムの設立に取り組んでいる。この移行期間中、一時的に分析作業に遅れが生じるだろう」というものである。

※この記事の執筆中に NIST は情報を更新しており、アップデートに関しては、我々の議論の最後に補遺として掲載されている。

何が起こっているのだろうか？ 一体、どうすれば良いのだろうか？

問題点

脆弱性のデータを一元管理することは、そのデータベースのみに注目と信頼が集中するため、危険も伴う。もし脆弱性が発見されたとしても、そのデータベースに登録されていなければ、それは脆弱性ではないと判断される可能性があるからだ。

しかし、脅威インテリジェンス企業の Flashpoint による、2024年3月の報告によると、CVE 番号がなく NVD に登録されていない脆弱性が、100,000 件も確認されているという。さらに恐ろしいことに、これらの脆弱性のうち、330件 が悪用されてきたとされる。

その一方で、NVD に情報が掲載されていても、正規の脆弱性であるとは限らないというケースもある。cURL プロジェクトの創設／兼リード開発者である Daniel Steinberg は、2024年2月21日のブログで、「私は、CVE システムは機能しておらず、MITRE がホストしており、他の多くのデータベースにインポートされている既存の CVE のデータベースは、疑わしい内容や真っ赤な嘘でいっぱいだと主張し続けている」と述べている。Steinberg によると、cURL の誤った脆弱性に、CVE 番号が与えられていたという。

同様に、別の脆弱性 CVE (CVE-2023-52071) も誤情報であり、cURL は誤った CVE リストを独自に公開した：

匿名によるインチキ報告
2024年1月30日 Project curl Security Dismissal
VULNERABILITY
CVE-2023-52071 は、匿名の人物によって無作為に、あるいは悪意をもって報告され、公開された。私たちはどちらとは言えないし、その区別は私たちには重要なことではない。

脆弱性の検知漏れは、防御側のトリアージ作業に組み込まれない、目に見えない脆弱性となるため、深刻な脅威である。その一方で、脆弱性情報の誤検出は、直接的なセキュリティ上の脅威にはならない。しかし、報告を受けたプロバイダと、不必要な脆弱性のトリアージに従事するセキュリティ・チームの双方にとって、リソースの膨大な浪費になり得る。これらの、どちらの影響も、MITRE による CVE 番号付けと、それに続く NIST による脆弱性エンリッチメントの目的に反している。

脆弱性の検知漏れについて、ReversingLabs の CTO である Sasa Zdjelar  は、「正式な CVE が割り当てられたことのないアプリケーションは、安全／信頼／セキュアとは見なされない。CVE がないということは、”完璧なセキュリティ” を意味するのではなく、ソフトウェアや製品のセキュリティに対する、”ブラックボックス” 的なアプローチを意味する」と述べている。

MITRE は、独自の権限で CVE 番号を要求できる仕組みになっている。したがって、承認された CVE 番号発行機関 (CNA：Candidate Nomination Authorities) を増やすことで、脆弱性の検知漏れについては、少なくとも部分的に解決できるだろう。また、より多くの組織が CVE を生成できるようになれば、CVE リストには多数の CVE が掲載されることになり、検知漏れは少なくなるだろう。

しかし　CNA が増えることによって、誤った情報が取り込まれる可能性が増加し、一元化された信頼できる情報源の価値は低下する。cURL の言葉を借りれば、”匿名の人物が無作為に、あるいは悪意をもって”、誤った CVE を提出する可能性があるのだ。現在の 350 の CNA は、理論上では、自らの脆弱性を監視し報告できるコード製作者のうちの、ごく一部にすぎない。

また、リソースの問題により NIST は、NVD にヒットする全ての CVE 情報を、適切に充実させることが困難になっている。それは、NVD の脆弱性分析が停止している (実際には遅延ではない) ことの説明にもなる。現時点において、NIST の言うコンソーシアムについては、目的／潜在的なメンバー／規模／完成予定日などが、不明なままである。

現状

何かを改善するには、まず何が欠けているのかを理解しなければならない。

脆弱性の管理に NVD を使用する際の問題の一つは、それが事実上は、過去のデータであるという点だ。NVD システムに掲載されるということは、おそらくパッチが利用可能であるか、少なくとも回避策があるということを意味する。しかし、それは同時に、脆弱性の存在が知られているということでもあり、悪用が急速に進む可能性があるということでもある。どの脆弱性が特定の環境に関連し、そして、どの脆弱性の緊急性が最も高いのかを、セキュリティ・チームとして、全ての CVE に対して精査することは不可能だ。

NVD は、いくつかの方法で、このトリアージ・プロセスの支援を試みている。たとえば、CVSS (Common Vulnerability Scoring System) の深刻度評価 (1〜10までの数値が大きいほど悪用された場合の潜在的影響が大きい) や、製品マッピング (脆弱性の特定や製品やバージョンとの関連付け) により、CVE レコードを充実させている。また、CISA の KEV (Known Exploited Vulnerabilities) カタログに登録された場合には、カタログへのリンクを提供している。KEV カタログとは、悪用されたことが判明している脆弱性の別個のリストであり、この情報は、トリアージ・プロセスにおける緊急度の判断材料となる。

しかし、このプロセスには、２つの弱点がある。第一に、脆弱性が CVE リストに含まれていなければ、NVD にも掲載されないため、少なくとも CVSS を充実させることはできない。第二に、KEV リストに登録されていなければ、その脆弱性は緊急度が高いものだと見なされない。

この問題に対して、別のデータベースが解決を試みている。FIRST Org が運営する Exploit Prediction Scoring System (EPSS) だ。これは、過去の出来事に関する機械学習を用いて、任意の CVE について悪用される可能性の高さを、0〜1 の間のスコアで測定するものだ。

そのため、MITRE の CVE で CVSS が高く、NIST の NVD に対応し、さらに FIRST Org の EPSS スコアが高く、KEV リストに含まれる可能性がある場合は、緊急な対応が必要な脆弱性であるということになる。

しかし、２つの問題が残っている。第一に、CVE リストは不完全であり、信頼性に問題がある。第二に、ユーザーの特定の実装が、この特定の悪用に必要な手順に対して、脆弱であるかどうかを示すものがないということだ。

一例として、OpenSSF のチーフアーキテクトである Dana Wang は、「CVE システムには、脆弱性とオープンソース・ソフトウェア・パッケージの特定のバージョンおよび、その修正ステータスを正確に関連付けるために必要な粒度が欠けている。その結果として、ノイズとシグナルの比率が大きくなっている」と指摘している。

最後の問題点を解決するのに役立ちそうなのが、MITRE の ATT&CK フレームワークという、さらに別のデータベースだ。ATT&CK は、攻撃で使われる様々な TTPs (戦術／技術／手順) を記述しているものだ。ATT&CK は、これらの攻撃を特定の CVE に関連付けるものではないが、新しいプロジェクトである MITRE Engenuity では、CVE を TTP にマッピングしようとしている。

それにより、ユーザーは、CVE が割り当てられた脆弱性と悪用に必要な TTP を比較して、ユーザー自身の環境が、その脆弱性の影響を受けやすいかどうかを測定できる。このデータベースでは、Wang が懸念するノイズを減らすことはできないが、シグナル部分を増やすことができる。

全てのボックスにチェックが入るなら、即座にパッチを当てる必要のある脆弱性が把握できる。しかし、問題なのは、CVE が与えられている脆弱性だけであること、言葉を換えれば、詳細情報が分散しているということだ。

Anomali の脅威リサーチ担当 VP である Steve Benton は、「私が何度も遭遇してきたのは、CVE/CVSS をリスク判断や対応の唯一の指針として、使おうとすることから生じる問題だ。CVE/CVSS システムは、スコアリングに基づく比較状況を提供し、評価の初期優先順位を設定することができる。しかし、この評価では、組織にとっての優先順位を決定するために、それとは別の、いくつかの要素も考慮する必要がある」と指摘する。

Zdjelar は、脆弱性データの分断された性質と、本質的な要素を見つけ組み合わせることの難しさを強調している。彼は、「もし CVE システムが最適化されていれば、組織が一般に公開された脆弱性を特定し、優先順位を付け、解決するのを支援するソリューションの販売に成功している企業は、これほど多くはなかっただろう。実際に、脆弱性に関する全ての関連情報を把握している、単一の包括的な情報源は存在しない」と述べている。

MITRE と NIST は、両者とも脆弱性に関する、こうした問題の解決に取り組んでいるようだが、詳細は明かされていない。

アシストしようとする試み

しかし、現行の CVE システムには多くの良い点があり、多くのことが成し遂げられてきた。したがって、全否定すべきではない。たとえば、CVE システムは、完全な情報公開に関する議論に先行するかたちで、つまり、脆弱性が一般に知られるようになる以前に、ベンダーにパッチを当てるための妥当な時間を与えるという点で、きわめて重要な役割を果たしてきた。

Panaseer の Security Evangelist である Marie Wilcox は、「CVE システムは完璧ではないが、非常に貴重なものだ。新しい脆弱性が定期的に出現し、タイムリーなアップデートの重要性が高まる一方で、多くの攻撃者は、組織がパッチを当てていないことを知っているため、古い有名な CVE を狙ってくる。脆弱性に関する、最新かつ完全な情報を手に入れることが理想だが、NVD が提供するものには、依然として大きな価値がある。このデータソースを持つことは、企業が防御を改善し、潜在的なカバー・ギャップを特定し、効果的にリソースを配置するのに役立つ」と述べている。

さらなる改善案も、数多く示されている。Critical Start の Threat Hunter Team Lead である Tyler Bellue は、「CVSS スコアリングの背後にある透明性と方法論を強化し、脆弱性の実際的なリスクと影響を、いま以上に反映させることが可能だ。さらに、研究者／ベンダー／防衛者による協力的な環境を促進することで、共有される情報の適時性と質を向上させることができる。最終的には、より強固で迅速な脆弱性管理のエコシステムにつながる」とコメントしている。

また、FIRST のような組織は、独自の追加機能により状況を改善しようとしている。Wang の OpenSSF もそのひとつだ。彼女は、「MITRE と NIST の実績は認めるべきだ。しかし、解決策は両者を超えるものでなければならない。システムの改善には、MITRE／NIST／業界リーダー／オープンソース・コミュニティの間での、継続的な対話が必要だ。コンセンサスの構築には、時間をかけた協力的な取り組みが必要だ」と提案している。

その一方で OpenSSF は、オープンソース・プロジェクト向けに特別に設計された、 Open Source Vulnerability (OSV) システムの採用を奨励している。このシステムは、OpenSSF OSV スキーマ／脆弱性スキャナ／オープンソース脆弱性データベースで構成されている。OSV スキーマは、脆弱性を正確に概説し、特定のオープンソース・パッケージのバージョンやコミット・ハッシュと整合させ、人間や機械に判読可能なデータ形式を提供するものだ。このデータベースは、NVD などの約 20の脆弱性データソースからの脆弱性情報を集約している。

それにより、多くの OSS の脆弱性の問題は、間違いなく解決されるだろう。しかし、全ての脆弱性のための、単一の中心的なデータベースという概念が、さらに減退することにもなるだろう。

OpenSSF だけではない。Anchore は 2024年3月8日のブログで、NIST が CVE に関する情報更新を、2024年2月中旬に停止したことを指摘している。同社は「2月12日以降から、何千もの CVE ID が NVD による分析記録なしに公表された。2024年に入ってから、合計 6,171の CVE ID があるが、NVD が情報を追加したのは 3,625 件だけである。2024年に追加された CVE の 42%を占める、残りの 2,546件は、情報が更新されないままとなっている」と指摘する。

Anchore が指摘するのは、NIST は取り組みを再編成しているが、それには時間がかかり、いま以上にユーザー企業は脆弱化していくという状況である。

このギャップを埋めるために、NIST は、独自の新しいプロジェクトを立ち上げた。Anchore のセキュリティ担当副社長である Josh Bressers は、「このデータは、CC0 でライセンスされており、誰もが何にでも使うことができる。この新しいデータベースには、現時点で 500以上のエントリーが登録されている。オープンソース・コミュニティの力を活用するかたちで、NVD が復活するケースが考えられる。あるいは、他のプロジェクトが、現在の NVD のタスクを引き継ぐケースも考えられる。そのような場合において、このプロジェクトを維持し続けることを、私たちは期待している」と述べている。

CVE の裂け目

MITRE は、政府から多額の資金援助を受けているが、非営利で活動する民間の組織である。その一方で NIST は、政府機関であり、商務省の一部である。政府は、新たな脆弱性の収集や番号付けには関与しないが、改善努力の説明や優先順位付けには、その重みと権威を提供できるというのは、おそらく正しいバランスなのだろう。そのため、民間が収集した脆弱性の CVE リスト (“リスト” と呼ばれていることに注意) と、脆弱性と関連情報を扱う NVD は、正規の脆弱性情報の強固な基盤となっている。

しかし、リストもデータベースも、その成果を上げることができないでいる。これは設計の失敗ではなく、リソースの失敗に起因する。MITRE は全ての新しい脆弱性のリストを作成できず、NIST は全ての脆弱性の充実したデータベースの提供に失敗した。NIST は、情報化プロセスのための、リソースの問題を抱えている。

問題点の１つ目は、MITRE が脆弱性のコレクションを改善することである。これは CNA の数を増やすことで達成できるだろう。しかし、どこで止めるべきなのだろう？全ての脆弱性の収集と、CVE 採番リクエストのバランスを、どのように取るべきなのだろうか？ なぜなら、収集源を増やすことで、誤検出の可能性が増えるからだ。

一方で Zdjelar は、「脆弱性に対して、CVE 番号を付与できる CVE 番号付与機関 (CNA) として登録されているのは、約 350の組織だけだ。これは、コードを生産している企業数のごく一部である。CVE システムへの普遍的な参加の欠如と、CVE 番号の取得に時間がかかるプロセスは、CVE システムの範囲と有用性を大きく狭めている」と述べている。

CNA の数を増やすことで、MITRE への提出物の価値が下がるというトレンドが生まれる。当初、NVD  に登録された脆弱性は、ベテランの研究者や定評のある実務家たちが報告したものであり、業界への彼らの貢献は、CVE の付与により認められてきた。しかし、ソフトウエア・セキュリティが支持されるようになると、新進の研究者たちがキャリアをスタートさせる手段として、NVD と CVE のクレジットを利用するようになった。

報告された全ての脆弱性を、MITRE は CVE リストに取り込もうとして、 自身と NIST のリソース不足がボトルネックとして浮上してきた。Sonatype の CTO である Brian Fox は、「このような低品質の報告の氾濫により、NVD プログラム内の課題が悪化し、新しい報告書の分析に、１カ月もの遅れが生じる結果となった」と説明する。

第三者である複数の機関は、独自の “充実した” 脆弱性データベースを開発することで、負担を軽減しようとしている。しかし、このような試みは、政府の権威に裏打ちされた正規の一元的な情報源を持つ価値を弱めるものでもある。現時点におけるユーザーたちは、個々の脆弱性を精査し、修復に必要な情報を見つけるために、複数の異なるデータベースを調べるという状況に陥っている。

それは、最適な状態とは程遠いものである。政府としては、NIST のアドバイザリに従うことを推奨している。Chainguard の創設者兼 CEO の Dan Lorenc は、「分散型グループが、NIST の主な価値に取って代わることが可能とは思わない。私たちにとって必要なのは、たとえ間違いが含まれるとしても、政府から信頼されてスコアリングを行う、センタライズされたグループである。コミュニティによる修正というメカニズムもあるが、それは政府が信頼するデータとは言えない。政府が本当に信頼できるのは、政府から提供されたデータだけだ。このデータを使わなければならないという基準や規制は、全てここから来ている」とコメントしている。

例として、SEC の情報開示ルールを考えてみよう。Lorenc は、「NIST が間違ったから、脆弱性スキャンを見落としたというのと、あなたのチームや他の誰かが間違ったから、脆弱性スキャンを見落としたというのでは、見え方がずいぶん違ってくる。つまり、セキュリティの観点からは完璧なソリューションであっても、コンプライアンスや規制の観点からは、完璧なソリューションではないということだ」と述べている。

要するに、米国における効果的なセキュリティとコンプライアンスにおいては、政府が支援する単一かつ正規の、脆弱性に関する中央情報源が必要だということだ。NIST の現在のリソースで、これを提供することは不可能であり、同機関は “コンソーシアム” の支援を求めているという。それを政府が達成し、政府による唯一かつ正規の情報源であり続けることが可能かどうかは、まだ分からない。しかし、早急に対策を講じる必要性があることは確かである。

追記：4月2日に、NIST は以下の情報を更新した：

NIST が管理する NVD は、コンピュータのセキュリティを脅かす可能性のあるソフトウェア／ハードウェアの脆弱性に関する情報のリポジトリであり、国家のサイバーセキュリティ・インフラの重要な一部だ。

NVD に新たに提出され、分析待ちの脆弱性は溜まっていく一方だ。これは、ソフトウェアの増加による脆弱性の増加／省庁間のサポートの変化などの、様々な要因に基づいている。

我々は現在、最も重要な脆弱性の分析を優先して行っている。加えて、脆弱性分析のサポートを強化するために、省庁間のパートナーとも協力し、NIST のスタッフも増員し、この業務に取り組んでいる。

また、NVD を改善するための研究を共同で行うための、産業界／政府機関／その他のステークホルダー組織などから構成されたコンソーシアムの設立など、この課題に対する長期的な解決策も検討している。

これらの計画が進展すれば、さらに情報を提供する予定である。NIST は、NVD の継続的な支援と管理に尽力する。

NVD では、すでに相当な量の CVE が放置されていて、それらに対処するのは、とても難しいだろうと思わざるを得ません。もともと、NVD へのエントリーでは、各種のメタデータが追加されるまで、時間が掛かっていました。つまり、対応が遅いわけですが、その背景には、リソース不足があったのかもしれません。 いったい、どうなってしまうのでしょうか？ 以下は、この件に関する履歴です。