Blog post

Using EDR For Remediation?

By Anton Chuvakin | March 11, 2016 | 9 Comments


“Do you believe in bible? – Totally, man, I’ve seen one!”

OK, do you believe in APT automatic remediation? In fact, have you seen one done successfully? BTW, here we define “remediation” as “putting it the way it was.”

My point is that automated remediation of compromised systems – however much desired – is also generally hopeless, especially in cases of real APT malware. Even with well-designed kernel-level EDR that records “everything” [or: the one uses fancy VM introspection approaches], making sure – and I mean 100.0% sure – that all the traces of the attacker or its creation [malware] are found and cleaned is impossible. Sure, the anti-virus guys can remediate commodity malware with decent certainty, but even there success is often incomplete or not assured…

Frankly, “APT remediation” is nuking it from orbit aka disk reimaging. In fact, given firmware persistence mechanisms, maybe this would be the only truly reliable “remediation” tool:

img src: CC license

The practical conclusion of this, if you are getting EDR, don’t insist too hard on remediation features, you either won’t use them much or you won’t trust them….

Related blog posts on EDR:

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • Matthew Gardiner says:

    Frankly if you can get detect & investigate (as in full understanding) right with a true “APT” you have solved 99% of the problem. Automated remediation is for commodity attacks.

    • >Automated remediation is for commodity attacks.

      100%, exactly, absolutely our view 🙂

    • Dori Fisher says:

      As with young children who cannot identify the intimate couple in a picture because they do not have prior memory associated with such a scenario, SOC personal have the same issue with understanding what they are seeing (APT) even after getting an alert something is wrong. Like looking hard at petri dish when you do not have the relevant experience and / or credentials.

  • Paul Stamp says:

    NIST talks about remediation as containment, eradication & recovery. EDR can help with containment, and has some role in helping with eradication, but recovery? I think not.

    EDR has a role, but any vendor that says its tool “will remediate your APT” is being utterly disingenuous.

    In the security market as a whole though, it’s difficult to have a nuanced, accurate position that folks will understand and differentiate from the wild claims.

  • Scott Gainey says:

    Sorry, I don’t agree. I do believe it’s possible to fully remediate a machine without having to a painful reimaging. We do this today on Windows. I’m going to set up a briefing with you so we can show you how it works on SentinelOne.

    • OK, so you think it is possible to record everything [and I do mean *EVERYTHING*] dangerous that the attacker may have done to the machine, including what implications his/her manipulation of [say] raw memory have cause. But HOW do you plan to do that?!

  • Paul Stamp says:

    Sure. If you narrow the definition of “remediation” and “APT” enough you could make that argument.

    In reality though, remediation goes way beyond anything to do with an endpoint – particularly if the attacker has legitimate credentials.

    We would be l doing a disservice to customers by mis-setting expectations.

    • Exactly – in this post I am am taking a more narrow view of remediation [put the endpoint to a KNOWN safe state]. Not ‘likely safe’, not safer, but KNOWN SAFE.