脅威モデリングプロセスパート2：最初の脅威モデルを設定する方法

Harnessで使用する脅威モデリングプロセスと、そのプロセス内のすべてのステップの詳細をご覧ください。

最初の部分では、脅威モデリングプロセスの概要を説明しました。この投稿では、各ステップの詳細を掘り下げて、その仕組みを学びます。

ステップ1：セキュリティ目標を特定する

セキュリティ固有の目標はプロジェクト目標のサブセットであり、脅威モデリングの取り組みの指針としてそれらを使用する必要があります。セキュリティ目標を制約の観点から考えると役立つ場合があります。「起こってほしくないことは何ですか？」という質問を考えてみましょう。たとえば、攻撃者が顧客データを取得できてはなりません。主要なセキュリティ目標を特定することで、どこに重点的に取り組むべきかを決定できます。また、潜在的な攻撃者の目的を理解し、細心の注意を必要とするアプリケーションの領域に集中するのにも役立ちます。顧客アカウントの詳細が保護が必要な機密データであると特定した場合、データがどのように安全に保管されているか、またデータへのアクセスがどのように制御および監査されているかを調査できます。

‍セキュリティ目標を決定するには、次の質問を考慮してください。

• どのような顧客データを保護する必要がありますか？（ユーザーアカウント、パスワード、クレジットカード番号、銀行口座情報など）
• コンプライアンス要件はありますか？（セキュリティポリシー、プライバシー法規制等）
• 特定のサービス品質要件はありますか？（可用性とパフォーマンス要件を含む）
• 保護する必要がある無形資産はありますか？（会社の評判、営業秘密など）

ステップ2：アプリケーションを分解する

このステップの目標は、アプリケーションとアプリケーションが外部エンティティとどのように対話するかを理解することです。これは情報収集と文書化によって実現されます。情報収集プロセスは明確に定義された構造を使用して実行され、正確な情報が確実に収集されます。
‍

以下のコンポーネントがあります。

• 脅威モデル情報
• 役割を特定する
• 主要な使用シナリオを特定する
• テクノロジーを特定する
• アプリケーションのセキュリティメカニズムを特定する
• 外部依存関係
• エントリーポイント
• 出口ポイント
• 資産
• 信頼レベル
• データフロー図

脅威モデル情報

脅威モデルを特定する情報には通常、次のものが含まれます。

1. アプリケーション名：検査されたアプリケーションの名前。
2. アプリケーションのバージョン：調査されたアプリケーションのバージョン。
3. 説明：アプリケーションの高レベルの説明。
4. ドキュメント所有者：脅威モデリングドキュメントの所有者。
5. 参加者：このアプリケーションの脅威モデリングプロセスに関与する参加者。
6. レビュー担当者：脅威モデルのレビュー担当者。

役割を特定する

アプリケーションの役割を特定する：アプリケーション内で誰が何を実行できるかを特定します。ユーザーは何ができるでしょうか？より高い特権を持つユーザーグループはどれですか？
‍

何が起こるべきなのか、何が起こらないのかを特定します。

主要な使用シナリオを特定する

アプリケーションの重要な機能は何ですか？それは何をするためのものか？この情報を得るには、アプリケーションのユースケースから始めます。主要なアプリケーションの機能と使用法を特定し、CRUDの側面をキャプチャします。

テクノロジーを特定する

• オペレーティングシステム
• Webサーバーソフトウェア
• データベースサーバーソフトウェア
• プレゼンテーション層、ビジネス層、データアクセス層で使用されるテクノロジー
• 開発言語

これは、テクノロジー固有の脅威を特定するのに役立ち、また、適切な軽減手法を決定するのにも役立ちます。

アプリケーションのセキュリティメカニズムを特定する

• 入力とデータの検証認証
• 認可
• 構成管理
• 機密データ
• セッション管理
• 暗号化
• パラメータ操作
• 例外管理
• 監査とログ記録

