セキュリティ組織設計：企画と運用を分ける
はじめに
セキュリティ製品の選定、PoC、導入展開、初期安定化までを一人で主導できる人がいるとする。その人を、そのまま定常運用の主担当に固定するのはもったいない。
理由は単純である。その人は「新しい能力を組織に作る人」だからだ。定常化した運用に張り付くと、次の企画、改善、導入が止まる。
この考え方はITILだけの話ではない。COBIT 2019、ISO/IEC 20000、NIST CSF、Google SRE、Team Topologies、PMIのBenefits Realizationでも、表現は違うが共通している。作る仕事、回す仕事、改善する仕事を分けるという話である。123456
まず分けるべき3つの仕事
最初に、セキュリティ組織の仕事を Build、Run、Improve に分ける。
| 区分 | 意味 | 主な成果物 |
|---|---|---|
| Build | 新しい仕組みを作る | 設計書 |
| Run | 定常業務を回す | 運用実績 |
| Improve | 運用から改善する | 改善バックログ |
この3つを同じ人に寄せすぎると、組織は属人化する。特にセキュリティでは、少数の強い人が企画、導入、監視、問い合わせ、障害対応、改善を全部抱えやすい。その状態は短期的には回っているように見えるが、長期的には組織能力が増えない。
フレームワーク上の位置付け
COBIT 2019は、ガバナンスとマネジメントの目的を、EDM、APO、BAI、DSS、MEAに分けて整理している。ここでは、セキュリティ組織設計に使いやすいように読み替える。
| 観点 | 意味 | 組織機能 |
|---|---|---|
| EDM | 評価と方向付け | 経営判断 |
| APO | 整合と計画 | 企画 |
| BAI | 構築と導入 | 導入 |
| DSS | 提供と支援 | 運用 |
| MEA | 監視と評価 | 評価 |
この整理を使うと、製品選定やPoCを担う人は主に APO と BAI の人材である。一方、定常監視や一次対応は DSS の仕事である。もちろん兼務はあり得るが、恒久的に同一人物へ寄せると、企画と導入の能力が運用に吸収される。
NIST CSF 2.0で見ても同じである。Govern で方針と責任を定め、Protect や Detect を設計し、Respond と Recover を運用する。セキュリティ組織には、検知や対応だけでなく、方針、責任、改善まで含む機能が必要になる。3
NIST RMFは、セキュリティとプライバシーリスクをシステムライフサイクルで管理し、継続的モニタリングまで含める。導入後に誰が監視し、誰が評価し、誰がリスク判断するかを決める根拠として使いやすい。7
人材設計まで落とすなら、NICE Frameworkが使える。仕事をTask、Knowledge、Skill、Work Roleで整理できるため、企画、導入、運用、高度分析を「人名」ではなく「担うタスク」で分けやすくなる。8
企画職と運用部隊の責任分界
企画職と運用部隊は上下関係ではなく、時間軸と責任範囲で分ける。
| 区分 | 担うこと | 担わないこと |
|---|---|---|
| 企画職 | 目的を定義する | 日次監視を主担当化する |
| 企画職 | 製品を選定する | 定型アラートを全件処理する |
| 企画職 | PoCを設計する | チケット処理を常時担当する |
| 企画職 | 運用設計を作る | 一次対応を恒久担当する |
| 企画職 | 初期安定化を主導する | 定常手順を抱え続ける |
| 運用部隊 | 定常手順を実行する | 導入目的を単独で再定義する |
| 運用部隊 | 監視を実施する | 製品戦略を単独で決める |
| 運用部隊 | 一次対応を行う | 例外リスクを単独で受容する |
| 運用部隊 | 証跡を残す | 改善投資を単独で決める |
| 運用部隊 | 改善要求を出す | アーキテクチャを単独で変える |
重要なのは、企画職が運用を知らなくてよいという意味ではない。むしろ逆で、企画職は運用できる形にして渡す責任を持つ。運用部隊も、単なる実行者ではなく、運用から見えた課題を改善要求として戻す責任を持つ。
運用へ移すタイミング
導入した仕組みは、次の状態になったら定常運用へ移す。
| 条件 | 確認すること |
|---|---|
| 目的が明確 | 何のリスクを下げるか説明できる |
| 対象が明確 | どの資産を対象にするか定義済み |
| 手順が明確 | 日次作業を再現できる |
| 判断基準が明確 | 運用で判断できる範囲が決まっている |
| エスカレーションが明確 | 専門判断へ上げる条件が決まっている |
| 証跡が明確 | 実施記録を確認できる |
| 例外処理が明確 | 標準外の扱いが決まっている |
| 改善導線が明確 | 運用課題を戻す先がある |
ISO/IEC 20000-1:2018は、サービスマネジメントシステムに、サービスの計画、設計、移行、提供、改善を含めている。つまり、運用へ渡すことは「丸投げ」ではなく、サービスとして提供できる状態へ移す活動である。2
運用移管パッケージ
運用部隊へ移すときは、最低限、次の移管物を作る。
| 移管物 | 内容 |
|---|---|
| 運用手順書 | 通常時の作業手順 |
| 監視設計 | 見るべきイベント |
| 判断基準 | 運用で判断できる条件 |
| エスカレーション条件 | 専門人材へ上げる条件 |
| SLA/SLO | 守るべき水準 |
| 権限設計 | 操作できる人 |
| 障害時手順 | 異常時の初動 |
| 変更手順 | 設定変更の流れ |
| 教育資料 | 運用担当者の学習材料 |
| 改善バックログ | 次に直す項目 |
これがない状態で渡すと、運用部隊は判断できない。結果として、導入した人にすべて戻ってくる。それは運用移管ではなく、属人運用の延長である。
SREの観点：高スキル者をToilに沈めない
Google SREでは、手作業、反復的、自動化可能、戦術的、長期価値が薄い、規模に比例して増える作業を toil として扱う。SREの重要な考え方は、運用作業に飲まれず、将来の運用負荷を下げるエンジニアリング時間を確保することにある。4
セキュリティ組織に読み替えると、次のようになる。
| 状態 | 見方 |
|---|---|
| 導入者が毎日アラートを処理する | Toil化している |
| 導入者が検知ルールを改善する | 改善活動である |
| 導入者が手順を標準化する | Toil削減である |
| 運用部隊が定型処理を担う | Runへ移管している |
| 運用課題が企画へ戻る | Improveが機能している |
ここで誤解してはいけないのは、運用が価値の低い仕事という意味ではない。価値が低いのは、改善されない反復作業を高スキル者が抱え続ける状態である。
Team Topologiesの観点：チームの形を決める
Team Topologiesは、チームを4つの基本形で整理する。セキュリティ組織にも使いやすい。
| チームタイプ | セキュリティでの例 | 役割 |
|---|---|---|
| Stream-aligned team | 事業部門 | 価値提供の流れを持つ |
| Enabling team | セキュリティ企画 | 他チームを支援する |
| Complicated subsystem team | 高度分析チーム | 専門領域を扱う |
| Platform team | SOC基盤チーム | 共通基盤を提供する |
この観点では、セキュリティ企画は全件を引き取るチームではない。現場や運用チームが自走できるように、標準、テンプレート、教育、レビュー、相談導線を提供するチームである。
典型例：EDR導入
EDR導入を例にすると、責任分界は次のように整理できる。
| フェーズ | 主担当 | 成果物 |
|---|---|---|
| 目的定義 | 企画 | 導入目的 |
| 製品選定 | 企画 | 比較表 |
| PoC | 企画 | 検証結果 |
| 運用設計 | 企画 | 運用設計書 |
| 展開計画 | 企画 | 展開計画 |
| 初期安定化 | 企画 | 調整記録 |
| 定常監視 | 運用 | 監視実績 |
| 一次対応 | 運用 | 対応記録 |
| 高度分析 | 専門 | 分析結果 |
| 改善管理 | 企画 | 改善バックログ |
この形なら、企画人材は定常監視から離れられる。一方で、導入後の責任を放棄するわけではない。改善バックログを通じて、運用で見えた問題を次の設計へ戻す。
RACIで責任を確認する
責任分界は、最後にRACIで確認する。
| タスク | 企画 | 運用 | 専門 | 経営 |
|---|---|---|---|---|
| 導入目的を決める | R | C | C | A |
| 製品を選定する | R | C | C | A |
| PoCを実施する | R | C | C | I |
| 運用手順を作る | R | C | C | I |
| 日次監視を行う | C | R | C | I |
| 一次対応を行う | C | R | C | I |
| 高度分析を行う | C | C | R | I |
| リスク受容を行う | C | I | C | A |
| 改善計画を作る | R | C | C | A |
| 記号 | 意味 |
|---|---|
| R | 実行責任 |
| A | 最終責任 |
| C | 相談先 |
| I | 報告先 |
RACIの目的は、責任を細かくすることではない。誰が主担当で、誰が判断者で、誰に相談するかを曖昧にしないことである。
よくある失敗
| 失敗 | 何が起きるか |
|---|---|
| 導入者が運用を抱え続ける | 次の企画が止まる |
| 運用部隊へ丸投げする | 判断できず差し戻る |
| 手順だけ渡す | 例外時に止まる |
| 判断基準を渡さない | 属人的な確認が残る |
| 改善導線を作らない | 同じ障害が繰り返される |
| 経営判断を現場へ寄せる | リスク受容が曖昧になる |
| 専門人材が一次対応を抱える | 高度分析の時間が消える |
特に避けたいのは、「強い人が全部やる」状態を成功と誤認することだ。それは導入成功ではなく、移管未完了である。
進め方
まずは大きな組織改編をする必要はない。既存のセキュリティ業務を、次の順で整理する。
- 既存業務を
Build、Run、Improveに分ける。 Runに入る業務の主担当を確認する。- 高スキル者が抱えている定型作業を洗い出す。
- 運用移管パッケージの不足を確認する。
- RACIで責任分界を確認する。
- 改善バックログの受け皿を決める。
この順で見れば、いまの組織が「企画が弱い」のか、「運用移管が弱い」のか、「改善導線がない」のかが分かる。
まとめ
セキュリティ組織では、企画人材を定常運用に固定しない方がよい。企画人材は、新しい能力を設計し、導入し、運用可能な形にする役割である。定常化した業務は運用部隊へ移し、運用で見えた課題を改善として戻す。
そのために必要なのは、単なる役割名ではない。
Build、Run、Improveを分ける。- 運用移管条件を決める。
- 運用移管パッケージを作る。
- RACIで責任分界を確認する。
- 改善バックログで企画へ戻す。
この形にすると、セキュリティ組織は「強い人が頑張る組織」から、「強い人が仕組みを作り、組織で回す状態」へ進める。