EDR・SIEMを導入してもSOC 運用は完成しない　24時間365日の監視を機能させる役割分担とは

EDRやSIEMを導入したものの、「アラートを十分に確認できない」「夜間・休日は担当者が不在」「重大なアラートが出ても、誰が判断し、誰が対応するのか決まっていない」といった課題は、SOC運用の設計不足から生じることがあります。

英国National Cyber Security Centre（NCSC）は、SOCの運用モデルについて、組織が直面する脅威、守る資産、利用可能なリソースに応じて設計すべきであり、万能なモデルは存在しないとしています。SOCの技術要件や製品を決める前に、各機能の依存関係、入力、プロセス、出力を整理することも推奨しています。

米Cybersecurity and Infrastructure Security Agency（CISA）も、ログの集約、高リスクイベントへのアラート設定、継続的な監視に加え、インシデント発生時の主要連絡先と役割を事前に決めるよう求めています。

イスラエルNational Cyber Directorate（INCD）の「Cyber Defense Methodology for an Organization」でも、攻撃試行をリアルタイムに特定・警告する仕組みとして、SIEMルールやSOCの設置を例示しています。

つまり、SOCの実効性を決めるのはEDRやSIEMの有無だけではありません。検知後のトリアージ、追加調査、エスカレーション、初動対応までを誰が、いつ担うかを決めておく必要があります。

セキュリティ対策Labを運営する合同会社ロケットボーイズが企画・編集し、株式会社ヤグラが提供するホワイトペーパー「SOC構築・運用ガイド　24時間365日の監視・分析体制をどう作るか」では、こうしたSOC運用の役割分担を整理しています。

本記事では、米国・英国・イスラエルの公的ガイドと同資料をもとに、EDR・SIEM導入後に見落としやすいSOC運用のポイントを整理します。

「SOC構築・運用ガイド」では、SOC業務を9つの機能に分け、自社運用・外部委託・AI活用の役割分担、24時間365日の運用設計、12項目の自己点検まで整理しています。

「SOC構築・運用ガイド」をダウンロード

SOC運用のサマリー

• 英国NCSCは、SOCを脅威、重要資産、利用可能なリソースに比例した形で設計するよう推奨しています。
• NCSCは、SOCの各機能と依存関係を整理した後に、必要な技術やツールを決める考え方を示しています。
• 米CISAは、ログの集約、高リスクイベントへのアラート設定、定期的なログ確認を推奨しています。
• CISAは、疑わしいインシデントに備え、技術、広報、法務、事業継続などの役割を含む危機対応体制を定めるよう求めています。
• イスラエルINCDは、攻撃試行をリアルタイムに特定・警告する手段としてSIEMルールやSOCを例示しています。
• 24時間365日の監視はすべての組織に一律で必要な要件ではなく、リスクとリソースに応じて決めます。
• NCSCは、他のIT機能が営業時間内だけでオンコールもない場合、24時間365日のSOCの効果が大きく低下すると指摘しています。
• SOCでは、アラート監視だけでなく、トリアージ、追加調査、インシデント対応への引き継ぎまで設計する必要があります。
• 添付ホワイトペーパーでは、SOC業務を9つの機能に分解し、担当と稼働時間を確認する方法を示しています。
• 同資料の「AI SOC」は公的・標準的な分類名ではなく、AIを監視・トリアージ・調査へ活用する運用モデルを便宜的に表したものです。

確認項目	SOC運用で決める内容
守る対象	重要システム、認証基盤、顧客情報、クラウド管理環境など
想定する脅威	不正ログイン、マルウェア、権限昇格、クラウド設定変更など
必要なログ	IdP、EDR、VPN、DNS、クラウド監査ログなど
監視	誰が、どの時間帯にアラートを確認するか
トリアージ	誤検知か追加調査が必要かを誰が判断するか
追加調査	複数ログを誰が横断して調べるか
エスカレーション	どの条件でCSIRT・情シスへ連絡するか
初動対応	端末隔離、アカウント停止などを誰が実行するか
事業判断	業務停止、復旧、通知、公表を誰が判断するか
運用改善	検知ルール、ログ、Runbookをどう見直すか

EDRやSIEMを導入しても「検知後」の仕事は残る

