セキュリティ組織の作り方 SOC・CSIRTが機能しない理由とKPIにもとづく改善ステップ

1　なぜSOC・CSIRTはうまく機能しないのか

SOC（Security Operation Center）やCSIRT（Computer Security Incident Response Team）といったセキュリティ対応組織は、多くの企業ですでに整備が進んでいます。しかし、「体制はあるのに成果が見えない」「インシデント対応が場当たり的になっている」といった悩みは後を絶ちません。この原因の多くは、組織の「名称」や「構造」を先に決めてしまい、その組織が提供すべき具体的なサービスや機能が定義されていないことにあります。

たとえば、SOCを設置してログを監視していても、それがどのような目的に紐づき、どの水準まで実施すべきなのかが明確でなければ、単なる作業にとどまってしまいます。同様に、CSIRTのメンバーを任命していても、平常時に実施すべき活動や、インシデント発生時の判断基準が定義されていなければ、適切な対応にはつながりません。つまり、重要なのは「組織を作ること」ではなく、「何を実現するための機能を持つか」「その機能が適切に稼働しているか」を明確にすることです。

2　CDC（Cyber Defense Centre）とは何か 組織横断でセキュリティを捉える考え方

では、これらのセキュリティ機能は、組織の中でどのように担われるべきでしょうか。

「セキュリティ対応組織の教科書」（以下、教科書）および、国際標準でもあるフレームワーク「ITU-T勧告X.1060」において、最も重要かつ実務的な概念は「CDC（Cyber Defense Centre）」³ という「主体」の定義です。

読者の皆様の組織には、すでに「情報システム部」「セキュリティ対策室」「CSIRT」といった名称の部署が存在するかもしれません。CDCとは、それらの既存組織を置き換える新しい部署名ではありません。CDCとは、「組織において、ビジネス活動におけるサイバーセキュリティリスクを管理するためのセキュリティサービスを提供する主体」⁴ を指す抽象的な概念です。

たとえば、以下のようなケースもすべて、CDCの機能の一部とみなされます。

このように、組織の内外を問わず「セキュリティに関するサービス」を提供している要素をひとまとめにしたものがCDCです。この考え方を導入することで、部署間のセクショナリズムや、自社・外部ベンダーという垣根を越えて、「組織全体として必要な機能が揃っているか」を冷静に評価することが可能になります。

3　セキュリティ組織の評価指標（KPI）設計 何をどう計測すべきか

では、その「機能」が適切に稼働しているかどうかは、どのように判断すればよいのでしょうか。組織の活動が適切かどうかを判断するには、客観的な「物差し」が不可欠です。その代表例としてグローバルで広く普及しているのが、NIST（米国立標準技術研究所：National Institute of Standards and Technology）のサイバーセキュリティフレームワーク「NIST CSF 2.0（Cyber Security Framework）」⁵ です。

NIST CSFは、組織のセキュリティ対策状況を「統治（GOVERN）」「特定（IDENTIFY）」「防御（PROTECT）」「検知（DETECT）」「対応（RESPOND）」「復旧（RECOVER）」という6つの大きな機能（コア機能）へと整理、評価します。これにより、組織のセキュリティ対策の全体像を俯瞰的に把握することが可能になります。これは経営層や法務部門にとって、「自社の対策レベルは現在どの位置にあり、どこを目指すべきか」という全体像を把握するための、非常に有効な評価指標（KPI）となります。

しかし、ここで現場が直面するのが「具体性の欠如」という課題です。たとえば、「検知能力を強化し、高度な攻撃を早期に発見できる状態にする」という目標（KPI）を掲げたとします。この目標自体は正しいですが、これだけでは現場のエンジニアや情シス担当者は、「明日からどの業務に取り組めばよいのか」という行動計画に落とし込むことができません。

つまり、目標（物差し）を具体的な業務（設計図）へと落とし込む、「翻訳」プロセスが必要となります。そして、その役割を担うのが教科書で定義された64のサービスです。

4　KPIを実行に落とす方法：64のサービス

教科書では、組織が持つべき機能を9つのカテゴリー、全64の具体的な「サービス」として細分化しています。これらを活用することで、抽象的な目標を「実行可能なタスク」へと変換できます。

ここでは、そのすべてを掲載することはできませんが、組織構築において中核となるサービスを、各カテゴリーから抜粋して紹介します。

4-1　戦略・ガバナンスと組織の健全性（カテゴリーA・H・I）

法務部門や経営層、リスク管理部門が主導し、組織のルール策定や健全な運営を維持する領域です。

4-2　監視・分析の現場力（カテゴリーB・C・G）

運用組織（SOC）が真価を発揮する、検知と技術的分析の領域です。

4-3　事後対応と予防・評価（カテゴリーD・E・F）

CSIRTが中心となり、被害の最小化と再発防止、事前の備えを行う領域です。

5　実践：NIST CSFと64サービスの対応マッピング

ここまでは、組織の「物差し」としてNIST CSFを例に、「設計図」としての教科書（64のサービス）について、それぞれの役割を解説してきました。しかし、読者の皆様が最も知りたいのは、「それらをどう組み合わせて実務に落とし込むか」という具体的な手順でしょう。

ここでは、NIST CSFのコア機能のなかでも多くの組織が課題としてあげる「検知（DETECT: DE）」機能を例にとり、抽象的な目標を具体的なアクションへと翻訳するプロセスを詳解します。

5-1　KPIを具体タスクに翻訳する方法

