脅威モデリング (Threat Modeling)について

脅威モデリング (Threat Modeling)とは?

脅威モデリングは、設計対象のシステムやソフトウェアに関するセキュリティ上の脅威を明確にし、抽出した脅威に対する対策を考えるために利用します。設計の上流工程など早い段階で行うことで、脅威に対する対策を機能要求や非機能要求として抽出し、設計に反映します。

セキュリティ上の脅威を明確にしないまま設計・実装を進めてしまうと、攻撃者は容易に設計対象のシステムやソフトウェアにアクセスし、攻撃者にとって価値のある資産を取得できます。設計や実装が進んだ段階、あるいは製品のリリース後に問題が発覚した場合、その対処には多くの工数がかかることが多く、場合によっては設計を根本的に見直す必要があるかもしれません。それだけでなく、取得された情報が例えば個人情報であれば、関係者への対応にも多くのリソースを要しますし会社の信頼を大きく損ねることになります。

実際に何らかのセキュリティ上の問題が発生した場合も、攻撃経路などが明確になっていなければ場当たり的な対応となり、攻撃を完全に防ぐことは用意ではありません。すでに攻撃されてしまっている状況で短時間で確実な対策を行うためには、事前にどのような構成になっているかを、設計の観点ではなくセキュリティの観点で明確にしておかなければなりません。

一方で、最近はインターネットに接続する製品が多く、攻撃者が侵入する経路が存在する点が以前とは異なります。例えば、火災報知器やスプリンクラーなど、以前は通信機能を持たず独立した機器であれば、実際に設置している場所に物理的に侵入する必要がありますし、何も永続的な情報を持たないのであれば何も価値がないこともあるでしょう。しかし、例えばスマートフォンから動作状況や故障の有無を確認できるようにすると、その情報のやりとりのための通信経路は攻撃のための経路になる可能性があり、また外部から火災報知器やスプリンクラーを誤動作させて混乱させることも可能となるかもしれません。OTAと呼ばれるソフトウェアの更新の仕組みがあると、悪意を持ったソフトウェアで更新させられ、自由に制御することも可能となるかもしれません。

通常の機能を中心とした設計では、こうしたセキュリティ上の脅威は考慮されないか、部分的にしか考慮できてないことが多いです。また、一般的な製品テストは、バグを検出することは可能ですがセキュリティ上の脅威を検出することは困難です。脅威モデリングを行うことで、ユースケースや機能といった通常の設計とは異なる観点で、セキュリティ上の脅威を網羅的に名確認することが可能となります。

なお、考慮すべき脅威は、守るべき資産を奪われるという脅威だけとは限りません。例えば、DDOS攻撃でシステムをダウンさせることは、守るべき資産を奪われることにはなりませんが、システムの利用者に不便が生じ、対外的なシステムであれば会社の信頼を損ねるものとなるでしょう。

Enterprise Architectの対応

Enterprise Architectでは、脅威モデリングを行うためのプロファイルを提供しています。全てのエディションで利用できます。このプロファイルを利用する場合には、対象のシステムと守るべき資産の明確化をまず行い、次に脅威を考え、最後にその対策を考えます。

なお、この驚異モデリングを行うためのプロファイルの内容は英語です。Enterprise Architectのバージョン15.2 ビルド1560以前をご利用の方は、このページの内容を試す前にこのページ末尾の更新ファイルの適用をお願いします

利用手順

Enterprise Architectでは、脅威モデリングを行う場合の手順を示します。

まず、利用するプロジェクトを開くか、新規にプロジェクトを作成してください。作成後に、パースペクティブを「脅威モデリング」に設定します。Enterprise Architectの画面の右上にある「パースペクティブ」ボタンを押し、「システムズエンジニアリング」→「脅威モデリング」を選択してください。

パースペクティブを選択すると、自動的にモデルテンプレートタブが表示されます。モデルテンプレートの追加の画面でテンプレートが1つ表示されます。
(もし、ここでテンプレートが何も表示されない場合には、「脅威モデリング」が有効になっていない可能性が高いです。「アドイン・拡張」リボンの「MDGテクノロジー」パネル内の「設定」ボタンを押すと表示される画面で「Cyber Security Modeling」にチェックを入れて有効にしてください。)

このテンプレートはサンプルとなるモデルを含んでいます。今回は、このテンプレートを利用して説明します。Enterprise Architectの画面で直接サンプルモデルを見る場合には、一覧でテンプレートを選択後、モデルテンプレートタブ内の左下にある「テンプレートの読み込み」ボタンを押してプロジェクトに読み込んでください。

対象のシステムと守るべき資産の明確化

まず、対象のシステムと守るべき資産の明確化を行います。サンプルでは、以下のような図で表現している内容です。

新規にダイアグラムを作成し、以下の要素を利用して対象のシステムやソフトウェアに関係する構成要素をツールボックスからドラッグ&ドロップで配置してください。

