By Published on

When we can apply controls directly against threats

We know that the standard way is to assign controls directly to vulnerabilities not directly to threats. Still, there are situations where we can apply controls directly to threats, ignoring vulnerabilites.

The controls → vulnerabilities relationship

The often-quoted infosec model for risk assessment:

risk = threat × vulnerability × impact

is really just a refinement of the classic:

risk = probability x impact formula.

Only that now:

  • threat = how likely an adversary or hazard is to act,
  • vulnerability = how likely that action succeeds given it occurs,
  • impact = damage if it succeeds.

We implement controls to reduce probability and impact of a negative event in places where we are able to act, that is - on vulnerabilities.

But sometimes we apply controls to threats directly

  1. threat deterrence (changing attacker's behavior)

controls don’t affect the vulnerability, but discourage the threat actor:

  • legal warnings / banners (“unauthorized access prohibited”),
  • law enforcement cooperation announcements,
  • honeypots / honeytokens,
  • public bug bounty programs.
  1. avoiding the threat

controls stop the threat before it reaches the vulnerable asset:

  • anti DDoS solutions,
  • WAF,
  • EDR blocking known malware families.
  1. threat displacement (actor redirection)

controls that make you a low profile target:

  • moving high-value assets or admin interfaces behind stricter network boundaries,
  • obfuscating service exposure (e.g., private APIs, non-public endpoints),
  • rate-limiting and throttling.

If attackers can't find obvious points to attack they will move on to try someone else.

  1. monitoring and detection

controls aimed at detecting the threat itself, not the weakness itself:

  • SOC monitoring, SIEMs,
  • threat intelligence alerts,
  • behavioral analytics (UEBA).
  1. when vulnerabilities are unfixable (or not yours)

controls that cannot work against:

  • unsupported, unpatchable legacy systems,
  • zero-day vulnerabilities,
  • third-party cloud platforms.

In these cases, you must act on the threat instead, so we implement controls like:

  • network isolation,
  • strict whitelisting,
  • limited permissions.

Remember: in all cases above - vulnerabilities might (and will) still exist, but the the negative event, the threat is less likely to happen because of these "indirect" controls.