【要点抽出】セキュリティ対応組織の教科書 第3.1版 - 2LoD.sec

2LoD.sec

セキュリティマネージャの仕事やセキュリティガイドラインの要約など

【要点抽出】セキュリティ対応組織の教科書 第3.1版

セキュリティ対応組織作りに深く関わる立場にいながら、何故か「セキュリティ対応組織の教科書」は未読だったので読んでみました。

日本語だし、元々平易な表現でまとまっているのですが、自分の勉強メモとして要点抽出しておきます。

何の本?

タイトルにもある「セキュリティ対応組織(別名 CDC)」を立ち上げ、改善していく流れを体系的に整理した本です。


組織の形は様々ですが、結局「やること」の全量は大差ありません

それをインソース/アウトソースどちらにするのか、どの程度のレベルでやるのか、といったいくつかの軸で分類しながら組織の形をパターン化しています。

構成は?

全87ページのPDFと全67行のExcelで構成されます。

PDFのうち本紙は61ページまで。残りの附録はExcelとおおむね同じ内容(PDFの方が詳しい)です。


PDFの本紙は9章構成です。

3章が本書の骨組みであり、その内容を4章以降で解説しています。

  1. はじめに
  2. セキュリティ対応組織の存在意義
  3. セキュリティ対応組織のサイクル
  4. セキュリティ対応組織のカテゴリー
  5. セキュリティ対応組織のサービス
  6. セキュリティ対応組織の役割分担と体制
  7. カテゴリーおよびサービスの関連
  8. セキュリティ対応組織のアセスメント
  9. おわりに

前提知識

本書が2016年に初版が発行された後、その内容を多く取り込む形でX.1060/JT-X1060というフレームワークが生まれたようです。

また、そのフレームワークの知見を逆に取り込んで本書のv3.0が作られるなど、相互に影響しあっています。


このため、本書の中では「X.1060/JT-X1060」が132回も登場しており、ほぼ兄弟のような関係かと思います。


なお、今回は本書の第3.0版と3.1版の違いはフォーカスしません。

その違いについてはこちらのブログが非常に分かりやすいです。

vuls.biz

セキュリティ対応組織とは

X.1060/JT-X1060ではCDC(Cyber Defense Centre)と呼ばれます。

この絵で位置づけが表現されています。


JT-X1060 図1 CDCの運営における関係者とその役割>

  • 事業におけるセキュリティリスクの低減と適切な管理を目的に、
  • CISOのもとで組織全体のサイバーセキュリティのお仕事を統括し、
  • セキュリティにまつわるお仕事(CDCサービス)を提供する集団

と理解しました。


CSIRTやSOCもこの中に含まれ、日本だと「セキュリティ統括室」とか呼ばれるものにあたると思います。

CIAを守るだけでなくCPA(creativity:創造性、productivity:生産性、Agility:機敏性)」も守ることが必要という記載が印象的でした。


さて、この絵を見てCDCとは別に「セキュリティチーム」がいることが気になるかもしれません。

本書では、セキュリティチームは「CDCで定義したサービスが割り当てられ、実装や保守運用を行うチーム」「各部門においてセキュリティに関わる実務をこなしている現場担当」と書かれています。


例えばIPSやWAFの実装・保守を担っている人たちかな?と思いましたが、後述するセキュリティ対応組織のカテゴリーの中にも「CDC プラットフォームの開発・保守」があり、結局CDCとセキュリティチームは内包関係にあるのか別なのかがよく分かりませんでした。

セキュリティ対応組織のサイクル

どんな組織でも立ち上げて・活動して・改善するというサイクルがあります。セキュリティ対応組織も同様です。

本書ではそれを

  • 構築プロセス
  • マネジメントプロセス
  • 評価プロセス

と呼んでおり、これらをくるくる回すイメージです。

(1)構築プロセス

「構築プロセス」は、3つのフェーズで構成されます。

  • フェーズ1:サービスカタログを作成
    X.1060/JT-X1060が定義する9カテゴリ・64サービスのリストから自分達のセキュリティ対応組織が提供するものを選び、推奨レベルを割り当てる

  • フェーズ2:サービスプロファイルを作成
    サービスカタログに対して担い手を決める。インソース/アウトソースの切り分けもここで行う

  • フェーズ3:サービスポートフォリオを作成
    サービスカタログに対してサービススコア(成熟度的なもの)を決め、現状と目指すレベルを定義する


「推奨レベル」「サービススコア」など見慣れない言葉が出てきました。

以下、それぞれを解説します。


フェーズ1で登場する「9カテゴリ・64サービス」のリストは、本書の附録とExcelのサービスポートフォリオシートにまとまっており、これこそが本書およびX.1060/JT-X1060の一番おいしい部分だと思います。

JT-X1060 図4 CDCサービスリスト(一部)

ためしに私の所属組織で実施している業務とマッチングしてみたところ、ほぼ全て該当しており、かなり実務を反映した良いリストだと感じました。


同じくフェーズ1で登場する「推奨レベル」は、JT-X1060に5段階の表が定義されています。


JT-X1060 表1 CDCサービスの推奨レベル

ウェイト 説明
不要 不要と判断されたサービス
ベーシック 実装すべき最低限のサービス
スタンダード 一般的に実装が推奨されているサービス
アドバンスド 高いレベルCDCサイクルを実現する場合に要求されるサービス
オプション 想定されるCDCの形態に応じて任意に選択されるサービス


「不要」は今リソース不足で出来ないとか、親会社側で提供されるからグループ会社で用意しなくていいとか様々考えられます。

「ベーシック~オプション」は、優先度の高さを意味します。


推奨レベルの割り当ては結構難しいと思います。本書でも「必ずしも決め切る必要はない」とあります。

