OWASP Top 10: A04:2021 安全でない設計(Insecure Design)とDREAD脅威評価 📊 詳細分析！

11月 2, 2026

—

皆さん、こんにちは！ 🌐 セキュリティ脆弱性の世界を探求する皆さんのガイドです。本日は、前回に引き続き、2021年OWASP Top 10の核であるA04:2021-Insecure Design（安全でない設計）についてさらに深く掘り下げ、特定された脅威のリスクを評価するのに役立つDREAD脅威評価モデルを詳しく説明します。💡

🤔 なぜ脅威を評価する必要があるのでしょうか？

前回、STRIDE脅威モデリングを通じて、私たちのシステムの設計にどのような潜在的脅威があるかを特定する方法を学びました。しかし、単に脅威をリストアップするだけでは不十分です。すべての脅威が同じレベルのリスクを持つわけではないからです。📉 ある脅威は直ちに解決すべき致命的な問題である可能性があり、別の脅威は後で対処してもよいほど優先順位が低い場合があります。

ここで、脅威評価の重要性が浮上します。特定された各脅威について、その深刻度を客観的に評価し、優先順位を付けることで、限られたリソースと時間を最も効果的に使用してセキュリティを強化できます。🛡️ そして、この脅威評価のための強力なツールがDREADです！

🎲 DREAD脅威評価モデル：リスクを測定する5つの尺度

DREADはMicrosoftが開発した脅威評価手法で、特定された各脅威に対して5つの基準を使用してリスクをスコア化します。各基準に従って1（低）から10（高）までのスコアを付与して合計点を計算するか、主観的な判断に基づいて「低」、「中」、「高」などに分類できます。これらのスコアを通じて、どの脅威がより緊急に対処されるべきか優先順位を決定できます。🎯

それでは、DREADの5つの基準を一つずつ詳しく見ていきましょう。

1. Damage (損害可能性) 💥

定義： 脅威が成功したときにシステムやビジネスに発生する可能性のある潜在的な被害の深刻度です。
考慮事項：
データ損失、改ざん、漏洩の規模は？ 📉
サービス中断時間は？ ⏱️
金銭的損失は？ 💰
企業イメージの損害は？ 💔
法的、規制的違反の可能性は？ ⚖️
例：顧客の個人情報漏洩（高）、サービス一時中断（中）、非必須ログファイルの改ざん（低）。
安全でない設計との関連性： 機密情報処理方法、重要サービスの復旧設計、データバックアップおよび保存ポリシーなどが損害可能性に大きな影響を与えます。

2. Reproducibility (再現可能性) 🔁

定義： 攻撃者が同じ脅威をどれだけ簡単に、そしてどれだけ一貫して再現できるかの程度です。
考慮事項：
攻撃に必要な特定の条件が頻繁に発生するか？ 🔄
攻撃手順は複雑か、それとも簡単か？ 🛠️
毎回同じ結果が発生するか？ ✅
例：数回のクリックで可能なSQLインジェクション（高）、特定の環境でのみ発生する非常にまれなバグ（低）。
安全でない設計との関連性： ユーザー入力値検証ロジックの欠如、異常なデータフローに対する処理の不備などは再現可能性を高める可能性があります。

3. Exploitability (悪用可能性) 🧑‍💻

定義： 攻撃者が脅威を成功裏に悪用するために必要な労力、技術、知識、リソースの量です。
考慮事項：
特定の専門知識が必要か？ 🎓
攻撃ツールは広く利用可能か？ 🔧
攻撃に必要な時間は短いか、長いか？ ⏳
回避しやすいか、難しいか？ 🚧
例：広く知られた脆弱性（例：古いライブラリ）を利用する攻撃（高）、ゼロデイ脆弱性を利用する非常に複雑な攻撃（低）。
安全でない設計との関連性： システムの複雑性、使用される技術スタックのセキュリティレベル、外部依存性の管理方法などが悪用可能性に影響を与えます。

4. Affectability (影響を受けるユーザー数) 👥

定義： 脅威が成功したときに影響を受けるユーザーまたはシステム構成要素の数です。
考慮事項：
全ユーザーが影響を受けるか、特定のグループのみが影響を受けるか？ 🎯
全サービスが中断されるか、一部の機能のみが中断されるか？ ⚙️
内部システムのみが影響を受けるか、外部システムも影響を受けるか？ 🌍
例：全ユーザーのアカウントを乗っ取ることができる脆弱性（高）、特定の管理者一人にのみ影響を与える脆弱性（低）。
安全でない設計との関連性： 権限分離設計、サービスモジュール化、ユーザー役割管理方法などが影響を受けるユーザー数に直接的な関係を持ちます。

5. Discoverability (発見可能性) 🕵️‍♀️

定義： 攻撃者が脅威や脆弱性をどれだけ簡単に発見できるかの程度です。
考慮事項：
脆弱性が公に知られているか？ 📢
システムの設計が公開されているか？ 📄
自動スキャンツールで簡単に見つけられるか？ 🤖
目視確認や基本的なテストで発見できるか？ 👀
例： HTTPヘッダーに機密情報が含まれており、簡単に見つかる場合（高）、非常に深く隠されたコードロジックにある脆弱性（低）。
安全でない設計との関連性： システムの複雑性、文書化レベル、エラーメッセージ設計、URL構造などが発見可能性に影響を与えます。

DREADスコアリングと活用 📈

各基準について1〜10点（または1〜3点）を付与した後、これらのスコアを合計または平均して最終的なリスクスコアを算出します。

例：


脅威名	損害可能性	再現可能性	悪用可能性	影響を受けるユーザー数	発見可能性	合計点 (合算)	危険度
DBインジェクション	10	9	8	10	9	46	高
サービス拒否	8	7	6	8	7	36	中
ログ改ざん	5	4	3	2	4	18	低

これらのスコアに基づいて、最も高いスコアを獲得した脅威から順にセキュリティ改善作業を進めることができます。DREADは、特定の脅威に対する主観的な感覚ではなく、客観的な尺度を提供することで、チーム内で脅威の優先順位について合意を形成するのに大いに役立ちます。🤝

結論：識別(STRIDE)から評価(DREAD)まで、安全な設計の完成！ 🏆

A04:2021-Insecure Designに効果的に対応するためには、単にコードを安全に書くだけでなく、設計段階からセキュリティを組み込む必要があります。STRIDEを通じて潜在的な脅威を幅広く特定し、DREADを通じて特定された脅威のリスクを客観的に評価し、最も重要な部分から改善することが重要です。

これら2つの強力なツールを開発プロセスに統合することで、最初から「安全に設計された(Secure by Design)」堅牢なシステムを構築できるでしょう。🏗️ セキュリティは開発の最終段階ではなく、最初から最後まで共に歩む旅です！