ブリーチ&アタックシミュレーション(BAS)には、これまで常に一種のサプライチェーンが存在していました。誰かが脅威レポートを読み込み、そこから攻撃手法を抽出し、実際に自社の対策に対して実行できる形に落とし込む必要があります。その「誰か」は、これまでずっと人間のレッドチームでした。数か月前まで、新たな主要脅威を24時間以内に実際に動くシミュレーションコンテンツへと変換できれば、それは非常に速いとみなされていました。
フロンティアAIモデルの登場が、この対称性を崩しました。ポストMythos時代に入り、タイムラインは劇的に変化しています。公開から実際に悪用可能なエクスプロイトが登場するまでの時間は、わずか10時間程度にまで短縮され、毎日130件を超える新たなCVEが出現しています。混乱に拍車をかけるように、開示された脆弱性のうち上流でパッチが適用されるのは0.5%未満にとどまります。実運用環境にデプロイされるコードの多くは、防御側がまだ評価している最中の同クラスのモデルによって組み立てられたものです。そして、パイプラインの片側だけが自動化されている状況では、そのギャップは一定に保たれるどころか、むしろ拡大の一途をたどっています。
だからこそ、BASを「より頻繁に実行する」のではなく「アップグレードする」ことが求められているのです。
3億3,800万件の攻撃シミュレーションが明らかにしたこと
Picus Blue Report 2026は、2026年上半期に顧客の実運用環境でBASによって実行された3億3,800万件の攻撃シミュレーションを集計したものです。防御効果の平均は69%で、およそ3分の1の攻撃が、本来それを阻止するために導入された対策をすり抜けていたことになります。ログ記録は過去4年で最高水準に達し、攻撃アクションの58%がSIEMに記録された一方で、アラートスコアは14%のまま変化していませんでした。
レポートによると、検知ルールの失敗は主に2つの原因に集約されるといいます。パフォーマンス上の問題は49%と首位に立ち、昨年時点のわずか24%から倍増しました。ログ収集のギャップはさらに41%を占めており、こちらのほうがより厄介です。というのも、これは静かに失敗するためです。挙動そのものが記録されないので、どんなルールも発火しようがないのです。
これらはいずれも、設定と運用上の問題です。「製品が悪い」という話は一つもなく、また、別の製品を新たに購入すれば解決するというものでもありません。
この最後の一文は重要です。というのも、マシン速度の攻撃者に対する業界の反射的な回答は、決まってもう一つの製品購入、すなわちマシン速度の防御=AI SOCだからです。AI SOCが処理する単位は「アラート」です。ところが、7回の攻撃のうち1回しかアラートを生成しないパイプラインにAI SOCを投入しても、その1回をどれだけ高速に処理できたとしても、残りの6回は依然として見えないままです。そもそも発火しないアラートを、自律システムがトリアージすることはできません。AIにAIで対抗する戦いは、まずアラートを生み出す検知エンジニアリングの上流から始まる必要があります。そして、検証プログラムがその負荷を軽くするのか、それとも増やすのかという点にこそ、第一世代のBASの限界が表れ始めています。
第一世代BASが行き詰まる理由
現在多くの企業が運用しているBASは、マシン速度の攻撃者が登場する以前に設計されたものです。そこには構造的な限界が3つあり、そのいずれもが今では大きな重荷となっています。
1つ目は、トリガーがカレンダーであることです。スケジュール実行型のプログラムはある時点でのスナップショット的な結果しか生み出さず、実行と実行の間に、証明したはずの結果は静かに失効していきます。ファイアウォールの整理やEDRエージェントのアップデートが、先月合格したはずの結果を知らぬ間に覆してしまい、その乖離は偶然、あるいはインシデントレビューの中で表面化するのであって、プログラム自体が検知することはありません。今年のBlue Reportは、この劣化の速さを示しています。平均防御率はわずか1年で7ポイント下落し、翌年にはまた取り戻しましたが、その最大の違いは単に「誰がテストを継続していたか」でした。優れた防御力は、所有するものではなく、いわば借り物にすぎないのです。
2つ目は、CVEに関する問いに答えられないことです。「昨夜KEVに追加された脆弱性、うちの環境では検知できるのか?」という問いは、もはや毎日のように寄せられます。すべてにパッチを当てることは不可能だからです。手作業での回答には1件のCVEあたり4~6時間かかります。アドバイザリを読み、SIEMをgrepし、「対応するルールはある」というカバレッジマップを信じるほかありません。結果として、最も重大なCVEしか問い合わせの対象にならず、残りのリストは検証されないまま放置されます。Blue Reportは、その行き着く先を示しています。今年最も防御できなかったワースト10の脆弱性は、いずれもブラウザ、アーカイブユーティリティ、OpenSSL、コアOSコンポーネントといった日常的なソフトウェアに存在し、それぞれのブロック率は25%を下回っていました。自動ペネトレーションテストも、この問題は解決できません。動作するエクスプロイトが必要になりますが、開示初日にはそれが存在しないからです。
3つ目は、テスト後のすべての工程が人手の時間で価格付けされていることです。検出結果は、汎用的なガイダンスとリンクだけを添えてキューに積まれ、それをNGFWが受け入れる形のシグネチャや、SIEMが実際に発火するルールへと翻訳するという本当の作業は、エンジニアの肩にのしかかります。露出箇所を見つけること自体は、これまでも難しい部分ではありませんでした。アラートスコアが14%で頭打ちになっているという現実は、誰もがこのプログラムを求めながら、誰もそれに人員を割けていないという、検知エンジニアリングの実態を映し出しています。検証をより頻繁に実行しても、キューが長くなるだけなのです。
フロンティアAIモデルの時代にBASが備えるべき姿
エージェント型BASとは、ブリーチ&アタックシミュレーションをエージェントによる閉じたループとして実行する仕組みです。シグナルが必要なテストを正確に発火させ、検出されたギャップにはそれぞれベンダー固有の修正が用意されてデプロイ・再検証され、人間はループの中に入り込むのではなく、意思決定のゲートに立って監督する立場になります。
ループの形自体は変わりません。シミュレーション、検証、修正、再検証というサイクルです。変わるのは、そこに何が投入され、何が引き金となり、誰がそれを動かすかという点です。
- 脅威は自ら組み立てられます。AI Threat Builderが、自社のCTIフィードやオープンソースインテリジェンスから数分で次の攻撃キャンペーンを組み立てます。
- シミュレーションは自動的かつ安全に、実運用中の対策に対して自ら起動します。これにより、静かな失敗はそれが生まれたその日のうちに表面化します。
- 修正はそのままチームに届きます。検知内容はスタックにデプロイされ、防御ルールは自動的にSecOps宛てのチケットとして起票されます。人間は監督し、エージェントが実行し、いつ動くかはシグナルが決めます。
これこそが、人間がループを監督する形でのマシン速度の対応です。アラートが実際に発火することを証明し、発火しない場合にはルールを届けます。
その手法は挙動ベースです。エクスプロイトの実行自体をシミュレートするため、実際のエクスプロイトが存在する前から脅威を検証できます。そして成果は「クローズ」という形で表れます。閉じられ、再検証されたギャップは、単に報告されただけのギャップとはまったく異なる成果物なのです。
自律性はワークフローごとに調整可能で、手動、監督付き、完全自律のいずれも選べますが、根底には「機械がリスクを引き受けることは決してない」という一貫したルールがあります。そして自動ペネトレーションテストは、このループをそもそも回すことができませんし、その3つの保証、すなわち実運用へのリスクゼロ、SOCへのノイズゼロ、人員数に応じて課金されないスケーラビリティにも太刀打ちできません。
「翻訳」という課題
Picusのアプローチでは、アナリストが受け取るのと同じ形で脅威インテリジェンスを取り込みます。CISAのアラート、ブログのURL、PDF、CVE ID、あるいはScattered Spiderのような脅威アクター名を入力するだけでも構いません。キーワードマッチングに頼るのではなく、情報源を実際に読み込んで攻撃チェーンそのものを理解し、およそ9分でATT&CKにマッピングされた実行可能なシミュレーションを組み立てます。
エクスプロイトの実行は挙動レベルでシミュレートされるため、実際に動作するエクスプロイトは不要です。KEVへのエントリはそれが公開された当日の朝には検証可能となり、答えはもはや一部の重大なCVEだけに限定されません。関連するすべての脆弱性について、ブロック済み、検知済み、あるいは隠れた残存リスクありのいずれかの結果が返され、パッチ適用を待つ必要がある場合には、既存のツール向けの代替ルールも提示されます。脅威グループについても同様です。そのグループがまさに使う手口が、その日のうちに実運用中の対策に対して実行され、各TTPはブロック済み・アラート済み・記録済み・検知漏れのいずれかに分類され、ギャップにはそれぞれ修正が付随します。そしてBASは天井ではなく土台であるべきです。同じループが自律型ペネトレーションテストやエクスポージャー検証と組み合わさることで、何かを買い直したり配備し直したりすることなく、対策検証を本格的なエクスポージャー検証プログラムへと発展させることができます。
実際に実行されるのは、決してモデルの生の出力そのものではありません。Picus脅威ライブラリで検証済みのコンテンツのみが、実運用環境で安全に実行されます。このエンジンは、Anthropicのサイバー検証プログラムのもとで検証されたフロンティアアクセスを基盤に動作しており、自社のエージェントからも、当社のMCP APIを通じて同じワークフローを操作できます。次の攻撃はAI主導のものになるでしょう。だからこそ、防御側もAI主導でなければならないのです。
AI時代のBASを、単なる「頻度アップ」から分けるものとは
その違いは5つあり、いずれも「実行頻度」の話ではありません。
- 実行のきっかけがスケジュールではなくシグナルであること。変化そのものがテストを起動します。
- 新たなCVEは、手元にエクスプロイトがなくても、公開された当日から検証可能です。
- 検知漏れは、トリアージすべき単なる発見事項としてではなく、原因が診断された状態で戻ってきます。テレメトリの問題なのか、ルールロジックの問題なのか、パフォーマンスの問題なのかが明らかになります。
- すべてのギャップにベンダー固有の修正が付随します。人間が承認し、機械がデプロイし、同じ攻撃で再検証します。
- 継続的な検証が、もはやエンジニアの工数で価格付けされなくなります。
Picusを含め、どのベンダーであっても、この5点をスライドの上だけでなく実際にライブで示す用意があってしかるべきです。限定的なパイロットを実施すれば、1週間で見極めがつきます。1つのセグメントに数体のエージェントを配置し、SIEMへの読み取り専用アクセスを与え、その日のうちに攻撃を実行するだけです。経営層からフロンティアAIを活用した攻撃への備えについて問われたとき、もはやそれは単なる見解ではなく、記録に残るトレンドを伴った検証済みの結果として答えられるようになります。
実際のアップグレードが何を意味するのか、そしてカレンダー主導からシグナル主導へとチームがゼロからやり直すことなく移行するにはどうすればよいのか、その具体像を知りたい方は、ぜひ私たちにご相談ください。アップグレードによって実際に何が得られるのかをお話しします。
翻訳元: https://www.helpnetsecurity.com/2026/09/09/picus-security-autonomous-breach-attack-simulation/
