9.2 Architecture, Threat Modeling, and Design Review

Designing For Misuse And Failure

Architecture review asks whether the system can meet its security objectives before the organization commits to implementation. A design may use modern services and still be unsafe if trust boundaries are unclear, privileged operations are hidden, logs are missing, or sensitive data flows through services that were never approved for that data. Threat modeling gives the review structure.

Threat modeling is not a paperwork exercise reserved for large projects. It is a way to ask what can go wrong, why it matters, what controls reduce the risk, and who accepts what remains. It should be scaled to the system. A small internal workflow may need a short abuse-case review. A payment, medical, identity, or safety-related platform may require a formal model, architectural signoff, and repeated updates as the design changes.

A useful threat model starts with assets and objectives. What data, transactions, identities, processes, and service dependencies matter? Then it maps data flows and trust boundaries. A trust boundary is a point where assumptions change, such as a browser entering an API, a service calling a database, a cloud workload using a managed identity, or a partner system connecting through an integration layer. Boundary crossings are where controls often belong.

Common threat modeling methods include STRIDE, attack trees, misuse cases, and data-flow-based analysis. CISSP scenarios usually care less about naming a method and more about applying the discipline. STRIDE can help structure thinking about spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Misuse cases help product teams see malicious or careless behavior that normal user stories omit.

Design review should be collaborative. Security teams bring threat knowledge and control patterns. Architects know dependencies and constraints. Developers know implementation realities. Product owners know customer and regulatory expectations. Operations teams know monitoring, recovery, and deployment limits. Privacy and legal teams may be needed when data use, notice, jurisdiction, or contractual commitments are affected.

Scenario: a company is moving a claims-processing application to cloud containers. The proposed design places public APIs, internal services, queues, object storage, and analytics jobs in the same network segment. The threat model identifies broad service account permissions, missing egress controls, unencrypted object storage events, and no separation between production and analytics identities. The right management response is not to reject cloud. It is to require segmentation, least-privilege identities, approved encryption, monitoring, and risk acceptance for any remaining exposure.

Architecture principles guide design choices. Defense in depth avoids dependence on one control. Least privilege limits what an identity can do. Fail-safe defaults deny access when policy cannot be evaluated. Economy of mechanism favors simpler designs that can be understood and tested. Complete mediation checks authorization for each protected action. Separation of duties prevents one role from building, approving, and operating sensitive paths without oversight.

Threat modeling should include privacy and data lifecycle risk. A design may protect confidentiality in transit but still collect excessive data, retain it longer than policy permits, or replicate it to analytics platforms without a clear business purpose. A CISSP should ask whether data is minimized, classified, retained appropriately, and deleted or anonymized when no longer needed. Security and privacy are related but not identical.

Design review should also examine negative space: what the system will not do. Will the API reject unsupported methods? Will file uploads be scanned and type checked? Will administrative functions be isolated? Will secrets be stored outside code and images? Will the system fail closed if an authorization service is unavailable? Will logs avoid sensitive values while still supporting investigation? These questions prevent controls from becoming aspirational.

Use this threat modeling workflow:

1. Define the business process, critical assets, and security objectives.
2. Draw data flows, trust boundaries, identities, stores, and external dependencies.
3. Identify threats using a consistent method such as STRIDE, misuse cases, or attack trees.
4. Rate threats by business impact, likelihood, exploitability, and exposure.
5. Select controls, design changes, or compensating controls.
6. Assign owners, due dates, and validation evidence.
7. Record accepted residual risk and review triggers.

Review triggers are important. A threat model should be revisited when data classification changes, new external connectivity is added, authentication patterns change, privileged workflows are introduced, critical dependencies change, or production incidents reveal a missed assumption. Treat the model as design evidence, not a static artifact.

The CISSP mindset is to prefer early, documented, risk-based design decisions. A late vulnerability can often be patched, but a flawed trust model may require rearchitecture. Leaders reduce cost and risk by making threat modeling part of normal architecture work and by ensuring unresolved design risk is visible to the people authorized to accept it.