Architectural Risk Assessment and Design Review

1. Why Architectural Risk Assessment and Design Review Matter

Most serious security weaknesses are not coding bugs; they are design flaws. Studies cited throughout the CSSLP body of knowledge (and by groups such as the IEEE Center for Secure Design) indicate that roughly half of all security defects originate in architecture and design decisions rather than in implementation. A missing authorization check on a trust boundary, a poorly chosen trust model, or an unprotected data flow cannot be fixed by writing cleaner code later; the flaw is structural.

The economics are equally compelling. The cost of fixing a defect rises steeply through the lifecycle: a design flaw caught in an architecture review may cost almost nothing to correct, while the same flaw found in production can cost 30 to 100 times more, plus the cost of a breach, regulatory penalties, and reputational damage. Architectural risk assessment and design review are therefore the highest-leverage security activities in the Software Development Lifecycle (SDLC). They embody the CSSLP principle of shifting left: finding and treating risk before a single line of production code is written.

For the exam, remember the core message: security must be designed in, not bolted on. Architectural risk assessment is how the designer proves that security requirements have been translated into a structure that can actually meet them.

2. What Architectural Risk Assessment Is

Architectural risk assessment is a structured process for identifying, analyzing, and prioritizing security risks that arise from the way a system is composed: its components, their interactions, trust relationships, data flows, dependencies, and deployment environment. It answers questions such as:
- What assets does this system protect, and what is their value?
- Where are the trust boundaries, and what crosses them?
- Who or what might attack the system, how, and with what motivation?
- What would the business impact be if a given component or flow were compromised?
- Which design decisions reduce risk to an acceptable level, and which risks remain?

Design review is the complementary activity in which the proposed (or existing) architecture is examined by qualified reviewers against security requirements, secure design principles, organizational standards, and the findings of the risk assessment. The risk assessment produces the risk picture; the design review verifies that the design adequately addresses it and approves, conditions, or rejects the design.

Together they form a gate in a secure SDLC (for example, the Microsoft SDL Design phase or the architecture gate in an organizational Secure Development Policy). Passing the gate typically requires a completed threat model, a documented risk register with treatments, sign-off from a security architect, and traceability from security requirements to design elements.

3. Key Concepts You Must Know

3.1 Risk fundamentals
Risk is commonly expressed as the product of likelihood (probability that a threat exploits a vulnerability) and impact (consequence to the business). The classic components are:
- Asset: anything of value (data, functionality, reputation, availability).
- Threat: a potential cause of an unwanted incident (a threat agent plus an attack vector).
- Vulnerability: a weakness that a threat can exploit.
- Exposure: the condition of being subject to loss.
- Countermeasure / control: something that reduces likelihood or impact.
- Residual risk: the risk remaining after controls are applied; it must be formally accepted by the business owner, not by the developer.

Risk treatment options (know all four): mitigate (reduce via controls), transfer (insurance, outsourcing, contractual shift), avoid (remove the feature or change the design), and accept (document and live with it). Ignoring risk is never a valid option on the exam.

3.2 Qualitative vs. quantitative assessment
- Quantitative uses monetary values: Single Loss Expectancy (SLE) = Asset Value x Exposure Factor; Annualized Loss Expectancy (ALE) = SLE x Annualized Rate of Occurrence (ARO). Useful for justifying control spend (a control is cost-effective if its annual cost is less than the ALE reduction it delivers).
- Qualitative uses ratings such as High/Medium/Low or scoring schemes. Most architectural assessments are qualitative or semi-quantitative because precise probabilities for software attacks are rarely available.

3.3 Threat modeling
Threat modeling is the central technique of architectural risk assessment. It is a systematic examination of a design to enumerate threats, understand attack paths, and decide on mitigations. The typical steps are:
1. Define scope and objectives (what are we building, what must be protected).
2. Decompose the application: identify entry points, exit points, assets, trust levels, external dependencies, and create Data Flow Diagrams (DFDs) showing processes, data stores, data flows, external entities, and trust boundaries.
3. Identify threats using a methodology.
4. Rate and prioritize threats.
5. Identify countermeasures and map them to threats.
6. Validate the model and update it as the design evolves (threat models are living documents).

