EDR Tuning and Custom Detections: Getting More Than Default Prevention From CrowdStrike and SentinelOne

The most dangerous assumption in endpoint security is that an EDR deployed in default prevention mode provides comprehensive protection. Vendor marketing conflates prevention with detection, but they are fundamentally different capabilities. Prevention stops known-bad binaries and behavioral patterns the vendor has classified at the platform level. Detection surfaces suspicious activity that an analyst needs to investigate, which may or may not trigger prevention. The operational gap between these two functions is where sophisticated attackers live.

Living-off-the-land (LOTL) techniques exploit legitimate system tools to execute attacker objectives. PowerShell, WMI, certutil, regsvr32, mshta, and dozens of other Windows binaries are present on every endpoint and, more importantly, are used legitimately by your business. When an attacker spawns PowerShell from a Word document to download a second-stage payload, the EDR's prevention engine sees a signed Microsoft binary executing a script. Unless a custom rule or behavioral indicator specifically flags that parent-child relationship, the action proceeds without alert. Red Canary's annual Threat Detection Report consistently shows that the most prevalent techniques in real-world incidents involve PowerShell, Windows Command Processor, and Windows Script Host, not novel malware binaries.

The technical capability to detect these behaviors exists in every modern EDR. CrowdStrike Falcon captures process creation events with full command-line arguments, parent-child relationships, network connection events, registry modifications, and file system activity at the kernel level. SentinelOne's Deep Visibility records the same telemetry. The platform has the data. The gap is the absence of detection logic that queries that data for the specific behavioral patterns relevant to your threat model. Writing that logic is not optional if you want meaningful detection coverage.

The operational consequence of running prevention-only mode becomes clear during incident response. When a breach investigation reveals an attacker lived on the network for 60 days using PowerShell remoting, WMI for lateral movement, and living-off-the-land persistence mechanisms, the EDR logs show every action in retrospect. The data was there. There was simply no rule to alert on it in real time. Every day spent building detection logic before an incident is time you save during the inevitable post-incident forensic review that reveals the coverage gap.

CrowdStrike's Indicator of Attack (IOA) framework is the behavioral detection layer that sits above the signature-based Indicator of Compromise (IOC) prevention engine. Custom IOA rules allow you to define new behavioral patterns that trigger alerts or prevention actions based on process, network, registry, or file events. Understanding the rule structure is prerequisite to writing effective rules.

Each Custom IOA rule belongs to a Rule Group assigned to a prevention policy. The rule structure consists of four core elements: the Action Type (the event class being evaluated, such as Process Creation, Network Connection, or Module Load), the Rule Fields (the specific event attributes to match, such as GrandparentImageFilename, CommandLine, and ImageFilename), the Pattern (the regular expression or literal match applied to each field), and the Disposition (whether matching events trigger Alert-only or Alert-and-Block). Grouping related rules into a named Rule Group lets you enable or disable related detections as a unit and makes version control practical.

High-value behavioral patterns worth encoding as Custom IOA rules cover several categories. Office-spawned command interpreters are among the highest priority: if Word, Excel, Outlook, or PowerPoint spawns cmd.exe, PowerShell, wscript, cscript, or mshta, that pattern has no legitimate business justification in most environments and represents either macro malware or a phishing delivery mechanism. The rule should match on GrandparentImageFilename containing winword.exe, excel.exe, or outlook.exe with a child ImageFilename matching the interpreter path. Encoded PowerShell execution is a second high-priority category: PowerShell launched with -EncodedCommand, -enc, or -ec arguments indicates deliberate obfuscation of the command string, which is a strong signal regardless of what the decoded command actually does. LSASS access from unexpected processes covers credential theft: if a process with an ImageFilename other than a defined allowlist of legitimate security tools attempts to open LSASS with access rights sufficient for credential dumping (PROCESS_VM_READ), the rule should generate a high-severity alert.

