EDRs distrust RMMs, and that's ok!

A few months ago an IT team contacted us (a bit frustrated) because their Endpoint Detection and Response (EDR) system had flagged and blocked Level as a potential security threat.  Level is their primary tool for managing and securing their endpoints, and an absolute necessity in their daily work.  Initially they were flustered and asked: "Why is Level being blocked by our security stack?"

A few weeks later, the same EDR detected and stopped an intrusion attempt from a malicious actor who was exploiting a vulnerability through a different RMM tool.  This incident was a revelation for them.  The attack specifically sought to use another RMM's extensive access and control features for malicious purposes.  Attackers are using industry-trusted tools to bypass security stacks.

The event illustrates a critical lesson: the EDR’s action to block unauthorized RMM tools wasn't an inconvenience but a crucial protective measure. It highlights the importance of configuring the EDR to trust the organization's chosen RMM tool while maintaining a healthy suspicion of all others. This wasn't about hindering operations but about ensuring that the only remote control tool operating within their network was the only one they trusted.

Understanding the Landscape

EDRs represent a central component of our defense against cyber threats, employing advanced strategies to detect, investigate, and respond to potential security incidents at the endpoint level. Their role in the cybersecurity infrastructure is indisputable, offering unparalleled visibility and control over the activities transpiring within our networks. However, the rigorous scrutiny applied by EDRs can sometimes result in the unintentional blocking of legitimate tools, like Level, which is pivotal for IT teams in managing systems remotely.

Any RMM tool, designed to streamline the management of IT systems, can inadvertently be marked as malicious by EDRs. This is not without reason; the same capabilities that make RMMs invaluable to IT professionals also render them potent tools in the hands of adversaries, should they be compromised. It's a double-edged sword – the efficiency and control afforded by RMMs, if weaponized, can become a significant threat to organizational security.

The Heart of the Matter

The frustration that arises when EDRs block RMM tools is understandable.  We rely on RMMs for a myriad of critical tasks, from routine maintenance to urgent incident responses. When access is impeded, the immediate reaction is often one of irritation towards the RMM, perceived as the root of the complication. However, this perspective misses the broader context of the EDR's function – to safeguard the endpoint ecosystem against any and all threats.

Acknowledging this, the path forward is not to question the vigilance of EDRs but to refine our approach to their configuration. The essence of the solution lies in tuning EDRs to recognize and allow the RMM tools employed by the IT team, ensuring their unimpeded operation. This strategy does not dilute the security posture but rather strengthens it by maintaining rigorous scrutiny over all other RMMs and remote access tools by subjecting them to the EDR's full analysis.

Implementing a Solution

In EDRs, exceptions (also known as exclusions) are needed for ensuring that legitimate applications like RMM tools operate efficiently without being mistakenly identified as security risks. There are three primary types of exceptions that should be considered when configuring the EDR to accommodate tools like Level:

1. Path to an Entire Subfolder Exclusion
   This type of exception involves directing the EDR to overlook all files within a specific subfolder. It's the broadest form of exclusion, offering ease of setup but presenting a higher security risk, as it could potentially allow malicious files in the excluded folder to go undetected.
   ‍
2. Path to Executable (Binary) Exclusion
   ‍A more targeted approach, this exclusion specifies that only certain executable files of the RMM tool are to be ignored by the EDR. It offers a tighter security profile than subfolder exclusions by limiting exceptions to known, essential binaries. However, this method requires accurate knowledge of the RMM's executable file paths, which may need updates if those paths change.
   ‍
3. ‍Binary's Certificate Signature Company Name Exclusion
   ‍The most secure and recommended method of exclusion involves configuring the EDR to trust any executables signed by the RMM provider's verified digital certificate.  This approach is the safest because it ensures that only software authenticated by the trusted vendor is permitted, significantly reducing the possibility of malicious software masquerading as the trusted RMM.

For Level, the specific signer identity to exclude is "LEVEL SOFTWARE, INC."

We strongly recommend using the certificate signature exclusion whenever possible. This method leverages the security and authenticity guaranteed by digital certificates, focusing on the identity of the software provider rather than just the location or characteristics of its files.

The Path Forward

Crafting the right EDR exceptions is a crucial step toward ensuring that remote access tools like Level seamlessly integrate into your IT infrastructure without compromising security. By prioritizing certificate signature exclusions, IT teams can maintain operational efficiency and robust security measures simultaneously.

Guiding our clients through the nuances of EDR configurations, especially in creating specific exceptions for Level, is part of our commitment to providing a secure and efficient remote management experience.  

Please let us know if you have further questions or comments about ensuring Level operates smoothly alongside your security tools!