Threat Modeling and Risk Assessment Questions

Systematic identification and evaluation of threats, vulnerabilities, assets, and attack surfaces to determine likelihood and business impact and to drive prioritized security controls. This topic covers threat modeling techniques and structured methodologies such as STRIDE, PASTA, and attack trees, enumeration of threat actors and attack vectors, scenario based attack simulation, and attack surface analysis. Candidates should be able to quantify risk using likelihood and impact, risk matrices, and concepts such as risk velocity, and explain how to integrate threat intelligence into probability assessments. The topic includes translating threat models into prioritized mitigations, detection and monitoring requirements, and security architecture or design trade offs that balance security with business objectives and operational constraints. At larger scale it covers enterprise risk assessment practices, alignment with risk management frameworks such as NIST and ISO 31000, integration with vulnerability assessment and vulnerability management programs, risk quantification, and effective communication of risk and remediation priorities to technical teams and executive stakeholders.

MediumTechnical

78 practiced

Given an AWS-hosted SaaS architecture with public S3 buckets, Lambda functions running with IAM roles, RDS in a private subnet, and a CI/CD pipeline that uses deploy keys, enumerate the top threats, likely attack paths an adversary might take, and propose 3–5 prioritized mitigations. Justify the prioritization using likelihood and business impact.

Sample Answer

**Situation overview (short)** Public S3 buckets, Lambda with IAM roles, RDS in private subnet, CI/CD using deploy keys. As Security Architect I’d enumerate threats, attack paths, then propose prioritized mitigations based on likelihood × business impact.

**Top threats & likely attack paths**- Public S3 data exposure — attacker enumerates/public objects → exfiltrate sensitive data or find credentials. - Compromise of Lambda execution role — vulnerable function code or dependencies → privilege escalation to other AWS services (S3, Secrets Manager, RDS proxy). - Stolen/compromised CI/CD deploy keys — attacker pushes malicious code or modifies infra (IAM, Lambda env vars) to implant backdoor. - RDS access via compromised app credentials or compromised Lambda with network access → data exfiltration or tampering. - Supply-chain / dependency compromise in build pipeline → malicious code into production.

**Prioritized mitigations (3–5)**1. Least privilege + role segmentation for Lambda (High impact, medium likelihood) - Use narrow IAM policies, separate roles per function, block wildcard permissions. Enforce IAM permission boundaries and monitor via IAM Access Analyzer. - Justification: prevents lateral movement if function compromised; high ROI.

2. Lock down S3 + automated discovery (High impact, high likelihood) - Make buckets private by default, enable bucket policies, block public ACLs, enable S3 Block Public Access, enable object-level encryption, and run automated scans & alerts for public objects (AWS Config, Detective). - Justification: public buckets are easy to discover and commonly exploited.

3. Harden CI/CD secrets and ephemeral credentials (High impact, medium likelihood) - Replace long-lived deploy keys with short-lived OIDC tokens or ephemeral creds via AWS STS; store secrets in Secrets Manager with rotation; enforce signed commits and branch protections. Audit pipeline actions. - Justification: prevents persistent foothold via leaked keys.

4. Network + DB protections (Medium impact, medium likelihood) - Use RDS IAM auth, restrict subnet security groups to minimal egress, enable encryption at rest/in transit, DB activity monitoring, and least-privileged app DB users. Add an RDS proxy to centralize credentials. - Justification: reduces data-exfil risk even if app compromised.

5. Pipeline and dependency controls (Medium impact, medium-low likelihood) - Implement SBOM, dependency scanning, reproducible builds, and CI sandboxing; require code reviews and signed artifacts. - Justification: prevents supply-chain insertion.

**Closing rationale** Prioritized mitigations address highest-probability, highest-impact vectors first: public data exposure and credential/role compromise. Controls combine prevention, detection, and rapid remediation to minimize blast radius and preserve business continuity.

MediumTechnical

76 practiced

An API gateway exposes several hundred endpoints. Propose a set of attack-surface reduction techniques (both design-time and runtime) you would apply to the gateway and describe how you would measure and quantify the reduction in risk or attack surface.

Sample Answer

**Design-time controls**

- API hygiene: remove/merge deprecated endpoints, strict versioning, and minimize public surface (only publish necessary endpoints).- Strong API contract/schema: enforce OpenAPI with strict request/response validation and reject unknown fields.- Principle of least privilege: fine-grained scopes/claims, attribute-based access control (ABAC) for sensitive operations.- Authentication & transport: OAuth2 + mTLS for service-to-service, short-lived tokens, JWKS rotation.- Network segmentation: split gateway into public vs internal zones, use private APIs for backend-only functions.- Threat modeling: enumerate attack paths per endpoint, prioritize by sensitivity and exposure.

**Runtime controls**

- Rate limiting & throttling: per-client, per-endpoint quotas and dynamic throttles tied to anomaly detection.- WAF + behavioral API anomaly detection: detect parameter fuzzing, credential stuffing, schema anomalies.- Circuit breakers & backpressure: prevent amplification and resource exhaustion.- Runtime allowlists: whitelist known clients/IPs for admin/internal endpoints.- Robust logging, distributed tracing, and alerting with SLA for MTTR.

