複数名による効率的な脅威モデリングの実践

脅威モデリングをゼロから実践する過程では、多くの課題と向き合うことになるかと思います。弊社では、分析作業を複数人で連携する点において特に大きな課題を感じました。各メンバーが連携し合い、作業を分担して効率的に処理することは、チームで価値を提供する場合には重要な要素かと思います。

本稿では、脅威モデリングの実践における共同作業の課題に関して、その内容と導出した解決策、その活用事例をご紹介いたします。本稿の内容を通じて、脅威モデリングを実践する際の参考になれば幸いです。

ToC

1. 課題
2. 解決策
3. まとめ

課題

脅威モデリングを初めて実践する際、多くの場合では既存の専用ツールを活用するところから着手するかと思います。それら代表的な専用ツールとしては、下記の2つのツールがそれらに該当すると思います。

1. Microsoft Threat Modeling Tool
2. OWASP Threat Dragon

上記2つのツールは、現在無料で入手可能であり、安定して操作できます。しかしながら、複数人で連携して作業を進めるシナリオにおいては、筆者の主観ではありますが当該ツールにはいくらかの煩わしさや非効率さを感じました。以降で、具体的な課題を触れていきますが、内容を補足するため、脅威モデリングの実践における前提要素と各ツールの特徴に触れた後、具体的な課題について説明するという順番で進めていきます。

まずはじめに本稿で取り上げる課題に関係する脅威モデリングの実践における前提事項について確認していきます。

• 脅威の分析の結果は、 DFD などで可視化される成果物の精度に強く依存する
• 分析者と実装・管理者が異なる場合、「周囲メンバーからのレビュー」→「レビュー内容の議論・反映」→…というサイクルが欠かせない

1つ目の依存関係は、脅威モデリングにおける「要素の分解」→「ダイアグラムの描画」→「脅威の分析」という作業行程から自明かと思います。すなわち、脅威の分析はモデリングされたダイアグラムの如何に基づくため、ダイアグラムが「実態と即していない」「抜け漏れがある」ということであれば、それぞれ「実態に即していない結果」「抜け漏れのある結果」という結果が出力されるという具合です。2つ目は、上記で述べるような理由からダイアグラムの精度を高めるための必要条件です。ダイアグラムの精度が分析結果に依存する背景から、抜け漏れや抽象化の粒度などについて注意することが重要となります。というのも、システムの実装・管理者と分析者が異なる場合には、前者が普段から DFD を書き慣れていないために、後者が実際に設計に関与していないためにという具合で、抜け漏れなどのリスクを発生させる可能性があります。以上のように、組織におけるプロダクトを対象として分析評価する時、脅威モデリングを実践する際には周囲のメンバーとの関わりが不可欠であり、個々の作業は前の工程に依存するため個々の作業効率は全体の作業効率に影響します。

次に、課題の原因につながるツールにおけるデータ管理の特徴について触れていきます。さきに紹介したツールは、いずれの場合もローカルで動作し、それぞれ .tm7、 .json のファイル形式でデータはローカルに保存されます。そのため、成果物をメンバーと連携する場合には、データ共有の方法について工夫する必要があります。Threat Dragon では Web サーバとして動作させることも可能ですが、その場合にはサーバの管理など別の運用上の煩わしさがあります。他方、両ツールには、分析した結果を数や概要などについてレポーティングする機能があります。作成されるレポートは、「Spoofingに関する潜在的脅威は xxx 個が確認されました。」や「 yyy の脅威は、 zzz という内容であり、それに対する管理策には sss があります。」という具合に、分析によって詳らかになった内容が PDF の形式で出力されるというものです。

以降では、さきに紹介したツールを利用して脅威モデリングを実践した際、具体的にどのような課題が生じるのかを述べていきます。

1. データに対する修正が直観的でない
   • これは、ツールの特徴で述べたデータ管理に起因した課題です。成果物のアウトプットの精度を高めるため、分析者同士ないしは分析者と実装・管理者が MTG など同期的なコミュニケーションを行う場合、ダイアグラムおよびレポートのデータを修正できるのは、データがローカルで保存される特徴のために基本的に1人となるはずです。そのため、コメントする際には、変更を加えたい内容を言語化する必要があります。ダイアグラムによっては、正確に意図した内容を伝えることは困難な場合があります。また、伝達される側においても同様です。いずれにしても、加えたい変更が操作するメンバーでない場合は間接的になり、面倒です。
2. データの同期が面倒
   • 上記1の課題に対して、各メンバーが手元でデータを修正できれば課題にはなりません。同期のために、データファイルを Github や Google Drive などクラウド上で管理する方法が容易に思いつきます。しかしながら、この運用方法では、1つの変更に対しても大まかに述べても commit、 push 、 pull などの行程を踏む必要があります。変更を加えたいメンバーが当内容を直接変更するというシンプルな工程を期待すると、面倒さを感じざるを得ません。
