2015年頃に脅威インテリジェンスという概念に出会ってから、色々調べて、講演・ブログで調査結果や自分の考えを公開してきましたが、一度その内容を体系的な資料として整理したいと考え、『脅威インテリジェンスの教科書』という形で執筆・整理したので、公開します。
先日公開した金融ISACの講演では、時間制約上、概要しかお話しできませんでした。それぞれの内容について、より詳細が知りたいという方は上記資料をご覧ください。
なにかのご参考になれば幸いです。
金融ISACの講演を公開しました！
先日オンラインで開催された『金融ISAC アニュアルカンファレンス 2020』において、『2019年度金融ISACアワード（個人賞）』を頂戴しました。ありがとうございます！！
受賞に伴い、アワード受賞記念講演として、『Intelligence Driven Securityの＜ことはじめ＞』と題して、脅威インテリジェンスの活用についてお話させていただきました。金融ISACはクローズドなカンファレンスのため、講演は会員企業に限定されますが、資料の共有について、金融ISACと会社の許可が下りましたので公開します。
今回の講演では、これから脅威インテリジェンスの活用を開始する金融機関を想定し、脅威インテリジェンスの分類や、活用手法などについてお話しさせていただきました。既に脅威インテリジェンスの活用に取り組まれている企業にとっては、基本的な内容かもしれませんが、ご参考になれば幸いです。
「リスク分析・管理」再考（その３）
前回（その２）は、リスク分析について深くご紹介しました。
大きく、６種類のステップでやることをご紹介します。
- Step 1 : 資産の特定
- Step 2 : 脅威の特定
- Step 3 : 脆弱性の特定
- Step 4 : 残存リスクの特定
- Step 5 : 発生確率・影響度の決定
- Step 6 : アウトプット作成
上記のプロセスは、上記のプロセスは、NIST SP800-30 "Managing Information Security Risk"におけるリスクマネジメントプロセスにおいて、「Assess」フェーズに該当します。今回は、残りの二つのプロセス「Respond」と「Monitor」をご紹介します。
リスク管理プロセス：Respondフェーズ
リスク分析を経てリスクを特定した後は、リスクへの対応を行います。リスク対応戦略は大きく４種類存在します。一般的には、リスク低減 → リスク受容をすることが一般的な戦略となります。
- リスク低減（Risk Mitigation）
- セキュリティコントロールの導入などにより、リスクを低減することを意味します。
- リスク受容（Risk Acceptance）
- 経営層の判断に基づき、残存リスクを受容することを意味します。
- リスク転移（Risk Transfer）
- リスクを第三者（3rd Party）に転移することを意味します。例えば、サイバー保険の活用や、サードパーティ製品・サービスの活用を意味します。*1
- リスク回避（Risk Avoidance）
- リスク、もしくはリスクの原因を取り除くことを意味します。例えば、ご送信のリスクを避けるために、メールでの顧客とのやり取りを禁止するなどが挙げられます。
５種類のセキュリティコントロール
リスク低減（Risk Mitigation）において、セキュリティコントロールを実装することが一般的です。分類は様々ですが、セキュリティコントロールは複数のカテゴリーに分類されます*2。
- 指揮的コントロール（Directive・Deterrent）
- 望ましい行動を促進したり、望ましくない行動を抑制するように指定・指示コントロール
- 例）ルール・啓発研修
- 予防的コントロール（Preventive）
- 特定の悪意のある行動を禁止・制限・抑止するコントロール
- 例）FW・アクセスコントロール
- 発見的コントロール（Detective）
- 悪意のある行動を検知するコントロール
- 例）IDS・EDR
- 訂正的コントロール（Corrective・Recovery）
- 発見的コントロールで検知された事象を修正・是正するコントロール
- 例）バックアップ
- 代替コントロール（Compensating）
- あるコントロールが正当な理由で取れない場合、リスクを低減するために取る代替策のこと
ここでのポイントは、多層防御（Defense-In-Depth）の観点から、複数種類のコントロールを組み合わせていくことが重要だとされています。例えば、アクセスコントロールによる予防的コントロールを実装した後、ログ監視による発見的コントロールを入れるなど組み合わせていくことが重要です。
リスク管理プロセス：Monitorフェーズ
さて、リスクマネジメントプロセスにおける最後のフェーズはモニタリングです。これは、以下の観点から、リスクと対応を監視し、何か変化があればリスク分析・リスク対応をやり直していくというプロセスです。
- 「リスク対応戦略が適切か？」
- 「セキュリティコントロールの実効性はあるか？」
- 「新しいリスクが登場していないか？」
リスク管理プロセスに関するまとめ
さて、上記の結果から、リスクマネジメントとは、リスク分析 → リスク対応 → リスクモニタリングを行っていくことだと言えます。そのため、リスク管理とはこの地道なプロセスを繰り返してく、PDCAサイクルにほかなりません。
さて、リスク分析・管理について少し補足しておきましょう。
補論１：リスク分析の簡略化について
第１回では、リスクとは、「脅威 × 脆弱性 × 資産」と紹介しました。しかし、一部のリスク分析では、「脅威 × 脆弱性」だけでリスク分析をする、さらにはCSCなどのフレームワークを使い、実質的に脆弱性だけでリスク評価をする場合もあります。
このように、リスク分析は簡略化をすることができます。
例えば、「資産は複数種類存在しない」、「いずれの資産も情報漏洩すればビジネス上大きな影響がある」など資産分析の種類によって分析結果がぶれない場合、省略することは可能です。
また、脅威についても、省略することが可能です。例えば、「脅威として特定のシナリオを想定している」、あるいは「いずれの脅威に対しても全力で対応する必要がある」などの場合、脅威をいくら考えても仕方ない場合があります。そうした場合、省略をすることが可能です。
特に、資産・脅威という二つのパラメータは、防御側でコントロールが難しいパラメータです。（一応、資産は防御側で管理できるパラメータなのですが、「これは非常にリスクが高い資産なので破棄しましょう」と主張したところでビジネス側は絶対に受け入れないでしょう）。そのため、当該２つのパラメータについては整理さえできれば簡略化することができます。
補論２：チェックリストアプローチ vs. シナリオベースアプローチ
上記のように、リスク分析を簡略化し、CSCによる「脆弱性」評価だけによるリスク分析をよくチェックリストアプローチと呼ぶことがあります。ようするに、CSCなどのチェックリストを用意し、YES/NO、あるいは５段階評価などで成熟度を測っていく方法です。このアプローチ自体は、簡単にでき、なにをやらなければいけないか明確にできるアプローチであるためとっかかりとしては非常に良いでしょう。下記記事で紹介した、CIS CSATは典型的なチェックリストアプローチのツールです。
しかし、これだけに頼ることは推奨しません。むしろ、CSCなどの棚卸をネットワーク図に当てはめ、攻撃シナリオを意識しながら分析していく、シナリオベースアプローチを利用することをを推奨します。そうしないと、落とし穴が生まれてしまう可能性があるためです。
例を挙げて説明します。例えば、ある企業Xは重要な業務システム・業務データをすべてクラウドに依存しているとしましょう。一方、チェックリストアプローチでチェックすると、（社内OA環境については）全て完璧に対策をできていました。この場合、正しいリスク分析はできているといえるでしょうか。
答えはNOです。上記の場合、一つの攻撃シナリオとしては、クラウドへの攻撃を考えるべきです。しかし、チェックリストに集中してしまい、「どんなネットワークか？」、「実際の攻撃シナリオは何か？」という点をおろそかにすると、本質を見失います。そのため、チェックリストアプローチは重要なアプローチですが、きちんと本質を見失いように攻撃シナリオを意識しながら分析していくことが必要になります。
参考文献
- 政府におけるRisk Management Framework（解説資料）
まとめ
さて、今回は「リスク分析・管理」の最終回ということで、リスクマネジメントプロセスの残りのフェーズについてご紹介しました。また、シナリオベースアプローチの重要性についてもお話をしました。
このように、リスク分析・リスク管理はセキュリティ施策の基礎となる方法ですが、こうした考えがあまり明確に書かれている資料がないため、ご参考になれば幸いです。
「リスク分析・管理」再考（その２）
前回は、リスクの定義、リスクマネジメントプロセスについて紹介しました。
前回のポイントは、リスクの定義です。改めて復習しておきましょう。
リスク = 発生確率 × 影響度 = 脅威 × 脆弱性 × 資産
今回は、リスクマネジメントプロセスの「ASSESS」フェーズについて具体的に紹介していきたいと思います。
リスク分析とは、大きく３つの特徴があるといえます。
- 3要素（脅威・脆弱性・資産）の３要素を特定する。
- 残存リスク（Residual Risk）を理解する。
- ROSI（Return on Security Investment）が高い対策を特定する。
リスク分析手法
NIST SP800-30によれば、脅威ベース、脆弱性ベース、資産ベースの３種類のアプローチが紹介されています。但し、結局全要素を分析する必要があるので、どこから手を付けるのか、というだけの話だと考えられます。
例えば、一つのアプローチとして、以下の方法で分析する方法があります。
- Step 1 : 資産の特定
- Step 2 : 脅威の特定
- Step 3 : 脆弱性の特定
- Step 4 : 残存リスクの特定
- Step 5 : 発生確率・影響度の決定
- Step 6 : アウトプット作成
それでは、各ステップごとに検討を進めていきたいと思います。
Step 1 : 資産の特定
資産の特定とは、文字通り自社の資産（システム・データ）を特定することです。そのためには、大きく３種類を特定します。
- ネットワーク図の特定
- データ資産リストの特定
- ビジネスプロセスの特定
第一に、ネットワーク図の策定です。具体的に、自社環境がどんなシステムを持っているか、どんな構成をしているか正確に理解するために、ネットワーク図を作ります。
第二に、データ資産リストとは、どんなデータを保持しており、性質、重要度、考えられる影響などを整理します。これを整理することで、影響度（Impact）が分析できるようになります。
第三に、ビジネスプロセスの特定で、具体的にどんな業務プロセスを持っているか整理を行います。この目的は、次で説明する通り、上記で整理したデータがビジネスプロセス上どのように流れていくか、そのデータフローを理解するために行います。
上記３種類の情報を集めたら、最後にマッピングを行います。マッピングとは、特定したデータ資産をネットワーク図、ビジネスプロセスにマッピングしていく作業で、ビジネスプロセス上のデータフロー、ネットワーク図上のデータフローなどを把握することが可能となります。
Step 2 : 脅威の特定
次に、脅威の特定を行います。脅威の特定とは、具体的な想定される脅威について、敵対的意図（Intent） × 能力（Capability）分析し、具体的な攻撃シナリオを整理することです。
敵対的意図（Intent）とは、攻撃者のモチベーションです。例えば、Canadian Centre for Cyber Securityが挙げるCyber Threat Actorsの分類では、以下のように分類されます。このモチベーションを果たすために、何をするのか考えることができます。具体的なアクションとして、情報セキュリティのCIA（Confidentiality・Integrity・Availability）の何を侵害するのか、あるいはSTRIDEフレームワークで具体的な脅威を整理しても良いでしょう。
一方、能力（Capability）とは、実際の攻撃手法（TTPs）です。これは、例えば事前に定義された攻撃シナリオを使う方法です。例えば、金融庁は演習などを通じて、攻撃シナリオを提供しています（リンク）。
また、APT・Oraganized Cyber Crimeを想定する場合、Threat Actors（攻撃グループ）を研究することで、攻撃者の意図と能力を同時に分析することができます。例えば、FireEye社のレポートによれば、APT41は知的財産の窃取を目的にしており、医療分野などを攻撃対象とし、次のような攻撃手法で知られています。
このように攻撃グループを分析することで、脅威（Intent × Capability）を分析することも可能です。脅威グループについては、次のリソースなどを活用することができます。
さて、ここで重要なことは２点です。
第一に、攻撃者の意図（Intent）と、既に特定した「資産」と合致している必要があります。先ほど例に挙げたAPT41の場合、知的財産を狙うため、資産としては知的財産がある必要があります。
第二に、ここで特定した攻撃手法は、ネットワーク図やビジネスプロセスにマッピングしてあげる必要があります。以下に、その例を挙げています。
Step 3 : 脆弱性の特定
「脆弱性の特定」とは、自社の脆弱性を特定することです。
では、脆弱性とは何でしょうか？様々な定義があると思いますが、ここでは以下の定義を採用しておきましょう。
脆弱性 = （理想のセキュリティ状態）ー（現在の状態）
脆弱性とは、あるべきセキュリティの状態（To-Be）と現在のセキュリティ状態（As-Is）のギャップという定義です。例えば、MS17-010脆弱性が脆弱性と認識される理由は以下の通りです。
- To-Be：本来リモートから任意のコードを実行できてはいけない
- As-Is：EternalBlueなどの攻撃ツールにより、任意のコードを実行可能
但し、リスク分析では特定の脆弱性について分析するわけではありません。むしろ、システム全体の脆弱性を洗い出していきます。
さて、これをシステム全体の脆弱性を分析する場合、セキュリティフレームワークを利用する方法が一般的です。セキュリティフレームワークは一般に、セキュリティのあるべき姿を示しているため、そのフレームワークを使って現状を分析することでシステム全体の脆弱性を明らかにすることができます。
個人的には、CIS ControlsがCIS CSATという無償分析ツールなども公開をしており使いやすいと思います。CISコントロールの詳細についてはこちらを参照してください。
Step 4 : 残存リスクの特定
このフェーズは、資産・脅威・脆弱性を利用して、残存リスク（Residual Risk）を特定します。
具体的なフェーズは、以下の通りです（既に実施済内容も含みます）。
タスク１：資産を分析し、影響範囲を特定する。（Step 1で実施済み）
例えば、以下のように資産を特定します。
＜顧客データ：重要度（High ~ Very High）＞
- リスク（CIA）：機密性（Confidentiality）
- 資産価値：HIGH（補償・顧客ロイヤリティの喪失）
- 暗号化なし。データ保存ポリシーがないため、非アクティブな顧客情報も含む
タスク２：資産・攻撃シナリオをNW図へマッピング（Step 2 & 3で実施済み）
資産と攻撃シナリオをネットワーク図にマッピングし、ネットワーク図上の攻撃シナリオを特定します。
タスク３：攻撃シナリオを、脆弱性の分析結果を組み合わせる
特定した攻撃シナリオと現在のセキュリティ対策・不足しているセキュリティ対策を組み合わせて、どの脆弱性（不足したセキュリティ対策）が単一障害点（SPF：Single Point of Failure）になるか、どの脆弱性（不足したセキュリティ対策）が実装されれば攻撃シナリオを止められるか、分析を行います。
その結果を、ネットワーク図にマッピングしていきます。
タスク４：残存リスクの特定
その後、上記の結果から、残存リスクをまとめていきます。
残存リスクシナリオ（Threat × Vulnrability ：High ~ Very High）
攻撃者がカスタマイズされたマルウェアを利用した場合、Office 365とエンドポイントのウイルス対策を回避された場合内部に侵入されます。しかし、侵入後、EDRが存在せず、SOCの能力も低いため、マルウェアを検知することが難しい。また、C&C通信は、Webフィルタリングのアップデートが適切になされていないため、検知できない可能性があります。
Step 5 : 発生確率・影響度の決定
次に、発生確率・影響度を導き出します。既に示した通り、それぞれの定義は以下の通りです。
- 発生確率（定義１）＝ 脅威 × 脆弱性（定義２）
- 影響度（定義１）＝ 資産（定義２）
ここから、R-Map（リスクマップ）へマッピングを行います。既に述べた通り、特にNon-ITの経営層にとってこの図は良いコミュニケーションツールであり、意思決定ツールになります。
Step 6 : アウトプット作成
次に、上記の結果を踏まえて、アウトプットを作成します。具体的には、上記のようなR-Mapに加え、優先度付きの対策一覧を出すことで具体的なアクションに結び付けていくことができます。
まとめ
今回は、リスク分析の具体的手法について説明してきました。このやり方は全てではありませんが、一つのやり方としてとらえていただければと思います。この評価では、ネットワーク図とビジネスプロセスへのマッピングへ帰着させることを強く意識しています。
その理由としては、ネットワーク図やビジネスプロセスを無視すると、本質的な脅威を見落とす可能性があるためです。たとえば、重要資産がクラウド環境に依存している環境において、いくらオンプレのセキュリティを語っても意味がありません。むしろ、きちんと実態に即した分析をする意味で、実際のビジネスプロセスとネットワーク図に帰着させることが重要だと思います。
次回は、NIST SP800-30 "Managing Information Security Risk"のリスクマネジメントプロセスの残り二つ（Respond・Monitor）とリスク分析の補足議論について行いたいと思います。
CIS Controlsと自己評価ツールCIS CSAT
CIS Controlsとは、CIS（Center for Internet Security）が管理しているサイバーセキュリティのフレームワークで、CSC（Critical Security Control）とも呼ばれます。
通常、セキュリティを担当するように言われた際、自分だけで考えていくと多くの考慮漏れが発生します。フレームワークはそういった考慮漏れがないよう、多くの専門家が検討に参加し、網羅性を担保した考え方です。
ちなみに、サイバーセキュリティのフレームワークはこれだけでなく、様々な種類があります（一部、法制度なども含まれます）。
- ISO 27001/27002
- NIST Cyber Security Framework
- ISF Standards of Good Practice for Information Security
- Payment Card Industry Data Security Standard (PCI DSS)
- NYDFS Cyber Security Regulation
- Australian Government - The Protective Security Policy Framework
- ASD Australian Government Information Security Manual
- ASD Strategies to Mitigate Cyber Security Incidents
- MAS Technology Risk Management
- FFIEC Cybersecurity Assessment Tool（金融庁調査レポート）
- Cybersecurity Capability Maturity Model(C2M2)
- HITRUST Cyber Security Framework
- FISC 金融機関等コンピュータシステムの安全対策基準
先ほど「網羅性」という単語を使いましたが、多くのフレームワークは特徴を持っており、CIS Controlsはサイバー攻撃に対する技術的対策をメインとするフレームワークです。
CIS Controlsの歴史
CIS Controlsの歴史は、2008 年にさかのぼります。国防総省（DoD）のセキュリティ支出に対して優先度をつける為、国防長官府（Office of the Secretary of Defense）がNSAに対して、「無数あるセキュリティ対策の優先度をつけるプロジェクト支援」を依頼をしたのが始まりとされています。
NSAに協力要請が届いた理由は、以下だといわれています。
- NSAは、当時もっともサイバー攻撃に精通していたこと*1
- 2000 年代初頭から、ホワイトハウスからの指導により強化された軍部からの要請に基づいて、既知の攻撃を阻止するために最も効果的なセキュリティ対策リストを作成していたこと
もともと政府利用前提とされていた内容ですが、NSAが持つ官民連携の枠組みを活用し、CIS・SANS Institute、様々な有識者を巻き込んで2009年度頃に公開され、現在ではVer.7.1までに進化しています。SANSが以前が全面的に協力していたこともあり、SANS Top 20 とか、SANS Critical Security Controlと呼ばれていた時代もあります。
こうした経緯から、CIS Controlは、サイバー攻撃の技術的対策に特化したフレームワークだと知られています。
より詳しい歴史を知りたい方は、こちらを参照してください。
CIS Controlsを読み解くポイント
CIS Controls自体は、以下に公開されていますので実際に読んでみることを推奨していますが、読み解く上でのポイントをいくつか紹介したいと思います。（ダウンロード）
5つの原則
CIS Controlsは、大きく５種類の原則があります。
- 攻撃から防御を学ぶ
- 優先順位をつける
- 測定とメトリクス
- 継続的な診断とリスク低減
- 自動化
特に注目すべきは、「測定とメトリクス」と「自動化」というポイントだと思います。まず、「想定とメトリクス」とは、日々の取り組みを定量化していくという点です。これは、日々のセキュリティプログラムの意義を経営層に説明する上で非常に重要な取り組みです。
また、CIS Controlsは「自動化」を推奨しています。これは、米国のセキュリティ人材市場が流動的で、人に依存したプロセスが組みづらく、また人間はミスをしやすいのでその可能性を排除したいという考えから、こうしたことに言及しています。
こうした「測定とメトリクス」や「自動化」などの取り組みを全面に押し出すガイドラインは珍しいといえます。
20種類のコントロール
さて、CIS Controlsは20種類のコントロールで成立しています。元々、サイバー攻撃対策の優先度を決めるフレームワークだけあり、技術的、NISTフレームワークの５カテゴリー（特定・予防・検知・対応・復旧）をバランス良く入っています。
- CIS Control 01：ハードウェア資産のインベントリとコントロール
- CIS Control 02：ソフトウェア資産のインベントリとコントロール
- CIS Control 03：継続的な脆弱性管理
- CIS Control 04：管理権限のコントロールされた使用
- CIS Control 05：ハードウェアおよびソフトウェアのセキュアな設定
- CIS Control 06：監査ログの保守、監視および分析
- CIS Control 07：電子メールと Web ブラウザの保護
- CIS Control 08：マルウェア対策
- CIS Control 09：ネットワークポート・プロトコル・サービスの制限とコントロール
- CIS Control 10：データ復旧能力
- CIS Control 11：ファイアウォール・ルータ・スイッチなどのネットワーク機器のセキュアな設定
- CIS Control 12：境界防御
- CIS Control 13：データ保護
- CIS Control 14：Need‐to‐Know に基づいたアクセスコントロール
- CIS Control 15：無線アクセスコントロール
- CIS Control 16：アカウントの監視およびコントロール
- CIS Control 17：セキュリティ意識向上トレーニングプログラムを実施する
- CIS Control 18：アプリケーションソフトウェアセキュリティ
- CIS Control 19：インシデントレスポンスと管理
- CIS Control 20：ペネトレーションテストおよびレッドチームの訓練
３つのカテゴリー
CIS Controlsは、Basic・Foundational・Organizational の３種類に分類されます。
Basicに分類されるCIS Control 1 ~ 6までは必要不可欠であり、最初にやるべきCyber Hygiene（サイバー公衆衛生）として知られています。そのため、Cyber Hygieneについて聞かれた場合は、この６つのコントロールを提示すればよいことになります。
４つの項目
各CIS Controlsは、以下の４項目が必ず書かれています。
- 当該コントロールの重要性
- サブコントロール
- 手順とツール
- システムエンティティ図
その重要性と各コントロールを実現するためのサブコントロールが表現されています。また、先ほどキーワードで挙げた通り、自動化に向けた「手順・ツール」と実装例としての「システムエンティティ図」なども紹介しています。
CIS Controlsの利点
CIS Controlsの利点は、様々なリソースが公開されている点が挙げられます。
例えば、CIS Controlsに伴って対策を実装するのであれば、当然次の疑問は、「何がソリューションになるか？」でしょう。昔は、SANSが認定製品リストのようなものを作っていたのですが、現在は中立性を優先してか、そういった情報は出なくなっています。以下に、古いバージョンも含めてリンクを張っておきます。
また、Windows 10とCSCについては以下で整理されています。
CIS Controlsによる自己評価（CIS CSAT）
CSCを活用する方法として、自社のセキュリティ態勢を評価することができる点です。
実際に、CSCは成熟度を評価するツール（CIS CSAT : CIS CSC Self-Assessment Tools）を提供しています。
もともと、こうした自己評価ツールとして、AuditScript社のExcel評価ツールを推奨していましたが、CSCの管理元であるCSC CSATというツールを出したため、これを使うのが良いと考えています（実際、このフレームワーク自体もAuditScript社の内容を参照しているようです）。私も登録して使ってみましたが、Evidenceを登録させたり、承認機能があり、同業他社との比較をしたり、報告用PPTを自動作成してくれたりと、無償でも非常によくできているツールだと思います。
もちろん、セキュリティ企業に依頼すれば、独自フレームワーク等を使い、インタビューやエビデンスを分析してもらい、第三者的観点での評価を得ることができます。しかし、こうした評価は多くの予算と労力を必要としますので、自社でCSCで評価できる人材がいる、予算が少ない企業はこうした無償ツールを使うことも一つの手段だとできます。
補足：他のフレームワークとの関係性
他のフレームワークとの関係性については、上記のCIS CSATがマッピングを整理していますし、また資料もいくつか存在します。
- CIS Controls V7.1 Mapping to NIST CSF
- Mapping Microsoft Cyber Offerings to: CSF, CIS Controls and ISO27001:2013 Frameworks
補足：オープンフレームワーク vs. 独自フレームワーク
こうしたフレームワークに基づく評価として、オープンフレームワークとコンサルティング会社が提供する独自フレームワークのどちらを使うべきかという議論があります。個人的にはオープンなフレームワークの利用を推奨していますが、メリット・デメリットを踏まえて判断すべき内容だと考えています。
オープンなフレームワークは、多数の専門家による知見が結集されている一方、使い方に成熟する必要があったり、コンセプトによっては期待する網羅性が担保されていない可能性があります（例えば、CSCのは技術的対策を中心としているため、内部不正やプロセスという面では弱い可能性があります）。
一方、コンサルティング会社の独自フレームワークは、様々なフレームワークを組み合わせているケースが大半のため、より多くの網羅性がカバーされていたり、個社の性質によってはよりマッチしている可能性があります。一方、ロックインの要因になる、他社比較が難しい、グループ内・業界内の共通言語になりづらい、評価に偏りがでる可能性がある、サービス提供停止になる可能性があるなど、デメリットもあります。
個人的には、こうした評価は、一過性ではなく継続的に実施すべき内容ですので、できるだけオープンフレームワークを使うことが望ましいと考えていますが、それぞれのメリット・デメリットを判断しながら決定するのが望ましいといえます。
まとめ
今回は簡単にCSCの概要と自己評価ツールについて整理しました。こうしたフレームワークによる点検は継続的に見直していくべき内容ですので、ツールを使いながら整理していくと良いかと思います。
*1:実際、TAO（Tailered Access Operation）と呼ばれる攻撃チームを持っています。