ベンダーの決定により、パッチが適用されているにもかかわらず、特定のOS /サービスが脆弱かどうかをどこで確認しますか？
パッチが適用されているにもかかわらず脆弱であるサービスのリスクを軽減する方法について説明する必要があります（通常、サービスがベンダーによって保守されなくなったため、またはベンダーがパッチを発行したくないため、または制御できないその他の理由のため）。
- マシンが脆弱かどうかを確認する方法を知っています（パッチインベントリシステム、脆弱性スキャナーなど）
- 脆弱性（OVAL、CVE、NVDなど）の詳細を探す場所を知っています。
私が知らないのは、特定のOS、サービス、またはアプリケーションが脆弱であるかどうかを確認する場所ですベンダーの決定によりパッチが適用され、強化されているにもかかわらず。
例としては、Microsoftによって保守されなくなったWindows Server 2003が挙げられ、EOS後に発見されたWindows全体の脆弱性に対して脆弱になる可能性があります。この知識があれば、リスクを軽減するために不測の事態に優先順位を付けることが簡単になります。
そのようなリソースはありますか？
それはベンダーに依存し、推論に依存する場合があります。それが、脆弱性スキャナーを使用する理由であり、脆弱性スキャナーは、明確な証拠を与えられた罪悪感を想定することを誤る理由です。
ベンダー
少なくとも1つのベンダーであるRed Hatは vulnerability-to-CVEマッピングデータベース を維持しており、ディストリビューション内のソフトウェアに適用されるすべてのCVEをリストしています。詳細ページでは、その脆弱性に関するソフトウェアのステータスについて説明します。
- RedHatによって配布された構成に脆弱性はありません（ CVE-2015-0202 を参照）
- Red Hat Security Errata（RHSA）によって対処（ CVE-2015-0192 を参照）
- Red Hatがパッチを適用できるほど重要ではないと考えられている（RHEL 5の場合は CVE-2014-2532 を参照）
したがって、Red Hatを実行している場合は問題ありません。あなたが心配しているCVEを取り上げて、それらを調べて彼らが何をしたかを見ることができます。ただし、ほとんどのベンダーはこのように構成されていません。 （ [セキュリティの脆弱性のライフサイクル も参照）。
一部のベンダーは、有償サポートの顧客のみに、場合によっては特定の要求に対してのみ、特定の修正をリリースする癖があります。それがこの研究をいかに複雑にするか想像できます。
推論
MITERはCVEに関連するベンダーアナウンスの追跡を試みるため、CVE内の「外部ソース」参照を参照することで、ベンダーが対処した問題を特定できる場合があります。たとえば、 CVE-2015-0202 の詳細を読むと、OpenSuSEとMandrivaにリンクがあることがわかります。 OpenSuSEリンクは、パッチが適用された更新バージョンを説明しています（そしてMandrivaリンクは壊れています）。 Red Hatはここにはリンクされていません。上で見たように、これらは脆弱ではないので、このリストからの欠落は脆弱性の証拠ではありません。
MITERは CVE参照キー/マップ も維持します。たとえば、 ソースMSのマップ は、CVEからMicrosoftパッチへの非常にきちんと整理されたマップを提供します。しかし、他のすべてと同様に、
リファレンスのリストは完全ではない場合があることに注意してください。
脆弱性スキャナー
データベースを最新の状態に保ち、公開し続けることを人々に信頼することは、間違いなく間違いです。これが、脆弱性スキャナーを使用して検証する理由です。脆弱性スキャナーはも誤りです-最も具体的には、限られた情報（サービスバナーバージョンのアナウンスなど）に基づいたテストは失敗することがよくあります。 OpenSSH-2.3.4がCVE-2002-1234に対して脆弱であるとしましょう。CVE-2002-1234はOpenSSH-3.4.5でパッチされています。 Red Hatはその脆弱性に固有のセキュリティパッチを取得してそれをバックポートし、OpenSSH-2.3.4p2を作成します。これにより、サービスバナーでOpenSSH-2.3.4としてそれ自体がアナウンスされます。スキャナーがバージョンをキーオフし、実際にそれが存在することを証明するためにバグを実行していないため、システムは脆弱であると見なします。
スキャナーがそれを行うとき、私たちは上記で見つかったすべてのアイテムで問題を調査し、それが実際に脆弱ではないことを証明しなければなりません。
まとめ
明らかな理由により、ベンダーはパッチを適用しないことを選択したもののきちんとしたリストを提供していません。正直なところ、彼らがあなたのためにそれを追跡するのに十分気にかけていれば、おそらく彼らも問題を修正するのに十分気にかけているでしょう。しかし、それだけでは、こうしたリストが行うことはすべて、明示的に見栄えを悪くするだけなので、そうする動機はあまりありません。
彼らが提供するもので間に合わせることができ、私たちが調査してパッチの可用性の証拠を見つけることができないとき、私たちは事柄を推測することができます。これらは正確な解決策ではありません。そうは言っても、私はCVEデータベースが開始される前の生活を覚えており、以前よりもずっと良い状態にあります。
これはまさに脆弱性スキャナーが行うことです。彼らはそれが得意ではありません（サポートされていないソフトウェアをすべて検出したことはありません。すぐに検出されるとは思えません！）。
一般に、すべてのベンダーはこの情報を広める独自の方法を持っています-仮にそうした場合でも-これは資産所有者とセキュリティ専門家にとって大きな苦痛です。脆弱性自体については、CVEは（たとえば、NVDのWebサイトを通じて）素晴らしいリソースであると思いますが、サポートについては説明していません。私はこの情報の中央リポジトリを知りません。
CVE Details Webサイトは、特定のバージョン番号で既知の脆弱性を検索するための優れたリソースです。ただし、このコンテキストでは、「サポートされていない」はそれらの1つではありません。
ここで "ベンダー決定"について考えることができる1つの例は、CVE-2015-0008/MS15-011です。CVE-2015-0008/ MS15-011は、当時サポートされていたとしても、Server 2003にはパッチが適用されていません。