本記事では、 脅威モデリングの概要と弊社で脅威モデリングをゼロからソリューションとして提供するまでの歩み、それに伴って発生した課題とその対応策の一部についてご紹介いたします。本記事を通じて、脅威モデリングの理解の助け、または実践する際の参考になれば幸いです。
ToC
背景
弊社のシステムセキュリティ推進グループ（以降、部署）は、「セキュリティ維持・向上・事後対応を通じて、サイバーエージェントグループの成長阻害要因となるITセキュリティリスクを排除する」をミッションに据えております。弊社には関連会社にてゲームやブログ、動画配信など多数サービスを有しており、弊部署は横断組織という位置付けから、それら関連会社に対してセキュリティ対応や管理策の設計・運用など日々多数の取り組みを実践しています。
その中で、プロダクトのシステムにおけるリスクアセスメントを実践して欲しいという需要は一定数あります。しかしこれまでは、 CIS Benchmark などの各種プラクティスを参考にして対応にあたっておりましたが、時間や労力、精度などの点で課題がありました。本ブログで紹介する脅威モデリングは、それら課題を解消するものであります。
弊部署で脅威モデリングを実践するに至ったきっかけには、部署内のチーム間連携の促進および新規の取り組みの芽を蒔くワーキンググループ（以降、 WG ）という施策の誕生に端を発します。当施策の誕生から程なくして、脅威モデリングに関心を寄せるメンバーが集まり施策を利用して WG として活動を開始し、情報の収集からプロダクトへの適用を経て現在に至る、という具合です。以降の内容は、その活動の過程で蓄積された情報の要点になります。
脅威モデリングについて
概要
はじめに、本稿の中心事項である脅威モデリングについて、その概要をご紹介します。詳細の説明については、現時点で入手可能であり書籍として体系的に整理されている次の2冊に譲ります。
- I. Tarandach et al, Threat Modeling: A Practical Guide for Development Teams, 2020.
- A. Shostack et al, Threat Modeling: Designing for Security, 2014.
脅威モデリングとは、上記の参考の I. Tarandach らによる定義を引用すると、“Threat modeling is the process of analyzing a system to look for weaknesses that come from less-desirable design choices.“、すなわち、システムを分析して望ましくない設計上の選択に起因する弱点を探すプロセスを指します。
脅威モデリングを実践する際には、いくつかの方法論と手法などを選択したり、または特定のアプローチで定義されるステップに従っていくことになります。ここでは、脅威モデリングの代表的なアプローチであるマイクロソフトによる STRIDE に基づいたアプローチ（以降、 MS アプローチ）と、 VerSprite による PASTA アプローチの概要を解説することを通じて脅威モデリングについて触れていきたいと思います。まずはじめに、 MS アプローチの説明として中心的な活動である2つの内容、システムのモデリングと脅威の分析の概要を紹介します。
1つ目のシステムのモデリングとは、システムを特定の観点に基づいて要素を分解し、抽象的に表現することを意味します。システムをモデリングするには、はじめにシステムを構成する要素（エンティティ）を分解し、要素間のデータの流れに着目して、可視化する手法を取ります。この手法を DFD （ Data Flow Diagrams )と呼び、他のアプローチなどでも利用されます。MSアプローチでは、必須ではないですが、システムをモデリングする手法には、特定の機能における処理をモデリングするシーケンス図やプロセスフローダイアグラム（ PFD、Process Flow Diagrams ）、フィッシュボーンダイアグラム（ Fishbone Diagrams ）などがあります。いずれの手法でも変わらないのは、図を用いてシステムの全体あるいは一部を抽象的に表現し直すことです。
2つ目の脅威の分析とは、1つ目のステップでモデリングされたシステムの情報に基づいて、システムに発生しうる潜在的な脅威を分析することを意味します。この脅威の分析では、 MS アプローチの根幹に位置づく STRIDE があります。 STRIDE は、6つの観点（ Spoofing ：なりまし、 Tampering ：改ざん、 Repudiation ：否認、 Information Disclosure ：情報漏洩、 Denial of service ：サービス拒否、 Elevation of privilege ：権限昇格）の英単語の頭文字をとった造語であり、前のステップで登場した DFD に依存します。 STRIDE を実践する方法には、観点を適用させる対象の違いによって、下記の2種類が提案されています。
- STRIDE per Element
- 対象： DFD で記述されたシステムを構成する各要素自体
- STRIDE per Interaction
- 対象： DFD で記述されたシステムのデータフローと信頼境界が交差する箇所において、その”送信元”、”送信先”、”交差点”
加えて、我々もソリューションに取り入れていますが、 M. Muckin et al.(2019) は、 Lateral Movement （水平移動）の脅威の観点を加えた STRIDE-LM を提案しています。脅威の分析に関わる手法については、 N. Shevchenko et al.(2018) による網羅的な調査結果がありますので、気になる方はご参考いただけばと思います。
続いて、脅威モデリングを実践するステップのイメージを補足するために PASTA アプローチの概要について触れていきたいと思います。 MS アプローチでは、モデリングした成果物を使って分析するという具合に活動の依存関係はあるものの、厳密な手順については触れられておりません。それに対して、2015年に開発された PASTA（The Process for Attack Simulation and Threat Analysis） は、はじめに分析対象のサービスやアプリの目的を、次に技術的なスコープを定義するという具合に MS アプローチだけだと曖昧だった具体的な活動の手順が定義されました。 PASTA アプローチで定義された手順は、次の通りです。
- Stage1:Defining the objectives
- サービスにおけるビジネスや保証すべきセキュリティレベルなどの目標を定義すること
- Stage2:Defining the technical scope
- サードパーティのライブラリやデプロイするまでの環境など分析の対象をどこまで含むかを決めること
- Stage3:Application decomposition & analysis
- アプリをリソースや機能などの単位で分解すること
- Stage4:Threat Analysis
- アプリケーションの動作や脅威になりうる対象やその種類を分析すること
- Stage5:Vulnerability & weakness analysis
- Stage4 で抽出された脅威に依存する脆弱性を分析すること
- Stage6:Attack modeling & simulation
- Stage5 で抽出した脆弱性を発生させる攻撃に関する手順や依存をモデル化すること
- Stage7:Residual risk analysis & management
- これまでの Stage で明らかになった脅威について、軽減などのリスク対応を管理すること
上記で示すように、 MS アプローチにおけるシステムのモデリングが Stage3 、脅威の分析が Stage4 という具合で PASTA アプローチに対応づけられ、補完するようなステップが加えられていることがわかります。 PASTA で定義された手順が当然全ての組織で最適とならないとは思いますが、弊社で実践した際の参考になったように手順の一例を確立させた功績は大きいように思います。ちなみに MS や PASTA 以外のアプローチについては、 IriusRisk による解説ページも参考になります。
期待される効果
脅威モデリングを実践することには、多くのメリットがあります。以降では、脅威モデリングをなぜやるのかという問いへの回答になりうるメリットについて、その代表的なものをご紹介しようと思います。
- 診断では検知できない設計上の脆弱性を検知できる
- 脅威モデリングでは、システムのアーキテクチャやネットワークの境界などについて分析することになります。そうすると、ネットワークのピアリングの設定などにもメスが入ります。これらは脆弱性診断では気付けない内容です。
- コストを削減できる
- 脅威モデリングは、システムを構築する前の設計段階に対して適用することができます。それゆえに既に構築したものに対してセキュリティ対応のために手戻りすることによるコストに対して未然に対応することができます。副次的ですが、システムをモデリングする過程ではアーキテクチャ構成の観点から無駄な構成に気づくこともあります。
- システム及びそれを構築する環境について深く理解することができる
- 脅威モデリングには、システムの分解し抽象的に表現するモデリングのステップがあります。その際には、システムのデータフローや処理について主にビジュアルで表現されるため、システムをより平易に、また網羅的に理解するのに寄与します。
- セキュリティ管理策の優先度付けの助けとなる
- 先の PASTA アプローチなどでは脅威モデリングのステップとして、ビジネスや担保すべきセキュリティレベルなどを定義します。これによって、抽出された脅威と設定した目標との関わりの強さが理屈で捉えることができるため、管理策の優先度付けする際のメタ情報として活用することができます。
- 開発者などコラボレーションの機会が増加する
- 組織によっては、セキュリティチームと DevOps チームが分離しているしていることはあるかと思います。脅威モデリングにおけるシステムのモデリングを実践するのには対象について詳細に理解する必要があります。例えば、セキュリティチームが分析対象を理解する手段としては、 DevOps チームへインタビューするなどコミュニケーションによる方法が一般的です。一過性のヒアリングだけではなく作図に関する DFD のレビューなど、脅威モデリングを実践する過程ではコミュニケーションが重要であり、そのため DevOps とセキュリティの両チームの関わりの強化が期待されます。
上記以外にもメリットはあるかと思いますが、その中でも代表的なものを今回ご紹介いたしました。以上が今回の脅威モデリングに関する概要の説明であり、実践することによって期待される効果になります。上記の説明で述べるように脅威モデリングは、従来のセキュリティ管理策にとって替わる存在ではありません。それぞれのセキュリティ管理策は得られる効果が異なり、脅威モデリングは特にシステムの設計に対して効果を発揮するという特徴があります。そのため、既存の管理策と併用することでシステムのセキュリティの成熟度を高められるということがわかるかと思います。
知見を整理するまでの歩み
弊社では、活動は先の背景で述べたようにWGの制度の一環で進めており、脅威モデリング WG の活動としては主に3名で取り組んでおりました。活動の変遷をフェーズごとに分けると4つに大別することができ、簡単のためそれらをインプット期、技術検証期、トライアル期、標準化期と称して紹介していきたいと思います。
インプット期には、脅威モデリングに関する先行事例や文献などを調査し、それらをメンバー同士で知見を共有しあったり、イベントを聴講するなどして知見を積み上げてました。下記で列挙するのは、その活動で参考とした資料の厳選になります。厳密に上から順に進めていたわけではなく、並行していたりします。
- 国内の先行事例
- 脅威モデリングの概要やどのような具合で実践したのか、どの手法が選択したのかを概観するのに使用したのが企業ブログなどで紹介される先行事例です。国外の資料が中心の脅威モデリングの資料において国内の事例は貴重で、次のようなものを参考にしてました。
- 書籍
- 先行事例を通じて概観した後、知見を体系的に整理するために書籍を活用しました。 WG では、I. Tarandach らの書籍を中心に読んで、要点を翻訳しドキュメントツールに整理するなどしていました。脅威モデリングをテーマの中心に据えた書籍は限定的で、その中で下記の2冊は代表的なようです。
- E-Learning
- 資料調査している過程でたまたま巡り会った資料には、 STRIDE を開発した Microsoft による E-Learning の教材がありました。コンテンツでは脅威とそれに対するセキュリティ管理策について具体例を用いて説明されており、 STRIDE について理解が進む資料となっています。
- ウェビナー
- サービス提供を行っている実際のアナリストによる解説であり、クライアントに対してどんなステップを踏んで実践しているのかなど実践に関する理解に有益な資料となっています。
技術検証期では、良さそうなツールを手に取り、使い方や特徴などを整理していました。検証したツールの特徴をまとめた表は、次の通りです。ただし、使いやすさや良し悪しの評価は主観に基づいています。
ツールの詳細は、それぞれ次の通りです。
ただし、 Miro で使用したテンプレートは弊部署で独自に作成したものです。
トライアル期では、社内において新規でサービス開発する組織と連携して、設計段階のフェーズのプロダクトに対して実際に脅威モデリングを実践しました。弊部署は、 Microsoft Threat Modeling tool 、 OWASP Threat Dragon 、 threagile の中から最も使い勝手がよさそうなのと脅威分析の選択肢の多さから OWASP Threat Dragon を選択しました。結果として、これまでガイドラインやプラクティスに従っていたアークテクチャを評価していた時に比べて、 DFD やシーケンス図などの成果物に基づいて評価する過程はより理屈だって実践できるなという印象を持ちました。ただこのトライアル期での実践を通じて下記のような課題が浮き彫りになりました。
- アナリスト次第で分析の精度や時間にバラツキがある
- 作図や分析を共同で作業できない
- Kubernetes におけるコンポーネントの要素分解の粒度および表現方法をどうするか
標準化期では、トライアル期で浮き彫りに課題への対応を通じて、ソリューションとしての成熟度を上げる活動に取り組んでいました。以降では、上記の課題の中から特に Kubernetes に関わる課題について、概要とその対応アプローチについて紹介します。
Kubernetes のクラスタは、下図のように etcd や kube-apiserver など多数のコンポーネントで構成されております。
これらコンポーネントについて全てを分析のスコープに含めた場合のDFDの成果物は、非常に煩雑になります。 Kubernetes クラスタの構成の複雑さはあるものの、分析の対象としては Kubernetes 自体ではなくシステムのロジックに焦点が当てられるべきです。 Kubernetes における各コンポーネントに焦点を当てた脅威モデリングについては、 Trail of Bits, Inc. によって実践されています。
それでは、課題に関わる要素をそれぞれ分解して、検討した対策について順に紹介していきます。
- DFD で表現すべきコンポーネントは何か
- 先に触れたように、 Kubernetes は複数のコンポーネントによってそのエコシステムを構築しています。そのため、それらコンポーネントを漏れなく全て分析の対象に入れるべきか検討する必要があります。これに対するアプローチとしては、 Kubernetes クラスタをどのようなプラットフォーム上で運用しているのかに帰着する問題であると考えます。例えば、 AWS や Google Cloud などのマネージドサービスを利用している場合、責任共有モデルの考えに基づくと、ユーザ側で管理できないコントロールプレーンの責任の所在をクラウドベンダー側と導けます。漏れなく全てを分析対象とすることが重要であるという考えは個人として認めますが、たとえ脅威の存在を想定できてもユーザ側で管理策を適用できることはありません。
- 以上のことから、 DFD で表現すべきコンポーネントとしては、ユーザ側で管理できるコンポーネントを全て切り出す、と導けるかと思います。
- 複数のワーカノードで構築される場合、各ノードはそれぞれ DFD で表現すべきかどうか
- Kubernetes クラスタは、1つないしは複数のノードによって構成されます。そのため、複数のワーカノードで構成されるクラスタが分析の対象である場合、モデリングする要素として各ノードをそれぞれ切り出すかどうか検討する必要があります。
- これに対するアプローチについても1.と同様に、 Kubernetes クラスタをどのようなプラットフォーム上で運用しているかに帰着することができます。マネージドサービスにおけるワーカノードの責任の所在はクラウドベンダー側に導けるという具合です。
- 各ノードを個別に表現するということは、ノードごとの差分を分析の対象に含めることに他なりません。
以上の検討から、 Kubernetes クラスタを利用したシステムのモデリングには次のようなアプローチを採るに至りました。
- DFD に記述するコンポーネントには、ユーザ側で管理できるものを全て切り出す
- 個別のノードを表現せず、クラスタという単位で信頼境界を表現する
このアプローチに従って、 Kubernetes を利用するサービスの DFD を作成すると次のように表現できます。
まとめ
本稿では、弊部署における WG という制度の活動事例として、脅威モデリングの概要とそれをソリューションとして提供するまでの歩みについてご紹介いたしました。上記で紹介した内容を通じて、少しでも脅威モデリングを実践する障壁が下がり、組織のプロダクトにおけるセキュリティ向上に寄与できれば幸いです。
弊部署ではキャリア採用を募集しています。弊社に関連する組織には多数のプロダクトがあり、それに付随してセキュリティに関する職務も多数あります。ご興味の方は下記より応募いただけます。
https://it.cyberagent.group/team/ssg/