Day 109　手法8：セキュリティ設計レビュー・テンプレート　Method 8: The Security Design Review Template

サイバー判断力によるヒューマン・ハードニング

» 2026/02/14

[シリーズ構造] 柱D｜脅威の現実

セキュリティ設計レビューは、儀式でも書類作業でもない。本稿では、実装前に攻撃者視点を組み込む軽量な設計レビューテンプレートを紹介する。目的はただ一つ、セキュリティを「想定外」から「想定内」へ変えること。

▶ シリーズ概要： シリーズ全体マップ：人間のしなやかさ ― サイバー判断力のために

▶ 柱E｜脅威の現実 関連記事：

• Day 59 | 攻撃者をステークホルダーとしてデザインする
• Day 60 | セキュリティトレーニングが失敗する理由
• Day 61 | 経験の科学
• Day 61 | すべてを変えた数字
• Day 63 | AIが攻撃者になる時
• Day 63 | 攻撃を学ぶことの倫理
• Day 65 | 理論から実践へ
• Day 66 | 手法 1: レッドチェア・テクニック
• Day 67 | 手法2: ユースケースの隣に、アビューズケースを置く
• Day 68 | 手法3 : STRIDE
• Day 105 | 手法4：セキュリティ・チャンピオン・ネットワーク
• Day 106 | 手法5: ハンズオン攻撃トレーニング
• Day 107 | 手法 6: セキュリティのガードレールを「デフォルト」にする
• Day 108 | 手法7：セキュア設計・チェックリスト
• Day 109 | 手法8：セキュリティ設計レビュー・テンプレート

手法8：セキュリティ設計レビュー・テンプレート

この段階では、敵対的思考を人の頭の中に置いておいてはいけない。

設計プロセスの中に、置く。だからこのテンプレートは、重要な機能を実装する「前」に、チームで埋める。

官僚的な手続きのためではない。

チェックを通すためでもない。

行動の前に、何に気づいているかを可視化するため。

失敗の原因は、「気にしていなかった」ことではない。

多くの場合、ただ、見ていなかった。

セキュリティ設計レビュー・テンプレート

対象：何を作るのか（1文で。曖昧さを残さない）

1) 露出されるデータ

この機能は、どんな「守るべきデータ」に触れるか。

• 個人情報／識別可能情報
• 金融情報・規制対象データ
• 認証情報・シークレット・トークン
• 業務上クリティカルな情報（運用・製造・物流・契約・価格 など）
• 漏えい・改ざん・破壊・窃取されたら「痛い」ものすべて

ここでは、あえてデータ中心で考える。それが、脅威モデリングを「机上の演習」から現実の判断に引き戻す、いちばん短い道だから。

2) 信頼境界

信頼が、どこで切り替わるか。

• どこから「信頼できない入力」が入るか
• 外部サービス／ベンダー／サードパーティは何が絡むか
• 権限レベルが変わる地点はどこか
• ID・完全性・可用性について何を前提（仮定）にしているか

境界を指させないなら、防御も設計できない。

3) STRIDEで10〜15分ざっと見る

ここでは、深掘りしない。

STRIDEで、軽く一周する。考え込むのは後でいい。

• Spoofing（なりすまし）
  ユーザーやサービスを偽れる場所は？
• Tampering（改ざん）
  データや設定を書き換えられる場所は？
• Repudiation（否認）
  「やっていない」と言い張れる場所は？
• Information Disclosure（情報漏えい）
  情報が漏れるとしたら、どこから？
• Denial of Service（DoS）
  詰まらせられる場所は？
• Elevation of Privilege（権限昇格）
  本来ない権限を取れてしまう場所は？

出てきたものは、全部並べる。まだ解かなくていい。先にやるのは、見える化。

修正は、次の工程でやる。STRIDEは、Microsoftが整理してきた代表的な脅威モデリングの枠組みのひとつだ。

そして重要なのは、脅威モデリングが設計段階で行われる前提として扱われていること。

つまりこれは、「レビューのため」ではなく、作る前の思考整理だ。

4) 脅威

列挙した中から、重要なものについてだけ、次を書く。

• 脅威の内容
• 発生可能性（高 /中 /低）
• 影響
• 対応の緊急度

例　パスワードリセット経由のユーザー列挙ー発生可能性：高　インパクト：中　対応の緊急度：P1＝リリース前に必須

ここでの前提は、これだけ。認証まわりのエラーメッセージは、列挙に使われ得る。

だから「使われないはず」ではなく、「使われる前提」で設計する。

5) 対策

脅威ごとに、実行できる形で書く。

• 何をすれば減らせるか
• 誰がオーナーか
• いつまでに終わらせるか

例 ユーザー列挙対策→ 返答の一般化＋レート制限　ステータス: リリース前に完了必須

特に、パスワードリセットなどのフローでは、

• トークンの総当たり
• 繰り返し試行

を前提に、レート制限を組み込む。

これは最適化ではない。設計の最低条件だ。

6) アビューズケース

攻撃者のストーリーを、3〜5本書く。