Methodologies you should recognize:
- STRIDE (Microsoft): Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Each maps to a security property: authentication, integrity, non-repudiation, confidentiality, availability, authorization. STRIDE is threat-centric and often applied per DFD element.
- DREAD: Damage, Reproducibility, Exploitability, Affected users, Discoverability. A rating scheme (not a threat-discovery method) used to score threats; now considered subjective, but still appears on exams.
- PASTA (Process for Attack Simulation and Threat Analysis): a seven-stage, risk-centric, business-aligned methodology (define objectives, define technical scope, decompose application, analyze threats, analyze vulnerabilities, model attacks, analyze risk and impact).
- Trike: a risk-management-oriented approach focused on acceptable risk from the stakeholder perspective, using requirements models and actor-asset matrices.
- VAST (Visual, Agile, and Simple Threat modeling): designed to scale across agile enterprises with application and operational threat models.
- OCTAVE: an organizational, asset-driven risk assessment approach from CERT/SEI; more enterprise-level than application-level.
- Attack trees: hierarchical diagrams with the attacker goal as the root and sub-goals or methods as branches; useful for analyzing attack paths and the cheapest or most likely route.
- Misuse cases and abuse cases: extensions of UML use cases that describe how a hostile actor could misuse functionality, helping to derive security requirements and test cases.
- Kill chain and MITRE ATT&CK: adversary-behavior frameworks sometimes used to inform realistic attack scenarios.

3.4 Attack surface analysis
The attack surface is the sum of all points where an attacker can interact with the system: network ports and protocols, APIs, user input fields, file parsers, configuration interfaces, privileged processes, third-party components, and administrative channels. Attack surface analysis enumerates and measures these points so that the design can minimize them: disable unnecessary services, reduce privileges, limit exposed interfaces, and validate every entry point. A smaller attack surface means fewer opportunities for exploitation and simpler verification.

3.5 Secure design principles used as review criteria
Reviewers assess the architecture against the classic Saltzer and Schroeder principles and modern additions:
- Least privilege: every component runs with the minimum rights needed.
- Separation of duties: critical actions require more than one party or role.
- Defense in depth: multiple, layered controls so that one failure is not fatal.
- Fail secure (fail safe): on error, the system denies access rather than granting it.
- Economy of mechanism: keep the design simple; complexity hides flaws.
- Complete mediation: every access to every object is checked, every time (no cached authorization shortcuts).
- Open design: security does not depend on secrecy of the design (Kerckhoffs principle); only keys and credentials are secret.
- Least common mechanism: minimize shared resources between users or components.
- Psychological acceptability: controls must be usable or users will bypass them.
- Weakest link: the system is only as strong as its weakest component; prioritize accordingly.
- Leverage existing components: reuse vetted libraries and services rather than inventing new security mechanisms (never roll your own cryptography).
- Avoid single points of failure and plan for graceful degradation.

3.6 Trust boundaries and trust models
A trust boundary is any point where data or control passes between components with different privilege or trust levels (client to server, application to database, internal service to third-party API, user mode to kernel). Every crossing requires authentication, authorization, input validation, and often encryption. Many exam scenarios hinge on recognizing a missing control at a trust boundary.

4. How Architectural Risk Assessment Works in Practice

Step 1: Establish context. Gather business objectives, regulatory and compliance drivers (PCI DSS, HIPAA, GDPR, FedRAMP), data classification, and the security requirements produced in the requirements phase. Identify stakeholders and the risk appetite of the business owner.

Step 2: Characterize the system. Produce or obtain architecture artifacts: component diagrams, DFDs, sequence diagrams, deployment diagrams, interface specifications, and a bill of materials for third-party and open-source components. Mark trust boundaries, data stores holding sensitive information, and privileged components.

Step 3: Identify assets and value them. Classify data (public, internal, confidential, restricted) and identify critical functions. Value determines the acceptable level of protection and drives prioritization.

Step 4: Identify threats and threat agents. Use STRIDE per element, attack trees, misuse cases, and threat intelligence. Consider internal and external actors, accidental and malicious causes, and supply-chain threats from dependencies.

