CISA KEVカタログとは?活用方法と包括的対策を徹底解
はじめに:脆弱性対応の現場が直面する深刻な課題
毎日のように新たな脆弱性が発見される中、あなたの組織はどの脆弱性から対処していますか?CVSSスコアが高いものから?それとも公開された順番に?
実は、実際に悪用される脆弱性はごく一部に過ぎません。Kenna Security(現Cisco)とCyentia Instituteが実施した複数年にわたる調査によれば:
これらの研究から、CVSS値で「重大」や「高」と判定された脆弱性であっても、実際に悪用されるのは数パーセント程度に過ぎないことが示されています。セキュリティ研究やEPSS(Exploit Prediction Scoring System)プロジェクトなどの分析によれば、高CVSSスコアと実際の悪用には必ずしも強い相関がないことが明らかになっています。
つまり、多くの組織が限られたリソースを、実際には攻撃に使われない脆弱性の対応に費やしている可能性があるのです。一方で、本当に危険な脆弱性への対応が後回しになり、攻撃を受けるリスクが高まっています。
「どの脆弱性から対処すべきか分からない」
「全ての脆弱性に対応するリソースがない」
「優先順位の判断基準が欲しい」
こうした現場の悩みを解決する鍵が、米国CISAが提供するKEV(既知の悪用された脆弱性カタログ)です。本記事では、KEVの基本から実践的な活用方法、そして包括的なセキュリティ対策までを徹底解説します。
KEV(Known Exploited Vulnerabilities)とは何か
KEVの定義と本質
- KEV(Known Exploited Vulnerabilities Catalog)は、日本語で「既知の悪用された脆弱性カタログ」と訳されます。米国CISA(Cybersecurity & Infrastructure Security Agency)が管理・提供する、実際に攻撃者によって悪用されたことが確認された脆弱性のデータベースです。
一般的な脆弱性データベース(CVEなど)との最も大きな違いは、「悪用される可能性」ではなく「実際に悪用された」という事実に基づいている点です。
分かりやすく言えば、CVE(全ての脆弱性情報)という大海原の中から、実際に野外(in the wild)で攻撃に使用された脆弱性だけを厳選したリストがKEVなのです。
KEVとKEVカタログの違い
実務上、この2つの用語はほぼ同義で使われますが、厳密には以下の違いがあります。
- KEV:実際に悪用された個々の脆弱性そのものを指す用語
- KEVカタログ:それらの脆弱性をデータベース化し、体系的に管理しているリストやシステム全体
本記事では主に「KEV」という表記を使用しますが、「KEVカタログ」も同じ意味として扱います。
KEVに登録される3つの厳格な基準
KEVへの登録は誰でも自由にできるわけではありません。CISAが定める3つの厳格な条件を全て満たす必要があります。
基準1:CVE IDが割り当てられていること
CVE(Common Vulnerabilities and Exposures)とは、共通脆弱性識別子のことです。世界中の脆弱性に対して「CVE-2024-12345」のような一意の番号が割り当てられ、情報共有の基盤となっています。
KEVに登録されるには、まずこのCVE番号が必要です。つまり、公に認知され、体系的に管理されている脆弱性であることが前提条件となります。
基準2:実際に悪用されている信頼できる証拠があること
これがKEVの最も重要な基準です。単なる「悪用の可能性」や「理論上の脆弱性」ではなく、実際の攻撃活動が確認されている必要があります。
証拠として認められるもの:
- 実システムへの攻撃成功例の報告
- ハニーポット(囮システム)での攻撃観測
- セキュリティベンダーやCISA自身が確認した攻撃活動
- 信頼できる脅威インテリジェンスソースからの報告
⚠️ 除外されるもの:
- 単なるスキャン行為(攻撃者が脆弱性の存在を確認しただけ)
- PoC(Proof of Concept:概念実証コード)の公開
- 理論上の悪用可能性の指摘
基準3:明確な是正ガイダンスが公開されていること
脆弱性を発見しただけでなく、その対処方法が明確に示されている必要があります。
具体的には:
- ベンダー提供のセキュリティパッチ
- 緩和策や回避策(パッチが提供されない場合)
- サポート終了製品の場合の代替手段
対処方法が存在しない、または不明確な脆弱性はKEVに登録されません。これにより、「分かっているのに何もできない」という状況を避けています。
なぜ今、KEVが不可欠なのか?6つの深刻な背景
背景1:脆弱性の増加と対応リソースの限界
新規CVEの年間登録数は増加の一途を辿っています。2020年には約18,000件だったものが、2024年には30,000件以上に達しました。
一方で、セキュリティ人材は慢性的に不足しています。全ての脆弱性に対応することは物理的に不可能であり、優先順位付けが必須となっています。
KEVは、この困難な状況下で「どの脆弱性を最優先すべきか」という明確な指針を提供してくれます。
背景2:実際の悪用スピードの速さ
CISAやセキュリティベンダーの調査によれば、KEVに登録される脆弱性には以下の傾向が見られます:
- 相当数がゼロデイ攻撃(脆弱性が公開される前から悪用)として発見される
- 公開後、極めて短期間(数日以内)で悪用が始まるケースが多い
- 大半が公開から数週間以内に活発な悪用が観測される
つまり、「後で対処しよう」という判断は手遅れに直結するリスクが極めて高いのです。KEVに登録された脆弱性は、即座の対応が求められる緊急性の高いものばかりです。
背景3:米国連邦政府による義務化とグローバル標準化
2021年11月、CISAはBOD 22-01(Binding Operational Directive 22-01)という拘束力のある運用指示を発令しました。これにより、米国連邦政府機関は以下の義務を負っています。
- KEVカタログの継続的な監視
- KEVに登録された脆弱性への迅速な対応(多くの場合、2週間以内)
民間企業には法的義務はありませんが、以下の理由から無関係ではいられません。
日本企業も注目すべき理由:
- グローバルサプライチェーンの一部として、取引先から対応を求められる可能性
- ベストプラクティスとしての価値(米国政府が採用する基準)
- 国際的な監査やコンプライアンス要件への対応
- サイバー保険の審査での評価向上
背景4:ランサムウェア攻撃との強い相関
KEVカタログには「knownRansomwareCampaignUse」というフィールドが存在します。このフィールドには、ランサムウェアグループが実際に悪用した脆弱性であることが明記されています。
ランサムウェア攻撃の多くは、既知の脆弱性を悪用した初期侵入から始まります。KEVを優先的に対応することは、ランサムウェア対策の第一歩となるのです。
背景5:ランサムウェアグループによる優先的な悪用
KEVに登録されている脆弱性の多くは、実際のランサムウェア攻撃で使用されたことが確認されています。CISAの分析によれば、主要なランサムウェアグループは、新たに公開された脆弱性を数時間から数日以内に攻撃ツールに組み込み、被害者の探索を開始します。
特に注目すべきは、ランサムウェアグループが「KEVに登録される前」から脆弱性を悪用し始めるケースが増加していることです。つまり、KEVへの対応は、ランサムウェア対策の最前線となるのです。
背景6:コンプライアンスとリスク管理の観点
監査時に「なぜこの脆弱性には対応しなかったのか」と問われた際、KEVの有無は強力な説明根拠になります。
- KEVに登録されている脆弱性:最優先で対応すべき(対応しなかった場合は明確な説明責任)
- KEVに未登録の脆弱性:リスク評価に基づく合理的判断の範囲
また、サイバー保険の審査でも、KEVへの対応状況が評価項目に含まれるケースが増えています。取締役会への報告材料としても、KEVは客観的で分かりやすい指標となります。
KEVカタログの具体的な活用方法
KEVカタログへのアクセス方法
KEVカタログは誰でも無料でアクセスできます。
公式URL: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
3つのアクセス方法:
- Webブラウザでの閲覧
- 最も手軽な方法
- 検索やフィルタリングが可能
- リアルタイムで最新情報を確認
- CSV形式のダウンロード
- Excelなどで独自の分析が可能
- 既存のツールへのインポート
- オフライン環境での参照
- JSON形式のダウンロード
- 自動化ツールとの連携
- プログラムによる処理
- システムへの組み込み
更新通知の受信: CISAのWebサイトでメールサブスクリプションに登録すると、KEVに新たな脆弱性が追加された際に通知を受け取れます。
KEVを活用した脆弱性管理の実践手順
ステップ1:資産とソフトウェアインベントリの整備
KEVと照合する前提として、自社が使用している全てのソフトウェアとシステムを把握する必要があります。「何を守るべきか」が分からなければ、KEVとの照合もできません。
ここで重要になるのが、後述するASM(Attack Surface Management)による網羅的な資産管理です。
ステップ2:KEVカタログとの照合
自社の脆弱性スキャン結果やシステムインベントリとKEVカタログを照合します。使用しているソフトウェアのCVE番号がKEVに登録されているかを確認します。
該当するCVEが見つかった場合は、最優先で対応が必要です。
ステップ3:影響範囲の特定
該当脆弱性が存在するシステムやアプリケーションを洗い出します。
- どのサーバーに影響があるか
- インターネットに公開されているか
- 重要な業務システムか
- ビジネスへの影響度はどの程度か
この段階で、SBOM(Software Bill of Materials)があると、依存関係を含めた正確な影響範囲の特定が可能になります。
ステップ4:修正措置の実施
優先順位に基づいて対応:
- パッチ適用:ベンダーが提供するセキュリティパッチを適用
- 緩和策の実装:即座のパッチ適用が困難な場合の一時的対策
- 該当システムの隔離:どうしても対応が間に合わない場合の最終手段
ステップ5:継続的なモニタリング
KEVは定期的に更新されます(平均して週に1〜2回)。一度確認して終わりではなく、継続的な監視体制が必要です。
自動化ツールによる継続監視を導入することで、新たにKEVに追加された脆弱性を即座に検知できます。
KEVを活用した対応優先順位付けフレームワーク
全ての脆弱性を同時に対処することは不可能です。以下のマトリックスで優先順位を付けましょう。
【最優先】KEV登録あり × 自社環境に存在 × インターネット公開
↓ 即座に対応が必要(数時間〜1日以内)
【高優先】KEV登録あり × 自社環境に存在 × 内部ネットワークのみ
↓ 早急に対応が必要(数日以内)
【中優先】CVSS高/重大 × KEV未登録 × EPSS高スコア
↓ 計画的に対応(1〜2週間以内)
【低優先】CVSS中以下 × KEV未登録
↓ 通常の脆弱性管理プロセスで対応
このフレームワークにより、限られたリソースを最も効果的に配分できます。
KEV対応における実務上の課題
一方で、KEVを活用した脆弱性管理を実践する上では、以下のような課題に直面することがあります。
- 資産の可視化が不十分:KEVとの照合を行う前提として、自組織が使用している全てのシステム、ソフトウェア、デバイスを正確に把握できていないケースが多く見られます。特にクラウドサービスなどの利用拡大により、IT部門が把握していない「シャドーIT」が存在する場合、KEV該当資産の特定自体が困難となります。
- 対応リソースの不足:KEVに登録された脆弱性は期限内での対応が求められますが、セキュリティ担当者の人員不足や技術的なスキルギャップにより、迅速な対応が困難な組織も少なくありません。また、対応の優先順位判断や影響範囲の調査にも相応のリソースが必要です。
- 業務影響との調整:ミッションクリティカルな業務システムにパッチを適用する際は、システム停止による業務への影響を最小限に抑える必要があり、変更管理プロセスとの調整や、適切なメンテナンスウィンドウの確保が課題となります。
- 継続的な監視体制の構築:KEVは随時更新されるため、手動での確認では対応が後手に回るリスクがあります。SBOM(Software Bill of Materials)管理と連携した自動化された監視・通知の仕組み、およびインシデント対応フローの整備が不可欠です。
これらの課題を解決するためには、資産管理、脆弱性診断、対応の優先順位付け、そして継続的なモニタリングを統合的に実施できる体制とツールが不可欠です。
まとめ
CISA KEVカタログは、実際に悪用が確認された脆弱性のみを掲載する、脆弱性管理の新しい基準です。CVSSスコアだけに頼った従来の優先順位付けから脱却し、「本当に危険な脆弱性」に焦点を当てることで、限られたリソースを最大限に活用できます。
KEV活用のメリット:
- 実際に悪用されている脆弱性を優先的に対処できる
- 限られたセキュリティリソースを効果的に配分できる
- ランサムウェアなどの実際の攻撃から組織を守れる
- 監査やコンプライアンス対応で明確な説明根拠となる
KEVへの対応は、もはや「できたら良い」施策ではなく、現代の脆弱性管理における必須要件となっています。しかし、KEVの運用を適切に行うためには、様々なセキュリティ診断を行い、包括的なアプローチで管理していくことが必要となります。
Securifyは、これらの要素を統合し、KEVへの対応を含む効率的な脆弱性管理を実現します。あなたの組織のセキュリティ体制を、次のレベルへ引き上げませんか?あなたの組織のセキュリティ強化を、Securifyがサポートします。ご興味のある方はぜひお問い合わせください。
SBOMについてはこちらで解説しております。併せてご覧ください。
参考文献
- Kenna Security & Cyentia Institute
https://www.theregister.com/2021/02/18/cve_exploitation_2_6pc_kenna_security/
- Kenna Security (Cisco) & Cyentia Institute
- CISA Known Exploited Vulnerabilities Catalog
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- CISA Binding Operational Directive 22-01
https://www.cisa.gov/known-exploited-vulnerabilities
- National Vulnerability Database (NVD)
https://nvd.nist.gov/
- MITRE CVE
https://cve.mitre.org/
