SOARを導入しても意味がない？自動対応もできないなら

By PLURA

📉 SOARはSIEMから発生したイベントを受け取り、自動対応を実行するソリューションとして知られています。
しかし実際には「SOARを導入したのに自動対応が難しい」という声が絶えません。

最大の理由は、SOARが単独では機能しないうえに、SIEMの検知結果に全面的に依存しているからです。
そして現在の多くのSIEM運用環境が「ログ収集・分析が不完全」な状態であるために、
SOARでも正確な自動対応を期待するのが難しいのです。

本記事では「SIEM、導入してどうなるの？」の文書を参考に、
SOAR導入時に直面する課題とその根本原因を整理します。

  • SOAR: Security Orchestration, Automation, and Response
  • SIEM: Security Information and Event Management

why_soar_always_fails

1. なぜSOARはSIEMに依存するのか？

(1) SOARの基本メカニズム

  • SOARは一般的にSIEMやその他のモニタリングソリューションからのセキュリティイベントを基に、

  • あらかじめ定義されたワークフローや自動化スクリプトを実行します。

    • 例：攻撃元IPの遮断、関連アカウントの一時停止、チケットの発行など

  • 即時または半自動での対応を可能にします。

(2) 「誤ったイベント」が入ってきたら？

  • 問題なのは、SIEMに誤検知（False Positive）が多かったり、
    正確な検知ができずに脅威情報を見落とすような状況では、

  • SOARも「誤ったイベント」や「漏れたイベント」により、

    • 対応がまったく発動しない、
    • 誤った対象を遮断・制限するなどの問題を引き起こす可能性があります。

  • つまり、SOARの精度はそのままSIEMの検知精度に依存しています。

(3) SIEMが不十分なら自動対応は“絵に描いた餅”

  • SIEMが不完全であれば、検知されるイベントが不十分または信頼性に欠けるものになります。

  • その状態でSOARを適用しても、「誤ったデータ」に基づいて自動化を試みることになり、

    • **「むしろ危険」**な状況を招く可能性があります。
    • 不必要な箇所を遮断したり、本当の攻撃を見逃したりするケースが発生し得ます。

⚡そのため、現場では「SIEMが安定していない状態で
SOARを導入するのは時期尚早だ」という意見が多く見られます。

2. SOARが自動対応できない理由

「SOARを導入すれば自動対応が可能になる」とよく期待されますが、
実際にはうまく機能しないケースが多く、その根本的な理由は以下のとおりです。

(1) SIEM自体のログ収集・分析の限界

  • SIEMは基本的に単純なアクセスログや基本的なイベントログに依存しています。

  • リクエストボディ（Request Body）、レスポンスボディ（Response Body）などの重要な攻撃情報を収集できなければ、

    • SQLインジェクションやデータ漏洩のような高度な攻撃はそもそも検知できません。

  • そのため、SIEMが適切な正確な検知（True Positive）を行えなければ、
    SOARが    自動遮断・対応    する根拠も得られません。

(2) 攻撃シナリオルールの不足 → ルールなしでは自動対応は不可能

  • SOARが「このイベントは危険だから自動対応しよう」と判断するには、

    • そのイベントが本当に悪性かどうかを判定するための**事前ルール（Rule）**が必要です。

  • しかし、多くのSIEM運用環境では攻撃パターンに関するルール定義が不十分であったり、 完成度が低いために誤検知と正確な検知の区別が困難です。

  • 「ルールや検知シグネチャが整っていなければ、SOARがやることもない」という言葉が出る理由です。

(3) 運用人員・プロセスの不在 → 自動化にも最終的に人の手が必要

  • 自動化という幻想とは裏腹に、SOARを導入しても

    • セキュリティチームが誤検知かどうかを丁寧に判断する作業が不可欠です。

  • SIEMの段階ですでに誤検知が多い場合、SOARも誤検知イベントを受け取り、
    無駄な自動化プロセスを延々と回すだけになります。

  • ✅ 結局、「適切なログ + 正確な検知ルール + 熟練した運用人材」が揃っていなければ、
    SOARは「自動対応」という名ばかりで、実際には対応を開始することすら困難になります。

SIEM ↔︎ SOAR ↔︎ WAF 連携構成図

sequenceDiagram
    participant SIEM as SIEM
    participant SOAR as SOAR
    participant WAF as WAF

    Note over SIEM: 1. SIEMでイベント（疑わしいログ）を検知
    SIEM ->> SIEM: ログ分析および脅威判別
    
    Note over SIEM,SOAR: 2. SIEMがSOARにセキュリティイベント（アラート）を送信
    SIEM ->> SOAR: 疑わしいイベントアラート

    Note over SOAR: 3. SOARがイベントを分析・相関処理
    SOAR ->> SOAR: ルール／ワークフロー実行
    
    Note over SOAR,WAF: 4. SOARがWAFにブロック命令を送信
    SOAR ->> WAF: ブロックリクエスト発行

    Note over WAF: 5. WAFが該当トラフィックをブロック
    WAF ->> WAF: 悪意のあるトラフィックをブロック／ドロップ
    
    Note over WAF,SOAR: 6. WAFがブロック結果をSOARに通知
    WAF ->> SOAR: ブロック確認

    Note over SOAR,SIEM: 7. SOARがブロック結果をSIEMに記録
    SOAR ->> SIEM: イベントステータスを更新

SOAR, SIEM & WAF

