Info

このページは、米国政府サイバーセキュリティ・社会基盤安全保障庁（CISA）による“Reducing the Significant Risk of Known Exploited Vulnerabilities”の、2023年1月3日時点の内容を日本語訳したものです。

文書は、原典に沿ってできるだけ忠実に翻訳するよう努めていますが、完全性、正確性を保証するものではありません。 訳者は、本翻訳物に記載されている情報より生じる損失または損害に対して、いかなる人物あるいは団体にも責任を負うものではありません。

既知の悪用された脆弱性による重大なリスクの軽減について 見出しへのリンク

サイバーセキュリティ共同体及びネットワーク防御従事者のために、そして全ての組織が脆弱性をよりよく管理し、脅威の活動に対応できるようにするために、サイバーセキュリティ・社会基盤安全保障庁（CISA）は、実際に悪用された脆弱性の信頼できる情報源である、「既知の悪用された脆弱性（KEV: Known Exploited Vulnerabilities）カタログ」原文リンクを管理しています。CISAはすべての組織に対し、既知の脅威主体による侵害の可能性を減らすために、KEVカタログを確認および監視し、掲載されている脆弱性の修正を優先することを強く推奨します。

全ての連邦文民行政機関（FCEB）当局は、拘束力のある運用指令（BOD: Binding Operational Directive）22-01原文リンク「既知の悪用された脆弱性による重大なリスクの軽減について」の定める期間内にKEVカタログの脆弱性を修正する必要があります。同様に、BOD 22-01に羈束はされないものの、州、地方、部族及び領土（SLTT）政府、並びに民間産業を含む全ての組織は、KEVカタログに記載されている脆弱性の修正に優先度を付与することで、セキュリティとレジリエンスの態勢を有意に強化できます。CISAは、全ての利害関係者が、脆弱性管理計画の一環として、KEVカタログの脆弱性に直ちに対処する要件を含めることを強く推奨します。これにより、サイバーセキュリティ共同体全体での集団的レジリエンスが構築されます。

組織はKEVカタログをどのように使用するべきですか？ 見出しへのリンク

KEVカタログは、脆弱性のうち、攻撃者の活動を基づき直ちに危害を及ぼしつつある部分集合に対する修復作業を優先するよう、全ての組織に明確な形で伝えるものです。組織は、脆弱性管理の優先度付与フレームワークへの入力として、KEVカタログを使用する必要があります。利害関係者固有脆弱性分類（SSVC: Stakeholder-Specific Vulnerability Categorization）モデル等の脆弱性管理フレームワークは脆弱性の悪用状況を考慮しており、KEVカタログはその情報の信頼できるリポジトリとして用いられます。組織は、KEVの脆弱性を自動的に組み込み、フラグを立てたり優先度を付与したりする、自動化された脆弱性・パッチ管理ツールの使用も検討するべきです。そのようなツールの例には、CISAのサイバー衛生サービス、Palo Alto Networks Cortex、Tenable Nessus、Runecast、Qualys VMDR、Wiz、Rapid7 InsightVM、及びRapid7 Nexposeが含まれます。これらの他のKEVの脆弱性を組み込んだツールを提供している組織は、[email protected]に電子メールを送信することで、上記に追記されることができます。 次節では、KEVカタログ更新にあたっての3つの閾値それぞれの背後にある判断基準について詳しく説明します。それらは以下のとおりです。

  • 脆弱性に共通脆弱性識別子（CVE: Common Vulnerabilities and Exposures）のIDが付与されていること。
  • 脆弱性が実際に積極的に悪用されているという信頼できる証拠があること。
  • ベンダ提供の更新プログラム等、脆弱性に対する明確な修復行為が存在すること。

判断基準#1 - CVE IDの付与 見出しへのリンク

KEVカタログに脆弱性を追加するための最初の基準は、CVE IDの付与です。CVE ID（CVE識別子、CVE レコード、CVE名、CVE番号及びCVEとしても知られています）は、公に知られているサイバーセキュリティの脆弱性を示す一意の共通識別子です。（https://www.cve.org/ResourcesSupport/FAQsを参照してください。）

