SOC 構築の進め方　脅威・重要資産・ログ・検知・役割を7ステップで設計

SOCを構築する際は、SIEMやEDRの製品選定から始めるのではなく、「何を守るか」「どの攻撃を検知するか」「どのログで判断するか」「誰が対応するか」を先に決めます。

英国National Cyber Security Centre（NCSC）は、SOCのOperating Modelを設計する最初の作業として、組織が直面する脅威と監視すべき資産を把握することを挙げています。SOCの能力は、想定する攻撃者の能力、重要資産、利用できる人員・予算に比例させる考え方です。

SOC構築を実務へ落とすと、次の7ステップに整理できます。

ステップ	決めること	主な成果物
1	SOCの目的と対象範囲	スコープ、対象システム
2	脅威と重要資産	脅威プロファイル、優先資産
3	検知ユースケース	検知したい攻撃シナリオ
4	必要ログ	ログ一覧、保存要件
5	運用モデル	監視、調査、エスカレーションの役割
6	技術・外部サービス	SIEM、EDR、MDRなどの要件
7	テストと改善	KPI、Runbook、改善計画

SOCの目的と対象範囲を決める

最初に「SOCを作る目的」を具体化します。

「セキュリティを強化する」「24時間監視する」だけでは、必要な機能を決められません。

たとえば目的は次のように分けられます。

• ランサムウェアの早期検知
• 特権アカウント侵害の検知
• クラウド管理操作の監視
• 顧客情報への不正アクセス検知
• 海外拠点を含む一元監視
• EDRアラートの一次分析
• インシデント発生時の調査時間短縮

目的を決めたら、SOCが監視するシステムと、監視対象外にする領域を定義します。

NCSCは、SOCがIT環境全体を同じ深度で監視することは難しいため、重要資産とその事業上の文脈を理解して優先順位を付けるよう案内しています。

脅威と重要資産を整理する

SOC構築では、資産台帳を作るだけでは不十分です。

同じサーバーでも、侵害時に顧客情報へ到達できるものと、検証環境だけで使うものでは優先度が異なります。

最初に次を整理します。

重要資産

• 認証基盤
• 特権アカウント
• 顧客情報を保存するシステム
• 基幹システム
• クラウド管理アカウント
• バックアップ基盤
• インターネット公開システム
• ソースコード・CI/CD
• 事業停止につながるOT・製造環境

想定する脅威

• 認証情報窃取
• フィッシング
• 公開システムの脆弱性悪用
• ランサムウェア
• クラウドアカウント侵害
• 委託先アカウントの悪用
• 内部不正
• サプライチェーン経由の侵害

NCSCはThreat ProfileをSOC設計の起点とし、想定する攻撃者の能力によって必要な検知能力が変わると説明しています。

国家支援型の攻撃者まで想定する組織と、一般的な認証攻撃やランサムウェアを主な脅威とする企業では、必要な人材、ログ、脅威ハンティングの深度が同じとは限りません。

攻撃シナリオから検知ユースケースを作る

SOCの監視項目は、製品が標準で出すアラート一覧から決める方法より、想定する攻撃から逆算する方が整理しやすくなります。

NCSCはThreat Modellingを使い、Risk、Attack、Log Source、Detectionをつなげる方法を示しています。

たとえば「管理者アカウントの乗っ取り」を想定する場合は、次のように分解できます。

項目	例
リスク	ID基盤の管理権限を奪われる
攻撃	パスワード窃取、MFA変更、特権付与
必要ログ	認証、MFA、権限変更、管理操作
検知	通常と異なる場所からの特権ログイン、MFA再登録後の管理操作
初動	セッション失効、アカウント停止、関連端末調査

同様に、ランサムウェア、クラウド侵害、Webサーバー侵害など、自社で優先度が高いシナリオを複数作ります。

検知ユースケースには、最低限次を記録します。

• 検知したい攻撃
• 対象資産
• 必要なログ
• アラート条件
• 調査手順
• 誤検知になりやすい業務
• エスカレーション条件
• 推奨初動

必要なログと保存要件を決める

検知ユースケースが決まったら、必要なログを接続します。

NCSCは、SOCの主要なログソースをApplication、Host、Network、Cloudに分類し、認証、セキュリティコントロール、DNSを「must-have」の例として挙げています。

CISAも、ユーザー活動、管理者操作、ネットワーク通信、アプリケーションログイン、システムイベントなどを記録し、ログを中央管理する方法を案内しています。

ログ設計では、取得可否だけでなく次を確認します。

• 監視したいイベントが記録されるか
• 利用者・端末・IPを識別できるか
• 時刻が統一されているか
• 調査に必要な期間を保存できるか
• 監査ログを攻撃者が容易に削除できないか
• SIEMや分析基盤へ遅延なく送れるか
• 保存コストが許容範囲か

ログを大量に保存していても、攻撃経路を追えなければ調査には使えません。

逆に、目的を決めずにすべてのログを集めると、SIEM費用や検索負荷だけが増える場合があります。

監視・調査・対応の運用モデルを作る