EDRはエンドポイント上の不審な挙動を検知・分析し、製品によっては端末隔離などの対応機能も備えます。

SIEMは複数のシステムからログを集約し、検索、相関分析、アラート生成などを行います。

しかし、いずれも導入しただけでSOC運用全体が完成するわけではありません。

CISAは、ログを中央管理し、高リスクイベントへのアラートを設定したうえで、ログを定期的に確認することを推奨しています。つまり「ログを取得すること」と「監視・判断できること」は別です。

実際のSOCでは、アラート発生後に次の工程が必要になります。

1. アラートを確認する
2. 誤検知か追加調査が必要かを判断する
3. 関連するログを調べる
4. 影響範囲を確認する
5. 定義した基準に従ってインシデント候補を引き渡す
6. 必要に応じて端末隔離やアカウント停止などへつなげる

NIST SP 800-61 Rev.3でも、サイバー攻撃や侵害の可能性を発見・分析する「Detect」と、確認したインシデントに対して行動する「Respond」を区別しています。

SOC運用では、このDetectからRespondへの接続を設計する必要があります。

関連記事：EDRとSOCの違いと関係性を徹底解説

製品を選ぶ前に「何を守るか」を決める

NCSCのSOCガイドは、Operating Modelを設計する際に、まず組織が直面する脅威と、監視すべき資産を整理するよう求めています。

すべてのIT資産を同じ優先度で監視するのは現実的ではありません。

顧客情報、認証基盤、基幹システム、クラウド管理アカウント、重要サーバーなど、侵害された場合の事業影響が大きい資産を特定し、監視の優先順位を決めます。

重要なのは、単純な資産一覧だけではありません。

たとえば同じ「管理者アカウント」でも、検証環境だけを管理するアカウントと、組織全体のID基盤を変更できるアカウントでは、侵害時の影響が異なります。

SOCが優先順位を付けるには、資産の業務上の重要度を理解する必要があります。

必要なログは攻撃シナリオから逆算する

SOCを構築するとき、「取得できるログをすべてSIEMへ送る」という設計では、コストとアラート量だけが増える可能性があります。

NCSCは、脅威モデリングを使って、守るコンポーネント、想定リスク、攻撃者、攻撃手法、必要なログソース、検知方法を結び付ける考え方を示しています。

たとえば不正ログインやアカウント乗っ取りを調査する場合、IdPの認証ログだけでは十分とは限りません。

• IdP・Active Directory
• MFA設定変更
• VPN
• EDR
• DNS
• Proxy
• クラウド管理操作
• SaaS監査ログ

などを組み合わせることで、単なるログイン失敗なのか、実際にアカウントが侵害され、その後の操作まで行われたのかを判断しやすくなります。

CISAも、ユーザー活動、管理者操作、ネットワーク通信、アプリケーションログイン、システムイベントなどを記録し、サーバー、ファイアウォール、エンドポイント、クラウドサービスのログを中央管理することを推奨しています。

イスラエルINCDは、受信・送信通信の監視や、高い権限を持つユーザーの活動を個別に監視することをガイドに含めています。

SOC業務は機能単位で分けて考える

「SOCを自社で作るか、外部委託するか」という議論だけでは、具体的な役割分担が決まりません。

NCSCもSOCのOperating Modelについて、Threat Intelligence、Detection、Engineering、Incident Response、Incident Managementなどの機能を整理し、それぞれのつながりを設計する考え方を示しています。

「SOC構築・運用ガイド」では、日々の実務へ落とし込むため、SOC業務を次の9つに整理しています。

SOC機能	主な業務
脅威情報収集	自社に関係する攻撃手口やIOCを収集する
ログ収集	必要なログをSOC基盤へ取り込む
検知ルール開発	攻撃シナリオを検知ロジックへ変換する
アラート監視	発報したアラートを決めた時間帯に確認する
トリアージ	誤検知か追加調査が必要かを判断する
追加調査	複数ログを横断して経緯・影響範囲を調べる
初動対応	端末隔離、アカウント停止などを行う
Incident Response / Management	インシデント認定、封じ込め、復旧、報告を統制する
運用改善	検知ルールやRunbookを見直す

このように分けると、「SOCを外注する」という言葉だけでは不十分なことが分かります。

監視だけを委託するのか、トリアージまでか、追加調査までか、初動対応も含むのかを確認する必要があります。

