一般的な脆弱性と露出

共通脆弱性識別子（CVE ）システムは、公に知られている情報セキュリティの脆弱性と露出に対する参照方法を提供します。 ^[1]MITRE Corporationが運営する米国の国家サイバーセキュリティFFRDCは、米国国土安全保障省の米国国家サイバーセキュリティ部門からの資金提供を受けてシステムを維持しています。^[2]このシステムは1999年9月に正式に一般公開されました。 ^[3]

セキュリティコンテンツ自動化プロトコルはCVEを使用しており、CVE IDはMitreのシステムと米国の国家脆弱性データベースに掲載されています。^[4]

CVE 識別子

MITRE Corporation のドキュメントでは、CVE 識別子 (「CVE 名」、「CVE 番号」、「CVE-ID」、「CVE」とも呼ばれる) を、公開されているソフトウェアパッケージ内の既知の情報セキュリティ脆弱性の一意の共通識別子として定義しています。歴史的に、CVE 識別子は「候補」(「CAN-」) のステータスを持ち、その後エントリ (「CVE-」) に昇格できましたが、この慣行は 2005 年に終了し^[5]^[6]、現在ではすべての識別子が CVE として割り当てられています。CVE 番号の割り当ては、それが正式な CVE エントリになることを保証するものではありません (たとえば、CVE がセキュリティ脆弱性ではない問題に不適切に割り当てられたり、既存のエントリと重複したりする場合があります)。

CVE は CVE 番号付与機関 (CNA) によって割り当てられます。^[7]以前は一部のベンダーが CNA として活動していましたが、その名前と指定は 2005 年 2 月 1 日まで作成されていませんでした。^[8] CVE 番号の割り当てには主に 3 つの種類があります。

マイターコーポレーションは編集者および主要CNAとして機能します
さまざまな CNA が自社製品に CVE 番号を割り当てています (例: Microsoft、Oracle、HP、Red Hat)
CERTコーディネーションセンターなどのサードパーティコーディネータは、他のCNAでカバーされていない製品にCVE番号を割り当てることがあります。

脆弱性または潜在的な脆弱性を調査する場合、早い段階で CVE 番号を取得すると役立ちます。CVE 番号は、MITRE または NVD CVE データベースにしばらく (数日、数週間、数か月、場合によっては数年間) 表示されない場合があります。これは、問題が禁止されている (CVE 番号は割り当てられているが、問題が公開されていない) か、リソースの問題により MITRE によってエントリが調査および記述されていない場合に発生します。早期に CVE 候補になることの利点は、将来のすべての通信で CVE 番号を参照できることです。オープンソースプロジェクトの問題の CVE 識別子を取得する方法については、Red Hat ^[9]およびGitHubから入手できます。^[10]

CVE は公開されているソフトウェア用です。広く使用されている場合は、ベータ版やその他のプレリリース版も含まれます。商用ソフトウェアは「公開」カテゴリに含まれますが、配布されていないカスタムビルドソフトウェアには通常 CVE は付与されません。さらに、サービス (Web ベースの電子メールプロバイダーなど) には、サービスで見つかった脆弱性 (XSS 脆弱性など) に対する CVE は割り当てられません。ただし、問題が公開配布されている基盤ソフトウェア製品に存在しない場合は除きます。

CVE データフィールド

CVE データベースにはいくつかのフィールドが含まれています。

説明

これは問題の標準化されたテキスト説明です。一般的なエントリは次のようになります。

** 予約済み ** この候補は、新しいセキュリティ問題を発表する際に使用する組織または個人によって予約されています。候補が公開されると、この候補の詳細が提供されます。

これは、エントリ番号が Mitre によって問題用に予約されているか、CNA によって番号が予約されていることを意味します。したがって、CNA が CVE 番号のブロックを事前に要求すると (たとえば、Red Hat は現在 500 ブロックで CVE を要求しています)、CVE 自体は CNA によってしばらく割り当てられない可能性がありますが、CVE 番号は予約済みとしてマークされます。CVE が割り当てられるまで、Mitre がそれを認識し (つまり、禁輸措置が解除され、問題が公開される)、Mitre が問題を調査して説明を作成するまで、エントリは「** 予約済み **」として表示されます。

