CVEを超えて:脆弱性管理では重大度よりコンテキストが重要な理由
By Mirko Peters ·
ブログへのご訪問ありがとうございます。何百、何千もの Common Vulnerabilities and Exposures (CVEs) が並んだ脆弱性スキャナーのレポートを前に途方に暮れたことがあるなら、あなたは…
Automatically translated with AI from the original post. Read the English original

ブログへようこそ。数百から数千件の共通脆弱性識別子(CVE)が並んだ脆弱性スキャナーのレポートを前に途方に暮れたことがあるなら、情報過多による重苦しさは既にご存じでしょう。CVSSスコアの高い順に並べて、上から対応していくのが最も賢い方法に思えるかもしれません。しかし、現代のエンタープライズセキュリティでは、そのやり方は無駄な作業の深みにはまり込む一方で、実際の脅威に対して組織を本当に無防備なままにしてしまいます。先日のポッドキャストでは、まさにこの課題を掘り下げました。音声による全体の内容は、関連エピソードのMicrosoft Defender Vulnerability Management - Simply Explainedでお聞きいただけます。本記事では、そのコンセプトをさらに広げ、技術的な重大度だけでなく、なぜコンテキストこそが効果的な脆弱性管理の鍵なのかを探っていきます。
パッチ管理と脆弱性管理の違い
強靭なセキュリティプログラムを構築するには、まず よくある誤解を解消しておく必要があります。パッチ管理と脆弱性管理は同じものではありません。パッチ管理は、本質的には修正の適用に焦点を当てた運用上の作業です。Windows の更新、新しいブラウザーバージョンのインストール、古いソフトウェアの削除、システム構成の変更などがこれにあたります。既知の問題を修正する「方法」といえます。
一方、脆弱性管理はより広く戦略的な問いに答えるものです。どの問題から優先して対処すべきか。実際にどの程度緊急なのか。影響を受けているのはどのデバイスか。修正プロセスの責任者は誰か。そして最も重要なのは、修正を適用した後に、その脆弱性が本当に解消されたかどうかです。
実際にありそうなシナリオを考えてみてください。研究室にある、ネットワークから切り離されたオフラインのテストマシンに重大な CVE が検出されているとします。同じ時期に、経理部門が毎日使用するノートPCには、重大度が中程度の脆弱性が残っています。このデバイスは機密性の高いデータを扱い、外部ネットワークに接続され、活動中の脅威アクターにさらされています。CVSSスコアだけに頼れば、まずテストマシンの修正に時間を費やすことになるでしょう。しかし実際の組織リスクという点では、経理部門のノートPCの方がはるかに大きな危険をはらんでいます。重大度は確かに重要です。ただし、コンテキストの重要性はそれをはるかに上回ります。
検出:実際に何を保有しているかを把握する
優先順位付けや修正を行う前に、セキュリティチームとIT チームは環境全体を網羅的に可視化しておく必要があります。存在を把握していないものは保護できません。Microsoft Defender Vulnerability Management のような最新のツールは、古いソフトウェア、欠落している更新プログラム、安全でない構成、その他のセキュリティ上のギャップを含め、デバイス全体の脆弱性を継続的に追跡します。
デバイスとソフトウェアの在庫における欠落
多くの組織では、資産インベントリに死角が生じがちです。従来の定期スキャンでは、動的に変化する資産や新たに接続された資産を見落とすことがよくあります。Defender は、エンドポイントから継続的に送られるシグナルを活用して、オンボードされたすべてのデバイスについて、オペレーティングシステム、インストールされているソフトウェアのバージョン、既知の脆弱性を把握します。さらに、デバイスの検出機能では、管理対象のエンドポイントを使ってローカルネットワーク上で見えている他のシステムを探り出します。隅に隠れている野良プリンター、忘れられたルーター、管理されていないワークステーションも、ようやく明るみに出すことができます。
ハードウェアだけでなく、正確なソフトウェアインベントリを構築することも極めて重要です。数百台のコンピューターを一台ずつ手作業で監査する代わりに、セキュリティチームは脆弱なアプリケーションを特定し、それを実行しているすべてのデバイスを即座に確認できます。逆に、特定のマシンを掘り下げて、そこにインストールされているソフトウェアをすべて監査することもできます。この粒度の高い可視化により、セキュリティ運用は手作業の限界をはるかに超えて拡張できます。
ソフトウェアパッチを超えて
脆弱性管理は、従来のデスクトップアプリケーションへのパッチ適用をはるかに超える範囲を対象とします。ライセンスや構成によっては、最新のプラットフォームでデジタル証明書、ブラウザー拡張機能、ファームウェア、ハードウェアのセキュリティ構成、ネットワーク共有も評価できます。場合によっては、正しい是正措置がソフトウェアの更新プログラムのインストールではないこともあります。危険な構成の変更、不要なアプリケーションの削除、ネットワークアクセスの制限、老朽化したハードウェアの交換などが必要になることもあります。
優先順位付け: 最初に修正すべきものは何か
検出が完了すると、チームには必ず大量のデータが押し寄せます。ここで優先順位付けが頼りになります。CVSS は有用な基準の重大度評価を示しますが、自社のビジネス環境は考慮されていません。
高度な脆弱性管理ツールは、判断に欠かせないコンテキストを加えます。実際に攻撃に使えるパブリックなエクスプロイトは存在するか。その脆弱性は脅威アクターによって実際に悪用されているか。社内ネットワークで関連するセキュリティアラートがすでに発生していないか。影響を受けるデバイスは何台あり、それらのデバイスはビジネス上どのような役割を担っているか。判断の問いは、「どの CVE のスコアが最も高いか」から、「どの脆弱性が自社にとって最も現実的なリスクをもたらすか」へと変わります。
露出スコア、セキュリティ スコア、およびセキュリティの推奨事項
この露出度を測定するために、ツールは組織の露出スコアを提供します。スコアは低いほど望ましいものの、脆弱性が完全にないことを保証する絶対的な指標として解釈すべきではありません。これに加えて、デバイスのセキュリティ構成と推奨される保護機能を評価する「デバイスのセキュリティ スコア」があります。これらの指標により、チームは時間の経過に伴う改善を追跡できますが、実行可能なセキュリティの推奨事項と組み合わせる必要があります。
実行可能な推奨事項は、特定の脆弱性を、影響を受けるソフトウェア、露出しているデバイス、具体的な是正手順と結び付けます。ここではコンテキストがすべてを左右します。深いアーカイブ ディレクトリ内に眠り、使われていない脆弱なファイルと、ネットワークトラフィックを待ち受けてユーザー要求を処理している、実際に稼働中の脆弱なソフトウェアとでは、リスクの性質がまったく異なります。
脅威分析を活用したより賢い優先順位付け
最新の脆弱性管理は、脅威インテリジェンス プラットフォームと直接統合されます。新たなゼロデイ脆弱性がニュースになったとき、セキュリティ チームは自社への影響を推測する必要はありません。脅威分析を活用して、自社が影響を受けているかどうかを確認し、露出しているデバイスを特定し、関連するアラートを確認し、公式パッチを待つ間に一時的な軽減策を展開できます。これこそ、がむしゃらに働くのではなく、賢く働くということです。
是正: 検出結果を実行可能な作業に変える
リスクを特定して優先順位を付けることは、戦いの半分にすぎません。検出結果は具体的な行動に移す必要があります。脆弱性管理ツールは、単独で万能のパッチ適用エンジンとなることはほとんどありません。その役割は、特定、優先順位付け、追跡、検証です。実際の展開という大変な作業は、多くの場合、Microsoft Intune、ServiceNow、その他の IT チケット管理システムなどのプラットフォームが担います。
Defender と Intune によるセキュリティと IT の橋渡し
Microsoft Defender などのセキュリティ ツールと Microsoft Intune などの管理ソリューションを接続することで、組織はセキュリティ チームと IT 管理者の間に従来存在していた溝を埋めることができます。セキュリティ チームはリスクを特定して優先順位を付け、デバイス管理チームは業務を妨げることなく変更を展開する最も安全な方法を決定します。
たとえば、重大なブラウザーの更新プログラムをすべてのエンドポイントに同時に配布すると、カスタム Web アプリケーションが動作しなくなるおそれがあります。そのため IT 部門は、まず小規模なパイロット グループを対象にすることができます。互換性が確認できたら、更新プログラムを段階的に展開します。この共同作業のワークフローは、セキュリティ体制を維持しながら、ダウンタイムを防ぎます。
例外、軽減策、および検証の処理
実際の現場では、すべての脆弱性を直ちに修正できるわけではありません。レガシー アプリケーションは古い依存関係に頼っていることがあり、ベンダーの更新プログラムの提供が遅れることもあり、本番サーバーでは厳格なメンテナンス時間帯が必要になることもあります。こうしたシナリオでは、明確なビジネス上の正当性と厳格な有効期限を備えた、文書化された例外が不可欠です。
恒久的なパッチの適用が遅れる場合は、ネットワーク接続の制限、リスクのあるアプリケーションのブロック、ベンダー提供の回避策の適用などの一時的な緩和策によって、その間も組織を保護します。最後に、検証によって作業が完了していることを確認します。追跡システムでチケットがクローズされても、脆弱性が解消されたことにはなりません。高度なツールがデバイスのシグナルを継続的に監視し、影響を受けたシステムがその脆弱性を実際に報告しなくなったことを確認します。
接続されたセキュリティ エコシステム:コンテキストとデータの機密性
脆弱性管理は、接続されたセキュリティ エコシステムの一部として機能したときに真価を発揮します。エンドポイント検出、デバイス管理、ID システムが相互に連携すると、セキュリティは動的かつ自動化されたものになります。
Microsoft Defender、Intune、Entra ID がどのように連携するかを考えてみてください。デバイスに重大なセキュリティの脆弱性が見つかった場合、Intune はそのデバイスを非準拠としてマークできます。Entra ID の Conditional Access policies は、修復が完了するまで、そのリスクのあるエンドポイントが SharePoint、Teams、Exchange Online などの社内リソースにアクセスするのを自動的に制限できます。技術者が手作業でマシンに触れるずっと前に、脅威は即座に封じ込められます。
さらに一歩進めて、データの機密性も考慮に入れることができます。Microsoft Purview などのツールを使えば、セキュリティチームは機密性の高い財務データや知的財産がどこに存在するかを特定できます。その機密情報を扱うデバイスは、まったく同じ脆弱性を抱える汎用デバイスよりも高い優先度で対処すべきです。技術的な深刻度、脅威インテリジェンス、デバイスのコンテキスト、データの機密性を組み合わせることで、組織はついに真に成熟した脆弱性管理プログラムを実現できます。
最新のエンタープライズ環境をこれらの強力なツールでどのように保護するかについての詳細は、関連するポッドキャストのエピソード Microsoft Defender Vulnerability Management - Simply Explained をぜひご覧ください。お読みいただきありがとうございます。引き続きセキュリティを適切に保ってください。