Threat Modeling and Attack Surface Analysis Questions

Direct answer

Threat modeling and enterprise risk assessment outputs map onto audit evidence for System and Organization Controls 2 (SOC 2) Type II and ISO/IEC 27001 (an international information security management standard) in two distinct ways: they demonstrate that risk identification is systematic rather than ad hoc, which both frameworks require as a foundation, and they generate the specific documents, metrics, and control evidence an auditor actually checks. SOC 2 Type II additionally requires evidence that controls operated effectively over a sustained observation period, typically six to twelve months, not just that they exist on the day of the audit, so the threat-modeling program's own operating history, models created and reviewed on schedule, findings tracked to closure, becomes part of the evidence itself.

Structured elaboration

Specific documents to present

• The threat model artifacts themselves (data-flow diagrams, the applied methodology's output, typically STRIDE, an acronym for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) for the in-scope systems, dated and versioned, showing the model existed before the period under review, not produced retroactively for the audit.
• A risk register or findings log, showing every identified threat, its assigned risk rating, its disposition (mitigated, scheduled, or formally accepted), and, critically for SOC 2 Type II, the dates showing when each disposition was reached, since the operating-effectiveness requirement is about the process functioning across the review period, not a single snapshot.
• A risk-acceptance record for any finding whose disposition is formal acceptance, showing who approved it and under what compensating controls, which auditors specifically look for as evidence that acceptance was a deliberate, authorized decision rather than an unaddressed gap.
• The program's own policy or standard document, describing when threat modeling is performed, by whom, and against what methodology, since both frameworks want to see a defined, repeatable process, not evidence that security work happens but without a documented basis for why or how.
• For ISO 27001 specifically, the Statement of Applicability, a required document listing which Annex A controls apply to the organization's scope and why, or why a control is excluded; the threat model's own identified risks are a primary input justifying which controls are in scope, since a control excluded with no threat-model-grounded justification is a common audit finding.

Metrics to present

• Coverage: the percentage of in-scope systems with a current threat model, since both frameworks care whether risk identification is comprehensive across the audited scope, not selectively applied.
• Time-to-remediate: the time from a finding being logged to closure or acceptance, since this metric is direct evidence of the process actually functioning over the review period rather than findings accumulating unaddressed, which is exactly what a Type II review is testing for.
• Model currency: the age distribution of active models against the program's own stated maximum-age policy, since a documented policy with models exceeding its own stated age is a more damaging finding than having no stated policy at all.
• Recurrence: whether previously mitigated findings reappear in later models on the same system, since recurrence is a signal to an auditor that a fix was not actually durable, which speaks to control effectiveness beyond a single point-in-time check.

Implemented controls to present

• Access controls on the threat-model artifacts and findings tracker themselves, since both frameworks care about the integrity of the audit evidence itself, not just the underlying systems the evidence describes.
• The specific technical and procedural controls the threat model's findings led to being implemented (for example, an access-control change, a network segmentation change, an authentication hardening measure), each traceable back to the finding that drove it, which is the concrete link between "we identified this risk" and "we did something about it" that an auditor is verifying end to end.
• The governance controls around the program itself: who approves the methodology, who signs off on high-severity findings, and how often the program's own effectiveness is reviewed, since both frameworks assess whether security decisions have defined ownership, not only whether the decisions themselves were reasonable.

Demonstrating continuous monitoring

SOC 2 Type II's defining feature versus a Type I report is that it tests operating effectiveness across the review period, so continuous monitoring evidence has to show activity distributed across that whole window, not concentrated near the audit date: dated tickets in the findings tracker showing steady remediation activity throughout the period, model-review dates spread across the calendar consistent with the program's stated cadence, and monitoring or alerting logs (from the automated staleness or material-change detection a mature program runs) showing the detection mechanism itself was live and firing throughout, not merely configured. ISO 27001 similarly expects evidence of an operating management system, typically demonstrated through management review meeting records, internal audit records, and the risk register's own revision history showing it is a living document under active management rather than a document produced once for certification and left static afterward.

Worked example

An auditor reviewing a SOC 2 Type II report for the six-month period ending in a given quarter would expect to see, concretely: a risk register showing findings logged throughout the period, not clustered in the final month before the audit; time-to-remediate figures with dates that check out against the tickets referenced (an auditor will sample individual tickets and verify the dates in the metric against the underlying evidence, so the metric and the source data have to agree); at least one instance of a risk-acceptance record with a named approver and a stated compensating control, since a program with zero acceptances across six months of real findings looks more like incomplete evidence than a genuinely risk-free environment; and for ISO 27001, a Statement of Applicability where each excluded Annex A control has a stated justification traceable to the risk assessment, since an excluded control with no justification is one of the most commonly cited nonconformities in ISO 27001 audits.

Trade-offs and pitfalls

• The most common wrong turn is producing threat-model artifacts specifically for the audit, dated near the review period's end, which fails the Type II operating-effectiveness test outright, since the entire point of Type II is evidence spread across the observation window, not a point-in-time snapshot dressed up as ongoing practice.
• Presenting metrics without the underlying evidence an auditor can sample against invites exactly the kind of discrepancy that turns a routine review into a finding; a time-to-remediate figure has to be reproducible from the actual tickets it summarizes, not asserted on its own.
• Excluding Annex A controls in the Statement of Applicability without grounding the exclusion in the risk assessment is a frequent, avoidable audit finding under ISO 27001; the threat model's own output is precisely the evidence that should justify each inclusion or exclusion, and skipping that linkage treats the two processes as unrelated when they should be the same underlying risk analysis serving two purposes.
• Treating the two frameworks as requiring entirely separate evidence packages wastes the overlap between them; both fundamentally want proof that risk is identified systematically and addressed traceably, and a well-run threat-modeling program's own artifacts, if kept dated, versioned, and linked to disposition, largely satisfy both with the same underlying records.

Direct answer

A probabilistic model that estimates 30-day exploitation likelihood from indicator-of-compromise (IOC) counts, actor tactics-techniques-and-procedures (TTP) fidelity, exploit availability, and patch presence should start from feature selection grounded in what actually correlates with near-term exploitation, then choose between two genuinely different modeling approaches: Bayesian updating, which starts from an explicit prior and revises it multiplicatively as each signal arrives, well suited to sparse data and fully interpretable per-signal contributions, or logistic regression, which learns the weight of each feature from a large labeled historical dataset, better suited once enough exploited-versus-not-exploited history exists to train on. This mirrors, in spirit, how the Exploit Prediction Scoring System (EPSS), published by the Forum of Incident Response and Security Teams (FIRST), already operationalizes exactly this kind of estimate at industry scale using a machine-learned model over a large feature set, though most organizations start smaller and simpler than that.

Structured elaboration

Feature selection for the four named signals. Each signal earns its place because it measures a different, largely independent dimension of exploitation risk, which matters for combining them without double-counting the same evidence:

• IOC counts: how much observed indicator activity (scanning traffic, malware samples, command-and-control infrastructure) is associated with this vulnerability, sourced from threat-intelligence feeds and, ideally, corroborated against your own telemetry rather than external reporting alone.
• Actor TTP fidelity: how closely a known, active threat actor's documented techniques (commonly mapped against the MITRE ATT&CK framework) match the exploitation path this vulnerability would require, since a vulnerability matching a currently active campaign's known playbook is meaningfully more likely to be targeted than one that would require a threat actor to develop new tradecraft.
• Exploit availability: whether working exploit code exists publicly (an exploit database, a module in a common exploitation framework, a public proof-of-concept repository), since this collapses the skill barrier to exploitation from specialist to opportunistic.
• Patch presence: whether a patch exists and, critically, whether it has actually been deployed on the specific affected asset, since an available-but-undeployed patch means the vulnerability remains fully exploitable on that asset regardless of what the vendor has published.

Weighting strategies. Two approaches to setting how much each signal moves the final estimate:

• Hand-specified weights or likelihood ratios, chosen from domain judgment and refined by review, are workable with limited historical data and keep the reasoning fully auditable, but carry the risk of being wrong in ways that are not obvious until enough outcomes accumulate to check them against.
• Learned weights, fit from historical labeled data (vulnerabilities with a known exploited-or-not outcome), remove the guesswork but require enough historical examples, and enough diversity across those examples, to fit reliably; a small internal dataset risks overfitting to whatever happened to be exploited in the past rather than learning a generalizable pattern.

Candidate modeling approaches, contrasted directly:

• Bayesian updating treats the four signals as evidence that revises a starting probability, using each signal's likelihood ratio (how much more likely the evidence is under "will be exploited" versus "will not be exploited") multiplied into the prior odds. It requires no historical training set at all, only calibrated likelihood ratios, and every step of the calculation is inspectable, which matters when someone needs to understand why a specific score came out the way it did. Its weakness is the independence assumption baked into simple multiplicative combination: if two signals are actually correlated (a vulnerability with public exploit code is also more likely to attract rising IOC activity, not for independent reasons but because both stem from the same underlying "this is a popular target now" cause), naively multiplying their likelihood ratios together overstates the combined evidence.
• Logistic regression learns a weight for each feature directly from labeled historical outcomes, which naturally absorbs some correlation between features into the fitted coefficients rather than assuming independence, and produces a well-calibrated probability once trained on enough data. Its weakness is exactly that data requirement: it needs a reasonably large, representative set of past vulnerabilities with known exploited-or-not labels to train on, which a smaller organization, or a novel signal with no track record yet, may not have.

Data sources, one per named signal: IOC counts from commercial or open threat-intelligence feeds and platforms (for example a Malware Information Sharing Platform, MISP, instance), cross-referenced against internal telemetry; actor TTP fidelity from cyber-threat-intelligence vendor reporting and ATT&CK-mapped campaign profiles; exploit availability from public exploit repositories and common exploitation-framework module listings; patch presence from the organization's own vulnerability- and patch-management system, which is internal ground truth rather than an external feed.

Validation and backtesting. Hold out a time window of historical vulnerabilities (train on older data, test on a later period, never randomly shuffled, since randomly mixing past and future data leaks information a model would not have had at prediction time) and score the model's predicted probabilities against what actually happened. Compare against a naive baseline, such as always predicting the historical base rate or using Common Vulnerability Scoring System (CVSS) severity alone, since a probabilistic model earns its added complexity only if it measurably outperforms the simpler baseline it replaces.

Worked example

A concrete Bayesian update for one vulnerability. Start from an illustrative prior, chosen for this exercise rather than measured from real historical data: 5% of newly disclosed vulnerabilities are exploited within 30 days absent any other information, giving prior odds $\frac{0.05}{0.95} = 0.05263$ (kept to 5 significant figures here specifically so the multiplication below reproduces its stated result exactly, rather than compounding rounding error). Four signals arrive: public exploit code is confirmed available (illustrative likelihood ratio $LR_1 = 8$, since exploit code sharply raises the odds of exploitation), IOC counts targeting this specific vulnerability are rising in threat-intelligence feeds (illustrative $LR_2 = 4$), the exploitation path shows high-fidelity overlap with a currently active threat actor's documented TTPs (illustrative $LR_3 = 3$), and the affected asset has not yet received the available patch (illustrative $LR_4 = 2$). Multiplying the likelihood ratios and updating the prior odds:

$\text{posterior odds} = 0.05263 \times 8 \times 4 \times 3 \times 2 = 0.05263 \times 192 = 10.105$
$P(\text{exploited within 30 days}) = \frac{10.105}{1+10.105} = 0.910 \;\; (91.0\%)$

The same computation in log-odds form, which is the additive version of the identical update and confirms the result: $\text{logit}(0.05) = -2.944$, plus $\ln(8)+\ln(4)+\ln(3)+\ln(2) = 2.079+1.386+1.099+0.693 = 5.257$, giving a posterior log-odds of $-2.944+5.257 = 2.313$, which converts back to $P = \frac{1}{1+e^{-2.313}} = 0.910$, matching exactly. This large a swing, from a 5% base rate to a 91% posterior, is a direct consequence of four moderately strong signals compounding multiplicatively, which is both the mechanism's strength (it lets several individually inconclusive signals add up to real confidence) and, per the pitfall below, its main risk when the signals are not actually independent of each other.

Trade-offs and pitfalls

The central pitfall, visible directly in the worked example, is that naive Bayesian updating assumes the four signals are conditionally independent given the outcome, when in practice exploit availability and rising IOC counts often share a common underlying cause (a vulnerability becoming popular with attackers drives both), so multiplying their likelihood ratios together can double-count the same underlying evidence and inflate the posterior beyond what the true, correlated evidence actually supports; logistic regression handles this more gracefully because a model trained on real co-occurrence patterns absorbs correlation into the fitted coefficients rather than assuming it away. A second pitfall is training or validating on randomly shuffled historical data instead of a strict time-based split, which silently leaks future information (a vulnerability's eventual fame or infamy) into what should be an earlier-stage prediction, producing backtest results that look far better than the model will actually perform going forward. A third is treating hand-specified likelihood ratios as settled once chosen; they are judgment calls dressed up as numbers, and the validation step exists specifically to check whether those numbers are actually earning their keep against real outcomes, not to be run once and forgotten.

Direct answer

A risk register entry needs to do two things at once: record enough context to reconstruct why a rating was given, and produce a comparable score so the entry can be ranked against every other entry in the register. Below is a filled entry for a web-facing customer-database breach, built on a simple 1-to-5 likelihood-times-impact matrix with a documented remediation-window policy tied to the resulting score band, so every value has a stated reason rather than being picked by feel.

Structured elaboration

The scoring convention this entry follows. Likelihood and impact are each rated 1 to 5, multiplied to produce a risk score from 1 to 25, and banded into a remediation-window policy:

What each field captures and why it matters. Risk-id gives traceability across systems (tickets, audits, reports) referencing the same finding. Description creates a shared understanding independent of whoever wrote the entry. Affected asset(s) scopes the actual blast radius. Likelihood, impact, and the resulting risk-score are the prioritization signal. Existing-controls prevents double-counting protection that is already in place, rating the residual exposure, not a hypothetical undefended baseline. Proposed-mitigations is the action. Residual-risk shows the register's job is not done at "we have a mitigation" but at "how much risk remains after it actually lands." Owner is accountability. Target-mitigation-date is tied to the score band above so it is enforceable rather than arbitrary.

Worked example

Rationale behind the values. Likelihood is rated 4, not 5, because the web application is internet-facing with a history of lower-severity injection findings in code review, indicating a nonzero baseline exploitation probability and a well-understood, commonly targeted entry vector, but 5 is reserved for confirmed active targeting or observed exploitation, neither of which applies here yet. Impact is rated 5, the top of the scale, because the overly permissive service account means a successful compromise exposes the entire customer database, not a subset, maximizing blast radius; a full-PII breach at this scale also triggers regulatory notification obligations and direct customer harm.

$$\text{Risk score} = \text{Likelihood} \times \text{Impact} = 4 \times 5 = 20$$

A score of 20 falls in the critical band, driving the 2-week target-mitigation-date directly from the stated policy rather than an arbitrary deadline.

Residual risk after mitigation. Likelihood drops to 3: the web-application compromise path itself is not eliminated, application-layer vulnerabilities remain a background risk, but a successful compromise no longer automatically grants full-database access, reducing the probability of this specific full-breach outcome given a web-app compromise. Impact drops to 3: a compromised least-privilege service account limits exposure to the specific subset of data the application actually needs, rather than the entire schema, materially shrinking blast radius even if the underlying application vulnerability is eventually found and used.

$$\text{Residual risk score} = \text{Likelihood} \times \text{Impact} = 3 \times 3 = 9$$

A residual score of 9 falls in the medium band, a defensible, documented improvement from the original critical rating, not simply asserted.

Trade-offs and pitfalls

A likelihood-times-impact matrix is simple but coarse: two entries can both score 20, one as 4 times 5, one as 5 times 4, and represent very different risk profiles, frequent-but-survivable versus rare-but-catastrophic. For high-stakes prioritization across a large volume of findings, a richer weighted model that separately accounts for exploit evidence and business impact resolves ties this simple matrix cannot. Skipping the existing-controls field and rating likelihood or impact as if no protection exists overstates risk and burns credibility with stakeholders who know a firewall is already in place; always rate the residual exposure given current controls, not a hypothetical undefended baseline. Residual-risk is the field most often left blank or copy-pasted from the pre-mitigation rating; that defeats its purpose, if a mitigation does not measurably change the likelihood or impact rating with a stated reason, question whether it is actually the right mitigation. A single, unaccountable owner field, "the security team" as a group rather than a named role, is a common register weakness; entries without individual accountability are the ones that miss their target-mitigation-date.

Direct answer
PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, risk-centric methodology that starts from business objectives and works down to concrete attack simulation, in contrast to STRIDE's more mechanical per-component category sweep. PASTA is the better choice when the audience and stakes require an explicit business-risk narrative (funding decisions, compliance justification, executive buy-in), not just a technical threat list.

Structured elaboration
The seven stages, each with its objective:

1. Define Objectives - capture business objectives and compliance requirements so later technical findings can be traced back to business impact.
2. Define Technical Scope - enumerate the architecture, technologies, and dependencies in scope (the technical surface the rest of the process operates on).
3. Application Decomposition - build the DFD-style model of components, data flows, and trust boundaries (this is where PASTA and STRIDE's inputs overlap).
4. Threat Analysis - gather threat intelligence relevant to the decomposed architecture (industry-specific threat actors, known campaign patterns).
5. Vulnerability and Weakness Analysis - map identified threats to actual vulnerabilities and weaknesses in the decomposed architecture (correlate stage 4 against stage 3).
6. Attack Modeling - simulate plausible attack scenarios (attack trees or kill chains) that would exploit the identified vulnerabilities.
7. Risk and Impact Analysis - quantify business impact and residual risk for each simulated attack, and prioritize remediation by business-risk-adjusted severity, not just technical severity.

When PASTA beats STRIDE: STRIDE is fast, mechanical, and per-component; it is the right tool when a team needs to sweep a specific system quickly and technical stakeholders will consume the output directly. PASTA is heavier (typically multi-day for a real system, requiring cross-functional participation from stage 1) but earns that cost when the audience includes non-technical business stakeholders who need to see risk in impact terms rather than category names, when the system is genuinely business-critical and regulatory-scrutinized (payments, healthcare, financial services) where a compliance-ready risk narrative is itself a deliverable, or when the goal is prioritizing a remediation budget across many findings, which requires the business-impact quantification PASTA builds in from stage 1.

Worked example
Consider threat-modeling a new payments API. A STRIDE pass on the API's DFD produces a solid technical finding quickly: the token-refresh endpoint is vulnerable to Spoofing via a predictable refresh token. A PASTA pass on the same system, run because leadership needs to decide whether to delay launch, produces a fuller chain: objectives (PCI DSS scope, Q3 launch date), technical scope (the API plus its 3 upstream dependencies), decomposition (the same DFD), threat analysis (payments APIs are a known target for credential-stuffing campaigns per current threat intel), vulnerability analysis (the predictable refresh token maps directly to that threat), attack modeling (a simulated credential-stuffing-to-refresh-token-prediction chain), and risk analysis (estimated fraud exposure if exploited, weighed against a 2-week launch delay to fix it). Same underlying technical finding, but PASTA's extra stages produce the artifact leadership can actually act on.

Trade-offs and pitfalls
PASTA's depth is also its cost: running full PASTA on every minor feature change is not sustainable, and teams that try tend to abandon it after one exhausting cycle. A defensible pattern is STRIDE for routine per-feature reviews and PASTA reserved for new business-critical systems, major re-architectures, or when a compliance or executive audience genuinely needs the business-risk narrative. Stopping at stage 3 (decomposition) and calling it PASTA produces a STRIDE-shaped DFD with none of PASTA's actual differentiator, for twice the process overhead.

Direct answer

Quantitative scoring (a numeric scale like the Common Vulnerability Scoring System, CVSS) and qualitative scoring (a simple High/Medium/Low rating) both try to answer "what do we fix first," but they trade precision for speed in opposite directions: CVSS gives a standardized, fine-grained, externally comparable number at the cost of requiring real expertise and time to score correctly, while a qualitative rating is fast and immediately understood by anyone, technical or not, at the cost of clustering many genuinely different findings into the same coarse bucket. For a small startup with limited security resources, the practical answer is usually qualitative for day-to-day prioritization, with CVSS reserved for the specific moments (a customer security questionnaire, a public disclosure, an auditor) where the standardized number is actually required.

Structured elaboration

The quantitative approach: CVSS or a simplified numeric scale. CVSS produces a base score from 0.0 to 10.0, computed from a defined set of technical metrics (attack vector, attack complexity, privileges required, user interaction, and the confidentiality, integrity, and availability impact of the vulnerability), and that score maps to published qualitative severity bands: None (0.0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), Critical (9.0-10.0). Because it is built from explicit metrics rather than a single subjective judgment, two different analysts scoring the same well-described vulnerability should converge on the same or a very close number, which is what makes it useful as a shared external language.

The qualitative approach: a simple rating scale. Instead of computing a metric-based score, a reviewer assigns a rating directly, typically by combining a quick likelihood judgment and a quick impact judgment through a small lookup table rather than a formula:

This requires no specialized scoring training and takes seconds per finding, which matters when the person doing the triage is often an engineer wearing a security hat part-time rather than a dedicated analyst.

Advantages and disadvantages of each:

Worked example

Apply both approaches to the same finding at a small startup: an internal admin panel is discovered exposed directly to the internet with no authentication required at all. Under the qualitative approach, likelihood is rated High (internet-reachable, no authentication barrier, trivially discoverable by automated scanning) and impact is rated High (an admin panel typically grants full application control), which the lookup table above maps straight to High, a triage decision made in seconds with no calculation required. Under the quantitative approach, the relevant CVSS metrics for this same finding would all sit at their most severe values, network-reachable attack vector, low attack complexity, no privileges required, no user interaction needed, and high impact to confidentiality and integrity at minimum, which by CVSS's design places a finding with that metric profile at the top of the scale, within the published Critical band (9.0-10.0), without needing to assert a specific decimal value the underlying calculator would produce. Both approaches agree this finding is top priority, which is the expected and reassuring outcome for an unambiguous case; the two approaches earn their keep on the harder, more ambiguous findings where a quick qualitative call and a metric-by-metric CVSS walk can genuinely diverge, and CVSS's explicit metric breakdown is what surfaces the disagreement instead of hiding it inside one reviewer's gut call.

Trade-offs and pitfalls

The most common mistake for a small, resource-constrained team is adopting full CVSS scoring for every finding because it is "the correct way," and then either scoring it inconsistently under time pressure (defeating the whole point of a standardized metric) or spending disproportionate analyst time on precise scoring for findings where a qualitative High/Medium/Low would have driven the exact same remediation decision. A second pitfall, in the opposite direction, is staying purely qualitative even when an external party specifically asks for a CVSS number (a customer security questionnaire, a coordinated vulnerability disclosure process, a compliance audit), since a qualitative rating alone does not satisfy that requirement and the team then has to retroactively derive a number under deadline pressure anyway. The practical resolution for a small startup is not choosing one approach exclusively, but using qualitative triage as the default working rhythm and computing an actual CVSS score only for the specific findings where an external audience genuinely requires it, which captures most of the qualitative approach's speed advantage while keeping the quantitative option available when it is actually load-bearing rather than symbolic.