戦場を守る：エージェント型脅威の時代におけるステートフル検知

執筆者

清水孝郎

利用状況レポートを読む

Published:

September 1, 2026

この記事の内容

本文の内容は、2026年8月31日に Sysdig Teamが投稿したブログ (URL) を元に日本語に翻訳・再構成した内容となっております。

クラウドネイティブ環境を守るには、迅速な対応が不可欠です。

クラウドセキュリティが人的スケールの限界に達しつつあることについては、以前から述べてきました。2026年初頭には大きな変化があり、React2Shellのような攻撃が、脆弱性が公開されてから数時間後に発生するようになりました。これは孤立した事例ではありません。Sysdig 脅威リサーチチーム（TRT）は、AI インフラツールを狙った他の複数の脆弱性についても、同様のパターンを確認しています。それだけでなく、攻撃はますます自動化されており、最初から最後までAI駆動で行われるケースも出てきています。私たちは、わずか8分で管理者権限を獲得したAI支援型攻撃や、3分で認証情報が窃取された事例を確認しています。Sysdig TRT はまた、データベースを破壊的に恐喝するプレイブックを自律的に実行した初のエージェント型ランサムウェアオペレーションであるJADEPUFFERについても報告しています。

だからこそ、ランタイムセキュリティはセーフティネットとしての重要性を増しています。迅速な自動レスポンスを実現するには、高品質なランタイム検知が必要です。

ステートフル検知でノイズを削減

セキュリティチームはしばしば、時間内に対応することに苦労しています。数多くの問題に埋もれ、誤検知のトリアージや個々のセキュリティイベントの調査に多くの時間を費やしているためです。

従来型の検知エンジンは、セキュリティイベントを単体で捉えます。たとえば、コンテナ上でターミナルシェルが開かれるとアラートを発しますが、それが開発者によるアプリのデバッグなのか、悪意ある攻撃者によるものなのかを判断するためのコンテキストを持っていません。この調査は、他のアラートを確認して何が起きたかを追跡できるセキュリティエンジニアに委ねられることになります。

ステートフル検知はこの状況を一変させます。

単一の検知が複数のアクションを関連付けて攻撃者の行動を再構築することで、検知された挙動が悪意あるものである確度を高めます。
このコンテキストがあることで、アナリストに届く前に、正当なアクションと悪意ある挙動を検知が切り分けられます。
その結果、ステートフル検知はトリアージすべきアラートの数を削減します（ノイズ削減）。
アラートにはこうした関連付け情報がすべて含まれているため、調査を迅速化できます。

たとえば、先ほどの「コンテナ上でシェルを開く」という例で考えてみましょう。このイベント自体は、ワークロードをデバッグしている開発者にとってはごく普通の操作である可能性があります。また、/tmpへの書き込みも正当な操作である場合があります。しかし、シェルを開き、バイナリを/tmpにダウンロードして、それを実行するという一連の流れは、ほぼ間違いなく攻撃に該当します。

ステートフル検知の構造

Sysdig の Falco エージェントにおけるステートフル検知は、次のような形になります。

このルールは、コンテナ内でターミナルシェルが開かれ、それを使ってパッケージマネージャーでソフトウェアがインストールされた場合を検知します。

Observation（オブザベーション）は、Falco ルールに対する Sysdig Secure の拡張機能であり、ステートフルな評価を表します。

- macro: spawned_process
  condition: (evt.type in (execve) and evt.dir=< and evt.arg.res=0)

- observation: Launch Process
  condition: spawned_process
  source: syscall

次に、2つのオブザベーションが関連しているかどうかを判定する方法を定義します。たとえば、同じプロセスIDを持っているかどうかなどです。

- obs_link_fields: same_session
  fields:
    - [proc.sid, proc.sid]

その後、Falco ルール内でobs.occursとobs.linkを使うことで、これらのオブザベーションを利用できます。

- rule: Spawn Package Management Program Below Container Exec
  desc: Detect an attempt to run a package management program from a container exec
  condition: >-
    obs.occurs["Terminal shell in container"]=true and
    obs.link["Terminal shell in container-->Spawn Package Management Program, same_session"]=true
…

ステートフル検知についての詳細は、以下をご覧ください。

ステートフル検知の導入率は高い

Sysdig の2026年度版クラウドネイティブセキュリティおよび利用状況レポートによると、組織の70%がステートフル検知を利用していることが分かりました。そして、導入している組織では、クラウド環境の91%にわたってこれを展開しています。

このような高い導入率は、ノイズの削減と調査の迅速化において、この新しいパラダイムがいかに大きな変革をもたらすかを証明しています。

自動化されたレスポンスには信頼が必要

組織は、セキュリティイベントに迅速に対応する上で自動化が果たす役割を理解しています。しかし、ビジネスの運用を致命的に中断させる可能性がある自動レスポンスの導入には自信を持てていません。

Sysdig の2026年度版クラウドネイティブセキュリティおよび利用状況レポートによると、組織の75%がさまざまなポリシーに対して自動レスポンスアクションを設定しています。しかし、それを有効化している組織はわずか27%です。

このギャップそのものがリスクになり得ます。エージェント型脅威アクター（ATA）は迅速に行動するため、人間の判断を待って一時停止するセキュリティ運用は、攻撃者の時間軸に取り残されてしまいます。

ステートフル検知は、組織が必要としているものかもしれません。より高精度な検知と誤検知の少なさにより、高品質なシグナルを提供します。人々がそのシグナルを信頼できるようになれば、レスポンスも信頼できるようになります。実際、自動レスポンスを有効化しているその27%に注目すると、明るい未来が見えてきます。

脅威検知アラートを受けてプロセスを終了させるためにkill -9コマンドを使用する組織が140%増加していることを確認しています。また、コンテナに関しても、一時停止や停止ではなくコンテナの強制終了を選ぶ組織の数が28%増加しています。

これは、こうしたチームの成熟度を示すサインです。第一に、サービスを完全に中断させることなくプロセスやコンテナを終了できるようになっています。第二に、侵害されたコンテナを稼働させたままトラブルシューティングするという運用上の便宜よりも、セキュリティを優先しています。

まとめ

ステートフル検知は、ランタイムセキュリティにとって不可欠なツールになりつつあります。組織がランタイムセキュリティの導入に自信を持つ必要があるまさにこのタイミングで、ステートフル検知はより高品質な検知を提供します。ATA は今まさに実際の環境で活動しており、人間のペースを前提とした脅威に対する防御では、AI駆動型の脅威には対抗できません。