SOCとは？役割・業務内容、SIEM・EDR・CSIRTとの違いを公的ガイドから解説

SOC（Security Operations Center／Centre）は、組織のシステムやクラウド、ネットワーク、エンドポイントなどを継続的に監視し、サイバー攻撃や侵害の兆候を検知・分析して、必要な対応へつなげる機能・組織です。

SOCはSIEMやEDRの製品名ではありません。ログやアラートを集める技術に加えて、「何を監視するか」「どの事象を調査するか」「誰が判断するか」「どの条件でCSIRTや情報システム部門へ引き継ぐか」を運用として成立させる役割を担います。

英国National Cyber Security Centre（NCSC）は、SOCの中心的な役割を、予防対策をすり抜けたサイバー攻撃を検知し、対応することで組織への被害を抑えることと説明しています。SOCの規模や業務範囲に共通の正解はなく、脅威、守る資産、利用できる人員・予算に合わせて設計します。

SOCとは

SOCは、セキュリティ監視を継続的に行うための人、プロセス、技術を組み合わせた運用機能です。

一般的には次の流れを担当します。

1. EDR、認証基盤、クラウド、ネットワークなどからログやアラートを集める
2. 異常なイベントを検知する
3. 誤検知か、追加調査が必要な事象かをトリアージする
4. 関連ログを調べ、侵害の可能性と影響範囲を確認する
5. 定めた条件に従ってCSIRTや情報システム部門へエスカレーションする
6. インシデントの結果を検知ルールやRunbookへ反映する

SOCがどこまで担当するかは組織によって異なります。一次分析まででCSIRTへ渡す企業もあれば、端末隔離やアカウント停止などの初動までSOCが担当する企業もあります。

NCSCも、SOCには脅威インテリジェンス、脅威ハンティング、検知ルール開発、エンジニアリング、インシデント対応など複数の機能を含められるとしています。

SOCの主な役割

SOCの業務は「アラートを見ること」だけではありません。代表的な機能を分けると次のようになります。

機能	主な内容
セキュリティ監視	ログやアラートを継続的に確認する
トリアージ	誤検知、要調査、緊急対応の優先度を判断する
追加調査	複数ログを横断し、攻撃経路や影響範囲を確認する
検知ルール開発	想定する攻撃手法をSIEM・EDRなどの検知条件へ落とす
脅威インテリジェンス	自社に関係する攻撃者、TTP、IOCを把握する
脅威ハンティング	既存アラートで検知できていない侵害の兆候を能動的に探す
エンジニアリング	ログ連携、監視基盤、検索環境などを維持する
エスカレーション	インシデント候補をCSIRT、情シス、管理者へ引き継ぐ
運用改善	誤検知、見逃し、実インシデントの結果を監視へ戻す

すべてのSOCが上記を内製する必要はありません。外部SOC、MSSP、MDRを組み合わせ、一部機能だけを社内に残す構成もあります。

SOCが必要になる理由

セキュリティ製品を導入しても、検知後の判断と対応が自動的に完了するわけではありません。

たとえばEDRが高リスクのアラートを出した場合でも、少なくとも次の確認が発生します。

• 対象端末は業務上どの程度重要か
• 検知したプロセスは正規業務か
• 同じアカウントで別端末への不審なログインがないか
• 外部通信や認証情報窃取の兆候がないか
• 端末隔離が必要か
• CSIRTへ引き継ぐ条件を満たすか

SIEMも同様です。ログを集約しても、検知条件、優先順位、調査手順、担当者が決まっていなければ運用は止まります。

米Cybersecurity and Infrastructure Security Agency（CISA）は、サーバー、ファイアウォール、エンドポイント、クラウドサービスなどのログを中央で管理し、高リスクイベントへアラートを設定して定期的に監視することを案内しています。

SOCは、こうした技術的な「検知」を、組織としての「判断」と「対応」へ接続する位置にあります。

SOCでは何を監視するのか

NCSCは、SOCで扱うログを大きくApplication、Host、Network、Cloudに分類しています。

その中でも初期の監視対象として、認証、セキュリティコントロール、DNSのログを挙げています。

企業では、次のようなデータが候補になります。

• Active Directory、Entra IDなどの認証ログ
• EDR、アンチマルウェアの検知ログ
• ファイアウォール、VPN、Proxy
• DNS
• WAF、Webサーバー
• Microsoft 365、Google Workspace
• AWS、Azure、Google Cloudの監査ログ
• SaaSの管理操作ログ
• 特権ID管理システム
• 重要な業務アプリケーションの操作ログ

すべてのログを無条件にSIEMへ投入する方法は、保存コストや分析負荷を増やします。

NCSCは、想定する脅威と攻撃経路から必要なログを特定するThreat ModellingをSOC設計に組み込んでいます。たとえば「クラウド管理者アカウントの乗っ取り」を検知したいのであれば、認証ログ、MFA変更、特権付与、管理操作など、その攻撃を追跡できるデータを優先します。

