soc-operations

SOC 運用 — セキュリティオペレーションセンターの構築と運営

siem-detection（エンジニアリングルール）と incident-triage（対応）の上位に位置する運用レイヤーです。このスキルでは、24 時間 365 日のアラートトリアージを運営するための人員とプロセスを扱います。アラートの優先順位付け、ランブックの作成、エスカレーション、オンコール体制の健全性、MTTD／MTTR、そして SOC を機能不全に追い込むアラート疲れの徐々な進行を扱います。

3 つのモードがあります。

• 構築 — SOC をゼロから設計します（初めてインシデント対応能力を整備する小規模組織、または MSSP の導入）
• 運用 — 既存の SOC の日常業務を運営します
• 改善 — 既存の SOC のメトリクスを分析し、問題のある部分を修正します

相互参照：siem-detection（SOC にアラートを送るルール）、incident-triage（インシデントが確認された場合のプレイブック）、threat-hunting（アラートトリアージの合間に行うプロアクティブな活動）、breach-patterns（SOC が備えるべき攻撃）、log-watch（小規模チーム向けの SIEM も SOC もない状態からの出発点。このスキルは、そこから次の段階へ進むためのものです）。

認可

ユーザー自身の組織、またはユーザーと契約したクライアントのセキュリティオペレーションを設計・改善します。ランブックと監視設計の対象は、組織が所有するシステムとアカウントです。従業員の監視については、人事、法務、現地の法律で認められる範囲内に限ります。エスカレーションやオンコール体制の変更は、SOC リーダーが承認するための提案です。

モード 1 — SOC を構築する

判断：社内運用、MSSP、ハイブリッドのどれにするか？

モデル	適している状況	落とし穴
完全な社内運用	成熟したセキュリティ組織、専任アナリスト 5 人以上、規制対象業界	8 人未満で 24 時間 365 日の体制を組むのは困難です。オンコールによる疲弊もあります
完全な外部委託（MSSP）	小規模組織、社内人員なしで規制要件を満たす必要がある場合	MSSP のコンテキストの乖離 — 自社のビジネスを把握していません。アラートのチューニングに時間がかかります
ハイブリッド（MSSP が Tier 1、社内が Tier 2 以降）	成長段階の企業で最も一般的	引き継ぎが複雑になり、「MSSP がフィルタリングしたのに、こちらに伝わらなかった」という抜け漏れが発生します

人員配置モデル

社内で 24 時間 365 日の体制を組む場合の計算は次のとおりです。

• 24 × 7 = 週あたり 168 時間のカバーが必要です
• アナリスト 1 人の勤務時間は週 40 時間（＝ 年 160 時間 × 50 週間 ≈ 年 8,000 時間 − 有給休暇 − 研修 ≈ 生産的な業務時間 1,700 時間）です
• 重複時間なしで真に 24 時間 365 日対応するには、最低 5 人が必要です。有給休暇や疲弊への対応を考慮すると、現実的な最低人数は 6～7 人です
• 6 人未満の場合 — 時間外のカバーには MSSP の利用を検討してください。「常時対応」による疲弊の代償は深刻です

アナリストの階層

標準的な階層モデルです（適宜調整してください）。

• Tier 1 — トリアージ： 初期アラートレビューを担当します。根拠を記録して誤検知をクローズし、実際の調査結果を Tier 2 にエスカレーションします。通常はランブックに従い、手順から外れる場合は記録を残します。
• Tier 2 — 調査： エスカレーションされた案件を詳しく分析します。複数のデータソースを横断して調査し、イベントを関連付け、「インシデント」か「ノイズ」かを判断します。Tier 1 が次回から対応できるよう、パターンに応じた新しいランブックを作成します。
• Tier 3 — エンジニアリングと対応： 検知エンジニアリング（siem-detection を参照）、脅威ハンティング（threat-hunting を参照）、インシデント対応の指揮（incident-triage を参照）を担当します。経験豊富でコストも高く、SOC の能力を構築する人員です。

小規模な SOC（アナリスト 4 人以下）では、階層は統合されます。すべてのアナリストが Tier 1 と Tier 2 の業務を担い、Tier 3 は兼任または外部委託です。実際に階層がないなら、あるように見せかけないでください。

実際に必要なツール

• ログ集約とアラート用の SIEM（siem-detection を参照）
• ケース管理 — ServiceNow／Jira Security／TheHive／Tines ワークフロー。Slack スレッドではなくチケットを使います。Slack は日常的なやり取りの場です。監査証跡はチケットに残します
• プレイブック自動化用の SOAR — Tines、Torq、Cortex XSOAR、Splunk SOAR。自動化する価値のある安定したランブックが整ってから導入してください
• トリアージ中にアナリストが調査先として利用できる EDR／NDR コンソール
• アナリストが参照できる 資産インベントリ — Snipe-IT、ServiceNow CMDB、Axonius
• ドキュメント — ランブックを保管する Wiki（Notion／Confluence／GitBook）。Slack の DM ではありません