Step 5: Identify vulnerabilities and weaknesses in the design. Compare the design to secure design principles, known weakness catalogs (CWE, especially the CWE Top 25 and the OWASP Top 10 design-related items such as Insecure Design), and organizational patterns. Look for missing authentication, improper authorization models, unencrypted sensitive flows, insufficient logging for non-repudiation, unsafe deserialization paths, excessive privilege, and single points of failure.

Step 6: Analyze and rank risk. Combine likelihood and impact. Use DREAD, the OWASP Risk Rating Methodology, or CVSS-style severity for known weakness types. Produce a prioritized risk register.

Step 7: Select and document countermeasures. Map each significant risk to a design-level control: authentication mechanism, authorization model (RBAC, ABAC), cryptographic protection, input validation strategy, secure session management, logging and monitoring, rate limiting, segmentation, secure defaults, and so on. Prefer proven security patterns (for example, a centralized authorization service, a secure gateway, a secrets vault). Document residual risk and who accepts it.

Step 8: Conduct the design review. A review team, typically including the security architect, lead developer, operations representative, and sometimes an independent reviewer or Architecture Review Board, walks through the design against a checklist derived from requirements, principles, and the threat model. Findings are logged with severity, owner, and due date. The outcome is approval, conditional approval pending remediation, or rejection.

Step 9: Trace and verify. Maintain traceability from security requirements to design elements to test cases so that later verification (code review, static analysis, penetration testing) can confirm that mitigations were actually implemented.

Step 10: Iterate. Re-run the assessment whenever the architecture changes materially: new interfaces, new data types, new third-party components, cloud migration, or a changed threat landscape.

5. Design Review Types and Artifacts

- Informal walkthroughs: lightweight peer review of a design document; fast but less rigorous.
- Formal inspections: structured, role-based reviews (moderator, author, reviewers, recorder) with entry and exit criteria and defect metrics.
- Architecture Review Board (ARB) reviews: governance-level approval against enterprise standards.
- Independent third-party design review: often required for high-assurance or regulated systems.

Typical inputs: security requirements, architecture diagrams, DFDs, threat model, data classification, compliance mapping, component inventory.
Typical outputs: threat model report, risk register, findings list with severity, mitigation plan, accepted residual risk statement, updated design, and go/no-go decision for the gate.

6. Common Design Flaws Found in Reviews

- Authorization performed only on the client side.
- Trusting data from another internal service without validation (implicit trust inside the perimeter).
- Sensitive data transmitted or stored without encryption, or with weak or home-grown cryptography.
- Shared service accounts with broad privileges.
- Missing or insufficient audit logging, undermining non-repudiation.
- Security decisions based on unverified identifiers (user ID in a URL or hidden field).
- Single points of failure in authentication or key management.
- Unvetted third-party components or outdated libraries in the bill of materials.
- Verbose error handling that leaks internal structure.
- Secure configuration left to deployment rather than secure by default.

7. How to Answer Exam Questions on Architectural Risk Assessment and Design Review

CSSLP questions in this area are mostly scenario-based and ask for the best or most appropriate action, methodology, or principle. Follow this approach:

Identify the lifecycle phase. If the scenario is in design, the answer will involve threat modeling, attack surface reduction, architecture review, or selecting a secure design pattern, not code review, static analysis, or penetration testing (those belong to later phases).

Match the keyword to the concept. Spoofing, tampering, repudiation, disclosure, DoS, elevation point to STRIDE. Damage, reproducibility, exploitability, affected users, discoverability point to DREAD. Seven stages and business impact point to PASTA. A root goal with branching attacker methods is an attack tree. A hostile actor described in use-case form is a misuse case. Entry points and exposed interfaces point to attack surface analysis. Monetary figures point to SLE, ARO, and ALE.

Look for the trust boundary. When a scenario describes data moving between a client and a server, between services, or to a third party, the correct answer almost always involves validating, authenticating, authorizing, or encrypting at that crossing.

Apply the principle that fixes the root cause. If a component has more rights than it needs, the answer is least privilege. If one control failing exposes everything, the answer is defense in depth. If an error grants access, the answer is fail secure. If a design relies on secrecy of the algorithm, the answer is open design. If security is bypassed by users because it is cumbersome, the answer is psychological acceptability.