レコード作成日

これはエントリが作成された日付です。Mitre によって直接割り当てられた CVE の場合、これは Mitre が CVE エントリを作成した日付です。CNA (Microsoft、Oracle、HP、Red Hat など) によって割り当てられた CVE の場合、これも CNA ではなく Mitre によって作成された日付です。CNA が事前に CVE 番号のブロックを要求する場合 (たとえば、Red Hat は現在 500 ブロックで CVE を要求しています)、CVE が CNA に割り当てられたエントリ日付です。

廃止されたフィールド

以下のフィールドは以前は CVE レコードで使用されていましたが、現在は使用されなくなりました。

フェーズ: CVE のフェーズ (例: CAN、CVE)。
投票: 以前は、理事会のメンバーが、CAN を受け入れて CVE に変換するかどうかについて賛成または反対の投票を行っていました。
コメント: 問題に関するコメント。
提案: 問題が最初に提案された日時。

構文の変更

^{CVE-YEAR-9999を超えるCVE ID（別名「CVE10k問題」 [11]} ）をサポートするために、2014年にCVE構文に変更が加えられ、2015年1月13日に発効しました。^[12]

新しい CVE-ID 構文は可変長で、次の内容が含まれます。

CVE プレフィックス + 年 + 任意の数字

可変長の任意の数字は 4 つの固定数字から始まり、暦年で必要な場合にのみ任意の数字で拡張されます。たとえば、CVE-YYYY-NNNN で、必要に応じて CVE-YYYY-NNNNN、CVE-YYYY-NNNNNN などになります。これは、以前に割り当てられた CVE-ID (すべて最低 4 桁) を変更する必要がないことも意味します。

CVE 分割と統合

CVEは、セキュリティ問題ごとに1つのCVEを割り当てようとしますが、多くの場合、これは非常に多くのCVEにつながります（たとえば、が使用されていないhtmlspecialchars()か、でファイルが安全でない方法で作成されたために、PHPアプリケーションで数十のクロスサイトスクリプティングの脆弱性が見つかる場合など/tmp）。^[13]

これに対処するため、ガイドライン（変更される可能性があります）では、問題を分割して別々の CVE 番号に統合することについて説明しています。一般的なガイドラインとしては、まず統合する問題を検討し、次に脆弱性の種類（バッファオーバーフローとスタックオーバーフローなど）で問題を分割し、次に影響を受けるソフトウェアバージョンで分割し（たとえば、1 つの問題がバージョン 1.3.4 から 2.5.4 に影響し、もう 1 つの問題がバージョン 1.3.4 から 2.5.8 に影響する場合は分割）、最後に問題の報告者で分割します（たとえば、Alice が 1 つの問題を報告し、Bob が別の問題を報告した場合、問題は別々の CVE 番号に分割されます）。^[13]

別の例として、アリスは、ExampleSoft ウェブブラウザのバージョン 1.2.3 およびそれ以前のバージョンに /tmp ファイル作成の脆弱性があると報告しています。この問題に加えて、他の/tmpファイル作成の問題もいくつか見つかりました。場合によっては、これは 2 人の報告者とみなされることがあります (したがって、2 つの別々の CVE に分割されるか、アリスが ExampleSoft で働いていて、ExampleSoft の社内チームが残りの問題を見つけた場合は、1 つの CVE にマージされる可能性があります)。逆に、ボブが ExampleFrameWork の ExamplePlugin に 145 件の XSS 脆弱性を見つけた場合など、影響を受けるバージョンに関係なく、問題はマージされ、1 つの CVE にマージされる可能性があります。^[13]

CVE識別子を検索

Mitre CVE データベースは CVE リスト検索で検索でき、NVD CVE データベースは CVE および CCE 脆弱性データベースの検索で検索できます。

CVE の使用

CVE 識別子は、脆弱性を識別するために使用することを目的としています。

