Threat Modeling Fundamentals Questions

Demonstrate the ability to identify, analyze, and prioritize threats to systems and architectures. Core skills include mapping attack surfaces, enumerating threat actors and their capabilities, applying threat modeling frameworks and methodologies, assessing likelihood and impact, and proposing mitigations and design changes to reduce risk. Candidates should be familiar with common classes of threats and trade offs when selecting defenses.

MediumTechnical

70 practiced

Design a validation plan that uses penetration testing and red-team exercises to test a completed threat model for a public-facing REST API. Define scope, hypotheses derived from the threat model to be tested, success criteria for the tests, and how test findings will map back into the threat model and remediation workflow.

MediumTechnical

68 practiced

Describe the fields and structure of a risk register produced from threat modeling outputs for a mid-sized SaaS product. Explain how items are triaged, assigned to owners, tracked through to mitigation, and how SLA-like expectations (e.g., time-to-remediate) are set with product teams.

Sample Answer

**Risk Register — fields & structure**

- ID: unique numeric/string- Title: concise vulnerability/threat- Source: threat-model artifact (e.g., data flow: auth service)- Description: threat scenario + attack path- Impact: Confidentiality/Integrity/Availability rating (H/M/L) with business impact notes- Likelihood: qualitative + rationale (exploitability, exposure)- Risk Score: numeric (e.g., CVSS-like or (Impact×Likelihood))- Affected Assets: services, components, data stores, diagrams ref- Mitigation Options: short-term compensating controls + long-term fix- Current Status: New / Triaged / Assigned / In Progress / Mitigated / Accepted- Owner: engineering owner (team + individual), security lead- ETA / SLA: time-to-remediate target- Verification: test/PR/patch ID and verification date- Residual Risk & Acceptance: approver and date- Links: tickets, threat model output, evidence

**Triage & Assignment**

- Triage board run daily by Security Triage (security eng + product/ops reps).- Use risk score + blast radius to bucket into P0/P1/P2: - P0: exploitable RCE/data leak in prod — SLA 72hrs - P1: auth bypass / sensitive data exposure — SLA 14 days - P2: low-impact or long-term design — SLA 90 days- Assign owner based on affected service; security proposes remediation, product schedules work.

**Tracking to Mitigation**

- Create JIRA ticket from register entry; ticket ID in register.- Security reviews PRs, provides test cases, and marks Verification when tests pass.- Weekly dashboard: open risks, aging, SLA breaches; monthly risk review with product leads.

**Setting SLA-like Expectations**

- SLAs negotiated with product teams, mapped to risk buckets and business impact.- Use historical remediation metrics to set realistic targets; include “fast-track” for exploit-in-the-wild.- Enforcement: risk aging alerts, exec escalation for SLA breaches, and temporary compensating controls until remediation.

This structure ensures traceability from threat model to verified mitigation, clear ownership, and operational SLAs that balance risk and product velocity.

HardTechnical

57 practiced

You've implemented mitigations for the top ten risks from a threat model. Explain how you would quantify residual risk, create executive-level metrics (for example: 'mean time to detection', 'percent of critical services with mitigations implemented', 'expected monetary loss reduction'), and justify acceptance or further investment to business stakeholders with supporting data and confidence intervals.

Sample Answer

**Summary approach** Calculate residual risk by estimating post-control likelihood and impact, quantify uncertainty with probabilistic modeling, then present 3–4 executive metrics with confidence intervals and a recommendation tied to ROI.

**How I quantify residual risk** - For each threat: estimate prior likelihood and impact, apply control effectiveness (percent reduction), combine to get residual risk. - Use Monte Carlo (or Bayesian) simulation across distributions to capture uncertainty and produce a 95% CI for residual risk.

text

Residual Risk = Likelihood_post  *  Impact_post

Plain-English: multiply the control-adjusted probability an event occurs by its expected impact.