外部依存関係

外部依存関係は、アプリケーションに脅威をもたらす可能性のある、アプリケーションのコードの外部にある項目です。これらの項目は通常、組織の管理下にありますが、開発チームの管理下にない可能性があります。

エントリーポイント

エントリポイントは、潜在的な攻撃者がアプリケーションと対話したり、アプリケーションにデータを提供したりするためのインターフェイスを定義します。潜在的な攻撃者がアプリケーションを攻撃するには、エントリポイントが存在する必要があります。アプリケーション内のエントリポイントは階層化できます。たとえば、Webアプリケーションの各Webページには複数のエントリポイントが含まれる場合があります。

出口ポイント

出口ポイントは、クライアントを攻撃するときに有用であることがわかります。たとえば、クロスサイトスクリプティングの脆弱性と情報漏えいの脆弱性は両方とも、攻撃を完了するために出口ポイントを必要とします。
多くの場合、出口ポイントによって可能になる脅威は、対応する入口ポイントの脅威に関連しています。ログインの例では、出口ポイント（ログインページ）を介してユーザーに返されるエラーメッセージにより、アカウント収集（例：ユーザー名が見つからない）やSQLインジェクション（例：SQL例外エラー）などのエントリポイント攻撃が可能になる可能性があります。

資産

資産は本質的に攻撃者のターゲットです。つまり、資産は脅威が存在する理由になります。資産には、物理​​的な資産と抽象的な資産の両方があります。

信頼レベル

信頼レベルは、アプリケーションが外部エンティティに付与するアクセス権を表します。信頼レベルは、エントリポイントおよび資産と相互参照されます。これにより、各エントリポイントで必要なアクセス権または特権、および各アセットとの対話に必要なアクセス権または特権を定義できます。

データフロー図

DFDの焦点は、データがアプリケーション内をどのように移動するか、および移動中にデータに何が起こるかにあります。DFDは階層構造になっているため、アプリケーションをサブシステムと下位レベルのサブシステムに分解するために使用できます。高レベルのDFDにより、モデル化されるアプリケーションの範囲を明確にすることができます。下位レベルの反復により、特定のデータを処理するときに関与する特定のプロセスに焦点を当てることができます。

ステップ3：脅威を特定してランク付けする

脅威の分類

脅威を特定するための最初のステップは、脅威の分類を採用することです。脅威の分類では、一連のカテゴリと対応する例が提供されるため、アプリケーション内で体系的に脅威を構造的かつ再現可能な方法で識別できます。

ストライド

STRIDEなどの脅威の分類は、次のような攻撃者の目的を分類することで脅威を特定するのに役立ちます。

• スプーフィング
• 改ざん
• 否認
• 情報開示
• サービス拒否
• 特権の昇格

脅威分析

脅威の分析における前提条件は、リスクの一般的な定義を理解することです。リスクは、2つの要素によって決定される損失の可能性です。攻撃が発生する可能性または確率です。そして、そのような攻撃が発生した場合の潜在的な影響またはコスト。リスクは次のように計算されます。

（脅威が発生する確率）x（組織のコスト）

脅威のランキング

脅威はリスク要因の観点からランク付けできます。特定されたさまざまな脅威によってもたらされるリスク要因を判断することで、最初に軽減すべき脅威に優先順位を付けるなど、リスク軽減戦略をサポートする脅威の優先リストを作成できます。さまざまなリスク要因を使用して、脅威を高、中、または低リスクにランク付けできます。一般に、脅威リスクモデルでは、さまざまな要素を使用してリスクをモデル化します。

主観モデル：ドレッド

Microsoft DREADリスク評価モデルでは、リスク因数分解により、脅威のさまざまな影響要因に値を割り当てることができます。これにより、脅威をランク付けするための主観的なプロセスが提供されます。脅威のランクを決定するために、脅威アナリストはリスクの各要素についての質問に答えます。たとえば、次のとおりです。

