Mitigate the Threats

Learning Objectives

After completing this unit, you’ll be able to:

Identify mitigations to address threats.
Explain how to develop mitigation strategies.
Make informed decisions on how to proceed with residual risk.

Identifying Mitigations

Once you’ve defined your security objectives, your system’s architecture, and your threats, the next step is deciding what changes to make to your system. This is where your team works together to close gaps and reduce risk.

Some changes remove a risky condition entirely, while others mitigate it by reducing its likelihood or impact. As you evaluate mitigations, consider how effective they are at changing the system so it is harder to exploit or less harmful if it is. Attackers tend to exploit the easiest path, so even small weaknesses can become entry points if they are left unaddressed. Fixing one issue can also reduce risk across multiple parts of the system, especially when it addresses a shared assumption or weak boundary.

Now let’s return to the simple blogging system and look at how mitigations apply to the data flows in the diagram. The goal isn’t to eliminate every risk, but to understand which changes make the biggest difference.

Many of these mitigations align with guidance from resources such as the OWASP Application Security Verification Standard (ASVS) and OWASP Cheat Sheets, which provide practical guidance developers can use when building secure systems.

Numbered Point	Action	Class(es)	Threat	Mitigations
1	An authenticated site administrator enters an email address to assign a role.	Tampering, Elevation of Privilege	An attacker modifies the role assignment request so a new account is granted administrator-level access.	Validate role assignments on the server side. Do not trust client-provided role data. Enforce strict authorization checks for role changes.
2	The system sends the blog author a reset token.	Spoofing, Information Disclosure	An attacker intercepts or guesses the reset token and uses it to set a passphrase and take over the account.	Only send tokens over HTTPS. Generate secure random tokens and quickly expire them. Avoid exposing tokens in logs or URLs when possible.
3	Blog author uses the reset token to set an initial passphrase.	Spoofing, Elevation of Privilege	An attacker uses an old or leaked reset token to reset the author’s passphrase without authorization.	Make reset tokens one-time use. Invalidate them after use. Limit how long they remain valid.
4	Authenticated blog author submits a blog post.	Tampering, Repudiation	An attacker alters request parameters so the post appears to come from another author or bypasses authorization checks.	Derive identity from the authenticated session, not request parameters. Enforce authorization checks on every request. Log important actions for accountability.
4, 5	Submitted blog content is stored and later rendered as HTML for readers.	Tampering, Information Disclosure	A malicious author injects JavaScript into a blog post, which is later rendered to readers and could lead to Cross-Site Scripting (XSS).	Sanitize or restrict user-submitted content. Avoid rendering unsafe HTML. Use safe output encoding when rendering content.
5	The system renders the blog post as HTML for readers.	Denial of Service	An attacker floods the blog server with requests for rendered posts, exhausting resources and slowing the site for legitimate users.	Add rate limiting or throttling. Apply resource limits. Monitor traffic and scale or cache where appropriate.
5	The system renders the blog post as HTML for readers.	Information Disclosure, Tampering	Without HTTPS, an attacker can modify blog content in transit, inject malicious JavaScript, or redirect readers to a malicious site.	Enforce HTTPS for all client-server communication. Redirect insecure requests to HTTPS. Use secure transport settings consistently across the application.

Some mitigations remove a risky interaction entirely, while others reduce how likely or harmful a threat is. For example, enforcing HTTPS or deriving identity from the authenticated session removes risky behavior directly, while expiring reset tokens quickly or adding rate limiting reduces exposure without removing the threat completely.

Each mitigation should change how the system behaves at a specific interaction point. For example, making reset tokens one-time use changes how the system handles account setup, while input sanitization changes how submitted content is stored and rendered. Some changes can be made right away, while others require deeper updates over time.

If a mitigation requires more research or design decisions, note it for further investigation.

In fast-moving environments, you’re often expected to ship quickly, and security work can feel like something that slows you down. At the same time, the system may still be used in ways you did not intend.

That’s why prioritization matters. When there’s pressure to go live, you might only have time to do one or two things, so the question becomes which changes will reduce the most risk first.

The Decision Model for Prioritization

Once you’ve identified threats and possible mitigations, the real work begins: deciding what to fix and when. Security is not just about finding problems, it's about deciding what to act on.

When prioritizing, consider:

Impact and urgency: How serious is the risk, and how quickly does it need attention?
Root cause versus symptom: Does this fix address a deeper weakness in the system?
Effort versus value: Is this a quick improvement, or a larger change that strengthens a critical part of the system?
Constraints and feasibility: Can this realistically be fixed given time, cost, or system limitations (such as legacy or end-of-life systems)?
Regulatory or contractual requirements: Are there external requirements that dictate how this risk must be handled?

Not all decisions are made at the development level. Developers help identify and explain risks, but prioritization often involves product, architecture, or leadership decisions. In some cases, especially with legacy or critical systems, the most practical decision may be to accept the risk and manage it over time.

Residual Risk and Risk Acceptance

Not every risk can be fully removed. Some risk may remain after you apply mitigations. This is called residual risk. For example, you might shorten the lifetime of a reset token and make it one-time use, but there is still a small chance it could be intercepted and used before it expires. That remaining exposure is residual risk.

Risk acceptance is the decision to move forward with known risk, whether that risk is still inherent in the design or remains after mitigation. This can happen because the issue cannot be fully addressed, because the system is constrained, or because the cost or impact of fixing it outweighs the benefit.

For each issue, decide:

Fix now–implement a mitigation immediately.
Monitor or investigate–gather more information or watch for impact.
Accept–document the risk and move forward.

If you accept a risk, define when you will revisit it and what would change your decision.

From Decision to Implementation

Once you’ve decided what to fix, monitor, or accept, the next step is to implement and track the work. Each identified threat should be accounted for before release, whether through a mitigation, a monitoring approach, or a documented decision. Translate mitigations into concrete work, such as code changes, configuration updates, or design adjustments, and track that work in your team’s normal workflow so nothing is missed.

A mitigation is not complete until it has been tested in a real environment, such as staging, to confirm that it works as intended. This means verifying not only that the feature works, but that the risk has actually been reduced. For example, that invalid input is rejected, permissions are enforced, or tokens can no longer be reused.

Even after applying mitigations, gaps may remain. At this point, you move forward based on the decisions you’ve already made. If the remaining risk is too high, the system needs to be redesigned. This can involve changing how components interact, simplifying features, or removing functionality that introduces unnecessary risk.

If the remaining risk is acceptable, the system can move forward with that understanding. That decision should be documented and revisited as the system evolves.

The goal of the decision model is to choose what to fix now, what to monitor, and what to accept based on how your system actually behaves under real conditions.

Sum It Up

You’ve now learned how to use threat modeling to understand your system, identify where it may behave in unintended ways, and decide how to address those risks. These skills help you reduce surprises and make more informed decisions about how your system behaves in real-world conditions.

To keep building your understanding of secure systems, check out the Cybersecurity Career Path on Trailhead.

Time Estimate

Topics

Looking for Help?