モード 2 — SOC を運用する

アラートの優先順位付け

5 分間に 10 件のアラートが届いた場合、どの順番で対応しますか？

デフォルトのランキング（環境に合わせて調整してください）：

1. Critical — 侵害が確認された兆候（既知の不正なハッシュ、C2 コールバック、ランサムウェアの挙動、既知の不正なインフラへのデータ流出）
2. High — 認証情報へのアクセスパターン（LSASS ダンプ、チケットの偽造）、特権アカウントの異常な挙動、セキュリティ制御の無効化（EDR の削除、監査ログの停止）
3. Medium — 永続化の兆候（新しいスケジュール済みタスク、レジストリの Run キー）、サービスアカウントによる探索コマンド、MFA 失敗の急増
4. Low — 単発イベントの異常、コンテキストのない行動の逸脱
5. Informational — 後で相関分析するためのコンテキストが豊富なイベント。単独では対応不要です

Critical と High は、決して後回しにしてはいけません。Medium はシフト内（≤ 8 時間）にトリアージします。Low と Info はまとめて処理します。

ランブックの作成

2～3 回を超えて発生するアラートには、すべてランブックが必要です。ランブックがないと、アナリストが毎回対応方法を一から考えることになり、対応品質にばらつきが生じます。

ランブックの構成：

# Runbook: [Alert name]
## Trigger: [exact SIEM rule / detection name]
## Owner: [team / person]
## Last reviewed: [date]

## Quick reference
- **What the alert means in plain English:** [one sentence]
- **Common false positives:** [list, with how to recognize]
- **Common true positives:** [list, with what to look for next]

## Triage steps
1. [Step 1 — specific query / action]
2. [Step 2]
3. [Decision point — true positive / false positive / escalate]

## False positive handling
- [How to close + what to document]
- [Whether to add to suppression list]

## True positive handling
- [Immediate containment if any]
- [Escalation to whom, with what info]
- [Link to incident-triage skill for full IR]

## Common pivots
- [Other data sources to check]
- [Other systems likely affected]

ランブックは、バージョン管理システムまたはバージョン管理された Wiki に保管してください。Slack の DM や個々のアナリストのメモには保管しないでください。

エスカレーション基準

エスカレーションのルールは、「判断に任せる」のではなく、明確に定める必要があります。判断が求められるのは Tier 3 以上です。下位の Tier にはルールが必要です。

条件	エスカレーション先	期限
データ流出が進行中であることを確認	Tier 2 / オンコール担当	直ちに
特権アカウントの挙動に異常	Tier 2	このシフト内
1 台のホストで複数の相関するアラートが発生	Tier 2	このシフト内
検知ルールが 1 時間あたり 50 回超発火し、TP 率が高い	Tier 3（エンジニアリング）	翌営業日
検知ルールが 1 時間あたり 50 回超発火し、FP 率が 100%	Tier 3（エンジニアリング）	翌営業日
Tier 1 が対応方法を把握していない事象	Tier 2	30 分間トリアージした後

シフトの引き継ぎ

侵害の検知が数日遅れる原因として最も防止しやすいのは、「夜勤の担当者が気になる事象を見つけたのに、朝の担当者に共有されなかった」ことです。

引き継ぎチェックリスト（シフトごとに 5～10 分）：

• 未完了のケース — 進行中の内容、行き詰まっている内容、次のステップ
• 要注意事項 — まだケースにはなっていないものの、注視する価値のある事項
• 進行中のチューニング — チューニング中のルール、調査中の FP パターン
• シフト中に受信したページ — 解決済みであっても、次のシフトに共有する
• 対応しないと判断した事項とその理由 — 次のシフトの担当者が、背景を知らずに黙って異なる判断をしないようにする

記録に残してください。Slack の引き継ぎチャンネル、日次サマリーのドキュメント、チケット管理システムのシフトレポートなど、永続的に保存され、検索できる形式であれば何でもかまいません。

モード 3 — SOC を改善する

本当に重要な KPI

