フューチャー技術ブログ

リスクアセスメント ーリスクの可視化から意思決定までー

夏の自由研究2025ブログ連載の2日目です。

はじめに

人生は選択の連続ですが、何を選択するかどうやって決めていますか?

おそらくはメリット/デメリットを鑑みて方向性を決める方が大半だと思います。時には、どう転んでも一緒でメリデメで考えない場面もあるとは思いますが、巨額マネーが動くケースではそうもいきませんよね。

今回は、サイバーセキュリティ界隈の文脈で「リスクの可視化~意思決定」がどのように行われるのかをお話します。これはプライベートでも仕事でも、おおよそ生きていく上で役立つ基本の考え方にも応用できると思います。

リスクアセスメントとは

ビジネスはいかに精度よく予測して経営計画を立て、調整力と実行力で推進し、残りは運、そんな感じのポートフォリオかと思います。もちろん経営者の方の中には長年の勘やデータからは読み取れないが物理的な何某か(ex. 生きている消費者から直接感じ取る波動や世間のそわそわした感じ…etc.)などあるかと思いますが、結局現実判断としてどの程度の見込みや期待に対して、どの程度リスクをとれるのか or とれないのかをどこかのタイミングでしています。

サイバーセキュリティの世界でも「リスクを可視化して経営者が意思決定しやすい状態にする」活動があり、それが我々の仕事の一つ、リスクアセスメントです。

リスクアセスメントの実践ステップ

では、具体的にどのように進めるのでしょうか。大まかには以下のステップで行われます。

  1. 情報資産の特定と評価
    まず「何を守るべきか」を明確にします。顧客データベース、ウェブサイト、社内システムなどをリストアップし、それぞれが停止したり情報が漏えいしたりした場合のビジネスインパクト(機密性・完全性・可用性の観点)を評価します。情報資産台帳をもとに洗い出すことが多いです。
  2. 脅威の特定と評価
    資産に対してどのような悪いことが起こりうるかを考えます。”脅威モデリング” という分野がここに該当します。
  3. 脆弱性の特定と評価
    資産にどのような弱点があるかを評価します。
  4. リスクの算定
    「資産価値」「脅威」「脆弱性」を包括的に考慮し、リスクレベルを評価します。リスクアセスメントは、評判、収益、法的・規制上のリスクといった複雑に絡み合った概念への影響も考慮することによって行われます。
  5. リスク対応の決定と報告
    この結果を、「現在〇〇のリスクが年間XXXXの確率で存在しますが、対策YにZZZ投資することで、リスクを$XXに低減できます」といった形で経営層に報告し、最終的な意思決定を仰ぎます。

このように、リスクアセスメント はインプットをもとに、意思決定を行うまでのプロセスを指します。

これとは別に、脅威モデリング という分野もあります。インプット自体をどう行うのかを作成するプロセスを指します。したがって、両者は密接に関わり、さらに前者は後者を内包し、後者は前者の中の複数のステップに関わっています。実際、どのように脅威の算出ステップを踏んでいるのか メルカリのユースケースPURESTORAGEのユースケース を見てみましょう。こちらの記事からも分かる通り、現状では自分たちが評価しやすいように各種フレームワークやモデルをカスタマイズして利用しているところが大半です。

脅威モデリングの成否は、ステップ1のシステムの全体像の正確な可視化に大きく依存します。DFD(データフロー図)はそのための最も効果的なツールの1つであり、これを用いてデータの流れや信頼境界を明確に定義します。このDFDの精度が、後続の脅威分析の網羅性と正確性を直接的に決定づけるため、最も注力すべき工程です。

フレームワーク・方法論・ナレッジベース

セキュリティの世界では、リスクを式で捉えなるべく定量化するようにフレームワーク等の確立を進めています。こうすることで客観的に表現できるよう努めています。以下によく用いられる思考モデルについてまとめてみました。

image.png ※ナレッジベースは定量度を考慮して配置するのが難しかったため、最下部にまとめています。該当象限やカテゴリ分けが違う等ご指摘あればコメントいただきたいです、ブラッシュアップしたいです!

各ステップで用いられる思考ツールがあるので下記に紹介します。どのステップで何を活用するのかをまとめた記事は、別途執筆予定(or 加筆修正)予定です。

フレームワーク:テクノロジーサイド

まず、テクノロジー寄りのフレームワークについてです。

CVSS(共通脆弱性評価システム)

