With any type of threat or vulnerability, there is risk. That risk usually comes down to a question asked by your stakeholders: 'Is it as low as it can get?'. This type of logic comes for all variety of findings, but isn't normally as applied as heavy during detection engineering, so let's chat about it!
Defining Detecting and Preventing
Before we can figure out what we need to do, we need to understand the actual meaning behind the terminology.
Prevention is defined as the act of blocking or removing the functionality for a capability to be able to be leveraged, invoked, or acted upon by a threat actor. An example would be disabling POWERSHELL.exe for certain users.
Detection is defined as the act of alerting upon for case of future triage for analysts a set of actions occurring in a particular sequence or order. If an attacker performs numerous password attempts to many accounts, then uses RDP with one of those accounts, this may invoke a 'Password Spray' alert for your analysts to triage and respond to.
When Should We Prevent?
Preventing should be your preferred step when it comes to tackling a Tactic, Technique, or Procedure from an attacker. It's important to remember that when we talk about detecting, that the addition of detections all run a risk of adding to alert fatigue if there is ever a miss-step in quality or fidelity, so preventing should always be what you look to do first.
Let's take the above example with an attacker running PowerShell. It can be disabled by a GPO pushed to certain users or certain machines and servers, but you need to take some caution. Narrowing down the specific machines, users, and groups is necessary before you do something that impedes critical business functionality. Think blocking PowerShell on all finance employee computers might be obvious? Well, perhaps there is a service of some application on the host that runs PowerShell regularly.
Good candidates for prevention follow the below schema:
- The prevented action/capability has not directly occurred from an employee in the last 90 days.
- The prevented action/capability is not functionally important for any services or applications within the enterprise.
- The prevented action/capability has no business logic criticality impact.
All of these are pretty vague, but they're intended to be. An easy block in one enterprise is not in another!
When Should We Detect?
Detection is the step that should occur when prevention is either not possible or practical in your enterprise. Sequences of actions can only be detected upon with sufficient fidelity when there is logging that supports it. You can only detect what you can see, so the first step should be a question to yourself: Do we ingest the right logs to detect this sequence of actions? Perhaps you want to detect malicious PowerShell functions from something like PowerSploit, but you aren't ingesting Event ID 4104 (PowerShell Script Block Logging). In this case, you'd either need to coordinate to get this Event ID onboarded, or rethink the strategy. The more log sources you have access to, the higher fidelity your detection will be. Higher fidelity in a detection will lower the alert fatigue your Security Operations Center has.
When making any sort of detection, there are a lot of questions you should ask, but here are a quick three to just get you started on the right path:
- Are we ingesting the right logs to detect this sequence of actions?
- Is this sequence of actions common in the environment? Or is a variation of this sequence common?
- How far 'left' in the kill chain are we detecting?
On the last point, we want to detect attackers as soon as possible in the environment to minimize the impact.
The Balancing Act
Security is always a balance between protection and usability. When we prevent actions, we reduce risk but potentially limit functionality. When we detect instead, we maintain functionality but accept some level of risk with the promise that we'll catch malicious activity quickly. This is why a mature security program needs both approaches, strategically applied.
Consider the principle of defense in depth - multiple layers of security controls. The outer layers might prevent common attacks entirely, while deeper layers detect more sophisticated threats that made it past the preventative controls. Neither approach alone is sufficient for a robust security posture.
Detection without prevention can lead to alert fatigue and resource drain, while prevention without detection leaves you blind to the threats that inevitably bypass your preventative controls. The most effective security programs understand this balance and implement both strategies where appropriate.
Practical Implementation
Start by mapping your critical assets and processes. For each one, evaluate whether prevention or detection makes more sense based on business impact, technical feasibility, and security value. Don't forget to consider the user experience - security that's too restrictive often leads to workarounds that create even bigger vulnerabilities.
Remember that your security controls should evolve as threats and your organization change. What might start as a detection control could eventually become a prevention control once you've established that it doesn't impact legitimate business operations.
If you want to learn more about detection engineering, go ahead and make a free account here on EpicDetect and get rolling without needing to setup your own homelab!