共通脆弱性識別子（CVE）は、公に知られている情報セキュリティの脆弱性の共通名（つまり、CVE識別子）の辞書です。CVEの共通識別子により、個別のネットワークセキュリティデータベースやツール間でデータを共有しやすくなり、組織のセキュリティツールの適用範囲を評価するための基準が提供されます。セキュリティツールの1つからのレポートにCVE識別子が組み込まれている場合は、1つ以上の個別のCVE互換データベースの修正情報に迅速かつ正確にアクセスして、問題を修正できます。^[14]

脆弱性に対して CVE 識別子が割り当てられたユーザーは、関連するセキュリティレポート、Web ページ、電子メールなどにその識別子を必ず記載することが推奨されます。

CVE 割り当ての問題

CNA規則の第7条によれば、セキュリティ脆弱性に関する報告を受けたベンダーは、それに関して完全な裁量権を持っています。^[15]これは利益相反につながる可能性があります。ベンダーは最初からCVE割り当てを拒否することで欠陥を修正しないままにしようとする可能性があり、この決定はMitreでは覆すことができません。2023年に発表された「!CVE」（CVEではない）プロジェクトは、プロジェクトの専門家パネルによって有効であると判断される限り、ベンダーによって拒否された脆弱性を収集することを目的としています。^[16]

CVE識別子は、偽の問題やセキュリティ上の影響のない問題にも付与されてきました。^[17]これに対応して、多くのオープンソースプロジェクトが自らのプロジェクトのCVE番号付与機関（CNA）となることを申請しました。^[18]

参照

参考文献

^ Wu, Xiaoxue; Zheng, Wei; Chen, Xiang; Wang, Fang; Mu, Dejun (2020). 「CVE 支援による大規模セキュリティバグレポートデータセット構築方法」.システムおよびソフトウェアジャーナル. 160 : 110456. doi :10.1016/j.jss.2019.110456. S2CID 209056007.
^ 「CVE – Common Vulnerabilities and Exposures」。Mitre Corporation。2007年 7 月 3 日。2009年6 月 18 日に閲覧。CVEは、米国国土安全保障省の国家サイバーセキュリティ部門が後援しています。
^ 「CVE - 履歴」cve.mitre.org . 2020年3月25日閲覧。
^ 「CVE - Common Vulnerabilities and Exposures (CVE)」cve.mitre.org。2013年4月7日時点のオリジナルよりアーカイブ。2013年4月8日閲覧。
^ 「CVE - よくある質問」cve.mitre.org . 2021年9月1日閲覧。
^ Kouns, Jake (2009年8月13日). 「Reviewing(4) CVE」. OSVDB: Everything is Vulnerable . 2021年9月1日時点のオリジナルよりアーカイブ。 2021年9月1日閲覧。
^ 「CVE - CVE 番号付与機関」。Mitre Corporation。2015年 2 月 1 日。2024 年3 月 5 日に閲覧。
^ 「CVE - CVE ブログ「私たちの CVE ストーリー: CVE プログラムの古代史 - Microsoft セキュリティレスポンスセンターには予知能力があったのか?」 (ゲスト著者)」。cve.mitre.org。2021年9 月 17 日閲覧。
^ 「CVE OpenSource Request HOWTO」。Red Hat Inc. 2016 年 11 月 14 日。2019年5 月 29 日閲覧。要件に応じて、リクエストを行う方法はいくつかあります。
^ 「GitHub セキュリティアドバイザリについて」。GitHub 。 2021年12月23日閲覧。GitHubセキュリティアドバイザリは、共通脆弱性識別子（CVE）リストを基盤として構築されています。
^ Christey, Steven M. (2007 年 1 月 12 日). 「CVE - CVE-10K の問題」. cve.mitre.org . The MITRE Corporation . 2023 年11 月 25 日閲覧。
^ 「CVE - CVE ID 構文の変更」cve.mitre.org . 2016 年 9 月 13 日。
^ abc 「CVE 抽象化コンテンツの決定: 根拠と適用 (アーカイブ)」。The Mitre Corporation。2005年 6 月 15 日。2024 年1 月 6 日に閲覧。
^ 「CVE - CVEについて」cve.mitre.org . 2015年7月28日閲覧。
^ 「CVE 番号付与機関のルール - 割り当てルール」(PDF)。MITRE Corporation。2020 年 2 月 1 日。pp. 13–15。2023年12 月 6 日に閲覧。
^ Edge, Jake (2023 年 12 月 5 日). 「!CVE による CVE の補足」. lwn.net .
^ Edge, Jake (2023年9月13日). 「偽のCVE問題」. lwn.net .
^ 「CVE 番号の転換点」LWN.net 2024 年 2 月 14 日。