こちら は、個別のソフトウェアなどの「脆弱性(弱点)」そのものの深刻度を評価するための世界共通の指標です。特定の企業のリスクというより、個々の弱点の危険度を0.0~10.0のスコアで示します。IT管理者が膨大な脆弱性情報の中から、対処の優先順位を判断するために広く使われています。

CVSSスコアは、以下の3つの基準から算出されます。

  1. 基本評価基準 (Base Metrics)
    脆弱性そのものが持つ、時間が経っても変わらない本質的な危険度。
  2. 現状評価基準 (Temporal Metrics)
    攻撃コードの出現など、時間と共に変化する脅威の状況を反映した危険度。
  3. 環境評価基準 (Environmental Metrics)
    組織の対策状況など、その脆弱性が存在する個別の環境に合わせた実際の危険度。

詳細は 弊社FutureVuls Document

OWASP ASVS (Application Security Verification Standard)

こちら は、検証フレームワークです。アプリケーションが満たすべきセキュリティ要件を網羅的にリストアップしており、テストや評価の際の市場における検証範囲と厳密さのレベルを標準化することを目的としています。この標準は、Webアプリケーションのセキュリティに対する信頼レベルを確立するために使用されます。

フレームワーク:ビジネスサイド

ここからはビジネスサイド寄りのフレームワークになります。

NIST SP 800-30 ー情報システムに対するリスクマネジメントガイドー

こちら は、技術的な脅威や脆弱性が、組織のミッションやビジネスプロセスにどのような影響を与えるかを評価するための「プロセス」そのものです。アメリカ国立標準技術研究所(NIST)が発行しているガイドラインで、特に米国政府機関やその取引先で標準的に利用されており、非常に詳細で体系的なアプローチが特徴です。技術部門からの情報(テクノロジー)と、事業部門からの情報(ビジネス)の両方をインプットとして必要とするため、両者の橋渡し役として機能します。

脅威、脆弱性、影響、可能性の4つの要素からリスクを評価します。リスクアセスメントのプロセスを「準備」「実施」「伝達」「維持」の4つのステップで定義しています。

CIS RAM (Center for Internet Security Risk Assessment Method)

こちら は、サイバーセキュリティ対策のベストプラクティス集である「CIS Controls」に基づいてリスクを評価するための手法です。この評価手法は、「どの技術的対策を、どこまで実施できているか」という技術的な実装状況を起点として実践的なセキュリティ対策とリスクアセスメントを直接結びつけられる点が特徴です。
CIS Controlsで定義されている具体的な対策項目(Safeguards)の導入状況を評価に組み込みます。事業への影響度や脅威の可能性を考慮し、合理的なレベルのセキュリティ対策を判断するのに役立ちます。

COSO-ERMフレームワーク

こちら は、COSO(米国トレッドウェイ委員会支援組織委員会:米国設立の民間部門主導の団体)が発行している、全社的リスクマネジメント(ERM:Enterprise Risk Management)のためのフレームワークです。サイバーセキュリティに特化したフレームワークではありませんが、事業戦略とリスク管理を統合する視点を提供するため、サイバーリスクを経営リスクの一部として位置づける際に非常に有効です。サイバー攻撃を単なるIT部門の問題ではなく、事業継続や財務、評判に影響を及ぼす「全社的な経営リスク」として捉える際に、COSO ERMの考え方が役立ちます。

以下参考

  • Managing Cyber Risk in a Digital Age (COSO)
    COSOが発行した、ERMフレームワークをサイバーリスク管理に適用するための公式ガイダンスです。サイバーリスクを事業リスクとして管理する方法を解説しています。
  • Integrating Cybersecurity and Enterprise Risk Management (ERM) (NIST)
    NISTが発行したレポートで、NISTのサイバーセキュリティフレームワーク(CSF)とCOSO ERMのようなERMを統合する方法について詳しく説明しています。
  • COSOレポートの概要等について
    金融庁検査局の専門検査官(公認会計士)が2005年に公表したもので、COSOが公表した内部統制とリスクマネジメントのフレームワークについて解説しています。
  • Why & How to Incorporate Cyber Risk Management Into Enterprise Risk Management
    病院や医療機関のリーダー層(経営者、理事会など)に向けて書かれたもので、サイバーセキュリティリスク管理を、病院全体の経営リスクを管理するERMの仕組みに統合する理由と具体的な方法を解説しています。どのように(How)統合するのかについては、
    • 意識改革
      サイバーリスクを技術用語(ex.脆弱性, マルウェア)で語るのではなく、ビジネス用語(ex. 手術の遅延, 罰金)に翻訳して、理事会や経営層と議論する。
    • 体制の構築
      IT部門だけでなく、臨床部門、法務、財務、広報など、部門横断的なリスク管理委員会を設置する。
    • フレームワークの活用
      NIST CSF(サイバーセキュリティフレームワーク)やCOSO ERMといった既存のフレームワークを活用し、リスクの特定、評価、対応のプロセスを標準化する。

 が挙げられています。