**Measurement & quantification**

- Baseline inventory: total endpoints, public vs internal, sensitive operations (e.g., 400 total, 200 public, 50 sensitive).- Exposure score: compute weighted sum

text

Exposure = sum_over_endpoints (reachability_weight * sensitivity_weight)

Plain-English: higher if endpoint is public and sensitive.

- Control effectiveness: measure % reduction in Exposure after controls. Example: removing 40 public endpoints and reclassifying access reduces Exposure by X%.- Attack surface metrics: # reachable endpoints, # of overly-permissive scopes, vuln density (vulns / endpoints) from automated scans and pentests.- Operational metrics: requests/sec allowed, rate-limit blocks, false positive rate, mean time to detect (MTTD) and mean time to respond (MTTR), exploitation attempts blocked.- Risk reduction: map vulnerabilities to CVSS and calculate expected loss reduction by reduced exploitability and attack frequency (use historical attempt rates to estimate).- Continuous validation: run weekly automated scanners, monthly red-team, and track trend lines on dashboard (Exposure, vuln density, MTTD, MTTR). Use these to report percent reduction in risk and improvements over time.

Example: baseline Exposure 1000 -> after controls 420 = 58% reduction; MTTD from 6h to 45m; exploit attempts blocked increased by 300% (fewer successful ones).

EasyTechnical

74 practiced

Describe what threat modeling is and why an organization should invest in threat modeling as part of its security architecture program. Include the main objectives, common outputs (for example: threat lists, attack trees, data-flow diagrams, misuse cases), typical stakeholders to involve, and at least two concrete ways threat modeling influences design decisions and enterprise risk management.

HardSystem Design

72 practiced

Design an enterprise threat modeling program for a global company with 10,000 employees and 500 applications. Define governance (roles and responsibilities), end-to-end process workflows, tooling (including automation and integration points), KPIs to measure program health, onboarding for new teams, and how to scale peer reviews while keeping models current.

Sample Answer

**Assumptions / Goals**Protect 500 apps and 10k employees globally; integrate threat modeling into SDLC, reduce exploitable design flaws, and provide measurable risk reduction.

**Governance (roles & responsibilities)**- Chief Security Architect: program owner, KPI reviewer, budget sponsor.- Threat Modeling Lead: standards, tooling, training, certifier.- App Security Champions (per dev org): run local models, coordinate reviews.- Review Panel (rotating SMEs from infra, dev, SRE, privacy): perform peer reviews for high-risk apps.- Product/Engineering Owners: own remediation and risk acceptance decisions.- Risk & Compliance: map outputs to enterprise risk register and audits.

**End-to-End Workflow**1. Intake & Classification: app inventory → categorize by criticality + data sensitivity.2. Trigger: model required at design, major change, or quarterly for critical apps.3. Create Model: threat modeling template (data flows, trust boundaries, assets, threats).4. Automated Analysis: run static DFD checks, dependency scanning, IaC policy checks.5. Peer Review: asynchronous SME review via platform; escalations to Review Panel for high risk.6. Remediation & Tracking: JIRA integration; risk owner signs off.7. Continuous Update: model refreshed on deployments, infra changes, or monthly automated drift detection.

**Tooling & Integrations**- Central TM platform (commercial or in-house) storing models, templates, lineage.- Integrations: SCM (GitHub), CI/CD (Jenkins/GitHub Actions), IaC scanners (TFsec), SCA, SAST, ticketing (JIRA), CMDB.- Automation: DFD extraction from code/IaC, automatic threat pattern detection, scheduled drift scans, webhook triggers for model re-eval on PRs.- Collaboration: Slack/MS Teams notifications, inline commenting.

**KPIs**- Coverage: % apps with current model (goal 100% critical, 80% others).- Time-to-model: avg days from trigger to accepted model.- Remediation lead time: median days to close findings.- Acceptance rate: % of findings accepted vs mitigated.- False-positive rate of automated detections.- Reduction in design-related incidents year-over-year.

**Onboarding for New Teams**- 2-hour workshop + hands-on 1-day lab using a sample app.- Playbook, checklist, starter templates, recorded sessions.- Assign an App Security Champion mentor for first two models.- Certification badge after first successful model submission.

**Scaling Peer Reviews & Keeping Models Current**- Triage by automated severity scoring to route only high-risk items to Review Panel.- Use asynchronous reviews with SLAs; rotate SMEs to avoid bottlenecks.- Introduce “lightweight” reviews for low-risk apps (single champion + automated signoff).- Continuous monitoring: CI triggers model re-eval; scheduled quarterly automated drift checks.- Maintain model lineage and change history; require re-approval for any boundary changes.

**Trade-offs**- Balance depth vs velocity: automated checks reduce load but need tuning.- Investment in platform vs manual effort: higher upfront tooling cost yields scalable automation.

This design provides governance, automation, measurable KPIs, and a scalable peer-review model suitable for a global 10k-employee enterprise.

EasyBehavioral

64 practiced

Tell me about a time you led a cross-functional threat modeling workshop. Use the STAR framework: set the Situation, describe the Tasks and Actions you took (methods like STRIDE/PASTA, facilitation approach), explain the Results, and describe any follow-up actions or lessons learned.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.