NIST CSFの「検知」機能は、大きく「継続的監視（DE.CM）」と「有害事象の分析（DE.AE）」に分類されます。これを教科書のサービスにマッピングすると、以下のような「目標と手段」の対応関係が見えてきます。

対応表：NIST CSF 2.0「検知（DE）」と教科書サービスの対応マッピング例

NIST CSF 2.0 サブカテゴリー （評価基準・あるべき姿）	対応する教科書のサービス例 （実行手段・具体的タスク）	組織への実装ポイント
DE.CM-01 潜在的な有害事象を発見するために、NWおよびNWサービスが監視されている	B-1. リアルタイム監視 G-2/3. NWセキュリティ製品運用	ファイアウォールやIDS/IPS、NDR等のログを「24時間365日」監視する体制（B-1）と、検知精度を維持するための製品チューニング（G-2/3）が必要です。
DE.CM-03 潜在的な有害事象を発見するために、人員の活動および技術の利用が監視されている	B-1. リアルタイム監視 H-2. 内部不正検知・再発防止支援	外部からの攻撃だけでなく、特権IDの利用状況や、退職予定者の大量データ持ち出しといった内部不正の予兆を検知する仕組み（H-2）が求められます。
DE.AE-07 サイバー脅威インテリジェンス（CTI）およびその他の文脈的情報が分析に統合されている	F-2. 内部脅威情報の収集・分析 F-3. 外部脅威情報の収集・評価 F-5. 脅威情報の活用	自社のログを見るだけでなく、外部で流行している攻撃手法やIoC（侵害指標）を収集し、自社の検知ルールに反映させるプロセス（カテゴリーF）が該当します。
DE.AE-08 有害事象が、定義されたインシデント基準を満たす場合に、インシデントが宣言される	A-9. トリアージ基準管理 D-1. インシデント報告受付	システム的なアラートを、組織としての「インシデント」として正式に認定・宣言するための判断基準（A-9）と、報告ルートの確立が必要です。

5-2　セキュリティ組織の作り方 ギャップ分析とロードマップ策定

このような対応表を手元に置くことで、経営層の指示やNIST CSFのアセスメント結果を、現場が迷わず実行できるタスクへと落とし込むことができます。分析から改善までの具体的な3つのステップを見ていきましょう。

（1）ステップ1：解像度の高い現状分析

多くの企業が「検知（DE）」の評価を行う際、「監視機器を入れているから問題ない」と大まかに判断しがちです。しかし、上記の対応表に照らし合わせると、よりシビアな現実が見えてきます。

このように、NIST CSFのサブカテゴリー単位で「Yes/No」を確認することで、教科書のサービスリストと照らし合わせて「欠けているピース」をピンポイントで特定できます。

（2）ステップ2：責任分界点の決定

不足している機能（サービス）が特定できたら、それをどう埋めるかを決定します。ここで重要なのは「すべてを自社で対応する必要はない」ということです。教科書のサービス単位で、インソース（自社実施）かアウトソース（外部委託）かを振り分けます。

このように、NIST CSFの項目を満たすためのパーツを、自社とベンダーでどう分担するかを設計することが、実効性のあるCDC構築の鍵となります。

（3）ステップ3：セルフアセスメント

最後に、それぞれのサービスの「質」の目標を定めます。教科書では各サービスに対し、レベル1（場当たり的）からレベル5（最適化）までの独自スコアを定義しています。

このように、「目標」を達成するために、「どの教科書サービス（手段）」を、「いつまでに、どのレベル（品質）にするか」という計画を立てることで、現場担当者は迷うことなく、日々の改善業務に取り組めるようになります。

6　部門別に見る教科書の活用方法

6-1　IT部門：リソース最適化の根拠として

情シス部門は、常に「人員不足」と「予算不足」に悩まされています。教科書のサービスリストは、これらの課題を解決するための論理的な根拠となります。「現在、自社のリソースはプラットフォーム保守（カテゴリーG）に8割割かれており、戦略的なリスク管理（カテゴリーA）が空白地帯になっている」というデータを示すことで、適切な人員配置や投資の必要性を経営層に訴えることができます。

6-2　セキュリティ運用組織：キャリアとスキルの指標として

現場のメンバーにとって、64のサービスリストは「どのような専門性を身につけるべきか」というスキルマップになります。個人の成長が組織のサービスレベル向上に直結することを可視化すれば、モチベーションの維持にもつながります。

6-3　法務部門：ガバナンスの証明として

インシデントが発生した際、法務部門には「組織として適切な対策を講じていたか」を証明する責任が生じます。「国際標準に基づいた64のサービス項目について、定期的にスコアを評価し、不備があれば是正していた」という記録は、ガバナンスが機能していたことを示す強力な証跡となります。

7　セキュリティ組織は「KPIと機能」で設計する

本稿では、セキュリティ組織について、KPIを達成するための「機能（サービス）の集合体」という視点で整理し、概要を解説しました。本稿のポイントは以下の3点に集約されます。

しかし、いざ64のサービスリストを目の前にすると、「これらすべてを完璧に実施するのは、予算も人も足りない」と途方に暮れるのが現実ではないでしょうか。すべての組織がフルスペックのCDCを持つ必要はありません。重要なのは、自社のビジネス特性や守るべき資産のリスクに合わせて、「何をして、何をしないか」を戦略的に決定することです。

次回は、具体的なケースを想定し、その手法と判断基準について解説します。

---