フレームワーク:Biz×Tech 融合フィールド

最後にビジネスとテクノロジーの中間に位置するフレームワークになります。

SSVC

こちら は、 脆弱性への対応の優先順位付けを決定する ためのフレームワークです。SSVC (Stakeholder-Specific Vulnerability Categorization) は、CVSSスコアのように単一の数値で評価するのではなく、意思決定ツリーを用いて、脆弱性ごとにとるべき行動を Track(追跡), Track*(深い追跡), Attend(注意), Atc(行動)の4つのカテゴリのいずれかに分類します。

詳細は 弊社FutureVuls Blog へ
SSVCにおける Human Impact 決定方法例
SSVCを使いこなそう 〜CISA × CERT/CCが提案する効率的な優先度付けフレームワーク〜

1. 損失イベントの発生頻度 (Loss Event Frequency)
脅威がどのくらいの頻度で発生し (Threat Event Frequency)、それが自社の弱点に接触し (Contact Frequency)、攻撃が成功する (Probability of Action) のかなどを分析します。これはALEのARO (年間発生率) をより詳細に分析するプロセスに相当します。

2. 損失の大きさ (Loss Magnitude)
インシデントが発生した場合に、どのような損失(直接的・間接的)が出るのかを分析します。これはALEのSLE (1回あたりの損失額) をより詳細に分析するプロセスに相当します。

脆弱性関連フレームワークの違い

CVSS SSVC
目的 脆弱性の技術的な深刻度を数値で評価 脆弱性への対応の優先順位を決定
評価対象 脆弱性そのものの特性 脆弱性に加え、組織への影響など
アウトプット 0.0~10.0までのスコア 具体的な行動指針
視点 定量的
普遍的・技術的
定性的
組織固有の状況を考慮

FAIR(Factor Analysis of Information Risk)

こちら は、サイバーセキュリティなどの情報リスクを金額(ドルや円)で定量的に評価するための国際標準の思考モデルで、CRQ(Cyber Risk Quantification)の一般的な算出方法の1つです。リスクを闇雲に見積もるのではなく、「リスクとは何か」を構成要素にまで細かく分解し、それらを論理的に積み上げて評価します。

「高・中・低」といった曖昧な表現ではなく、「このリスクによる年間の予想損失額はX円です」のように、ビジネス上のインパクトを具体的な金額で示すことを目的としています。FAIRでは、以下のようにリスクを大きく2つの要素(LEFとLM)に分解し、それぞれにおいてさらに要素分解して具体的に値を算出していきます。

image.png

OWASP SAMM (Software Assurance Maturity Model)

こちら は組織のソフトウェアセキュリティ体制の 成熟度モデルフレームワーク です。組織がセキュリティ活動を評価し、改善していくための戦略的な指針を提供します。5つのビジネス機能と各機能にぶら下がる3つのセキュリティプラクティスで構成されています。評価は、この合計15のセキュリティプラクティスに対して行われます。

OWASP-SAMM-model-800.png

フレームワークの行き着く先は DOMAIN SPECIFIC

個人的には、サイバーセキュリティ特化のフレームワークを経営のフレームワークに取り込むには 業界ドメイン知識 が不可欠であると考えています。今はまだ融合過渡期ですが、将来的には各業界におけるビジネスとテクノロジー融合フレームワークができると思っています。(すでに自動車業界では、課題はあるものの “TARA” というフレームワークを自動車製造現場で活用しようという動きが見られます)

逆に言うと、ドメイン知識なしに融合は図れないため、全業界横断的な画一的なフレームワークは実現しえない。ビジネスは変数が多く、どこに何が紐づくか、要するにどのような意味を持ったデータなのかはドメイン固有の問題であり、これを共通化や統一することは不可能であるという見方をしています。

