脅威モデルの記録と報告書
Sytance · 更新日
脅威モデルには、製品アーキテクチャ、攻撃シナリオ、セキュリティ対策、検証結果を記録します。記録を関連付けることで、攻撃の分析からその対策として選んだ措置まで、審査者が根拠をたどれるようになります。ゲートウェイの例では、これらの記録のつながりを示します。以下の各節では、記録する内容とレビュー方法を説明します。
モデルの構成方法
図と分析は一緒に保管するか、安定した識別子を使って関連付けてください。小規模なレビューには文書が適しています。同じ対策が複数の脅威に対応する場合や、チームがリリースを比較する必要がある場合は、構造化された記録が役立ちます。
Sytanceでは、チームがワークスペースでアーキテクチャと脅威の記録を編集し、関連するセキュリティ要件、設計、検証記録を結び付けます。文書化モジュールは、ワークスペースの情報を使ってレポートを作成します。
製品情報と前提条件
製品バージョン、導入環境、目的、使用者を特定します。分析に含める範囲、外部依存先、攻撃経路に影響する除外事項を明記してください。
OWASPの分解ガイダンスでは、エントリーポイント、アセット、信頼レベルを区別しています。すべてのアセットを図上の個別プロセスにするのではなく、この区別を使ってアーキテクチャを説明します。
- コンテキスト：製品、リリース、環境、目的、レビュー責任者。
- アーキテクチャ：図の改訂版、プロセス、データストア、外部エンティティ、フロー。
- 保護目標：機密性、完全性、可用性の確保が必要なデータと機能。
- 前提条件：不確かな条件、その担当者、確認方法。
攻撃シナリオごとに1件の記録を作成
各脅威に安定した識別子を付け、関連する図の要素またはフローに結び付けます。攻撃者、必要なアクセス権、行為、弱点、影響を記述してください。シナリオが依存する条件も明記します。
例 TM-01：ゲートウェイの読み取り専用ユーザーが構成書き込みAPIを呼び出す。APIが認証を確認しても書き込み権限を確認しない場合、ユーザーはテレメトリーの送信先を変更できます。対象となるフローはブラウザーから管理APIへの通信であり、攻撃は保存済み構成の完全性を脅かします。
「権限昇格、高リスク」とだけ記載しても、このシナリオを説明できません。必要なアカウント、エンドポイントの露出、現実的な影響、検討済みの既存対策など、リスク判断の根拠を追加してください。
対策、実装、検証
TM-01では、提案する対策AC-01により、管理APIはすべての構成書き込み時に操作権限とリソース権限を確認する必要があります。実装記録には関連する変更を特定します。検証記録には、対象リリースで実施した実際の試験結果を含めます。
- 判断：理由と担当者を明記したうえで、リスクを低減、除去、または受容する。
- 対策：必要な動作と、それが対応する脅威の手順。
- 実装：コンポーネント、変更参照情報、製品バージョン。
- 検証：セットアップ、操作、期待結果、観察結果、エビデンスへのリンク。
- 残留リスク：未解決の条件と、権限を持つ人によるレビュー判断。
期待結果と観察結果
架空のゲートウェイでは、読み取り専用ユーザーからの書き込みリクエストが拒否され、保存済みの構成が変更されないことを期待します。観察結果には、試験中に実際に起きたことを記録します。試験を行うまでは、この欄は保留です。
対策にも同じ区別が当てはまります。「署名検証を計画中」と「署名検証を実装し、試験済み」は、信頼性の異なる段階を示します。記録をレポートや別のツールに移す際も、この違いを維持してください。
完成したモデルのレビュー
レビュー担当者に、図から選定した対策と試験結果まで、1つの攻撃を追ってもらいます。関連をたどれない場合は、記録が欠落しているのか、攻撃の説明を明確にする必要があるのかを特定してください。
製品リリースと図が一致していること、各シナリオに対応判断があること、受容したリスクについて受容者が特定されていることを確認します。未確認の前提条件は、担当者と確認方法を付けて引き続き一覧に残します。
ワークスペースの記録を更新したら、「文書化」を開いて対象のレポートを選択します。Sytanceでは、ワークスペースの構成とプランに応じて、HTMLプレビューとPDFまたはDOCXを出力できます。レビューに使用する前に、生成されたレポートを現行の製品バージョン、分析、検証エビデンスと照合してください。