Methodologies Beyond STRIDE

A security model protects the system from unauthorised parties. A privacy model protects the person the data describes, including from the operator's own authorised staff and vendors. So the fix is collecting and keeping less, not stronger access control.

Fix the scope to the change itself, sketch its flows and trust boundaries, walk one fixed question set over every boundary crossing, and leave with ranked threats that each have an owner. You buy the obvious high-impact threats and spend completeness.

Fit decides it, not fashion: team maturity, the system's type and risk profile, any regulatory or contractual driver, the time budget per model, and who consumes the output. A lighter method run every release beats a heavier one nobody finishes.

Points arbitrage is a chain of legitimate operations permitted by that system's own rules, and no catalog holds rules it never saw. A library sets a floor of known patterns; novel abuse comes from an asset-driven pass.

A checklist encodes threats already found on other systems, so it catches known misses cheaply and uniformly. It cannot see what is specific to your design: your business logic, your boundaries, your attacker. Put it beneath a model, not in place of one.

CAPEC is a public catalog of attack patterns, and each pattern links to the CWE weaknesses that make it possible. In a design review you pull the patterns matching your entry points, then design against the linked weaknesses.

The information asset is the data itself; its containers are the technical, physical and people places where that data is stored, transported or processed. OCTAVE Allegro profiles the asset once, then inherits risk from every container, including containers another organization operates.

PASTA runs: define business objectives, define technical scope, decompose the application, threat analysis, weakness and vulnerability analysis, attack modeling, then risk and impact analysis. Each stage feeds the next, ending in business-priced risks plus countermeasures.

Trike grids every actor against every asset, marking each create, read, update and delete cell allowed, disallowed, or conditional. Threats are the complement: an actor performing a disallowed action, or being denied an allowed one.

VAST builds two model types. An application threat model uses a process-flow diagram that follows features and the calls between components the way a delivery team designs them. An operational threat model uses a data-flow diagram of the deployed shared infrastructure those applications run on.

Non-repudiation destroys plausible deniability. Where a person must be able to deny acting, such as a whistleblower filing a report, evidence that irrefutably binds them to the act is itself the harm, so LINDDUN treats it as a threat.

Linkability on the tap ledger dominates, escalating to identifiability. A per-element pass applies six LINDDUN types to the flow, store and analytics process, but only linkability, identifiability and unawareness to the rider, whose card number is a pseudonym, not anonymity.

Starting from business objectives gives PASTA a yardstick: the final stage rates each attack path by the damage it does to a stated objective. It also surfaces abuse of legitimate features, which a design-first pass misses because nothing is technically broken.

Let PASTA's stages own scope and impact and let STRIDE own elicitation: the category walk populates the threat-analysis stage, and its output feeds attack modeling as input, not as a second list. One register, one granularity, one de-duplication pass.

Anything the requirements never named: actors nobody wrote down, assets outside the grid such as tokens, logs and backups, and threats that are not one actor acting on a business asset. A stated rule that is itself over-broad also passes silently.

What scales is production: a process-flow application model is drawn by the product team from how they already describe their features, so 700 models are made in parallel instead of queued behind a handful of facilitators. What is lost is per-model depth and attacker-motivation reasoning.

Design-level modeling analyses one system you drew; OCTAVE Allegro follows an information asset across every container that holds it, including paper, people and other organizations. It answers which assets deserve attention and judges impact against business-ranked criteria, so the two run at different cadences.

Treat it as a purpose-limitation threat, not an access request: nothing is breached, yet data a customer gave to be priced is used against them in a claim. Test compatibility, seek a less invasive form, enforce it technically.

An area of concern is a stakeholder's plain-language worry about an asset in one of its containers. OCTAVE Allegro expands each one into a threat scenario by filling in actor, means, motive, outcome and the violated security requirement, then sweeps threat trees for scenarios nobody voiced.

Stripping names and loyalty IDs gives pseudonymised data, not anonymised. Purchase histories are sparse and near-unique, so rare item combinations act as identifiers and a partner can re-link shoppers to other data. Aggregate, generalise, or release answers instead of rows.

Security Cards is organised around human impact, adversary motivations, adversary resources and adversary methods, so it forces a team to name who would attack and why. Control-oriented lists never prompt that, and miss attackers whose goal is not money.

Mandate the outcome, not the traversal. A curated, architecture-specific library is a good floor for new teams, but percent-of-catalog coverage is theatre: require threats that came from the design too.

LINDDUN GO is the lightweight card-based form: a deck of prompting cards worked against a rough system sketch with non-specialists. It trades the full method's exhaustive per-element coverage and its defensible record for speed and reach.

Run all seven stages where loss is large, trust is contested and the design is long-lived — the case that justifies weeks of cross-functional input. Elsewhere keep stage one and stage seven, reuse decomposition, and compress the middle into one evidence-informed pass.

Neither extreme. Set a house default matched to the median system, publish the selection criteria and two or three alternatives, and require a written rationale to deviate. Uniformity buys comparability; forced uniformity buys ritual compliance where it does not fit.

Usually yes, but narrowly. The cost is not the analysis; it is authoring the authorization rules the organisation never wrote — and that written rule set, not the threat list, is the main payoff. Scope it to the authorization-dense core.

Say plainly that a model per system proves production capacity, not security. Stop trying to review every model, sample by exposure and asset value, review recurring threat classes rather than documents, and be explicit with the mandate owner about what modelled does and does not mean.