脅威モデリング

脅威モデリングとは、確立されたまたは新しい手順を取り上げ、それを潜在的なリスクについて評価するプロセスです。多くのテック企業にとって、これは通常、コードとコードの変更を伴います。しかし、このプロセスは潜在的なリスクが存在するあらゆる状況に適応でき、私たちの多くが日々行っていることです。車に行くまでの暗い路地のショートカットではなく、長くてもよく明かりが灯った道を選ぶこと。道を渡る前に左右を確認すること。これらは私たちが本能的に行っていることです。

GitLab のコンテキストでは、評価する異なるリスクがあります。私のコード変更は製品にセキュリティ脆弱性を導入するか？導入される会社の急進的な新方針は外部からの批判を生み、GitLab の評判を傷つけるか？この既存のコードライブラリの脆弱性を最後に評価したのはいつか？新しい販売キャンペーンが新規市場に進出する際に直面する可能性のある潜在的な落とし穴は何か？これらは、他のあらゆる企業と同様、私たちが常に対処しているリスクです。

はじめに

脅威モデリングを始めるのに役立つリソースをいくつか紹介します。

こちら（プライベートリンク）から利用できる Issue テンプレートを開発しており、脅威モデルを文書化する Issue を作成するために使用できます。脅威モデル Issue を作成する際は、エンジニアリングが技術文書を提供することが必須です。また、アプリケーションの分解、ユースケース、外部エントリーポイント、信頼レベル、データフロー図、および以前のセキュリティ Issue（もしあれば）のセクションを記入することも要請しています。

私たちの脅威モデリングは PASTA に基づいています。完全な PASTA 脅威モデルは通常 7 つのステップを含むため必要ないことが多く、多くの場合、ステップ 4、5、6 のみが必要です。さらに簡単にするために、STRIDE を使って脅威を定義することもできます。

そのため、初心者向けの脅威モデリングのハウツーガイド を含めており、脅威モデリングが初めての方はぜひ読んでください。STRIDE の使用に関する詳細も含まれています。追加のサポートが必要な場合は、AppSec チームにピンを送るか、#security_help Slack チャンネルでお問い合わせください。

PASTA 評価のサンプル

これは敵対的な環境における GitLab スタンドアロンインスタンスのインストールの実際の評価サンプル です。

さらにサンプルは後ほど追加されます。

GitLab における脅威モデリング

GitLab のようなテック企業における脅威モデリングの最も一般的な使用先は、私たちのコードベースです。セキュリティチームは、次の点を念頭に置いて、エンジニアリング向けの脅威モデリング「フレームワーク」を開発しました:

• 理解しやすく従いやすいフレームワークを確立すること
• フレームワークは DevSecOps を強化し、最小限のオーバーヘッドを導入するべきこと
• 可能であれば、現在の GitLab チームメンバーに馴染みがあるであろうため、確立された実績のある既存のフレームワークに基づくべきこと
• セキュリティチームが人気で成功している HackerOne バグバウンティプログラムを支援し、コンプライアンスのニーズを処理し、私たちの資産に対するセキュリティ脅威に対処していることから、リスク分析プロセスに「フィードバック」を提供できるフレームワークを持つことは、実際の結果を判断するうえで非常に重要です
• フレームワークは、エンジニアリング以外の他の GitLab チームでも使えるほど柔軟であるべきこと

GitLab 脅威モデリングプロセスの目的は、将来の AppSec コードレビュー の出発点を提供することです。脅威モデルはアプリケーションの概念的なアーキテクチャに基づいており、可能な場合のみ検出事項を裏付けるためにコードを利用します。

なぜこれを行うのかと尋ねる方もいるかもしれません。私たちの理由は次の重要な点を含みます:

