Imagine you’re working in the IT security department and you’re just about to take your lunch when someone in accounting calls to say their computer is “acting strange.” That might sound like bad luck – lunch will have to wait – because you’re going to have to find out if this strangeness is a symptom of malicious code or some other form of attack that needs to be dealt with. But in a way, you’re also lucky – you’ve been alerted to a problem. Not all attacks raise red flags. That is where endpoint detection and response (EDR) comes into play.
D Is for Detection
In fact, even before you ask the user to explain what they mean by strange, your EDR console flashes a warning: someone just ran whoami.exe on a system that has no need to run it. You click for more detail. The console shows you that the offending machine is in accounting, and the offending process is Firefox executing operating system utilities with cmd.exe, generally not a good thing. What you have here is the D for detection in EDR, although it is only one of a myriad detection scenarios.
R Is for Response
Now you have a decision to make: kill this process tree and isolate the machine, or see where the unauthorized activity leads. Then your EDR indicates net.exe is being executed with these parameters:
net groups “domain admins” /domain
A prelude to a privilege escalation attack? You decide not to take chances and tell the EDR to shut it down. This is the R for response part of EDR, although you should probably take your response a lot further. For example, you might create a rule that automatically kills this behavior in the future.
Getting Clues from Endpoint Detection Response Consoles
You might also use your EDR console to look at the history of the machine in question to see how the intrusion began.
- What was the user doing?
- Did they ignore any warnings?
- Does this person have a history of clicking on email attachments?
- Should they be referred to HR for remedial anti-phishing training?
Another question you might want to research is: why did the endpoint protection (EPP) on that system in accounting not block this in the first place? Which brings us to one of the biggest challenges in cybersecurity: understanding the shifting definitions of product categories.
Is Endpoint Detection and Response Right for You?
If you were advising clients about cybersecurity 15 years ago, you probably told them they needed antivirus, even though that term was already becoming a misnomer – a lot of malicious code in this century has not been viral, and the term malware makes more sense as a threat category. As antivirus vendors started to rebrand products to antimalware, they also added protection mechanisms beyond scanning incoming code, like detecting and blocking malicious URLs, phishing emails and suspicious system behavior. Basically, these products were providing multiple layers of defense to protect the endpoint, in other words endpoint protection.
Yet some attackers were still beating that protection – which can be undermined by poor management and poorly trained users – hence the need to detect attacks in progress and respond to them. There are now dozens of vendors in this space offering EDR alone, EDR combined with EPP or EDR as a service. But is endpoint detection and response right for your organization?
Unless you are completely outsourcing your cybersecurity – which can be a viable option – you need a certain amount of in-house talent to make an investment in EDR worthwhile. This implies there might be a minimum network size below which EDR is viable, but I hesitate to specify one due to variables like the sensitivity of the data you are protecting and the emergence of new products in this space.
What I can say is that the installation, calibration and management of an EDR is – almost of necessity – a bigger lift than an EPP install. After all, the goal is to obtain highly granular visibility into activity on all your endpoints and distinguish between legitimate and malicious behavior so that the latter is detected and you have the means to respond very quickly, and effectively when it is. Furthermore, you want the EDR to learn over time and from external inputs such as indicators of compromise (IOCs) and other forms of threat intelligence.
Endpoint Detection and Response vs. Endpoint Protection
While automation within EDR products is bound to improve over time, it is likely that some human threat hunters and incident responders will still be needed. Given that appropriately skilled humans are expensive, and budgets are seldom unlimited, you might be wondering if you can – or should – replace your EPP with an EDR.
While vendors may vary in their views on this, it is important to bear in mind that a good EPP can – quietly and with little attention or overhead – detect and block a very high percentage of malicious code attacks, network exploits, ransomware and phishing campaigns. (For example, some EPP products protected customers against the EternalBlue exploit well before WannaCry burst onto the scene.)
So, is it time to protect your endpoints with detection and recovery? The answer is clearly yes. Unless you are a small organization that doesn’t handle sensitive data, you should be looking to have EDR capability. You can use in-house tools and talent, buy EDR as a security service or invest in a full-blown EDR product. The reality is that attackers show no signs of giving up, and the number of vulnerabilities they can exploit is not going down. Furthermore, not all attacks raise red flags, and you need to be looking for attackers even when there are no obvious signs they have compromised your endpoints.
Stephen Cobb is a senior security researcher at ESET and will present at ChannelCon 2018 in Washington, D.C. His session, Endpoint Detection and Response: the Next Frontier of Security, has been approved for continuing education units to renew CompTIA A+, CompTIA Network+, CompTIA Cloud+, CompTIA Security+, CompTIA Cybersecurity Analyst and CompTIA Advanced Security Practitioner.
