Building out your detection engineering portfolio is something that will greatly expand the capabilities of your Security Operations Center (SOC). That valuable time spent building however needs to be on the right areas, and you must ensure your precious time away from the alert dashboard isn't squandered by building things that have no net benefit to your security program.
Categorizing Your Detection Types
Before we can know about the location of potential redundancies, we should look at the basic detection category types:
- Host Based - These are detections on physical machines or VDIs
- Identity Based - These are detections from things Okta, Entra, etc.
- Network Based - These are detections on your physical network, such as east-west traffic
- Cloud Based - These are detections in AWS, Azure, GCP, etc.
- Email Based - These are detections from Exchange or your email security gateway
- SaaS Based - These are detections stemming specifically from SaaS applications such as Salesforce, Hubspot, etc.
If I forgot one or two, feel free to let me know - but this should cover nearly every single possibility for a detection. A detection can fall into more than one type, but an action or specific log itself should be isolated to a singular type. Think of how a login event to a SaaS might trigger an individual alert to that platform, but also may call some integration which will trigger an event on your Identity based detections.
Where You Might Be Doubling Up
Before even looking at your custom detections themselves, and if you already have some alerts being triaged in your environment, ask yourself the following questions:
- Am I getting alerts, usually after another alert, that state the same information?
- Am I leaving alerts unclosed in one console just to actually work on them in another?
The most common culprit for these are endpoint detections. Let's say you have a low-hanging-fruit type of detection where your EDR detects a common Red Team tool like PowerView running user enumeration on the domain. This might trigger a massive combination of alerts, such as the actual malicious script itself, the identity alerts for recon activity if it was ran, and other network activity for such actions. While it's great to detect on something like PowerView, you need to ask yourself: "Do I really need to write a custom detection for this tool if my EDR is covering it?". More than just PowerSploit tooling, a critical offender of this are Living Off The Land Binaries (LOLBINs) as defined in something like the LOLBAS project.
How To Cover Your Bases Efficiently
Now that we know how doubling-up looks, we can look at conceptual practices to avoid it.
With most detection engineering, it's key to have your processes defined in a matter that is similar to something like the software development lifecycle. A systemic process will allow us to eliminate most overlaps. First you must ask yourself, what am I actually trying to see? In the above example, you may say "I'm trying to detect PowerView!", but in reality, you are trying to detect malicious PowerShell usage. Most EDRs, for this example, come with an implementation of their own Anti-Malware Scanning Interface (AMSI) DLL, so you need to take that into account. So to build a detection, you need to specifically craft a detection that is catered towards detecting potentially malicious PowerShell your EDR will likely not see via its AMSI DLL-based detections.
Identifying this gap can be done in one of the most effective methods (that we will make a different blog on!) known to detection engineering: Purple Teaming! Whether it's with your Red Team, some consultants, or even a Defender wanting to get their hands dirty with offensive work, you need to actually test tooling and such that deals with this gap you are looking to identify. What commandlets are consistent with malware tooling in PowerShell that might not be exclusive to PowerView? Does the EDR trigger on these alone (probably not)? Do these commands run much at all in my environment? All questions to answer as you look to do some testing.
Future Work
As you try and think of detection engineering a bit more strategically and try to reduce alert fatigue, be sure to check back on our blog frequently :) Thank you so much for reading!