Remember who owns risk. Developers and architects identify and recommend; the business owner or designated risk owner accepts residual risk. Any answer where the developer unilaterally accepts risk is wrong.

Prefer prevention and early detection. When choosing among options, the one that identifies or eliminates the flaw earliest in the SDLC and at the design level is usually correct.

Prefer proven, standardized mechanisms. Answers advocating custom cryptography, custom authentication protocols, or obscurity as a primary control are distractors.

Watch qualifiers. Words like FIRST, BEST, MOST, PRIMARY, and NEXT change the answer. The FIRST step in threat modeling is to define scope and decompose the application (understand what you are building); identifying threats comes after you know the components and data flows. The FIRST step in risk assessment is identifying assets.

8. Exam Tips: Answering Questions on Architectural Risk Assessment and Design Review

- Tip 1: Know STRIDE cold, including the security property each letter maps to (Spoofing to authentication, Tampering to integrity, Repudiation to non-repudiation, Information Disclosure to confidentiality, Denial of Service to availability, Elevation of Privilege to authorization). Questions often give the property and ask for the threat, or vice versa.
- Tip 2: Distinguish threat identification methods (STRIDE, attack trees, misuse cases) from threat rating methods (DREAD, CVSS, OWASP risk rating). If the question asks how to prioritize, DREAD or a risk-scoring method is the answer, not STRIDE.
- Tip 3: Threat modeling is a design-phase activity that produces a living artifact. If a question asks when to perform or update a threat model, the answer is during design and whenever the architecture changes significantly.
- Tip 4: Data Flow Diagrams with trust boundaries are the canonical decomposition artifact for threat modeling. If asked which diagram best supports threat identification, choose the DFD.
- Tip 5: Attack surface reduction means removing or disabling unneeded features, services, ports, and privileges. It is a design decision, and it directly lowers likelihood.
- Tip 6: Risk = likelihood x impact. Controls that reduce likelihood are preventive; controls that reduce impact are often detective or corrective, or involve segmentation and limiting blast radius. Be ready to classify.
- Tip 7: Recognize all four risk treatments and that residual risk must be explicitly accepted by the appropriate business authority and documented.
- Tip 8: For quantitative questions, memorize SLE = AV x EF and ALE = SLE x ARO, and that a control is justified when its annual cost is lower than the ALE reduction it provides.
- Tip 9: A design review verifies that requirements are met and principles are followed; it is not the place to test code. If a scenario says a design review discovered an issue, the fix is a design change, not a patch.
- Tip 10: The CSSLP exam favors answers that are holistic, risk-based, and aligned to business objectives. Between a purely technical answer and one that ties the control to business risk and stakeholder acceptance, the latter is usually correct.
- Tip 11: Third-party and open-source components are part of the architecture. A complete architectural risk assessment includes the software supply chain: component inventory (SBOM), license and vulnerability review, and trust decisions about external services.
- Tip 12: Eliminate distractors that rely on security through obscurity, that defer security to a later phase, that let developers accept risk, or that treat a one-time assessment as sufficient.

9. Quick Reference Summary

- Purpose: find and treat structural security risk before implementation; design flaws are roughly half of all security defects and are cheapest to fix in design.
- Core activity: threat modeling (scope, decompose with DFDs and trust boundaries, identify threats, rate, mitigate, validate, iterate).
- Methodologies: STRIDE (identify), DREAD (rate), PASTA (risk-centric, seven stages), Trike, VAST, OCTAVE, attack trees, misuse cases.
- Supporting analyses: attack surface analysis, asset valuation, qualitative and quantitative risk analysis (SLE, ARO, ALE).
- Review criteria: security requirements, secure design principles (least privilege, defense in depth, fail secure, complete mediation, open design, economy of mechanism, separation of duties, least common mechanism, psychological acceptability, weakest link, leverage existing components), compliance mandates.
- Outputs: threat model, risk register, prioritized mitigations, residual risk acceptance by the business owner, gate decision, traceability to verification.
- Exam mindset: shift left, fix root causes at the design level, protect every trust boundary, prefer proven mechanisms, and align every decision to business risk.