SOCを構築する際、SIEM1とSOAR2の両方を検討している組織は多くありますが、「とりあえず両方入れればよい」という判断は後から運用コストの増大を招くことがあります。検知の精度を上げたいのか、対応の速度を上げたいのか——目的が異なれば、優先すべきツールも変わります。この記事では、両ツールの役割の違いを実務フローに沿って整理し、導入判断や設計時の参考になる視点を提供します。
SIEMとSOARの役割の違い
SIEM（Security Information and Event Management。各種システムのログを一元集約し、相関分析によって脅威を検知するプラットフォーム）は、組織内のファイアウォール・エンドポイント・クラウドサービス等から生成されるログを収集・正規化し、「怪しい動き」をアラートとして可視化する役割を担います。Splunk・Microsoft Sentinel・IBM QRadarなどが代表的な製品です。
SOAR（Security Orchestration, Automation and Response。インシデント対応の調整・自動化を担うプラットフォーム）は、SIEMが上げたアラートを受け取り、あらかじめ定義したプレイブック3（対応手順書）に従って処理を自動実行します。たとえば、不審なIPからのアクセスをSIEMが検知した場合、SOARが自動でそのIPをブロックリストに追加し、Slackで担当者に通知し、チケットを起票する——というフローを無人で回すことができます。Palo Alto Networks XSOAR（旧Demisto）やSplunk SOAR（旧Phantom）が代表例です。
端的にいえば、SIEMは「見る」、SOARは「動く」という機能分担と理解するとよいといえます。どちらが欠けても、SOCは「気づいているが手が回らない」あるいは「動いているが根拠があいまい」という状態に陥りやすくなります。
実務フローで見る使い分け
検知から対応までの一連の流れを整理すると、SIEMとSOARの接続点が明確になります。
1. ログ収集・正規化: SIEMがエンドポイント・ネットワーク機器・クラウドサービス等から生ログを収集し、共通スキーマに変換します。
2. 相関分析・アラート生成: SIEM内の相関ルール（または機械学習モデル）が異常パターンを検出し、アラートを生成します。
3. トリアージ（優先度判定）: SOARがアラートをインジェストし、資産重要度・脅威インテリジェンス・過去の類似アラートといったコンテキスト情報を自動付与して優先度を判定します。
4. 対応・封じ込め: プレイブックに従い、SOARがアカウントの無効化・通信のブロック・証跡の取得などを自動実行します。
5. 記録・クローズ: 対応履歴をチケットシステムやSIEM自体に書き戻し、次回の学習データとします。
このフローにおいて、SIEMとSOARは競合するのではなく、上流・下流の関係にあります。SIEMなしにはSOARへのインプットが届かず、SOARなしにはSIEMのアラートはアナリストの手作業に委ねられ続けます。
実際の導入優先度については、アラート数が多く対応が追いつかない組織はSOARの自動化から着手し、ログの可視性が低い組織はまずSIEMの整備を先行させる判断が妥当といえます。
主要製品と統合パターン
現在の市場では、SIEMとSOARの機能を統合した製品が増えています。Microsoft SentinelはSIEM・SOAR・UEBA4（User and Entity Behavior Analytics。ユーザーや機器の通常行動からの逸脱を検知する拡張機能）を単一プラットフォームに統合しており、Azure環境での導入摩擦が少ないのが特徴です。Splunkも、Splunk EnterpriseとSplunk SOARを組み合わせた統合SOCプラットフォームを提供しています。
一方、ベストオブブリード（目的別に最適な製品を組み合わせる戦略）を採る組織では、SIEMにQRadarを使いつつSOARにXSOARを組み合わせる構成も見られます。この場合、APIによるデータ連携の設計と保守が運用コストの鍵になります。
選定・設計における留意点を軸ごとに整理します。
- 設計
- SIEMとSOAR間のスキーマ統一を事前に設計しないと、プレイブックのメンテナンスが属人化しやすくなります。
- 自動対応の実行権限（何を無人で実行してよいか）を技術設計の段階でポリシーとして定義する必要があります。
- 運用
- プレイブックは「作って終わり」ではなく、誤検知率・平均対応時間（MTTR）をKPIとして定期的に改訂する運用サイクルを組むことを推奨します。
- ログのインジェスト対象は優先順位をつけて設計しないと、従量課金型SIEMでコストが予算を大幅に超過するケースがあります。
- ガバナンス
- 自動対応の範囲と承認フローを組織ポリシーとして文書化し、CISO承認を得ることを推奨します。
- インシデント対応の証跡を監査ログとして保全し、事後の法的対応や規制報告に備える必要があります。
一枚要約
- 何が起きているか: SIEMとSOARは役割が異なる補完的なツールであり、「どちらか一方」ではなく「上流・下流の連携」として設計することが実務上の標準になりつつあります。
- 自社への影響: SIEM単独では検知件数が増えるほどアナリストが疲弊し、SOARがないと対応遅延が蓄積します。SLAや規制報告の観点から、対応速度の可視化が急務です。
- 打つべき手: まず現状のアラート量と対応工数を計測し、ボトルネックがログ収集側（SIEM）なのか対応側（SOAR）なのかを特定することが出発点といえます。
今日着手できる3アクション
- 現行SIEMのアラート件数とクローズ率を計測する: 過去30日のアラート総数・自動クローズ数・手動対応数を集計します。Microsoft Sentinelであれば「分析ルール」→「アクティビティログ」、Splunkであれば `index=_audit` クエリで概数を把握できます。アラートの未処理率が高ければSOAR導入の優先度が上がります。
- プレイブック候補を1本選定する: フィッシングメール対応やブルートフォース検知など、頻度が高く手順が標準化されているユースケースを1つ選び、SOARのプレイブックとして文書化します。Palo Alto Networks XSOAR の公式ドキュメント（`https://docs.paloaltonetworks.com/`）にはサンプルプレイブックが公開されており、参考にできます。
- MITRE ATT&CKとのマッピング状況を確認する: 現行のSIEM検知ルールが攻撃チェーンのどのフェーズをカバーしているかを可視化します。`https://attack.mitre.org/` のATT&CK Navigatorツールを使うと、検知の空白領域を一目で把握できます。
AI×セキュリティの観点
SOCの文脈でAIが最も大きなインパクトを与えているのが、自動トリアージの領域です。従来は熟練アナリストが経験則で行っていた「このアラートは本物か？」という判断を、大規模言語モデルや機械学習モデルが補助することで、AI-SOC（AI支援型SOC）の実現が現実的な選択肢になってきています。Microsoft Sentinelの「Copilot for Security」連携やSplunkのAIアシスト機能はその実装例といえます。一方、攻撃者側もAIを使って意図的に大量の誤検知を発生させる「アラートフラッディング」を自動化するリスクがあります。AIが下す自動対応の判断根拠を人間が検証できる監査ログの整備は、防御側にとって不可欠な設計要件です。
用語ミニ解説
- SIEM — Security Information and Event Managementの略。各種システムのログを集約・分析し、脅威を検知するプラットフォーム。「シーム」と読むことが多い。 ↩
- SOAR — Security Orchestration, Automation and Responseの略。あらかじめ定義した手順書（プレイブック）に従い、インシデント対応を自動化・調整するツール。「ソアー」と読む。 ↩
- プレイブック — インシデント発生時の対応手順をコード化したもの。SOARがこれを実行することで、通知・ブロック・記録などの処理を無人で実行できます。 ↩
- UEBA — User and Entity Behavior Analyticsの略。ユーザーや機器の通常行動をベースラインとして学習し、逸脱を検知するSIEMの拡張機能。内部不正の早期発見などに活用されます。 ↩
- MITRE ATT&CK — サイバー攻撃者の戦術・技法・手順を体系的に分類したフレームワーク。SIEMの検知ルールがどの攻撃フェーズをカバーしているかを確認するための共通言語として広く使われています。 ↩
コメント