Endpoint detection and response (EDR) is a protection approach that monitors endpoint devices across a network and blocking threats as these are identified. Like any other cybersecurity products, it can only protect a network if set up appropriately and tested. Based on my decade’s experience as a security and red team consultant, here are five things CISOs should know about EDR platforms.
1. EDR can be evaded
The first, and arguably the most important, thing to understand about EDR is that it isn’t a drop-in solution that will solve all your endpoint security problems. Despite what the marketing departments and the various market research firms would have you believe, EDR can be defeated, and rather trivially at times. There are countless diverse ways in which an EDR can be evaded, whether it be from an interruption of the sensors, an implementation of a technique that subverts the detection logic of the EDR, blending in with normal system behavior, or breaking the communication chain between the endpoint and the central collection server.
EDR has a difficult job. We expect it be able to detect every tool that an adversary can use against our endpoints, both known and unknown, all while being perfectly correct as to not introduce too many false positives, leading to alert fatigue in the security operations center (SOC). Mind you, they need to balance all of that on top of being easy to use and deploy, performant, secure, and competitively priced so that the vendor can sell their product. If we simply temper our expectations of EDR and understand that, while it is the best tool for monitoring endpoint activity now, it can’t catch everything out of the box, we can begin improving our usage of it and extract more value.
2. EDR is not antivirus
The endpoint protection market and how products are named can be confusing. Despite the ever-growing list of names and acronyms, there are really only two families of detection products: antivirus and EDR. Antivirus is generally focused on catching artifacts (usually file-based malware). EDR, on the other hand, focuses on detecting behaviors. While most EDR solutions today implement some form of antivirus, they’re primarily concerned with catching the things that happen after malware is detonated – such as post-exploitation activity.
EDR’s focus on behavior is what makes it so powerful. Many modern threats have evolved to not require introducing artifacts to the system which would be detected by antivirus — such as fileless malware. In these situations, we need to be able to investigate behaviors on the system for patterns indicative of a malicious actor’s presence. This is the true value of EDR: being able to query and correlate behaviors across systems, whether it be to hunt active compromises or build proactive detections. Treating our EDR solely as a tool for catching malware dropped to disk prevents us from extracting much of its value.
3. Fleet coverage matters
I can’t begin to tell you how many times, in my time as a red team operator, I compromised a workstation and immediately jumped to a server solely because EDR was not deployed there. In discussing the issue of limited fleet coverage with those customers, I’ve found no shortage of reasons as to why it is the case. Regardless of those reasons, however, the recommendation is the same: You need as full coverage as you can possibly get when it comes to your EDR deployment. There will certainly be exceptions, such as unsupported operating systems, constrained system resources, critical business function, but the default should be to install the EDR agent and exceptions should be made on a system-by-system basis.
The reasoning behind this makes sense if we again consider what is EDR’s purpose, that is collecting and reporting events that occur on an endpoint. Imagine that you have three systems: workstation, server, and a database holding your organizations’ “crown jewels.” You’ve deployed EDR on the workstation because that system will almost certainly be subject to attempts at initial access. You’ve also deployed EDR on the database because it is the most important system in your entire environment. Meanwhile, EDR was not deployed on the server for one reason or another.
During a breach, the adversary compromises a workstation and operates below the detection threshold of the EDR. They find that they have sufficient privileges to migrate to the server range and they jump to system the server. On the server they’re effectively free to do whatever they want from a detection perspective, so this becomes their new beachhead. Through reconnaissance, they find that they can connect to the database to extract high-value information and exfiltrate it. Incident response (IR) kicks off and they very clearly see the initial access, post-exploitation actions, and even the jump from the workstation to the server, but then they find out that there is no data for the server because there was no EDR installed, and the trail runs dry.
Now the process of determining the scope and impact of a breach, as well as eradicating resident actors, becomes substantially more difficult. If EDR was installed on the server, the internal security team could have proactively responded to reduce impact and/or IR could have pieced together the adversary’s attack chain more quickly and accurately to improve the efficacy of remediation.
4. You must add to your EDR
Every EDR comes with some detection logic built in. Some vendors even go as far as to have baselining period where the EDR normalizes for your environment (e.g., a process accessing LSASS may be normal in your environment while never happening at another company). While this is a great starting point, we can do more. The detection logic included by the vendor should only be seen as a starting point. It doesn’t understand the intricacies of your environment, the sensitivity of certain hosts or system groups, the strategically important pieces of your network, or specific concerns you may have. For that, we need to turn to detection engineering.
Historically, detection rules have been a game of whack-a-mole due to their precise nature. For example, a detection for Mimikatz, a tool used for extracting credentials from Windows systems, would consist of simply searching for processes called “mimikatz.exe.” This logic is trivial to bypass, if an attacker renames “mimikatz.exe” to “mimidogz.exe” for example and needed to be complimented with something more robust. Because EDR has such deep hooks into the operating system through its myriad sensors, we have all the data to find Mimikatz-esque behavior without needing to look for Mimikatz specifically.
If our detection logic looks for the core functionality of a given technique – such as opening a sufficiently privileged handle to lsass.exe and reading its memory — we can capture more than one variation of its implementation. This means that a single detection rule can supply coverage at the procedural level for Mimikatz and similar tools including SafetyKatz or Invoke-Mimikatz. This extensibility is a core functionality of every EDR worth buying today.
5. Test your EDR
How do you know that your EDR can detect the things that it says it does? How do you know that that holds true across all versions of the operating system, EDR agent, and policy configuration? Does it hold true across every host in your environment? Will that hold true next week and the week after? We must test our assumptions about our EDR so that we have full situational awareness and make meaningful approvements.
There are many ways to test detections with some being more specific than others. The first one that may come to mind is Red Teaming, which is a service designed to test your detections and exercise your incident response procedures. While this is a completely valid way to test your defenses, it doesn’t supply test coverage for all your detections and is only a point-in-time assessment.
Another style is “atomic” testing. This involves using tests specifically crafted to emulate some behavior (most commonly mapped to MITRE ATT&CK) to stimulate defenses in a calculated way so that the EDR can be evaluated more directly. The downside of this approach is that the quality of the test corpus is difficult to gauge, and most solutions aren’t designed continuously or at scale. These testing approaches both supply immense value to your security program by testing assumptions and exercising defenses. Regardless of which approach you prioritize, the most important piece is assessing the efficacy and robustness of your detections and improving any deficiencies found using the rich dataset provided by your EDR.