**Executive metrics (examples)** - Mean Time to Detection (MTTD): median and 95% CI from telemetry; e.g., MTTD = 8 hrs (95% CI 6–12 hrs). - Percent critical services mitigated: 92% implemented, 95% CI from verification sampling ±3%. - Expected Monetary Loss Reduction (EMLR): difference between baseline and residual expected annual loss with CI.

text

Expected Loss = Σ (Probability_i * Impact_i)
EMLR = Expected Loss_baseline - Expected Loss_residual

**Justifying acceptance vs further investment** - Show EMLR and cost of additional controls; compute payback and Net Present Value using conservative CIs. - Example: additional control costs $200k, reduces expected annual loss by $80k (95% CI $60–$100k) → payback 2.5 years; if upper CI still > cost, recommend invest. - If residual risk falls within business risk appetite (e.g., < $X or likelihood < Y%), recommend acceptance and periodic review; otherwise fund further controls or transfer risk.

**Confidence & action plan** - State confidence drivers: data sources, simulation size, detection telemetry coverage. - Recommend monitoring: continuous metrics pipeline, quarterly re-evaluation, and acceptance thresholds tied to CI bounds.

HardTechnical

73 practiced

Model an advanced persistent threat (APT) that targets your CI/CD pipeline to insert a backdoor into a signed release artifact. Describe probable attack steps (credential theft, compromised build agents, tampering with build scripts, signing key compromise), the TTPs you expect, controls that would detect or prevent each step, and an incident containment and recovery plan that restores trust in the build system.

Sample Answer

**Threat model summary** An APT seeks persistence in our CI/CD to inject a backdoor into a signed release. Objectives: modify build output, get artifact signed, and maintain long-term stealthy access.

**Probable attack steps & TTPs** 1. Reconnaissance — enumerate CI servers, build agents, signing tooling (OSINT, internal scanning). 2. Initial access — spearphish dev or CI admins; exploit exposed API keys or VPN credentials. 3. Credential theft & persistence — deploy credential harvesters, install reverse shells, steal service tokens from credential stores (Mimikatz-like, custom scripts). 4. Compromise build agents — lateral movement to build runners; implant malicious runner image or kernel rootkit. 5. Tamper build scripts/pipelines — alter pipeline steps or inject pre/post-build hooks to add backdoor into binaries or packages. 6. Signing key compromise — copy or misuse code-signing keys, or modify signing service to sign tainted artifacts. 7. Exfiltration & cleanup — exfiltrate keys/artifacts, erase logs, implement stealth backdoors for future access.

**Detect/Prevent controls (mapped to steps)** - Recon: network segmentation, asset inventory, WAF, honeypot CI endpoints. - Initial access: MFA, phishing-resistant auth (FIDO2), isolated admin workstations, hardened VPN. - Credential theft: secrets management (vault with ACLs, short-lived tokens), endpoint EDR, credential guard, key rotation, least privilege. - Build agent compromise: immutable build agents, ephemeral containers, signed runner images, attestation (remote/TPM), runtime EDR for containers. - Pipeline tampering: pipeline-as-code in repo with protected branches, CI config signing, required code reviews, policy-as-code (OPA) gating. - Signing key compromise: HSM/PKCS#11 or cloud KMS, MFA for signing operations, signing audit logs, threshold signing (M-of-N), offline/key ceremony. - Detection: artifact integrity checks (SBOMs, reproducible builds, binary transparency), anomaly detection on build sizes/timestamps, SIEM correlation of unusual pipeline runs.

**Containment & recovery plan** - Immediate: Revoke CI service tokens, isolate compromised agents, block attacker C2, enforce MFA, snapshot affected systems for forensics. - Eradication: Rebuild all build agents from trusted images, rotate all secrets and signing keys (perform key revocation), revoke and re-issue certificates via HSM with new key material generated in secure ceremony. - Restore trust: Reproduce builds from source in air-gapped environment, verify reproducible builds match expected outputs, publish reproducible build proof and new SBOMs, re-sign artifacts with new keys. - Post-incident: Full forensic report, strengthen controls above, implement continuous attestation, mandatory pipeline signing and transparency logs, run purple-team exercises, set SLAs for key rotation and agent rebuilds.

