こんにちは、同僚！
コンプライアンス管理製品の作成者が直面する問題の1つは、システムインベントリの結果とこれらの脆弱性を比較するプロセスです。 これは、データベース（ NVDなど ）の脆弱性を正式に文書化する場合、脆弱性の適用可能性が正式な言語CPEによって記述されるという事実に基づいています。 これは、可能なすべての製品、オペレーティングシステム、およびハードウェアデバイスを説明する方法です。
普遍的なフォーマットとして考えられ、それはMITREのユートピアのままでした。
CVEの脆弱性に関する情報を送信する方法で、情報セキュリティにおける情報の形式化されたストレージの「基礎」に置かれています。
この言語の基礎は辞書です 。これは基本的に、標準の略語とその追加情報との対応を調べるための参照です。 CPEの略語がどのように機能するかを見てみましょう。
図からわかるように、CPEコード行は記号「：」によって論理セクションに分割されています。 フィールドの数は、必要に応じて、不要なフィールドを空の文字列に置き換えて、必要な近似の程度によって決まります。 したがって、粒度を最大にするには、すべてのフィールドの値を指定する必要があり、選択を一般化するには、目的の場所にギャップを作成する必要があります。 これらの構造をコンパイルするための規則は仕様で詳細に見つけることができます。
このようなリンクがあると、 辞書に目を向けて、製品データのXMLブロックを取得できます。 cpe：/ o：sun：sunos：5.9の例で考えてください：
<cpe-item name = "cpe：/ o：sun：sunos：5.9" >
<title xml：lang = "en-US" > Sun SunOS（以前のSolaris 9）5.9 </ title >
<check href = " oval.mitre.org/repository/data/DownloadDefinition?id=oval：org.mitre.oval：def：2174 " system = " oval.mitre.org/XMLSchema/oval-definitions-5" > oval ：org.mitre.oval：def：2174 </チェック>
<meta：item-metadata modification-date = "2011-01-19T19：36：00.913Z" status = "DRAFT" nvd-id = "122557" />
</ cpe-item >
ご覧のとおり、製品自体、その一意の識別子nvd-id、および「チェック」ブロックに関する情報が提供されています。 検証ユニットは、私が以前に書いたOVAL言語の形式化された検証へのリンクが含まれているため、最も興味深いものです。 このリンクを使用すると、定義で指定された基準を使用してシステムを一意に識別できます。 残念ながら、システム内の製品の在庫管理方法へのこれらのリンクは、現在CPEにとってまれです。
もちろん、このシステムは、多数の製品を指定できる論理要素なしにはできませんでした。 このソリューションは、脆弱性の適用可能性を判断するためにも必要です。
<cpe-lang：logical-test negate = "false" operator = "OR" >
<cpe-lang：fact-ref name = "cpe：/ a：ibm：db2：9.0" />
<cpe-lang：fact-ref name = "cpe：/ a：ibm：db2_universal_database：6.0" />
<cpe-lang：fact-ref name = "cpe：/ a：ibm：db2_universal_database：7.0 :: linux" />
<cpe-lang：fact-ref name = "cpe：/ a：ibm：db2_universal_database：7.1 :: linux" />
<cpe-lang：fact-ref name = "cpe：/ a：ibm：db2_universal_database：7.2 :: linux" />
<cpe-lang：fact-ref name = "cpe：/ a：ibm：db2_universal_database：8.0 :: linux" />
<cpe-lang：fact-ref name = "cpe：/ a：ibm：db2_universal_database：8.1 :: aix" />
<cpe-lang：fact-ref name = "cpe：/ a：ibm：db2_universal_database：8.2 :: windows" />
</ cpe-lang：論理テスト>
コンテキストが示すように、これらの行は製品グループの「OR」条件を説明しています。
したがって、これらの製品のいずれかが存在する場合、状態は陽性になります。
これらのツールを組み合わせることで、「適用性」が保証された正確な方法を決定できます。
これで、CPE言語の説明を終了したいと思います。 このMITERソリューションは、既存のすべてのプラットフォームを標準化し、その決定のためのメソッドを作成するように設計されました。 しかし、残念ながら、ベンダーはこの電話を無視し、CPEのような有望なツールはまだ普及していません。
したがって、脆弱性を処理および検索するためのツールを作成する場合、これらの依存関係をほとんどの場合手動で解決する必要があります。 このような悲しい事実は、ソフトウェアの作成者が自社の製品に関する情報を体系的に入手し始めるまでそのままです。
お時間をいただきありがとうございます。
またね