MDR Series Part 2: Why Endpoint Detection and Response (EDR) isn't enough

What's Missing From Your Managed Detection and Response (MDR) Solution?

07 March 2023

By John Hollner

Why Endpoint Detection and Response (EDR) isn't enough

Endpoint Detection and Response (EDR) solutions are powerful tools for network defenders, but they also have their limitations and challenges. Many companies that purchase these tools struggle to maximize their effectiveness. This paper will help clarify EDR product marketing, provide context on strengths and weaknesses, and describe how to get the most security value from them.

This is part two of our four-part series, "What's Missing from Your MDR Solution," which explores:

  • The case for detection in addition to prevention
  • Overviews the MITRE ATT&CK framework and cautions coverage claims
  • The benefits of EDR in detection and response
  • Areas where EDR struggles
  • Getting more out of an EDR solution

100% prevention simply doesn't exist.

In cyber security, there are no perfect prevention tools. History shows us that they'll all fail eventually. Look no further than the rash of double extortion ransomware attacks and data breach announcements in the news through 2020 and 2021.

There are two main reasons prevention tools can't be fully trusted. First, threat actors have plenty of funds to buy the latest preventative security tools and hire top software engineers to explore their weaknesses to circumvent them. This is a constantly evolving "arms race." The second reason is more basic: threat actors often don't require advanced tradecraft because they simply take advantage of improper configurations, incomplete deployments, or poor cyber hygiene in environments to gain access to networks.

As organizations grow, so does risk. In many cases, the business risks associated with data loss, compliance fines, legal defense costs, brand impact, and general downtime justify the additional budget to identify when prevention tools fail. EDR tools allow for advanced detection and proactive threat hunting to simplify this process.

MITRE ATT&CK

Looking to any marketing material on endpoint tools will result in multiple references to the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) framework. Launched in 2013, the MITRE ATT&CK Enterprise framework is a living, open source collection that attempts to catalog many of the tactics and techniques used by known threat actors to compromise systems and networks. As security researchers contribute to this framework, it starts to provide a common language of describing an attack, detecting it, and recommending corrective action to mitigate impact.

There are three advantages of incorporating MITRE ATT&CK into a security program. If tools, vendors, MSSP/MDR providers map to this framework, organizations will have more context on where to look in logs to help piece together the full attack. The framework can provide insight to where in the attack the activity may be to determine appropriate next steps more rapidly. Lastly, and perhaps most importantly, it allows organizations to identify gaps in controls based on their industry risk and/or previous targeted attacks from threat actors to show risk in more easily understood business terms by removing the technical aspects of the solutions.

EDR Tools concentrate on device behavior. With a strong focus on logging and monitoring parent/child process relationships on a device, EDR tools map with several of the tactics of the MITRE ATT&CK framework, particularly execution, persistence, defensive evasion, credential access, discovery, lateral movement and collection. Many tools report providing 60%+ visibility across the framework depending on the tool and configuration.

While there could be accuracy in these statements, it is important to note that coverage does not imply full protection. Take for example technique T1210, exploitation of remote services. As of this writing, a quick visit to Exploitation of Remote Services, Technique T1210 - Enterprise | MITRE ATT&CK® shows 10 different procedures, including the well-publicized WannaCry, NotPetya and Emotet malware. The 10 procedures leverage at least 5 different vulnerabilities to execute these attacks for lateral movement, including CVE-2020-1472 (also known as Zerologon) which was a heavily exploited zero-day vulnerability that many organizations struggled to address. If the tool had detection against certain versions/aspects of Emotet, it doesn’t mean it would have something for Zerologon, but it could still claim coverage for the framework category.

Guidance:

When it comes to using MITRE data in tool selection criteria, coverage alone is not the key criteria. For known industry threats, challenge the vendor to show detections available to alert on the related techniques involved in those attacks in the off-the-shelf (OTS) offering. If the detection is available, but it requires specialists to identify and implement specific threat intelligence for it to work, it makes it much harder to get the full value from the tool. This point is often overlooked and greatly increases the total cost of ownership to maximize the benefits of one solution over another.

