Gartner Blog Network

The D in EDR

by Augusto Barros  |  February 9, 2016  |  5 Comments

The research on EDR tools and practices renders some very interesting discussions on tools capabilities. While many EDR vendors will focus on their fast searching and automated IOC checking capabilities, the “Detection” piece is always a fun piece to talk about. Especially when you discard the basic “blacklist” approach which, by the way, may not be as simple as we think (malware polymorphism makes it far more challenging than most people think it is).

What would you expect from an EDR tool regarding “Detection”, considering we are not including there the basic IOC matching? Write down you answer, then look at it. Isn’t that something you would expect, for example, from your antivirus (or “Endpoint Protection Platform”, the grown-up name)? What kind of detection capabilities should we expect from an EDR tool but not from an EPP?

Most EDR tools trying to do something beyond EPP are taking a “behavior” based approach. Identifying exactly what the vendors refer to as “behavior based detection” is another interesting challenge. If you hard code on your tool something considered a malicious behavior (something like “disabling AV”, “setting up hidden persistence”, “establishing contact with C&C server” or “search for data files or memory pages containing credit card numbers”), is it “behavior based” detection or just a fancy signature (or “rule”)?

There are no strong definitions and descriptions for capabilities such as “behavior based detection”, “anomaly detection” (isn’t it funny that some tools doing that define what an “anomaly” is just like a…signature?), etc. Add to it the claims about Machine Learning, AI, etc, and we have the perfect storm of inflated claims and, unfortunately, expectations.  It also makes the lives of those comparing solutions a big nightmare.

To be fair with all those tools, identifying malicious activity, or just malware (malware as the main vehicle for malicious activity is so big now that we often forget that it is not a requirement), is very hard. Computers can do anything and it’s hard to understand when some instructions are part of malicious activities and when they are not. Some powershell use, for example, would be expected from system administrators and power users, but is often a good indication of malicious activity when done by a “regular” user. Only the context (that sometimes is only different from a human point of view) will tell if it’s good or bad. A malware dropper behaves almost exactly like an installer or auto-update component of regular software.

Removing the inflated claims, the existing capabilities for detection are not that bad. If it’s so hard to identify what is malicious and what is not, we may need to keep explaining that to the tools. The real risk of not meeting expectations is in believing that the tool doesn’t need to learn, or when you don’t fully understand who has the role of teacher. It might be primarily the vendor, but you still need to be able to assess if they are doing that appropriately.

What does that mean? It means tools need to be tested before buying and constantly after implemented too. Understanding how the existing and emerging threats behave and how the tools would react to them is crucial to ensure they will keep detecting bad stuff. If you have resources that can obtain that information (here’s where that “other” Threat Intelligence comes into play) and translate it into the right questions (or test scenarios) to the vendors, you’ll be able stay aware of your tools capabilities and limitations. And of course, identify the snake oil when you see it in that booth at RSA 😉

Category: insights-and-philosophical  threat-detection  

Tags: edr  

Augusto Barros
Research VP
3 years at Gartner
21 years IT Industry

Augusto Barros is Research VP in the Gartner for Technical Professionals (GTP) Security and Risk Management group. Read Full Bio

Thoughts on The D in EDR

  1. >What would you expect from an EDR tool regarding “Detection”, considering we are not including there the basic IOC matching?

    Well, we ARE including it, but we just assume that it is tablestakes…

  2. Andre Gironda says:

    Detectors come in all shapes and sizes, but if we are talking about modern Cyber Defense and fully-integrated operations thereof, we should consider that EPP, NF, and EDR are not where detection begins or ends.

    UEBA, especially network visualizers such as Vectra Networks, Darktrace, LightCyber, Bay Dynamics, Exabeam, SpectorSoft, and a few others are a great place to start up your detectors. The next stage would be with sandbox-exploding technology, such as FireEye NX/EX/etc, Cyphort, JoeSandBox Ultimate, or Cuckoo Sandbox. EDR is the third-stage toolchain, where app whitelisting or blacklisting can be actioned. EDR prepares the artifacts for notification, recovery, and other response options including data forensics as well as hunting. Hunting is the final say for all detectors — it is the moment in the cycle where new courses of action can be developed.

    In my version of detectors, IDS/IPS, NF, and EPP are a sideshow to the real event for exactly the reasons that you mention, i.e., polymorphism, or self-modifying and self-checking code. Additionally, as security products, the three categories of classic detectors become legacy when you consider how easy it is to utilize a one-packet kill or one-memory-block kill in order to shut them down. They’re as fragile or more-so than the services and apps that they supposedly set out to protect. Windows 10 Device Guard is the exception to this rule — it’s an EPP of sorts that is integrated more cleanly and doesn’t suffer from the one-packet/block kill issues.

    I think network-only based UEBA, IDS/IPS, and NF technology can be made more resilient against one-packet kill attacks, but this is an exercise in appsec maturity that has not yet been proven in the Gartner-approved process.

    • Jian Zhen says:

      Andre, interesting points. I completely agree with you that security is a multi-stage/phase process. However, putting EDR as third-stage is probably outdated due to how previous EDR products work (as you said, app whitelisting or blacklisting).

      To truly combat the latest threats, EDR solutions must be able to look across different phases of the breach including pre-breach, active breach and post-breach. The solutions need to deter threats at the earliest possible point that the threat touches the endpoint, detect and disrupt these threats at any point of the pre, active and post-breach phases, and do that with a non-signature/rule approach.

      This is to say, the EDR solutions must be the first stage defense for endpoints, not third. Because in the cloud, you won’t be able to use many of the network technologies. And waiting for events to happen on the endpoints so some tools can detect the anomaly is already too late.

      For example, if there’s an active exploit against an endpoint, can the EDR solution detect/prevent the threat before the exploit succeeds? If the exploit somehow succeeds, can the EDR solution detect/prevent the threat trying to gain persistence or lateral move using process injection and privilege escalation? If somehow persistence is obtained, can the EDR solution detect the persistence or determine if the any files left behind are malicious? Finally, can the EDR solution help you automate the detection and investigation and not require operators to manually hunt for threats?

      Just some thoughts…

      p.s. Full disclosure, I work for Endgame. Automate the Hunt.

    • Augusto Barros says:


      you are more than right when you say that EDR is not where detection begins or ends. It is one more component of a detection ecosystem. As much as we want to apply behavior analytics on the network and on an event/log level, some activities can only be detected on the endpoint. The investigation workstream also requires additional instrumentation for visibility, being another strong motivator for EDR.

      But EDR, as any software, has also the potential to be vulnerable, as you said. Any security tool added to the environment also contributes to increase the attack surface. I bet many of these EDR tools are vulnerable to some silly attacks too. Jeremiah Grossman repeatedly reminds us of that. Appsec maturity should be a decisive factor for selecting security tools. Unfortunately we don’t see many bug finders pointing their guns to them; maybe it’s not as cool (or profitable) as owning the last iPhone?

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.