外部リンク

公式サイト
国家脆弱性データベース (NVD)
NVD の共通構成列挙 (CCE)
相関および集約された脆弱性データベース vFeed - SQLite データベースと Python API
サイバーウォッチ脆弱性データベース 2018年8月22日アーカイブWayback Machine、サードパーティ
企業が IT セキュリティ監査サービスについて知っておくべきことは何ですか?

[1] Wu, Xiaoxue; Zheng, Wei; Chen, Xiang; Wang, Fang; Mu, Dejun (2020). 「CVE 支援による大規模セキュリティバグレポートデータセット構築方法」.システムおよびソフトウェアジャーナル. 160 : 110456. doi :10.1016/j.jss.2019.110456. S2CID 209056007.

[2] 「CVE – Common Vulnerabilities and Exposures」。Mitre Corporation。2007年 7 月 3 日。2009年6 月 18 日に閲覧。CVEは、米国国土安全保障省の国家サイバーセキュリティ部門が後援しています。

[3] 「CVE - 履歴」cve.mitre.org . 2020年3月25日閲覧。

[4] 「CVE - Common Vulnerabilities and Exposures (CVE)」cve.mitre.org。2013年4月7日時点のオリジナルよりアーカイブ。2013年4月8日閲覧。

[5] 「CVE - よくある質問」cve.mitre.org . 2021年9月1日閲覧。

[6] Kouns, Jake (2009年8月13日). 「Reviewing(4) CVE」. OSVDB: Everything is Vulnerable . 2021年9月1日時点のオリジナルよりアーカイブ。 2021年9月1日閲覧。

[7] 「CVE - CVE 番号付与機関」。Mitre Corporation。2015年 2 月 1 日。2024 年3 月 5 日に閲覧。

[8] 「CVE - CVE ブログ「私たちの CVE ストーリー: CVE プログラムの古代史 - Microsoft セキュリティレスポンスセンターには予知能力があったのか?」 (ゲスト著者)」。cve.mitre.org。2021年9 月 17 日閲覧。

[9] 「CVE OpenSource Request HOWTO」。Red Hat Inc. 2016 年 11 月 14 日。2019年5 月 29 日閲覧。要件に応じて、リクエストを行う方法はいくつかあります。

[10] 「GitHub セキュリティアドバイザリについて」。GitHub 。 2021年12月23日閲覧。GitHubセキュリティアドバイザリは、共通脆弱性識別子（CVE）リストを基盤として構築されています。

[11] Christey, Steven M. (2007 年 1 月 12 日). 「CVE - CVE-10K の問題」. cve.mitre.org . The MITRE Corporation . 2023 年11 月 25 日閲覧。

[12] 「CVE - CVE ID 構文の変更」cve.mitre.org . 2016 年 9 月 13 日。

[:0-13] 「CVE 抽象化コンテンツの決定: 根拠と適用 (アーカイブ)」。The Mitre Corporation。2005年 6 月 15 日。2024 年1 月 6 日に閲覧。

[14] 「CVE - CVEについて」cve.mitre.org . 2015年7月28日閲覧。

[15] 「CVE 番号付与機関のルール - 割り当てルール」(PDF)。MITRE Corporation。2020 年 2 月 1 日。pp. 13–15。2023年12 月 6 日に閲覧。

[16] Edge, Jake (2023 年 12 月 5 日). 「!CVE による CVE の補足」. lwn.net .

[17] Edge, Jake (2023年9月13日). 「偽のCVE問題」. lwn.net .

[18] 「CVE 番号の転換点」LWN.net 2024 年 2 月 14 日。