CVEプログラムは、CISAの資金提供により、非営利の連邦資金による研究開発センター（FFRDC）によって運営されており、これはThe MITRE Corporationが運用しています。CVEプログラムの使命は、公に開示されているサイバーセキュリティの脆弱性を識別、定義、目録化することです。（https://www.cve.org/About/Overviewを参照してください。）

CVE IDを取得するプロセスは、潜在的なサイバーセキュリティの脆弱性を発見することから始まります。発見後、この情報には、CVE採番機関（CNA: CVE Numbering Authority）によってCVE IDが付与されます。（https://www.cve.org/About/Process#CVERecordLifecycleを参照してください。）CNAは、それぞれ異なる事前合意された範囲内の製品に影響を与える脆弱性に、CVE IDを付与し、入力することを承認された組織です。CNAになることは志願制によります。CNAには、ソフトウェアベンダー、オープンソースプロジェクト、コーディネーションセンター、脆弱性報奨金サービスプロバイダー、または研究会が含まれます。（https://www.cve.org/ProgramOrganization/CNAsを参照してください。）

CNAが説明文と参考文書を含むCVEレコードを作成した後、MITREはそれをCVEウェブサイトに投稿します。（https://www.cve.org/About/Process#CVERecordLifecycleを参照してください。）

MITRE CVEリスト（CVE® List）ウェブサイトhttps://cve.mitre.org/cve及び米国国立標準技術研究所（NIST: national Institute of Standards and Technology）により運営される米国国家脆弱性データベース（NVD: National Vulnerability Database）https://nvd.nist.gov/ウェブサイトは、付与された全てのCVEの最新の一覧を提供します。NVDはCVEと同期されており、CVEへの全ての更新はNVDに直ちに反映されます。NVDはCVEリストによって提供される情報を、セキュリティチェックリストの参考文書、セキュリティ関連のソフトウェアの欠陥、誤構成、製品名、影響指標、及び検索エンジンのデータベースで補強します。（https://nvd.nist.gov/general/FAQ-Sections/General-FAQsを参照してください。）

https://www.cve.org/About/Process#CVERecordLifecycleによると、CVE記事は次の3つの状態のいずれかにあります。

  1. 予約済み（Reserved）。CVEレコードの初期状態で、紐付けられたCVE IDがCNAによって予約された時点。CVE レコードが予約済みと表示されている場合、訪問者/利用者はhttps://cveform.mitre.org/を介してMITREにCVE要求を送信し、CVE レコードの公開を依頼できます。フォームでは、「依頼種別」（Request Type）としては「その他」（Others）、「意見の種類」（Type of comment）としては「問題」（Issue）を選択します。
  2. 公開済み（Published）。CNAがCVE IDに紐付けられたデータをCVEレコードとして入力した時点で、CVEレコードの状態は公開済みになります。関連データには、識別番号（CVE ID）、自由形式の説明文、及び少なくとも1つの公開参考文書が含まれている必要があります。
  3. 否決済み（Rejected）。CVE ID及びそれに紐付けられたCVEレコードが使用されるべきではなくなった場合、CVEレコードは否決済み状態にされます。否決済みのCVE レコードはCVEリストに残り、これにより利用者はそれが無効であることを知ることができます。

判断基準#2 - 積極的な悪用 見出しへのリンク

「悪用可能」という用語は、攻撃者が脆弱性をいかに容易に利用できるかを表します。公開されている概念実証コード（PoC: proof-of-concept）が有るか、ネットワークからのアクセスが可能か、特権によらないアクセスか、ワーム利用可能か、悪用コードの実行に必要な技術レベル等、様々な側面を評価します。ワーム利用可能とは、利用者の介入無しに、あるマシンから別のマシンに広がりうるサイバー攻撃を指します。脆弱性の悪用可能性の分析は、脆弱性の深刻度を判断するのに役立ちます。