外部システム
(External System)
設計対象のシステムやソフトウェア以外の外部のシステムを示します。
利用者
(Human Actor)
設計対象のシステムやソフトウェアの利用者を示します。
データストア
(DataStore)
設計対象のシステムやソフトウェアが扱う、守るべき資産を示します。
プロセス
(Process)
データストアに対する何らかの処理・操作ないしは、その処理や操作をする主体を示します。

また、あわせて信頼境界(Trust Boundary)を利用し、配置した要素がどの境界に属するのかを明確にします。一般的には、上の例のように、少なくとも設計対象のシステムやソフトウェアを示す信頼境界は入れ子になることが多いです。作成する対象のシステムやソフトウェアを示す最も外部の信頼境界の中に、何らかの区切りがある領域を明確にします。例えば、ネットワークを持つシステムを対象とする場合、ファイアーウォールやルーターによって制約があり、直接通信ができないよう場合には、信頼境界が異なるということになります。

データストアは、守るべき資産を示します。資産とは、一般的には個人情報のように外部からの攻撃者にとって価値のある有用・有益な情報を示しますが、情報に限りません。例えば、自動運転の車であれば、その車を外部から操作できることが悪意を持つ人にとっては価値がありますので、車の操作機能ないしは車の操作権限は守るべき資産といえます。永続的なデータだけでなく、キャッシュなど一時的なデータも該当します。

この段階では、設計対象のシステムやソフトウェアのすべてを表現するのではなく、あくまでもセキュリティ上の脅威を明確にするために必要な内容・必要な観点で構成します。データストアも、設計対象のシステムやソフトウェアが扱うすべての情報を表現するのではなく、守るべき資産、つまり外部からの攻撃者にとって価値があり、奪われることで問題となるもののみが対象となります。極論を言えば、設計対象のシステムやソフトウェアが扱うデータに守るべき資産が何もなければ、この段階で脅威モデリングは終了となります。
(ただし、データに価値があるかどうかは、「誰にとって」を考える必要があります。ほぼすべての人にとって価値がないとしても、特定の立場の人・特定の用途で有用であれば、それは守るべき資産となります。)

これらの要素を作成後は、通信可能である要素間について、配置した要素間をデータフローで結びます。データフローで結ぶ際には、ツールボックスから作成する方法だけでなく、Enterprise Architectのクイックリンクの機能が利用できます。データフローのプロパティサブウィンドウの「方向」を指定することで、双方向のデータフローに表現を変えることができます。

ほかに、データフローにはいくつかの情報を設定可能です。データフローの名前は、HTTP・SOAPなど通信方法とする流儀と、実際に流れるデータとする流儀があるようです。通信の種類をプロパティサブウィンドウから設定できますが、これらの設定は図には反映されません。(Wordの仕様書生成の機能で出力するなどの利用方法があります。)

データフローで結んだ結果、外部からのアクセスが可能である経路が明確になります。この段階で、もし外部からのアクセス経路が全く存在しない場合には、この段階で脅威モデリングは終了となります。ただし、明示的・常設のアクセス経路がないとしても、侵入経路がないということではありません。例えば、内部ネットワークに接続するノートパソコンやスマートフォンを持ち運び、外部のネットワークとも接続する運用であれば、脆弱性となり得ます。

脅威の抽出と対策の検討

対象のシステムと守るべき資産の明確化を行った後は、その図に配置された要素に対して、脅威と対策の検討を行います。サンプルでは、以下のような図で表現している内容です。

脅威の抽出は、信頼境界を越えるデータフローについて行います。網羅的に抽出するため、一般的には以下のSTRIDEの観点を利用します。

Spoofing
(なりすまし)
攻撃者が他の誰かになりすます
Tampering
(改竄)
攻撃者がデータを変更する
Repudiation
(否認)
攻撃者が実行・変更などを行ったことを証明できない
Information Disclosure
(情報漏洩)
攻撃者がデータを取得する
Denial of Service
(サービスの拒否)
攻撃者が対象のシステムやサービスを動作不能にする
Elevation of Privilege
(特権の昇格)
攻撃者が特権を得て、特権が必要なデータを見たり操作を実行したりする

Enterprise Architectでは、脅威は以下のような要素で表現し、対象となるデータフローと結びつけます。それぞれのデータフローには上記のSTRIDEの観点で脅威を発見するため、複数の脅威が結びつく可能性があります。また、複数のデータフローに対して同一の脅威が考えられることもあります。

データフローを選択すると表示されるクイックリンクアイコンで脅威を作成することもできますし、ツールボックスから脅威要素を配置後、対象のデータフローと結びつけることもできます。

脅威を図に配置すると、図が煩雑になります。必要に応じて、Enterprise Architectのフィルタの機能を利用し、図の内容を調整すると良いでしょう。例えば、「ダイアグラム」リボン内の簡易ダイアグラムフィルタの機能を利用する場合に、脅威要素をフィルタする場合の設定は以下の通りです。フィルタとレイヤーサブウィンドウからフィルタ効果を調整することで、脅威要素を非表示にすることもできます。