3. なぜ「SIEMの問題」がそのまま「SOARの問題」になるのか？

以下のドキュメントでも強調されているように、SIEMの最大の問題は「ログの収集すらまともにできず、分析できる人材もいない」という点でした。

SIEMを導入しても意味があるのか？ログの収集も分析もできないなら

この問題は少し視点を変えると、SOARにもまったく同じように当てはまります。

  1. ログの収集そのものが不十分 → 検知イベントが不足 → SOARが対応すべき根拠（イベント）も不足。

  2. 検知ルールや分析能力が不足 → SIEMのアラートの信頼性が低い → SOARが自動対応を行って正常なトラフィックを遮断する事例が頻発。

  3. 運用人材の不足 → SIEMの誤検知対応も困難 → SOARでも誤検知処理の自動化が難しく → 結局放置される。

✅ 結論として、SIEMが正しく運用されていない状態では、 SOARもまた安定した自動対応を実現するのは難しいというのは当然の帰結です。

4. 「SOAR、導入しても意味あるの？」に対する答え

(1) 自動対応の前に「自動検知」から始めよう

  • SOARの本質は「自動検知 → 自動対応」という流れにあります。

  • しかし、自動検知そのものがSIEMでしっかり行われて初めて、 「このイベントは無条件で遮断すべき」という安全な自動対応が可能となります。

  • つまり、SOARより先にSIEMの正確な検知精度を高めるために、

    • ログ収集範囲の拡大、
    • 検知ルールの高度化、
    • 分析担当者の育成と配置 などが先に行われるべきです。

(2) まずはSIEM運用の実力を高めよう

  • SIEMの運用がある程度洗練され、誤検知率が下がって初めて、

    • 「イベントが発生したら、自動で処理しても安全だ」と自信を持てるようになります。

  • このプロセスを飛ばしていきなりSOARを導入すると、

    • 誤検知が多すぎて企業の業務が停止するリスクがあり、
    • 結局SOARは“自動化”ではなく半自動モードでしか使えず、
    • 導入効果も半減してしまいます。

(3) 「SIEMを完璧にしてからSOARを拡張しても遅くない」

  • 現場ではまずSIEMを運用しながら、少しずつルールを精緻化し、

    • 問題のないイベントだけをフィルタリングしていくプロセスを長期的に進めます。

  • その後、「ある程度の水準で正確に検知できる」と判断されてから、

    • そのタイミングでSOARを導入しても決して遅くはありません。

  • 💡 むしろその方が、SOAR導入時に実質的な自動化が実現され、 投資に見合った高い効果が得られる可能性が高いのです。

5. では「SOAR」はいつ導入すべきか？

  1. SIEMから正確なイベントが十分に出ているかを確認する

    • ログ収集の範囲を広げてもシステムが耐えられるか？
    • 誤検知に対する**正確な検知（True Positive）**の比率が適切か？
    • 担当者が状況を把握し、指標を改善できるスキルを持っているか？

  2. 対応プロセスがある程度標準化されているか？

    • 攻撃タイプごとに「どのような対処を行うか」が定義されていなければならない。
    • その定義があることで、SOARがそのプロセスをスマートに自動化できる。

  3. 業務影響に対する十分なリスク評価が行われているか？

    • 誤検知によって正常なユーザーがブロックされるリスクはないか？
    • 自動対応において、モニタリングや追加検証が必要な段階はないか？

これらのプロセスを「チェック」して、ある程度成熟していると判断された段階で
SOARを導入すれば、自動対応も実効性を持って機能します。

6. 結論：「SOARはSIEMの影である」

  • SOARは「セキュリティイベントの自動対応」を掲げていますが、
    そのイベントは結局SIEMから送られてきたものです。
  • SIEMが正しく正確な検知を行えなければ、
    SOARの自動化も空虚な理想に過ぎません。
  • したがってSOARの導入を検討する際には、
    「自社のSIEM運用レベルは自動対応に耐えうるか？」を
    冷静に診断することが先決です。

7. 「SOARを導入して意味があるのか？」に対する最終的な答え

  1. SOARは決して単独で自動対応を実現できる万能ソリューションではない。
  2. SIEMの検知精度、運用人材、ルール設計などが十分に成熟していて初めて、
    SOARもようやく安全な自動対応を実行できる。
  3. SIEM自体が不完全な場合、SOARはただ誤ったイベントを受け取り、
    誤った自動化を引き起こすだけで、かえって大きなリスクになり得る。
  4. よって、ログ収集から分析能力までしっかりと準備した後で、
    SOARを導入しても決して遅くはない。

✅ 結局、「SOARによる自動対応を夢見るなら、まずはその前段階のSIEM運用の高度化が必要」という結論です。

📖 一緒に読んでみましょう

📖 SIEM & SOAR 導入失敗事例

🌟 PLURA-XDRの差別化ポイント

🌟 PLURA-XDRのサービス

SOARで「自動化されたセキュリティ」を実現したいなら、
まずは SIEM が「正確かつ十分なログ」を収集・分析できるように
体系的な構築をすることが最も重要です。
自動化の基本は信頼できる検知だからです。
準備もなく SOAR だけを導入すれば、自動対応どころか自動混乱になる可能性すらあります。

PLURA-XDR の自動化プラットフォームを導入してみてください。
SIEM、WAF、EDRと連携し、自動対応を行うSOARも内蔵されています。

Tags