LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてセキュリティ運用基盤の開発・運用を受託

アラートの洪水と対応の属人化——SOC運用が抱える課題

セキュリティ運用の現場では、SIEMや各種セキュリティ製品が日々大量のアラートを吐き出します。Microsoft社は、SIEMやSOC(セキュリティオペレーションセンター)のチームが、担当者では処理しきれない量のアラートとインシデントに日常的にさらされていると指摘しています^*1。結果として、多くのアラートが見過ごされ、調査されないインシデントが残り、気づかれないまま攻撃を許す状況が生まれかねません^*1。

負荷が高まる理由は、一件ごとの対応が多数の手作業の積み重ねになっている点にあります。担当者はアラートを受け取ると、送信元IPやドメインの評判を調べ、資産管理台帳と突き合わせ、過去の類似事象を検索し、関係者へ連絡し、必要ならチケットを起票します。こうした定型作業は繰り返しが多い一方で、担当者の勘や手順書への習熟に依存しやすいのが実情でしょう。

属人化が進むと、熟練者の不在がそのまま対応の停滞につながります。IPA(独立行政法人情報処理推進機構)も、中小企業向けの手引きで、インシデント対応を「検知・初動対応」「通知・公表」「復旧・再発防止」といった段階に整理し、組織として対応できる体制づくりの重要性を示しています^*4。手順を仕組みに落とし込み、繰り返し作業を自動化する発想が、SOAR(セキュリティ自動化)の出発点です。本稿では、公式情報をもとにSOARの役割と機能要素、外注時の確認点を整理します。

SOAR(セキュリティ自動化)とは、インシデント対応を自動化・オーケストレーションする仕組み

SOARは「Security Orchestration, Automation and Response」の略で、セキュリティのオーケストレーション・自動化・対応を指す言葉です。Microsoft社は、Microsoft SentinelがSIEMであると同時にSOARの基盤でもあると説明し、その主目的の一つを、SOCや運用担当が繰り返し担う予測可能なエンリッチメント・対応・是正のタスクを自動化することだとしています^*1。定型作業を仕組みに委ねることで、担当者は高度な脅威の調査やハンティングに時間を割けるようになります^*1。

ここで鍵になるのが「対応の自動化」と「複数ツールの連携」という二つの側面です。SOARは、検知されたインシデントに対して、情報収集から通知、初期対応までの一連の流れを、あらかじめ定義した手順に沿って実行します。Microsoft Sentinelでは、この自動化を中央で管理する「オートメーションルール」と、対応・是正のアクションをまとめた「プレイブック」という二つの部品で構成しています^*1。

NIST(米国国立標準技術研究所)も、インシデント対応をリスク管理の活動全体へ組み込むための推奨事項を、SP 800-61 Revision 3として公開しています^*3。検知・分析から対応までを場当たり的にではなく体系立てて回す考え方は、SOARが自動化の対象とする領域と重なります。つまりSOARは、まったく新しい対応を発明するものではなく、確立された対応の流れを、人の判断を残しつつ機械に肩代わりさせる仕組みだと捉えると分かりやすいでしょう。

SIEM・SOCとの違い——検知・監視とSOARの役割分担

セキュリティ運用の文脈では、SIEM・SOC・SOARがしばしば並べて語られます。三者は密接に連携しますが、担う役割はそれぞれ別のレイヤーです。ここを混同したまま要件を決めると、「検知はできるが対応が回らない」といった偏りが生まれかねません。

SIEM(Security Information and Event Management)は、各種ログやイベントを集約し、相関分析によって脅威の兆候を検知する基盤です。SOC(Security Operation Center)は、そのSIEMなどを使ってセキュリティを監視し、インシデントに対応する運用の体制や組織を指します。これに対してSOARは、SOCが担う対応作業のうち、繰り返し発生する定型的な処理を自動化し、複数のツールをまたいで手順を組み立てる部分を受け持ちます^*1。検知はSIEM、監視運用はSOC、そして対応の自動化と連携はSOARという分担です。

三者の関係を整理すると、次の表のようになります。

この分担は、どれか一つを入れれば足りるという関係ではありません。検知の精度が低いままSOARだけを入れても、自動化すべき良質なアラートが十分に上がってこないおそれがあります。逆に、検知はできていても対応が手作業のままでは、SOCの負荷は下がりにくいでしょう。三者をどこまで自社で持ち、どこを外部に委ねるかを見極めることが、導入設計の起点になります。

SOARの機能要素——オーケストレーション・プレイブック・チケット連携

SOARが担う中身を、機能の側面から具体的に見ていきます。Microsoft Sentinelの公式ドキュメントでは、プレイブックが役立つ代表的なユースケースとして、エンリッチメント、双方向同期、オーケストレーション、対応(レスポンス)の4つが挙げられています^*2。これらを軸に、SOARの機能要素を4点に整理します。

オーケストレーション——複数ツールを束ねて対応を組み立てる

オーケストレーションは、複数のセキュリティ製品や業務ツールをまたいで、一連の対応を組み立てる働きです。Microsoft Sentinelのプレイブックは、内外の他システムと連携できるよう設計されており、脅威対応を自動化・オーケストレーションする役割を担います^*1*2。個々のツールに閉じていた操作を横串でつなぐことで、担当者が画面を行き来しながら手作業でこなしていた工程を一本の流れにまとめられます。

プレイブック——対応手順を定型化して自動実行する