例えば「A-1 リスクマネジメント」はベーシック、「E-5 ペネトレーションテスト」はアドバンスドと定義してベーシックから徐々に満たしていく組織もあれば、A-1もE-5もベーシック!と言い切って一気に実現する組織もあると思います。


このあたりは組織ごとに違うのは分かるものの、例えば組織の規模や成熟度別に「各サービスの推奨レベルはこんなもんだろう」といった参考指標があると嬉しいところです。



フェーズ2で行う「インソース/アウトソースの切り分け」は、JT-X1060に4つのタイプが定義されています。


JT-X1060 表2 CDCサービスの割り当て

タイプ 説明
インソース 組織内のチームでサービスを実現する。責務を負う担当を明確にする。
アウトソース 組織外のチームでサービスを実現する。委託先を明確にする。
併用 インソースとアウトソースを併用する。責務を負う担当と委託先を明確にする。
未割り当て 組織に存在すべきサービスはあるが、割り当てられていない。


セキュリティ対応組織が提供するサービスごとに上記のタイプを選ぶ際は、以下の2点を考慮します。

  • そのサービスで取り扱う情報の性質
    (情報が組織内部・外部どちらのものか)
  • そのサービスが必要とするセキュリティの専門性
    (高=ポータビリティの高いスキル / 低=組織内・社内スキル)


この2つの判断軸に64のサービスをマッピングした上で、インソース/アウトソースどちらに寄せるべきか4象限で表したものが本書に掲載されており、非常に納得感があります。

セキュリティ対応組織(SOC/CSIRT)の教科書 第3.1版 図 16 セキュリティ対応の役割分担

この4象限のⅠはインソースが基本ですが、その他はⅡ→Ⅳ→Ⅲの順に進むほどアウトソースと相性が良くなります。

自組織のリソースに応じて、どこまでをインソースにするか・目指すかを考えます。


また、本書では、上記のうちⅢやⅣの領域をインソースで提供する場合の要員数を4段階のモデルケースで示しています。

  • Level0:4名
    立ち上げ初期の試験的なチーム。実行性はまだない。
  • Level1:7名
    実行性がある最低限のチーム。24365対応やフォレンジックはしない。
  • Level2:12名
    一通りの対応ができるプライべートSOCとしての水準。24365対応も行う。
  • Level3:26名
    グループ会社などを統括する規模の水準。


フェーズ3で登場する「サービススコア」は、セキュリティ対応組織が提供するサービスの成熟度のようなもので、評価対象のサービスがインソース/アウトソースどちらで提供しているかにより測り方が異なります


インソースの場合は、各業務が属人化しておらず、組織的な対応を行えているかどうかによりスコアが割り振られます。

  • 運用が明文化済。組織的に承認済(5点)
  • 運用が明文化済。担当者と交代して他者が業務を実施可能(4点)
  • 運用が明文化されていない。でもいざとなったら誰か一部の業務の代わりはできる(3点)
  • 運用が明文化されていない。特定の担当者が業務を実施できる(2点)
  • その業務が実施できていない(1点)


アウトソースの場合は、受けているサービスの内容や得られる結果の理解度によりスコアが割り振られます。

  • サービス内容と得られる結果を理解でき、想定通り(5点)
  • サービス内容と得られる結果を理解できているが、想定未満(4点)
  • サービス内容、得られる結果のいずれかが理解できていない(3点)
  • サービス内容と得られる結果を理解できていない(2点)
  • 結果や報告を確認できていない(1点)


これらの検討の末、サービスポートフォリオが完成します。

そのイメージは、こちらExcelを見ると分かりやすいです。


(2)マネジメントプロセス

作った組織を実際に活動させる段階です。


「マネジメントプロセス」は、3つの工程と2種類のサイクルで構成されます。

3つの工程とは「運用」「対応」「戦略マネジメント」です。

2種類のサイクルとは「短期」「長期」です。


短期サイクルで「運用」と「対応」を行い、

長期サイクルで「戦略マネジメント」を行います。


各工程の意味は以下の通りです。

  • 運用:ログ監視やセキュリティ機器のメンテなど、平常時に行うこと(≒SOC)
  • 対応:インシデント対応(≒CSIRT)
  • 戦略マネジメント:セキュリティ管理の体制やプロセスや仕組みを考え構築すること


上述の「9カテゴリ・64サービス」のリストは、この2サイクル・3工程にマッピングされます。

これは本書の「図11 カテゴリーと実行サイクル」が分かりやすく、詳細はJT-X1060「図8 CDC サービスカテゴリー」に表されています。

セキュリティ対応組織(SOC/CSIRT)の教科書 第3.1版 図11 カテゴリーと実行サイクル


JT-X1060 図8 CDCサービスカテゴリー

(3)評価プロセス

「評価プロセス」では、「構築プロセス」で挙げた3つのフェーズに対してギャップ分析を行い、見直します。

  • 各サービスに割り当てた「推奨レベル」の理想と現実にギャップがないか?
  • 各サービスに割り当てた「担い手(インソース/アウトソース)」の理想と現実にギャップがないか?
  • 各サービスに割り当てた「サービススコア(後述)」の理想と現実にギャップがないか?

を考えて継続的な改善につなげます。


これらの構築→マネジメント→評価のプロセスを繰り返すことで、組織を徐々に改善して理想の姿に繋げていく取り組みが必要です。



以上でまとめは終わりです。


私の場合は、これから組織を作るというよりも今ある組織をレベルアップさせていくのですが、その方向性を語る際にこうしたサービスのリストや4象限の図があると非常に考えをまとめやすく、活用しやすいドキュメントだと思いました。


これまでにまとめたガイドライン類の一覧はこちら