ビジネスの切り口は様々で、製造業・金融業などといった事業内容でカテゴリ分けすることもできますし、サプライヤーモデル・ライセンスモデル・人的資本モデル・知財展開モデル・仲介投資モデルなどビジネスモデルでカテゴリ分けすることも、さまざま可能だからです。ビジネスはその国特有な文化的背景も考慮しないとなりませんしね。まとめると以下が主な理由になります。

  • リスクのコンテキストが全く異なる
  • 準拠すべき法規制と監督官庁が異なる
  • バリューチェーンとビジネスモデルが異なる

方法論 -Methodology-

OWASP Risk Rating Methodology

こちら は、 ウェブアプリケーションに存在するセキュリティ上の脆弱性が、ビジネスにどれほど深刻なリスクをもたらすかを評価するための、世界標準のフレームワークです。DREADモデルよりも客観性と具体性が高く、セキュリティの専門家の間では非常に優れた方法論として知られ、デファクトスタンダード(事実上の標準)と見なされています。
詳細は 弊社FutureVuls Blog:OWASP Risk Rating Methodologyについて -リスクの判断-

OWASP Threat Dragon

こちら は、アプリケーションやシステムの設計段階でセキュリティ上の脅威を特定し、対策を検討するためのOWASP提供の無料OSSツールです。システムの設計図を描きながら、どこにどのような危険が潜んでいるかを洗い出すため支援し、選択したコンポーネントに応じて、想定される脅威を自動で提案してくれる機能があり、分析作業を効率化します。

STRIDE

こちら は、Microsoftが提唱した 脅威モデル化の方法論 で、システムの設計段階で脅威を洗い出すために使われます。非常によく用いられるため、各々の用途に特化した亜種が複数存在します(後述)。東京都産業労働局でも中小企業向けに 紹介 しているようです。
STRIDEは以下の6つの観点からシステムに潜むリスク(脅威)を分析します。

評価項目 具体例
Spoofing (なりすまし) 攻撃者が正規のユーザーや別のシステムになりすまして、不正にアクセスする
Tampering (改ざん) 攻撃者がネットワークを流れるデータや、データベースに保存されている情報を不正に書き換える
Repudiation (否認) ユーザーが「自分はその操作をしていない」と、行った行為を後から否定できるようにしてしまう
Information disclosure(情報漏洩) 本来アクセスが許可されていないユーザーに、個人情報や機密情報が閲覧されてしまう
Denial of Service (サービス拒否) 大量のアクセスを送りつけるなどして、システムを停止させ、正規のユーザーがサービスを使えないようにする
Elevation of Privilege (権限昇格) 一般ユーザー権限しか持たない攻撃者が、何らかの不具合を悪用して、管理者権限などを奪取する

STRIDEは、システムアーキテクチャ(ex.DFD)を見ながら以下のステップで活用するのが一般的です。

  1. システムの理解と分離
    • どのような利用者がいるのか
    • どのような処理が行われるのか
    • データはどこに保管されるのか
    • コンポーネント間でどのようにデータがやり取りされるのか
  2. 脅威の洗い出し
    ステップ1での各要素に対してSTRIDEの6カテゴリを当てはめてどのような脅威がありうるかをブレインストーミングします。
  3. リスクの評価と対応
    洗い出した脅威に対して、その発生可能性や影響度を評価し、どの脅威から対処すべきか優先順位をつけます。そして、リスクを低減するための具体的な対策(ex. 多要素認証の導入、入力値の検証強化、ログの取得徹底)を検討し、設計に反映させます。それぞれの脅威が「どれほど危険か」を定量的に評価する手法として、DREAD モデルが知られていますが、評価者の主観に依存する部分が大きいため、現在ではより客観的な評価が可能なCVSS (共通脆弱性評価システム) などが使われる場面も増えています。

STRIDE-per-Element

こちらは、DFDの各構成要素から脅威を洗い出す方法です。まず、システムの構成についてDFDを作成し、構成要素を特定し、すべての要素に対してSTRIDEに当てはまるか判断して各要素についてリスクを洗い出しメトリクスにまとめていきます。要素としては主に以下が挙げられます。

  • 外部エンティティ
  • プロセス
  • データフロー
  • データベース

STRIDE-per-Interaction

こちらは、DFDの中から信頼境界(管理している組織やインターフェイスが変わる境界線)上の脅威を洗い出す観点で実施する方法です。信頼境界を既存のDFDに書き込み、信頼境界と交差するデータフローを特定し、それぞれについてSTRIDEに当てはまるかどうかを判断します。