Where EDR tools excel


Before diving into the benefits of EDR tools, it is important to note this discussion will focus on the threat hunting tools and properties, as opposed to the prevention tools that replaced many legacy anti-virus solutions, which many organizations have adopted as stage one of deploying an enhanced Endpoint Protection Platform (EPP). It is important to separate EDR prevention and EDR hunting functions when reviewing your potential or current licensing agreement.

When it comes to reducing the time to detect and respond to attacks, EDR hunting tools provide multiple benefits. Endpoints are often where attacks start, so having visibility into the early stages of attacker presence is key to accelerating defense. Many endpoint indicators of compromise (IoCs) come from abuse of privileges, misuse of native tools, and device changes that defenders can only see by looking at the device level. EDR tools act like a flight recorder to track device state changes and provide context to the health of the box through showing configuration changes, active processes, and other command line activity. Many organizations struggle to capture all of this data with a Security Information Event Management (SIEM) because it can be very voluminous, which may be cost prohibitive from a licensing perspective, and often results in low fidelity alerts, which slows down the monitoring team. Organizations not capturing these logs may not have enough information to be effective during response and/or could be missing on important artifacts to confirm the scope of an investigation. EDR tools help simplify this process.

The EDR hunting platform further centralizes this collected data and provides powerful tools with built-in investigation processes to simplify hunting. These processes can help quantify where and when deeper hunts are necessary and show how many devices the attack involved via connections with other impacted devices. They may also allow network defenders to understand the device changes an attacker made that enable the team to reverse the changes without having to wipe the device, thus saving significant time and expense.

EDR tools also provide the ability for defenders to take protective action on compromised devices from a central location. Unlike SIEM tools that are designed for data analysis and detecting threats, when a device exhibits malicious or suspicious behavior, defenders can isolate the device from the rest of the network with the EDR capabilities. This faster time to respond can reduce the number of affected devices and result in additional cost savings for remediation.

Guidance:

When combined with other logging sources, EDR tools often help to validate other alerts to confirm the difference between true and false positives more easily. If the EDR logs exhibited no suspicious behaviors that might be expected based on the network logs, analysts can move on and save time. If existing SIEM tool deployments generate a significant percent of false positive alerts, having a way to reduce this noise could justify your EDR investment.

Not a silver bullet…


While EDR tools excel at quickly identifying attack behavior and its impact on a system, they do have shortcomings that do not allow them to replace SIEM tools and network monitoring completely. If there is only budget for one of these two core MDR components to start, here are limitations to keep in mind to ensure maximum visibility and minimal risks. Attackers target all parts of the IT landscape. As the name says, EDR provides detection and response visibility for only a part of the big picture. Examples of logging sources where EDR tools will not apply include:

  • The cloud management plane
  • Cloud services
  • Serverless infrastructure (containers, functions-as-a-service)
  • Application logs
  • Mobile devices
  • Perimeter device logs (i.e. firewall, Intrusion Prevention Systems (IPS), web app firewalls)
  • IoT devices (printers, manufacturing equipment, cameras, etc.)
  • Operational technology devices

When attackers leverage non-endpoint devices to gain traction in an environment, they may not need to take more easily detected steps on the endpoints, making them harder to spot through the traditional detections in EDR tools. It also means you may not have the data on the initial access in the EDR tool to prevent the threat actor from coming back in. For effective investigations, properly configured logs must be available. There are two EDR design philosophies to be aware of that could affect whether logs are available when responders are building an investigation within the EDR platform. The first is how many days of data the tool stores. The typical options from the major vendors are between 7 and 30 days. The longer the logs go back, the more time security researchers and/or the internal IR team has to learn new indicators of compromise to hunt for.

