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

69 practiced

Propose a process to integrate automated vulnerability scan results (software composition analysis, SAST, network scans) into your organization's risk scoring pipeline. Cover deduplication, false-positive suppression, asset context enrichment, correlation with threat intelligence, and feedback loops into patching and SLA management.

Sample Answer

**Overview (one-line)** I would build an automated ingestion pipeline that normalizes scan output, deduplicates and suppresses noise, enriches findings with asset/context and threat intel, scores risk, and feeds patching/SLA workflows with continuous feedback.

**Ingestion & normalization**- Parse SCA/SAST/network scans into a canonical schema (vuln id, scanner, asset id, file/package, line, CVE, severity, confidence, timestamp). - Store raw payloads for forensic replay.

**Deduplication**- Deterministic matching: same CVE/package/version/file/hash + asset identifier → single finding. - Fuzzy matching: map SAST fingerprints (file/line/function) and SCA package names to canonical IDs to collapse duplicates across scanners.

**False-positive suppression**- Apply confidence thresholds per tool and rule; maintain allowlist for accepted findings. - Run automated validation where possible (e.g., test compile, exploitability checks, dependency graph reachability). - Human-in-the-loop triage UI to mark FPs; those labels feed ML-driven suppression rules.

**Asset context enrichment**- Enrich via CMDB/IDAM: owner, environment (prod/preprod), business criticality, exposure (internet-facing), patch-level, container image digest, runtime telemetry. - Use exposure + criticality to weight score.

**Threat intelligence correlation**- Match CVEs/IOCs to feeds (Exploit DB, NVD with EPSS, vendor advisories, Active Campaign intel). - Boost priority if PoC/exploit exists or observed in telemetry/IDS. Record confidence of TI match.

**Risk scoring & prioritization**- Composite score = severity * exploitability_factor * exposure_factor * business_impact * confidence. - Bucket into SLAs (P0/P1/P2) and map to runbooks.

**Automation & feedback into patching/SLA**- Create tickets in ITSM with playbooks and remediation commands; for containers/images, trigger CI/CD rebuilds; for hosts, orchestrate patch jobs. - Automate verification: post-patch re-scan and telemetry check; auto-close on remediation verification, else escalate.

**Metrics & continuous improvement**- Track MTTR, FP rate, dedupe rate, remediation rate; use triage feedback to refine rules and thresholds. - Quarterly review with dev/ops to tune SLAs and update allowlists/runbooks.

EasyTechnical

104 practiced

List and classify likely threat actors for a mid-size e-commerce company (examples: script kiddies, financially motivated cybercriminals, nation-state, insiders, competitors). For each actor specify probable motivations, typical TTPs, and high-level indicators you would look for in logs or telemetry to detect their activity.

Sample Answer

**Overview** Below are common threat actors for a mid-size e‑commerce firm, with motivations, typical TTPs (mapped to MITRE ATT&CK concepts), and high‑level telemetry/log indicators to detect them.

**1) Script kiddies / opportunistic scanners** - Motivation: notoriety, curiosity. - TTPs: automated scanners, simple DDoS, credential stuffing using public lists (TA0001 Reconnaissance, TA0006 Credential Access). - Indicators: high rate of failed logins from many IPs, unusual user‑agent strings, port scan logs, spikes in 404/500 errors, repetitive request patterns in web/app logs.

**2) Financially motivated cybercriminals (fraudsters, carders, ransomware)** - Motivation: theft, fraud, extortion. - TTPs: credential stuffing, carding, web skimming (Magecart), phishing, ransomware lateral movement (TA0001, TA0006, TA0040 Impact). - Indicators: unusual payment API calls, new or altered JS served to checkout pages, anomalous transaction patterns, encrypted backups inaccessible, unusual SMB/RDP access, elevated privilege creation.

**3) Insiders (malicious or negligent employees/contractors)** - Motivation: financial gain, sabotage, data theft, negligence. - TTPs: data exfiltration via cloud storage, abuse of valid credentials, privilege misuse. - Indicators: large file transfers to external email/cloud, access outside business hours, abnormal access to sensitive records, policy violations in DLP alerts.

**4) Competitors (corporate espionage)** - Motivation: steal IP, pricing, customer lists. - TTPs: targeted phishing, supply‑chain compromise, covert scraping, privileged access procurement. - Indicators: targeted spear‑phishing indicators, unusual API scraping patterns, new service accounts, lateral movement to research directories.