• セキュリティチームはすでに常にリスク分析と評価を行っており、これは私たちに共通言語を与えます
• 共通言語は、特に非同期コミュニケーションを利用するオールリモート企業において、エンジニアリンググループ間のより良いコミュニケーションを可能にします
• パートナー、顧客、コントリビューターと対峙する際に、議論に使える共通の参照点があります
• 成熟した堅牢なコードベースを持つセキュアな企業であることが私たちの目標であり、これはその努力に役立ちます
• 私たちはすでに大きなコードベースを持っています——すべてをゼロから書き直して再分析するのではなく、脅威モデリングは新しい変更を評価して将来のリスクを軽減するのに役立つツールを与えてくれます。セキュリティ Issue をトリアージしたり、新しいセキュリティ関連機能を導入したりする際に、セキュリティとリスクに関連する組織的および技術的負債を、より消化しやすいピースで処理するためのツールがあります。

全体的な目標は、厳格に従わなければならない硬いストラクチャーを作ることではなく、セキュリティリスクが発生する前にプロアクティブに発見し、リスクの可能性に基づいた解決策をマップアウトするのに役立つ適応的なツールを作ることです。

いくつかの一般的なフレームワークを評価した結果、私たちは PASTA フレームワークをベースとして採用することにし、GitLab の環境向けにいくつかの軽微な調整を加えてフレームワークを完成させました。原書の著者によるオーバービューはこちら で見ることができます。

私たちは依然としてフレームワークへの変更を歓迎し、それをハンドブックの他の部分と同様に生きたドキュメントだと考えています。

フレームワーク

私たちのベースフレームワークは PASTA です。PASTA は Process for Attack Simulation and Threat Analysis の頭字語です。これは 7 ステップのリスクベース脅威モデリングフレームワークです。

他にもいくつかの脅威モデリングフレームワークがありますが、他のものはコーディングに焦点を当てすぎているか、攻撃に焦点を当てすぎていると判断されました。PASTA はもっと広範囲をカバーでき、必要に応じて簡単にスケールアップやスケールダウンができ、他のほとんどの脅威モデリングフレームワークもそれにマッピングできます。

検討した他の脅威モデリングフレームワーク:

• STRIDE。これは Microsoft で使用されており、主に脅威自体に焦点を当て、既知/既存の脅威に偏る傾向があります。STRIDE を超えるにつれ、彼らはテンプレートを定義して脅威を評価できる SDL（Microsoft Windows で動作）を開発しました。私たちは Windows を使用しておらず、また私たちの焦点も彼らがそのために設計した既存のテンプレートには関係ありません。Microsoft の全体的な開発プロセスの一部として、私たちのニーズより「コード中心」です。
• Evil Personas。Evil Personas の焦点は通常の Personas に似ていますが、強調されているのは脅威アクターです。コード中心のプロジェクトはカバーせず、認識された脅威のみをカバーします。有用ですが、脅威が個人または個人のグループであると仮定するため、限定的です。ほとんどの「ペルソナ」シナリオは通常、他の脅威モデルに組み込まれるか追加されています。脅威モデリングにおけるペルソナのより攻撃的な側面については、Attack Personas に関するこの論文 を参照してください。
• カードゲーム。Elevation of Privilege を含むいくつかのバージョンがあります。極めて有用なツールですが、対面のコラボレーション向けに設計されており、STRIDE に整合する性質があります。Attack Trees に似ており、インフラやコードの一部に関する攻撃側に焦点を当てています。これは将来の Contribute では楽しいことになるかもしれませんが、Zoom ベースの文化にうまくスケールしません。
• Attack Trees。攻撃のみに焦点を当て、既存のコードとシステムの欠陥をマッピングするプロセスです。

PASTA は他のフレームワークと比べて GitLab に対していくつかの利点があります:

• リスク中心 - 重要なものを軽減
• エビデンスベースの脅威モデリング
  • 脅威の動機をサポートする脅威インテリジェンスを収集
  • 以前の脅威パターンをサポートする脅威データを活用
