Techカテゴリ

ISOG-J セキュリティ対応組織の教科書が更新されました

ISOG-J(日本セキュリティオペレーション事業者協議会1)が公開している「セキュリティ対応組織の教科書2」について、2023年10月17日に更新版である 3.1版 が公開されました。3.0版と3.1班の差分を簡単に説明しつつ、どのように利用するのが良いかについて記載します。

; 本稿は、筆者の見解であり、Future及びISOG-J等の見解ではないことに注意が必要です。

セキュリティ対応組織の教科書とは

セキュリティ対応組織の教科書は、SOCやCSIRTなどのセキュリティ対応を行う組織の構築や運用について、組織としてどのように全体観を持ってサイバーセキュリティ対応を実現するか方向性を示している資料です。

この教科書自体は、JNSA(NPO Japan Network Security Association3)配下のISOG-Jのワーキンググループ「WG6: セキュリティオペレーション連携WG」で執筆されたものです。
ISOG-Jのワーキンググループでは、「Webシステム/Webアプリケーションセキュリティ要件書(WG1)」「Webアプリケーション脆弱師診断ガイドライン(WG1)」「マネージドセキュリティサービス(MSS)選定ガイドライン」などを公開しています。

会社組織でどのようにセキュリティ対応を行う組織を作ればいいのか/考えればよいのか、の参考資料として作られています。言及する範囲から、経済産業省の”サイバーセキュリティ経営ガイドライン4“も別途参照が必要です。SOCやCSIRTという実対応する部署というよりは、組織のセキュリティポリシー策定や統制も含めた全体を指しています。

なぜFutureVuls Blogで紹介するのか

このBlogで紹介を行うのは、以下の意味合いからです。

  • 脆弱性対応は単独で意味があるわけではなく、組織のセキュリティ対応の一環として考えられるべきであり、本書がそれを考える起点になる為

以前のVuls祭りや塩尻サイバーセキュリティ勉強会でも言及しましたが、組織のセキュリティ対応活動を俯瞰して考えることが非常に重要です。
例えば、脆弱性管理(アップデート運用)を完璧に行っていたとしてもログ管理をしていなければ侵害が発生したかを確認することはできませんし、ログ分析をする組織がなければ侵害を検出することもできません。また、インシデントが起きないように教育やトレーニングが必要ですし、セキュリティベンダや関連団体との連携も必要でしょう。対応リソースが特定の対応に偏っていては、実装した機能が有効に活用できないことは多々あります。「全体として何をやらなければいけないのか」を俯瞰できるような資料であるため、FutureVulsで提供する脆弱性対応とその周辺の必要な活動を可視化し、より安全に運用できるような気づきが得られると考えます。

また、担当者においては、現在やっている業務が組織のセキュリティ対応に於いてどの部分に該当し、どのように他の機能と連携するのか、などを考えるきっかけになると考えます。それにより、例えば自身のキャリアについて考えることもできるでしょう。

上記理由でFutureVulsBlogにて本書を紹介します(おそらく、私がWG6で微力ながら本件に関わっている、個人の勉強会でもX.1060の話をしている、というblogの私的利用的な側面も否定できません。。)。

差分について

今回の 3.0版から3.1版への更新 は何が変わったのでしょうか。
見比べてみると、内容は大きくは変わっていません。

  • より分かりやすくなることを意図した、表現変更
  • 図の追加による、番号付け直し
  • 説明を追加
  • サービスポートフォリオシートの追加

全体として述べていることは変わりません。言及が必要そうな部分のみ、こちらで差分を書いてきます。

図表の追加

P.28に、”図12 マネジメントプロセスと各サービスの関係”という図が追加されています。
これは、セキュリティ対応組織(CyberDefenceCenter:CDC)は何をするべきかの全量を示した”CDCサービスリスト”と、マネジメントプロセスの関係図であり、どの目的のためにどのサービス(機能)を実装すればよいのか、の参考になると考えられます。

脆弱性管理については “E.診断と評価”の”E-3 脆弱性診断”及び”E-4パッチ管理”が該当すると考えられます。
前段として、”E-1 ネットワーク情報収集”や”E-2 資産棚卸し” などが必要なこともわかります。

FutureVulsは驚異情報も利用しているため、以下の機能を一部でもみたいしていると言えるでしょう。

  • F-3 外部驚異情報の収集・評価
  • F-5 驚異情報の活用
  • E-2 資産棚卸
  • E-3 脆弱性診断
  • E-4 パッチ管理

推奨レベルの表現変更

サービスの推奨レベルについて、今まではベーシック/アドバンスドと故障していたものが、”必須””推奨”に変更されました。こちらのほうが理解しやすい単語だからだと思われます。

また、サービススコアの呼称では、現状及びあるべき姿に”As-Is”や”To-Be”の括弧書きが追加されています。

補足の追加

例えば、”3.4.2 ギャップ分析と見直し”において、「一度作った体制も徐々に陳腐化してしまうことは避けられない。」の補足として、COVID-19によるリモートワークの例が追加されている。理解促進のための補足の説明となっています。

同様に、”4.2 カテゴリーとセキュリティ対応の実行サイクル”に於いては、図中のマネジメントサイクルに関する補足がされている。

“5.2.1. X.1060の推奨レベルの解釈の仕方”についても、表も含めて補足説明が加わっています。

“6.6 セキュリティ対応組織の要員数”も、補足説明が加わっています。

“8.3 各サービスの実行レベル”部分は説明が詳細になっている（17行から26行）ので、読み返しても良いと思われます。

セキュリティ対応組織と脆弱性管理

以上のように、差分としては大きな内容変化はありません。

脆弱性管理という文脈で考えた場合、引き続き、以下のことに注意が必要と思われます。

  • 図12マネジメントプロセスと各サービスの関係、を理解する
    • FutureVulsを含む脆弱性管理製品はどこまでカバーしているのか、カバーしている内容はどの程度まで実施されるのか、を確認しておく必要がある
    • “E-2 資産棚卸し”は全数で来ているかを考える必要がある
    • “E-3 脆弱性診断”は、どこにどの頻度で必要化を考える必要がある。機械的に実施するのか、ペネトレーションサービス等を使ってリリースタイミングで確認するのか、等
    • “E-4 パッチ管理”の失敗後（インシデント発生時）の活動もパターンとして用意しておく
    • 上記全体の動きとして、”E-7 サイバー攻撃対応力評価”を実施したほうが良いと思われる

まとめ

セキュリティ対応組織の教科書は、脆弱性対応以外の領域を含む、全体を俯瞰できるものに仕上がっていると思います。一度目を通して、自組織の状況と合わせて考えてみるのが良いと思われます。

※すべてを教科書に沿ったものに置き換えるという発想ではなく、「現状実装できているところ」「できていないところ」「代替えが聞きそうなところ」に気づき、必要であれば対策を取るきっかけになる、というのが目的と考えます。自組織になにか使えそうな考え方や表現はないかな、という味方で良いと思います。

参考