**5) Nation‑state / advanced persistent threats (APTs)** - Motivation: strategic espionage, disruption. - TTPs: spear‑phishing, zero‑day exploitation, custom malware, long‑term persistence, credential harvesting (TA0001–TA0043). - Indicators: novel malware signatures, long dwell time, use of C2 domains with low reputation, encrypted beaconing at regular intervals, stealthy privilege escalation patterns.

Detection priorities: baseline normal behavior, deploy EDR/NGFW/WAF, instrument application and payment telemetry, enable authentication logs + MFA telemetry, integrate threat intelligence to map IOCs to telemetry, and set analytic rules for the above indicators.

HardTechnical

57 practiced

You are evaluating two design choices for an internal file-sharing platform: option A uses strict compartmentalization with strong encryption and multi-factor authentication but increases latency and restricts collaboration; option B relaxes access controls but adds extensive monitoring and logging to preserve productivity. Using threat-model outputs, quantify trade-offs between residual risk reduction, user productivity (measurable KPIs), operational cost, and propose a decision framework to choose between A and B.

Sample Answer

**Summary of approach**I’d translate threat-model outputs into measurable deltas for risk, productivity, and cost, then apply a weighted decision framework tied to business impact (CISO/owners). Below I quantify trade-offs and give a repeatable decision framework.

**Quantified trade-offs (example using threat-model outputs)**- Residual risk reduction - Option A: threat-model shows 70% reduction in unauthorized data-exfil risk (control effectiveness: strong encryption + MFA). - Option B: 40% reduction from coarse controls + detection improvements.- Time-to-detection / containment - A: detection latency 24–48 hrs (limited telemetry), MTTD = 36 hrs. - B: MTTD = 6 hrs with extensive logging/UEBA.- User productivity (KPIs) - Average file access latency: A = +300 ms; B = +30 ms. - Collaboration turnaround (time-to-share, approvals): A increases by 25% (slower workflows); B neutral. - Helpdesk tickets/week: A +40%; B +5%.- Operational cost (annualized) - A: higher development/PKI/MFA ops = +$350k/yr. - B: logging/analytics/storage = +$200k/yr, plus alert triage = +$150k/yr.- Expected annualized loss (from threat-model, approximated) - Without controls baseline loss = $2.5M. - With A: residual loss = $0.75M (70% reduction). - With B: residual loss = $1.5M (40% reduction).

**Decision framework (weighted score)**1. Define weights by stakeholder impact (example): Confidentiality 40%, Availability/Productivity 30%, Detection/Response 20%, Cost 10%.2. Score each option 0–10 per criterion using quantified metrics above.3. Compute weighted score = sum(weight * score).4. Set threshold: choose option if score delta > 1.0; otherwise consider hybrid.

Example outcome with weights above likely favors B when business values productivity and detection (B higher score), favors A when data sensitivity/legal/regulatory weight increases confidentiality weight >60%.

**Operational recommendation**- If high-regulated data (PHI/PCI): prefer A or hybrid (A for high-sensitivity buckets, B for low-sensitivity teams).- Otherwise: choose B + compensating controls — limit privileged access, enforce encryption-at-rest, and invest saved budget into SOC automation to reduce MTTD further.- Implement measurable guardrails: monthly KPI review (MTTD, helpdesk tickets, access latency, residual risk estimates) and a 6-month reassessment with simulated adversary tests.

This framework maps threat-model outputs to business KPIs and supports a defensible, data-driven choice or a practical hybrid.

HardTechnical

72 practiced

Design an approach to automatically generate and score attack trees for common web application goals such as data exfiltration, using static architecture metadata, vulnerability feeds, and threat intelligence. Describe the graph model, algorithms for path enumeration and shortest/cheapest-path identification, scoring heuristics for nodes and edges (ease, likelihood, impact), data storage model, and how results should be presented to engineers for mitigation prioritization.

Sample Answer

**Overview (approach)** I would build an automated pipeline that ingests static architecture metadata (components, trust boundaries, flows), vulnerability feeds (CVEs, exploitability), and threat intelligence (TTPs, actor likelihood) to synthesize weighted attack trees and rank remediation priorities.

**Graph model** - Directed multi-graph: nodes = assets/processes/apis/credentials/primitives; edges = interactions, privilege gains, or capability transitions. - Node attributes: type, sensitivity, exposure, CVSS, compensating controls. - Edge attributes: exploitability, required preconditions, cost, detection probability, TTP match score.

