Secure Design Review Scenarios
Key Takeaways
- A secure design review identifies assets, data flows, trust boundaries, assumptions, control gaps, and residual risk before deployment.
- Threat modeling helps teams reason about spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
- Design reviews should produce specific changes, such as narrowed ACLs, stronger identity, logging, encryption, or segmentation.
- The best exam answer usually addresses the most direct risk with the least disruptive effective control.
- Secure architecture is iterative: validate assumptions, test controls, document exceptions, and monitor after release.
Secure Design Review Scenarios
A secure design review asks whether a proposed system can meet its security requirements before it goes live. For Security+, focus on identifying the highest-risk gap and choosing a control that fits the scenario.
Review Inputs
| Input | Why it matters |
|---|---|
| Data-flow diagram | Shows where data moves and where trust changes |
| Asset inventory | Identifies what must be protected |
| Data classification | Determines required handling controls |
| Identity model | Shows users, admins, service accounts, and federation |
| Network design | Shows segmentation, exposure, and allowed paths |
| Logging plan | Shows whether events can be investigated |
| Resilience plan | Shows backup, failover, and recovery expectations |
Threat Modeling Shortcut
STRIDE is a common threat-modeling memory aid:
| STRIDE item | Question to ask | Example control |
|---|---|---|
| Spoofing | Can someone pretend to be another identity? | MFA, certificates, strong service identity |
| Tampering | Can data or code be altered? | Integrity checks, code signing, access control |
| Repudiation | Can actions be denied later? | Logging, time sync, nonrepudiation controls |
| Information disclosure | Can sensitive data be exposed? | Encryption, DLP, least privilege |
| Denial of service | Can availability be disrupted? | Rate limiting, redundancy, DDoS protection |
| Elevation of privilege | Can a user gain more access? | Least privilege, patching, PAM |
Scenario 1: Partner API
An insurance company exposes a claims API to a partner. The partner needs to submit claims, but should not read all customer records.
Design review findings:
| Finding | Better design |
|---|---|
| Shared API key used by all partner users | Use partner identity, scoped tokens, and rotation |
| API can read and write all claim records | Restrict scopes and object-level authorization |
| No rate limit | Add rate limiting and anomaly alerts |
| Logs exclude partner identity | Log subject, action, object, source, and result |
| API accepts unvalidated payloads | Validate schema and reject unexpected fields |
Best exam answer: use scoped authorization and strong partner identity, not a single shared secret with broad access.
Scenario 2: New Admin Portal
A team proposes a new admin portal for production support. It is reachable from the internet because support staff work remotely.
Minimum safer design:
- Require SSO and phishing-resistant MFA where supported.
- Restrict access by device posture and risk.
- Put the portal behind ZTNA or VPN rather than open internet access where feasible.
- Use privileged access management for high-risk actions.
- Log admin sessions and sensitive changes.
- Separate approval for destructive operations.
Trap: "Use HTTPS" is necessary but incomplete. TLS protects data in transit; it does not prove the user should be allowed to administer production.
Scenario 3: Analytics Copy of Production Data
A product team wants a copy of production customer data for analytics in a development environment.
Better design choices:
| Requirement | Control |
|---|---|
| Developers need trends, not identities | Mask, tokenize, or anonymize direct identifiers |
| Data is copied between environments | Encrypt transfer and restrict destination |
| Development has weaker controls | Do not place regulated raw data there |
| Query activity must be auditable | Enable logs and review privileged access |
| Retention must be limited | Set expiration and deletion process |
Best exam answer: minimize and de-identify the data. Do not simply grant developers production database access.
PBQ-Style Walkthrough
Task: Review a diagram and choose the three most important fixes.
Facts:
- Public web app accepts payments.
- Database with cardholder data is reachable from the web subnet and the user workstation subnet.
- Admins share a local administrator account.
- Logs stay only on each server.
- Backups exist but have never been restored.
Priority fixes:
- Restrict database access to only required application sources.
- Replace shared admin use with named privileged accounts, MFA, and session logging.
- Centralize logs and test backup restoration.
Why not pick "change the logo" or "buy faster servers"? They do not address confidentiality, integrity, accountability, or recoverability.
Design Review Output
A useful review result is specific:
- Risk: Database accepts connections from user workstation subnet.
- Impact: Customer data could be queried after workstation compromise.
- Recommendation: Deny workstation subnet, allow only app security group on database port, monitor denied attempts.
- Owner: Infrastructure team.
- Due date: Before production release.
- Residual risk: App-tier compromise could still reach database; monitor and harden app tier.
For the exam, favor answers that are actionable, mapped to risk, and aligned with least privilege.
A design review finds that developers want raw production customer data in a test environment. Which recommendation is best?
Which findings from a secure design review should be prioritized? Choose two.
Select all that apply
Which review output is most useful?