5 Things MSPs Should Consider When Evaluating EDR

Buzzwords and acronyms abound in the MSP industry, an unfortunate byproduct of marketing years in the making. Cybersecurity is a hot watercooler topic at any business. Well, now probably more likely a virtual happy hour than a watercooler, but, nevertheless, cybersecurity remains top of mind.

To sleep at night, MSPs feel they must enhance or expand their security offerings beyond the standard layers, like firewalls, firewall filtering, Active Directory protocols, DNS filtering and antivirus/malware detection. One of the ways many MSPs feel they can satiate their cybersecurity concerns involves buzzword-y new acronyms floating around involving “EDR” or endpoint detection and response. But what is EDR really, and what can it do for MSPs and their clients?

But, first, besides EDR, there’s also ADR, MDR, xDR … The industry can surely expect newer blank-DR acronyms to come in the next few years. What are all these acronyms, and how do they help MSPs protect their clients? Here are a few definitions:

Here are five things MSPs should consider when evaluating EDR solutions.

1. All security tools with an endpoint agent are basically EDR.

Their job is to detect malicious code, applications, scripts or other malicious files and make a status determination on the fly. Most security agents use various methods like physically scanning file hashes, scanning file content, watching behaviors, looking at scripts and detecting known attack surfaces to try to ascertain if a newly encountered file is good or bad.

How the security agent reports its activity depends on the EDR tool. So, while many security tools claim they offer an “EDR” solution, the key is to determine the level of threat, suspicions, and action taken in reporting or alerting that adds value for MSPs.

2. The “R,” or response, is key to a successful EDR solution.

While many security tools report and alert, the level of response is the most important aspect of any security practice. If the security agent provides minimal information for decision making, it’s of limited use to the technical personnel responsible for intervening.

On the other hand, technicians can take advantage of security tools with consoles that display alerts, reports and visibility into whether an agent responded, how the agent responded and the agent’s current status. Too often, tools don’t provide necessary insight for reviewing or comparing threat data or approaches–like the MITRE attack framework or other sites with relevant threat information.

Solutions with a more comprehensive APIs are advantageous for custom review, integration into more dedicated threat review tools, or for alerting through a log gathering and reporting tool. APIs are valuable for providing added information from which human technicians can make decisions.

3. What can be done with the EDR information? Is it actionable?

Once a tool has been selected, what should be done with the information it provides? Answering this is key to successfully setting EDR expectations for customers. If a client requires that an MSP has an EDR solution in place, installing an agent is only half of the equation.

Gathering the information into a comprehensive tool or suite can be daunting. If the security solution provider has tools like alerts, reports or an API, start there. However, these tools are often limited and need to be supplemented by a solution with higher performance or a faster response time.

Log gathering tools are a higher-performance option that allow many tools to feed into a single system. Once such a solution is in place, the next challenge is to build rules for sifting through the millions of ingested points of information. These rules provide human reviewers more details for making decisions. It may take several cycles to focus on the rules that lead to successfully spotting suspicious or malicious activity and protecting customers.

4. Understand what’s behind the EDR hype.

What’s the buzz around EDR and why has it become such a topic for discussion? Fair question, considering the level of effort it takes to stand up, manage, monitor and address a situation when it arises. Simply having a security vendor that “supports EDR” isn’t enough. Selecting a check box to satisfy a requirement is, again, only half of the equation.

So, why go through the time and expense of implementing EDR? Here are three top reasons:

5. Plan out next steps for adopting EDR at your MSP.

Simply selecting ticking an EDR box won’t necessarily contribute to client security. MSPs should evaluate the needs EDR will satisfy, the level of effort it takes to implement, and how EDR fits into their overall service offering.

Vendors won’t hesitate to offer “EDR solutions,” but it’s up to the MSP to properly implement and establish process to support expectations. Simply having the solutions does no good. EDR done right requires the additional team focus, rules, review and responses. Implement an EDR offering with caution and planning.

This guest blog is part of a Channel Futures sponsorship.