リスクベースのパッチ適用が未来を切り拓く。AIがそれを必須要件に変えた

AIがゲームのルールを変えました。賢いセキュリティとは、あらゆる脆弱性にパッチを当てることではなく、最も重要な攻撃経路を止めることです。

CISAの新しい拘束力のある運用指令(BOD 26-04)は、ここ数年で連邦政府の脆弱性管理における最も重要な変化の一つとなっています。すべての重大な脆弱性に対して各機関に同一のスケジュールでのパッチ適用を求めるのではなく、この指令はリスクに基づいて修復に優先順位を付け、パッチ適用の期限は最もリスクの高い脆弱性については3日間、リスクが最小限のものについては先送りするという幅を持たせています。これは歓迎すべき進化ですが、あくまでスタートラインに立ったに過ぎず、ゴールではありません。

セキュリティチームは、深刻度だけではリスクを判断できないことを長らく認識してきました。CVEスコアは、その脆弱性がインターネットから到達可能かどうか、実際に悪用されているかどうか、自動化が可能かどうか、あるいは攻撃者にアセットの制御権を与えるかどうかについては、ほとんど何も語りません。BOD 26-04は、組織に対してまず悪用される可能性が最も高いエクスポージャーに注力するよう指示することで、リスクが文脈依存的な性質を持つことを認めています。

しかしAIは攻撃ライフサイクルのあらゆる段階を圧縮し、脆弱性管理の実践が追いつけないスピードで脅威の状況を変化させています。CrowdStrikeの報告によれば、eCrimeによる侵害の平均ブレイクアウト時間(初期の横展開までの時間)はわずか29分にまで短縮しており、観測された最速のブレイクアウトはわずか27秒でした。攻撃者はいったん足がかりを築くと、Mandiantの調査によれば、オペレーター間でアクセス権を引き継ぐのに中央値でわずか22秒しかかかっていません。

同時に、AI自体も攻撃対象領域として拡大しています。各組織はコパイロットやブラウザエージェント、自律的なワークフローなどAIを活用したシステムを急速に導入しており、それに伴いプロンプトやプラグイン、コネクタ、インテグレーションといった保護が必要な要素が新たに生まれています。

このような背景を踏まえると、この指令が最もリスクの高いエクスポージャーに設けた3日間という修復期限は、もはや野心的な目標というよりも、贅沢な猶予に近いものに見えてきます。

今日の攻撃者は、単にCVEを悪用するだけではありません。脆弱性を盗まれた認証情報、クラウドの設定ミス、露出したAPI、SaaSの弱点、そして近年ではAIシステムと組み合わせることで、重要なアセットへの攻撃経路を構築します。BOD 26-04は前進をもたらしますが、AIが防御側に求めているのは既存のプロセスを単に加速させることではなく、根本から見直すことです。

AIはサイバー攻撃のテンポと経済性を変えた

攻撃者にとってAIがもたらす最大の利点の一つは、以前は複数の人間のオペレーターによるチームを必要としていた作業を自動化できる点です。偵察、脆弱性調査、エクスプロイトの生成、フィッシング、認証情報の窃取、さらには横展開の一部までもが、今やAIによって加速され、場合によってはほぼオーケストレーションされるようになっています。

最近の調査では、人間が大きな目的を監督する一方で、自律的なエージェントが高度なサイバー作戦における運用作業の大部分を担っている実態が明らかになりました。その結果、攻撃キャンペーンの規模拡大がより容易かつ低コストになり、同時に狙える標的の数も増え、攻撃者は防御側が探査に気づく前に、環境への侵入経路をはるかに多く試すことができるようになっています。

長年、脆弱性管理は、組織がセキュリティ問題を特定し、優先順位を付け、修復するまでに数週間、場合によっては数か月の猶予があるという前提に立っていました。しかしその前提は、もはや現実を反映していません。攻撃者は初期アクセスから横展開まで1時間足らずで移行するのが常態化しており、脆弱性は公開後間もなく悪用されるケースが増えているだけでなく、場合によっては防御側が評価を始める前に兵器化されてしまうこともあります。

だからこそ、CISAがリスクベースの修復へと舵を切ったことが重要なのです。悪用可能性と運用上のリスクに基づいて脆弱性に優先順位を付けることで、防御側は自分たちに対して使われる可能性が最も高い問題に対処できる確率が大きく高まります。しかし、脆弱性は今日のエクスポージャー環境を構成する要素のほんの一部に過ぎません。

現代の攻撃は「発見事項」ではなく「経路」をたどる

多くのセキュリティ組織は今なお、専門チームごとに責任範囲を分割しています。脆弱性管理チームはCVEに注力し、IDチームは認証と権限に集中し、クラウドセキュリティチームは設定を担当し、アプリケーションセキュリティチームはコードをレビューします。

しかし攻撃者は、そうした境界線に沿って行動するわけではありません。彼らの目的は、利用可能などのような経路を使ってでも価値あるアセットに到達することです。ある攻撃キャンペーンは、露出した脆弱性、盗まれた認証情報、過剰なクラウド権限、設定ミスのあるSaaSアプリケーション、あるいは侵害されたAIエージェントから始まることがあります。そして多くの場合、これらの条件のうち複数が組み合わさっています。例えば2026年のVerizonの侵害レポートによれば、昨年の初期侵害の31%は脆弱性が原因だった一方、攻撃連鎖の39%はID関連の問題を伴っていました。注目すべき侵害事例のいずれにおいても、攻撃者はさまざまな種類のエクスポージャーを連鎖させてネットワーク内部へと進んでいます。