**Metrics & lessons** Track time-to-detect, time-to-rotate keys, number of affected releases. Prioritize eliminating long-lived credentials and moving signing into HSMs with multi-party approval.

HardTechnical

59 practiced

Given this architecture description, identify hidden trust boundary misconfigurations and propose design changes:

- Mobile app (public) communicates with an API Gateway (public L7) → routes to API service running in the same VPC as the database- API service connects directly to Database on port 5432 with a single shared DB credential- Admin UI deployed in the same cluster as the API uses the same DB credentials and exposes an admin route on a public load balancer- CI system can run arbitrary scripts that have network access to the cluster

List at least five issues, explain the associated risks, and propose fixes prioritized by impact and effort.

Sample Answer

**Approach (brief)** I'll enumerate hidden trust-boundary misconfigurations, explain risk, and propose prioritized mitigations (impact / effort).

**Top issues, risks, and fixes (prioritized)**

1) Shared DB credential for API + Admin UI - Risk: Single credential broad blast radius; credential leak -> full DB compromise. - Fix: Use short-lived, per-service DB credentials via IAM-based auth (e.g., cloud IAM DB auth, Vault DB secrets engine). Rotate automatically. - Impact: High. Effort: Medium.

2) Admin UI exposed on public LB in same cluster - Risk: Admin route public → exposed control plane, UI CSRF/FFI, credential capture. Lateral move to DB. - Fix: Move Admin UI to private management network or restrict to bastion / IDP-authenticated VPN, mTLS, WAF. - Impact: High. Effort: Low–Medium.

3) API service and Admin UI in same trust boundary / VPC with direct DB access on 5432 - Risk: East-west lateral movement; compromised pod can reach DB. - Fix: Implement network segmentation: DB subnet private with security groups allowing only app IP ranges and use a DB proxy that enforces RBAC and query restrictions. Pod-level egress controls and service mesh with mTLS. - Impact: High. Effort: Medium–High.

4) CI system can run arbitrary scripts with network access to cluster - Risk: Malicious CI job or compromised runner can exfiltrate secrets or deploy backdoors. - Fix: Harden CI: use ephemeral runners in isolated networks, limit network access, enforce least privilege, sign artifacts, require MR approvals, and scan pipelines for secrets. Store creds in vault with short leases. - Impact: High. Effort: Medium.

5) API Gateway public L7 routes directly to API service in same VPC without WAF/auth contextual checks - Risk: OWASP attacks, credential stuffing, unauthenticated admin routes reachable if routing misconfig. - Fix: Enforce fine-grained authorization at gateway (JWT validation, scope checks), apply WAF, rate limits, and strip unused headers. Ensure separate routes for admin that never traverse public gateway. - Impact: Medium. Effort: Low–Medium.

6) Direct DB port open (5432) rather than proxy with RBAC/observability - Risk: SQL injection, large-scale queries, unmonitored access. - Fix: Use DB proxy (e.g., PgBouncer+auth, RDS Proxy) with query logging, per-user accounts, and network rules. Implement DB audit logging and anomaly detection. - Impact: Medium. Effort: Medium.

**Additional controls (low effort, high value)** - Enforce pod security policies, network policies, and service mesh mutual TLS. - Centralize secrets in Vault with IAM auth and audit logs. - Implement least-privilege DB roles: separate read/write, admin, and monitoring roles. - Threat detection: EDR for nodes, DB anomaly detection, and pipeline integrity checks.

These changes reduce blast radius, add defense in depth, and harden CI/CD and admin surfaces while keeping developer workflows usable.

Unlock Full Question Bank

Get access to hundreds of Threat Modeling Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.