Endpoint Detection and Response Best Practices in 2024

Perhaps the trouble with endpoints is that they keep multiplying, faster than security teams can fully understand their potential impact on the whole. As a Deepwatch Principal in Endpoint Detection and Response, I have some thoughts for teams looking to deploy advanced EDR solutions to address the many challenges. Follow these key recommendations to ensure success in your program.

Pilot Testing

Not every user or every department poses the same risk to an organization. It’s important to first designate those users and protectors of critical business applications. When it comes to targeting your pilot group members, it’s the power users–the admins running applications that underpin the business–that should be your focus. It should also include a healthy amount of servers that can be designated for pilot testing. 

One key to any pilot program is identifying these individuals/hosts.Typically organizations will know who these users are, but it is worth a review during the pilot stage. It’s also the difference between a few people being affected during the pilot and the entire organization being impacted. With proper pilot testing, any new updates to policies or agent versions can be tested in a controlled manner before being deployed to the rest of the enterprise.

Start in Detect Only Mode

When deploying an EDR solution, make sure your initial policies are set to Detect Only mode. You don’t want the solution to perform any response actions just yet. You will avoid any interoperability issues this way. To go into prevention mode right away could cause issues with your critical business applications. When teams fail to do this, it can result in phone calls and panic attacks.

Limit Policy Exceptions 

One of the key pitfalls to avoid is the creation of exceptions to policies during this phase. Poking holes in your policy to make a solution work is not necessarily the way to approach an EDR pilot. A variety of EDR software vendors will recommend settings with exclusions in order to function, but don’t start with a holistic security mindset. One solution may ask for a blanket exclusion of entire directories, which is not in your best interest.

Well-defined policies are key to an effective SOC and to improving cyber resilience. They could mean the difference between a day of detection and response actions, and a day with your DFIR vendor. If you follow the best practices of your EDR vendor, limiting the number of exceptions, you will protect the organization the best possible way you can by that vendor. Configurations on those policies allow for an automated response by that EDR solution.

Your detections must be supported by equally sound response policies. If there is an aggressive detection that your team configures as moderate, those things are going to slip through. In such a case an aggressive threat will continue to be active, persistent with malicious intent. Your policy has to assign the right response at the right time.

Over-Engineering Solutions

Another pitfall is the tendency for teams to over-engineer on the platform itself. If you make unique policies for every department or division, you only increase time and overhead. Teams should keep it simple, establishing a clear, broad base policy for your production that a majority of users adhere to. Then they can pilot policies for critical users, those people with the keys to the kingdom, with a limited number of exceptions.

With all the tuning necessary to make prevention policies work, there is the potential for an EDR administrator to create an environment of false negatives. Avoid this by limiting those exceptions required by the EDR vendor solution. Sometimes those exclusions are required by the vendor to allow something to work, but you will lose valuable visibility.

Agents Everywhere You Can

If an EDR agent can be installed on an endpoint, it should. Some teams will see a high-touch endpoint and exclude it from the solution. This is exactly the opposite of how you should approach EDR. Those rich targets are exactly the ones that should be included. Without an agent on these endpoints, you can’t prevent attacks, and you can’t gather critical information if there is an incident. If you have to do response work, you won’t have the information you need.

Replacement or Changes to EDR

For teams replacing an existing Antivirus (AV) or EDR solution, the key is to watch for interoperability issues or known exclusions with each EDR vendor. For example, if you were changing from Sentinel to CrowdStrike or vice versa, you want to understand exclusions for each. Otherwise you can have a variety of conflicts or spikes in CPU usage. Running two EDR solutions in prevention mode at the same time is going to create headaches.

The cybersecurity space is undergoing many changes, and teams are consolidating tools or deploying new solutions. It’s important to understand those changes, and to ensure you don’t have multiple EDR solutions with different policies operating in prevention mode.

Balance EDR Prevention Policies and Business Risk

Prevention policies bring balance to business risk. The primary way prevention policies cause issues in critical business functions is through the mismanagement of EDR solutions or policies. There will always be interoperability issues with EDR software across an organization, it’s the nature of so many solutions interacting in the environment. With proper testing and tuning of your EDR solution, you can more easily identify and adjust to those issues.

Other Recommendations

Anyone deploying or replacing an EDR solution should target at least a 5% sample, for example if you have a thousand endpoints, shoot for at least fifty in your pilot to ensure a good sample. From that pilot group, establish a pilot or test policy that sits above your production policy. This is where you make granular changes on the pilot side before pushing those changes to production. For some of those high-touch users you can create a second pilot group that you roll out changes to before being placed on a broad audience. 

Teams can go from having no EDR solution or policies to full engineering implementation in as little as sixty days. It will depend on deployment tools you have available–the bottleneck is usually how quickly you can deploy agents. For example, some may be in a segregated network that requires manual installations. Once you’ve figured out how to deploy those agents, policy development and ongoing maturity can happen very quickly. Teams can conduct weekly or bi-weekly changes to the pilot environment, then roll those policy changes out to the broader user base on the production policy.

↑