プレイブックは、対応・是正のアクションとロジックをまとめ、定型の処理として実行できる部品です^*1。Microsoft Sentinelでは、プレイブックはAzure Logic Apps上のワークフローとして構築され、特定のアラートやインシデントに応じて自動実行することも、担当者が必要に応じて手動で実行することもできます^*1*2。あらかじめ検証済みのテンプレートを土台に組み立てられる仕組みも用意されており、ゼロから作り込む負担を抑えられます^*2。

チケット・通知連携——ServiceNowやTeams・Slackとつなぐ

対応の流れを止めないためには、既存の運用ツールとの連携が欠かせません。Microsoft Sentinelは、インシデントをServiceNowのようなチケット管理システムと双方向に同期する使い方や、Microsoft TeamsやSlackのチャネルへ通知を送り、担当者にインシデントを知らせる使い方を公式のユースケースとして示しています^*2。起票や通知を自動化すれば、連絡漏れや二重起票を減らし、対応状況を一元的に追いやすくなるでしょう。

一次対応の自動実行と人の判断ポイント

SOARの効果が最も分かりやすいのが、一次対応の自動実行です。Microsoft社は、アカウントとマシンが侵害された際に、SOCが通知を受け取る前にプレイブックが自動でマシンをネットワークから隔離し、アカウントをブロックする例を挙げています^*2。一方で、影響範囲の大きい封じ込めや、業務への影響を伴う遮断の可否は、人が判断すべき場面も残ります。実際、対応(レスポンス)のユースケースでは、最小限の人の関与で即時に対応する形と、調査やハンティングの途中で担当者が手動で自動処理を起動する形の両方が示されています^*2。どこまでを自動で走らせ、どこで人の承認を挟むかという判断ポイントの設計が、運用の信頼性を左右します。

SOARの開発・構築を外注する際に確認したいこと

SOARは、既存のセキュリティ製品や業務システムとの連携が品質を大きく左右します。開発・構築を外注する際は、次の点を委託先とすり合わせておくと、導入後の手戻りを抑えやすくなります。

連携する製品・ツールの範囲を明確にする

まず、どのSIEMやEDR、チケット管理システム、チャットツールと連携するのかを洗い出します。連携先が増えるほど、必要なコネクターやAPIの検証範囲は広がります。自社が現在使っている製品と、今後導入予定の製品を棚卸ししたうえで、対応範囲を委託先と共有しておくと、見積りからの抜け落ちを防げるでしょう。

プレイブックの設計と保守体制を確認する

プレイブックは一度作れば終わりではなく、脅威の傾向や運用ルールの変化に合わせて見直す前提の部品です。どの対応をプレイブック化するか、その手順を誰がどう保守するか、テンプレートをどこまで流用するかを整理しておく必要があります^*2。稼働後に手順を更新する運用まで含めて、委託先の対応範囲を確認しておきたいところです。

自動化と人の承認の切り分けを設計する

前章で触れたとおり、SOARでは自動で走らせる範囲と、人が判断する範囲の線引きが重要です。隔離やブロックのように影響が大きいアクションは、自動実行とするか、承認を挟む半自動とするかを事前に決めておく必要があります^*2。誤検知を起点に業務を止めてしまう事態を避けるためにも、判断ポイントの設計思想を委託先とすり合わせておく必要があります。

既存の監視・運用体制との役割分担を決める

SOARはSOCの運用を効率化する道具であり、監視や意思決定そのものを置き換えるものではありません。既存の監視体制やインシデント対応フローのどこにSOARを組み込むか、内製で保守する範囲と外注する範囲をどう分けるかを決めておくことが大切です。IPAやJPCERT/CCが示す組織的なインシデント対応体制の考え方も、役割分担を整理する際の参照点になります^*4*5。

まとめ：SOARでSOC運用を効率化する要点

本稿では、SOAR(セキュリティ自動化)の役割と機能要素、外注時の確認点を公式情報に沿って整理しました。要点は3つに集約できます。第一に、SOARはインシデント対応の定型作業をオーケストレーションとプレイブックで自動化し、SOC担当者を繰り返し作業から解放する仕組みです^*1。第二に、検知を担うSIEM、監視運用を担うSOCとは別レイヤーにあり、対応の自動化とツール連携という役割分担を押さえることが導入設計の起点になります^*1。第三に、一次対応を自動化しつつ、影響の大きい判断は人が担う設計が基本であり、外注時は連携範囲・プレイブックの保守・判断ポイントの切り分けが確認の軸です^*2。自社の検知精度や運用体制をふまえ、どこまでを自動化し、どこを人が担うかを見極めることが、SOAR活用の第一歩といえるでしょう。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Microsoft「Automation in Microsoft Sentinel」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/sentinel/automation/automation）
2. *2　出典：Microsoft「Automate threat response with playbooks in Microsoft Sentinel」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/sentinel/automate-responses-with-playbooks）
3. *3　出典：NIST「SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management」（2025年）（https://csrc.nist.gov/pubs/sp/800/61/r3/final ）
4. *4　出典：IPA（独立行政法人情報処理推進機構）「中小企業の情報セキュリティ対策ガイドライン（付録8 中小企業のためのセキュリティインシデント対応の手引き）」（https://www.ipa.go.jp/security/guide/sme/about.html ）
5. *5　出典：JPCERT コーディネーションセンター（JPCERT/CC）「CSIRTマテリアル」（https://www.jpcert.or.jp/csirt_material/ ）

Tweet