アジャイル開発にセキュリティをどう組み込むか。
これは、以前から自分の中で気になっていたテーマです。
セキュアなシステムを開発するための手法は、すでに数多く存在します。Threat Modeling、Attacker Persona、Misuse/Abuse Caseなど、それぞれ非常に有用な考え方です。
一方、スクラムなどを使ったアジャイル開発の現場からこれらを眺めると、少し距離があるようにも感じます。
実際、アジャイル開発とSecurity Requirements Engineering（セキュリティ要求工学）の統合について調査した研究では、セキュリティ要求工学はアジャイル開発に必ずしも自然に適合するものではなく、その統合のためにSecurity Story、Abuser Story、Evil User Storyなどの追加的な成果物や活動が導入されていることが報告されています。
「セキュリティのために別のプロセスを追加する」のではなく、普段行っているアジャイル開発の活動の中に、攻撃者の視点を自然に組み込むことはできないだろうか。
そんなことを考えて、既存のセキュリティ手法とUser Story Mappingを組み合わせた**防御駆動開発（Prevention-Driven Development: PDD）**という考え方を整理してみました。
PDDは、Threat Modelingなどに代わる新しいセキュリティ理論を作ろうというものではありません。
むしろ、すでに存在する優れた考え方を尊重しながら、それらをアジャイル開発の流れに沿って接続することを狙ったものです。
この記事では、その考え方について紹介します。
情報システム開発における脅威分析
情報システムを安全に開発するためには、実装した後で脆弱性を探すだけでは十分ではありません。
「このシステムは誰から狙われる可能性があるのか」
「攻撃者は何を目的としているのか」
「どのような方法で攻撃してくるのか」
といったことを、開発の早い段階から考える必要があります。
そのための考え方や手法は、すでにいくつも存在しています。
Threat Modeling
代表的なものが**Threat Modeling（脅威モデリング）**です。
Threat Modelingは単一の技法を指すものではありませんが、システムの構成、データフロー、資産などを分析し、「何がうまくいかない可能性があるのか」「それに対して何をするのか」を設計段階から検討するために使われています。
MicrosoftのSecurity Development Lifecycle（SDL）ではThreat Modelingがセキュア設計の重要な活動として位置付けられており、脅威を分類する方法としてSTRIDEが利用されています。
STRIDEでは脅威を、
- Spoofing
- Tampering
- Repudiation
- Information Disclosure
- Denial of Service
- Elevation of Privilege
の6カテゴリーから検討します。
Microsoft自身も、STRIDEを機械的に適用するだけでは十分ではなく、攻撃者の立場で考えることがThreat Modelingの重要な部分であると説明しています。
つまりThreat Modelingには、
「攻撃者なら、この設計をどう攻撃するだろうか」
という視点が含まれています。
Attacker Persona / Persona Non Grata
攻撃者の立場をさらに具体化する考え方として、Attacker Personaがあります。
関連する先行研究としてJane Cleland-Huangは2014年のIEEE Softwareの記事 How Well Do You Know Your Personae Non Gratae? で、通常のPersonaの考え方を悪意あるユーザーへ拡張したPersona Non Grataを紹介しています。
通常のPersonaでは、システムを利用する典型的なユーザー像を具体化します。
これに対してPersona Non Grataでは、望ましくない行動をするユーザーや攻撃者をPersonaとしてモデル化します。
PDDではこの考え方を継承し、例えば、
- スクリプトキディ
- 国家の支援を受けた攻撃者
- サイバーテロリスト
- 企業スパイ・産業スパイ
などのAttacker Personaを考えます。
攻撃者によって目的、能力、利用できるリソース、費やせる時間などは異なります。
「攻撃者」という一つの曖昧な存在ではなく、具体的なPersonaとして考えることで、想定すべき攻撃を考えやすくします。
Misuse Case / Abuse Case
通常のUse Caseでは、
ユーザーがシステムを使って何をしたいか
を考えます。
この考え方を悪意のある利用に拡張したものとして、Misuse CaseやAbuse Caseがあります。
John McDermottとChris Foxは1999年の Using Abuse Case Models for Security Requirements Analysis で、Use Caseをセキュリティ要求の分析に応用するAbuse Case Modelを提案しました。
また、Guttorm SindreとAndreas L. OpdahlはMisuse Caseについて研究し、Use Caseだけではセキュリティ上の脅威や要求の抽出を十分に支援できないという問題に対して、悪意のある利用を表現するMisuse Caseを利用してセキュリティ要求を抽出する方法を体系化しています。
ここでも中心となっているのは、
「正しい利用方法だけではなく、システムがどのように悪用される可能性があるか」
という視点です。
Evil User Story / Abuser Story
同じ考え方をアジャイル開発のUser Storyに持ち込んだものとして、Evil User StoryやAbuser Storyと呼ばれるアプローチも存在します。
アジャイル環境におけるSecurity Requirements Engineeringを調査した研究でも、Security Story、Abuser Story、Evil User Storyなど、セキュリティ要求をアジャイルの成果物として表現する方法が実際に利用されていることが報告されています。
Evil User Storyの考え方では、通常のUser Storyとは逆に、
攻撃者は何をしたいのか
という観点からストーリーを作ります。
さらに、その攻撃に対するMitigationをAcceptance Criteriaとして表現し、通常の機能と一緒にBacklog上で扱うという実践もあります。
ここまでを見ると、
「攻撃者の立場からUser Storyを考える」
というアイデアそのものはPDD独自のものではなく、すでに先行する研究や実践が存在することが分かります。
優れた手法はある。でも、どうつなぐか
ここまで紹介した考え方には、それぞれ異なる背景や目的があります。
Threat Modelingでは脅威を体系的に分析します。
Attacker Persona / Persona Non Grataでは攻撃者をモデル化します。
Misuse/Abuse Caseでは悪意のある利用方法を考えます。
Evil User StoryやAbuser Storyでは、それをアジャイル開発で扱いやすいStoryとして表現します。
どれも有用です。
しかし、ここで自分が注目したのは、
「これらを、プロダクトのフィーチャーを発見し、MVPを決め、User Storyを実装していく日常的なアジャイル開発の流れとどうつなぐのか」
という点です。
アジャイル開発とSecurity Requirements Engineeringの統合を調査した先行研究でも、両者が自然には統合されにくいことや、そのためにセキュリティ固有のStory、役割、活動、能力などが追加されていることが報告されています。
そこで、セキュリティのために独立したBacklogやプロセスを作るのではなく、
プロダクトを作るためにすでに存在しているUser Storyそのものを起点にできないか
と考えました。
User Story Mappingに着目する
アジャイル開発では、プロダクトに必要なフィーチャーを洗い出し、整理し、優先順位を付けるためのさまざまな方法があります。
今回はその中でも、User Story Mappingに着目します。
User Story MappingはJeff Pattonによって体系化され、2014年にO'Reillyから User Story Mapping: Discover the Whole Story, Build the Right Product として出版されています。
User Story Mappingでは、ユーザーが目的を達成するまでの活動を流れとして捉え、その下に具体的なUser Storyを配置します。
そしてStoryを整理しながら、
「ユーザーが何をしようとしているのか」
「最初のリリースでは何が必要なのか」
「どこまで作ればユーザーに価値を届けられるのか」
をチームで考えます。
ここで少し視点を変えてみます。
User Story Mappingが、
「ユーザーは、このシステムで何をするのか」
を可視化するものだとすれば、
Attacker PersonaやMisuse/Abuse Caseは、
「攻撃者は、このシステムで何をするのか」
を考えるものだと言えます。
だったらUser Story Mappingで明らかになったUser Storyを、今度は攻撃者の立場から見直せばよいのではないか。
ここから考えたのが、今回提案する**防御駆動開発（Prevention-Driven Development: PDD）**です。
防御駆動開発（Prevention-Driven Development: PDD）
PDDは、まったく新しいセキュリティ理論を作ることを目的としていません。
既存の、
Threat Modeling
Attacker Persona / Persona Non Grata
Misuse Case / Abuse Case / Evil User Story
Cyber Kill Chain
User Story Mapping
Gherkin
といった考え方を、アジャイル開発の流れの中で接続することを目的としています。
その中心となる考え方は、
User Story Mappingで作ったUser Storyを、攻撃者の視点でもう一度見る
というものです。
そして、
誰が攻撃するのか
攻撃のどの段階なのか
何をしようとするのか
それを防ぐためにはUser Storyがどのような条件を満たす必要があるのか
を順番に考えていきます。
「誰が攻撃するのか」―― Attacker Persona
最初の軸がAttacker Personaです。
例えば、
- スクリプトキディ
- 国家支援を受けた攻撃者
- サイバーテロリスト
- 企業スパイ・産業スパイ
などを考えます。
Personaを変えれば、同じUser Storyを見ても想定する攻撃は変わります。
重要なのは、「攻撃者」という抽象的な存在ではなく、
目的や能力の異なる具体的な攻撃者の立場からUser Storyを見る
ことです。
「攻撃のどの段階なのか」―― Cyber Kill Chain
もう一つの軸として、攻撃の進行過程を考えます。
ここではLockheed Martinが提唱したCyber Kill Chainを利用します。
Cyber Kill Chainは、Eric M. Hutchins、Michael J. Cloppert、Rohan M. Aminによる2011年の論文 Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains で示されたモデルです。
攻撃を、
- Reconnaissance（偵察）
- Weaponization（武器化）
- Delivery（配送）
- Exploitation（脆弱性の悪用）
- Installation（インストール）
- Command and Control（コマンド＆コントロール）
- Actions on Objectives（目的の実行）
という7段階として捉えます。
PDDではこの既存概念をそのまま尊重して利用します。
したがってPDDでは、
Attacker Persona × Cyber Kill Chain × User Story
という組み合わせで攻撃を考えることになります。
User Storyを攻撃者の視点から見る
ここでUser Story Mappingに戻ります。
User Story MappingによってMVPに必要なUser Storyが定義されているとします。
通常は、それぞれのUser Storyについて、
「ユーザーにどんな価値を提供するのか」
「どのような条件を満たせば完成なのか」
を考えます。
PDDでは、そこにもう一つの問いを追加します。
「このUser Storyを、このAttacker Personaが攻撃するとしたら何をするだろう？」
さらにCyber Kill Chainを使って、
「攻撃のどの段階で、このUser Storyが利用される可能性があるだろう？」
と考えます。
具体的な攻撃が考えられるのであれば、それをMisuse Case、Abuse Case、Evil User Storyなどの先行する考え方を参考にして、攻撃者視点の攻撃ストーリーとして表現します。
PDDの流れを抽象化すると、
User Story Mapping
→ MVP
→ User Story
→ Attacker Persona × Cyber Kill Chain
→ 攻撃ストーリー
→ 防御のためのAcceptance Criteria
となります。
PDDで新しく提案したいのは、個々の技法そのものではなく、この接続の仕方です。
攻撃ストーリーをAcceptance Criteriaへ変換する
攻撃ストーリーを作るだけでは、実装には十分につながりません。
そこで、その攻撃が成功しないための条件をUser StoryのAcceptance Criteriaとして定義します。
その記述方法としてPDDではGherkinを利用します。
Cucumberの公式リファレンスでは、GherkinのScenarioを、
Given ...
When ...
Then ...
という形式で表現します。
Givenは初期状態、Whenはイベントや操作、Thenは期待される結果を表します。
PDDではこの構造をセキュリティにも利用します。
つまり、
攻撃者がある条件のもとで攻撃を試みたとき、システムが安全な結果になること
をAcceptance Criteriaとして表現します。
これによって、
脅威分析 → セキュリティ要求 → 実装 → テスト
をUser Storyから切り離さずにつなぐことを狙います。
さらにGherkinは実行可能な仕様として利用できるため、BDDや自動テストにつなげられる可能性もあります。
PDDは何が新しいのか
ここは誤解のないように整理しておきたいと思います。
今回調べた範囲では、PDDを構成する個々の考え方のほとんどには先行する研究や実践があります。
攻撃者をPersonaとして考える。
悪意のあるUse Caseを考える。
攻撃者視点のUser Storyを作る。
それをBacklogに入れる。
セキュリティ要求をAcceptance Criteriaとして表現する。
これら自体をPDD独自のアイデアとして主張するつもりはありません。
PDDで提案したいのは、それらを、
User Story Mappingを出発点として
MVPを構成するUser Storyに対して
Attacker PersonaとCyber Kill Chainという二つの視点から攻撃を検討し
Misuse/Abuse Storyとして具体化し
防御条件をGherkinによるAcceptance Criteriaへ落とす
という一連の流れとして整理することです。
言い換えると、新しい部品を発明するというより、
既存の優れた部品を、アジャイル開発者が扱いやすい一つの流れとして組み立て直す
というのがPDDの狙いです。
セキュリティを「別の仕事」にしない
PDDで実現したいのは、セキュリティ専門家だけが脅威を考える開発ではありません。
開発者、QA、Product Ownerなど、普段からプロダクトについて考えている人たちが、
「もし自分が攻撃者だったら、この機能をどう使うだろう？」
と考えることです。
セキュリティを開発の最後に追加するのではなく、User Storyを考える段階から攻撃者を登場させる。
そして、
ユーザーがやりたいこと
と同時に、
攻撃者がやりたいこと
も考える。
その攻撃を防ぐ条件まで含めてUser Storyを完成させる。
そうすれば、セキュリティは「開発とは別に行う特別な活動」ではなく、普段のプロダクト開発の一部になっていくのではないかと考えています。
既存の手法を置き換えるものではない
PDDはThreat Modelingなどの既存手法を置き換えるものではありません。
Threat Modeling、Attacker Persona、Misuse/Abuse Case、Evil User Story、Cyber Kill Chain、User Story Mapping、Gherkin。
それぞれ長年にわたって研究・実践されてきた考え方があります。
PDDがやろうとしているのは、それらとは別の理論をゼロから作ることではありません。
むしろ、
既存の優れた考え方を、アジャイル開発者が普段行っている活動の流れに沿ってつなぐこと
です。
Test-Driven Development（TDD）やBehavior-Driven Development（BDD）のように、アジャイル開発では「○○-Driven Development」という名前によって、開発するときに何を起点として考えるのかを表現することがあります。
PDDという名前にも同じ意図があります。
攻撃を受けた後に対処するのではなく、攻撃者が何をするかを開発時点で考え、未然に防ぐことを起点にする。
その考え方を、**Prevention-Driven Development（防御駆動開発）**と呼んでみよう、という提案です。
次は、実際にPDDをやってみる
ここまでの話だけでは、
「考え方は分かったけれど、実際にはどうやるの？」
という疑問が残ると思います。
次の記事では架空のWebサービスを題材として、
User Story Mapping
→ MVP
→ User Story
→ Attacker Persona
→ Cyber Kill Chain
→ 攻撃ストーリー
→ GherkinによるAcceptance Criteria
という流れで、実際にPDDを試してみたいと思います。
セキュリティを「最後に確認するもの」から「最初から一緒に考えるもの」へ。
PDDが、そのための一つの考え方になればと思っています。
参考文献・関連資料
-
John McDermott, Chris Fox, Using Abuse Case Models for Security Requirements Analysis, 15th Annual Computer Security Applications Conference (ACSAC), 1999.
-
Guttorm Sindre, Andreas L. Opdahl, Eliciting Security Requirements with Misuse Cases, Requirements Engineering, Vol.10, pp.34–44, 2005. DOI: 10.1007/s00766-004-0194-4.
-
Jane Cleland-Huang, How Well Do You Know Your Personae Non Gratae?, IEEE Software, Vol.31, No.4, pp.28–31, 2014. DOI: 10.1109/MS.2014.85.
-
Eric M. Hutchins, Michael J. Cloppert, Rohan M. Amin, Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains, Lockheed Martin Corporation, 2011.
-
Jeff Patton, Peter Economy, User Story Mapping: Discover the Whole Story, Build the Right Product, O'Reilly Media, 2014.
-
Maya Daneva, Chong Wang, Patrick van Sinderen, Security Requirements Engineering in the Agile Era: How Does It Work in Practice?, 2018 IEEE 1st International Workshop on Quality Requirements in Agile Projects (QuaRAP), pp.10–13, 2018. DOI: 10.1109/QuaRAP.2018.00008.
-
Microsoft, Secure by Design — Threat Modeling / STRIDE, Microsoft Security Engineering.
-
Cucumber, Gherkin Reference, Cucumber Documentation.
-
Lockheed Martin, Cyber Kill Chain®, Lockheed Martin Cybersecurity.
-
OWASP, DevSecOps Maturity Model — Creation of Advanced Abuse Stories, OWASP Foundation.