セキュリティ情報漏洩のニュースサイトセキュリティ対策Labの運営とBtoB マーケティングコンサル支援|合同会社ロケットボーイズ

CSIRTとSOCの違いは、組織名ではなく「どの業務を中心に担うか」で整理すると分かりやすくなります。 SOC（Security Operations Center）は、ログやアラートを継続的に監視し、サイバー攻撃や侵害の兆候を検知・分析する機能を中心に担います。 CSIRT（Computer Security Incident Response Team）は、インシデントを認知した後の調査、封じ込め、復旧、再発防止、社内外との調整などを進める機能を中心に担います。 ただし、両者の境界は固定ではありません。 JPCERT/CCの「CSIRTガイド」は、CSIRTのインシデント対応について、インシデントの検知または報告受領、情報収集・分析、復旧、再発防止までを一連の活動として説明しています。英国National Cyber Security Centre（NCSC）も、MonitoringとIncident Managementが同じ人員で構成される場合があるとしています。 そのため、「SOCは検知だけ」「CSIRTは対応だけ」と完全に切り分けるのではなく、監視から対応、復旧、改善までの責任分界を決めることが実務上のポイントです。 CSIRTとSOCの違い 項目 SOC CSIRT 主な目的 攻撃・侵害の兆候を検知し、分析する インシデントによる被害を抑え、復旧まで進める 平常時の中心業務 ログ監視、アラート分析、トリアージ、検知改善、Threat Hunting 対応手順整備、連絡体制、演習、外部連携、対応能力の維持 インシデント時 追加調査、影響範囲の確認、技術情報提供、初動対応 対応統括、封じ込め、復旧、証拠保全、社内外調整 主に扱う情報 ログ、アラート、通信、IOC、TTP、資産情報 SOC分析結果、事業影響、顧客影響、法務・規制・広報上の情報 主な関係者 SOCアナリスト、セキュリティエンジニア、情シス IT、セキュリティ、経営、法務、広報、人事、事業部門など 稼働 継続監視が中心 平時も準備活動を行い、インシデント時に活動が拡大 外部委託 監視・一次分析を委託しやすい 技術支援は委託可能。事業判断や社内調整は自社に残る 両者の接点 インシデント候補を分析し、必要な情報を引き渡す 引き継いだ事象を組織として対応する この表は典型的な役割分担です。 SOCが端末隔離やアカウント停止まで実施する企業もあれば、CSIRTがフォレンジックやログ分析、Threat Huntingを担当する企業もあります。 NCSCはSOCについて「one-size-fits-all」のモデルはないとし、組織が直面する脅威、守る資産、利用可能なリソースに応じて設計するよう案内しています。 関連記事：SOCとは？役割・業務内容、SIEM・EDR・CSIRTとの違いを解説 SOCは監視・検知・トリアージを中心に担当する NCSCはSOCの目的について、予防策をすり抜けたサイバー攻撃を検知し、対応することで組織への被害を抑えることと説明しています。 代表的な業務は次のとおりです。 ログ収集 アラート監視 一次トリアージ 関連ログを使った追加調査 検知ルール開発 脅威インテリジェンスの活用 Threat Hunting インシデント候補のエスカレーション 検知ルールやRunbookの改善 SOCの仕事は「アラートを見る」だけではありません。 アラートが誤検知なのか、攻撃の兆候なのか、すでに侵害が成立しているのかを確認し、次の判断に必要な技術情報をそろえます。 NCSCのCyber Assessment Framework（CAF）v4.0では、Monitoring and Detectionの担当者について、ログやアラートを分析・調査する能力だけでなく、監視対象システムの運用上の文脈を理解することも求めています。 CSIRTはインシデント対応を組織横断で進める JPCERT/CCはCSIRTを「コンピューターセキュリティインシデントに対応するチーム」と説明しています。 CSIRTはインシデント対応を組織横断で進める 同ガイドでは、CSIRTによるインシデント対応を次の一連の活動として整理しています。 インシデントを検知する、または報告を受けて発生を認知する 影響の拡大を防ぐ 情報を収集・分析し、全体像や原因を把握する 復旧措置を行う 再発防止策を検討・実施する CSIRTは単なる技術対応チームではありません。 NCSCは、CSIRTの中核をIT・Cyber Security担当としつつ、インシデントの内容に応じて経営層、Incident Manager、Technical Lead、IT・インフラ、フォレンジック、事業継続、法務、広報、人事、顧客対応、外部IR事業者、政府・法執行機関などが参加するとしています。 顧客情報への不正アクセスが疑われる場合、技術調査だけでは対応は完了しません。システム停止、顧客通知、規制当局への報告、対外公表、サービス再開などの判断が発生します。 NIST SP 800-61 Rev.3で見るSOCとCSIRTの関係 NISTは2025年4月、インシデント対応ガイド「SP 800-61 Rev.3」を最終版として公開しました。 Rev.3は2012年のRev.2を置き換え、NIST Cybersecurity Framework（CSF）2.0に沿ってインシデント対応を整理しています。 NISTは、インシデント対応をDetect、Respond、Recoverだけの作業とはしていません。CSF 2.0の6機能すべてが関係するとしています。 NIST CSF 2.0 インシデント対応との関係 Govern 方針、役割、権限、リスク管理 Identify 資産・リスク・依存関係の把握 Protect 予防策と被害軽減 Detect 攻撃・侵害の兆候を発見し分析 Respond インシデントを管理し、優先順位付け・封じ込め等を実施 Recover 影響を受けた資産・業務を復旧 SOCは主にDetectに深く関わり、CSIRTはRespondとRecoverの調整に深く関わるとなります。 ただし、NISTが「SOC＝Detect」「CSIRT＝Respond」と組織名を一対一で定義しているわけではありません。 NCSC CAF v4.0では監視とIncident Managementの連携を明示 NCSCのCAF v4.0は2025年8月に公開されています。 CAFのSecurity Monitoringでは、監視・検知機能について、何を監視するか、誰が分析・調査するか、どの事象をエスカレーションするか、誰へ何の情報を渡すかを明確にする考え方が示されています。 さらにNCSCは、Monitoring capabilityがIncident Managementとシームレスに連携すべきだとし、両機能が同じ人員で構成される場合もあると明記しています。 公的ガイドが求めているのは「SOC部署」と「CSIRT部署」を必ず二つ作ることではありません。検知から対応までを切れ目なく動かせることです。 FIRSTのCSIRT Services FrameworkではCSIRTの業務範囲を固定していない FIRSTは「CSIRT Services Framework v2.1」を公開しています。 同フレームワークはCSIRTが提供し得るサービスと機能を体系化したもので、すべてのCSIRTが掲載された全サービスを提供する必要はないとしています。 2026年5月には「Metrics for the CSIRT Services Framework v1.1」も公開され、CSIRTサービスを定量・定性指標で評価し改善する考え方が示されました。 CSIRTを設置した後は、チーム名や人数だけではなく、インシデント認知までの時間、対応開始までの時間、エスカレーション品質、対応記録の完全性、復旧や改善の実施状況など、自社のサービス内容に合った指標を設定できます。 アラートとインシデントは同じではない SOCが受け取るアラートのすべてがインシデントになるわけではありません。 NCSCもSOCガイドで「Not every alert will be an incident」と説明し、トリアージを求めています。 SOCでは次を確認します。 誤検知ではないか 対象端末やアカウントは何か 対象資産の重要度は高いか 攻撃が成功した証拠はあるか 他の端末・アカウントへ広がっていないか 外部通信が発生していないか 認証情報へのアクセスがないか 自社のインシデント認定基準を満たすか 「インシデントと認定する権限」をSOCに置くか、CSIRT責任者に置くかは企業ごとに異なります。誰が認定するかを事前に決めます。 SOCからCSIRTへ何を渡すか SOCからCSIRTへ「Critical Alertが出ました」とだけ伝えても、CSIRTは対応方針を判断しにくくなります。 情報 内容 発生日時 最初のイベント、直近のイベント 対象 端末、アカウント、IP、システム 資産重要度 基幹、顧客情報、認証基盤、検証環境など 検知内容 何を根拠にアラートが発生したか 調査結果 SOCが確認した事実 関連ログ EDR、認証、DNS、Proxy、クラウドなど 影響 横展開、外部通信、情報アクセスの有無 未確認事項 まだ確認できていない点 実施済み措置 隔離、セッション失効など 推奨初動 次に取るべき技術措置 緊急度 いつまでに判断が必要か NCSCは、アラート設計について5W1Hを意識し、アナリストが迅速に内容を理解してトリアージ・エスカレーションできる情報を含めるよう推奨しています。 関連記事：EDR・SIEMを導入してもSOC運用は完成しない 24時間365日の監視を機能させる役割分担とは CSIRTからSOCへ戻す情報 連携はSOCからCSIRTへの一方向ではありません。 インシデント対応後は、次の情報をSOCへ戻します。 実際の侵入経路 悪用されたアカウント IOC 攻撃者のTTP 有効だったログ 欠けていたログ 見逃していた挙動 誤検知だった条件 追加すべき監視対象 再発防止策 NIST SP 800-61 Rev.3は、インシデント対応で得た知見をGovern、Identify、Protectなどへ戻し、継続的に改善する考え方を採っています。 NCSC CAFも、インシデントや演習のLessons LearnedをSecurity MonitoringやInvestigation、Containment、Governanceへ反映するよう案内しています。 SOCとCSIRTはどちらが上なのか SOCとCSIRTに一般的な上下関係はありません。 企業では次のような構成が考えられます。 SOCとCSIRTを別部署にする CSIRTの中にSOC機能を置く SOC組織の中にIncident Response機能を置く 情報システム部門がSOCとCSIRTの機能を兼務する SOCを外部委託し、CSIRT機能を社内に置く MDRへ監視・調査・一部初動を委託し、社内CSIRTが意思決定する 組織図よりも、監視、分析、インシデント認定、封じ込め、復旧、公表などの担当と権限を決める方が先です。 SOCだけあればCSIRTは不要か SOCの分析能力が高くても、企業としての意思決定は残ります。 たとえばランサムウェアが重要サーバーで確認された場合、ネットワーク遮断、基幹システム停止、復旧、顧客・取引先への連絡、規制当局への報告、公表などの判断が発生します。 外部SOCやMDRが技術的な推奨を出しても、事業停止や対外公表の最終判断は企業側に残ります。 NCSCも、インシデント対応を外部委託する場合でも、社内に事業への影響を判断し、外部専門家の助言を受けて意思決定する人員を置くよう案内しています。 CSIRTだけあればSOCは不要か CSIRTが存在していても、攻撃を発見できなければ対応開始は遅れます。 専任SOCを設置しない場合でも、EDRやクラウドのアラート監視、認証ログの異常検知、メール・Web・DNSの監視、利用者からの通報、委託先や外部機関からの通知、脅威情報との照合、必要に応じたThreat HuntingといったDetect機能は必要です。 監視を外部SOCやMDRへ委託する場合も、どの条件で社内へ連絡するか、夜間に誰が受けるか、誰が隔離やアカウント停止を承認するかを契約と社内手順の両方で決めます。 関連記事：MDRとEDRの違いとそれぞれの特徴を解説 SOCとCSIRTは24時間365日必要なのか SOCもCSIRTも、名称だけで24時間365日が必須になるわけではありません。 NCSCはSOCの規模・能力を脅威、資産、利用可能なリソースに応じて設計するよう案内しています。CSIRTについても、必要な対応時間は事業特性とリスク許容度によって決めるとしています。 確認すべきなのは次の4点です。 重大アラートを何分・何時間以内に確認するか 誰がトリアージするか 誰が夜間・休日の初動を実行するか どの重大度でCSIRT・経営へエスカレーションするか SOCが24時間監視していても、深夜の端末隔離やアカウント停止を実行できる担当者がいなければ、検知から対応までに空白が生じます。 SOCとCSIRTの役割分担チェック表 業務 SOC CSIRT 情シス 経営・法務・広報等 アラート監視 トリアージ 追加調査 インシデント認定 端末隔離 アカウント停止 証拠保全 事業影響判断 顧客通知 規制当局対応 対外公表 復旧判断 検知改善 空欄が残る業務は、実際のインシデントで判断や対応が止まる可能性があります。 担当者だけでなく、承認者、代替要員、夜間・休日の連絡方法まで決めておきます。 より詳細な役割分担、24時間365日の監視、内製SOC・外部SOC・MDR・AI活用の違いは、SOC構築・運用ガイド -24時間365日の監視・分析体制をどう作るか-で整理しています。 情報システム部門が確認したいポイント 重大アラートを継続的に確認できるか 誤検知とインシデント候補を切り分けられるか 複数ログを横断して影響範囲を調査できるか インシデント認定者が決まっているか SOCからCSIRTへの引き継ぎ条件が文書化されているか 夜間・休日の緊急連絡先があるか 端末隔離やアカウント停止を実行・承認する人が決まっているか 事業停止やサービス再開を判断する責任者が決まっているか 法務・広報・経営への連絡基準があるか 外部SOC・MDRへ委託している範囲と社内に残る責任を説明できるか インシデント後にSOCの検知ルールやログ設計を更新しているか CSIRTの活動を時間・品質・改善状況などで評価しているか SOCとCSIRTは、別々の組織として完成させる必要はありません。 監視・検知・分析から、インシデント認定、封じ込め、復旧、対外対応、検知改善までを一つの流れとして設計し、各工程の担当者と権限を決めることが実務上のゴールです。 出典 NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management - NIST NIST Revises SP 800-61: Incident Response Recommendations and Considerations for Cybersecurity Risk Management - NIST Building a Security Operations Centre (SOC) - UK National Cyber Security Centre Incidents (Incident Management) - UK National Cyber Security Centre Build: A cyber security incident response team (CSIRT) - UK National Cyber Security Centre CAF Objective C: Security monitoring - UK National Cyber Security Centre CAF Objective D: Minimising the impact of cyber security incidents - UK National Cyber Security Centre CSIRTマテリアル - JPCERT/CC CSIRTガイド - JPCERT/CC CSIRT Services Framework Version 2.1 - FIRST Metrics for the Computer Security Incident Response Team (CSIRT) Services Framework Version 1.1 - FIRST

ブログ