SOARが重要な理由

現代のセキュリティオペレーションセンター（SOC）は、アラートに埋もれています。中規模企業のSIEMでは、1日に数万件ものアラートが発生することがあり、その大半は信頼度が低いか、誤検知です。

アナリストは、すべてのアラートを手作業でトリアージすることはできません。その結果がアラート疲れです。実際の脅威が埋もれ、平均対応時間（MTTR）が長くなり、燃え尽きによって熟練したスタッフが職場を去ることになります。

SOAR（Security Orchestration, Automation and Response）は、調査と対応における反復的で決定論的な部分を自動化することで、この問題に対処します。

SOARは、次の3つの機能を組み合わせたものです。

• オーケストレーション — SIEM、EDR、ファイアウォール、チケット管理、脅威インテリジェンスなど、多数の異なるツールを1つのコントロールプレーンから連携させます。
• 自動化 — IPの情報を補強する、ホストを隔離する、アカウントを無効化するなど、人手を介さずにタスクを実行します。
• 対応 — 検知から封じ込め、ケースの終了まで、インシデントのライフサイクル全体を進めます。

目的はアナリストを置き換えることではありません。手間のかかる作業を取り除き、人間が判断を必要とする意思決定に集中できるようにすることです。

フィッシング報告に対して、Tier-1アナリストが行う作業を考えてみます。各手順は機械的で、毎回同じです。

• メールからURLと添付ファイルを抽出します。
• 添付ファイルをサンドボックスでデトネーションします。
• 送信元ドメインのレピュテーションを照会します。
• 同じメールを他のユーザーも受信しているか確認します。
• チケットを作成し、重大度を付与します。

これらの作業に人手は必要ありません。必要なのはAPI呼び出しです。SOARはこれらの手順を一度コード化し、毎回数秒で実行します。

SOARは、検知および防御の実行ツールの上位に位置する連携役です。一般的な流れは次のとおりです。

SIEMまたはEDRが検知を発生させます。その検知が、SOARプラットフォームに取り込まれるイベントになります。プレイブックが起動し、情報補強のソースを呼び出し、実行するアクションを判断して、ファイアウォール、IDプロバイダー、またはEDRにコマンドを送り返します。

概念的には、SIEMが何が起きたかを伝え、SOARがそれにどう対処するかを判断して実行します。

悪意があると確認されたホストを自動的に封じ込める場合を考えてみます。人間が行う場合は、EDRコンソールにログインして「Isolate」をクリックします。SOAR連携を通じて同じ操作を行う場合は、API呼び出し1回で済みます。

以下は、SOARアクションがラップするEDR隔離呼び出しの例です。これはセキュリティ操作であり、単独で実行できるコードではない点に注意してください。

平均対応時間（MTTR）は、SOARによって大きく改善される代表的な指標です。手作業によるフィッシング調査には、アナリスト1人あたり30～45分かかることがあります。プレイブックなら情報補強を1分未満で完了し、最後の人間による判断だけを残せます。

対応が速くなると、攻撃者の滞留時間が短くなります。これは、侵害されてから封じ込めるまでの時間です。滞留時間の1分1分を、攻撃者は権限昇格、ラテラルムーブメント、または情報の持ち出しに利用します。

自動化は、速度だけでなく一貫性ももたらします。同じアラートを処理する場合でも、アナリストによって手順が異なることがあります。プレイブックは毎回同じように実行されるため、コンプライアンスとインシデント後のレビューにおいて重要です。

自動化されたすべてのアクションは、タイムスタンプ、トリガーとなったイベント、実行主体（プレイブック）とともに記録されます。これにより、手作業では実現しにくい、明確な監査証跡が作成されます。

• プレッシャー下でも手順を省略しません。
• 調査を再現できます。
• 証拠を自動的に保持できます。

自動化は、自律化を意味しません。経営幹部のアカウントを無効化したり、重要なサブネットをブロックしたりするような影響の大きい操作は、承認のために一時停止すべきです。

SOARプラットフォームはhuman-in-the-loopゲートをサポートしています。プレイブックがすべての証拠を収集して提示し、破壊的な手順を実行する前に、アナリストが「承認」または「却下」をクリックするまで待機します。

これにより、元に戻せない操作に対する人間の判断の安全性と、対応の速さを両立できます。

SOARは強力ですが、魔法ではありません。よくある失敗モードは次のとおりです。

• Garbage in, garbage out — 悪いプロセスを自動化すると、悪い判断をより速く下すだけです。
• 壊れやすい連携 — APIが変更され、トークンが期限切れになり、プレイブックが気付かないうちに停止します。
• 過度な自動化 — 信号が弱い状態で自動ブロックすると、自分で障害を引き起こすことになります。

まずは、十分に理解され、確信度の高い対応経路だけを自動化し、その後に対象を広げることが原則です。

チームがSOARの機能を実現する方法は2つあります。専用プラットフォーム（Splunk SOAR、Cortex XSOAR、Tines、Torq）には、コネクタライブラリとビジュアルなプレイブックエディターが付属しています。

小規模なチームでは、スクリプトとスケジューラーから始めることもあります。この方法のリスクは、コネクタ、リトライ処理、監査ログを手作業で作り直すことです。

通常は、必要な連携の広さと、カスタムコードを保守するために確保できるエンジニアリング時間のどちらを優先するかで判断します。

初日からすべてのアラートにプレイブックが必要なわけではありません。効果が最も高く、リスクが最も低いところから始めます。

• 量が多い — フィッシングのトリアージ、マルウェアアラート、ブルートフォース攻撃などです。頻繁に実行するほど、節約できる時間が積み上がります。
• 十分に理解されている — 手作業の手順がすでに文書化され、一貫しています。
• 決定論的である — 同じ証拠から、信頼性の高い同じ結論が導かれます。

まれで、判断が難しく、影響範囲が大きいインシデントから始めるのは避けます。単調で反復的なケースで信頼を築き、その後に難しい領域へ広げます。

SOARが必要とされる核心的な理由について、理解度を確認します。

SOARが重要である理由の要点は次のとおりです。

• SOCは膨大な量のアラートとアナリストの燃え尽きに直面しており、SOARは対応における反復的な部分を自動化します。
• SOARは、オーケストレーション（ツールを連携する）、自動化（タスクを実行する）、対応（インシデントのライフサイクルを進める）を意味します。
• SOARは検知ツールの上位に位置し、何が起きたかを何をすべきかへ変換します。
• 主な効果は、MTTRの短縮、一貫性と監査可能性のあるアクション、滞留時間の短縮です。
• 元に戻せない操作には人間を関与させ、確信度の高い経路だけを自動化して、自ら障害を引き起こさないようにします。