指標	定義	目標
MTTD	平均検知時間 — イベント発生からアラート発火まで	信頼度の高いルールでは 5 分未満、振る舞い検知では 1 時間未満
MTTR	平均対応時間 — アラート発生からトリアージの判断まで	Tier 1：Critical は 15 分未満、Medium は 4 時間未満
MTTC	平均封じ込め時間 — インシデント確認から拡散の阻止まで	侵害が確認された場合は 1 時間未満（業界の P50 は約 6 日です。さらに短縮を目指してください）
ルールごとの TP 率	真陽性数 / アラート総数	すべてのルールで 30% 超。これを下回るルールはチューニングするか無効化します
アナリスト 1 人あたりのシフトごとのアラート量	Tier 1 アナリスト 1 人が 8 時間のシフト中に受け取るアラート数	25 件未満 — これを超えると疲労が大きく影響します
ATT&CK 戦術ごとのカバレッジ	検知ルールが 1 つ以上ある戦術	Initial Access、Execution、Persistence、Defense Evasion、Credential Access を 100% カバーすることを目指します
ランブックのカバレッジ	ランブックが用意されているアラートの割合	アラート量の 80% 超
ランブック作成までの時間	新しいアラートタイプの発生からランブックの提供まで	そのタイプのアラートが 5 件発生する前

行動に移せないものは測定しないでください。「処理したアラート数」は見栄えだけの指標です。ノイズの多いルールほど数値が増えるためです。

チューニングのサイクル

SOCで最もよくある障害は、ルールが未チューニングであることによるアラート疲れです。それを防ぐサイクルは次のとおりです。

1. 毎週： アラート件数の多い上位 N 件のルールを確認します
2. アラート件数の多い各ルールについて： TP 率はどれくらいですか？ 30％未満なら、そのルールは機能していません。チューニングするか廃止してください
3. 廃止するか、チューニングするか： ルールの基礎となる考え方が妥当なら、チューニングします（フィルターの追加、しきい値の引き上げ、許可リストの追加）。考え方が妥当でない場合（環境内では通常の異常な振る舞いなど）は、廃止します
4. 廃止するルールはすべて記録します。後任のエンジニアが、なぜルールがなくなったのかを知りたくなるためです
5. チューニングのサイクルを追跡します。「ルール X は 6 か月で 3 回チューニングされた」という場合、問題はパラメーターではなくルールの考え方にあります

エンジニアリング面については siem-detection のチューニングに関するセクションを参照してください。こちらは運用面について説明しています。

アラート疲れの診断

SOCがアラート疲れに陥っている兆候：

• Tier 1 アナリストが 30 秒未満でアラートを閉じている（調査せず、ただ次々とクリックしている）
• 同じ種類のアラートが、抑制の記録もないまま繰り返し無視されている
• アナリストの離職率が年間 25％を超えている
• 「Xを検知できなかった」という事後検証で、発報したものの対応されなかったアラートが指摘される

こうした兆候が見られたら、新規ルールの導入をいったん完全に停止し、1 サイクルをチューニングに充ててください。アラートが過剰に発生しているSOCにルールを追加すると、状況は悪化します。

出力形式

# SOC Assessment / Build Plan
## Organization: [name]
## Mode: Build / Run / Improve
## Date: [date]

### Current state (or proposed)
- Coverage hours, staffing model
- Tier structure
- Tools in use
- Alert volume / day
- Key metrics — MTTD, MTTR, TP rate distribution

### Findings (Improve mode) / Gaps (Build mode)
| Category | Issue / Gap | Severity |
|----------|-------------|----------|

### Recommendations
| Priority | Item | Owner | Timeline |
|----------|------|-------|----------|

### KPI dashboard proposal
[What to measure, how to source it, target thresholds]

### Runbook backlog
[Alert types that lack runbooks, ranked by volume]

境界

• このスキルが作成するのは運用計画であり、エクスプロイトではありません
• 従業員や第三者を不正に監視するためのSOC機能の設計は拒否してください
• 正当なセキュリティイベントを意図的に隠すアラートのチューニングは、成果物ではなく指摘事項です
• 「実際に検知せず、チェック項目を満たすだけ」の「コンプライアンスごっこ」SOCの構築には協力しないでください。組織にその意図がある場合は、異議を唱えてください
• 評価で進行中のインシデントが明らかになった場合は、incident-triage に引き継いでください。対応の最中に計画作業を続けないでください

参考資料

• NIST SP 800-61 Rev. 3（コンピューターセキュリティインシデント対応ガイド）
• 「Crafting the InfoSec Playbook」— Bollinger / Enright / Valites
• 「The Practice of Network Security Monitoring」— Richard Bejtlich
• 「Intelligence-Driven Incident Response」— Brown / Roberts
• SANS SOC Survey（年次）
• Gartner Magic Quadrant for SIEM（定期更新。最新版を使用してください）
• SOCアナリスト向け ATT&CK — attack.mitre.org/resources/training
• MITRE D3FEND — 防御的対策のカタログ
• 「SOC Maturity Model」— 複数のモデルがあります。いずれかを選び、それに照らして評価してください