SOCとSIEMの違い

SOCとSIEMは同じものではありません。

SIEM（Security Information and Event Management）は、複数のシステムからログを集め、検索、相関分析、アラート生成などを行う基盤です。

SOCは、SIEMを含む複数の技術を使い、監視、分析、判断、エスカレーションを行う運用機能です。

用語	主な位置付け
SOC	セキュリティ監視・分析・対応連携を担う組織・機能
SIEM	ログの集約、検索、相関分析、アラート生成を行う基盤
EDR	エンドポイントの挙動を監視し、検知・調査・隔離などを行う製品
NDR	ネットワーク通信を監視・分析する製品・機能
SOAR	調査や対応手順の自動化を支援する仕組み
MDR	ベンダーが監視・調査・対応支援を提供するマネージドサービス

SIEMを購入しただけでSOCが完成するわけではありません。

逆に、監視対象が限定される企業では、SIEMを大規模導入せず、EDRやクラウドの標準監視機能と外部サービスを組み合わせてSOC機能を作る場合もあります。

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

SOCとCSIRTの違い

SOCとCSIRTは、サイバーインシデント対応の異なる段階を中心に担当します。

SOCは、攻撃・侵害の兆候を見つけ、分析する機能に重点があります。

CSIRT（Computer Security Incident Response Team）は、インシデントとして扱うべき事象について、封じ込め、復旧、社内調整、法務・広報・経営との連携などを進める機能に重点があります。

NIST SP 800-61 Rev.3は、NIST Cybersecurity Framework 2.0に沿って、インシデント対応をDetect、Respond、Recoverを含む継続的なリスク管理として整理しています。

SOCとCSIRTを別部署にする必要はありません。NCSCのCyber Assessment Frameworkでは、MonitoringとIncident Managementが同じ人員で構成される場合もあるとしています。

分ける場合は、「どの条件でSOCがCSIRTへ引き継ぐか」を決めます。

SOCは24時間365日必要なのか

SOCを24時間365日で運用する企業はありますが、24時間365日はSOCの定義要件ではありません。

NCSCは、SOCの能力を脅威と資産に比例させる考え方を示しており、セキュア・バイ・デザインの環境では常に大規模なSOCが必要とは限らないとしています。

監視時間を決める際は、次の条件を確認します。

• 重要システムが稼働する時間
• 夜間に侵害された場合の許容時間
• 海外拠点やクラウドサービスの利用状況
• 顧客・取引先への影響
• 規制・契約上の要件
• 社内のオンコール体制
• 外部SOCやMDRのSLA

24時間監視を導入する場合は、夜間にアラートを受けるだけでなく、その後に端末隔離やアカウント停止を実施できる担当者まで決めます。

24時間365日の役割分担については、EDR・SIEMを導入してもSOC運用は完成しない　24時間365日の監視を機能させる役割分担とはで整理しています。

SOCは内製と外部委託のどちらがよいか

SOCの機能は、すべてを社内で持つ方法と、外部SOC、MSSP、MDRへ一部または全部を委託する方法があります。

内製では、自社のシステムや業務背景を理解した分析をしやすい一方、監視要員、検知開発、基盤運用など複数の役割を維持する必要があります。

外部委託では、専門人材や24時間監視を利用しやすくなりますが、委託先が自社の重要資産や例外業務を自動的に理解するわけではありません。

契約前には次を確認します。

• 監視だけか、一次分析まで含むか
• 追加調査の範囲
• 夜間・休日の連絡方法
• 端末隔離などの初動を代行するか
• 調査結果に根拠となるログが含まれるか
• CSIRTへ引き渡す情報
• 自社側に残る作業と意思決定

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

SOC導入前に情報システム部門が確認したいポイント

SOCの検討時は、製品名より先に次の項目を決めます。

• 侵害された場合に事業影響が大きい資産は何か
• 優先して検知したい攻撃シナリオは何か
• その攻撃を追跡するログが取得できているか
• アラートを誰が確認するか
• 誤検知かどうかを誰が判断するか
• 追加調査を誰が行うか
• どの条件でCSIRTへ引き渡すか
• 端末隔離やアカウント停止を誰が実行するか
• 夜間・休日にどこまで対応するか
• 検知ルールを誰が改善するか

SOCは「監視製品を入れること」ではなく、検知から対応までの責任分界を決める運用設計です。

より具体的な構築手順や自己点検項目は、SOC構築・運用ガイド -24時間365日の監視・分析体制をどう作るか-で確認できます。

出典

• Building a Security Operations Centre (SOC) – UK National Cyber Security Centre
• Operating Model – UK National Cyber Security Centre
• Log sources – UK National Cyber Security Centre
• Use Logging on Business Systems – U.S. Cybersecurity and Infrastructure Security Agency
• NIST SP 800-61 Rev. 3 – NIST
• CAF Objective C: Security monitoring – UK National Cyber Security Centre
• Cyber Defense Methodology for an Organization – Israel National Cyber Directorate