Defining Mitigations

Identifying threats is only half the job. For each threat you identify, you need to decide what to do about it. Mitigations are the security controls that reduce or eliminate the risk posed by a threat.

Types of Mitigations

Security controls fall into four categories:

A good security posture uses controls from all four categories. Preventive controls reduce the probability of exploitation; detective controls reduce time-to-discovery; corrective controls reduce impact.

Writing Good Mitigations

A mitigation description should be specific enough for an engineer to implement. Avoid vague statements like “improve security” or “use best practices.”

Poor mitigation:

“Secure the API.”

Better mitigation:

“Enforce JWT token expiry of 15 minutes and validate the aud claim on every authenticated endpoint. Rotate signing keys monthly.”

Each mitigation should answer:

• What specific control will be implemented?
• Where in the system will it be applied?
• Who is responsible for implementing it?
• When will it be done (status)?

Mitigation Status

Track whether each mitigation has been implemented. This turns the threat model into a living document you can use to track security debt.

The Defence-in-Depth Principle

No single control is infallible. Defence in depth means layering multiple independent controls so that if one fails, others still protect the system.

For a threat like “Attacker steals session tokens to hijack user accounts”:

• Preventive: Short-lived tokens with secure, HttpOnly, SameSite=Strict cookies
• Preventive: Bind session to IP or device fingerprint
• Detective: Alert on logins from new geographies or unusual user agents
• Corrective: Allow users to invalidate all sessions; force re-authentication for sensitive actions

Residual Risk

After applying mitigations, some risk always remains. This is residual risk — the risk that remains after controls are in place.

A threat with a raw risk score of 20 (Critical) might become Medium after mitigations reduce both likelihood and impact. The mitigated risk score is what you track over time.

When residual risk is acceptable, the threat status becomes Mitigated. When residual risk is too high but no further mitigations are practical, it becomes Accepted — a documented, conscious decision by a responsible person.

Common Security Controls by STRIDE Category

Spoofing

• Multi-factor authentication
• Short-lived, signed tokens (JWTs, OAuth)
• Certificate-based mutual authentication between services

Tampering

• Parameterised database queries
• Digital signatures and hash verification
• Transport layer security (TLS 1.2+)

Repudiation

• Immutable, centralised audit logging
• Log integrity protection (append-only, off-system storage)
• Digital signatures on transactions

Information Disclosure

• Encryption at rest and in transit
• Response field filtering / data minimisation
• Secret management systems (not environment variables or source control)

Denial of Service

• Rate limiting and throttling
• Resource quotas and timeouts
• Auto-scaling and circuit breakers

Elevation of Privilege

• Server-side authorisation on every request (not just UI gating)
• Principle of least privilege
• Role-based access control (RBAC)
• Regular access reviews

Tracking Mitigations Over Time

Your threat model should be revisited when:

• A new feature changes the attack surface
• An incident reveals a gap in the existing model
• A security assessment uncovers new threats
• Mitigations that were planned are now implemented

Update threat statuses and mitigation statuses as work progresses. A threat model that is kept up to date is a powerful security artefact; one that is never revisited is just a snapshot in time.