Common mistakes when using endpoint detection and response products (EDR)
We have seen many instances where endpoint detection and response (EDR) products do not provide the protection a client was expecting from them. There were varying reasons why this was the case, but most cases have something in common: the client was not using the product properly. As it is always helpful to learn from mistakes of others, this blogpost will detail common mistakes we have seen.
Not enabling features and rulesets
EDR products come with a host of features and rulesets that may not be enabled within your organization. One reason for this could be that the features in question are disabled by default and have never been enabled. Another reason could be that these features generated a lot of false positives and were disabled on purpose. In any case, not using the features and rulesets of your EDR product will result in lower detection and prevention rates. How you should handle false positives will be discussed further down. However, the starting point of a configuration journey should be: taking your time to understand the features of your product, whether they are enabled and whether they should be.
Running entire rulesets in detection mode
A second solution to the false positive problem we have encountered is to run entire rulesets in so-called detection mode. In this mode, processes are not terminated for triggering detection rules. Instead, alerts are generated for human analysts to look at and take action on. Although detection mode is a useful feature, as we will see later, it should not be the go-to solution for the false positive problem. Analysts will get flooded with alerts and they won’t have time to properly analyze them. As new alerts keep coming in at the same pace, they will be closed with little inspection.
Not using fine grained exceptions
In a large environment, EDR products will generate false positives. This may have been a reason for consciously disabling features and rulesets within your organization, or to run rulesets in detection mode. While this ensures your users can perform their tasks, it also decreases the effectiveness of your EDR product. What you want to do is to implement fine grained exceptions to individual rules that cause false positives. Investigate the false positives and attempt to uncover a pattern in them that is:
A. Unique to the false positives
B. Unlikely to be copied by an attacker
Detections that do not adhere to the pattern should result in termination of the process. Making exceptions that minimize false positives while also preventing false negatives requires expertise in threat hunting and/or attack simulation.
Making exceptions that minimize false positives while also preventing false negatives, is outside of the scope of this blogpost. However, it is imported to remember that attackers will attempt to make their actions look as legitimate as possible. At the most basic level, they run their malicious code in the context of legitimate processes, it is not sufficient to simply whitelist behavior from known processes. Whenever the case is too complex to automatically perform classification, detection mode can be used to prevent users from being unable to do their work.
Not testing the solution
In many cases there exists a discrepancy between what organizations think their solution will do and what it actually does. While false positives result in complaints from users, false negatives go unnoticed in daily use. Testing your EDR product and its configuration is essential to have an understanding of its effectiveness, be aware of any gaps and make informed decisions on additionally required security measures. Test against a large set of offensive tools, as well as individual techniques aimed at bypassing EDR solutions. Furthermore, tests should be performed periodically with an updated set of tools and techniques, to determine the extent to which the solution is keeping up with the rapid developments from the offensive side.
Conclusion
When you properly tailor an EDR solution to your environment, you will be able to make use of many more of its features without limiting the experience of end users. This ensures a broader coverage of possible attacks you will be able to detect. Furthermore, you prevent your SOC-analysts from being flooded with false positives, leaving them more time to investigate more complex detection events. Regardless of the configuration you end up using, test the solution with real-world scenarios so you know what it is capable of and, more importantly, what not.
