8 Secure Architecture Review and Practice

Purpose of an architecture review

A security architecture review assesses whether a system’s design can meet its security, privacy, availability, and business requirements under realistic failure and attack conditions. It is an engineering activity, not just a checklist: reviewers connect assets and trust boundaries to threats, choose controls that reduce risk, examine costs and limitations, and check that controls work as intended.

Security decisions should be revisited as requirements, threats, or constraints change. A useful review makes clear what must be protected, how harm could occur, why the selected controls are appropriate, what they cost, and how their effectiveness will be demonstrated.

Prepare the review

Define the review’s scope and success criteria before examining controls. Establish the business service the system provides and consider harms from disclosure, alteration, loss, or interruption.

Record which applications, infrastructure, cloud services, third parties, environments, and operational processes are included or excluded. Identify applicable security, privacy, legal, contractual, and recovery requirements, translating them into testable outcomes where possible.

Include system owners, architects, developers, operations, security, privacy, and relevant business or data owners. Gather evidence such as architecture and data-flow diagrams, identity and network policies, configuration records, threat models, incident history, recovery plans, and test results.

A review diagram should show components, data flows, trust boundaries, administrative paths, external dependencies, and where controls are enforced. Mark flows that cross organizational or privilege boundaries, including cloud-provider interfaces and service-to-service calls.

Develop threat scenarios

A Threat scenario describes a plausible chain of events that could cause harm. Avoid vague descriptions such as “hacking.” Specify the actor or cause, starting condition, path through the system, threatened asset, and consequence.

For each scenario, ask:

1. What asset, information, or service is at risk?

2. What must the threat source be able to access or influence?

3. Which trust boundary or dependency does the scenario cross?

4. What weakness, misconfiguration, or failure makes it plausible?

5. What is the impact, and how likely is the scenario in this environment?

6. What evidence supports the assumptions?

Prioritize scenarios by business impact and likelihood, while recording uncertainty. A qualitative scale such as low, medium, and high can organize discussion, but should not be mistaken for precise measurement. Risk assessment involves identifying threats, vulnerabilities, likelihood, impact, and risk responses.

Apply scenarios to a cloud application

Consider a cloud customer application in which a public-facing service calls an application API, and the API reads a managed database. Engineers administer the environment through a separate identity system, while backups are stored in a second account.

One scenario is that an attacker obtains a service credential from a compromised application component and uses it to query customer records. If the credential is broadly privileged, network paths are unrestricted, and database access is not monitored, the attacker may extract data before detection.

This scenario focuses the review on whether the service identity is limited to necessary operations, whether the application can reach only its required database endpoint, whether records are encrypted and key access is separately governed, and whether logs capture meaningful access events and are protected from alteration. Reviewers should also ask whether responders can quickly revoke the credential.

Select controls for the risk

Choose controls according to the risk they reduce, not a product category or checklist count. A useful control statement identifies the protected asset, expected behavior, enforcement point, and evidence that demonstrates operation.

Common control layers include:

• Identity and access: Use strong authentication, Least privilege, scoped service identities, time-limited administrative access, and periodic access reviews.

• Segmentation: Restrict communication among user, application, data, management, and recovery environments. Use explicit allow rules; network location alone does not establish trust. Zero-trust approaches verify access to individual resources rather than relying on implicit trust from network position.

• Data protection: Classify information; minimize collection and retention; encrypt data in transit and at rest; restrict key administration; record sensitive access; and securely dispose of data when it is no longer required.

• Cloud governance: Confirm which party operates each control, how provider evidence is obtained, and whether service configuration, data location, logging, and recovery meet organizational requirements. Provider capabilities do not automatically satisfy customer responsibilities.

• Detection and response: Centralize relevant logs, alert on suspicious behavior, define response ownership, and ensure responders can isolate systems and revoke credentials.

• Resilience: Set business-approved recovery objectives, protect backups from compromise or deletion, plan for degraded operation, and test restoration rather than only backup creation.

Use control catalogs such as NIST SP 800-53 to identify candidate controls, then tailor them to the system’s context and risk. A catalog supports selection; using it does not prove that a system is secure.

Compare trade-offs and record risk

Controls may add cost, operational burden, latency, complexity, or new failure modes. For each significant design choice, compare alternatives and record why the selected option is appropriate.

• Fine-grained service segmentation: It can limit lateral movement and unintended access, but adds policy rules and troubleshooting effort. Ask whether an unauthorized service connection can be shown to fail.

• Stronger administrator authentication: It can reduce the risk from stolen passwords, but recovery and emergency-access procedures must be maintained. Check whether authorized staff can safely recover access without bypassing controls.

• Separate, protected backups: They can help recover from deletion or ransomware, but add storage, administration, and restoration complexity. Check whether a clean recovery can meet approved objectives.

• Centralized logging: It can improve detection and investigation, but brings cost, sensitive log content, and alert noise. Check whether important events are complete, protected, retained, and actionable.

Document assumptions, alternatives considered, selected controls, dependencies, owners, and Residual risk. Escalate risk acceptance to the role authorized to make that decision. A reviewer should not silently treat an unresolved gap as accepted risk.

Validate controls with evidence

A design review establishes expected behavior; Validation checks whether the implemented system actually exhibits it. Use multiple forms of evidence:

• Inspect: Review policies, configurations, data flows, IAM permissions, encryption and key settings, and backup protections.

• Demonstrate: Ask operators to show how they provision access, revoke a credential, isolate a workload, and restore a service.

• Test: In an authorized test environment, attempt a prohibited connection, use an overly broad identity, trigger an alert, or restore from backup.

• Analyze: Examine logs, vulnerability findings, access reviews, incident exercises, and recovery-test results for gaps and trends.

Define expected results before testing. For example, a compromised web-service identity should not be able to query the payroll database, and a denied attempt should be logged and generate an alert. Record test conditions, results, evidence, limitations, and the remediation owner. Tests must be authorized and designed to avoid unintended disruption or exposure of sensitive data.

NIST SP 800-53A provides a structured approach to assessing security and privacy controls through examination, interview, and testing procedures.

Practice a complete review

For the cloud application, assume a new requirement that the customer service remain available during a regional outage and that customer records not be exposed through routine developer access.

1. Draw the system’s components, data flows, trust boundaries, and administrative paths.

2. Write three threat scenarios: one involving credential theft, one involving unintended data exposure, and one involving an outage or destructive event.

3. For each scenario, identify the threatened asset, likely impact, existing controls, and remaining gap.

4. Select one preventive, one detective, and one recovery control per scenario, and explain why each addresses the scenario.

5. Compare at least two regional-recovery alternatives. Consider cost, complexity, recovery speed, data-loss tolerance, and security implications.

6. Define a validation test and objective evidence for each selected control.

7. Record assumptions, residual risks, owners, and review dates.

A strong review explains what must be protected, how a threat could cause harm, why selected controls reduce risk, what they cost, and how their effectiveness will be demonstrated.

Keep the review current

Effective reviews begin with mission, assets, boundaries, and requirements. They turn vague concerns into credible scenarios, select layered controls matched to those scenarios, make trade-offs and remaining risks explicit, and verify intended behavior using configuration evidence, demonstrations, and authorized tests.

Revisit the review as the system, its dependencies, and its threat environment evolve.