Writing detections when stuck with EDR
Making the leap to purchasing and maintaining an EDR solution can be huge for organisations so huge in fact that they never really progress from there when it comes to visibility on assets. This is an important consideration because organisations should aim to achieve some level of detection engineering but will likely never get to explore the associated complexities. So how can organisations effectively and easily write detections that actually help to protect them when they are only able to leverage an EDR tool.
Understanding your tools limitations
To most people EDR tools are incredibly verbose in the telemetry they capture from any given asset but unfortunately relative to overall telemetry available they actually only capture what the vendors think is the most pertinent. This is for obvious reasons because ingesting telemetry at the scale vendors do comes at a significant cost so they implement "cost-saving measures" like limiting the amount of any one given telemetry source can send in a given time period or just outright ignoring some sources. These global limits need to be explored so that when you begin writing detections you have a strong understanding of what your EDR can and can't see.
This continues to the extent that at large your only ever going to see your tools interpretation of activity occurring on an asset which can vary wildly between tools and of course importantly everything you see has already happened so understanding time constraints is important too. With this in mind your likely going to be limited to building detections for atomic behaviours or procedures and not the actual code running on your systems unlike if you had the capability to deploy Yara rulesets.
These are not absolute statements and different EDR tools can and do capture some incredibly verbose sources and provide incredible context to what is actually happening like for example what permissions are assigned to a file when its executed or even raw events from etw providers (thank you MDE team) So it is incredibly important to find these features by diving into your telemetry and exploring as they are rarely documented (if you haven't already you will be pleasantly surprised by what your EDR tool can actually do). Examples below:
Carbon Black - Process Metadata
Crowdstrike - Telemetry sources
Source: Olaf Hartong
Understanding your limitations
More than likely if you work in a security team you are swamped with work and as always you should be focusing on achieving brilliance in the basics first not the detection engineering outlined in this post. With that said if you're ready to take the plunge into just getting something started you need to take into consideration your own personal expertise and how its going to impact the shape of your detection engineering program.
If you do not feel equipped to reverse engineer payloads, perform dynamic analysis and ultimately have a strong foundational understanding of how your operating systems work then that's ok! In the immediate term it's perfectly viable to focus on using other people's work so long as you expend effort identifying the overall quality of the detection and ensuring that quality is kept when translating it to your tools and environment.
A big part of detection engineering is the thinking that goes into the creation of detections beyond the technical work. Some key topics you will want to explore are as followed:
- Do you have the appropriate telemetry for the detection?
- Do you have even better telemetry than the detection intends to use?
- Once built how is the detection meant to be responded to?
- Does the detection need to be put in front of a human or can it be automated?
- How are you going to test and validate that the detection is working?
- If something changes how do you monitor how it impacts your detections fidelity?
Luckily there are lots of fantastic resources that answer these questions so do your research using resources the community has already made.
While you are going to be restricted by your limitations it's still worthwhile figuring out what you can't detect because by documenting what the detection is, why you can't detect it and what the return on investment would be you can establish a trend that will highlight key areas in your security monitoring program and posture that you can push for new additions for and at the very least it's an excellent learning exercise to explore how your systems work and what's available to you.
Designing your program
Building a program for your detections helps ensure consistency and quality. I've captured below what yours will likely look like if you are stuck with EDR and do not have a lot of time:
This component is the why and when to you perform some detection engineering. It could be just when you find something of relevance in the news, as a result of posture and asset assessments or even your own ingenuity. At this step, its important to decide how much time and effort your going to commit to the rest of the lifecycle.
Once your trigger has activated and you have gathered a detection 'idea' its a good idea to keep it in a repository, particularly because oftentimes you might not have time to complete the entire lifecycle right there and then. This repository will need to capture a few points around the idea such as the below:
- Research Sources
- Relevant Technologies
- Detection idea
Don't be afraid to let your repository build up with lots of ideas so long as you provide the appropriate metadata so the ones you really need to establish get done when you have time. If you want to look into more mature models for repositories check Florian Roth's post here Capturing Detection Ideas to Improve Their Impact | by Florian Roth | Medium
Now that you have a detection idea you want to begin the necessary work to build the detection. Use the content already detailed at the top of this post to guide you on this. In particular focus on the quality of the detection, you are making.
Testing and Validation
Almost finished! with the detection, you have built make ensure you spend time and effort testing the logic your applying works with actual data in production and measuring whether when the detection raises an alert is it as expected. This can include the below items:
- Does your detection contain actionable information?
- Is your detection being routed via the appropriate workflow ie enrichment?
- Is the detection as precise as you intended it to be?
- Are you missing actual malicious activity?
- Are the volume of alerts so great it degrades the value of the detection?
Finally, you need to devise a method to deploy your detections. If you have only a few tools or instances to deploy to then manual efforts are worthwhile alternatively if you have a lot of places the detection needs deploying to consider automating via the APIs available in all major EDR tools. Regardless of the method make sure that when you deploy the rule you note a period of time to monitor it for immediate and obvious issues.
Next, I will be covering extending your EDRs capability using third-party productions in particular THOR scanner and KAPE/.