はじめに
本書はAmazon/O'Reillyで出版された、SOC（Security Operations Center）の設計から運用、組織構造、人材育成、アウトソーシングに至るまでを網羅した実務書です。著者はSOC構築の現場で培った経験を体系化しており、抽象論ではなく「実際にどう作り、どう動かすか」に焦点を当てた内容になっています。
同じセキュリティインフラを抱えながらも「誰が見るか・どう対応するか」が曖昧なままになりがちな組織にとって、整理の指針になる一冊でした。以下、章ごとのポイントをまとめます。
第1章 効率的な運用 — SOCとは何か
SOCとはセキュリティイベントを監視・分析・対応する組織です。NOC（ネットワーク系）やEOC（緊急対応）といった他のオペレーションセンターと役割が似ていますが、SOCの最大の特徴はインテリジェンスの活用にあります。
SOCは以下の5フェーズで成熟していきます。
| フェーズ | 概要 |
|---|---|
| テクノロジー | セキュリティツールの棚卸しと責任範囲の把握 |
| 組織化 | セキュリティ機器の管理・維持プロセスの確立 |
| ポリシー | ITセキュリティポリシーの整備、内部標準の策定 |
| 運用 | 定常監視・インシデント対応の開始 |
| インテリジェンス | 外部情報の取り込みとプロアクティブな脅威検知 |
「インスタントSOC」（侵害後に慌てて作る組織）が多い現実を本書は率直に指摘しており、事前計画の重要性を強調しています。
重要な用語定義
用語の共通認識が組織横断でSOCを機能させる前提になります。
- ログ：システムが記録する最も基本的な情報
- イベント：特定コンテキストを持つログ、対応要否は問わない
- アラート：介入が必要と判断された重要イベント
- インシデント：セキュリティポリシー違反、または違反の差し迫った脅威（NIST定義）
アラートには偽陽性・真陽性・偽陰性・真陰性の4分類があり、チューニングによって精度を高めていくことがSOCの継続的な課題です。過剰チューニングは逆に見逃しを増やすため、脆弱性スキャナや侵入テストツールで定期的に検証することが推奨されます。
第2章 顧客を特定する — SOCのステークホルダー
SOCの顧客は「IT部門」だけではありません。本書は以下のような内部・外部顧客を列挙しています。
- 人事部門：Webアクセスポリシーの執行や内部調査のサポート
- 法務部門：eDiscovery、データ保護法対応、侵害時の通知義務
- 監査部門：証跡の提供、コンプライアンスレポートの生成
- R&D/エンジニアリング：製品セキュリティのコンサルティング
- IT部門：脆弱性情報の提供、インフラトラブルシューティング支援
IT部門をSOCの「敵」ではなく「顧客」として捉える視点は実践的です。1,000ページの脆弱性レポートを丸投げするより、「最も影響の大きい上位10件」を渡す方がIT部門に刺さる、という指摘は現場感があります。
ユースケースの文書化
本書が強調するのがユースケースの文書化です。SIEM上のルールを作るだけでなく、「なぜそのルールが必要か・誰がステークホルダーか・何が検出条件か」を記録することで、監査対応・新人教育・トラブルシューティングの全てに使い回せます。
ユースケース: 無効化されたユーザーアカウントの再有効化
説明: 退職者アカウントの悪用を検知するため、無効アカウントが
再有効化された際にアラートを生成する。
ステークホルダー: HR・IT
検出条件: アカウント無効化から24時間以上経過後、再有効化を検知
ユースケースは機密性が高く、社内のプレイブックとして管理すべき情報です。
第3章 インフラストラクチャー
SOCのインフラは3層に分けて考えます。
- 組織のセキュリティインフラ：ファイアウォール、IDS/IPS、AV、DLP 等
- オペレーションセンターインフラ：SIEM、ログ管理、チケットシステム
- サポートインフラ：物理レイアウト、ビデオウォール、ラボ環境
SIEMとログ管理の違い
よく混同される2つの概念を本書は明確に区別しています。
| SIEM | ログ管理 | |
|---|---|---|
| 目的 | リアルタイムの相関・アラート | 長期保存・フォレンジック |
| 要件 | 高速処理・大量ルール評価 | 大容量ストレージ・圧縮 |
両者を混用すると、どちらも中途半端になります。組織の規模とコストに合わせて適切に設計することが重要です。
チケットシステム設計
チケットシステムはSOCのワークフローの中核です。設計時に考慮すべき主な要素は以下です。
- 件名：送信元IPを含めると重複チケットの判別が楽になる
- キュー：Tier1/Tier2/エンジニアリング等でルーティング
- 理由コード：「感染除去済み」「偽陽性」等で指標に活用
- ソース追跡：SIEM発・電話発・メール発を区別して集計
- 自動ワークフロー：クリック数を減らしてアナリストの作業効率を上げる
"チケットをすべてアナリストが自力で分析するより、
チケットを開いたら必要な情報が揃っている状態が理想"
第4章 組織構造
SOCの報告ラインと組織上の位置づけは、SOCの有効性に直結します。CISOへの直接報告ラインが望ましいとされており、IT部門の傘下に置くとSOC本来の独立性が損なわれるリスクがあります。
Tier構成（Tier1: 初期トリアージ、Tier2: 深掘り分析、Tier3: インテリジェンス/フォレンジック）の設計と、各Tierが担う役割の明確化も重要なテーマです。
第5章 最も貴重な資源は人材
SOCにおける「人、プロセス、テクノロジー」の三本柱のうち、著者は人材こそが中核だと主張します。優れたプロセスもテクノロジーも、結局はそれを動かす人間の質によって成否が決まります。
バーンアウトが高い職種であるため、シフト設計・キャリアパス・スキルアップの機会提供が重要です。
第6章 日々の業務 / 第7章 トレーニング
日常業務の中で繰り返されるのが「イベントを評価し、チケットを起こし、対応し、クローズする」サイクルです。このサイクルを自動化・効率化するほど、アナリストはより高度な分析に集中できます。
トレーニングはラボ環境での実機演習が効果的です。紙の上の知識よりも「実際に攻撃シナリオを流して検知できるか」を確認する演習の方がSOCの実力向上に寄与します。
第8章 メトリクス
KPIを設定せずに動いているSOCは目標を持たない組織と同じです。本書が挙げる代表的な指標は以下です。
- インシデント対応時間（MTTR）
- 偽陽性率
- チケットクローズ率
- チケット発生源の内訳（SIEM/電話/メール）
ビデオウォール等にリアルタイムで指標を表示することで、チーム全体の状況認識を共有できます。
第9章 インテリジェンス
SOCをリアクティブな組織からプロアクティブな組織に進化させるのがインテリジェンスの活用です。外部のIOC（侵害の痕跡）フィードをSIEMルールに組み込み、自社環境への適用を継続的に改善することが、成熟したSOCの証です。
第10章 アウトソーシング
MSSP（マネージドセキュリティサービスプロバイダー）に委託する際も、「何をアウトソースし、何を内製するか」を明確にしないとコントロールを失います。SLAの設計、指標の定義、エスカレーションルートの確立は内製・外製を問わず必要です。
第11章 なぜここにいるのか忘れないでください
最終章は哲学的なメッセージです。SOCは「侵害を受けるかどうか」ではなく「いつ・どの程度の被害を受けるか」を最小化するために存在します。日々のルーティン作業の中でも、その使命を見失わないことが組織の継続的な強さにつながります。
まとめ
本書全体を通じて感じたのは、SOCは技術の問題ではなく組織設計の問題だという視点です。ツールを揃えても、顧客（ステークホルダー）が不明確で、ユースケースが文書化されておらず、人材が疲弊している組織ではSOCは機能しません。
構築の順序としては「1. 顧客の明確化 → 2. ユースケースの文書化 → 3. SLAの合意 → 4. インフラ設計 → 5. 人材育成」という流れが本書のメッセージの骨格です。
SOCの設計・改善を検討している方や、セキュリティ運用の体系化に興味がある方にとって、実務寄りの参考書として役立つ一冊だと思います。