CrowdStrike regex in rule fields uses a limited syntax compared to PCRE: it supports character classes, quantifiers, alternation, and anchors, but not lookaheads or backreferences. Test every regex pattern in isolation before deploying to a prevention policy. A broken regex in an IOA rule may silently fail to match rather than generating an error, so functional validation against known-good event data from your Endpoint Activity Monitor is mandatory before marking a rule as production-ready. Deploy new IOA rules in Alert-only disposition for a minimum of two weeks to understand the volume and nature of matches before considering blocking disposition.

SentinelOne's Storyline Active Response (STAR) is the custom detection framework that extends the platform's behavioral AI engine with analyst-written detection logic. STAR rules query the Deep Visibility telemetry stream using a structured query language similar in concept to SQL, with specific operators for event correlation and time-bounded sequence detection. The result is a detection engine that can express multi-event behavioral sequences, not just single-event pattern matches.

The STAR query language operates on Deep Visibility event types including Process Creation, Network Action, File Modification, Registry Modification, and DNS Resolution. A basic process creation rule filtering on command-line content uses the syntax: EventType = 'Process Creation' AND ProcessCmd ContainsCIS 'EncodedCommand'. The ContainsCIS operator performs a case-insensitive contains match, while MatchesRegex allows regular expression evaluation. For sequence detection, the SEQUENCE operator chains events with an optional time window: SEQUENCE(EventType = 'Process Creation' AND SrcProcParentName = 'WINWORD.EXE', EventType = 'Network Action' AND NetworkDirection = 'OUTGOING') WITHIN 5 MINUTES detects a pattern where Word spawns a process that subsequently makes an outbound network connection within a 5-minute window. This expressiveness exceeds what single-event IOA rules can achieve and enables detection of multi-stage attack sequences.

STAR rule response actions define what happens when a rule matches. The available actions are Alert (generate a threat alert and add to the SIEM feed), Kill Process (terminate the matching process), Quarantine File (move the file to quarantine), Remediate (initiate full remediation workflow), and Network Quarantine (isolate the endpoint from network access). Automated response actions require confidence in the rule's precision. For new rules, configure Alert-only and monitor the match volume and quality for two to four weeks. Automated kill or isolation actions should only be applied after the rule has demonstrated near-zero false positive rates in your environment.

Scheduled STAR rules run against historical Deep Visibility data on a defined interval, enabling threat hunting use cases. A scheduled rule can query 30 days of process creation events looking for patterns consistent with discovery activity, enumeration commands, or persistence mechanisms, and generate alerts on historical matches that were not caught in real time. This retrospective detection capability is particularly valuable after a new threat intelligence report identifies a TTP previously not in your detection coverage: write the STAR rule, run it against historical data, and determine whether the technique was used in your environment before you deployed the detection.

ATT&CK Navigator is the practical tool for measuring what your EDR currently detects and what it does not. The Navigator is a web-based visualization of the ATT&CK matrix that supports annotation layers: you can color-code techniques to indicate whether your current detection coverage covers them, and where the gaps are. Building an accurate coverage layer requires honest assessment rather than vendor claims.

To map your actual EDR coverage, work through the ATT&CK techniques most relevant to your threat profile and, for each technique, identify whether you have an active detection rule that fires on that technique's execution. Do not count vendor-default detections you have never validated. For each technique, run the corresponding Atomic Red Team test in a lab environment and confirm the EDR generates an alert. If it does not, the technique is not covered regardless of what the vendor's ATT&CK matrix graphic shows. Document the result in your Navigator layer: covered and validated techniques in green, covered but unvalidated in yellow, no coverage in red.

The gap analysis output becomes your detection engineering backlog. Prioritize gaps by two factors: the frequency with which the technique appears in threat intelligence relevant to your industry, and the impact if the technique succeeds without detection. Credential access techniques like T1003 (OS Credential Dumping) and T1555 (Credentials from Password Stores) rank high on both dimensions for most organizations. Execution techniques like T1059 (Command and Scripting Interpreter) sub-techniques generate high volumes of legitimate activity and require environment-specific tuning to avoid noise. Persistence techniques like T1053 (Scheduled Task/Job) and T1547 (Boot or Logon Autostart Execution) are relatively low noise and should have validated coverage early in your detection engineering program.

