
脆弱性エンリッチメントを実施するためのリポジトリ。
CISA Vulnrichmentプロジェクトは、CISAのADP(Authorized Data Publisher)コンテナを通じて、公開CVEレコードに対するCISAのエンリッチメントを公開するリポジトリです。このフェーズでは、CISAは新規および最近のCVEを評価し、重要なSSVCの判断ポイントを追加しています。スコアリングが完了すると、リスクの高い一部のCVEには、可能な場合にはCWEやCVSSのデータポイントによるエンリッチメントも行われます。
このCVEデータのプロデューサーおよびコンシューマーは、現在のCVE Record Formatにすでに精通しているはずであり、GitHub APIやCVE Services APIなど、通常の方法でこのデータにアクセスできます。Vulnrichmentの結果は、最近(2024年)開始されたADP Programを通じて、CVEコーパスにプッシュバックされていることに注意してください。ダウンストリームのコンシューマーがすでにライブのCVEデータを消費している場合、このGitHubリポジトリをフォークして追跡する必要はありません。
このプロジェクトは活発に開発中であるため、最新情報についてはこのREADME.mdに注目してください。
まず、CISAは各CVEをSSVCスコアリングプロセスにかけます。
次に、「Total Technical Impact」、「Automatable」と評価されたCVE、または「Exploitation」の値が「Proof of Concept」または「Active Exploitation」であるCVEについては、さらなる分析が行われます。CISAは、特定のCWE識別子やCVSSスコアを主張するのに十分な情報があるかどうかを判断します。場合によっては、これらの判断ポイントのいずれにおいても高リスクと評価されない脆弱性に対しても、CISAがこれらのメトリクスを提供することがあります。
これらのフィールドが発信元のCNAによってすでに設定されていないCVEについて、CISAは、それを裏付ける十分な証拠がある場合、関連するADPコンテナにそれらの値を設定します。CISAがCVEレコード内の元のCNAコンテナにある発信元CNAのデータを上書きすることは決してありません。
これらのフローチャートはVulnrichmentプロセスを示しています。フローチャートの詳細は、Vulnrichmentプロセスの改良に伴い変更される可能性があることに注意してください。
CISA ADPから期待できる各種類のvulnrichmentについて、いくつかのCVEレコードを見てみましょう。
以下に例として挙げたCVEはすべて、示された基準に適合するものの中からランダムに選ばれたものです。
CISA ADPによって分析されたすべてのCVEには、3つのSSVC判断ポイントが記載されます。これらの例では、CVE-2024-34974、CVE-2024-25522、CVE-2024-35057を見てみましょう。また、低リスクのSSVCスコアであるCVE-2024-33666も見てみます。
CVE-2024-25522は、47行目のExploitに「poc」値があり、分析時点で公開された概念実証が存在したことを示しています:
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
]
CVE-2024-34974は、50行目の「Automatable」に「yes」値があり、攻撃者が偵察、兵器化、配信、悪用防止技術を気にすることなく、一般にこの脆弱性を意のままに悪用できることを示しています。
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
]
CVE-2024-35057は、59行目の「Technical Impact」に「total」値があり、この脆弱性を悪用すると一般に攻撃者が影響を受けるソフトウェアを完全に制御できるようになることを示しています。
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
]
KEVに掲載されているCVEについては、CISA ADPがKEVブロックを追加します。掲載されていないものについては、更新は行われません。
CVE-2024-4947はそのようなCVEの1つで、153行目からKEVブロックが含まれています:
"other": {
"type": "kev",
"content": {
"dateAdded": "2024-05-20",
"reference": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-4947"
}
}
CVE-2024-3477は、発信元のCNAがCWEを提供しておらず、CISAのアナリストが利用可能な脆弱性情報の文脈からCWEを特定できたCVEの例です。そのメトリクスは49行目のproblemTypesノードの下から始まります:
"problemTypes": [
{
"descriptions": [
{
"lang": "en",
"type": "CWE",
"cweId": "CWE-352",
"description": "CWE-352 Cross-Site Request Forgery (CSRF)"
}
]
}
]
CVE-2024-0043は、CISAによってCVSS計算が追加されたCVEの例で、30行目から始まります。これもまた、分析時点で利用可能な脆弱性情報の文脈に基づいています。
"cvssV3_1": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 7.8,
"attackVector": "LOCAL",
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"integrityImpact": "HIGH",
"userInteraction": "REQUIRED",
"attackComplexity": "LOW",
"availabilityImpact": "HIGH",
"privilegesRequired": "NONE",
"confidentialityImpact": "HIGH"
}
2024年12月10日をもって、CISAはエンリッチされたデータセットにCPE文字列を追加しなくなることに注意してください。以前にエンリッチされたデータには、CPE情報がまだ含まれている場合があります。ここでのCPE文字列に関する記述は、履歴目的のものです。
CVE-2024-1347は、CISAによってCPE文字列が追加されたCVEの例で、61行目から始まります。
"cpes": [
"cpe:2.3:a:gitlab:gitlab:*:*:*:*:*:*:*:*"
]
CVE-2024-2905は、CISAがSSVCトリアージステップを実行した時点で、すでにCWE、CVSS、CPEメトリクスを持っていたCVEの例であり(こちらを参照)、KEVにも掲載されていないため、これ以上追加する必要はありませんでした。よくやりました、Red Hat CNA!
CISA ADPは、CNAが自らCWE、CVSS、CPEデータを提供するという「正しいこと」を行うよう促すことに尽力しているため、CISA ADPが評価を行った後にCVEエントリがそれらのデータを含むように更新された場合、CISA ADPは自身の評価をCVEエントリから削除します。このアプローチにより、CVEレコード内の重複した(そして矛盾する)データが削減されます。発信元CNAとCISA ADPの両方によってCWE、CVSS、またはCPEデータが提供されるという稀なケースでは、これはCISA ADPコンテナのエラーとして扱われるべきであり、発信元CNAのデータが優先されるべきです。
SSVCデータは、そのデータを生成した決定木で使用されたSSVCバージョンのスキーマに沿った方法でエンコードされています。現在、CISAはCISA Coordinatorツリーを利用しています。
SSVCデータのversionフィールドはmajor.minor.patchの慣例に従っており、major.minorはSSVCバージョンを示し、patchは決定木バージョンを示します。現在のCISA決定木では、これによりバージョン番号は2.0.3となります: SSVCバージョン2.0、CISA Coordinatorツリーバージョン3です。
SSVCの更新に適合するための決定木の更新は、バージョン文字列の変更をもたらします。このデータを消費するユーザーは、SSVCスコアをデコードする際にバージョンを確認し、JSONデータをどのように検証および処理するかを判断することが推奨されます。
私たちは、ITサイバーセキュリティ専門家コミュニティであるあなたから、VulnrichmentとADPについて意見を聞きたいと思っています!何か気づいたことがあれば、Issuesで気軽に発言してください。さらに良いのは、提案する修正を含むpull requestを開くことです。CNAコンテナからのデータに問題がある場合は、その問題を責任あるCNAに直接持ち込むことが推奨されることに注意してください。