Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.

In this edition of the security automation blog, I’m going to dive deeper into EDR use cases for automation. Honestly, EDR is one of the top areas where automation can make or break your day in SecOps. It sounds easy enough, detect suspicious activity on endpoints and respond. But as many of us know, it can get complicated real fast, especially if you have to juggle alerts from a hundred different laptops, smartphones, or random servers in the basement that nobody admits to owning.

Table of Contents

• Which endpoints generate these alerts?

  • What Automations Are We Talking About?

• Step 1: Enrichment

• Step 2: Answer the Big Questions

• Step 3: Investigation Phase - Threat Analysis

• Step 4: Containment & Eradication

• Step 5: Recovery

• Step 6: Lessons Learned

• Closing Thoughts

This edition is sponsored by Intezer

Which endpoints generate these alerts?

Most of the time, we’re dealing with three environments:

• End-Users (laptops, desktops): So many browser tabs and random software, makes it tough to get a baseline.

• Mobile Devices (smartphones, tablets): People underestimate mobile all the time, but it’s basically your entire personal life on a tiny slab of glass.

• Servers (on-prem or cloud): Generally easier to baseline than user endpoints, but can still get wild if folks install unapproved apps or forget to patch.

End-user devices can be especially noisy in EDR, simply because of how unpredictable they are. Servers, theoretically, should be simpler, less browsing, fewer random apps. But let’s be honest: “should be simpler” doesn’t always mean they are.

What Automations Are We Talking About?

Now, the main thing I want to share is the type of automations you’d typically build around EDR alerts. I’ve seen quite a few approaches, and I’d love to hear from the community on what you guys are doing or planning. For now, let’s use the SecOps process blueprint I mentioned a while back. It’s a good way to structure how we handle EDR alerts, from start to finish.

Step 1: Enrichment

Some EDR solutions provide a decent amount of context by default. But if they don’t, or if you just want more, this is where you plug in other data sources.

1. Internal Enrichment

   Check if the same file or process was seen on other devices.

   Maybe run a historical search to see if it’s brand new or has been around for weeks.

   Find out which machines it communicated with, or if it was downloaded from some shady IP address.

2. External Enrichment

   Detonate the file in a sandbox and observe what it does, static and dynamic analysis can reveal if it’s trying to escalate privileges or phone home.

   Pull related threat intel: Is it a known malware family, or something brand-new out of a fancy APT playbook?

By automating these lookups, you save a ton of time. No more juggling eight browser tabs or bugging your buddy on the threat intel team for the hundredth time that day.

Step 2: Answer the Big Questions

Once you’ve got that enriched data, you want to build an automation that helps you answer the following questions :

• Who is involved?

  Are we dealing with a laptop, a server, or a mobile device? Which user account triggered the alert? Was it an admin account or a regular user?

• Where is the activity originating from?

  Is it happening on-prem or in the cloud? Maybe it’s an Infrastructure as Code environment? For a server, you might also review related change requests. For an endpoint, check the device’s posture or trust level.

• When did this happen?

  Is it new, or has it been going on for a while? Comparing alert timestamps against historical data is crucial in spotting weird patterns.

• What was executed?

  What commands or code got run, and which processes or communications were started? This is where correlation across other alerts or logs can paint a bigger picture.

Basically, automating these checks turns “chasing random alerts” into “smart triage.” You quickly figure out if it’s a false positive, or if it’s the beginning of your worst nightmare.

Step 3: Investigation Phase - Threat Analysis

If your automation confirms it’s not just Bob from Accounting playing with PowerShell, then it’s time to really dig in:

• What is happening?

  Are we looking at resource misuse (like cryptominers)?

  Is it a compromised account?

  Maybe an attacker is trying to pivot laterally to a more valuable server?

• Why is it occurring?

  Weak or stolen credentials?

  Or an advanced threat group trying to exfiltrate your crown jewels?

During deeper investigation, you’ll likely gather logs from all over the place, system logs, network logs, application logs, plus memory dumps and file samples if needed. This can be super time-consuming, so the more automation you build for collecting, preserving, and analyzing these logs, the better.

• Blast Radius Determination: Check other systems and accounts for similar indicators.

• Timeline Analysis: Reconstruct the sequence of events to see how the attack started and whether it’s still ongoing.

Sometimes you’ll find out it was just a false positive. But this is also where you might discover bigger issues, like missing logs that could’ve helped you catch the attacker earlier.

Step 4: Containment & Eradication

Alright, so you’ve confirmed it’s something bad. Now you need to stop it from spreading and eradicate it from your environment. Often these steps happen at the same time because you want to move fast:

• Containment

  • Block known Indicators of Compromise (IPs, domains, file hashes) in your firewall, proxy, or EDR tool.

  • Isolate the infected machines from the network.

  • Disable any compromised accounts.

• Eradication

  • Remove malicious files, scripts, or artifacts.

  • Revoke or reset credentials.

  • Double-check you haven’t missed any sneaky backdoors.

Step 5: Recovery

Once the threat is gone, it’s time to bring everything back online and maybe fix a bunch of stuff while you’re at it.

• System Recovery

  • Restore from clean backups.

  • Rebuild servers or endpoints if they’re too compromised.

• Vulnerability Patching

  • Apply all relevant patches and update configurations.

  • Harden any weak areas, like enabling MFA, rotating keys, and so on.

• Data & Compliance

  • If sensitive data was touched, consider encryption or stricter access controls going forward.

  • Document everything for compliance and continuous improvement.

Automation here helps ensure consistency, like rolling out patches to all affected systems or automatically generating reports for audits.

Step 6: Lessons Learned

After the dust settles, it’s time for a proper debrief. This is where you take what you learned and feed it back into your security strategy:

• Root Cause Analysis: Figure out exactly how the threat got in and why.

• Update Threat Intel: Add any new IOCs or patterns to your detection rules.

• Improve Detections: Fine-tune your EDR alerts so next time you spot the threat faster (and reduce false positives).

• Add New Log Sources or Tools: If you realized a gap, like missing cloud logs or memory analysis capabilities, now’s the time to fix that.

• Playbook Enhancements: Adjust your automation workflows and operating procedures. Maybe you need a better escalation process or a more thorough triage step.

Closing Thoughts

EDR automation is both simple and complicated at the same time (I know, that sounds contradictory). On one hand, you can create pretty straightforward playbooks that gather context and quarantine a device. On the other hand, analyzing endpoints, especially end-user laptops, can be messy. That’s why it’s so important to have these processes outlined and automated as much as possible.

I hope this breakdown gave you some ideas. Feel free to share in the comments if you have your own EDR automation best practices, or if you’ve tried something that totally flopped (we’ve all been there!). The more we learn from each other, the better prepared we’ll be for the next wave of suspicious alerts that come our way.