目次
- GPT-5.6でもサイバー防御は41％―高性能LLMだけでは足りない理由
- 20モデルを実際の攻撃ログで検証したCyber Defense Benchmark
- なぜLLMはサイバー防御の調査を途中で止めてしまうのか
- 41％から95％へ―SimbianのDefensive Harness
- MITRE ATT&CKを使って「まだ調べていない領域」を追跡する
- Case ManagerがJira・ServiceNow・SIEMと双方向同期
- Microsoft 365・Wiz・Cato Networksを使った調査・対応
- 機密性の高いセキュリティデータを扱うためのオンプレミス運用
- AI SOCで重要なのは「どのLLMを使うか」だけではない
- まとめ
GPT-5.6でもサイバー防御は41％―高性能LLMだけでは足りない理由
生成AIの性能が向上し、 セキュリティ運用でも LLMを活用できる場面が 大きく広がっています。
ログを要約する、 不審なイベントを説明する、 検知ルールの作成を支援する、 攻撃手法について調べる。
こうした作業では、 GPTなどのLLMが アナリストを支援することができます。
では、 高性能なLLMをそのままSOCへ接続すれば、 実際のサイバー攻撃の調査まで 任せられるのでしょうか。
Simbianが実施した Cyber Defense Benchmarkでは、 興味深い結果が示されています。
GPT-5.6 Solは、 評価された20モデルの中で 2位という高い順位を記録しました。
しかし、 実際の攻撃を対象とした サイバー防御のカバレッジは 41％。
MITRE ATT&CKの 13の戦術のうち、 合格基準をクリアできたのは 6戦術でした。
しかも、 これはGPT-5.6だけの問題ではありません。
評価された20モデルの中で、 すべての戦術について 50％の合格基準を突破したモデルは 一つもありませんでした。
ここから見えてくるのは、
「高性能なLLMを選べば、 そのままSOCを自動化できる」
というほど、 実際のサイバー防御は 単純ではないということです。
20モデルを実際の攻撃ログで検証したCyber Defense Benchmark
Cyber Defense Benchmarkでは、 20のフロンティアLLMに対して、 1,002件の実際の攻撃調査を 実行しています。
評価対象には、 MITRE ATT&CKの 13すべての戦術が含まれています。
さらに、 各調査では 10万件を超えるセキュリティイベントの中から 実際の攻撃を見つけ出し、 105のMITRE ATT&CKプロシージャにまたがる 攻撃の流れを再構築します。
つまり、 AIに分かりやすい攻撃ログだけを 与えているわけではありません。
大量の正常なイベントや 攻撃とは関係のない情報が含まれる中から、
- どのイベントが攻撃に関係しているのか
- どのユーザーや端末が関係しているのか
- その後どのような動きが発生したのか
- 別のイベントと同じ攻撃として関連付けられるのか
- まだ調査していない攻撃経路が残っていないか
といったことを 判断し続ける必要があります。
主な結果を見ると、
| 順位 | モデル | カバレッジ | 合格した戦術 |
|---|---|---|---|
| 1 | Opus 4.6 | 44.5％ | 7 / 13 |
| 2 | GPT-5.6 Sol | 41.0％ | 6 / 13 |
| 3 | GPT-5.5 | 37.4％ | 2 / 13 |
| 4 | Sonnet 4.6 | 36.9％ | 2 / 13 |
| 5 | GLM 5.2 | 35.0％ | 1 / 13 |
1位のモデルでも44.5％、 GPT-5.6 Solでも41％です。
この結果は、 AIのサイバーセキュリティ能力が 低いことを意味するものではありません。
むしろ、 「攻撃について知っていること」と 「大量のログから実際の攻撃を最後まで追跡すること」は、 異なる能力である ことを示しています。
なぜLLMはサイバー防御の調査を途中で止めてしまうのか
攻撃側と防御側では、 AIに求められる仕事が大きく異なります。
攻撃では、 一つ有効な経路を見つければ 目的を達成できる場合があります。
一方、 防御側はそうはいきません。
数万、 数十万というイベントの中から 攻撃の痕跡を見つけ、 それを時間軸に沿って 追い続ける必要があります。
例えば、
- 認証情報へのアクセス
- 権限昇格
- ラテラルムーブメント
- 永続化
- データへのアクセス
といった挙動は、 一つのログにまとまって 現れるわけではありません。
最初の不審なイベントから 数時間後に別の端末で 新しい挙動が発生することもあります。
そのため、 SOCの調査では 「まだ何かあるかもしれない」 という仮説を維持しながら、 次の情報を確認し続ける 必要があります。
ところがSimbianの検証では、 LLMが調査の早い段階で 「これ以上侵害の兆候はない」 と判断してしまうケースが確認されています。
本来なら まだ複数の調査ステップが残っているにもかかわらず、 調査を終了してしまうのです。
また、 次のクエリを実行する代わりに 現在までの状況を文章で説明し始めたり、 MITRE ATT&CKの一部の戦術を ほとんど確認しないまま 終了したりすることもあります。
つまり、
「不審なログを見つけられる」 ことと、 「攻撃全体を最後まで調査できる」 ことは同じではありません。
41％から95％へ―SimbianのDefensive Harness
この問題に対して Simbianが採用しているのが、 Defensive Harness（防御用ハーネス） という考え方です。
ポイントは、 LLMそのものに すべてを任せないことです。
LLMを セキュリティ調査を行うシステムの 一つの構成要素として利用し、 その周囲に 調査を継続するための仕組みを配置します。
次に実行する調査を決める
現在までに得られた証拠をもとに、 次にどの情報を調べ、 どのクエリを実行するべきかを判断します。
一度質問して 一度回答を得て終了するのではなく、 調査結果を次の調査へつなげていきます。
早すぎる「調査終了」を再確認する
LLMが 「これ以上調査する必要はない」 と判断した場合でも、 その結論だけで終了しません。
別の確認プロセスによって、 見落としている調査項目がないか、 本当に終了してよいのかを 再確認します。
対象環境について記憶する
セキュリティ調査では、 その組織にとって 何が通常の動作で、 何が異常なのかという 環境固有の情報も重要です。
Simbianでは、 対象環境について得られた情報を 維持しながら調査を進めます。
新しいアラートが発生するたびに 完全にゼロから始めるのではなく、 環境の文脈を持った状態で 調査できるようにします。
こうしたDefensive Harnessを組み合わせた構成では、 同じCyber Defense Benchmarkで 95％を記録しています。
この結果は、 グローバルMSSPによって 検証されています。
41％と95％。
この差を見ると、 AI SOCを考えるうえで 本当に重要なのは 「どのLLMを選んだか」だけではなく、 「そのLLMをどのような仕組みの中で動かしているか」 だということが分かります。
MITRE ATT&CKを使って「まだ調べていない領域」を追跡する
Defensive Harnessの中でも 特にサイバー防御らしい仕組みが、 MITRE ATT&CKを利用した 調査状況の管理です。
一般的なLLMとの対話では、 AIが一度 「調査は完了した」 と判断すると、 そこで処理が終わってしまいます。
しかし実際の攻撃では、 Credential Accessを確認しても、 PersistenceやLateral Movementなど 別の戦術が残っている可能性があります。
Simbianでは、
- どのMITRE ATT&CK戦術を確認したのか
- どの領域で証拠が見つかったのか
- まだ調査していない戦術は何か
といった進捗を追跡しながら 調査を進めます。
これは、 単にAIへ 「このログを分析してください」 と依頼する場合とは 大きく異なります。
一つの答えを生成することではなく、 攻撃調査そのものを管理する ことが目的だからです。
Case ManagerがJira・ServiceNow・SIEMと双方向同期
AIが高度な調査を行えても、 実際のSOC業務から 切り離されていては 運用しにくくなります。
Simbianには、 調査結果やインシデントを管理するための Case Managerが 組み込まれています。
さらに、 すでに企業で使われている ITSMやSIEMとの 双方向同期に対応しています。
ITSM / チケット管理
- Jira
- ServiceNow
- ManageEngine
- Freshservice
インシデント対応を ServiceNowやJiraで管理している場合でも、 Simbianのために ケース管理を全面的に切り替える必要はありません。
Case Managerと 現在使用しているITSMを 双方向で同期させることで、 既存の運用フローへ AIによる調査を組み込むことができます。
SIEM
- Microsoft Sentinel
- Palo Alto Networks XSIAM
- Securonix
SIEMについても 双方向同期に対応しているため、 既存のセキュリティスタックを活用しながら AIによる調査とケース管理を 組み合わせることができます。
AI SOCを導入するために 現在のSIEMやITSMを すべて置き換えるのではなく、
すでに存在する運用環境へ AIを追加する
という考え方で利用できる点は、 実務上大きなポイントです。
Microsoft 365・Wiz・Cato Networksを使った調査・対応
連携は、 ケース情報の同期だけではありません。
実際のセキュリティ調査や 対応を行うための インテグレーションにも対応しています。
Microsoft 365―フィッシングアラートを調査
Microsoft 365と連携し、 フィッシングアラートの調査を 行うことができます。
メール関連のアラートについて、 AIが単に内容を要約するだけではなく、 調査ワークフローへ 接続できる点が重要です。
Wiz―CNAPPアラートを調査
Wizとの連携では、 CNAPPから発生したアラートの調査に Simbianを利用できます。
クラウド環境で発生したアラートについても、 AIによる継続的な調査の対象として 扱うことができます。
Cato Networks―ネットワーク上の脅威を封じ込める
Cato Networksとの連携では、 ネットワーク上で確認された脅威の 封じ込めにつなげることができます。
つまり、 SimbianのAI活用は 「アラートについて説明して終わる」 ものではありません。
調査し、 ケースとして管理し、 必要な対応へつなげる
という、 実際のSecOpsワークフローを 意識した構成になっています。
機密性の高いセキュリティデータを扱うためのオンプレミス運用
AIをSOCへ導入する際には、 調査性能だけでなく、 セキュリティデータを どこで処理するのか も重要です。
SOCが扱うログには、
- ユーザー情報
- 端末情報
- IPアドレス
- 認証情報に関するイベント
- 社内システムの構成情報
- 攻撃や脆弱性に関する情報
など、 外部へ出すことが難しい 情報が含まれる場合があります。
一般消費者向けのAIチャットへ 機密性の高いログやソースコードを そのまま入力することは、 データ露出のリスクにもつながります。
Simbianは、 オンプレミスでの本番運用に対応しています。
この構成では、 機密性の高いセキュリティテレメトリを 顧客自身のネットワーク内に保持した状態で AIによる調査を行うことができます。
AI SOCを評価する際には、 モデルの性能や自動化できる範囲だけではなく、
「どこでAIが動き、 どこにデータが残るのか」
まで含めて確認することが重要です。
AI SOCで重要なのは「どのLLMを使うか」だけではない
AIをセキュリティへ導入するとき、 どうしても
- GPTとClaudeではどちらが強いのか
- より新しいモデルの方が良いのか
- より大きなモデルなら精度が上がるのか
といった モデルそのものの比較に 注目しがちです。
もちろん、 どのモデルを利用するかは 重要です。
しかし、 Cyber Defense Benchmarkの結果を見ると、 それだけでは サイバー防御の性能を 決められないことが分かります。
GPT-5.6 Solは41％。
最も高かったOpus 4.6でも44.5％。
一方で、 SimbianのDefensive Harnessを 組み合わせた構成では95％。
重要なのは、 AIが一回の回答を 正しく生成できるかだけではありません。
- 次に何を調査するかを判断できるか
- 結果が出なくても仮説を維持できるか
- 調査を早く終了していないか再確認できるか
- 対象環境についての情報を維持できるか
- MITRE ATT&CK上で未調査の領域を把握できるか
- 既存のSIEMやITSMと実際の運用をつなげられるか
といった、 AIの周囲にあるシステム全体 が重要になります。
Simbianが掲げる Self-Improving SecOpsも、 AIを完全に放置して 勝手に動かすという考え方ではありません。
AIを 人間が監督するセキュリティシステムの 一部として利用し、 実際のケースから学びながら 調査の質を高めていくという アプローチです。
AI SOCを検討するときには、 「どのLLMを搭載していますか？」 だけでなく、
「そのLLMが途中で調査を止めないために、 どのような仕組みが用意されていますか？」
という視点も 重要になってくるでしょう。
まとめ
GPT-5.6 Solは、 Cyber Defense Benchmarkにおいて 20モデル中2位という 高い結果を記録しました。
それでも、 実際の攻撃ログを対象とした サイバー防御のカバレッジは 41％です。
この結果が示しているのは、 最新のLLMの性能が 足りないという単純な話ではありません。
実際のSOCで必要になる、
- 大量のノイズから攻撃の痕跡を探す
- 複数のイベントを関連付ける
- 仮説を維持したまま追加調査する
- 調査を途中で諦めない
- 攻撃チェーン全体を確認する
という仕事は、 一度の質問に回答するLLMとは 性質が異なります。
Simbianでは、 LLMの周囲に Defensive Harnessを構築し、
- 次の調査を計画する
- 早すぎる調査終了を再確認する
- 環境についての情報を保持する
- MITRE ATT&CKで調査状況を管理する
といった仕組みを組み合わせています。
さらに、 Jira、 ServiceNow、 ManageEngine、 FreshserviceなどのITSM、 Microsoft Sentinel、 Palo Alto Networks XSIAM、 SecuronixなどのSIEMとの 双方向同期にも対応しています。
Microsoft 365による フィッシングアラートの調査、 WizによるCNAPPアラートの調査、 Cato Networksを利用した ネットワーク上の脅威封じ込めなど、 実際の調査・対応につながる連携も利用できます。
「高性能なLLMを導入する」 ことと、 「AIを実際のサイバー防御で機能させる」 ことは同じではありません。
AI SOCを評価する際には、 モデル名やチャット上の回答性能だけではなく、 調査をどのように継続し、 既存のSecOps環境と どのようにつながるのかまで 確認することが重要です。
Simbian AIのライセンス、 既存のSIEM・ITSMとの連携、 オンプレミス構成、 導入について ご不明な点がございましたら、 お気軽にお問い合わせください。
今後も、セキュリティと実務運用の両面から役立つ情報を発信してまいります。
ぜひブックマークのうえ、最新記事をお見逃しなく！