SOC（Security Operation Center）とは？役割・業務内容・SIEMとの違いを公的ガイドから解説

SOC（Security Operation Center：セキュリティオペレーションセンター）とは、組織のシステム、ネットワーク、クラウド、エンドポイントなどを継続的に監視し、サイバー攻撃や侵害の兆候を検知・分析し、必要な対応へつなげる機能・組織です。

英国National Cyber Security Centre（NCSC）は、SOCの役割を、予防的なセキュリティ対策をすり抜けたサイバー攻撃を検知し、対応することで組織への被害を抑えることと説明しています。米Cybersecurity and Infrastructure Security Agency（CISA）も、ログを集約して定期的・継続的に監視し、高リスクイベントへアラートを設定することを推奨しています。

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

SOCはSIEMやEDRといった製品名ではありません。検知、トリアージ、分析、エスカレーションを継続的に回すための運用機能です。

SOCのサマリー

• SOCは、組織のIT環境を監視し、サイバー攻撃や侵害の兆候を検知・分析する機能・組織です。
• 英国NCSCは、SOCの主目的を「予防対策をすり抜けた攻撃の検知と対応」と整理しています。
• 米CISAは、ログの集約、高リスクイベントへのアラート設定、定期的な監視を基本的な対策として挙げています。
• イスラエルINCDは、攻撃試行をリアルタイムに検知・警告する仕組みとしてSIEMやSOCを例示しています。
• SOCはSIEM、EDR、NDRなどを利用しますが、これらの製品自体がSOCではありません。
• SOCの代表的な業務は、ログ収集、アラート監視、トリアージ、追加調査、脅威情報の活用、エスカレーション、検知改善です。
• SOCは必ずしも24時間365日である必要はなく、脅威、重要資産、事業影響、利用可能な人員に応じて設計します。
• すべてのログを無条件に集めるのではなく、想定する攻撃シナリオから必要なログを逆算する考え方が重要です。
• 重大な事象を検知した後は、CSIRTや情報システム部門、経営層などとの連携が必要です。
• SOCを構築する目的は「監視画面を見ること」ではなく、異常を必要な時間内に判断し、対応につなげることです。

項目	内容
正式名称	Security Operation Center
主な目的	サイバー攻撃・侵害の検知、分析、対応への接続
主な監視対象	エンドポイント、ネットワーク、認証基盤、クラウド、SaaS、公開システムなど
主なデータ	認証ログ、セキュリティ製品ログ、DNS、ネットワーク、クラウド監査ログなど
主なツール	SIEM、EDR、NDR、SOAR、脅威インテリジェンスなど
主な業務	監視、トリアージ、追加調査、エスカレーション、検知改善
24時間365日	必須ではなく、リスクと運用要件に応じて設計
CSIRTとの関係	SOCが検知・分析した事象をCSIRTなどの対応機能へ引き継ぐ
内製・外部委託	どちらも可能。ハイブリッド運用も可能

SOCとは何をする組織なのか

SOCは、セキュリティ製品から発生するアラートやログを継続的に確認し、実際に対応が必要な事象を見つける役割を担います。

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

つまりSOCの業務範囲は、単純な「監視」に限定されません。

組織によっては、一次分析までをSOCが行い、その後をCSIRTへ渡します。別の組織では、SOCが追加調査や初動対応まで担当する場合があります。

NCSCが「one-size-fits-all SOCはない」としている通り、名称よりも実際に持たせる機能を明確にすることが重要です。

SOCが必要とされる理由

EDR、SIEM、ファイアウォール、クラウド監査ログなどを導入しても、それだけではインシデント対応は完結しません。

EDRがCritical Alertを出した場合でも、誤検知なのか、本当に侵害が起きているのかを判断する必要があります。

SIEMへ大量のログを集約しても、誰も確認していなければ異常を見逃します。

CISAは、中小企業向けの公式ガイドでも、ログを集約し、高リスクイベントへアラートを設定し、ログを定期的に確認することを推奨しています。また、疑わしいインシデントに備えて、技術、広報、法務、事業継続などを含む危機対応チームの役割を決めるよう求めています。

SOCは、セキュリティ製品の「検知」を、人による「分析」と組織の「対応」へつなげる位置にあります。

SOCで監視する主なログ

英国NCSCは、SOCで扱うログについて、アプリケーション、ホスト、ネットワーク、クラウドという4つの大きな分類を示しています。

特に優先度が高いログとして、認証、セキュリティコントロール、DNSを挙げています。

実務では次のようなログが対象になります。

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

イスラエルINCDも、外向き・内向き通信の監視や、高い権限を持つ利用者の活動を個別に監視することを推奨しています。

SIEMとSOCの違い

SIEMはSecurity Information and Event Managementの略で、複数のシステムからログを集約し、検索、相関分析、アラート生成を行うための製品・仕組みです。