ただし、脆弱性の悪用可能性は、KEVカタログに含める判断基準とは見なされません。むしろ、KEVカタログに含まれるための主たる基準は、脆弱性が悪用されたか、又は積極的な悪用下にあるかどうかです。これら2つの用語は、脆弱性を利用しようとする者による悪意あるコードの使用を指します。KEVカタログの文脈においては、積極的な悪用と悪用されたは同義語です。

積極的な悪用下にある脆弱性とは、悪意あるコードの実行がシステム所有者の許可なしにシステム上の活動者によって行われたという信頼できる証拠がある脆弱性です。

積極的な悪用には、KEVカタログの文脈においては、悪用の試みと悪用の成功が含まれます。

  • 悪用の試みは、攻撃者が標的のシステム上でコードを実行するが、システムが脆弱ではないか、又はシステムがハニーポットである等の理由でコードが実行されない場合に発生します。ハニーポットは、検知する、反らす、又はその他の方法により、情報システムの不正使用の試みに対抗するためのコンピュータセキュリティ機構です。ハニーポット上での悪意あるコードの実行の成功は、攻撃者が実際の標的の情報を取得しないため、悪用の試みと見なされます。
  • 悪用の成功は、攻撃者が標的のシステム上で脆弱なコードの悪用に成功した場合に発生し、これにより攻撃者はそのシステム又はネットワーク上で追加の不正な活動を行えるようになります。

積極的な悪用の2つの重要なポイントは、活動者の意図は悪用を成功させることであることと、攻撃は現在進行形で、つまり、「実際に」発生したことです。

積極的な悪用とは見なされない事象には、KEVカタログの関連では、次のようなものがあります。

  • スキャン行為
  • 悪用コードのセキュリティ研究
  • 概念実証コード（PoC）

PoCは、実行された場合に悪用が可能となる、脆弱性に対応するコードです。セキュリティ研究者とベンダー間のPoCの交換は定常的に行われ、脆弱性を悪用する方法を実証し、ベンダーが脆弱性に対するパッチを開発するのを支援します。PoCを公開すると、攻撃者が実際に脆弱性を悪用する可能性が高くなります。ただし、PoCが公開されたからといって、脆弱性が悪用された、または悪用される可能性があることを自動的に示すわけではありません。PoCが公開されていることは、KEVカタログに脆弱性を含めるための要件ではありません。

判断基準#3 - 明確な修復手引 見出しへのリンク

CISAは、影響を受けた組織が取るべき明確な行為がある場合に、既知の悪用された脆弱性をカタログに追加します。BOD 22-01で触れられている是正措置では、連邦文民行政機関（FCEB）当局がKEVの全ての脆弱性に対して次の措置を講じることを要求しており、CISAは全ての組織が同じことを行うことを強く推奨しています。

  • ベンダーの指示に従って更新プログラムを適用する。セキュリティベンダーから入手可能な更新プログラムが存在しており、利用者はそれを適用するべきです。
  • 影響を受けた製品がサポート終了（end-of-life）であるか、その他の理由により更新できない場合は、当局のネットワークから取り除く。

緩和策は、脆弱性の悪用を防ぐために利用者が実装できる一時的な解決策です。例としては、無停電電源装置に対する攻撃の軽減を参照してください。これは、無停電電源装置（UPS）機器の悪用を防止するためのベストプラクティスの手引きを提供します。

回避策では、ベンダーが正式なセキュリティパッチを提供するまでの間、脆弱なシステムを悪用から保護するために、影響を受けた製品への手動での変更を実装する必要があります。回避策から公式パッチに、利用可能になり次第移行することが利用者におけるベストプラクティスです。ただし、回避策を実装することは、製品を脆弱なままにしておくこととは対照的に、推奨されています。

注：CISAは、サイバーセキュリティ共同体へのサービスを改善するにあたり、利害関係者のフィードバックに依存しています。KEVカタログの判断基準とプロセスに関するフィードバックを提供するには、[email protected]に電子メールを送信してください。