箇条書きでいい。 正確でなくていい。動機が見えることが大事。

• 攻撃者として、メールアドレスを列挙し、フィッシングの対象リストを作りたい
• 攻撃者として、パスワード変更後もセッションを保持し、アカウントを継続監視したい
• 攻撃者として、このエンドポイントを洪水にして、正規ユーザーを締め出したい

想像できないなら、どこかを見落としている。

戻って、もう一回見る。

アビューズケースをユーザーストーリー形式で扱う考え方は、OWASPでも実務向けに整理されている。

これは空想ではない。攻撃者視点での要件定義だ。

7) セキュリティ基本統制

"基本"を、言語化する。空欄を、潰す。

• 認証：ユーザー本人性をどう担保するか
• 認可：許可された操作だけに、どう絞るか
• 入力検証：悪意ある／不正な入力を、どう落とすか
• レート制限：乱用・大量アクセスを、どう捌くか
• ログ／監視：何が起きたら「おかしい」と分かるか

空欄は、失敗じゃない。未解決の問いだ。

設計段階でリスクモデル（脅威モデリング等）をレビューすることは、NISTの SSDF（Secure Software Development Framework）でも実務タスク例として触れられている。ここで問いを残せるチームは、後で事故を小さくできる。

8) 残余リスク

対策をしても、残るものは残る。

それを、書く。

• なぜ受容するのか
• 誰が合意したのか
• いつ見直すのか

ここがないと、未来で揉める。そして組織は、驚くほど早く忘れる。リスク評価結果を意思決定に使える形で残す、という考え方は、NISTのリスク評価ガイダンスに沿ったものだ。これは防御ではない。記憶装置だ。

9) レビュアー

レビューした人を、記録する。サインはいらない。名前で十分。

これは儀式じゃない。責任の所在を曖昧にしないための記録だ。セキュリティ・チャンピオンを各チームに置く発想は、OWASPでも実務プログラムとして整理されている。

また、成熟モデルであるOWASP SAMMでも、チャンピオンはチームとセキュリティをつなぐ連結点として位置づけられている。

ルール

これが終わっていないなら、その機能は準備不足。例外はない。「後でやる」は、だいたい永遠にやらない。これは恐怖で縛るためのルールじゃない。

説明責任を、文化にするためのルールだ。

―――

[Series Structure] Pillar D | Threat Reality

Security design reviews should not be ceremonies or paperwork. This post introduces a lightweight security design review template that embeds adversarial thinking before code is written. Its goal is simple: turn security from surprise into expectation by making risks, assumptions, and residual decisions visible early.

▶ Series overview: Series Map - Human Flexibility for Cyber Judgment

▶ Other posts in Pillar E (Pillar D | Threat Reality):

• Day 59 | Design with Attacker as Stakeholder
• Day 60 | Why Security Training Fails
• Day 61 | The Science of Experience
• Day 62 | The Numbers That Changed Everything
• Day 63 | When AI Becomes the Attacker
• Day 64 | The Ethics of Learning to Attack
• Day 65 | From Theory to Practice
• Day 66 | Method 1 :The Red Chair Technique
• Day 67 | Method 2: Abuse Cases Alongside Use Cases
• Day 68 | Method 3: STRIDE
• Day 105 | Method 4: Security Champions Network
• Day 106 | Method 5: Hands-On Attack Training
• Day 107 | Method 6: Security Guardrails as Defaults
• Day 108 | Method 7: The Secure Design Checklist
• Day 109 | Method 8: The Security Design Review Template

Method 8: The Security Design Review Template (refined in your continuity)

At this stage, adversarial thinking shouldn't live in people's heads.

It should live in the design process.

So before implementing any significant feature, teams fill out this template.

Not as bureaucracy - as proof of awareness before action.

Because the failure mode isn't "we didn't care."　It's "we didn't look."

Security Design Review Template

Feature　What are we building (one clear sentence)?

1) Data Exposure

What sensitive data does this feature touch?

• Personal or identifiable data
• Financial or regulated information
• Authentication credentials, secrets, or tokens
• Business-critical / operational data
• Anything that would hurt if exposed, corrupted, or stolen

2) Trust Boundaries

Where does trust change?

• Where does untrusted input enter
• Which external services / vendors are involved
• Where do privilege levels change
• What assumptions are we making about identity, integrity, or reliability

If you can't point to the boundary, you can't defend it.

3) STRIDE Threat Sweep (10-15 minutes)

Run a quick pass using STRIDE:

• Spoofing→ Where could someone impersonate a user or service?
• Tampering→ Where could data/config be modified?
• Repudiation→ Where could someone deny their actions?
• Information disclosure→ Where could data leak?
• Denial of service→ Where could the system be overwhelmed?
• Elevation of privilege→ Where could someone gain rights they shouldn't?

List what surfaced. Don't solve yet -- see first, fix second.

STRIDE is a standard, widely-used threat categorization approach in industry threat modeling practice.
It's also explicitly used as a "prompting mnemonic" in OWASP threat modeling guidance.