**Path enumeration & shortest/cheapest-path** - Use constrained DFS/BFS to enumerate attack paths up to depth D with pruning by precondition failure. - Compute cheapest path via Dijkstra (edge cost = effort / likelihood) or A* with heuristic combining remaining privilege distance and exposure delta. - Parallelize per goal (data exfiltration) and cache subpaths.

**Scoring heuristics** - Node score = sensitivity * asset_value * (1 - control_effectiveness) * vulnerability_factor. - Edge score = ease (1..10 from exploitability + TTP match), likelihood = edge ease * attacker_capability, impact propagated from node scores. - Path score = product of likelihoods * sum of impacts / total_cost; normalize to 0–100.

**Data storage model** - Graph DB (Neo4j) for fast traversal; time-series store (Elasticsearch) for scores/history; relational for canonical metadata. Keep provenance for each score.

**Presentation to engineers** - Dashboard showing top attack trees per goal, drillable path view (node/edge rationale, evidence links, exploitability CVE links), prioritized remediation actions with expected risk reduction and estimated effort. Provide API for CI/CD to fail builds when risk delta exceeds threshold.

**Trade-offs & safeguards** - Tune depth and scoring weights; surface uncertainty bands; allow human overrides and feedback loop to retrain heuristics from incidents.

HardTechnical

74 practiced

For a security organization adopting PASTA across many applications, define a maturity model and KPIs to measure process adoption and effectiveness. For each PASTA stage suggest measurable indicators, how to collect the data, and how to link observed maturity improvements to reduced incident rates or other risk metrics.

Sample Answer

**Overview — Maturity levels (0–4)**- 0: Absent — no PASTA activities- 1: Initial — ad‑hoc threat modeling per app- 2: Repeatable — template-driven, some automation- 3: Defined — organization-wide process, training, toolchain integration- 4: Optimized — continuous improvement, metrics-driven, feedback into SDLC

**Per-PASTA stage indicators, collection, linkage**

1) Preparation- Indicators: % apps with threat-modeling kickoff within sprint 0; time-to-first-model- Collection: CI/CD ticket tags, project metadata- Link: Faster prep → fewer late-design vulnerabilities; correlate to reduced design-stage findings in SAST/IAST.

2) Definition of objectives- Indicators: % apps with mapped business assets & security objectives- Collection: Threat model artifacts, asset registry sync- Link: Clear objectives → targeted controls; measure reduction in high-risk control gaps from risk registers.

3) Attack surface enumeration- Indicators: # exposed endpoints per app, % assets scanned weekly- Collection: Automated discovery tools, API gateway logs- Link: Surface shrinkage correlates with fewer external exploit incidents (external-facing CVEs exploited).

4) Threat analysis- Indicators: # threats enumerated per app, % mapped to attacker profiles- Collection: Threat catalog, CTI ingestion logs- Link: More complete catalogs → increase preventative controls; compare pre/post trends in successful phishing/supply-chain events.

5) Vulnerability & weakness analysis- Indicators: % threats with mapped vulnerabilities, mean time to remediate (MTTR)- Collection: Vulnerability management system, ticketing- Link: Lower MTTR → fewer exploited vulnerabilities; track exploited-vuln incidents vs MTTR.

6) Attack modeling & simulation- Indicators: # automated attack paths simulated; % critical paths mitigated- Collection: Red/blue exercise reports, automated adversary emulation logs- Link: Simulation coverage reduction in mean-time-to-detect (MTTD) and incident severity.

7) Risk & remediation management- Indicators: % of risk treatment plans executed, residual risk scores over time- Collection: Risk register, GRC dashboards- Link: Falling residual risk scores → measurable drop in incident rate and expected annual loss (EAL).

**Cross-cutting KPIs**- Adoption rate = % apps with PASTA artifacts- Process lead time = avg days from finding → remediation- Coverage = % codebase / infra under regular PASTA review- Outcome KPI = incidents per 1,000 app-days, mean time to contain (MTTC), EAL

**How to measure impact**- Use before/after cohorts (apps onboarding PASTA vs controls)- Run regression controlling for app size, threat exposure to attribute incident reduction to maturity score changes- Convert reduced incident frequency + severity into financial risk reduction (EAL) for executive reporting

**Practical tips**- Automate collection via CI/CD, ticketing, vuln scanners, CTI feeds- Start with lightweight dashboards (per-app maturity score) and map to incident telemetry quarterly- Use targets (e.g., move 60% apps to level 3 in 12 months) and tie to SLOs for remediation and detection

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.