3. 分析に参加するメンバーの各々でプログラムを実行できる環境を構築するのが負担になりうる
   • メンバー間におけるデータの同期方法が解消されても、そのデータを編集するためには各メンバーの環境下においてツールの動作を担保させる必要があります。特に紹介したさきの専用ツールは、言語設定が英語である点や普段から利用していないために慣れの観点からメンバー全員のツールの動作を担保することには煩わしさがあります。

解決策について

導出した最終的なアプローチは、脅威モデリングの専用ツールで一貫させるのではなく、それぞれの工程に求められる機能を提供する汎用的なツールを選択するというものです。すなわち、それは DFD や Attack Tree などのダイアグラムの作図には Miro もしくは Google Drive と組み合わせた draw.io を、脅威やセキュリティ管理策の列挙には Google Spreadsheet を、レポートには Google Docs を選択するという具合です。

導出した解決策の概要

前項では、従来のツールには、 1 データの編集が直観的でない、 2 データの同期が面倒、 3 動作環境が負担という課題を述べました。解決策として選出したツールの使用方法は、いずれも SaaS としてでありデータはサービスベンダーないしはクラウドストレージ上で管理されます。このような使用方法では、各機能の専用ツールということもあり編集操作は直観的に行うことができ、データの同期の課題も解消されます。また、いずれのツールもブラウザ上でも動作可能なため特別な環境構築は不要です。さらに専用ツールに比較してシンプルな UX な設計や広く利用されているツールであるという点で学習コストは極めて低いです。以降では、それぞれのツールの活用方法について具体的にご紹介します。

Miroまたはdraw.ioを用いたダイアグラムの作図について

まずは、ダイアグラムの作図についてです。Miro は、ビジュアルコラボレーションプラットフォームと紹介されているホワイトボードの SaaS です。オンライン上でリアルタイムにボードを編集できるため、リモート環境下でMTGを実施することが普及した昨今において本サービスを利用している企業や個人は多いと予想します。draw.io は、人によってはより染みのある方が多いサービスかもしれません。 Miro 同様、 draw.io もダイアグラムの作成に特化したホワイトボードのアプリケーションです。 draw.io は、システムのアーキテクチャを作成する際によく使用されるのではないかと思います。いずれのツールも描画することに特化したツールであるため、先に紹介した脅威モデリングの専用ツールと比較するとその操作性はより優れていると感じます。ただし、Miroをブラウザで利用する場合においてシステムのスペックや利用状況次第では、筆者が遭遇したようにフリーズしてしまうことはあるかもしれません。 Miro でも draw.io でも機能面で大きな差はない印象で、弊社ではソリューションを提供する組織側の担当者の好みに合わせて選択するという方針を取っています。

テンプレートによる簡単化

さきに紹介したいずれのツールもホワイトボードの専用ツールということもあり、脅威モデリングを専用にしたツールと比較すると、高い自由度があります。そのため、アナリストの趣味趣向に依らず、チームの成果物に一貫性を持たせるために、私たちはテンプレートを活用してダイアグラムを作図するものと定めました。 draw.io においては、Michael H. によってテンプレートが開発され、それは既に一般利用できる状態になっています。実装の経緯は、ブログ で述べられています。このテンプレートは、 Google Drive や Dropbox などと組み合わせて、ダイアグラムのファイルを管理することで容易にバージョンを管理することでき、先に述べた課題を解決するものでありました。

それに対して、 Miro において私たちが調査していた当時にはそのようなテンプレートはありませんでした。そのため、テンプレートは Miro のカスタムテンプレートとして新たに用意しました。テンプレートの作成に際しては、 Michael 氏のテンプレートを参考にしました。作成したテンプレートは、次の具合です。

概要は次の具合です。

1. インタビューなどに基づいて整理されたシステムを構成する要素をボード上にプロットし、それらのつながりや境界線を記述
2. 各エンティティなどにおける実践されているセキュリティ管理策をラベルを用いてプロットし、その詳細をプロットしたラベルの番号に対応するテーブルに説明
3. どのエンティティにどのようなアセット（データ）が管理されているのかを可視化するためラベルをエンティティにプロットし、その詳細をテーブルの対応する番号に対応するテーブルに説明

作成したMiroのテンプレートには、2点の特記事項があります。