24時間365日「監視できる」と「対応できる」は別

SOCの要件として24時間365日監視が挙がることがあります。

ただし、NCSCは24時間365日SOCについて、他のIT機能が9時から17時までしか稼働せず、オンコール体制もない場合、その有効性は大きく低下すると明記しています。

重大インシデントでは、SOCだけで対応が完結しないためです。

たとえば23時にEDRでCritical Alertが発生した場合を考えます。

SOCが23時5分に調査を開始し、23時30分に侵害の可能性が高いと判断しても、その後に次の担当者が必要になります。

• 端末を隔離する担当
• アカウントを停止する担当
• 業務への影響を判断する担当
• 翌朝までの暫定対応を決める担当
• 必要に応じて経営・法務へ連絡する担当

NCSCはSOCのHours of operationについて、24時間365日のSOCは9時-17時の運用より多くの人員が必要であり、高脅威環境では適切な場合がある一方、営業時間内＋オンコールという選択肢も示しています。

インシデントレスポンス側についても、NCSCは、必要な対応時間を事業特性とリスク許容度に応じて決め、平日のみ、延長営業時間、24時間365日、オンコール、外部事業者などを比較するよう求めています。

24時間365日は目的ではなく、必要な時間内に対応できる体制を作るための選択肢です。

ホワイトペーパーでは、夜23時にCritical Alertが発生したケースを例に、「監視時間」「アラートの受け手」「夜間・休日のエスカレーション先」「実際の対応担当」の4項目を確認できるようにしています。

24時間365日のSOC運用設計を確認する

外部委託は「SOCという名称」ではなく担当範囲で比較する

NCSCは、SOCの一部機能を外部委託することを現実的な選択肢として扱っています。

外部委託には専門人材を利用しやすい利点がある一方、外部事業者は自社固有の業務コンテキストを持ちにくいという課題があります。

比較すべきなのは「MSSPかMDRか」といった名称だけではありません。

• 誰が監視するか
• 誰がトリアージするか
• 誰が追加調査するか
• どのログまで調査できるか
• 誰がインシデント候補と判断するか
• 端末隔離などを実施できるか
• 夜間・休日は誰へ連絡するか

を確認する必要があります。

MDRなどのサービス名称や対応範囲には事業者差があります。契約時には、実際の作業範囲と責任分界を確認することが重要です。

関連記事：MDRとEDRの違いとそれぞれの特徴を解説

技術調査を外部化しても、事業判断は社内に残る

SOC運用では「調べる仕事」と「決める仕事」を分けると、内製・外部委託の境界を整理しやすくなります。

たとえばログ検索、IOC照合、一次トリアージ、関連イベントの収集、技術的な影響範囲の調査は、外部事業者へ委託しやすい業務です。

一方、次の判断は組織固有の事情を踏まえる必要があります。

• 重要システムを停止するか
• 業務を継続するか
• 顧客・取引先へ通知するか
• 規制当局へ報告するか
• 復旧をどの順番で進めるか
• 公表するか

NIST SP 800-61 Rev.3では、インシデント対応に経営、技術、法務、広報、事業継続、第三者サービスプロバイダーなど多数の役割が関与することを前提にしています。

NCSCもCSIRTの構成について、IT・Cyber Securityだけでなく、経営、法務、広報、人事などが必要に応じて参加するとしています。

SOCの技術調査を外部化しても、事業リスクそのものを外部へ移すことはできません。

「AI SOC」は公的な標準分類ではない

「SOC構築・運用ガイド」では、自社SOC、外部SOC・MSSP、MDRと並び、AIを監視・トリアージ・調査へ利用する運用モデルを便宜上「AI SOC」と表記しています。

ここは、一般的なSOCの用語と区別する必要があります。

「AI SOC」はNIST、CISA、NCSC、INCDなどが定めた公的・標準的な分類名ではありません。

同資料では、AIへ任せる候補として、アラート監視、一次調査、関連情報収集、複数ログの横断調査などを整理し、インシデント認定、システム停止、復旧、顧客通知、公表などの事業判断は社内へ残すモデルを示しています。

株式会社ヤグラの「ヤグラAI SOC」も、既存のEDRやSIEMで発生するアラートの監視・調査を支援するサービスとして説明されています。