If you want a lightweight way to get developers to actually do this, Microsoft's "Elevation of Privilege" cards were built specifically to draw devs into STRIDE-style thinking.

4) Identified Threats (what matters)

For each risk that matters, describe:

• What the threat is
• Likelihood (High / Medium / Low)
• Impact
• Priority/urgency (e.g., P1 = required before release)

Example:

User enumeration via password reset Likelihood: High / Impact: Medium / Priority: P1

User enumeration via overly-specific auth errors is a known class of weakness called out in OWASP authentication guidance.

5) Mitigations (make it executable)

For each high-priority threat:

• What action will mitigate it
• Who owns the change
• When it must be completed

Example:　Enumeration mitigation → generic responses + rate limiting
Status: must be completed before release

OWASP explicitly discusses rate limiting protections in reset flows and warns about enumeration risks from error handling/auth messaging.

6) Abuse Cases (3-5 attacker stories)

Write 3-5 attacker stories like:

• As an attacker, I want to enumerate emails so I can target phishing
• As an attacker, I want to stay logged in after password change so I can monitor the account
• As an attacker, I want to flood this endpoint so I can deny service to real users

If you can't imagine how it can be abused → go back and look again.

This isn't just "folklore." Abuse cases (and related misuse-case methods) are an established security requirements technique, with OWASP providing a practical implementation pattern and academic work dating back decades.

7) Security Controls (the basics, explicitly)

Describe how the basics are covered:

• Authentication: how do we know who the user is
• Authorization: how do we know what they're allowed to do
• Input validation: how do we reject malformed/malicious input
• Rate limiting: how do we handle abuse and volume attacks
• Logging & monitoring: what signals tell us something is wrong

Empty fields are not failures -- they are questions to resolve.

This "make expectations explicit" move is consistent with how security maturity models operationalize design review and threat assessment practices.
And it aligns with the NIST Secure Software Development Framework's expectation that organizations review risk models created during design (threat modeling, attack modeling, etc.).

8) Residual Risk (the part that prevents future blame)

After mitigations, what risk remains?

• Why are we accepting it
• Who agreed
• When will we revisit

This prevents future blame and future amnesia.

Formally capturing residual risk is part of standard risk assessment discipline (risk is evaluated, treated, and what remains is communicated/accepted). NIST SP 800-30 includes templates and structure for communicating risk assessment results.

9) Reviewers (record, not ritual)

Record who reviewed:

• Developer
• Red Chair Reviewer
• Security Champion
• Security team (only required for high-risk work)

No signatures. Names are enough.

This is record, not ritual.

Security champions as a scaling mechanism is a recognized industry practice and is documented directly in OWASP culture guidance and OWASP SAMM.

Rule

If this isn't done, the feature isn't ready.

Period. No exceptions.

This is how accountability becomes culture -- not fear.

References 出典・参照文献

Microsoft. (n.d.). Microsoft Security Development Lifecycle (SDL): Threat modeling. https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling

Microsoft Developer Network. (2006). Uncover security design flaws using the STRIDE approach. https://learn.microsoft.com/en-us/archive/msdn-magazine/2006/november/uncover-security-design-flaws-using-the-stride-approach

Microsoft. (n.d.). Elevation of privilege: Drawing developers into threat modeling (White paper). https://download.microsoft.com/download/f/a/e/fae1434f-6d22-4581-9804-8b60c04354e4/eop_whitepaper.pdf

National Institute of Standards and Technology. (2022). Secure software development framework (SSDF) version 1.1: Recommendations for mitigating the risk of software vulnerabilities (NIST Special Publication 800-218). https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf

National Institute of Standards and Technology. (2012). Guide for conducting risk assessments (NIST Special Publication 800-30 Revision 1). https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-30r1.pdf

National Institute of Standards and Technology. (2016). Guide to data-centric system threat modeling (NIST Special Publication 800-154, Initial Public Draft). https://csrc.nist.gov/pubs/sp/800/154/ipd

OWASP Foundation. (n.d.). Threat modeling process. https://owasp.org/www-community/Threat_Modeling_Process

OWASP Foundation. (n.d.). Threat assessment (OWASP SAMM). https://owaspsamm.org/model/design/threat-assessment/

OWASP Foundation. (n.d.). Authentication cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

OWASP Foundation. (n.d.). Forgot password cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html

OWASP Foundation. (n.d.). Abuse case cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html

OWASP Foundation. (n.d.). Security champions program. https://devguide.owasp.org/en/08-culture-process/02-security-champions/01-security-champions-program/

OWASP Foundation. (n.d.). Education & guidance stream B (OWASP SAMM). https://owaspsamm.org/model/governance/education-and-guidance/stream-b/

Sindre, G., & Opdahl, A. L. (2000). Eliciting security requirements with misuse cases. Requirements Engineering, 5(1), 34-44. (Commonly cited foundational work; if you want, I can fetch the publisher DOI/landing page you prefer and format it precisely.)

McGraw, G. (2006). Software security: Building security in. Addison-Wesley. (Often cited for "build it in" framing; include if you're using it elsewhere in the series.)