• 攻撃の確率、可能性、固有のリスク、侵害の影響に焦点
• コラボレーティブ
• 優先順位付けは、脅威モデルをいつ、どのアプリに適用するかを定義し、脅威モデルプロセス自体の一部であるべき

PASTA には、コードベースのシナリオからインフラシナリオへ簡単に採用できるという利点があります。役員のソーシャルメディアへの投稿による広報危機や、論争のある組織への GitLab 製品の販売など、非伝統的な脅威もカバーするように適応できます。ログ、インテリジェンスサービス、さらには以前のインシデントを含む脅威インテリジェンスソースからの脅威の強化を可能にするため、インシデント対応シナリオへのマッピングにも使用できます。

PASTA の段階

PASTA には 7 つの段階があります。以下が私たちの定義です。多くの例はコード中心ですが、これらは時間とともに進化させて、サードパーティ SaaS アプリケーションの承認、新しい地域への販売戦略や計画など、コーディング以外のシナリオにも対応できるようになります。

段階 I - 目的の定義

これはプロジェクトや評価のトーンを設定するのに役立ちます。次のことを考慮します:

• ビジネス目的。プロジェクトのビジネス目的を述べます。これはコードの目的、インフラの変更、マーケティングキャンペーンの目標など、目的が何であれ構いません。
• セキュリティ、コンプライアンス、および法的要件。これらは広い意味でガイドラインと制限の両方です。例えば、提案されたサードパーティアプリケーションのライセンスが整っていること、検討中の新しい SaaS アプリケーションのプライバシーポリシーが基準を満たしていること、新しいコードがセキュリティ標準を下げる必要がないことなどです。
• ビジネス影響分析。これにはミッションとビジネスプロセスへの影響、復旧プロセス、予算への影響、システムリソース要件を含めるべきです。
• 運用への影響。これには、運用担当者がすでに使用している既存プロセスへの影響を含めるべきです。例えば、追加のログ収集が導入されることでシステムイベントの解釈に影響が出たり、将来の変更に必要なステップ数が増えたり、高度なトラブルシューティングのための文書化された手順を変えたりする可能性があります。

段階 II - 技術的範囲の定義

これは「技術」そのものでなくても構いませんが、プロジェクトの境界を含めるべきです。

• 技術環境の境界。これらはプロジェクト自体に関連する境界です。これにはこのプロジェクトで触れられる（分類による）データの種類を含めるべきです。
• インフラ、アプリケーション、ソフトウェアの依存関係。これらすべては影響レベルを含めて文書化される必要があります。例えば、プロジェクトがあるサブシステムのライブラリのアップグレードを必要とし、そのサブシステムが RED データへの読み取り専用アクセスを持つ場合、それはサブシステムの他のユーザーに影響を与え、RED データへの潜在的な攻撃ベクトルを導入する可能性があるため、文書化される必要があります。

段階 III - アプリケーションの分解

これは、範囲内のものに対して何が重要かをマッピングすることを可能にします。

• ユースケースを特定し、プロジェクトの結果として変更されない場合でも、アプリケーションのエントリーポイントと信頼レベルを定義します。
• アクター、資産、サービス、役割、データソースを特定します。
• データフロー図を介してデータの動き（移動中、保存中）を文書化します。提案された変更を含む既存および提案された信頼境界を示します。
• 触れたすべてのデータとその分類を文書化します。

段階 IV - 脅威分析

これは、ここまでに収集したデータに関連する脅威と脅威パターンを主に文書化する場所です。

• 確率的攻撃シナリオ分析。発生する可能性のあるシナリオは少なくともリストされます。
• セキュリティイベントの回帰分析。同じまたは類似のコンポーネントに触れるイベントを例として調べます。
• 脅威インテリジェンス相関。ログ、Hackerone レポート、インシデント、その他攻撃シナリオを示すために使用できるソースからのデータを取り入れます。

段階 V - 脆弱性と弱点分析

これは、脅威を調べ、ランク付けし、その可能性を評価する場所です。