The second design feature is less obvious in the marketing material. As the vendor is typically incurring cost to store logs for review, some vendors have opted to move away from capturing all raw telemetry, but rather wait for certain trigger events to happen before pulling in additional telemetry. This may create a logging gap that an advanced adversary would likely be aware of after reverse engineering the tool. There are also limitations to how defenders and software vendors can write EDR detection rules. While capabilities vary from tool to tool, these challenges normally fall into one or more of these three categories:

  • The rules mimic normal system administrator behavior
  • Boolean search logic restrictions
  • Lack of accurate or complete threat intelligence

The first limitation can result in a very high false positive rate, especially upon initial deployment, which is not something that small teams are often prepared for. The second also has the ability to increase the false positive rate to a point that certain types of attacks are too noisy to set up default alerts, resulting in a potential gap. Some attack types require more of a threat hunting approach to identify the attack. This is a variation of the scenario mentioned earlier in the paper in the MITRE section comparing off-the-shelf detections to coverage only available with extra internal staff effort.

The third scenario also varies from vendor to vendor, but the ability to integrate threat intelligence into custom searches with the EDR tool requires having an accurate, current source of intelligence and having an operator that understands what good and bad look like to be able to write the appropriate detections. This type of work is not typically in the tier-one system analyst skill set, so unless those skills exist on staff elsewhere or there are plans to add them, it is difficult to fully integrate feeds outside the vendor default detections.

Guidance:

To enable effective investigations, it’s important to understand the design philosophies that can impact the availability of properly configured logs. Additionally, limitations around how defenders and software vendors can write EDR detection rules can increase the rate of false positives.

Getting more from an EDR solution


So, how can you get more from an EDR solution? Any discussion on EDR effectiveness should start with solution design. While universal coverage is ideal, the upfront costs may not make sense. If comprehensive coverage is not possible, companies should use risk analysis and threat intelligence to determine where to deploy EDR tools. It is often helpful to get guidance from a trusted partner who understands unique business and industry risks beyond the software vendor whose goal is to sell more licenses. Common deployment scenarios observed by NCC Group’s Red Team include all corporate endpoints but no servers, servers only, and servers in addition to VIP users. VIP users could include executives and their assistants, IT staff with higher access privileges, and other typical social engineering and spear phishing targets like HR, accounting and sales/marketing. The appropriate strategy should result in increased visibility around the highest risk assets.

As alluded to earlier, most organizations new to off-the-shelf EDR hunting tools quickly realize three things:

  • Very similar to SIEM tools, EDR hunting tools are complex and require continuous tuning to minimize false positives and reduce alert fatigue, as new threats evolve and as internal practices may trigger vendor default detections
  • Operators require a working knowledge of forensic investigation theory to know when, where and why to start hunts and what to include and exclude in investigations
  • Industry specific threats may require writing custom detections, as vendor defaults typically are limited to top global attacks due to shear volume

The tool complexity and lack of experienced staff in the talent pool lend to outsourcing support for EDR platforms. There are several advantages for doing this, especially for small teams. If this has not been a past consideration or there are internal biases against outsourcing in general, here are the standard reasons companies move in this direction:

  •  24x7x365 management/monitoring - minimize detection/response time without 4+ staff
  • Get level one triage review to reduce false positives so internal teams can focus on other work
  • Eliminate staffing “single points of failure” and related technology debt when someone leaves
  • Immediately “add” tool experts on staff to accelerate deployment, utilization and a return on investment
    without having to go through the typical learning curve when purchasing new technology

It is important to note here that tool monitoring is not enough if maximization is the goal. Management, while costing more, offers significantly higher value than just monitoring the logs coming from the EDR hunting tool for triage support. Most MSSPs will offer the ability to provide 24x7x365 monitoring of the tools to reduce log fatigue and/or complement their existing services, but in order for there to be any kind of response action taken, like device isolation during an attack, the provider will require some level of device management. 

Additionally, the EDR logs often lack additional context that is only available in the portal itself. Only adding 24x7x365 monitoring generally results in the main problem most people have with MSSPs, alerts that still require extensive additional work to clear up.

