EDRやSIEMを導入したものの、発報したアラートを誰が確認するのか、夜間や休日に検知された事象を誰が判断するのかが決まっていない。「SOCを入れる」と言うとき、その言葉が指している範囲が社内で揃っていない。こうした状態は、製品の不足ではなく運用モデルの未設計から生じています。
UK NCSCは、SOCの能力は組織が直面する脅威と守るべき資産に見合うべきだとし、脅威プロファイルの定義を最初の作業に挙げています。守る対象を決め、想定する攻撃を定義し、誰がいつ対応するかを決めたうえで、EDR・SIEM・SOARといった技術要件を確定する。製品選定は、運用モデルが決まったあとに来ます。
本資料では、SOCの仕事を脅威情報収集、ログ収集、検知ルール開発、アラート監視、トリアージ、追加調査、初動対応、Incident対応、運用改善の9つに分解しました。そのうえで、それぞれをSOC・情シス・CSIRT・経営のどこが担うのかを一覧表に整理しています。技術的に異常かどうかの判定と、事業としてインシデントと認定するかどうかの判断は、別の役割です。
24時間365日についても、「監視できる」ことと「対応できる」ことは別として扱っています。夜23時にCritical Alertが発生した場合を時系列で追い、SOCが検知して調査を始めたあと、誰が端末を隔離し、誰がアカウントを停止し、誰が業務への影響を判断するのかを可視化しました。運用時間の設計で決めるべき4項目も併せて整理しています。
運用モデルの比較は、サービス名ではなく責任分界で行いました。自社SOC、外部SOC・MSSP、MDR、AI SOC＋社内担当のそれぞれについて、誰が監視し、誰がトリアージし、誰が調査し、誰がインシデント判断をするのか、24時間365日をどう実現するのかを並べています。加えて、監視・分析・検知・運用・対応・連携・継続性の観点から12項目の自己点検チェックリストと、5段階の成熟度整理を収録しました。
終盤では、SOC業務を機械化・自動化しやすい領域と、組織固有の判断が要る領域に分けています。監視や一次調査の担い手は変えられますが、事業への影響判断やインシデント認定、封じ込めの最終判断は社内に残ります。EDRやSIEMは導入済みだが夜間休日の監視担当が決まっていない、アラートを処理しきれていないという情報システム部門・セキュリティ担当・CSIRTの方に向けたホワイトペーパーです。
資料編集・企画：合同会社ロケットボーイズ（セキュリティ対策Lab） 提供元：株式会社ヤグラ
資料概要（箇条書き・10項目）
- SOC構築で最初に決めるのは製品ではなく「何を守り、何を検知し、誰がいつ対応するか」
- UK NCSCが示す運用モデル設計の順序と、SOC運用モデルの4つの柱
- SOCの仕事を9つに分解した業務一覧と、担当を書き込める整理フォーマット
- アラート監視・トリアージ・インシデント認定・業務停止判断のSOC／情シス／CSIRT／経営の役割分担表
- NIST SP 800-61 Rev.3に基づく、Alertからトリアージ・調査・Incident判断・対応・復旧・改善までの流れ
- 自社SOC・外部SOC／MSSP・MDR・AI SOC＋社内担当を、責任分界の観点から比較した一覧
- 夜23時にCritical Alertが発生した場合の時系列と、運用時間の設計で決める4項目
- 脅威モデリングを起点に必要なログを逆算する考え方と、不正ログインを例にしたログ設計
- 監視・分析・検知・運用・対応・連携・継続性を確認する12項目の自己点検チェックリスト
- AIに任せる領域と社内に残す判断の切り分け、ヤグラAI SOCの位置付けと検討ステップ
このような方におすすめ
- EDRやSIEMを導入したものの、アラートを処理しきれていない情報システム部門
- 夜間・休日に発生したCritical Alertの確認担当が決まっていない企業
- SOCの内製・外部委託・AI活用のどれが自社に合うかを比較検討している企業
- 「SOCを入れる」という言葉が指す範囲を、社内で揃えたいセキュリティ担当者
- SOC・情シス・CSIRT・経営の役割分担を、業務単位で明文化したい企業
- インシデント認定者やエスカレーション先が決まっていないと感じているCSIRT
- MSSPやMDRの提案を受けており、責任分界の観点で評価したい企業
- 24時間365日の監視体制を、人員を増やさずに検討したい情報システム部門
- 検知ルールやRunbookの見直しが定例化していない運用担当者
- 従業員500〜3,000名規模で、セキュリティ運用の現状を棚卸ししたい組織