Update the Navigator coverage layer every quarter as you add new detection rules and validate existing ones. The coverage map also serves a communication function: it translates detection engineering work into a visual artifact that non-technical stakeholders can understand, and it provides a measurable metric for the detection program's progress over time. A detection program with no coverage measurement is a detection program with no accountability.

Exclusion management is where EDR deployments most often degrade their own security posture over time. The operational pressure to reduce false positives and performance overhead drives analysts to create exclusions that, in aggregate, open significant blind spots. Understanding the distinction between detection exclusions and prevention exclusions, and implementing separate approval workflows for each, is critical to maintaining a defensible EDR configuration.

Detection exclusions suppress alerts without disabling prevention. They are appropriate when a legitimate business process generates high volumes of known-good alerts that consume analyst time without security value. A vulnerability scanner that triggers LSASS access alerts, a backup agent that generates high-frequency file modification events, or an RMM tool that spawns PowerShell are candidates for detection exclusions. The exclusion should be scoped as narrowly as possible: exclude by specific ImageFilename and SHA256 hash combination, not by parent process name alone. Detection exclusions should be reviewed quarterly and removed when the underlying process changes or the business need no longer exists.

Prevention exclusions are a different category with higher risk. A prevention exclusion means the EDR will not block an action even if it matches a prevention rule. These are required when legitimate software triggers prevention rules that cannot be tuned around, such as a memory-scanning security tool that looks like credential dumping to the EDR. Prevention exclusions should require formal risk acceptance, a named approver, a defined review date, and a documented business justification. They should never be created by SOC analysts unilaterally. The approval workflow for prevention exclusions should involve both the security team and a risk owner from the business.

The most dangerous exclusion pattern is the overly broad process exclusion created under operational pressure during an incident. When a critical business application breaks because the EDR blocked a legitimate action, the fastest fix is to exclude the entire application directory from scanning. This creates a permanent blind spot that persists long after the original incident is forgotten. Instead, investigate the specific event that was blocked, scope the exclusion to that specific event type and binary hash, and document the exception in your exclusion registry. An exclusion registry that tracks every active exclusion with its owner, creation date, justification, and review date is not optional overhead: it is the control that prevents exclusion sprawl from undermining your entire EDR investment.

No detection rule should go to production without being validated to fire on the technique it is designed to detect. Atomic Red Team is the standard tool for this validation: it is an open-source library of small, modular tests mapped to MITRE ATT&CK techniques that execute the technique in a controlled, observable way. Each atomic test includes a description of what it does, the prerequisites to run it, the execution command, and cleanup instructions to reverse the changes made.

To validate a new custom IOA or STAR rule, execute the corresponding Atomic Red Team test in a lab endpoint enrolled in the same EDR policy as your production endpoints. Run the test and verify that the EDR generates an alert with the expected rule name and severity. Check that the process tree captured in the alert contains the expected parent-child relationship and command-line arguments. If the alert does not fire, check whether the rule is correctly deployed to the lab endpoint's policy, whether the regex pattern matches the actual command-line syntax used by the atomic test, and whether the test is generating the specific event type the rule queries. Iterate on the rule until it fires reliably.

Atomic Red Team also enables regression testing when you modify existing rules or update EDR agent versions. Before deploying a new agent version to production, run the full set of atomic tests for your covered techniques in the lab environment and confirm all rules continue to fire as expected. Agent updates occasionally change the event schema or behavioral detection logic in ways that silently break custom rules. A regression suite of atomic tests that runs before every major agent update is the operational control that catches these breaks before they reach production.

For techniques where Atomic Red Team does not have an existing test, write your own. Document the commands that exercise the technique, the expected EDR event type and field values, and the specific rule that should fire. This documentation serves both as a test artifact and as the specification for the detection rule itself, ensuring that the rule logic and the test logic remain synchronized as both evolve.

