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 with STRIDE structures reasoning about spoofing, tampering, repudiation, disclosure, denial of service, and elevation of privilege.
- Reviews must produce specific changes such as narrowed ACLs, stronger identity, logging, encryption, or segmentation.
- The best exam answer addresses the most direct risk with the least disruptive yet effective control.
- Secure architecture is iterative: validate assumptions, test controls, document exceptions, and keep monitoring after release.
What a Design Review Decides
A secure design review asks whether a proposed system can meet its security requirements before it goes live. For SY0-701 the skill being tested is judgment: find the highest-risk gap and pick the control that fits the scenario with the least disruption. The exam rewards specific, actionable, risk-mapped answers and punishes vague ones like "be more secure."
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 the required handling controls |
| Identity model | Shows users, admins, service accounts, federation |
| Network design | Shows segmentation, exposure, and allowed paths |
| Logging plan | Shows whether events can later be investigated |
| Resilience plan | Shows backup, failover, and recovery expectations |
STRIDE Threat Modeling
STRIDE is the threat-modeling mnemonic CompTIA leans on. Each letter maps a threat category to a control class.
| STRIDE item | Question to ask | Example control |
|---|---|---|
| Spoofing | Can someone impersonate an identity? | MFA, certificates, strong service identity |
| Tampering | Can data or code be altered? | Integrity checks, code signing, access control |
| Repudiation | Can an action be denied later? | Logging, time sync, non-repudiation signatures |
| Information disclosure | Can sensitive data leak? | 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 must submit claims but must not read all customer records.
| Finding | Better design |
|---|---|
| Single shared API key for all partner users | Per-partner identity, scoped tokens, rotation |
| API can read and write every claim | Restrict scopes plus object-level authorization |
| No rate limiting | Add rate limits and anomaly alerts |
| Logs omit partner identity | Log subject, action, object, source, and result |
| Unvalidated payloads accepted | Validate the schema and reject unexpected fields |
Best exam answer: scoped authorization with a strong partner identity, never one shared secret carrying broad access.
Scenario 2: New Admin Portal
A team proposes an internet-reachable admin portal for remote production support.
- Require SSO and phishing-resistant MFA (FIDO2/WebAuthn) where supported.
- Gate access by device posture and session risk.
- Front the portal with ZTNA or VPN rather than raw internet exposure.
- Use PAM for high-risk actions and separate approval for destructive operations.
- Record admin sessions and sensitive changes.
Trap: "Use HTTPS" is necessary but incomplete. TLS protects data in transit; it does not prove the user is authorized to administer production.
Scenario 3: Production Data Copy for Analytics
A product team wants a copy of production customer data in a development environment.
| Requirement | Control |
|---|---|
| Developers need trends, not identities | Mask, tokenize, or anonymize direct identifiers |
| Data is copied between environments | Encrypt transfer and restrict the destination |
| Dev has weaker controls | Do not place regulated raw data there |
| Query activity must be auditable | Enable logging and review privileged access |
| Retention must be limited | Set expiration and a deletion process |
Best exam answer: minimize and de-identify the data. Do not simply grant developers production database access.
PBQ-Style Walkthrough
Review a diagram and choose the three most important fixes. Facts:
- A public web app accepts payments.
- The database with cardholder data is reachable from both the web subnet and the workstation subnet.
- Admins share one local administrator account.
- Logs stay only on each server.
- Backups exist but have never been restored.
Priority fixes:
- Restrict database access to only the required application source.
- Replace the shared admin account with named privileged accounts, MFA, and session logging.
- Centralize logs and test backup restoration.
Why not "change the logo" or "buy faster servers"? Neither touches confidentiality, integrity, accountability, or recoverability.
Anatomy of a Useful Finding
A strong review output is concrete:
- Risk: the database accepts connections from the workstation subnet.
- Impact: customer data could be queried after any workstation is compromised.
- Recommendation: deny the workstation subnet, allow only the app security group on the database port, and alert on denied attempts.
- Owner: infrastructure team.
- Due date: before production release.
- Residual risk: an app-tier compromise could still reach the database, so harden and monitor the app tier.
On the exam, always favor answers that are actionable, mapped to a named risk, and aligned with least privilege.
Secure-by-Design Through the Lifecycle
A design review is one checkpoint in a longer discipline SY0-701 calls secure by design: security requirements are defined before code is written, validated at design, tested before release, and monitored afterward. Map the recurring review themes to lifecycle stages:
- Requirements: classify data and set the controls each classification demands so nothing is retrofitted later.
- Design: run STRIDE threat modeling, draw the data-flow diagram, and confirm secure defaults and least privilege.
- Build and test: scan IaC templates and container images, validate input handling, and verify that logging is actually emitted.
- Deploy: enforce change control and separation of duties so no single person ships an unreviewed production change.
- Operate: monitor, re-review after major changes, and track every accepted exception with an owner and expiry date.
Two trade-offs appear repeatedly in scenarios. First, risk versus cost: the cheapest control that effectively reduces the dominant risk usually wins, so do not over-engineer a low-impact path. Second, residual risk acceptance: after controls are applied, some risk remains, and a mature review documents who formally accepts it rather than pretending it is gone. The strongest exam answers reduce the most direct risk, stay proportional to the threat, and leave a clear, owned record of what was decided.
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 the most useful to an engineering team?