7.1 Security Design: Requirements, Threat Modeling, and Verifiable Controls

A secure software development lifecycle isn't just adding one scan before release; it's ensuring each stage produces verifiable security decisions for the next. Finding design flaws before dependent implementations spread usually reduces rework; but "shifting left" doesn't mean shifting all security responsibility onto developers.

Security requirements must be testable

“The system must be secure” is not verifiable. Rewrite it as constraints with a subject, resource, action, and failure behavior:

Only the project owner may export the full member list;
Require phishing-resistant reauthentication within 10 minutes before export;
Bind the download credential to its subject and object, consume it atomically once, and expire it after 15 minutes;
Refuse to create an export when the policy service is unavailable;
Log the subject, project, result, and policy version for every attempt.

The 10/15-minute periods are example product requirements, not universal security thresholds. An ordinary object-store presigned URL can usually be reused until expiry. Single-use access needs server-side consumption state and concurrent-download handling. Define recovery after a broken connection, for example by redeeming the token once for a restricted download session rather than treating one HTTP range request as a completed file download.

Requirements must also cover abuse, resource exhaustion, privacy, auditing, recovery, and dependency failure, rather than confidentiality alone. Security acceptance criteria are added to the backlog and prioritized and tested alongside features.

Threat Modeling Starts with a System Diagram

A useful data-flow diagram identifies:

• External entities and workload identities;
• Processes, data storage, queues, and third parties;
• Protocols, authentication, and sensitivity levels of data flows;
• Network, tenant, management, and organizational trust boundaries;
• Location of key, token, and personal data generation and destruction.

STRIDE can help frame questions about: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. It's a checklist, not a risk assessment; the priority of any threat is still determined by exploitability, business impact, data sensitivity, and existing controls.

Trace Controls Along an Abuse Path

Entry points: guess report_id / batch export / cache poisoning / background tasks
Prerequisite: A standard tenant account or stolen service token
Control: tenant-scoped query + policy check + cache namespace
Detection: cross-tenant deny, abnormal enumeration rate
Recovery: revoke token, isolate export, audit accessed objects

If control exists only in the Web controller, queue consumers and export tasks might still bypass it. The value of a threat model is identifying inconsistent execution points along the entire data flow.

Define a Protocol at Each Trust Boundary

Cross-boundary interfaces must be defined:

• Parties' identities and source of credentials;
• message schema, length, version, and normalized encoding;
• Authorization and tenant propagation;
• timeout, retry, idempotency, and replay window;
• Rules for logging error messages and sensitive fields;
• The worst loss this component can suffer when its peer is compromised.

"Internal APIs" aren't security properties. Input must be validated independently on both sides of the boundary, never assume upstream validation is a permanent guarantee.

Distinguish Prevention, Detection, and Recovery

Prevention: parameterized queries, least privilege, strong authentication
Detection: anomalous authorization denials, key usage auditing, integrity verification
Recovery: session revocation, key rotation, backup restoration, feature degradation

Prevention alone can leave a successful bypass undetected; detection alone leaves responders chasing harm after it occurs. High-risk threats need independent prevention and detection paths and rehearsed recovery actions.

Preserve Review Decisions

The final document doesn’t need dozens of pages of templates, but it should include: scope and version, key diagrams, threats, controls, residual risk, owner, verification methods, and action items. Accepted risks must have a defined deadline and a business owner; they cannot end with “we’ll add WAF later.”

Architecture changes trigger incremental reviews: new identity providers, new data uses, new external integrations, shifts in trust boundaries, and high-privilege background tasks can all render previous conclusions obsolete.

Turn the example into acceptance cases: deny a non-owner, deny reauthentication older than 10 minutes, allow only one concurrent redemption, and enqueue no export when policy evaluation is unavailable. Check persisted effects as well as responses; a 403 alone is insufficient. The next lesson follows findings through remediation and deployment verification.

References

• NIST, SP 800-218 SSDF 1.1
• OWASP, Threat Modeling Cheat Sheet
• MITRE, Threat Modeling