freee Developers Advent Calendar 2024 17日目の記事はWaTTsonが担当します。昨年のAdvent Calendarでは「credentialをSlackに書くな高校校歌」というのを出してプチバズりしていたのですが、今回はネタ枠ではなくもうちょっと真面目な話を書きます。
脅威モデリングの取り組み
みなさんは開発しているシステムに対して「脅威モデリング」を行っているでしょうか？脅威モデリングとは、システムの各要素が持つ様々な脅威を挙げ、それらの緩和策を考えて整理する、という取り組みです。最近では、12月6日・7日に脅威モデリングナイト#5とTMC Tokyo x ZANSINの2日連続でのイベントが開催されたりと、界隈が活気を見せつつあります。
freeeでは、2023年に開催した自社カンファレンス「freee 技術の日」において「脅威分析はじめました」という発表をするなど、ここ2年ほど取り組みを強化しているところです。
また、「freee 技術の日」での発表から1年ほど経って、今年の6月に「IssueHunt Lounge #5」というイベントで、その後の経緯について登壇をしてきました。
ここではfreeeでの脅威モデリングの取り組みがあまりうまくいかなかったという話をしたのですが、どういう点でうまくいかなかったかというと、「セキュリティチーム（PSIRT）だけでの活動には限界があり、大きく複雑なシステムに対して継続的に取り組むのが難しい」というポイントでした。ここまでの1年半くらいの取り組みでは主にPSIRT内の有志メンバーが主業務と並行して取り組むような形でやっていたのですが、脅威モデリングを実践するのはそれなりに工数がかかるもので、複数のプロダクトを持ちそれらが互いに連携するような複雑なシステムを持つfreeeの状況下では取り組みを横展開していくのに難航する状況となっていました。上のIssueHunt Lounge #5では、そうした状況を踏まえた上で、PSIRTが完全主導するよりは、より開発者チームに寄った形で進めていくのが望ましいのではないか、という展望を語っています。
さて、そんな折に、私は "異動戦国" という社内異動の制度を使ってPSIRTから開発チームへと異動しました（異動戦国についてはこちらを参照: 異動をカジュアルに！freeeの社内異動制度「異動戦国」 - freee Developers Hub）。これにより、私はセキュリティ専属のチームという立場ではなく開発チーム内の "Security Champion" としてセキュリティに関わることになったのですが、ちょうど良いタイミングだったので、異動先のチームのメンバーを巻き込んで、開発しているシステムに対しての脅威モデリングを行いました。
開発チームが主導して脅威モデリングを行うのは、「システムそのものについて熟知している」という大きなメリットがあります。脅威モデリングは一般に
- 対象のシステムについて理解する
- システムに対する脅威を列挙する
- 挙げた脅威のそれぞれを評価し、緩和策を考える
- 以上の流れがうまくできたか振り返る
という4つの手順（four-question framework）に従って行われるのですが、特に最初の「対象のシステムについて理解する」のステップを行う上で、開発チームは高い優位性を持っています。
一方で、2つめの「システムに対する脅威を列挙する」のステップについては、開発チームでは脅威や攻撃についての知見が少ないという点で、セキュリティ専属のチームが進めるより若干劣る点になると思います。開発チーム主導で脅威モデリングを行う場合は、ここをいかにうまく補っていくかが大きな課題の一つとなるでしょう。
そうした点をカバーするための方策として、脅威モデリングを行うためのカードゲームというものが考案されています。これは、セキュリティにあまり詳しくない人でも簡単に脅威モデリングが行えるようにするために作られた、ある種のゲーミフィケーションになります。これについての既存の記事では、2020年にmakoto-iguchiさんによって書かれたものが非常に分かりやすく書かれています：
この記事では、脅威モデリングでよく使われるフレームワークである「STRIDE」をベースとしてAdam Shostackが考案したカードゲーム"Elevation of Privilege"が紹介されています。この記事では "Elevation of Privilege" の日本語版も作られていて、GitHubで無償公開されています：
脅威モデリングカードゲームのいろいろ
上の記事では脅威モデリングカードゲームの元祖である "Elevation of Privilege" が紹介されていますが、実はこの種のカードゲームはこれだけではありません。"Elevation of Privilege" に触発されて、色々な人が色々な観点で拡張したり、新たに作ったものがいくつか存在します。開発チームとして脅威モデリングを進めていく上で、このあたりについて色々と調べたので、これらのカードゲームについて紹介する、というのがこの記事の趣旨となります。
"Elevation of Privilege" から派生したカードゲームについては、Adam ShostackのWebサイトに事例がまとめられています。
それぞれの内容はざっと以下の通りです：
- OWASP Cornucopia
- OWASP Secure Coding Practicesをベースに、OWASP ASVS（アプリケーションセキュリティ検証基準）、OWASP Webテスティングガイドなどの観点を加えたもの
- Colin Watsonが2012年に考案
- Elevation of Privacy
- プライバシーの観点に焦点をあてて整理したもの
- STRIDEの代わりにTRIM（Transport, Retention/Removal, Inference, Minimisation）を使っている
- 2018年にF-Secureのチームが考案
- Mark Vinkovitsによる拡張
- STRIDEにプライバシーのPを入れた”STRIPED”にする拡張版
- 元のブログポストは消されてしまっているが、2019年にAppSec Cali: Game On! Adding Privacy to Threat Modeling で説明されている
- OWASP Cumulus
- クラウド環境にフォーカスしたもの
- 2023年にTNG Technology Consultingのチームが考案
- Elevation of MLsec
- 機械学習のセキュリティ（MLsec）に焦点をあてたもの
- 2024年にElias Brattli SørensenとJorun Kristin Bremsethにより考案
また、少し別系統のものとしては、プライバシーに関わる脅威モデリングフレームワークの1つ「LINDDUN」をベースにした LINDDUN GO というものもあるようです。
ここでは、これらの中から特に「Elevation of Privilege」「OWASP Cornucopia」「OWASP Cumulus」の3つを取り上げて、比較を行いたいと思います。
ゲームの基本ルール
「OWASP Cornucopia」「OWASP Cumulus」は「Elevation of Privilege」の派生ゲームということもあり、これら3つは基本的なルールは変わりません。まず事前準備として、それぞれのカードを用意し、またモデリング対象のシステムの構成図を書いておきます。構成図は一般には DFD (data flow diagram) が良いとされますが、実際には必ずしもDFDに限らず、対象のシステムのどういう面を分析したいかによって必要な情報が載った何らかの構成図であれば十分だと思います。
ゲームの推奨プレイ人数はおおよそ3〜6人程度です。カードのデッキをシャッフルし、各プレイヤーに配っておきます。
ゲームの全体的な流れは、トランプゲームの「スペード」のようなトリックテイキングゲームです。各プレイヤーが順にカードを出していって一巡したところで、最も強いカードを出した人がそのラウンドに勝利する、というのを繰り返していき、最終的にポイント数が最も高い人がゲーム全体の勝利です。
トランプではカードに「スペードの3」や「ハートのキング」などのスートと数字（+α）が付いていますが、ここで紹介する脅威モデリングカードゲームではスートとしてSTRIDEなどの脅威の種類が使われているのが特徴的です。
より詳しく説明します。ゲームの最初には「スタートプレイヤー」が決められます。「Elevation of Privilege」ではスタートプレイヤーは「Tamperingの3」のカードを持っているプレイヤーで、他2つではランダムに決めることになっています。
ラウンドはスタートプレイヤーから開始し、時計回りに手番が回っていきます。各プレイヤーは自分の手番が来たら、手札から一枚を選んで場に出します。このとき、出すカードは基本的にはスタートプレイヤーが出したカードと同じスートのものを出すのですが、もし手札に当該スートのカードがない場合は、他のスートのカードを出すこともできます。
カードを出す際に、カードに書かれている脅威シナリオに基づいてシステムの脅威を指摘します。全体で協議を行い、脅威として認められた場合はそれを記録しておきます。この時プレイヤーは1ポイントを獲得します。
プレイヤーが順番にカードを出して一巡したらラウンドが終了です。この時、以下の条件に従ってラウンドの勝者が決まり、1ポイントが加算されます：
- 「切り札」のカードを出したプレイヤーがいれば、その中で最も強いカードを出した人がラウンドに勝利する
- 「切り札」が出されていない場合は、スタートプレイヤーが出したスートの中で最も強いカードを出した人がラウンドに勝利する
このようなラウンドを繰り返していきます。2ラウンド目以降のスタートプレイヤーは、前のラウンドに勝利した人となります。手札が全てなくなったらゲーム終了です。それまでに獲得したポイント数の最も高い人がゲームに勝利します。
実際のゲームの様子については、以下の動画が参考になると思います：
ゲームとしてのコツは、各ラウンドにおいて積極的にプレイするのか消極的にプレイするのかを見極めることです。自分が強いカードを持っている場合は強気にプレイできますが、他のプレイヤーが皆弱いカードしか出していないときにあまりにも強いカードを出すと、他のラウンドを戦うときに苦しくなります。他のプレイヤーが強気に出ている時は、あえてそのラウンドは捨てて別ラウンドの勝ちを狙いに行くのも戦略です。
標準的なルールは以上の通りですが、実際に行う際には適宜ルールを調整しても良いと思います。Elevation of Privilegeではルールのバリエーションとして、「カードを出したプレイヤーが脅威を思いつけなかったとき、他のプレイヤーが代わりに脅威を指摘できる」などが提示されています。
カード構成の比較
3つのゲームは基本ルールがほぼ同じで、大きな違いはカードの構成です。以下、それぞれのゲームについてカードの構成の面で特徴を見ていきます。
1. Elevation of Privilege
Elevation of Privilegeはこの種のゲームの元祖ということもあり、最もオーソドックスな構成です。カードのスートとしては、脅威モデリングで一般的によく使われるフレームワークである「STRIDE」がそのまま採用されています。
- Spoofing（なりすまし）
- Tampering（改ざん）
- Repudiation（否認）
- Information Disclosure（情報漏洩）
- Denial of Service（サービス拒否）
- Elevation of Privilege（特権の昇格）
STRIDEは汎用的なフレームワークで、かつ脅威モデリングの手法として広く用いられているため、ゲームを実際に行うにあたって情報を入手しやすいという大きなメリットがあります。また、カードそのものについても、上述の日本語版が作られていたり、Shostackの『Threat Modeling: Designing for Security』に説明が載っていたり、Brett Crawleyによる『Threat Modeling Gameplay with EoP: A reference manual for spotting threats in software architecture』という詳細な解説書が出されていたりと情報が豊富です。
その一方で、汎用的なシステムへの適用を想定しているために、特定のシステムにはあまりそぐわない脅威シナリオが含まれているという側面もあります。そういったシステムについてElevation of Privilegeを使う際には、当てはまる脅威がないときに「パス」ができるようにしたり、予め使用カードから除いておく、といったやり方を取っても良いかもしれません。
2. OWASP Cornucopia
OWASP Cornucopiaは、現在は「Website App Edition」と「Mobile App Edition」の2種類がありますが、ここでは主に前者について取り上げます。スートの構成は以下のような形です：
- Data validation & encoding（データの検証とエンコーディング）
- Authentication（認証）
- Session management（セッション管理）
- Authorization（認可）
- Cryptography（暗号化）
- Cornucopia
これは基本的な構成をOWASP Secure Coding Practiceに依っており、それに加えてOWASP ASVS（アプリケーションセキュリティ検証基準）やOWASP Webテスティングガイドなどの要素を付加して作られています。
OWASP Secure Coding Practiceはセキュアコーディングのための汎用的なチェックリストで、項目としては以下のような章立てになっています：
- 2.1 Input Validation（入力値の検証）
- 2.2 Output encoding（出力のエンコーディング）
- 2.3 Authentication and password management（認証とパスワード管理）
- 2.4 Session management（セッション管理）
- 2.5 Access control（権限管理）
- 2.6 Cryptographic practices（暗号に関するプラクティス）
- 2.7 Error handling and logging（エラーハンドリングとロギング）
- 2.8 Data protection（データ保護）
- 2.9 Communication security（通信セキュリティ）
- 2.10 System configuration（システム設定）
- 2.11 Database security（データベースのセキュリティ）
- 2.12 File management（ファイル管理）
- 2.13 Memory management（メモリ管理）
- 2.14 General coding practices（一般的なコーディングプラクティス）
OWASP Cornucopiaのスートとの対応を見ると、特に最初の6つについて
- Data validation & encoding
- 2.1 Input validation
- 2.2 Output encoding
- Authentication
- 2.3 Authentication and password management
- Session management
- 2.4 Session management
- Authorization
- 2.5 Access control Cryptography
- 2.6 Cryptographic practices
のようにざっくり対応しています。OWASP Cornucopiaの各カードにはOWASP Secure Coding Practicesなどの関連プロジェクトとの対応関係が事細かに記載してあります。
OWASP Cornucopiaを使う場合には、構成図を書く時点で、よりコーディング寄りの内容を詳細に表した図にしておいた方が良さそうに思います。一般的に脅威モデリングで使われる構成図は「サーバー」とか「データベース」といった粒度で書くことが多いですが、この場合にはもっとアプリケーションの内部に踏み込んだ形で図を書いておくことで、Cornucopiaのデッキの特性をより生かすことができそうです。
3. OWASP Cumulus
OWASP Cumulusはクラウド上のシステムに適用することを想定して作られたものです。スートは以下のようになっています：
- Access & secrets（アクセスとシークレット）
- Delivery（デリバリー）
- Recovery（回復、復旧）
- Monitoring（モニタリング）
- Resources（リソース管理）
OWASP Cumulusはクラウド上のシステムに適用することを想定して作られたものです。TNG Technology ConsultingのChristoph NiehoffによるLinkedinの投稿 によると、
Threat modeling with Elevation of Privilege and Cornucopia can help you in boosting the security of your project. However, we had the impression that the Ops aspect of DevOps has been under-represented in these games. That led to the idea to create a custom threat modeling card deck which explicitly targets cloud infrastructures and DevOps setups.
（Elevation of PrivilegeおよびCornucopiaによる脅威モデリングはプロジェクトのセキュリティを強化するのに役立ちます。ですが、これらのゲームではDevOpsでいうところのOpsの部分が十分に表現されていないという印象を受けます。そこで、クラウドインフラとDevOpsを明に対象としたカスタムの脅威モデリングカードデッキを作成するというアイデアが生まれました。）
と説明されており、特にクラウドにおける運用面に関する比重を大きくして作られているようです。クラウド上のサービスでは、ハードウェアの管理やネットワークなどの低レイヤの層はクラウドベンダー側の責任範囲となり、クラウドサービスのユーザーとしては設定項目に気をつける部分が多くなります。OWASP Cumulusの項目ではクラウド上のシステムによく見られる設定をある程度具体的に挙げる形で設計がなされているようです。
なお、OWASP Cumulusの公式サイトの説明には、
This game does explicitly not try to replace Elevation of Privilege or Cornucopia. It should rather be seen as part of a triplet of threat modeling card decks, reflecting different aspects of modern software development projects.
（このゲームはElevation of PrivilegeやCornucopiaの代替物になることを想定して作られたものではありません。むしろ、現代のソフトウェア開発プロジェクトの異なる側面を反映した、脅威モデルのカードデッキ三部作の一部、という風に見るべきです。）
という説明文があります。なので、OWASP CumulusがあるからといってこれだけをやっていればElevation of PrivilegeやCornucopiaは必要ない、というものを目指している訳ではなく、クラウド上のサービスにおいてより具体的な脅威を挙げる上で他二者を補うようなものとして見るのが良いと思います。
"Elevation of Privilege" をやってみた感想
上のように色々と調べてはみたものの、結局私が異動先のチームで脅威モデリングをやる際には「Elevation of Privilege」を採用することにしました。これは、このシステムに対しての最初の脅威モデリングなので標準的なものを使いたかったことと、開発チームのメンバーがあまりこういったものに慣れていないと想定されるため、情報が多いものの方が進めやすそうだという見通しによる選択です。実際にやってみた感想は以下のような感じです。
まず、これを実践する上では事前準備が非常に重要だというのを感じました。ゲームを行う前にチームメンバーに対して「脅威モデリングとは何か」について1時間くらいかけて説明を行い、また構成図もシステム全体を大雑把に書いたものと個別のユーザーストーリー・個別のコンポーネントの詳細について書いたものを複数用意してから臨んだことで、ゲームの流れはある程度すんなり行えたと思います。
改善ポイントとしては、「Elevation of Privilege」そのものに関する理解を深める、というのをもっと準備しておいた方が良かったな、というところがありました。私自身としては「Elevation of Privilege」は過去にPSIRTで脅威モデリングをやった時に使っていたのでなんとなく大丈夫だろうという感覚でいたのですが、それはお互いにある程度セキュリティの勘所が分かっている状態だったから成り立っていた側面も一定あったようで、開発チームメンバーから「この脅威シナリオはどういう意味？」という質問が出てゲーム進行が中断しがちになっていました。また、あるカードについて挙げた脅威が、「これはどちらかというと別のこのカードに該当するものじゃない？」というような混乱も時々出ていました。
一般的なプラクティスとしては、『Threat Modeling Gameplay with EoP: A reference manual for spotting threats in software architecture』のような解説書を見て、どのようなカードがあるのか、それぞれの脅威はどういったシナリオで、一般にどう対策されるものなのか、について参加者の間で認識のすりあわせをしておいてから進めた方がゲーム中に詰まりにくくなると思います。また、freeeのように多数のプロダクトを抱える中で各開発チームに横展開することを考える場合は、プロダクトの標準構成に従った場合は例えばこういう脅威シナリオになる、というのを具体的に示したものを作って整備しておくと、個別のシステムがそれぞれ特性上標準から外れている部分に注力できて良さそうに思いました。
次に、このようなカードゲームは可能であれば最初はオフラインで集まってやった方が良さそう、と感じました。私が現在所属しているチームは半分のメンバーが関西オフィスに所属しているのですが、この脅威モデリングを行う際には関西メンバーに東京まで集まってもらって、オフラインで実施をしました。これは、メンバーの大半が脅威モデリングに慣れていないという状況下では良い選択だったのではないかと思います。
上で書いたような若干の準備不足のせいでもあるのですが、やはり慣れていない人が多い中で進めていくと、どうしてもゲーム中の細かな部分で疑問点などが色々と出てきます。オンラインのミーティングでは現状どうしても喋るのが1人ずつ順番になりがちなので、そうした声を全て拾うのは難しい側面があると思います。オフラインで顔を合わせてやっていると、発言も気軽にしやすいですし、各メンバーが困ってそうな雰囲気もより鋭敏に感じ取ることができます。慣れていない人のサポートをしながら進めるという状況下では、こうしたメリットが享受できるオフラインでの開催の方がやりやすいのではないかと私は思います。
なお、メンバーがそれぞれ慣れてくれば、オンラインで進めていく方が手軽にできて良いかもしれません。Adam Shostackのサイト（Shostack + Associates > Elevation of Privilege Game）の「Software and tooling」の節ではオンラインでこれらのカードゲームを行うためのツールがいくつか紹介されています。また、オンラインで進める際に気をつけた方が良い点については、「A Guide to Threat Modelling for Developers」の「Running sessions face-to-face vs. running remotely」の節で挙げられているものが参考になるかもしれません：
今回、カードゲームをするのには3時間ほどの時間を取っていたのですが、この時間内には「Elevation of Privilege」のカードを全て完遂することはできませんでした。結局この時は、開始スートが全スートを網羅するように6ラウンドだけやって終える、という形に収めました。理想的には全てのカードを使い切るまでやるのが望ましいのだと思いますが、全部でカードの枚数は74枚もあり、その1つ1つについて脅威を細かく話していくと、かなりの時間がかかります。6ラウンド分やるだけでも、最後の方は皆若干疲れて集中力が切れ気味になってしまっていました。
脅威モデリングではしばしば網羅性にこだわるのはバッドプラクティスだと言われますし、Elevation of Privilegeのようなカードゲームについてもフルセットを全部やりきることにこだわる必要はそんなにないと思います。私が異動先チームでやった後にPSIRTの別メンバーが別のチームでもElevation of Privilegeをやっているのですが、そちらでは予め使うカードの枚数を絞った形で行って、1時間程度で終わらせるという方針をとったようでした。このようなやり方もまた一つ良い方針なのではないかと思います。
ちなみに、Elevation of Privilegeは脅威の列挙の部分を扱っているので、four question frameworkでは4つあるうちの1ステップに過ぎません。重要な作業として次に「挙げた脅威を評価して対策を考える」というものがあるのですが、これは私のチームでは毎日の朝会の最後に時間が余ったら少しずつ進める、という形を取りました。挙げた脅威を全部網羅するのに2ヶ月ほどかかりましたが、それほど負担なく対策を挙げるところまで終えることができたので、これはかなり良い方針だったかなと思います。
最後にもう一つ、挙げた脅威の記録についての感想を挙げておきます。今回はGoogleスプレッドシートに記入していく、という方式をとったのですが、これは表形式で見やすい反面、議論の内容を文字として書き込みづらく、後から「対策を考える」ステップで見返したときに議論を思い出すのが大変、という側面がありました。そのため結局スプレッドシートからGoogleドキュメントにコピペして「対策を考える」議論で改めてメモを追加していく、というようなことをやったのですが、これはあまりうまくいかなかったやり方のように思います。最初からGoogleドキュメントに書くか、あるいは「OWASP threat dragon」や「OWASP pytm」のようなツールを使った方が良かったかもしれない、とちょっと思っているところです。この辺のやり方について何か良い知見を持っている方がいれば、ぜひアドバイスをもらえるとありがたいです。
おわりに
以上、ちょっとボリューミーな内容となりましたが、脅威モデリングカードゲームの紹介と、Elevation of Privilegeをやってみた感想を書いてきました。脅威モデリングの手法は色々あるのですが、日本語の情報が意外と少なくてちょっととっつきづらい側面があるように思います。英語で探そうと思えば「awesome-threat-modelling」とかOWASPのthreat modelingのページとかthreat modeling connectのフォーラムとかから色々辿れるのですが、それなりにモチベーションがあって余裕のある人でないと手が出しづらい側面がある気もします。このようなハードルを少しでも下げるために、こうした情報発信も積極的にしていけたら良いなと思っています。
freee Developers Advent Calendar 2024 はまだまだ続きます。明日はjumpさんの記事です。お楽しみに〜〜
