5 common mistakes to avoid when building an endpoint detection and response capability

Organizations are increasingly looking to Endpoint Detection and Response (EDR) to detect and respond to threats that bypass prevention tools. EDR is designed to give organizations better visibility into finding and stopping malware, advanced threats, and reducing the risk of a breach. Unfortunately, while EDR tools can assist with detecting attacks and limiting dwell time, they can also create new challenges for organizations that are unfamiliar with the processes and expertise required.

Here are 5 common mistakes security teams make with EDR, along with actionable recommendations to help you avoid these missteps and drive the most value from your investment.

Download an EDR Buyer’s Guide to learn additional elements to consider when evaluating an EDR product.

1. Underestimating the time and resources required for EDR

EDR products collect a lot of data, and the sheer volume of information can be overwhelming. A typical EDR product provides extensive visibility into endpoint activity: operating system activities, application activity, process starts and stops, cross-process injections, file access, registry changes, network connections, memory content, and the user’s interactions with data, including creation, modification, transmission, and much more. And that is just what is collected. The raw data needs to be analyzed, correlated, potential threats investigated, and then the user needs to respond to confirmed malicious activity. The amount of work adds up quickly.

Getting a handle on endpoint data

While visibility into endpoint activity is immensely valuable to an organization, parsing through the data can be extremely difficult. The image above shows 14 days of data for one mid-sized organization—over 40 million processes that its security team would need to parse through.

A real-world example can help illustrate this point. A hospital implemented an EDR product to improve visibility into their endpoints and reduce the risk of threats. However, the security team soon realized they didn’t have the internal resources to review all the endpoint data and find the actual threats within the mountain of EDR alerts.

After deploying the EDR product across its endpoints, the analyst team was inundated with 100,000+ alerts that needed attention. The continued influx of new alerts quickly became unmanageable. The team had difficulty triaging any more than 50 threats a day and the analyst team was only able to devote time to a limited number of endpoints. Investigating and responding to all of the alerts would have required multiple full time positions—and everyone on the hospital’s security team already had full-time jobs. They still believed in the power of EDR—they just had underestimated the time and resources required to build an EDR capability.

What to do instead:

• Make sure your security team has a good understanding of how much time is required to triage and investigate potential threats.
• Understand the average volume of alerts that will be generated every day, week, month.
• Seek approval for additional headcount to manage the EDR product, or determine how much time can be allocated from existing security positions.
• Consider a managed solution if your team does not have at least one full-time employee to triage, investigate, and respond to alerts generated from an EDR product.

Read the full case study to learn how the hospital reduced its daily EDR workload from hours to minutes.

2: Using an MSSP to manage EDR

Some security teams assign management of an EDR product to a managed security service provider (MSSP) without understanding the distinct expertise EDR requires. MSSPs typically offer a breadth of security services centered primarily on signature-based network security technology. They can be a staple of organizations that need to check the right boxes for security compliance purposes and have built their services around that function.

The problem is that an MSSP’s infrastructure is typically designed around signature-based detection, perimeter security products, and ensuring compliance. The current MSSP business models simply cannot support EDR, even when they advertise such services. For the most part MSSPs employ low-level SOC analysts who are there to handle high-volume monitoring. EDR requires a different skill set, additional technologies, and a updated processes. In order to add MDR services to the mix, most MSSPs would need to completely retrofit their SOC architecture and go through an intense hiring binge to bring on a veteran team with experience in threat hunting, malware analysis, incident response, and data science. It’s a massive investment and culture shift that most MSSPs have not and will not make.

Another real-world example comes from an investment firm that experienced an MSSP’s shortcomings firsthand. The firm rolled out Carbon Black Response to continuously monitor all endpoint activity and detect potential threats. The firm was working with two MSSPs and assigned one of them to manage the EDR product. The team quickly realized that the MSSP did not have the experience and expertise to deliver a full EDR capability. Threats were often lingering in the firm’s environment for days before the MSSP caught them. While the firm knew that Carbon Black Response was the right endpoint product to use, they recognized the MSSP was better suited to manage IDS/IPS than EDR.

After moving to a managed detection and response (MDR) solution, the firm saw an immediate improvement in detection accuracy, breadth, and response time. When it previously took days or weeks to be notified of a threat, the MDR solution quickly notified the firm of a threat and enabled rapid response within minutes to hours.

What to do instead:

• Conduct due diligence to get a handle on the distinctions between an MSSP managing EDR and Managed Endpoint Detection and Response.
• If you’re considering having an MSSP manage your EDR product, dig into the provider’s staffing capabilities and team’s expertise as well as the workflow required for advanced detection and investigation.
• When assessing the MSSP’s SOC employees, look for deficiencies in areas like threat investigation and forensics, security operations, data science and analytics, and reverse malware engineering.

Read the full case study to learn how the investment firm cut their mean time to respond (MTTR) by replacing their MSSP’s endpoint threat detection service.