参考) STRIDEの変化形とセキュリティ要件で導き出す脅威分析手法 FFRI:詳細記載あり

STRIDE-LM

近年では、従来のSTRIDEに加えて水平展開の概念も取り入れて評価すべきという理由から STRIDE-LM が提唱され始めています。先ほどの6項目に加え、下記が加わります。

Lateral Movement:
Lateral Movement involves moving laterally within a network or system to gain access to additional resources or data. This can occur through various means, such as exploiting vulnerabilities in network protocols or using stolen credentials.

STRIDE-LM can help identify potential vulnerabilities related to each of these threat categories by analysing processes and identifying potential security issues. This can help organizations take a proactive approach to cybersecurity and reduce the risk of security incidents.

参考) CyberAgentの記事:上記執筆にあたり有益な情報を提供いただき感謝しています
https://www.iriusrisk.com/threat-modeling-methodologies

PASTA(Process for Attack Simulation and Threat Analysis)

こちら は、STRIDEが「この設計でどんな悪いことが起こりうるか?」という 技術中心 のアプローチであるのに対し、PASTAは「このビジネスにおける最悪の事態は何か?」という ビジネス中心 からスタートします。

PASTAは以下の 7ステップ でリスク分析を行います。

特徴としては以下が挙げられます。

  • リスク中心のアプローチ
    ビジネス上の目的や資産価値を最初に定義し、それに紐づく脅威とリスクを評価します。
  • 攻撃者の視点を重視
    攻撃者がどのように考えるかをモデル化し、攻撃シミュレーションを通じて、現実的な脅威シナリオを洗い出します。
  • コンプライアンスとの整合
    ビジネス要件からスタートするため、業界の規制やコンプライアンス要件(例: GDPR, PCI DSS)と連携させやすい特徴があります。

TRIKE(Threat and Risk-driven Intelligence-based Kill-chain for Embedded systems)

こちら は、前述の2つの手法(STRIDE系とPASTA)とは異なり、リスクベースでセキュリティ監査プロセスに取り組むように設計された、OSSの脅威モデリングプロセスです。他の多くの手法が「攻撃者が何をできるか」という視点から脅威を洗い出すのに対し、TRIKEは「このシステムが持つべきセキュリティ要件は何か」「どこまでのリスクなら許容できるか」というアプローチであるのが最大の特徴です。こうすることで、各資産にリスクレベルを割り当て、そのレベルがステークホルダー(利害関係者)にとって許容可能であることを保証します。

TRIKEのプロセスは、主に2つのモデルを作成し、それらを突き合わせることで進行します。

  • 要求モデル (Requirements Model):システムが どうあるべきか を定義
    このモデルは、システムのセキュリティ要件そのものを表します。
    • 資産 (Assets)
      保護すべき対象(例: 顧客情報、商品マスター)を定義します。
    • アクター (Actors):システムと対話する人や外部システム(例: 一般ユーザー、管理者、決済システム)を定義します。
    • アクション (Actions):アクターが資産に対して何を行うか(作成:Create, 読取:Read, 更新:Update, 削除:Delete)を定義します。
    • リスク許容度:上記の各アクションに対して、ステークホルダーが許容できるリスクレベルを5段階評価などで設定します。
  • 実装モデル (Implementation Model):システムが 実際にどう作られているか を可視化
    • データフロー図 (DFD): システムのコンポーネント(プロセス、データストア等)と、それらの間のデータの流れを図で表現します。これにより、システムのアーキテクチャが明確になります。

OCTAVE Allegro(Operationally Critical Threat, Asset, and Vulnerability Evaluation )

こちら は、組織が情報セキュリティのリスクを評価・管理するために、カーネギーメロン大学のCERT/CCによって開発された手法です。組織がデータ、人、機器などの包括的な資産セット全体にわたって情報セキュリティリスクを特定し、優先順位を付けるのに役立つように設計されています。

自己主導型のアプローチを採用しており、従業員(管理部門と運用部門)が全体的なセキュリティ戦略の策定に責任を負うため、基本的に中小企業向けのアプローチとなります。規模に応じて複数種類がありますが、Allegro は original と -S をうまくマージし、より合理的かつ効率的にリスク評価を行えるように改良されたバージョンです。下記が特徴として挙げられます。

  • 資産中心のアプローチ
  • 包括的な評価範囲
  • 規模に応じた柔軟性と効率性

EPSS (Exploit Prediction Scoring System)

