APP / APP-01
脅威モデリングとセキュア設計
アプリケーションの設計前または設計中に調査を行い、機密資産、信頼境界、および悪用シナリオを特定すること。目的は、アーキテクチャ上の欠陥の修正コストが高くなる前に、適切な制御策を選定することである。.
役立つとき
的確な回答
定義されたニーズに対して.
新しいポータル、マルチテナントアーキテクチャ、IDシステムの変更、決済または機密データ統合、または情報システム上で動作するAIプロジェクト。.
適用範囲と成果物
このエンゲージメントの対象範囲.
スコープ
- ビジネス＆建築ワークショップ
- データフロー
- 俳優と特権
- 虐待のシナリオ
- セキュリティコントロール
- 検証可能な要件
- 残存リスクと所有権
成果物
- 注釈付き図表
- 脅威モデル
- 優先されるセキュリティ要件
- 建築上の決定事項
- 計画された試験
- 受け入れられるリスクまたは治療が必要なリスク
検収証拠
主なシナリオはビジネスチームと検討し、要件は割り当てられ、テスト可能になります。決定は文書化され、主要な変更に対するレビューは計画されます。.
配達
仕事の進め方.
アプローチ
アーキテクチャを理解する；リスクと要件を選択する；制御を統合または検証する；テストする；チームに引き渡す；回帰チェックの計画を行う。.
前提条件と責任
顧客：コード、アーキテクチャ、開発者、テスト環境、およびパイプラインへのアクセス。プロバイダー：専門知識とチェック。コードの修正は含まれている場合のみ。.
スコープ要因
アプリケーション、言語、リポジトリ、依存関係、ロール、パイプライン、ボリュームと深度。個別のツールライセンス、修復開発、保守。.
確認のための質問
どの行動が最も害を及ぼすでしょうか？信頼の境界はどこで越えられますか？どの建築上の決定はまだ変更可能でしょうか？
重要な境界線
脅威モデリングは、侵入テストでもないし、欠陥がないという証でもない。その価値は、情報品質と変更後のアップデートに左右される。.
管理策は、合意されたバージョンおよびスコープに適用されます。スキャナー、SBOM、フレームワークのいずれ単体でも、納品されるソフトウェアのセキュリティを保証するものではありません。.
実際には
具体例.
これらの例は、想定される関与と目標とする成果について説明したものであり、顧客の事例や達成された実績ではありません。.
シナリオ01
ベンダーはマルチテナントアプリケーションを準備している。プロジェクト：開発前に顧客アクセスと交換のモデルを作成する。目標成果：リリース後に追加されるのではなく、バックログやテストに組み込まれた分離要件。.
シナリオ 02
チームはデータ修正可能なAIエージェントを追加する。 プロジェクト：ツールと機微な決定の評価。 ターゲット結果：事前に策定された行動制限と人的承認；一部のツールはパイロット段階外に留まる。.
技術と参照コンテキスト
参考文献：OWASPの取り組みとNIST SSDF；図表および要件は、任意の義務付けられたツールとは無関係です。.
最終的なテクノロジーセットは、相互運用性、ライセンス、アクセス権、および運用要件に基づき、スコープ設定の段階で合意されます。.
コネクテッドサービス
次のステップを構築する。.
これらのサービスはエンゲージメントを補完するものであり、自動的には含まれません。.
会話を始めましょう。
スコープを明確にする。.
このサービスの目的、依存関係、および責任範囲を明確にした上で、納品を提案いたします。.