Threat Modeling and Secure System Design Questions

Applying threat modeling and structured problem solving to secure system design. Candidates should be able to decompose complex security challenges by identifying business context, critical assets, threat actors, attack surfaces, and compliance requirements. Topics include threat modeling methodologies, attacker capability and motivation analysis, risk assessment and prioritization, selection of mitigations and compensating controls, and evaluation of trade offs among security, usability, cost, and performance. Candidates should also be able to produce implementation and monitoring plans that address scalability and maintainability and to clearly explain and justify design choices and residual risk to stakeholders.

EasyTechnical

26 practiced

You're shown this simplified IAM policy snippet for cloud storage: { 'Effect': 'Allow', 'Action': ['s3:GetObject','s3:PutObject','s3:DeleteObject'], 'Resource': ['arn:aws:s3:::company-bucket/*'], 'Principal': '*' }. Identify misconfigurations and security risks, explain the potential impact, and propose corrected policy elements and operational controls to reduce risk.

MediumTechnical

27 practiced

Design an initial threat hunting program for a mid-size enterprise. Detail team composition (roles and skills), essential telemetry sources to prioritize, three detection use cases (for example: credential misuse, insider data exfiltration, lateral movement), hypotheses for each use case, data requirements, and success metrics to measure program effectiveness.

Sample Answer

Overview: Build a pragmatic, scalable threat-hunting program focused on high-fidelity telemetry, domain expertise, and measurable outcomes. Start small (Core Team) and iterate into a federated model with stakeholders (IT, App Owners, Legal).

Team composition (roles & skills):- Hunt Lead (Sr. analyst/architect): hunt framework, hypothesis design, tooling selection, stakeholder reporting.- Threat Hunters (2–3): TTP knowledge (ATT&CK), DFIR, scripting (Python/PowerShell), EDR/SIEM expertise, query authoring.- Detection Engineer (1): convert hunts into durable detections/playbooks, testing, tuning, CI for rules.- Data Engineer (1): telemetry ingestion, normalization (CEF/JSON), enrichment, retention policies.- SOC Liaison & Incident Responder: escalate validated findings and measure MTTD/MTTR.- SME Pool (ad hoc): app owners, identity, cloud, network.

Essential telemetry (prioritize):1. Endpoint (EDR telemetry: process, commandline, parent-child, network connections)2. Identity/auth logs (AD, Azure AD, Okta, MFA logs)3. Network metadata (NetFlow, proxy, DNS, cloud VPC flow)4. Cloud audit logs (AWS CloudTrail, Azure Activity Logs)5. Email gateway & DLP logs6. Asset & vulnerability inventory7. SIEM with long-term analytics store (and parquet lake for hunts)

Three detection use cases

1) Credential misuse- Hypothesis: Attackers use stolen credentials to access high-value assets from unusual locations or at anomalous times, bypassing MFA or abusing legacy protocols.- Data requirements: AD/Azure AD auth logs, MFA logs, VPN/remote access logs, EDR process+cmdline, geolocation of IPs, device identifiers.- Detection signals: impossible travel, concurrent logins from different geos, suspicious use of legacy auth protocols, post-auth anomalous process execution.- Success metrics: reduction in dwell time for credential misuse, % hunts that produce validated incidents, false positive rate of rules.

2) Insider data exfiltration- Hypothesis: Data exfiltration involves unusual data staging, large outbound transfers to non-business endpoints, or misuse of cloud storage and removable media.- Data requirements: DLP alerts, cloud storage access logs, proxy/HTTP(S) logs, EDR file access events, email attachments metadata, USB device logs.- Detection signals: abnormal bulk reads of sensitive file paths, uploads to unsanctioned cloud services, repeating chunked transfers, large encrypted archives.- Success metrics: number of prevented exfil attempts, mean time to detect exfil event, precision of detections.

3) Lateral movement- Hypothesis: Attackers escalate privileges then move laterally using living-off-the-land tools, RDP/SMB abuse, or compromised service accounts.- Data requirements: endpoint process trees, SMB/SMB session logs, RDP logs, Windows event logs (4624/4688/7045), service account activity, AD replication logs.- Detection signals: unusual service creation, remote execution patterns, credential reuse across hosts, Kerberos Ticket anomalies.- Success metrics: detected lateral movement chains validated, time from first lateral step to containment, reduction in spread rate.

Operational design & playbooks:- Quarterly hypothesis backlog prioritized by business risk.- Hunt cadence: weekly tactical hunts, monthly strategic hunts against high-risk ATT&CK techniques.- Convert validated hunts into detection rules + playbooks; rule testing in staging, phased rollout.- Data pipeline: normalize to common schema, enrich with asset risk scoring and user risk.- Governance: SLA for hunt triage, IR handoff, and lessons learned.

KPIs & maturity metrics:- Coverage: % critical assets with EDR + logging- Detection quality: precision, recall (estimated), false positive rate- Time metrics: MTTD, MTTR, mean time to validate hunt- Productivity: hunts per analyst per month, detections automated- Business impact: number of incidents prevented, reduction in sensitive data exposure

Roadmap & trade-offs:- Phase 1 (0–3 months): onboard EDR, identity logs, hire core team, run high-priority hunts.- Phase 2 (3–9 months): build data lake, automated enrichment, detection engineering pipeline.- Phase 3 (9–18 months): scale via automation, integrate threat intel, federate hunters across lines of business.

This design balances immediate high-priority telemetry and skilled hunters with an engineering-backed pipeline so hunts translate into lasting detections and measurable business risk reduction.

HardTechnical

48 practiced

Using a FAIR-style probabilistic approach, estimate the Annualized Loss Exposure (ALE) for a customer data breach at an online marketplace. Define model inputs: threat event frequency, vulnerability/exploit probability, asset value, and secondary impacts (fines, remediation, reputational loss). Show calculations with assumed numbers and explain key uncertainties and how mitigation reduces ALE.

Sample Answer

We’ll follow a FAIR-style decomposition: ALE = Annualized Rate of Occurrence (ARO) × Probable Loss Magnitude (PLM). PLM = Primary loss (direct remediation, fines) + Secondary loss (reputation, customer churn).

Model inputs (assumed for an online marketplace):- Threat event frequency (threat community capability × contact rate) → expected threat attempts per year: 50- Vulnerability/exploit probability (probability a threat attempt results in breach): 2% (0.02)- ARO = 50 × 0.02 = 1.0 breaches/year (i.e., ~1 breach per year)- Asset value per breach (records × value per record): 1,000,000 records × $12/record = $12,000,000 (primary exposure cap)- Primary direct costs per breach: - Containment & remediation: $1,200,000 - Regulatory fines & legal: $2,000,000 - Notification/credit monitoring: $800,000 Primary loss = $4,000,000- Secondary impacts (probabilistic): reputational loss leading to revenue drop + customer churn = modeled as 10% chance of massive impact ($20M), 40% chance of moderate ($5M), 50% chance of minimal ($0.5M). Expected secondary loss = 0.10*20M + 0.40*5M + 0.50*0.5M = $2.0M + $2.0M + $0.25M = $4.25M

PLM = Primary ($4.0M) + Secondary ($4.25M) = $8.25M

ALE = ARO × PLM = 1.0 × $8.25M = $8.25M per year

Key uncertainties and sensitivities:- Vulnerability/exploit probability (2%) could be 0.5%–5% depending on defensive controls — changing this scales ARO linearly.- Secondary loss distribution is highly uncertain; reputation impacts are fat-tailed. Small changes to high-impact probability greatly change PLM.- Regulatory fines depend on jurisdiction and breach specifics; legal exposure can spike.

How mitigation reduces ALE (examples with effects):- Strong perimeter + WAF + MFA + secure dev practices: reduce exploit probability from 2% → 0.5% (ARO from 1.0 → 0.25). New ALE ≈ 0.25 × $8.25M = $2.06M.- Data minimization & encryption-at-rest: reduce asset value and regulatory fines (primary loss from $4.0M → $1.5M) and secondary impacts (lower probabilities). If combined with exploit reduction above, PLM might drop to ~$2.5M → ALE ≈ 0.25 × $2.5M = $0.625M.- Rapid detection/IR playbooks reduce containment costs and probability of large secondary events.

Practical recommendations (solutions-architect lens):- Prioritize mitigations that reduce exploit probability and asset value first (MFA, WAF, encryption, RBAC, data retention policy).- Model ranges (low/likely/high) and run sensitivity analysis on exploit probability and secondary-impact tail probability; present ALE as distribution to stakeholders.- Use these quantified ALE reductions to justify investment and map to SLA/security controls in the solution architecture.

HardSystem Design

30 practiced

Design authentication and authorization flows for a zero-trust architecture across users, services, and devices. Include certificate or token issuance, mutual TLS vs token-based approaches, short-lived credentials, Policy Decision Point (PDP) and Policy Enforcement Point (PEP) placements, and discuss latency vs security trade-offs. Justify when you'd choose mTLS over token-based solutions and vice versa.

Sample Answer

Requirements (clarify): strong mutual authentication between users/clients, services, and devices; least-privilege authorization; minimal blast radius; auditability; low-latency for user-facing flows; scalable across many services.

High-level architecture:- Identity Provider (IdP)/Certificate Authority (CA): issues short-lived X.509 certs and OAuth2.0/OIDC tokens.- Certificate Signing Service (CSS): automates device/service cert provisioning (SCEP/EST) and rotation.- Token service (STS): issues short-lived JWTs / PoP tokens for users and services.- Policy Decision Point (PDP): centralized policy engine (e.g., OPA/Gatekeeper, PDP-as-a-service).- Policy Enforcement Points (PEP): sidecars (Envoy), API gateways, service mesh data plane.- Audit/Telemetry and Key/Secrets store (HSM/KMS).

Authentication & issuance flows:- Device/service bootstrapping: hardware-backed keypair -> CSR to CSS -> get short-lived cert (hours) bound to device identity and attestation claims.- User auth: OIDC flow to IdP, strong MFA + device-attestation -> receive short-lived access token (minutes) and refresh token (rotatable).- Service-to-service: prefer mTLS with ephemeral certs via CSS for high-assurance services; alternatively use token-based with mutual Proof-of-Possession (PoP).

Mutual TLS vs token-based tradeoffs:- Use mTLS when: you need cryptographic mutual auth, hardware-backed keys, low replay risk, fine-grained service identity, or when regulatory/audit requires certificate chains. mTLS provides strong non-repudiation and integrates well with service mesh (Envoy) for automated PEP enforcement. Downsides: heavier TLS handshake cost, lifecycle/rotation complexity without automation.- Use token-based (JWT/PoP) when: interoperability with external IdPs, mobile/ browser clients, simpler rotation, or when you need rich claims from IdP (scopes, roles). Tokens are lighter—faster for high-throughput APIs—but riskier if long-lived; mitigate with short lifetimes, PoP, audience/revocation lists.

PDP/PEP placement:- PEPs at ingress: API gateways, sidecar proxies (Envoy) enforce authn/authz checks, cache PDP decisions short-lived (seconds) to reduce latency.- PEPs in-app: for sensitive ops enforce local policy checks with cached decisions and periodic PDP validation.- PDP centralized for consistent policies; scale with distributed replicas and local caching. Use decision caching with TTL and versioning to balance latency vs freshness.

Short-lived credentials & revocation:- Always issue short-lived creds (minutes–hours). For sessions use refresh tokens bound to device and rotate frequently.- Implement revocation via short TTL + revocation list / token introspection endpoint. For certs use OCSP stapling or short cert TTL.

Latency vs security trade-offs:- Low latency: use local PEP caches, accept slightly-stale PDP decisions (TTL 1–5s), use session tokens with PoP to avoid repeated mTLS handshakes.- High security: mTLS with per-connection certs, synchronous PDP checks, minimal caching (near-zero TTL), hardware-backed keys.- Choose hybrid: service mesh mTLS for service-to-service (automated rotation) and token-based OIDC for user/browser flows. Tune TTLs and caching per risk profile.

Justification summary:- Prefer mTLS for machine-to-machine in high-security contexts and internal meshes where automation handles rotation.- Prefer token-based for user-facing, cross-domain, mobile/browser scenarios or third-party integration.- Always combine short-lived credentials, device attestation, centralized PDP with distributed PEPs and telemetry to achieve practical zero-trust with acceptable latency.

MediumTechnical

32 practiced

A vendor-supplied on-prem billing system that processes invoices is end-of-life and cannot be patched in the near term. Propose compensating controls to reduce exposure, including network isolation, access restrictions, monitoring, and data handling. Explain how you would present and justify residual risk and compensating controls to auditors and the business.

Sample Answer

Situation: We have an on‑prem vendor billing system that’s end‑of‑life (EOL) and can’t be patched soon. We must reduce attack surface, protect data, and create an auditable justification for residual risk.

Compensating controls (practical, layered):- Network isolation - Place the system in a dedicated VLAN with strict ACLs; deny all inbound except from approved application servers and management jump hosts. - Use network segmentation with internal firewalls / next‑gen firewall rules and microsegmentation (host-based firewall) to restrict lateral movement. - Remove internet routes and block egress to all non‑approved destinations; allow only required endpoints (e.g., payment gateway IPs) via explicit whitelisting.- Access restrictions - Enforce MFA, just‑in‑time (JIT) privileged access and role‑based least privilege for all admin and service accounts. - Require bastion/jump host with session recording and time‑boxed access windows; disable local interactive logins. - Rotate credentials and use credential vaulting (HashiCorp/CP4S/Key Vault).- Monitoring & detection - Deploy host and network IDS/IPS and endpoint detection & response (EDR) agents in passive/monitor mode if active blocking is risky. - Centralize logs to SIEM with alerts for anomalous logins, privilege escalation, unexpected outbound connections, and file integrity changes. - Implement continuous vulnerability scanning and periodic red/blue team checks focused on this segment.- Data handling & protection - Encrypt data at rest and in transit; implement strict export controls so sensitive billing data cannot be copied out except via approved secure transfer processes. - Implement data minimization: retain only required data, purge old records, and mask/PII tokenize data used in non‑production. - Backups: immutable, offline backups with tested restore procedures.- Operational controls - Formal change control and configuration hardening checklist; disable unused services and remove default accounts. - Business continuity / incident playbook specific to the billing system with RTO/RPO defined. - Contract/vendor plan: require vendor support plan or escrowed code where possible.

Presenting/justifying residual risk to auditors and business:- Document control mapping: map each compensating control to the risk(s) the EOL system introduces and to relevant compliance frameworks (PCI/ SOC/ISO27001).- Quantify residual risk: use likelihood x impact scoring, show pre‑ and post‑control risk levels. Provide metrics (MFA coverage, % of allowed egress, SIEM alerting SLAs).- Provide compensating‑control evidence: network ACL configs, jump host session recordings, SIEM alerts, EDR telemetry, encryption keys management logs, backup snapshots and restore test results.- Risk acceptance workflow: propose time‑boxed risk acceptance (e.g., 6 months) with conditional controls and trigger points (if metrics fall below threshold, require immediate mitigation). Include executive sign‑off and owner assignment.- Business case: compare cost/time of accelerated replacement vs. ongoing control costs and residual risk exposure; highlight mitigations for business continuity and legal/compliance exposure.- Audit readiness: prepare a concise package: control description, implementation evidence, monitoring dashboards, incident playbook, and timeline for remediation/replacement.

Why this approach: layering technical, operational and data controls reduces attack surface, detects and limits compromise, and creates traceable evidence for auditors. Time‑boxed acceptance with measurable KPIs aligns business risk tolerance with a clear migration/replace plan.

Unlock Full Question Bank

Get access to hundreds of Threat Modeling and Secure System Design interview questions and detailed answers.

Join thousands of developers preparing for their dream job.