CVEエントリはどの程度役に立ちますか？
ほとんどのCVEエントリは、バグ自体を完全に説明したものではなく、概念実証でさえバグを示しています。彼らが持っているのは、可能性のある副作用のいくつかの非常に高レベルの抽象的な説明です。 CVE-2016-8412 状態、
Qualcommカメラに権限昇格の脆弱性があるため、悪意のあるローカルアプリがカーネル内で勝手なコードを実行できるおそれがあります。最初に特権プロセスを侵害する必要があるため、この問題の重大度は「高」と判断されています。製品：Android。バージョン：Kernel-3.10、Kernel-3.18。 Android ID：A-31225246。参照：QC-CR＃1071891。
説明には有用な情報がありません。ソースの脆弱なブロック（Androidであるため）、関連する分析、可能なパッチ（オプション）など。これらの種類のCVEは、セキュリティ調査の観点からはまったく役に立ちますか？それらは、ソフトウェアのバグの程度の指標となる可能性があることを除いて、実際の目的を果たしますか？
それらは有用ですが、エクスプロイトを構築するためには有用ではありません。ソフトウェアのバグがどれほどあるかを判断するのにも役立ちません... CVEの数はコードの品質と強い相関関係はありません。
それらが何に役立つかある使用している特定のソフトウェアパッケージのバージョンが特定の既知のエクスプロイトにパッチされているかどうか、および発見されたエクスプロイトの潜在的な影響を管理者として判断すること。このようにして、組織がソフトウェアのセキュリティリスクを適切に管理していることを確認するために使用できる多くのツールの1つとして、脆弱性管理プロセスに直接フィードできます。
CVEの主な使用例は、ソフトウェアの脆弱性の一意の識別子を持つことです。製品の全体的なセキュリティを測定するのは 良いツールではありません であり、バグの詳細な分析には役立ちません。
CVEは、脆弱性に標準名を割り当てるデータベースではなく、ディクショナリと考える必要があります。これにより、異なるシステム間でそれらを明確に参照できます。 CVEエントリが脆弱性の完全な説明または影響の正確な推定を提供すると仮定することを間違えないでください。
About CVE ページは、フォーカスが標準化に焦点を合わせていることを明確にします：
CVEは次のとおりです。
- 1つの脆弱性または露出の1つの名前
- 脆弱性または露出ごとに1つの標準化された説明
- データベースではなく辞書
- 異種のデータベースとツールが同じ言語を「話す」ことができる方法
- 相互運用性とセキュリティカバレッジを改善する方法
- ツールとデータベース間の評価の基礎
[...]
したがって、エントリはサードパーティによって検証されず、必ずしも完全ではないため、CVEは、製品のすべての既知の脆弱性の包括的なデータベースであることを意味していません。これは概して、概要として、またパッチまたは報告のバグに対処するために使用できる一意の識別子を持つために役立ちます。
CVEはいくつかの点で役立ちます。
最初に、そしておそらく最も重要なこととして、それらは特定の脆弱性に共通の用語を提供します。これにより、誰かが「Androidの脆弱性を見つけましたか」と言ったときに、sameAndroidについて話していることを簡単に確認できます。 _脆弱性。また、問題に関する詳細情報の検索も大幅に簡素化されます。
次に、クリックして NISTの脆弱性のページ をクリックすると、 [〜＃〜] cvss [〜＃〜] 情報が表示されます。この表記により、環境内の脆弱性にパッチを適用することがどれほど重要であるかを簡単にすばやく把握できます。
私にとって、CVEは辞書用語に少し似ています。これは、共通の列挙を介して何かが簡単に伝達できることを意味します。
それらがそのように書かれている理由についての詳細は https://cve.mitre.org/about/faqs.html#b4 で読むことができます
優れたCVEは、OpenSSLに関連するこれです。 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6304
説明は短いですが、ページは関連する参照にリンクしており、CVEをさらに拡張しています。
例として使用しているCVEには、Androidのセキュリティ速報が含まれています）へのリンクがあります（多くは言及されていません）。利用可能な場合は共有されません。
すでに述べたように、それらは便利です...それはあなたが何をしたいか次第です。セキュリティ監査を行っている場合（これが私の答えにアプローチする方法です）、どこかから開始することが重要です。 NessusやOpenVASなどを実行すると、特定のCVEがホストと相関していることがわかります。そこから、 exploit-db.com のようなものを使用して利用できるエクスプロイトがあるかどうかを調査する必要があります。エクスプロイトは常にCVEにリストされているわけではないため、十分な注意が必要です。
CVEは、ソフトウェアチェーンのすべてのアクター（開発者、システム管理者、顧客...）が既存のソフトウェアにアクションを実行するかどうかを決定するのに役立ちます。これから説明するように、実際のインストールにパッチを適用するには長い時間がかかるため、概念実証は意図的に編集されています。
理論的な世界では、パッチはすべてのデバイスにすぐに展開されます。これにより、すべてのデバイスにパッチが適用され、保護されます。不可能だよ。
Androidを選択...
- T0：Androidカーネルに影響を与えるLinuxカーネルの脆弱性が見つかり、パッチが適用されます
- T1：GoogleがAOSPにパッチを適用し、パッチをリリースする
- T2：モバイルメーカー（LG、Motorola、Samsungなど）がパッチを受け取り、カスタマイズされたビルドに適用します
- T3：パッチはOTAで消費者に配信されます
- T4：Android同じ製造元のビジネスデバイスが1000台ある会社が、更新を仕事用デバイスに展開します
Apacheを選択...
これは私の仕事中に私に起こった事件に似ています
- T0：Apacheの脆弱性が見つかりパッチが適用され、Apacheがリリースされました
- T1：社内のさまざまなサーバーにインストールされている多くのアプリケーションにApacheを使用している大企業がアップグレードをスケジュールしている
- T2からT100：すべてのApacheインスタンスが企業システムでアップグレードされ、テスト計画を満たし、スケジュールするサプライヤーとマネージャーが関与します
要するに
CVEは、ソフトウェアの「古さ」と「危険性」を判断するのに役立ちます。重大度と影響を受けるコンポーネントを調べることにより、ITスタッフは、たとえば今のところアップグレードしないで、すぐにアップグレードするか、追加の一時的なセキュリティ対策（ファイアウォール、プロキシなど）を適用するかを決定できます。
企業の世界では、ソフトウェアのアップグレードに固有のslownessがあります。 Java <= 1.5（ここでも1.5以降））を実行している銀行が表示されます以降のバージョンが認定されていないためとJava 1.7はすでにサポートが終了しています。企業はまだXPを実行しています。既存のソフトウェアベースはWindows 7で実行されます。
私の経験によれば、厳しいCVEが、構造化された企業シナリオでソフトウェアのアップグレードを優先する理由になり得ます。