Five EDR prevention policy settings that should always be enabled

Endpoint detection and response (EDR) tools are complex and often opaque systems. And yet, they’re a critical—and expensive—part of our security tool stack. We rely on our EDR tools to regularly monitor for, alert on, and often prevent malicious behavior. 

Among its component parts, EDR tools rely on policy configurations or predefined rules and settings that can be enabled to detect and act on specific behaviors and actions. There are innumerable, highly-technical settings that make up an EDR, many of which don’t come enabled out of the box. 

In this post, we’ll drill down into the critical policy settings that should be top-of-mind and what they mean for your team once enabled. 

Credential dumping 

OS Credential Dumping is a commonly abused vector attackers use to extract authentication material, such as passwords or hashes, from an operating system's memory, files, or services. This serves as a springboard for lateral movement or privilege escalation, making it a critical technique for attackers to capitalize on their access to your network. Common tools and methods for credential dumping include exploiting arbitrary memory reads, accessing SAM files, or using tools like Mimikatz.

Typically, your EDR’s OS Credential Dumping prevention policy setting actively monitors and blocks unauthorized attempts to access or manipulate LSASS, such as reading its memory or loading a new authentication package, effectively neutralizing attackers' efforts to extract sensitive credentials. Leaving this policy disabled likely means your teams are writing detections for the innumerable and highly specific methods an attacker could dump credentials from LSASS. That means more false positives, higher operational load, and simply a higher likelihood of missing attacks altogether. 

Detect on-write

A detect on-write (DoW) policy setting actively scans files before they are executed. EDR tools like CrowdStrike have DoW settings that use machine learning to analyze files on endpoints as they are written to the disk, identifying potential threats before they can be executed and in some cases, quarantining the file/device or preventing the action entirely.

While this a critical policy setting to alert on potential threats before they detonate, teams often disable this function, potentially due to high-performance workflow such as software development or media production. Frequently generating large volumes of new files could trigger false positives or slowdowns. However, in these cases, teams should opt to adjust the machine learning sensitivity levels versus outright disabling to strike a balance between detection accuracy and operational needs.

Vulnerable driver protection

A Bring Your Own Vulnerable Driver (BYOVD) attack is a technique where attackers exploit legitimate but outdated or poorly coded drivers with known vulnerabilities to bypass security mechanisms and gain elevated privileges on a system. For example, an attacker might attempt to deploy an outdated, vulnerable graphics driver with known privilege escalation flaws. The vulnerable driver protection setting actively analyzes the unique characteristics of new drivers, such as their hash, metadata, and versions, rather than relying solely on basic file hashes or names. 

When that known vulnerable driver is installed, your EDR recognizes this profile and prevents the driver from being installed. This functions similarly to the DoW setting where the EDR identifies the content as it's written to the disk, but focuses on the specific file contents. This setting proactively ensures that malicious drivers are stopped at the entry point, preventing attackers from exploiting them to compromise your systems. 

Legitimate but uncommon drivers might lead to false positive, but such scenarios are unique enough as to warrant that this setting is consistently enabled in your EDR tool. 

File system access

File system spidering, similar to how a bot crawls its way through a website and its subpages, is common among ransomware variants. A malware variant might quickly move through directories, performing multiple read actions in order to find information useful to them, such as secrets, sensitive data, intellectual property, etc. 

Your EDR’s file system access policy setting performs similarly to a DoW policy in that it identifies processes performing unusual or high-volume operations throughout your file system. Without this policy enabled, malware that relies on spidering your filesystem could run on your endpoints with impunity. Fear of false positives is another roadblock here, especially in large-scale data operations, but often inhibits what is otherwise an important element of your EDR’s ability to detect—and prevent—ransomeware threats.

Memory scanning 

Not all adversary tradecraft occurs directly on the disk. Your EDR’s memory scanning settings provide the necessary coverage against fileless malware, such as PowerShell scripts or in-memory implants like Cobalt Strike or Sliver, which operate entirely in memory and avoid traditional file-based detection methods. 

For example, if a threat actor loads a command-and-control (C2) agent directly into a process's memory to establish remote access without leaving artifacts on disk, memory scanning search for indicators related to the agent can identify and block this malicious behavior before it escalates.

Similar to DoW policies, memory scanning should always be tuned before being disabled outright. Though often negligible, memory scanning is a more resource-intensive function of your EDR. Teams can configure memory scanning to focus on high-risk processes or trigger scans only during suspicious activity, such as specific system calls or anomalies in behavior. Adjusting the scan depth or excluding low-priority processes can further optimize performance without sacrificing security or system function. 

Configuring your EDR for success

You are investing money in best-of-breed security controls for a reason. We expect tools like our EDR to serve as a proactive defensive mechanism against common threats like ransomware. Still, these settings are frequently found to be disabled in environments, typically due to concern over false positives or operational capacity. 

The reality is, these settings being disabled inhibit your EDR’s ability to proactively detect and prevent threats as expected when you make your original investment. These prevention policies and settings create a baseline threshold for alerting and prevention that would otherwise have to be managed by your SOC, MDR, or internal detection teams to manage and create alerts for, occupying a similar amount of time and resources with a far greater potential for things to slip through the cracks. 

There are a vast number of policies and settings to consider when configuring your EDR tool. To maximize the effectiveness of the tool, a quick audit of these critical policies is an excellent starting point.