こちら は、特定の脆弱性が今後30日以内に悪用される確率を0%から100%(または1~10)のスコアで予測する、データ駆動型のアプローチです。まだ悪用は確認されていないものの、将来的に攻撃対象となる可能性が高い脆弱性を特定し、プロアクティブな(先を見越した)対応を可能にすることを目的としています。従来の CVSS が脆弱性自体の「技術的な深刻度(例:攻撃が成功した場合の被害の大きさ)」を評価するのに対し、EPSS は「悪用される可能性」という脅威の側面に特化しています。
詳細は FutureVuls Blog:EPSS入門:脆弱性管理を変革する新指標の理解と活用方法

ナレッジベース系

情報セキュリティ10大脅威

こちら は、前年に発生した社会的に影響が大きかったと考えられる情報セキュリティにおける事案から、IPAと10大脅威選考会が協議し、決定した脅威の一覧です。

OWASP TOP10

こちら は、Webアプリケーションにおける最も重大なセキュリティリスク10項目を定期的に発表している標準リストです。非常に有名で影響力が大きく、多くの企業のセキュリティ基準や脆弱性診断のベースとなっています。

MITRE CWE(共通脆弱性タイプ一覧)

こちら は、ソフトウェア業界全体で共有されている国際標準的な脆弱性種類の一覧です。プログラム上の「なぜ」脆弱性が生まれるのか、その原因(バグの種類)を分類したものです。CWEは、インシデントを引き起こす根本的な “設計ミス” や “コーディングの癖” のパターンをまとめた知識ベースであり、ソフトウェアを安全にするための土台となります。脆弱性診断の結果を理解する上で必須の知識です。

CVE(共通脆弱性識別子)

こちら は、個々の製品で見つかった、特定の脆弱性(セキュリティ上の欠陥)に与えられる、世界共通の固有番号です。研究開発者へおすすめな 外部リソース もまとめてくれています。

KVE(Known Exploited Vulnerabilities)

こちら は、実際に悪用が確認された脆弱性のリストです。米国のサイバーセキュリティ・社会基盤安全保障庁(CISA)が管理・公開しており、「KEVカタログ」として知られています。膨大な数の脆弱性の中から、攻撃者に現実に狙われている「今すぐ対応すべき最も危険な脆弱性」を特定し、組織が迅速に対策を講じることを支援することが目的です。特徴としては、以下が挙げられます。

  • 実績ベース
    リストに掲載されているのは、理論上の危険性だけでなく、実際に攻撃コードが存在し、悪用されていることが確認された脆弱性に限定されます。
  • 高い優先度
    KEVに掲載された脆弱性は、対応の優先度が極めて高いと判断されます。米国の連邦政府機関に対しては、CISAが定める期限内に修正プログラム(パッチ)の適用などが義務付けられています。

MITRE ATT&CK

こちらは、脅威分析の中の攻撃手法に特化した体系知識を提供してくれるナレッジベースです。ATT&CK は “Adversarial Tactics, Techniques, and Common Knowledge” の略です。
セキュリティ界隈では “超有名” なサイトですが、使い方がいまいち分からん!という方へ下記にまとめてみました。

ユースケース

1)サイトへアクセス
今回は Enterprise 用のサイトに絞ってみていきます。まず、ATT&CK Navigator へ飛びます(下図赤枠クリック)

image.png

攻撃対象のカテゴリと好みのUIを選びます。
ここでは、ほぼデフォルトで [Create New Layer] > [Enterprise] を選択し下記に飛びました。
image.png

2) フィルタリング項目
フィルタリング項目は右ペインの一覧に列挙されています。
image.png
2025年8月現在は全7項目あります。文字通りの項目は説明を割愛しますが、おおよそ意味は以下の通りです。

  • Techniques(攻撃テクニック)
  • Thread Groups(攻撃グループ)
  • Software(攻撃対象ソフトウェア)
  • Mitigations(緩和策)
  • Campaigns(キャンぺーン)

特定の目的をもって、一定期間に行われた一連のサイバー攻撃活動のまとまり
多くの場合、 Thread Groups と関連づけられています。

  • Assets(資産)
    主に産業用制御システム(ICS)環境下で観測される攻撃標的となりうる物理デバイスやシステム
    ATT&CK for ICS という工場やプラント向けのフレームワークで特に重視されるため、ここで掲載している Enterprise では数としては “Assets(0)” となっていますが気になる方は ICS 要のページで閲覧すると該当数が異なると思います。
  • Data Sources(データソース)
    攻撃者の Technique を検知するために、組織が収集すべきログや情報の種類
    防御側が「何を見れば」攻撃の痕跡を見つけられるかを示したリストです。これは非常に便利ですね!