権限の低いアカウントを侵害した攻撃者が、過剰な権限を持つIDを発見し、クラウドワークロードを足がかりに横展開し、脆弱なアプリケーションを悪用して、最終的に機密性の高い業務システムへのアクセスを獲得する、ということがあります。それぞれの脆弱性を個別に見れば、致命的には見えないかもしれません。しかしそれらが組み合わさることで、実行可能な攻撃経路が形成されるのです。

侵害は常にさまざまなエクスポージャーの連鎖であり、脆弱性は実際に侵害がどのように起きるかを説明するストーリーの一部に過ぎません。ここに、脆弱性中心のセキュリティが機能しなくなり始める理由があります。CrowdStrikeはまた、ベンダーが発表する前に悪用された脆弱性が前年比42%増加したことも報告しています。つまり、何百もの重大度の高い発見事項をひたすら潰し続けている組織であっても、攻撃者が重要なアセットに到達するために取る最も現実的な経路を封じるために必要な文脈情報を欠いていれば、結局は侵害されてしまうということです。

組織は「侵害は必ず起きる」という前提に立ち、攻撃者が最終的に初期の足がかりを得る可能性に備えて計画を立てるべきです。セキュリティアーキテクチャは可能な限りセグメント化し、その初期侵害の後に攻撃者、あるいは侵害されたAIエージェントがどこまで移動できるかを制限すべきです。そしてセキュリティ対策は、導入に成功したからといって有効だと決めつけるのではなく、継続的に検証されるべきです。

こうした原則は、個々の発見事項から、攻撃を成功させる条件そのものへと注意を向けさせます。

防御側はどう適応すべきか:継続的な評価と検証

この移行を実現する実践的な方法の一つが、継続的脅威エクスポージャー管理(CTEM)プログラムの導入に本腰を入れることです。これは、エクスポージャーを理解し低減し続けるための継続的なプロセスを確立するものです。

その出発点となるのは、多くの組織が今なお維持に苦戦している、環境に対する最新の理解です。つまり、アセット、ID、クラウドインフラ、SaaSアプリケーション、AIシステム、そしてそれらの間の関係性を継続的にマッピングすることを意味します。そこから、セキュリティチームはエクスポージャーを特定し、悪用可能性とビジネスへの影響に応じて優先順位を付け、それらが実際に到達可能かどうかを検証し、運用チーム全体での修復を推進できるようになります。

この継続的なサイクルは、Mandiantが「防御側の優位性」と呼ぶものを取り戻します。攻撃者は、見知らぬ環境を悪用する前に、まずそれを発見しなければなりません。防御側はすでにその知識を持っているはずです――少なくとも、持っているべきです。課題は、クラウドサービスやID、AIアプリケーション、業務システムが日々進化する中で、その知識を常に最新の状態に保つことにあります。

検証をプロセスに組み込む

セキュリティチームはまた、特定したエクスポージャーが実際に悪用可能かどうか、そして修復の取り組みが意味のあるリスクを本当に排除できたかどうかを検証する必要があります。

ここで、敵対者の視点を取り入れたエクスポージャー検証が、プロセスに不可欠な要素となります。侵害・攻撃シミュレーション、自動化されたペネトレーションテスト、攻撃経路分析といった技術を用いれば、実際の攻撃者に似た手法を使って環境を継続的にテストできます。

エクスポージャー検証が答えるのは、「脆弱性が存在するかどうか」ではなく、より実践的な問いです。攻撃者はそこに到達できるのか。それを悪用できるのか。そこを足がかりに、ビジネスが本当に重視するものへとピボットできるのか。同様に重要なのは、検証によって、修復の取り組みがダッシュボード上の発見件数を減らしただけなのか、それとも本当に侵入口を閉ざせたのかを確認できるという点です。

ダッシュボードではなくビジネスを優先する

検証は、ビジネス上の文脈と組み合わせることで、さらに大きな価値を持ちます。収益を生むアプリケーションや規制対象データ、重要な業務システムに影響を与える中程度の深刻度の弱点は、孤立した開発環境に影響を与える複数の重大な脆弱性よりも、組織にとって大きなリスクとなる場合があります。

検証済みのエクスポージャーをビジネスへの影響度に応じて優先順位付けすることで、セキュリティリーダーは技術的な言葉ではなく、業務的な言葉で経営層に説明できる修復戦略を手にすることができます。さらに重要なのは、それによって防御の取り組みを、組織に影響を与える可能性が最も高い攻撃経路と一致させられることです。

BOD 26-04は重要な前進です。しかしAIはすでに、リスクベースのパッチ適用を必須要件に変えてしまいました。AIの時代に成功を収める組織とは、必ずしも最も速くパッチを適用する組織ではありません。攻撃者よりも自分たちのエクスポージャーを深く理解している組織こそが、成功を収めることになるでしょう。

本記事はFoundry Expert Contributor Networkの一環として掲載されています。
参加をご希望ですか?

翻訳元: https://www.csoonline.com/article/4202381/risk-based-patching-is-the-future-ai-made-it-table-stakes.html

ソース: csoonline.com