ログと検知があっても、誰が処理するか決まっていなければSOCは動きません。

NCSCはTarget Operating Model（TOM）で、SOCの各機能について依存関係、入力、プロセス、出力を整理する考え方を示しています。

企業側では、少なくとも次の責任分界を決めます。

業務	担当を決める
アラート監視	誰が最初に見るか
トリアージ	誤検知と要調査を誰が分けるか
追加調査	誰が複数ログを横断して調べるか
インシデント認定	誰がCSIRT起動を判断するか
端末隔離	誰が実行・承認するか
アカウント停止	誰が実行・承認するか
事業影響判断	誰が業務部門と調整するか
夜間連絡	どの重大度で誰へ電話するか
検知改善	誰がルールを更新するか

24時間365日監視を採用する場合は、「夜間にアラートを受ける」だけでなく、調査と初動までの所要時間を設計します。

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

運用要件を決めてからSIEM・EDR・MDRを選ぶ

製品・サービスの選定は、SOCのスコープと運用モデルを決めた後に行います。

必要になる技術はSOCごとに異なります。

技術・サービス	主な用途
SIEM	ログ集約、検索、相関分析、アラート
EDR	端末の検知、調査、隔離
NDR	ネットワーク上の異常検知
SOAR	調査・対応処理の自動化
Threat Intelligence	IOC、TTP、攻撃者情報の活用
MDR	外部事業者による監視・調査・対応支援
Ticket／Case Management	調査記録、担当、エスカレーション管理

製品比較では機能表だけでなく、「自社の検知ユースケースを実装できるか」で確認します。

たとえば、MDRを利用する場合は次を見ます。

• どのログ・製品まで監視対象か
• 24時間の監視だけか、調査も含むか
• 調査結果に根拠ログが付くか
• 端末隔離などを代行できるか
• 自社CSIRTへの連絡条件
• チューニングの責任範囲
• データ保存場所と保存期間

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

本番前にテストし、運用指標を決める

SOCは、ログ接続が完了した時点では完成していません。

本番前に、想定した攻撃シナリオを検知し、担当者が決めた手順で調査・連絡できるかを確認します。

テスト項目の例は次のとおりです。

• 検知ルールが想定どおり発火するか
• 必要なログをすぐ検索できるか
• 担当者がRunbookを使って調査できるか
• 夜間連絡先へ到達できるか
• 重大事象をCSIRTへ引き継げるか
• 端末隔離・アカウント停止を実施できるか
• 調査記録を残せるか

運用開始後は、アラート件数だけでなく、次のような指標を確認します。

• 未処理アラート数
• 重大アラートの確認までの時間
• エスカレーションまでの時間
• 誤検知率
• 検知ユースケースのカバレッジ
• ログ欠損
• インシデントで見逃した挙動
• Runbookどおり処理できなかった事象

指標の目的は担当者を評価することではなく、監視設計の詰まりを見つけることです。

SOC構築で起きやすい設計上の問題

SOC構築では、次の状態を避けます。

SIEM導入をSOC構築の完了とする

ログ基盤ができても、検知、トリアージ、調査、エスカレーションが決まっていなければ運用は成立しません。

すべてのログを最初から集める

保存コストとアラート量が増え、重要な検知を埋もれさせる場合があります。攻撃シナリオから優先ログを決め、段階的に広げます。

24時間監視だけを契約する

外部SOCが夜間にアラートを検知しても、社内の担当者が応答できなければ封じ込めは遅れます。

SOCとCSIRTの境界を決めない

SOCは「通知した」、CSIRTは「十分な情報がない」という状態になると、重大事象の判断が止まります。引き渡し条件と必要情報を定義します。

重要資産の情報をSOCへ渡さない

同じアラートでも、対象が検証端末か認証基盤かで優先度は変わります。資産の業務上の重要度を監視側へ共有します。

SOC構築前のチェックリスト

構築計画を作る際は、次を確認できます。

• SOCの目的を一文で説明できる
• 優先して守る資産を決めている
• 想定する攻撃シナリオを複数定義している
• 攻撃シナリオごとに必要なログを特定している
• ログの保存期間と時刻同期を確認している
• アラート監視、トリアージ、追加調査の担当が決まっている
• CSIRTへ引き継ぐ条件を決めている
• 端末隔離やアカウント停止の権限者が決まっている
• 夜間・休日の連絡先が決まっている
• 外部SOC・MDRの契約範囲を責任分界で確認している
• 本番前に検知とエスカレーションをテストする
• インシデントの結果を検知改善へ戻す手順がある

より詳細な役割分担、成熟度、自己点検項目は、SOC構築・運用ガイド -24時間365日の監視・分析体制をどう作るか-で整理しています。

出典

• Building a Security Operations Centre (SOC) – UK National Cyber Security Centre
• Things to consider – UK National Cyber Security Centre
• Designing an Operating Model – UK National Cyber Security Centre
• The target operating model – UK National Cyber Security Centre
• Threat modelling – 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
• Cyber Defense Methodology for an Organization – Israel National Cyber Directorate