3. Forgetting to outline the triage and response process

Every organization that buys a tool, implements it, and then thinks that they are all set is overlooking a critical process that must be defined with every security product. Once a product detects a potential threat, what happens next? Have you outlined the triage, investigation, and response process for your organization? Without answers to questions like these, organizations quickly find themselves overwhelmed with the workflow surrounding the EDR product.

Your team should be able to answer questions like:

• Is there a process in place for tracking investigations?
• How do you prioritize potential threats within the EDR product and across multiple products?
• Does your team have the capacity to triage multiple threats simultaneously?
• How will threats be assigned?
• What types of information will be available to the analysts about the user, threat, and endpoint?
• Does the EDR product provide all of the information needed to make a decision or will analysts need additional data sets?
• Can the EDR product’s alerts be integrated into other products and your pre-existing workflow? If so, what specific endpoint telemetry and threat information can be ingested?

What to do instead:

• Make sure you’ve outlined your process for alert prioritization, assignment, investigation, and remediation ahead of time.
• Consider how you are going to increase your response bandwidth before looking for new detection technology.
• Explore options such as adding more bodies, improving alert validation efficiency, or reducing current alert volume.

To learn a framework for response operations, watch an on-demand webinar: How to Take Control of Your Incident Response Operations.

4. Placing too much emphasis on prevention

EDR solutions are increasingly beginning to include some form of prevention in an attempt to offer an “all-in-one” solution. As prevention capabilities mature, it is possible endpoint prevention, visibility, detection, and response capabilities will converge into a single endpoint product. However, we are not there yet. While it may be tempting to look for a solution that includes prevention alongside detection and response, it is not recommended to weigh your EDR purchase too heavily on prevention at this point.

Be cautious of EDR solutions with immature prevention capabilities. Purchase EDR products first for their visibility, detection, and response capabilities. If the solution also includes prevention capabilities that is an added bonus.

What to do instead:

• Assess yourself and your organization. Do you fall more into the prevention camp or detection and response camp? While they are not mutually exclusive, your underlying beliefs specific to prevention vs. detection will impact what aspects you include in your evaluation of EDR products. If prevention is more important, it might make more sense to focus on AV, NGAV, or whitelisting before investing in EDR.
• If prevention is a factor in your EDR purchase, ensure you perform a thorough analysis that definitively defines what will be stopped. Compare this against your existing AV solution to understand if you are buying a replacement or additive product.
• Understand every potential EDR products’ roadmap and how they will evolve over time to deliver a true prevention capability.

Read more: What to Do When Threat Prevention Fails (Hint: It Always Does)

5. Forgetting to assign metrics to measure efficiency and improve security operation’s effectiveness

Metrics allow you to show management how critical your security efforts are to your organization and how well you’re doing when defending against different types of attacks. If an organization purchases EDR and doesn’t have a reporting structure in place they will constantly be questioning how well the product is performing.

It is critical that you understand your highest fidelity tooling. This will support prioritization and the amount of time spent acknowledging, confirming, and remediating threats.

Some common metrics organizations track specific to EDR include:

False positive and negative rates:

How many alerts converted to actual threats? It should go without saying but if you are not tracking the EDR product’s false positive and negative rate you will have no way to assess improvement and accuracy.

Severity of detected threats:

You should have some rating of the severity or impact of the threats the EDR product detects. Whether this is a simple High/Medium/Low or something more specific to your organization, severity should be a key metadata point for any threat identified. This information paired with your false positive rate can provide a good measure for understanding the potential impact of any particular alert. This in turn will help you prioritize alerts appropriately. For example: an alert with a near 100% true positive rate but of typically low severity should not be prioritized when compared to an alert that has a 75% true positive rate, but is almost always high severity.

Occurrence to detection:

This is one of the most important measures for understanding the EDR product’s efficiency and timeliness. It is important that you understand the time it took from something to happen to an alert being generated. The goal should be to reach as close to zero as possible. However, you should also have realistic expectations and a clear definition of what constitutes “detection.” In most programs, detection should be defined as the point at which the threat is identified and confirmed. The confirmation is key, because if an alert triggers but no one confirms, the alert does not provide any value to improving your security. This metric will help you assess the timeliness of an EDR product as well as your security operations.

Resolution time:

Once an attack is identified, how long did it take to resolve? Was the attack shut down and cleaned up in minutes, hours, or did the threat dwell for days or weeks due to poor process, lack of communication, and other roadblocks? This value helps communicate the effectiveness and maturity of your program and how well you have integrated the EDR product. It also can highlight underlying issues with the EDR product – are you still having to do a full investigation for every alert because the EDR product is only presenting part of the picture? Does the EDR product include features that supports your response efforts?

Before you make these mistakes…

It’s important to realize that an EDR product does not give your organization an EDR capability. Making the most of your EDR investment requires the right products, process, and expertise.