SOCは、そのSIEMを含む複数のツールを利用して監視・分析を行う人・プロセス・運用機能です。

整理すると次のようになります。

用語	位置付け
SOC	監視・検知・分析・対応連携を行う組織・機能
SIEM	ログを集約・分析するための基盤
EDR	エンドポイント上の挙動を監視・検知・対応する製品
NDR	ネットワーク通信を監視・分析する製品
SOAR	調査や対応手順の自動化を支援する仕組み

SOCを作ることとSIEMを購入することは同義ではありません。

NCSCも、SOCの設計では最初に脅威、資産、必要な機能を定義し、その後に技術要件を決めるよう示しています。

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

SOCの主な業務

SOCの業務を整理すると、次のようになります。

業務	内容
脅威情報収集	自社に関係する攻撃手法やIOCを把握する
ログ収集	監視に必要なログを取り込む
検知ルール開発	攻撃シナリオを検知ロジックへ変換する
アラート監視	発生したアラートを確認する
トリアージ	誤検知か、追加調査が必要か判断する
追加調査	複数のログを横断して経緯・影響を調べる
エスカレーション	インシデント候補をCSIRTなどへ引き渡す
運用改善	検知ルールやRunbookを改善する

NIST SP 800-61 Rev.3では、Detectを「サイバー攻撃や侵害の可能性を発見・分析する機能」と定義しています。SOCはこのDetectを中心に担う組織として理解すると整理しやすいでしょう。

一方、RespondやRecoverでは、インシデントの優先順位付け、封じ込め、復旧、社内外とのコミュニケーションなど、より広い組織的対応が必要になります。

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

SOCを「24時間365日監視する組織」と定義する説明もありますが、24時間365日はSOCの必須条件ではありません。

英国NCSCは、組織が直面する脅威、守る資産、利用可能なリソースに比例したSOCを設計するよう求めています。また、セキュア・バイ・デザインの環境では、常に大規模なSOCが必要とは限らないとの見解も示しています。

重要なのは、24時間365日という数字ではなく、必要な時間内に重大な事象を検知して対応へつなげられるかです。

24時間監視する場合は、夜間・休日のエスカレーション先や、端末隔離・アカウント停止を実施できる担当者まで決める必要があります。

SOCとCSIRTの関係

SOCは監視・検知・分析に重点を置き、CSIRTはインシデント対応の統括に重点を置く、という整理が一般的です。

ただし、両者の境界は固定されていません。

英国NCSCのCyber Assessment Frameworkでも、監視・検知チームはIncident Managementとシームレスに連携し、必要に応じて同じ人員が両方を担う可能性があるとしています。

NIST SP 800-61 Rev.3も、現代のインシデント対応は専任インシデントハンドラーだけで完結せず、経営、技術、法務、広報、外部事業者など多数の役割が関与するとしています。

SOCで大切なのは「どこまでSOCが担当し、どこからCSIRTへ渡すか」を決めることです。

SOCを内製するか外部委託するか

SOCは自社だけで運用する必要はありません。

外部SOC、MSSP、MDRなどを利用して監視・分析を外部化することもできます。

NISTは、インシデント対応に第三者サービスプロバイダーを利用する形態を想定しており、英国NCSCもSOCの外部委託を選択肢として示しています。

一方、外部事業者は自社の業務背景を自動的に理解しているわけではありません。

重要資産、管理者アカウント、通常業務、例外処理、夜間の連絡先などは企業側から共有する必要があります。

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

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

SOC導入を検討する場合は、最初に製品を選ぶのではなく、次の項目を整理してください。

• 何を守るのか
• どの攻撃を検知したいのか
• そのためにどのログが必要か
• 誰がアラートを見るのか
• 誰がトリアージするのか
• 誰が追加調査するのか
• どの条件でCSIRTへ引き渡すのか
• 夜間・休日は誰に連絡するのか
• 端末隔離やアカウント停止を誰が実行するのか

米CISA、英NCSC、イスラエルINCDの公的ガイドに共通するのは、ログを集めること自体ではなく、リスクに応じて監視し、異常を検知し、役割を決めて対応できる状態を作るという考え方です。

SOCはセキュリティ製品の導入プロジェクトではなく、継続的な運用設計です。

「SOC構築・運用ガイド　24時間365日の監視・分析体制をどう作るか」では、SOC業務の役割分担、自社SOC・外部SOC・MDR・AI SOCの違い、24時間365日体制、自己点検チェックリストを整理しています。

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

出典

• Building a Security Operations Centre (SOC) – UK National Cyber Security Centre
• Onboarding systems and log sources: 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: Incident Response Recommendations and Considerations for Cybersecurity Risk Management – NIST
• Cyber Defense Methodology for an Organization – Israel National Cyber Directorate
• EDRとSOCの違いと関係性を徹底解説 – セキュリティ対策Lab
• MDRとEDRの違いとそれぞれの特徴を解説 – セキュリティ対策Lab