同社が公開する機能や性能に関する情報はサービス提供者による説明であり、公的機関が同製品を推奨しているものではありません。また、第三者による検証値や、すべての環境で同じ効果を保証するものではありません。

SOCの課題は「製品数」ではなく運用の空白から確認する

SOC運用を見直す場合は、「新しい製品が必要か」を考える前に、担当の空白を確認します。

まずは次の点を確認してください。

• EDR・SIEMのアラートを継続的に確認できているか
• 夜間・休日のCritical Alertの受け手が決まっているか
• アラートの真偽を判断できる担当者がいるか
• EDRだけでなくIdPやクラウドなどを横断して調査できるか
• 検知ルールを定期的に見直しているか
• 調査手順がRunbook化されているか
• 端末隔離・アカウント停止の権限者が決まっているか
• インシデント認定者が決まっているか
• SOCからCSIRTへのエスカレーション条件があるか
• 担当者の休暇・退職時にも運用を継続できるか

ホワイトペーパーでは、これらを監視、分析、検知、運用、対応、連携、継続性の7領域、12項目に整理しています。

「はい／いいえ」で確認することで、監視ツールの不足ではなく、トリアージ、調査、対応、連携のどこに問題があるかを把握しやすくなります。

情報システム・セキュリティ部門への示唆

SOC運用の見直しでは、最初に現在の担当と稼働時間を書き出すことが有効です。

業務	担当	稼働時間
アラート監視
トリアージ
追加調査
端末隔離
アカウント停止
インシデント認定
夜間エスカレーション
復旧判断

空欄があれば、インシデント時に対応が止まる可能性があります。

次に、守る資産、想定する攻撃、必要なログ、エスカレーション基準を整理し、どこを自社で担い、どこを外部化・自動化するかを決めます。

NCSCが示すSOC設計でも、脅威、資産、SOCの機能、依存関係、入出力を整理した後に、必要な技術要件やツールを決める流れになっています。

EDRやSIEMを導入済みでも、SOC運用が機能していない場合に最初に見直すべきなのは製品ではなく、担当とプロセスです。

SOC構築・運用を25ページで整理

「SOC構築・運用ガイド　24時間365日の監視・分析体制をどう作るか」は全25ページで、SOCの機能整理から役割分担、監視時間、自己点検、AI活用までを7章で整理しています。

資料では、主に次の内容を確認できます。

• SOC構築前に決める脅威プロファイルと重要資産
• SOCに必要な9つの業務
• SOC・情報システム部門・CSIRT・経営の役割分担
• 自社SOC・外部SOC／MSSP・MDR・AI活用の比較
• 24時間365日の監視と対応時間の考え方
• 必要なログを攻撃シナリオから逆算する方法
• アラート過多と検知ルール見直しの考え方
• 12項目のSOC体制自己点検チェックリスト
• SOC成熟度の整理
• AIへ任せる範囲と社内に残す判断
• 現在の状態から運用モデルを検討するための分岐

EDRやSIEMを導入済みで、アラート対応や夜間・休日の監視に課題がある企業だけでなく、これからSOCを設計する企業も利用できる内容です。

監視、トリアージ、調査、判断のどこを自社に残し、どこを外部やAIへ任せるか。

25ページのガイドと12項目のチェックリストで、自社のSOC運用を整理できます。

無料で「SOC構築・運用ガイド」をダウンロード

出典

• Building a Security Operations Centre (SOC) – UK National Cyber Security Centre
• Designing an Operating Model – UK National Cyber Security Centre
• The target operating model – UK National Cyber Security Centre
• Log sources – UK National Cyber Security Centre
• Threat modelling – UK National Cyber Security Centre
• Build: A cyber security incident response team (CSIRT) – UK National Cyber Security Centre
• Use Logging on Business Systems – U.S. Cybersecurity and Infrastructure Security Agency
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management – NIST
• Cyber Defense Methodology for an Organization – Israel National Cyber Directorate
• Cyber Defense Doctrine 2.0 – Israel National Cyber Directorate
• EDRとSOCの違いと関係性を徹底解説 – セキュリティ対策Lab
• ヤグラ AI SOC – 株式会社ヤグラ
• MDRとEDRの違いとそれぞれの特徴を解説 – セキュリティ対策Lab