1. 情報の機密度に関するラベル及びその表の存在
   • 何度も言及していますが、脅威モデリングを実践する上で参加するメンバーが同じ前提知識を共有し同じ目線で議論できることは重要です。前提でも述べたように、参加しているメンバーが漏れなく脅威モデリングの経験があるわけではありません。そのため、ダイアグラム1つとっても着目する観点は、人によって変わります。着眼点が増えるという意味においては良いですが、はじめて実践する方においてはどこに着目すればいいのかを連想し辛くなる可能性が予想されます。そのために、着目すべき箇所をハイライトすることにしました。すなわち、システムのダイアグラムにおいて、どこに機微な情報があるのか一瞥して認識できるようにしたという具合です。
2. ソリューションとして分析対象か否かを可視化するための点線と実線の使い分け
   •  PASTA の第一フェーズがそうであるように、脅威モデリングを第三者にソリューションとして提供する際にはどのような観点で実践するのかは重要です。想定しうる脅威のシナリオを漏らすことなく列挙するのは嬉しい反面、当然ながらそれには時間を要します。また、 STRIDE per Element に従って実践していくと、設定した目標によっては明らかに分析の対象から外れるエンティティとなることがあります。その際に、1と同様に、メタな情報としてどのエンティティが分析の対象であり、逆にその対象から除外されているのかが一瞥して把握できる工夫は有効であると筆者は考えています。そのため、ダイアグラム上の各エンティティは、実線と点線を使い分けることとしました。

Google Spreadsheet を用いた脅威および管理策の分析について

データフローなどの着眼点で分析対象に関するダイアグラムの構築が完了すれば、それらに基づいた分析作業のステップに進むことになります。この際、分析するスコープやシステムの複雑さ次第では、膨大な対象を相手にする可能性があります。そのため、ここからここまでをアナリスト A さん、ここからここまでをアナリスト B さんという具合に連携することが、作業を迅速に終了させるには肝になります。量的な負担のために、アナリストによってはエンティティが類似するなどの理由で脅威のシナリオや管理策を前出のものでコピペして済ましてしまいかねず、それでは成果物の品質の低下を招いてしまいます。この分析フェーズで使用するツールとして、 Google Spreadsheet は最適です。データの同期はもちろんのことながら、希望に応じて抽出した脅威のシナリオについて独自のメタ情報を付与したり、それらについて統計的に俯瞰させることが可能です。既存の脅威モデリング以外に規定されていないこと（E.g. 脅威シナリオに対する対応ステータス）について、カスタイマイズできるという恩恵を享受できます。 CxO など報告内容を受ける上位のメンバーによっては、潜在的な脅威の存在やその数以外にも、システムが成熟度として設計に潜むリスクに対して現時点でどの程度のセキュリティ管理策を適用して対応済みなのか認知したいなどの要望はあるかと思います。そのような多様な要望に対しても、高い自由度のある本ツールであれば対応することは容易に実現できます。

このフェーズでも使用するSpreadsheetにはテンプレートを作成し、利用に際してはそのテンプレートをコピーして実践することに手順を定めました。作成したテンプレートは次の通りです。

Google Docs を用いたレポーティングについて

システムにおける潜在的な脅威の整理を完了できれば、その内容を報告することになるでしょう。報告に際しては、前述のGoogle Spreadsheetを利用することで数値的な集計は完結するため、レポートとしては分析者の洞察コメントが記述できれば十分かと思います。それには、資料共有の手軽さから Google Docs を選択しました。ただし、分析内容の記述は、社内の関連会社へのソリューション提供に限った話かもしれませんが、 MTG などで報告することを前提とすればレポート資料の作成は省略できる可能性があります。レポートにおいても、 Google Spreadsheet 同様に私たちはテンプレートを作成しました。そのテンプレートは、次の通りです。

まとめ

本稿では、チームで脅威モデリングを実践する過程で浮き彫りになった作業連携の課題を取り上げ、導出した対処方法とその使い方についてご紹介しました。取り上げた課題というのは、既存の流布している専用ツールを使用して複数人で作業する場合、データ連携やそれに付随してレビュー時に煩わしさを感じるというものでした。それに対して、ローカルに編集データが管理されること、加えて専用ツールが複数の機能を内包しているということに原因を帰着させました。具体的には、データ管理にはクラウドベースのものを、また機能については各作業ごとにツールを選択するということを導きました。2つ目は、すなわち、ダイアグラムの作成、分析、レポーティングという3つの工程に対して、それぞれの目的に即したツールを選択するという具合です。また、アプローチがクラウドを活用するということになりますので、もし参考にする際にはアクセス制御など適切なセキュリティ管理策を実施することを推奨致します。本稿の内容が脅威モデリングをチームで実践する際の1つの参考になれば幸いです。

幣チームでは、中途採用を積極的に行っております。ご興味をお待ちの方は、次のリンクより応募いただけます。
https://it.cyberagent.group/team/ssg/