セキュアなソフトウェア設計を少しずつ、頻繁に行う
この記事では、脅威モデリングを採用したいチームを支援するための明確でシンプルな手順を提供します。脅威モデリングは、セキュアなシステムを設計するためのリスクベースのアプローチです。脅威を特定して、それに対する緩和策を開発することに基づいています。サイバーセキュリティのリスクが増大し、企業が責任をより意識するようになるにつれて、ソフトウェア開発チームはソフトウェアにセキュリティを組み込む効果的な方法を必要としています。残念ながら、彼らは脅威モデリングの採用に苦労することがよくあります。多くの方法論では、最新のソフトウェアチームの働き方に合わない、複雑で徹底的な事前分析が必要です。したがって、完璧な脅威モデルを作成するためにすべてを停止するのではなく、チームはシンプルに始めてそこから成長することを推奨します。
2020年5月28日
ジムはThoughtworksのテクノロジーコンサルタントです。彼の焦点は、リスクとソフトウェアおよびインフラストラクチャへのセキュリティの組み込みです。ジムはOWASPのチャプターリーダーでもあります。
構築しているソフトウェアのセキュリティ要件は何ですか？適切な答えを見つけるのは驚くほど複雑です。システムのライフサイクル全体にわたってサイバー損失を防ぎたいと考えています。しかし、その結果をもたらす具体的なストーリー、受け入れ基準、技術的範囲とは何でしょうか？それがこのガイドで取り上げられているパズルです。
グダグダグダグダ
あなたの脅威モデルは何ですか
-- ダン・カミンスキー
やや役に立たないことに、サイバー専門家はよく「あなたの脅威モデルは何ですか？」と尋ねます。この答えは非常に非具体的で不確実であり、「場合による」と言い返すようなものです。さらに、「脅威モデル」はほとんどの人にとって不明瞭な専門用語であり、不必要な神秘性を加えています。そして、脅威モデリングのトピックを調べると、情報が圧倒的で行動に移しにくい場合があります。「脅威モデル」やそれに類する合意された標準はありません。
では、脅威モデルとは何で、脅威モデリングとは何でしょうか？概念の核心は非常にシンプルです。サイバーセキュリティの損失に関連する原因を理解することです。その理解を利用して、リスクベースの方法であなたのシステムを保護することです。チェックリストに従うだけでなく、特定のケースでの潜在的な脅威から始めることを意味します。
システムの脅威モデルを理解するのは簡単ではありません。システムに対して想像できる脅威は無数にあり、それらの多くは可能性が高い可能性があります。脅威の現実は、多くの原因が組み合わさることです。サイバー脅威は、予期せぬ、予測不可能な、さらには混沌とした方法で連鎖します。文化、プロセス、テクノロジーに関連する要因がすべて貢献します。この複雑さと不確実性が、サイバーセキュリティ問題の根幹にあります。これが、ソフトウェア開発チームがセキュリティ要件に合意するのが非常に難しい理由です。
実際の侵害の背後にあるストーリーは、脅威と因果関係がどのように複雑になるかを示しています。詳細が驚くべきものであることがよくあります。NotPetyaのストーリーが良い例です。国家のマルウェアは「ShadowBrokers」と呼ばれるグループによって取引され、その後兵器化されました。最終的な影響は、ほぼランダムに組織に大きな損失をもたらしました。海運会社のMearskは、出荷の進行を停止する必要がありました。製菓会社のキャドバリーは、チョコレートの製造を停止する必要がありました。それぞれの脅威モデルは何でしたか？このような複雑な因果関係と付随的損害を想像できる開発チームはどれだけいたでしょうか？あなたのチームがこれをモデル化し、他のすべての危険な可能性をモデル化するのにどれくらいの時間がかかるでしょうか？
脅威モデリングは複雑すぎて価値がないのでしょうか？開発者はチェックリストに従い、「指を交差」させて運が良くなることを期待するだけでよいのでしょうか？懐疑主義は健全な場合もありますが、脅威モデリングを学ぶことは開発者にとって重要なスキルであると私は信じています。必要なのは適切なアプローチと、複雑さを抑制するためのツールです。このガイドはその精神で書かれており、良好なリスクベースのセキュリティ要件を特定するのをはるかに簡単にする3つのアイデアから始まります。
最初の推奨事項は、少なくとも最初は、広範な脅威よりも技術的な脅威に焦点を当てることです。
このガイドに従うことで、主に技術的な脅威を見つけることに焦点を当てます。システムの構造とデータフローは確実なものであるため、これにより詳細化プロセスが簡素化されます。しかし、それはあなたがソフトウェア開発者としての既存の強みから、つまり技術的なものを理解することから始めることができることを意味します。これは、あなたがほとんど知らない可能性のある脅威の発生源の高度なリスク分析から始めるよりもはるかに強力な基盤です。
ただし、全体像を完全に忘れないでください。広範な脅威の可能性についての現実的でリスクベースの理解は、ある技術的な脅威を別の技術的な脅威よりも優先するのに役立ちます。たとえば、単純な人的エラーは通常、国家による攻撃よりもはるかに可能性が高いです（サイドバーを参照）。その考え方は、最初に調査を開始するセキュリティ範囲を選択する際に役立ちます。最初に技術的な脅威を特定することに焦点を当てると、それらを修正と追加のコントロールを正当化する広範な脅威に結び付けるのがはるかに簡単になります。
2番目の推奨事項は、協力的なチームベースのアプローチを採用することです。セキュリティ要件を特定するのは簡単ではなく、多様な視点を持つことで、より良い意思決定につながります。常に別の脆弱性や技術的な脅威が見つかるため、この演習に幅広い視点を取り入れることで、ブレインストーミングがより堅牢になります。また、最も重要な脅威を特定する可能性も高まります。グループでの脅威モデリングは、リスクに全体的に対処するのに役立ち、チーム全体がセキュリティについて効果的に考え、話し合う方法を学ぶのに役立ちます。
リスク管理の観点から、プロダクトオーナーを巻き込むことは絶好の機会です。プロダクトオーナーは、ソフトウェア開発者が単に欠いているユーザーの行動とビジネスコンテキストに関する洞察を持っています。彼らは、ビジネスに対する特定のサービスの価値と、そのデータが公開または失われた場合の影響について知っている必要があります。サイバーセキュリティの損失が発生した場合、それはビジネス上の損失です。最悪の事態が発生した場合、その原因はあなたの組織とあなたが使用しているテクノロジーに特有のものである可能性があります。サイバーセキュリティの問題は、技術的なボックスにチェックを入れるだけでなく、ビジネスを保護するための適切な投資決定を行うことです。
3番目の推奨事項は、「少しずつ、頻繁に」脅威モデリングを開始することです。チームとの各脅威モデリングセッションは、すぐに配信できるものにすばやく消化できる程度に短く、焦点を絞ったものである必要があります。可能な限り薄いシステムの断片、つまり現在取り組んでいるものだけを分析することから始めます。システム全体を事前に分析しようとするのではなく、脅威モデリングを少しずつ行うことで、チームの筋肉の記憶を構築します。
完全に指定されたソフトウェア設計を必要とするプラクティスは、アジャイルチームの働き方と一致しません。脅威モデリングを網羅的な事前分析にする必要はありません。チームが脅威モデリング[1]への包括的で高度に構造化されたアプローチに圧倒されることがあまりにも多くあります。私はそのようなアプローチを試して、実際の脅威が特定される前に時間と忍耐力が尽きたチームを見てきました。修正が配信されることは言うまでもありません！
網羅的な「脅威モデル」ドキュメントを作成および維持するのではなく、「少しずつ、頻繁に」脅威モデリングを行ってください。このように作業すると、各脅威モデリングセッションは非常に小さく、影響はほとんどありません。しかし、それらを行う累積的な効果は非常に大きいです。この作業をイテレーションごとに再び行うことがわかっている場合は、すべてを一度に行おうとする動機は少なくなり、今最も重要な作業を優先する動機が大きくなります。
ガイドのこのセクションでは、チームで脅威モデリングを開始するための計画を立てることができるように、より詳細かつ具体的に説明を開始します。
脅威モデリングセッションの単純な構造を理解し、少し計画を立てることは、素晴らしい結果を得るのに大いに役立ちます。
最初に紹介するのは、脅威モデリングのためのシンプルで柔軟な構造です[2]。これは3つの重要な質問に基づいています。この構造を記憶にコミットするのに役立ちます。脅威を評価する必要がある場合はいつでも、3つの質問構造をガイドとして使用できます。自転車に乗るのと同じように、基本をマスターすれば、これらのスキルを応用して成長させることができます。
| アクティビティ | 質問 | 結果 |
|---|---|---|
| 説明と探索 | 何を構築していますか？ | 技術図 |
| 脅威をブレインストーミングする | 何がまずい可能性がありますか？ | 技術的な脅威のリスト |
| 優先順位をつけ、修正する | 何をしますか？ | 優先順位付けされた修正がバックログに追加されました |
このガイドは、3つの質問構造に従っています。脅威モデリングの各セッションでは、各質問に答えるのに約3分の1の時間を費やす必要があります。そうすれば、有益な結果が得られます。ガイドの残りの部分では、この基本的な構造を、より詳細な手順、ヒント、および説明に分解して、脅威モデリングセッションを成功させるのに役立てます。
脅威モデリングセッションを実行する前に、いくつか整理しておく必要があります。以下のヒントは、計画に役立ちます。
各セッションには、技術担当者と非技術担当者の両方を含む、デリバリーチーム全体を参加させるようにしてください。これにより、より多くの視点とアイデアがテーブルにもたらされるだけでなく、共通の理解が構築されます。プロダクトオーナー、ビジネスアナリスト、デリバリーマネージャーを除外すると、セキュリティ上の欠陥を修正する作業が完了しない可能性があります。価値が広く理解されないためです。
脅威モデリングを開始して貴重なセキュリティ範囲を発見するために、セキュリティの専門家は絶対に必要ありません。ただし、脅威モデリングセッションは、専門家、セキュリティアーキテクト、またはリスク管理チームと協力する絶好の機会です。それはすべて、組織内の役割と専門知識がどのようなものであるかによって異なります。
開始にあたっては、90分のセッション長をお勧めします。チームに、構造と関連するセキュリティの概念を学ぶための時間とスペースを与える必要があります。ただし、いったん開始すれば、物事ははるかに速くなるはずです。私が今まで参加した中で最も影響力のある脅威モデリングセッションは、15分未満で終わりました。チームの全員が練習で「筋肉の記憶」を構築すれば、短く簡潔なセッションが可能になります。
脅威モデリングセッションの頻度についてよく尋ねられます。正解はないと思います。チームによって異なります。私は脅威モデリングを他のチームデザインセッションと同じように考えています。毎週必ず実施しなければならないというように、厳格にはしません。ただし、スプリントごとに脅威モデリングを行うことを正当化するリスクプロファイルを持つ多くのチームと協力してきました。もう一方の極端な例として、脅威モデリングをまったく行わないスプリントが数回続いている場合は、その実施は、成熟しているとはみなされないほど継続的ではありません。
対面での脅威モデリングセッションは、会議室や、スペースがあればチームの通常の作業エリアで、より非公式に行うことができます。典型的なセッションでは、図を描いて範囲を説明および調査し、脅威をブレインストーミングし、バックログの修正の優先順位を付けます。ただし、対面セッションが常に可能とは限りません。
リモートでセッションを実行する場合は、全員が仮想的に参加できるように、少し異なる計画を立てる必要があります。ビデオ会議ツールとコラボレーションツールが必要になります。これらのツールを事前に合意して設定します。Thoughtworksのチームは、Mural、Miro、Google Jamboard、Googleドキュメントなど、さまざまなツールで成功を収めています。
セッションの前にツールに慣れ、参加者がアクセスできることをテストしてもらいます。どのツールを選択する場合でも、ツールを使用するためのセキュリティ承認が組織から得られていることを確認してください。脅威モデリングの出力は、さまざまな理由で機密情報を表しており、保護する必要があります。
リモートで作業する際に留意すべきヒントを次に示します。
セッションがリモートであろうと対面であろうと、時間どおりに終了することを目指してください。そして、具体的な成果を上げて！これには規律が必要です。タイムスケジュールを促進するのは、ワークショップセッションを成功させる経験のあるデリバリーマネージャーまたは誰かが担う役割になる可能性があります。
Thoughtworks GermanyのMona FenzlとSarah Schmidは、Muralというコラボレーションツールを使用して成功を収めています。彼らはそれを使用して、他のチームがそのツールを使い始めるのに役立つ脅威モデリングテンプレートを作成しました。
セッションの適切な焦点と詳細レベルを決定することを「範囲の特定」と呼びます。人々を集めて活動を実行する前に、これを決定していることを確認してください。今最も価値のあるものに導かれてください。もしかしたら、今回のイテレーションで作業しているユーザーストーリーだけかもしれません。
一度に多くの範囲をかじりつこうとしないでください！一度にシステム全体を脅威モデリングしようとすると、利用可能な時間内に何も発見できないか、大幅に時間超過になり、再度実行する意欲や予算がなくなるでしょう。脅威モデリングを管理しやすい塊に時間を区切り、「少しずつ頻繁に」活動を実行する方がはるかに優れています。
以下に、うまく機能した範囲の例をいくつか示します。
チームが選択する範囲に関係なく、利用可能な時間でカバーするには大きすぎないようにしてください。
ガイドの残りの部分では、脅威モデリングに関わる具体的な手順を示すために、実際の機能を使用します。小売組織に、家庭配達用の食料品を販売するプラットフォームを構築している開発チームがあります。これは、次のスプリントでの彼らのエピックです。
顧客として、自分の顧客詳細を確認できるページが必要です。これにより、詳細が正しいことを確認できます。
オンラインストアを使用したことがある場合は、住所の詳細を更新し、おそらくロイヤリティカードの残高を確認するために使用されるページを想像できるでしょう。
経験上、このサイズの機能は、脅威モデリングセッションにとってかなり妥当な範囲です。
古い画像をWikiから引っ張り出そうとしないでください。システムが現在どうなっているか、またはすぐにどうなるかを話し合うことで、共通の理解が構築されます。
「何を構築していますか？」
図は、ソフトウェアの構造と、コミュニケーションを図るように設計された方法を説明および調査するのに最適なツールです。このガイドのセクションでは、脅威モデリングセッションの基礎となる図に関する詳細なヒントを提供します。
図を描くと、全員が同じ認識を持つことができます。脅威、リスク、軽減策を考え始める前に、扱っているソフトウェアまたはインフラストラクチャに関する共通の技術的理解が必要です。
幸いなことに、開発者はソフトウェア設計を調査するために図を描くことに慣れているでしょう。ホワイトボードまたはフリップチャートに、合意した範囲の簡単な技術図を描くことによって、これらの確立されたスキルを活用してください。
洗練されたものである必要も、完璧である必要もありません。メインコンポーネントのボックスを描いてラベルを付けるだけです。
最終的に、システムは人々が何かを行うことを許可するように設計されています。ユーザーは、システム内で何かを行うことを許可された人々であるため重要です。図にそれらを表してラベルを付けます。
信頼とは、基本的に誰または何が特定のことを行う自由を持つべきかということです。セキュリティにとって重要であるため、それらの「アクター」を必ず説明してください。
上記で紹介した実際の機能に戻り、チームが新しい「顧客詳細ページ」機能をどのように説明することにしたかを見てみましょう。彼らは次の図を描きました。
これは、システムが
これらのテクノロジーの詳細な知識は、このガイドに従うために必要ありませんが、これらの事実は、図を描いている間に議論する必要がある詳細レベルを示しています。
データがシステム内でどのように流れているかを示すために詳細を追加することが重要です。
攻撃者は多くの場合、正規ユーザーが使用するのと同じ経路を使用してシステムをピボットします。違いは、彼らがそれらを悪用するか、誰もチェックすることを考えなかった方法で使用することです。したがって、システム周辺の信頼できるパスを示すことは、実際の脅威が発生する可能性のある場所を確認するのに役立つため、重要です。
ユーザーとコラボレーションシステムから始まる、矢印でデータフローを示します。最近では、ほとんどのデータフローが要求/応答であるため、双方向です。ただし、要求の発生元から方向矢印を描くことをお勧めします。経験上、これにより、後で脅威をブレインストーミングすることがはるかに簡単になります。
脅威は、特定のネットワークから発生する可能性が高くなります。ネットワークは、ある場所から別の場所へのトラフィックのフローの自由を制限するように構成されています。その制限（または開放）は、どのような脅威が可能または可能性が高いかを判断するのに役立ちます。オープンインターネットは、十分に保護されたバックエンドネットワークよりも危険です（バックエンドネットワークがクラウドプロバイダーによってホストされているVPCであっても）。
別の色で、点線を描いて、システム内の異なるネットワーク間の境界を示します。これらは多くの場合、「承認境界」と呼ばれます。ロードバランサーやファイアウォールなどのゲートウェイデバイスを説明する価値がある場合もあります。他の場合には、それらのデバイスがそのセッションの範囲にとってそれほど重要ではない場合もあり、それでもかまいません。不明な場合は、次のセッションにDevOpsまたはインフラストラクチャの知識を持つ人を招待するのが理にかなっている可能性があります。
今回のケースでは、顧客が自分の詳細を見たいという要望から、UI、そしてBFFサービス、さらに顧客詳細リソースサーバーへとデータが流れ、データを取得または更新する様子を矢印で示しています。また、セッションを認証するトークンを発行するIDサーバーへのデータの流れもあります。
UIはインターネット上にあり、その他のコンポーネントは組織のクラウドホスティング内にあるため、認証境界も存在します。
ビジネス価値のあるデータやサービスがどこにあるかを、図に簡単に示すと役立ちます。例えば、個人データを保存する場所などが該当します。システムが支払いを処理する場合は、おそらく支払いを行うサービスでしょう。システム内の資産は、機密に保つ必要がある情報や、完全性を保つ必要がある情報、そして可用性を維持する必要があるサービスです。
このステップに時間をかけすぎないでください。目的は、ブレインストーミングと優先順位付けを支援するための少しのコンテキストを提供することです。これに5分以上費やす場合は、おそらく長すぎます。
チームは、顧客サービスが保存する個人識別情報（PII）と、IDプロバイダーのクレデンシャルストアを、最もビジネス価値の高い資産として特定しました。
「何が起こりうるか？」
セッションの第2部では、作成したシステムの脅威をブレインストーミングします。このセクションでは、関連性の高いセキュリティの脅威を幅広く洗い出すのに役立つ詳細な手順とヒントを提供します。
チームが脅威モデリングを始めたばかりの場合は、STRIDEが最適です。STRIDEは、セキュリティの脅威をブレインストーミングするための手始めとなる非常に軽いフレームワークです。これは頭字語で、各文字はセキュリティの概念を表します。重要なのは、見つけたものを分類することではなく、効果的にブレインストーミングをすることです。
始める前に、6つのセキュリティ概念をチームで理解し、議論するために時間を費やしてください。学習を助けるために、ThoughtworksはSTRIDEキューカードを作成しました。これらの6枚のカードは、すぐ下にリンクされています。裏面には例のリストも含まれています。
インターネット上では、あなたが犬であることを誰も知らない。
データがオーバーフローして命令になることはありますか？
証拠がないと、それが起こったことを否定するのは簡単です。
他に誰が見ている可能性がありますか？
サービスがダウンする可能性はありますか？
保護を回避するのはどれくらい簡単ですか？
特定のソフトウェアを攻撃したり、破壊したり、妨害したりする方法を考えることは、脅威モデリングの本質です。それはまた、とても楽しいものでもあります！
グループの全員が脅威を提案します。最も多様な脅威を見つけることが良いことです。私たちは「ハッピーパス」よりも可能性に関心があります。いくつかの奇抜なアイデアも役立ちます。全員が参加し、単一の声が支配することを許さないようにすることで、その多様性を促進します。誰でもペンと付箋にアクセスできるようにし、バックグラウンドや経験に関係なく、少なくとも1つの潜在的な脅威を提案するようにしてください。
創造的で発散的な思考を使用し、グループに存在する経験とさまざまな視点を活用してください。後で、最もリスクが高いまたは重要な脅威に優先順位を付けるので、潜在的な脅威が多すぎる危険性はありません。
インスピレーションが必要な場合は、図のデータフローラインを1つずつ追ってみてください。STRIDEの概念の1つが、そのデータフローにどのように適用できるでしょうか？それが対処する必要がある特定の脅威を示唆していますか？この方法で作業すると、攻撃者が使用する可能性のある技術的なメカニズムとデータフローを特定するのに役立ちます。
サイバー攻撃へのデータフローは、作成した信頼できるデータフローと同じように存在します。攻撃者は、信頼できるユーザーのために設置されたのと同じ経路を使用して、システムをピボットします。サイバーセキュリティの損失は、技術レベルで悪いことを防ぐための制約が不十分な場合に発生します。
各脅威について、それをキャプチャするのに少し時間を費やしてください。「インターネットからのSQLインジェクション」、「データベース内の暗号化の欠如」、「多要素認証の欠如」が良い例です。「このデータを保存する必要がありますか？」、「認証バイパスが発生する可能性がありますか？」、「退職者のアカウントを誰が取り消しますか？」のような質問も良いでしょう。
これらの付箋を、特定のユーザー、コンポーネント、またはデータフローの横など、図の特定の場所に自然に配置することがわかります。付箋の意味がわかる程度の詳細を含めて、次の脅威のブレインストーミングに移ります。
以前に作成した図を使用して、チームはSTRIDEを利用して、システム内の各データフローについてブレインストーミングを行いました。
ソフトウェアのメカニズムで潜在的な脅威を発見したら、付箋に書き込み、ローファイ図に注釈を付けます。
セッションのブレインストーミング部分の終わりに、彼らが思いついたものは次のとおりです。
脅威の多くは、データフローがインターネットからシステムへの認証境界を越える場所で発生したことに注意してください。ただし、ブラウザベースのUIとバックエンドネットワーク内でも脅威が特定されました。
これで、グループが作成した図を、脅威の注釈を付けて構築します。
「それについてどうするつもりですか？」
ソフトウェアチームはデリバリーを行うインセンティブを与えられており、特定されたすべての脅威に対処するために離れていくための帯域幅が限られていることがよくあります。また、一部の脅威はごくわずかなリスクしか及ぼさない可能性があります。効果的に持ち帰り、実行できる最も重要なアクションを絞り込み、優先順位を付ける必要があります。
システムのリスクプロファイルについて私たちが知っていることの共通理解を得るのに役立ちます。これに5分以上費やさないでください。大まかに言って、脅威を優先順位付けする際に役立つ知識には2種類あります。プロダクトオーナーやセキュリティチームは、共有するのに優れた洞察を持っていることがよくあります。
グループの誰もより広範なリスクについての洞察を持っていない場合でも、問題ありません。この知識へのアクセスは前提条件ではありません。技術的なリスクのみに基づいて優先順位を付けることができ、脅威モデリングから大きなメリットを得ることができます。
これは、以前にレトロスペクティブやワークショップで「ドット投票」を行ったことがある人なら誰でもよく知っているはずです。誰もがいくつかの票を取得し、最もリスクの高い脅威に投票します。最初のセッションでは、おそらく1人あたり3票で始めます。ただし、グループの人数と見つけた脅威の数によって異なります。目標は、最初に始めるための最も価値のある脅威に絞り込むことです。リスクは、脅威が発生する可能性が高いだけでなく、潜在的な損失の規模も考慮に入れる必要があることに注意してください。
誰もが、リスクに対する自身の認識に従って、ドットを使用して投票します。
誰もが付箋にドットをマークして投票する必要があります。誰もが固定数の票を取得します。それが正しいと思う場合は、同じ脅威に複数回投票してもかまいません。
この方法で投票すると、グループ内の多様な視点を反映して、少ない投資で優れたリスク判断が得られます。人々はリスクに対する直感的な感覚を持っており、最小限の促しで投票することができます。
各脅威に対する投票数を数え、最も多くの票を獲得したものを何らかの方法でマークする必要があります。おそらく、最もリスクの高い脅威をペンで囲みます。
セッションで特定すべき脅威の数についてよく質問されます。最初は、3つが良い数になる可能性があります。それは、投資された時間のバランスが取れています。ただし、自分の判断で使用して実験してください。非常にリスクの高い項目が1つあるかもしれません。今すぐ対処するのが理にかなっています。同様に、1回のセッションから4つまたは5つの脅威が出現する可能性があります。
ブレインストーミングと優先順位付けの結果をキャプチャするために、この段階で携帯電話のカメラを使用して写真を撮ります。リモートツールを使用している場合は、スクリーンショットまたはエクスポートを実行できます。画像をWikiにアップロードしたり、どこかのリポジトリに保存したりすることは非常に理にかなっています。
チームによる時間の投資がフォローアップ作業につながることが不可欠です。ソフトウェアチームには、ソフトウェアを配信するためのアクティビティを表現および順序付けるための強力な方法が既にあります。バックログです。リスクを軽減するために実際に必要な修正を決定する時が来ました。チームの既存のプロセスと作業方法を使用して、これをサポートします（サイドバーを参照）。
優先順位付けされた各脅威について、具体的な次のステップを定義します。セキュリティの用語では、これらを「コントロール」、「緩和策」、「セーフガード」、または単に「セキュリティ修正」と呼ぶことができます。これらの修正には、さまざまな形式があります。修正が「完了」したとき、つまりリスクが軽減されたときが明確になるように、これらの修正を具体的にします。
セッションでカードや紙に修正を書き留めた場合は、誰かがそれらをプロジェクト追跡ツールまたはアジャイルボードに追加する責任を負うようにしてください。理想的には、プロダクトオーナーが脅威モデリングセッションに参加します。そうでない場合は、優先順位付けを適切に行えるように、作業を優先順位付けする担当者に脅威について説明するアクションを起こしてください。
脅威モデリングが影響を与えることを確実にする最良の方法は、修正を配信してから再度脅威モデリングを行うことです。
投票の結果、チームは3つの脅威が最もリスクが高く、修正する価値があると判断しました。
APIへの直接的な承認バイパス
ユーザーはページを閲覧するためにログインする必要がありますが（認証されています）、チームは認証されていないリクエストがAPIに直接送信されるのを防ぐものは何もないことに気づきました。これが本番環境に組み込まれていた場合、かなり重大な欠陥になったでしょう！チームはセッション前にはそれに気づいていませんでした。
チームは、ストーリーのサインオフの一部として明示的にテストできるように、次の受け入れ基準をストーリーに追加しました。
シングルページアプリからAPIへのAPIリクエストがある場合
リクエストに含まれている現在のユーザーの有効な承認トークンがない場合
APIリクエストは承認されていないため拒否されます
ユーザー入力を介したXSSまたはインジェクション
ユーザープロファイル機能では、個人情報、住所、配送設定をユーザーが入力できます。これらの詳細は、SQLおよびXMLインジェクション攻撃に対して脆弱な可能性のあるさまざまなレガシーバックエンドシステムによって解釈されます。
チームは、今後のイテレーションでユーザーからの入力を受け入れてバックエンドに保存する多くの機能を実装することを知っていました。このようなチェックをすべてのストーリーに追加するのではなく、チームの完了の定義に以下を追加しました。これは、ストーリーのサインオフで一貫してチェックできることを意味します。
すべてのAPI変更は、XSS、SQL、およびXMLインジェクションのサニタイズについてテストされています
インターネットからのサービス拒否
サイバーリスクチームからセッションに参加したセキュリティスペシャリストは、オンライン犯罪者による分散型サービス拒否による収益の損失が彼らの仕事で強調されているとアドバイスしました。
この要件には、コンテンツ配信ネットワーク（この場合はサードパーティのセキュリティサービス）とのソフトウェアの統合が含まれるため、チームは必要な作業をキャプチャするために特定のストーリーを作成しました。セキュリティスペシャリストは、実装でチームとペアを組むことに同意しました。
サイバーリスクスペシャリストとして
オンライン犯罪者によるサービス拒否による収益損失を軽減できるように、インターネットに面しているすべてのUIおよびAPIリクエストがコンテンツ配信ネットワークを通過する必要があります
そうすることで、犯罪者によるサービス拒否による収益損失を軽減できます
作業が定義され、バックログに追加する準備ができたので、脅威モデリングセッションは完了です。また次回！
「私たちは十分に良い仕事をしたのか？」
このガイドの冒頭で、3つの質問構造を紹介しました。しかし、常にフィードバックを得て改善する必要があるため、実際には4つの質問があります。
フィードバックと継続的な改善は、リスク管理の中心です。ガイドの冒頭で強調したように、構築するシステムも、システムが直面する脅威も単純ではありません。そして、すべてのチームは、異なるスキル、ツール、制約、および個性を持っています。脅威モデリングに単一の方法はなく、このガイドは開始するためのいくつかの基本を提供するだけです。テスト駆動開発や継続的なデリバリーと同様に、脅威モデリングは投資に報います。
改善するための1つの方法は、いくつかのセッションを実行した後、脅威モデリングの取り組みについて振り返りを行うことです。何がうまくいったか、何が改善できるかを尋ねてください。タイミングは適切ですか？スコープは細かすぎましたか？十分に細かくありませんでしたか？使用した場所やリモートツールはどうですか？セッション後にどのような問題が発生しましたか？スコープの配信にはどのくらいの時間がかかりましたか？そのような質問をすることで、チームは時間の経過とともに適応し、習熟度を上げ、効果的なものを倍増させ、付加価値の低いものを破棄します。
時間の経過とともに、チームや組織に最適なプラクティスを育成できます。次に、いくつかの次のステップのアイデアを示します。
セキュリティにおける多くの「ソリューション」は、開発者の手からセキュリティを遠ざけるように設計されているようです。それはそれらを悪いソリューションにするわけではありません。パイプラインの自動チェックは、脆弱性を発見するのに効果的です。使用する必要があります。ペネトレーションテストでは、自分自身では見つけられない問題を見つけることができます。安全なデフォルトを備えたプラットフォームは、多くの一般的な脅威を排除できます。ただし、各「ソリューション」は、限られたクラスの脅威にのみ対処します。一方、サイバーリスクは単純なものではなく、多面的で絶えず変化しています。このリスクを理解することは、それを管理するための効果的なアプローチの中核です。
脅威モデリングのキラーアプリケーションは、チーム全体でセキュリティの理解を促進することです。これは、セキュリティを誰もが責任を負うようにするための最初のステップです。ビジネス成果、品質、統合、インフラストラクチャと同様に、セキュリティはソフトウェア配信に対するチームの考え方の中心になる可能性があります。最後に付け加えるものではなく。私の経験では、脅威モデリングの筋肉の記憶を持っているチームは、サイバーリスクを積極的に管理するチームです。
脅威モデリングは、ほとんどの開発チームにとって難しすぎると言われたのを覚えています。私はそれが事実であることを認めるつもりはありませんでした。開発者がセキュリティに対処する方法を改善する機会を理解しました。それ以来、私は多くのチームが脅威モデリングを開始し、セキュリティを適切に理解するための旅を支援してきました。アクセスしやすい方法で説明した場合、脅威モデリングやセキュリティが難しすぎると感じたチームには、一度も出会ったことがありません。
私は、脅威モデリングがソフトウェア開発チームにとって変革的なプラクティスであると信じています。継続的に適用できる協力的でリスクベースのプラクティス。ソフトウェアチームの一員である場合は、この記事をチームに送信し、脅威モデリングセッションを提案してください。または、組織でソフトウェアセキュリティを担当している人に転送してください。セッションを実行するために少し時間を割くことで、開始できます。システムの脅威、リスク、および必要なセキュリティ修正を理解し始めることで、効果的なサイバーセキュリティに一歩近づきます。
このガイドがあなたのチームが脅威モデリングを開始するのに役立つことを願っています。少なくとも、セッションはすぐに価値を提供する必要があります。優れたセキュリティストーリーと受け入れ基準がバックログに追加されます。この方法は、Thoughtworksのクライアントの多くの開発チームがサイバーセキュリティへの包括的なアプローチを採用するのに役立ちました。皆様のお役に立てれば幸いです。
この記事の初期草稿について詳細かつ思慮深いフィードバックを提供してくれたMartin Fowler、Adam Shostack、Charles Weir、Avi Douglanに感謝します。洗練さやニュアンスは彼らのおかげです。
リモートで脅威モデリングセッションを実行するためのガイダンスを手伝ってくれたThoughtworksのNalinikanth Meesala、Mona Fenzl、Sarah Schmidに感謝します。ガイドのそのセクションについては、彼らがすべての功績に値します。
脅威モデリングが「単純」ではないことに気づくのを手伝ってくれた、英国国立サイバーセキュリティセンターの社会技術グループ（およびRISCSの下の開発者中心のセキュリティ研究ポートフォリオ）の人々に感謝します。
入力と知恵のオープンな共有のために、OWASP脅威モデリングプロジェクトに参加するすべての人々に感謝します。
私の意識の流れから読みやすい文章を抽出するのに役立った、素晴らしい校正をしてくれたKatie Larsonに感謝します。
STRIDEキューカードを素晴らしいものにしてくれたThoughtworksマーケティングのPete StaplesとJeni Oglivyに感謝します。そして、このWebページ用にフォーマットするのを手伝ってくれたMatt Pettittに感謝します。このガイドのすべての画像が提供されたUnsplash.comのカメラマンにクレジットを付与します。
脅威モデリングに関する私たちのアプローチとガイダンスの改善にご協力いただいたThoughtworksの皆様に、心より感謝申し上げます。特に、Harinee Muralinath、Jaydeep Chakrabarty、Fulvio Meden、Neelu Tripathy、Robin Dohertyには格別の感謝を申し上げます。
1: 言及する価値のある構造化されたアプローチには、PASTAとOCTAVEがあります。これらのアプローチは、専任のセキュリティ専門家が実施することを想定しています。また、事前に大規模な設計を行うことを好む環境に適しています。役立つ点は多くありますが、アジャイル環境のソフトウェア開発者は、これらの手法を意味のある形で採用するのに苦労するでしょう。これらのガイドに従うと、多くの成果物（通常は攻撃ツリー！）を生成することに多大な投資を行うのが一般的なパターンです。そして、「予算を使い果たし」、チームはリスクを軽減するソフトウェアの変更をやり遂げることができません。
2: 脅威モデリングについて広範に執筆し、このガイドに関するフィードバックを提供してくれたアダム・ショスタック氏は、この3つの質問構造の功績を認めています。彼はさらに4番目の質問「私たちは十分に良い仕事をしたか？」を追加しています。脅威モデリングの成果を振り返り、改善する必要があるというアダムの意見には異論はありません。しかし、この質問は別の場所で対応できると考えているため、基本的な構造からは省略しました。フィードバックに基づいた反復と改善は、特に「小さな単位で頻繁に」脅威モデリングを行う場合は、アジャイルソフトウェア開発において暗黙的に行うべきです。このガイドの最後のセクションでは、チームの脅威モデリングの成果を振り返り、改善し、成長させる方法について説明します。
2020年5月28日: 最終回を公開
2020年5月27日: 優先順位付けと修正を公開
2020年5月26日: 脅威のブレインストーミングを公開
2020年5月20日: 説明と調査を公開
2020年5月19日: 開始準備を公開
2020年5月18日: 最初のセクションを公開