• 既存の脆弱性レポートと Issue 追跡を調べます。
• 脅威ツリーを使用した既存の脆弱性へのマッピング。
• 使用および誤用ケースを使用した設計上の欠陥分析。
• スコアリング (CVSS) と列挙 (CWE/CVE)。
• 影響を受けるシステム、サブシステム、データ。私たちは悪用の歴史があるものに追加または変更しているのか。現在の状態は脆弱で、この変更がその評価に影響を与えるか、または変えるか。

段階 VI - 攻撃モデリング

提案された変更の前後の攻撃面を調べることで、脅威を攻撃に変えていきます。

• 影響を受けるコンポーネントの攻撃面分析。
• 攻撃ツリーの開発。これは MITRE ATT&CK のようなものが助けてくれる場所です。
• 攻撃ツリーを使用した攻撃 –> 脆弱性 –> 悪用分析。
• 影響をまとめ、各リスクを説明します。

段階 VII - リスクと影響の分析

これは、残余リスクに基づく軽減の根拠の開発をカバーします。

• ビジネスへの影響を質的および量的に評価します。
• 対策の特定と残余の影響。
• リスク軽減戦略を特定します。軽減策の効果と軽減策を実装するコスト。
• 残余の利益。1 つのコンポーネントへの軽減努力としての変更の実装は、そのコンポーネントにアクセスする他のシステムのセキュリティ向上を意味する可能性があります。

3 段階アプローチ

PASTA フレームワークの実装と使用を支援するために、3 段階アプローチを使用できます。このアプローチは次のとおりです:

盲目的脅威モデル

GitLab のベストプラクティスをプロジェクトのコンポーネントに適用します。

• アプリケーションやサービスの主要な目標をマップし、アーキテクチャ、サーバー/サービスの堅牢化、アプリケーションフレームワーク、コンテナなどに関する明確な技術標準と相関させます。
• コンポーネントごとのベストプラクティス。例えば、GitLab 標準に設定された TLS 設定で、私たち自身の標準が業界のベストプラクティスより高いか低いかを記録します。
• コーディングのベストプラクティスもここで適用され、DevSecOps の「Sec」部分とそれを CI/CD に統合します。
• SAST/DAST のポリシーと範囲。私たちは「自分のドッグフードを食べて」、実装する変更の品質を改善できます。

PASTA の段階 I と段階 II を適用

エビデンス駆動脅威モデル

理論や推測ではなく、多数の指標を介した脅威の証明。

• 脅威ログデータ分析を統合します。
• 最大の動機を持つ攻撃ベクトルをサポートするログに焦点を当てます（例: TLS MITM 対 Injection ベースの攻撃）。
• プロジェクトコンポーネントに関連する対象アプリケーションへの攻撃の傾向を予測するために、脅威インテリジェンスを相関させます。

PASTA の段階 III、IV、V を適用

完全リスクベース脅威モデル

• 脅威データと攻撃の有効性に関する統計的/確率的分析
• 非伝統的な脅威ベクトルを考慮
• これには脅威インテリジェンス、H1 のトレンド、既存のログが含まれます
• 定義された脅威を実データで裏付けます

PASTA のすべての段階を適用

追加のリソース

役立ついくつかのリンクを以下に示します。

• 脅威モデリングについて議論されたセキュリティ部門の「Show and Tell」からの抜粋。
• Michael Henriksen によるブログ投稿。Draw.io（diagrams.net 経由で利用可能）を使ってダイアグラムやフローチャートを作成し、それらを脅威モデリング中に使用することについて議論しています。脅威モデルダイアグラムに役立つライブラリへのリンク も含まれています。
• Elevation of Privilege に加えて、Web ベースのアプリケーションに重点を置く OWASP Cornucopia もあります。
• MITRE ATT&CK。これは脅威モデリングそのものに使用するフレームワークではありませんが、既存の脅威モデリングフレームワークに適応してマッピングできます。

ページのソースコードを見る - ページの編集 - please contribute.