Choose a provider wisely

Depending on the specific EDR provider selected for management and
monitoring, other benefits might include:

  • Going beyond the core capabilities of the tool with the addition of separate detection engineering based on threat intelligence to improve on “off the shelf” or out of the box” detection capabilities
  • Getting on-going proactive threat hunting to identify previously unknown attacks faster
  • Strategic advice as to best leveraging the strengths of EDR, avoiding its weaknesses, and evaluating EDR’s position in your security stack, e.g., through integration with a SIEM as a second phase to mature the organizational security posture
  • Having forensics specialists available to support required investigations based on what the EDR tool uncovers

When considering outsourcing support for EDR tools, it is important to evaluate the provider’s strengths and weaknesses, especially in the context of their history and background. These are the four main types of EDR service providers together with common considerations:

  • Endpoint software companies setting up a SaaS model; product focused, not strong at advising on the big picture, helping integrate with other parts of your security stack
  • SIEM vendors with EDR integration setting up a SaaS model; focused on the core SIEM and general integration; not strong in service delivery and less depth in technical EDR details
  • IR as-a-service organizations leaving an EDR solution behind after an attack; tend to be extreme, costly deployments with less emphasis on a balanced approach
  • Managed Security Services Providers (MSSP) incorporating both network and endpoint solutions, while knowledgeable about service delivery in general, may lack forensics or threat research capabilities on staff

Guidance:

Companies can use risk analysis and threat intelligence to determine where to deploy EDR tools when comprehensive coverage is cost prohibitive. Companies should choose a trusted partner who understands unique business and industry risks to accelerate EDR deployment, utilization, and a return on investment.

Conclusion: Why EDR isn't enough

It is important to remember that product development and delivering services tied to a product are two different skill sets. Tool developers newer to services often struggle with the daily “in the trenches” activity that core service providers have worked out over time. The next paper in this series, “Is Your MSSP or Service Provider Qualified to Deliver MDR?”, will elaborate on how these challenges impact service efficacy and customer experience, along with other criteria to consider.


Main takeaways from this paper:

  • Prevention tools will fail at some point. Use business risk to guide the need to invest in detecting when this happens.
  • Companies should focus more on detections for attacks unique to their industry available Off-the-Shelf versus the typical MITRE coverage suggested in marketing materials.
  • Companies should focus more on detections for attacks unique to their industry available Off-the-Shelf versus the typical MITRE coverage suggested in marketing materials.
  • Compared to using SIEM tools, EDR hunting tools can simplify the logging of device configuration changes and suspicious behaviors and allow for centralized alert review, device isolation and investigations. Off-the-Shelf, they have powerful tools built in for investigations.
  • While EDR hunting tools can increase visibility and improve response efforts in environments, they cannot replace SIEM because they only show a portion of the network, have blind spots to non-endpoint attacks and may not provide comprehensive logs for responders.
  • EDR hunting tools are complex and require specialized skills to operate fully that many companies do not have on staff, lending to an outsourced support model.
  • When selecting an outsourced services partner, legacy service providers may offer a better customer experience than legacy tool vendors.

About the author

John Hollner

John Hollner

MSS Sales Specialist, Security Consulting, NCC Group, NA

John Hollner has been selling managed security services for over a decade with a heavy focus on SIEM and EDR technologies, the core of MDR solutions. He has worked extensively with financial services, healthcare, legal and manufacturing organizations during that time.  He is currently the RFP Manager in North America, where he draws on his industry knowledge to differentiate the NCC Group services.

Read part 3 of this series or learn more about our MDR solutions.

This guide and series will seek to provide clarity around a fast-moving, cluttered managed security marketplace. The installments of this guide will cover:

Part 1: Common buzzwords associated with MDR and their true meaning

Part 2: Why Endpoint Detection and Response (EDR) can only take you so far

Part 3: Is your MSSP providing true MDR capability?

Part 4:  In-house MDR creates more problems than it solves, and the case for outsourcing MDR