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

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

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

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

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

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

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

Enterprise Architectの対応

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

脅威モデリングの概要(動画デモ)

ツールを利用した脅威モデリングの概要と、Enterprise Architectで脅威モデリングを利用する際の価値の1つであるトレーサビリティについて動画で説明しています。(13分5秒・音声あり)

利用手順

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

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

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

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

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

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

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

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

また、あわせて信頼境界(Trust Boundary)を利用し、配置した要素がどの境界に属するのかを明確にします。一般的には、上の例のように、少なくとも設計対象のシステムやソフトウェアを示す信頼境界は入れ子になることが多いです。作成する対象のシステムやソフトウェアを示す最も外部の信頼境界の中に、何らかの区切りがある領域を明確にします。例えば、ネットワークを持つシステムを対象とする場合、ファイアーウォールやルーターによって制約があり、直接通信ができないよう場合には、信頼境界が異なるということになります。信頼境界は、後述する「脅威一覧の出力」アドインが有効になっている場合には、SysML 1.5のブロック要素をモデルブラウザからドロップすることでも作成できます。また、プロパティdashedおよびfilledの値を変更することで、境界線を点線表示にしたり、内部を塗りつぶし表示にしたりできます。

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

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

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

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

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

脅威の抽出と対策の検討

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

脅威の抽出は、信頼境界を越えるデータフローについて行います。網羅的に抽出するため、一般的には以下の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」を追加してください。)

モデルとして定義した内容は、「脅威一覧の出力」アドインを利用することで、Excel形式で出力できます。

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

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

• 図で書いた内容を一覧表示することで、図とは異なる観点で内容の確認や利用が可能
  (脅威の属性を一覧に追加したり、ソート・フィルタしたり、印刷したり、CSVでコピーしたりすることができます。一覧で内容を編集した場合、関係するすべての図に自動的に反映されます。)
  
• 独自の検索ルールを作ることで、モデル内の情報を簡単に検索し、検索結果から図に移動可能
• マトリックス機能で、関係の把握・漏れ抜けの確認が可能
• WordやHTMLのドキュメント生成の機能で、作成した内容からドキュメントを生成可能
• フォルトツリー解析(FTA)・アタックツリー解析・GSNなどさまざまな表記方法も利用し、作成した脅威モデリングの内容の根拠や対策などを表現可能
• 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回のみ行えば問題ないということはありません。前述のように、設計の早い段階で実施することが必要ですが、その後の工程でも折に触れて内容を見直し、前提となる要求や設計・構成に変化がないか、新たな攻撃手段などが広まっていないか、などを確認することが必要です。もし変更が発生する場合には、モデリングツールで他の設計情報とトレーサビリティを確保しておけば、影響を与える範囲を明確にすることができますので、変更を確実に設計に反映させることができます。