The process tree is the most valuable context element in an EDR alert. Where a standalone file hash or IP address tells you what happened at a single point in time, the process tree tells you how the attacker got there, what they did before the alerted event, and what they did after. Learning to read process trees fluently is the core skill of endpoint detection and response work.

In CrowdStrike, the process tree is displayed in the Incident Workbench and can be queried directly in Event Search using the ParentProcessId and ProcessId fields to reconstruct the full chain. In SentinelOne, Deep Visibility's Storyline feature renders the process tree as an interactive graph that includes file, registry, and network events alongside process creation events. Both representations reveal the same information: the ancestry of every process involved in the attack, the command-line arguments at each step, and the lateral extent of post-exploitation activity.

For custom detection rules, process tree analysis informs the parent-child relationship rules that catch post-exploitation behavior. A svchost.exe process spawning PowerShell, a browser process spawning cmd.exe, or a scheduled task host spawning a network enumeration tool are parent-child patterns that have no legitimate business explanation in most environments. Document the specific parent-child relationships you observe in your environment's legitimate activity before writing blocking rules to avoid false positives from unexpected but benign software behaviors.

Alert severity calibration is the connection between detection logic and SOC operations. Most EDR platforms allow custom rules to be assigned a severity level that determines how alerts are routed and prioritized. Align severity levels to your SOC's response SLAs: Critical severity should map to a 15-minute response requirement and should be reserved for rules with near-zero false positive rates and immediate breach indicators such as LSASS credential dumping or lateral movement using PsExec. High severity maps to a 1-hour response and covers high-confidence behavioral indicators like Office spawning command interpreters. Medium and Low severity cover technique coverage where false positives are expected and analyst triage determines whether action is required. Do not make every custom rule Critical: if everything is Critical, nothing is.

A detection engineering program without a structured backlog defaults to reactive rule writing after incidents, which means you are always detecting the last attack rather than preparing for the next one. Building and prioritizing a detection backlog requires combining threat intelligence, ATT&CK coverage gap analysis, and historical incident data into a ranked list of rules to write.

The inputs to backlog prioritization are: the ATT&CK Navigator coverage gap layer identifying techniques with no current coverage, threat intelligence reports identifying TTPs used by groups targeting your industry, incident retrospective findings identifying techniques observed in past incidents that were not detected in real time, and red team or penetration test findings identifying techniques that succeeded against your current detection capability. Score each potential detection rule by the product of its detection value (how impactful would catching this technique be?) and its urgency (how likely is this technique to be used against you in the next 90 days?). Build the backlog in a ticketing system with acceptance criteria: a rule is not complete until it passes an Atomic Red Team validation test.

Measure detection program performance using four metrics. Detection coverage percentage tracks the fraction of ATT&CK techniques in your priority matrix with validated coverage, and should increase over time as you work through the backlog. Mean time to detect measures the lag between an attacker action and the resulting alert in your SIEM, which should decrease as detection logic becomes more precise. False positive rate per rule identifies rules generating noise that distracts analysts, which should be minimized through exclusion tuning. Alert investigation rate measures what percentage of alerts are actually investigated by an analyst, which is the practical effectiveness ceiling of your detection program regardless of how good the rules are.

Performance impact of custom detection rules deserves specific attention in large environments. Each custom rule adds processing overhead to the EDR agent as it evaluates additional behavioral patterns against the event stream. In CrowdStrike, monitor Falcon Sensor CPU and memory utilization in your Falcon Management console after deploying new Custom IOA rule groups, particularly on endpoints with high process creation rates like build servers or developer workstations. SentinelOne's agent impact can be measured using endpoint performance telemetry in the management console. If custom rules cause measurable performance degradation, optimize the most expensive patterns first: broad regex patterns on high-frequency event types are the most common performance culprit, and tightening the initial filter before applying the regex can reduce processing overhead substantially.