対策の検討

抽出した脅威に対して対策リストを結びつけ、どのような対策を行うかを明確にします。

まず、新規にダイアグラムを作成し、脅威と結びついているフローにつながる要素と脅威要素を配置します。前工程の図で要素を選択してCtrl+Cを押し、新しく作成した図にCtrl+Vで貼り付けます。この操作により、同じ要素を複数の図に配置することができます。要素の名前などの変更は両方の図に反映されます。また、「利用されているダイアグラム」機能 (ショートカットキー: Ctrl+U)で、すべての配置されている図を探索し、簡単に他の図に切り替えることができます。次の例のようにEnterprise Architectのレーンの機能を利用して分類・整列することもできます。また、この例では、脅威の詳細情報をダイアグラム内で表示しています。

脅威にはいくつかのプロパティがありますが、特に優先度が重要です。また、脅威についての対策を検討したかどうかの「状態」も設定できます。「Not Started」(未着手) が初期値です。「Needs Investigation」(要調査) は検討のための調査が必要な状態です。「Mitigated」(緩和)は対策可能で緩和できた状態です。「Checklist」は、結びつく緩和チェックリストで対策の洗い出しができたことを示し、多くの脅威についての最終状態です。

脅威が明確になった後は、その対策を検討します。緩和チェックリスト要素を新規に作成し、脅威に結びつけて対策を記入します。対策が困難である場合には、その脅威を受容せざるを得ない場合もあるでしょう。検討の過程や根拠などは、Enterprise Architectで利用できるフォルトツリー解析(FTA)アタックツリー解析GSNなどさまざまな表記方法を利用することで、図として表現することもできます。

脅威に結びつく対策は、設計に対して機能要求や非機能要求として明示され、設計・実装されることになります。あるいは、その対策を実行する設計要素に結びつけることもできます。これらの情報はツール内で結びつけを行い、トレーサビリティを確保します。


(拡張マトリックスアドインで脅威を表示する場合には、設定ファイルに「要素,脅威,Requirement,threat」を追加してください。)

Enterprise Architectで脅威モデリングをするメリット

脅威モデリングは、他の様々な作図ツールでも作成可能です。Enterprise Architectで脅威モデリングをするメリットは以下の通りです。

  • 図で書いた内容を一覧表示することで、図とは異なる観点で内容の確認や利用が可能
    (脅威の属性を一覧に追加したり、ソート・フィルタしたり、印刷したり、CSVでコピーしたりすることができます。一覧で内容を編集した場合、関係するすべての図に自動的に反映されます。)
  • 独自の検索ルールを作ることで、モデル内の情報を簡単に検索し、検索結果から図に移動可能
  • マトリックス機能で、関係の把握・漏れ抜けの確認が可能
  • Wordの仕様書生成の機能で、作成した内容からドキュメントを生成可能
  • フォルトツリー解析(FTA)アタックツリー解析GSNなどさまざまな表記方法も利用し、作成した驚異モデリングの内容の根拠や対策などを表現可能
  • SysMLやUMLなどの設計に関する表記方法を利用し、抽出した対策に関係する内容についてトレーサビリティを設定し、もれなく設計に反映できているか確認可能
  • チャート要素を利用し、さまざまな情報を視覚化可能

    (この例は、チャート要素の条件としてカスタムSQLを選択し、「SELECT t.[Value] AS Series FROM t_object o, t_objectproperties t WHERE t.[Property] = 'Type' AND t.Object_ID = o.Object_ID AND o.Stereotype = 'threat'」を設定しました。

さいごに

脅威モデリングは、1回のみ行えば問題ないということはありません。前述のように、設計の早い段階で実施することが必要ですが、その後の工程でも折に触れて内容を見直し、前提となる要求や設計・構成に変化がないか、新たな攻撃手段などが広まっていないか、などを確認することが必要です。もし変更が発生する場合には、モデリングツールで他の設計情報とトレーサビリティを確保しておけば、影響を与える範囲を明確にすることができますので、変更を確実に設計に反映させることができます。

脅威モデリングの追加ファイル

Enterprise Architect 15.2 ビルド1560以前のバージョン・ビルドでは、脅威モデリングに関連するファイルが古く、またツールボックスなどの表示の一部が英語表示となります。

以下のZIPファイルをダウンロードし、ZIPファイル内のそれぞれのファイルについて、インストールディレクトリ内の同名のファイルを上書きしてください。
ThreatModelingFiles.zip

  • インストールディレクトリ内の「metatypes.xml」
  • インストールディレクトリにあるMDGTechnologiesディレクトリの「CyberSecurityModeling.xml」
  • インストールディレクトリにあるModelPatternsディレクトリの「cs1.3-threat-multiple-boundaries.xml」