STRIDE and TARA: From Threat Discovery to Risk Prioritization

Security is easier to plan when teams ask two questions early: What could go wrong? and which risks should we address first? Threat modeling and risk assessment help turn those questions into a practical, repeatable process.

Two useful approaches are STRIDE, which helps identify and classify threats, and TARA (Threat Analysis and Risk Assessment), which helps assess and prioritize risks. They address different parts of the same problem and can be used together.

STRIDE: a structured way to find threats

STRIDE is a threat-modeling framework originally developed at Microsoft. It provides six categories to help teams consider how a system, its data, or its users could be attacked:

Category	Security concern	Example question
Spoofing	Someone impersonates a user or component	Could an attacker use another person’s identity?
Tampering	Data or configuration is changed without permission	Could a request or stored record be altered?
Repudiation	An action cannot be reliably attributed	Would there be enough evidence to determine who performed a sensitive action?
Information Disclosure	Information is exposed to an unauthorized party	Could private data be accessed or revealed?
Denial of Service	A system or service becomes unavailable	Could a resource be exhausted or disrupted?
Elevation of Privilege	A user gains more authority than intended	Could a lower-privileged account perform an administrative action?

STRIDE is most useful when teams understand the system they are assessing. A simple diagram of components, data flows, and trust boundaries gives the team a concrete place to apply each category. For each component or flow, ask which threats could apply, then record the assumptions and potential mitigations.

This makes threat discovery more systematic than brainstorming alone. STRIDE is a guide for asking questions, not a guarantee that every possible threat has been found.

TARA: understand and prioritize risk

TARA stands for Threat Analysis and Risk Assessment. While STRIDE helps generate and classify potential threats, TARA focuses on understanding their risk and deciding what deserves attention.

A practical assessment generally involves:

1. Define the system and its assets. Identify what needs protection, how the system is structured, where information moves, and which boundaries matter.
2. Identify threats and weaknesses. Consider possible attackers or failure conditions, the assets they may affect, and weaknesses that could be involved.
3. Assess risk. Estimate factors such as likelihood, impact, exploitability, and scope. Use a consistent method that fits the organization rather than treating a score as absolute certainty.
4. Prioritize and respond. Decide which risks to mitigate first, which require monitoring, and which may be accepted with clear ownership.

Risk assessment supports decisions; it does not remove uncertainty. Teams should document assumptions and revisit them when the system, its environment, or the threat landscape changes.

How STRIDE and TARA work together

The difference is straightforward:

• STRIDE asks: What kinds of threats could affect this system?
• TARA asks: How significant are those risks, and what should we do about them?

For example, a team reviewing an account-management service could use STRIDE to consider impersonation, unauthorized changes, disclosure of account data, or privilege escalation. TARA can then help assess the likelihood and impact of those scenarios, compare them consistently, and decide which controls or follow-up actions should come first.

Used together, the frameworks help connect system design to practical security decisions. STRIDE broadens the team’s view of what could go wrong; TARA helps focus limited time and resources on the risks that matter most.

A useful security habit

These methods are valuable beyond any single framework: they encourage teams to question assumptions before a system is deployed. Instead of asking only whether a design appears secure, ask what an attacker might try, what could be affected, and what evidence would help detect or investigate an incident.

Threat modeling cannot replace secure implementation, testing, or monitoring. It gives those activities a clearer starting point and helps make security a considered part of design rather than a last-minute checklist.

This article is adapted from my original Medium article on STRIDE and TARA.