• ダメージ：攻撃が成功した場合、ダメージはどのくらいになりますか？
• 再現性：攻撃を再現するのはどれくらい簡単ですか？
• 悪用可能性：脅威を悪用するにはどのくらいの時間、労力、専門知識が必要ですか？
• 影響を受けるユーザー：脅威が悪用された場合、何パーセントのユーザーが影響を受けるでしょうか？
• 発見可能性：攻撃者がこの脅威を発見するのはどれくらい簡単ですか？

定性的リスクモデル

一般的なリスクモデルでは、リスクを計算として考慮します。リスクは、攻撃の可能性とその攻撃の影響によって決定されることを思い出してください。（脅威が発生する確率）x（組織へのコスト）可能性または確率は、悪用の容易さによって決定できます。これは、脅威の種類とシステムの特性に応じて異なり、すでに導入されている可能性のある対策を考慮します。

 

以下は、悪用の容易さを判断するための一連の考慮事項です。

1. 攻撃者はこれをリモートから悪用できますか？
2. 攻撃者は認証される必要がありますか？
3. エクスプロイトは自動化できますか？

影響は主に、脅威の影響を受ける可能性のあるコンポーネントの数など、損害の可能性とその程度によって異なります。

損害の可能性を判断するのに役立つ質問は次のとおりです。

1. 攻撃者がシステムを完全に乗っ取って操作することはできるのでしょうか？
2. 攻撃者はシステムへの管理者アクセスを取得できますか？
3. 攻撃者がシステムをクラッシュさせる可能性はありますか？
4. 攻撃者は機密情報やPIIなどの機密情報にアクセスできるでしょうか？

脅威の影響を受けるコンポーネントの数を判断するのに役立つ質問は次のとおりです。

1. 影響を受ける可能性のある接続されたデータソースとシステムはいくつありますか？
2. 脅威エージェントはインフラストラクチャコンポーネントの何層を通過できますか？

これらの例は、可能性と影響因子に高、中、低などの定性的な値を割り当てることにより、全体的なリスク値の計算に役立ちます。この場合、DREADモデルの場合のように数値ではなく定性的な値を使用すると、ランキングが過度に主観的になるのを避けることができます。

ステップ4：対策と緩和策を決定する

対策の特定の目的は、脅威の実現を防ぐことができる何らかの保護対策（セキュリティ制御、ポリシーなど）があるかどうかを判断することです。脆弱性とは、対抗策のない脅威のことです。脅威と対応する対抗策が特定されたら、次の基準で脅威プロファイルを導き出すことができます。

• 緩和されていない脅威：対抗策がなく、完全に悪用されて影響を与える可能性のある脆弱性を表す脅威。
• 部分的に軽減された脅威：1つ以上の対策によって部分的に軽減され、限定的な影響を与えるために部分的にのみ悪用される脅威。
• 完全に軽減された脅威：これらの脅威には適切な対策が講じられており、脆弱性が露出することはありません。

ステップ5：脅威モデリングレポートを作成する

レポートの作成は非常に重要視されていますが、当社が実施するセキュリティ活動の非常に重要な部分であり、プロセスで特定された脅威、軽減策、影響を受ける資産、上級管理者への影響などを要約するのに役立ち、セキュリティ中心のアプローチへの注意を引くことができます。

結論

私たちは脅威モデリングのプロセスを高レベルかつ詳細な観点から検討してきました。このプロセスを実装することで、ビジネス全体のリスク姿勢を軽減できます。Harness STO（セキュリティテストオーケストレーション）モジュールは、アプリケーションセキュリティをすべての開発者のワークフローのポリシー主導の部分にすることで、ビジネスへのリスクを軽減するのにも役立ちます。最新のDevSecOpsソリューションを使用してエンジニアをサポートすることで、セキュリティ目標を達成する可能性を高めることができます。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。