On the heels of my previous post on the topic, from my perspective, there still seems to be something of a misconception within the market as a whole as to the value of EDR/MDR.
During conversations on the EDR/MDR topic, one of the questions we hear quite often is, "Do you detect X?", with "X" being some newly-identified virus or exploit. I think that the reason we hear this question so often is that EDR/MDR is still somewhat new in the minds of the marketplace, and most organizations are still trying to visualize and really understand the concept, and how it applies to them. The way we most often go about doing that sort of thing is by finding something we're familiar with, and start by building a comparison relationship there. Unfortunately, starting with AV as the comparison doesn't really get us to where we need to be, in part because this is a whole new way of looking at things.
And believe me, I do understand how difficult it is in today's marketplace to really understand what's out there. A while back, I was in a sales presentation, and a sales rep was going through the slide pack they'd been provided by marketing; at one point, the client just came right out and said, "...yes, everyone says that, every other vendor we've spoken to has said the same exact thing. How are you different?" They were asking this question because they were trying to get beyond the initial fluff and down to, okay, how is this vendor's product better for us and our needs? Now, the folks we were talking to were actually very mature, in the sense that they had already identified their EDR needs, and actually had been working with an EDR product with a subset of their infrastructure, so they were essentially trying to make an apples-to-apples comparison of products.
As recently as last week, I was encouraged via a marketing email to sign up for a webinar, and one of the inducement statements in the corresponding blog post (linked in the email) was along the lines of, "...you should be detecting ransomware the moment it reaches out to the C2 server."
Hhhhmmm...but what if we could detect the issue before that point? What if you could detect the initial behaviors that lead to a malware infection, and block the activity at that point, rather than waiting to try to detect the malware itself? If we focused our efforts earlier in the attack cycle, we could impose greater pain on the attacker, raising the level of effort required on their part, and forcing them to change their tactics.
So what do I mean by this? Every day, thousands (millions?) of employees log into their corporate computer systems, launch Outlook, and read their email. Part of this may involve opening attachments, including MSWord documents and Excel spreadsheets. As such, it's normal and expected to see a process tree that goes from the user logging in (Windows Explorer), to launching Outlook, and then Outlook includes whichever attachment is opened as a child process. It looks something like this:
explorer.exe
|__Outlook.exe
|__winword.exe
Now, when a user is sent a phishing email with a weaponized attachment, the user may be prompted to click the "Enable Content" button in MSWord in order to allow any embedded macros to run; once this happens, we generally see something like the command prompt (cmd.exe), or something else (PowerShell, etc.) running as a child process of MSWord. This is ( a ) never a good thing, ( b ) easy to detect, and ( c ) equally trivial to block. Here's what that might look like:
explorer.exe
|__Outlook.exe
|__winword.exe
|__cmd.exe /c powershell.exe...
|__powershell.exe...
Here's a good example, shared by Phil Burdette some time ago, albeit without the Outlook component.
The point is that this behavior can be detected and alerted on, and then action can be take at the point where winword.exe spawns a command shell as a subprocess. As such, if we're blocking processes from executing at that point, then we're not even getting to the point where PowerShell or WScript or BITSAdmin or whatever is used to download the malicious stuff to the compromised system. With the right instrumentation, you may also be able to isolate the system on the network after having blocked the malicious behavior. That way, instead of sending someone a ticket telling them that they have to respond, and them getting it at some point in the future (even as much as a few minutes is enough for the adversary to burrow their way into your infrastructure), all access is immediately disabled.
This is where MDR solutions come into play. With the right endpoint technology in place, an MDR not only monitors what's going on, but is able to take threat intelligence developed from monitoring their entire client base, and apply is across all monitored clients. This means that every client benefits from what was gleaned and developed from any one client, and they benefit immediately.
What this ultimately leads to is much earlier detection of malicious activity, and a much quicker response to that activity, such that reporting is obviated. After all, if you're able to detect and respond to an adversary much earlier in their attack cycle, and you're able to cycle through the OODA loop faster than the adversary, then you're able to prevent access to any "sensitive data". If that sensitive data isn't accessed, then you don't have to report. Also, you've got a record of activity that demonstrates that you were able to respond to, contain, and eradicate the adversary.
No comments:
Post a Comment