各項目でヒットさせたい条件を detect してアンド条件を指定していきます。指定後は青枠で囲われた状態になります。各項目にカーソルをあてると、該当する攻撃手法がハイライトされます。ここでは、よく知られている攻撃グループ(ハッカー集団)に注目してみました。(ふむふむ、なんだか動物の名前が多い気が…

image.png

3)詳細情報へ
Fox Kittenという攻撃グループはどんな集団なのか気になった場合は [view] をクリックして詳細ページを見ることができます。他の項目それぞれにおいても同様に各詳細情報を閲覧することが可能です。

image.png

MITRE D3FEND

こちら は、世界中のセキュリティ専門家に利用されている攻撃技術のフレームワーク『MITRE ATT&CK®』と対をなす存在で、ATT&CKが「攻撃者の手法(TTPs)」を体系化しているのに対し、D3FENDは「防御側の対抗策(Countermeasures)」を体系化しています。特定の攻撃テクニックに対して、どのような防御技術が有効かをマッピングできます。D3FENDは 比較的新しいプロジェクト で、MITREによるとまだ実験段階とのことですが、ATT&CKフレームワークと組み合わせてセキュリティ可視性要件の優先順位付けに活用することができると考えられます。

D3FENDの最大の特徴は、防御技術が独自の『防御マトリクス(Defensive Matrix)』によって分類・整理されている点です。マトリクスは、防御活動の目的別に大きく分類されています。

The D3FEND matrix categorizes countermeasure techniques into five stages of defense:

Harden – application hardening, platform hardening, credential hardening, message hardening
Detect – network traffic analysis, process analysis, file analysis, platform monitoring, identifier analysis, message analysis, user behavior analysis
Isolate – network isolation, execution isolation
Deceive – decoy environment, decoy object
Evict – credential eviction, process eviction

引用)MITRE ATT&CK & D3FEND: Step-by-Step Guide to Closing Security Visibility Gaps

ユースケース

1)特定の「攻撃手法」から防御策を探す
D3FENDの最も強力な使い方は、特定の攻撃手法(ATT&CK ID)から、それに対応する防御策(D3FEND ID)を逆引きすることです。

D3FEND公式サイト 左側検索窓から対策したい攻撃(今回は「Kerberoasting」とする)を入力すると、ATT&CKの攻撃ID「T1558.003」がヒットします。
image.png
ATT&CK公式サイト からも検索できます。
image.png

そのまま D3FEND の検索結果ページを開くと、この攻撃(T1558.003)に紐づく防御技術(D3FEND Countermeasure)がリストアップされます。これは、D3FENDが自動的に推測(infer)した、防御技術同士の隠れた関連性のことです。MITREが防御策と防御策の関連性を定義したものではなく、攻撃(ATT&CK)と防御(D3FEND)の膨大なマッピングデータを分析した 結果、防御技術のブロックしている 攻撃対象の類似性から実質的に関連性が高いだろう(推論) とAIやシステムが提示した関係を示しています。

kerberoasting.png

ある防御策が、直接の目的以外に「どのような攻撃手法にも間接的に効果があるか」という隠れた関係性が分かりますが、その関係性の数は膨大になるため、関係しないnodeを非表示にすることで把握しやすいUIになっています。

Detect & Restore Hardening & Isolation & Restore
relationship_01 Hardening & Isolation & Restore

上記マッピングを活用することで、下記を把握することが可能です。

  • 防御策の費用対効果
    たった一つの防御策(UACの有効化)で多様な攻撃の芽を摘む可能性があることを可視化できます。これにより、セキュリティ投資の優先順位付けがしやすくなります。
  • 防御の網羅性
    自分たちが導入している防御策が、想定していなかった攻撃経路に対しても有効である可能性に気づけます。「この対策は、あの攻撃にも効いていたのか!」という発見があります。

2)防御の「目的」から探す
防御マトリクス(Defensive Matrix)を選択すると、D3FENDの防御技術が Model / Harden / Detect / Isolate / Deceive / Evict と分類されて表示されるため、目的に応じた防御技術を選定することが可能となります。例えば、AD要塞化をしたいとなった場合、「Harden(要塞化)」に注目して目的に沿った 直接関連する多くの防御技術を俯瞰 することができます。

