EDRやファイアウォールなどのセキュリティ製品に加え、企業が利用するクラウドサービスも多様化しています。それに伴って、各製品から出るアラートを継続的に確認し、優先順位を付けて対応する負担も大きくなりました。アラートが出ていても、分析する人や対応手順がなければ、攻撃の発見が遅れる可能性があります。この監視・分析の中核を担うのがSOCです。本記事では、SOCとは何か、どのような仕組みでセキュリティ監視を行うのかを解説し、CSIRT、EDR、MDRとの違いや、内製と外部委託を含む体制整備の考え方を紹介します。
contents
SOCとは
SOCとは「Security Operations Center」の略で、一般に「セキュリティオペレーションセンター」と呼ばれます。組織内のセキュリティイベントを継続的に監視し、攻撃の兆候を検知・分析して、必要な対応へつなげる機能または組織です。名称に「センター」とありますが、必ずしも一つの部屋に担当者が常駐する形に限られません。社内の専任チームが運営するSOC、複数部署の担当者が兼務するSOC、外部のセキュリティ事業者に監視・分析を委託するSOC、社内と外部が共同運営するSOCがあります。重要なのは場所ではなく、監視対象、分析方法、連絡先、対応権限を定めて継続的に機能させることです。
NIST SP 800-61 Rev.3では、インシデント対応に社内要員だけでなく、外部のサービス事業者や専門家を活用する考え方も示されています。SOCは必ずしも自社内で完全に内製する必要はなく、外部の専門性を組み合わせて運営することもできます。
SOCの主な役割
ログやアラートを集めて監視する
SOCは、契約または運用設計で定めた情報源から、セキュリティに関係するログやアラートを収集します。対象には、EDR、ファイアウォール、IDS・IPS、認証基盤、サーバー、クラウド、SaaS、ネットワークセンサーなどがあります。すべてのログを無条件に集めるのではなく、守るべき資産と想定する攻撃を踏まえて、検知に必要な情報を選ぶことが重要です。
IPAが公開する「プラクティス・ナビ」では、外部との接続点だけでなく内部環境も対象とし、攻撃の特性を考慮したログを取得する必要性が示されています。監視対象が不足していれば攻撃の痕跡を見落とし、逆に目的なくログを増やせば、コストと分析負荷が膨らみます。SOCの設計はログ収集基盤の導入ではなく、何を見つけるために何を集めるかを決めるところから始まります。
複数の情報を関連付けて分析する
一つのアラートだけでは、正常な操作か攻撃かを判断できないことがあります。たとえば、深夜のログイン、短時間に繰り返される認証失敗、端末上の不審なプロセス、未知の外部サーバーへの通信が関連していれば、アカウント侵害から内部侵入へ進んでいる可能性を検討できます。
NIST SP 800-61 Rev.3では、複数ソースの情報を相関させ、脅威インテリジェンスや資産情報などの文脈を分析に組み込むことを推奨しています。SOCでは、こうした関連性をSIEMやXDRなどの技術で可視化し、担当者が攻撃の可能性、影響範囲、緊急度を評価します。
トリアージとエスカレーションを行う
SOCが受け取るイベントには、実害のない通知や誤検知も含まれます。そこで、検知内容の真偽と重要度を確認し、対応が必要な事象を絞り込むトリアージを行います。インシデントの可能性が高い場合は、定められた連絡先へ状況と推奨対応を伝え、CSIRTやシステム管理者などへ引き継ぎます。
連絡は「アラートが出た」という事実だけでは不十分です。どの端末やアカウントで何が起き、どのような攻撃が疑われ、既に実施した措置は何か、次に何を確認すべきかが整理されていれば、受け取った側は判断しやすくなります。
初動対応と継続改善を支える
SOCの役割を「監視だけ」と決めつけることはできません。組織や契約によっては、感染端末の隔離、アカウント無効化、通信遮断などの初動封じ込めまでSOCが担います。一方で、業務停止を伴う措置には組織側の承認を必要とする設計もあります。どこまで実行できるかは、平時に権限と条件を決めておく必要があります。
また、SOCは検知ルールや手順を固定したまま運用するものでもありません。誤検知の傾向、見逃した事象、システム変更、新しい攻撃手法を踏まえ、検知ルール、監視対象、分析手順を継続的に見直します。英国NCSCのSOC構築ガイダンスも、検知ルールのライフサイクルを設け、頻出アラートや誤検知を定期的に見直す必要性を示しています。
SOCを支える主な技術
SIEMは、さまざまな機器やシステムのログを集約し、検索や相関分析を行うための基盤です。SOARは、調査や通知、対応などの手順を連携・自動化します。EDRは、端末上の挙動を監視し、脅威の検知・調査・対応を支援する技術・製品です。NDRはネットワーク通信の分析、XDRは端末・認証・クラウドなど複数領域の情報を横断した検知・対応を目指す技術です。
これらはSOCが利用する道具やデータソースであり、SOCそのものではありません。技術を導入しても、監視対象の設計、アラートの評価、判断基準、対応手順がなければ、セキュリティ監視は機能しにくくなります。逆に、優秀な担当者がいても、必要なログを取得できなければ調査には限界があります。SOCは人、プロセス、技術を組み合わせて運営する必要があります。
SOCとCSIRTの違い
SOCとCSIRTは密接に連携しますが、一般的には役割の重心が異なります。SOCは平時からセキュリティイベントを監視・分析し、攻撃の兆候を見つける前線です。CSIRTは、インシデントが疑われる、または発生した際に、封じ込め、原因調査、復旧、社内外の調整などを進める対応組織です。
ただし、「SOCは検知だけ、CSIRTは対応だけ」と完全に切り分けられるわけではありません。SOCが一次的な封じ込めを行う場合もあり、CSIRTが平時の監視改善に関与する場合もあります。企業規模によっては同じ担当者が両方の役割を担います。重要なのは名称ではなく、SOCからCSIRTへ何を、いつ、どの経路で伝えるか、誰が業務停止や対外公表を判断するかを明確にすることです。
CSIRTの役割やインシデント対応体制については、関連記事「インシデント対応体制とは？CSIRTの役割と企業が整えるべき運用のポイント」でも解説しています。
SOCとEDR・MDRの違い
EDRは、端末上の脅威の検知・調査・対応を支援する技術・製品です。製品によっては端末隔離や悪性ファイルの停止を実行できますが、アラートの監視者や組織内のエスカレーションまで自動的に整うわけではありません。SOCはEDRを情報源の一つとして利用し、人とプロセスを介して対応につなげます。
EDRの仕組みや主な機能、導入後の運用課題については、「EDRとは？仕組みや主な機能、導入後の運用課題を解説」で詳しく紹介しています。
MDRは、専門家による脅威の監視・検知・分析・対応を提供するセキュリティ運用サービスです。外部事業者のSOCがMDRの提供基盤になることもあります。自社SOCのすべてを置き換えるだけでなく、夜間監視や高度分析など不足する機能だけを補う使い方も可能です。
MDRの仕組みや導入メリット、EDR・SOCとの違いについては、「MDRとは？EDR・SOCとの違いや導入メリット、選び方を解説」をご覧ください。
SOCは内製と外部委託のどちらがよいか
内製SOCは、自社のシステムや業務を理解した担当者が判断しやすく、検知ルールや対応手順を細かく調整できる点が強みです。一方で、継続的な採用・育成、交代勤務、監視基盤の維持、担当者の負荷管理が必要です。特に24時間365日の有人体制を自社だけで構築する場合は、単純に担当者を一人置けば済むものではありません。
外部委託は、専門家と監視基盤を活用し、夜間・休日を含む監視や高度な分析を補いやすい方法です。ただし、委託すれば責任まで移せるわけではありません。NISTは、外部事業者との契約で、情報の流れ、連携方法、代理で実行できる対応、その制限を明確にするよう求めています。IPAも、EDR管理やセキュリティ監視は外部委託可能としながら、丸投げではなく、自社の対策状況を把握し、ベンダーと意思疎通できる人材が必要だとしています。
社内のCSIRTやIT担当者が事業判断と調整を担い、外部SOCやMDRが常時監視と技術分析を担うハイブリッド型も、有効な選択肢です。内製か外部委託かの二者択一ではなく、自社で保持すべき判断と、外部の専門性を使う業務を切り分けることが大切です。
SOCを構築・委託するときの確認事項
まず、守るべき業務と資産、想定する攻撃を整理し、その検知に必要なログを決めます。次に、監視時間、検知から通知までの目標時間、連絡方法、重大度の基準、夜間の連絡先を定めます。インシデントが疑われる場合は、端末隔離やアカウント停止を誰が承認し、誰が実行するのかも具体化します。
外部委託では、既存製品との連携可否、ログの保管場所と保護方法、事業者が顧客環境へ接続する方法、分析結果の提供内容、チューニング、フォレンジックや緊急対応の範囲を確認します。事業者自身が攻撃を受けるリスクもあるため、アクセス制御や監査、インシデント発生時の通知方法も選定条件です。
運用開始後は、通知件数だけで良し悪しを判断しないことも重要です。重要な事象を見逃さず、誤検知を抑え、通知から判断・封じ込めまでの時間を短縮できているかを確認します。システム変更や新たな脅威に合わせ、監視対象と検知ルールを更新する仕組みまで含めてSOCを設計します。
24時間365日のセキュリティ監視を支えるG‑MDR®
SOCに必要な機能をすべて自社で抱える必要はありません。BBSecの「G-MDR®」は、OpenXDRと専門SOCを組み合わせ、対応可能な複数のセキュリティ製品やサービスから得られる情報を相関分析し、24時間365日体制で監視・検知・分析から初動対応までを支援します。導入時には監視対象やログ収集方法、役割分担を整理し、運用開始後は脅威の分析・通知や初動封じ込めを支援します。既存のEDRに加え、認証基盤やネットワーク、SaaSなどへ監視範囲を広げる構成も検討できます。具体的な連携製品や対応範囲は、導入環境や契約内容によって異なります。
セキュリティ監視・初動対応の強化をご検討の企業様へ
EDRなどのセキュリティ製品を導入していても、アラートの分析や夜間・休日の対応に課題はありませんか？
G-MDR®について詳しく見る
※外部サイトへリンクします。
まとめ
SOCとは、セキュリティイベントを継続的に監視・分析し、必要な対応へつなげる機能・組織です。SIEMやEDRを導入するだけではSOCにはならず、監視対象、分析基準、連絡経路、対応権限、継続改善を含む運用設計が必要です。SOCとCSIRTの境界は組織によって異なりますが、一般にはSOCが検知・分析の前線、CSIRTが組織横断の対応と調整を担います。内製、外部委託、ハイブリッドのいずれを選ぶ場合も、最終的な事業判断まで外部へ丸投げせず、自社と事業者の役割を明確にすることが、実効性のあるセキュリティ監視につながります。
SOCに関するよくある質問
▼ SOCは必ず24時間365日で運用する必要がありますか【参考情報】
- 米国立標準技術研究所（NIST）「Security Operations Center – Glossary」
https://csrc.nist.gov/glossary/term/security_operations_center - 米国立標準技術研究所（NIST）「NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile」https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf
- National Cyber Security Centre（NCSC）「Building a Security Operations Centre (SOC) – Detection practices」https://www.ncsc.gov.uk/collection/building-a-security-operations-centre/detection/detection-practices
- 独立行政法人情報処理推進機構（IPA）「指示5 サイバーセキュリティリスクに効果的に対応する仕組みの構築」https://www.ipa.go.jp/security/economics/practices_navi/practice213.html
- 独立行政法人情報処理推進機構（IPA）「プラクティス5-2 サイバーセキュリティ対策において委託すべき範囲の明確化とその管理」https://www.ipa.go.jp/security/economics/practices_navi/practice215.html
- 独立行政法人情報処理推進機構（IPA）「プラクティス7-6 インシデント発生時の優先度に応じた顧客への通知・連絡・公表手順」https://www.ipa.go.jp/security/economics/practices_navi/practice232.html
- Canadian Centre for Cyber Security「Choosing the best cyber security solution for your organization – ITSM.10.023」https://www.cyber.gc.ca/en/guidance/choosing-best-cyber-security-solution-your-organization-itsm10023
編集責任：木下
ウェビナー開催のお知らせ
最新情報はこちら