image.png

こちら では、ATT&CK or D3FEND に掲載されている緩和策それぞれに対し、より具体的にどんな防御テクニックがあるのかをマッピングしてくれています。より多層的で抜け漏れの少ない(MECE)防御策を立案するのをサポートしてくれます。

image.png

このように、なぜこの設定強化が必要なのか を攻撃手法とセットで理解でき、かつ、より具体的な対応まで落とし込めるため、単なるチェックリストをこなすよりも はるかに効果的で説得力のある堅牢化計画 を立てることができます。

情報資産/脅威/脆弱性 の評価 -アセスメント要素の具体化-

上記フレームワークは大枠を示すものの、定量評価するにあたっては、各要素(変数)の定義を定めて具体的に算出していきます。各要素の算出方法は時代とともに変化し、どのように表現されるかも変わりますので画一的な式は存在しません。用途とフェーズに応じて各種式を使い分けていきます。

ここに関しては、リスクをどう因数分解するのか、考慮すべき要素に何を指定するのかなど複雑かつ膨大なので、また別記事でご紹介したいと思います。

リスクの算定 -構築モデルの評価-

可視化したリスクの算定プロセスをモデル化したのち、そのモデルの妥当性を検討する必要があります。検討すべきは2点、正当性の評価妥当性の評価 を行います。前者は理論的に正しいのかどうか、後者は実証実験にて実際の結果からモデルを評価します。

  • 正当性の評価では、モデルの論理的な構造や計算ロジックそのものが、専門家の知見や確立された理論に基づいて正しく構築されているかを検証します。これはデータを用いたシミュレーションを行う前の、いわば設計図のレビュー段階です。
  • 妥当性の評価では、多量変数それぞれに不確実性、つまり分布があり、それらのランダムな組み合わせを発生させて最終的に1つの指標で確率分布を求めたいので、モンテカルロシミュレーションを用います。

モンテカルロシミュレーションとは

未来の予測が難しい不確実な事象についてコンピューター上で何度もランダムな試行を繰り返すことで、その結果がどうなるかの確率を求める手法です。結果が一意に決まらない様々な分野で応用される基本ツールです。

リスク対応の決定と報告 -4つの決め方-

リスクが可視化できたら、次はいよいよ「どうするか」を決める意思決定のフェーズです。ただ闇雲に対策するのではなく、ここでも合理的な選択肢が存在します。大きく分けて、以下の4つの対応方針があります。

  1. リスク低減 (Mitigation)
    セキュリティソフトの導入、社員教育の実施、システムの暗号化など、リスクの発生確率や影響度を下げるための対策を講じる、最も一般的なアプローチです。
  2. リスク回避 (Avoidance)
    リスクの原因となる活動そのものを止めるという選択。例えば、特定の信頼できないWebサービスの利用を全面的に禁止する、といった判断です。
  3. リスク移転 (Transfer)
    自分たちだけでリスクを抱え込まず、第三者と分担する方法です。代表的な例が、サイバー保険への加入です。万が一の際の損害を保険でカバーしてもらいます。
  4. リスク受容 (Acceptance)
    リスクによる損失が許容範囲内である場合や、対策コストがリスクの大きさに見合わない場合に、あえて「何もしない」という意思決定をします。すべてのリスクをゼロにすることは不可能であり、これもまた合理的な判断の一つです。

企業は、可視化されたリスク一つひとつに対して、「対策コスト」と「得られる効果(リスクがどれだけ下がるか)」を天秤にかけ、この4つの選択肢の中から最適な組み合わせを選び、実行していくのです。

まとめ:不確実な未来を乗りこなすための思考法

今回は、サイバーセキュリティの世界におけるリスクとの向き合い方についてご紹介しました。

重要なのは以下です。

  1. 漠然とした不安や期待を、具体的な要素に最大限分解して リスク因子を「可視化」する こと
  2. それぞれの要素に対し、リスクがどの程度存在するのか算出する こと
  3. 可視化されたリスクに対して、 複数の選択肢の中から最適な「決め方」を選ぶ こと

100%成功する選択というものは存在しません。しかし、リスクの正体を知り、それとどう向き合うか、時には未来予測シミュレーションなどを取り入れて真剣に考えることで、私たちはより後悔の少ない、納得感のある意思決定を下すことができます。

悩んだときは、上記を応用して物事を進めていけるといいですね✨