Tuesday, May 08, 2018

EDR Obviates Compliance

Okay, you'll have to excuse me for the title of this blog post...I needed something to get your attention, and get you to read this, because it's important. I know that stating that "EDR obviates compliance" is going to cause a swirl of emotions in anyone's mind, and my intention was to get you to read on and hear me out; 280 characters simply is not enough to share this line of reasoning.

GDPR is just around the corner, and article 4 of GDPR defines a "personal data breach as"...

...‘personal data breach’ means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed...

Something to be aware of is that this definition includes ransomware, as it includes "access to" and "alteration of". 

As security professionals have been saying for quite some time now, breaches of your perimeter are going to happen, it's simply inevitable.  However, per GDPR, it's not a reportable breach until something happens with respect to 'personal data'.  The simple fact is that without adequate/suitable instrumentation and visibility, you simply won't know if personal data has been accessed during a breach.  EDR provides that visibility.

Where Are We Now?
Right now, we're "right of breach".  Most organizations are simply unprepared for breaches to occur, and breach identification comes in the form of third-party external notification.  This notification comes weeks or even months after the initial intrusion occurred, during with time the dearth of instrumentation and "evidence decay" makes it nearly impossible to definitively determine what the adversary may have done, with any degree of certainty. 

The 2018 Nuix Black Report states that 98% of those surveyed stated that they could breach the perimeter of a target organization and exfil data in 15 hrs or less.  Compare that to the 2017 Ponemon Institute report that indicated that the 'dwell time' (the time between a breach actually occurring and it being detected) was 191 days, and it's still in the triple digits.  I hardly seems far, but that's reality in today's terms.

Where we need to be is "left of breach".  We know breaches are going to occur, and we know that clean up is going to be messy, so what we need to do is get ahead of the game and be prepared.  It's not unlike boxing...if you step into the ring with gloves on, you know you're going to get hit, so it behooves you to get your gloves up and move around a bit, lessening the impact and effect of your opponent's punches. In cybersecurity, we move "left of breach" by employing monitored EDR (MDR) so that breaches can be detected and responded to early in the adversary's attack cycle, allowing us to contain and eradicate the adversary before they're able to access "critical value data", of CVD.  CVD can consist of "personal data", or PII; credit card data, or PCI; healthcare data, or PHI; or it can be intellectual property, or IP.  Regardless of what your "CVD" is, the point is that you want to detect, respond to and stop the bad guy before they're able to access it, and the only way you can do that is to instrument your infrastructure for visibility.

Chris Pogue wrote this blog post, addressing the "cost of breach" topic, almost three years ago.  With the help of our wonderful marketing department, I recently gave this webinar on reducing costs associated with breaches.  Things haven't changed...breaches are becoming more expensive; more expensive to clean up, more expensive in terms of down-time and lapses in productivity, and more expensive in terms of legal fees and fines.

While researching information for the webinar, one of the things I ran across was the fines that would have been associated with GDPR, had GDPR been in effect at the time that the Equifax breach.  In 2016, Equifax reportedly earned $3.145B USD.  High end GDPR fines can be "20M euros or 4% of world-wide operating revenue, whichever is greater", bringing the fine to $125.8M USD.  That's just the GDPR fine; that does not include direct costs associated with the IR response and investigation, subsequent notification, nor any indirect costs.

On 1 May, Alabama became the 50th US state to enact a data breach notification law, SB 318.  As you read over the stipulations regarding reporting detailed in the law, keep in mind that for the 50 US states, everyone is different.  If you store or process the personal data for US citizens, the cost associated with simply determining to which states you actually have to report is enormous!  And that's before you even report...it doesn't include the actual cost of notification, it's just the cost of determining to whom (which states) you need to report!

So where does endpoint detection and response (EDR) come in?

I've been doing DFIR work for about two decades now, and most of the work I've done has been after an incident has occurred.  Early on, the work involved a system or two thought to be infected or compromised in some manner, but it was always well after the supposed infection or compromise occurred.  In most cases, questions involving things like, "...what data was taken?" simply could not be answered.  Either the information to answer the question didn't exist due to evidence decay, or it didn't exist because that information was was never actually recorded or logged.

EDR/MDR solutions allow you to detect a breach early in the adversary's attack cycle, as one of the things monitored by most, if not all, EDR tools is the processes executed on systems.  Yes, you get a lot of 'normal' user stuff (allowing you to detect fraud and insider threats), but you also get a detailed look at the adversary's activities.

To see some really good examples of process trees showing what various attacks look like, go to Phil Burdette's Twitter feedThis tweet includes an example of a phish, with the user clicking "Enable Content" on a malicious document, leading to the implant being downloaded via bitsadminThis tweet illustrates a great example of credential theft.  I could go on and on about this, but I think that the point has been made...EDR gives you a level of visibility that you don't get through any other instrumentation.

Where I've used this information to great effect was detecting an adversary's activities within a client's infrastructure several years ago; the tool being used at the time alerted on the use of an archive utility known as "Rar".  The adversary had renamed the executable so that it was no longer 'rar.exe', but adding a password to protect the archive is not something the adversary could change, and it's what was detected in this case.  So, we had the fact that data was marshaled and archived for exfiltration (along with the password), and we further was that after exfiltrating the archives, the adversary deleted the archived data.  However, once we got an image of the system we were able to carve unallocated space and recover a number of the archives, and using the adversary's password, we were able to open the recovered archives and see exactly what data was taken. 

Today, the way to address this behavior is that rather than alerting on the condition, instead, block the process itself.  And the same thing is true with other adversary behaviors; intelligence gives us excellent insight into adversary behaviors, and using these behaviors, we can implement our EDR solution to alert on some things, but if other specific conditions are met, prevent those actions from completing.  We can further isolate the adversary by isolating the system on the network.

In March of this year, the City of Atlanta was hit with Samsam ransomware.  Interestingly enough, Secureworks, a security MSSP located within the corporate limits of the city, has a good bit of documentation as to the methodology used by the adversary that deploys the ransomware; had the city had an EDR/MDR solution in place prior to the incident, they would've detected and been able to respond to the initial breach, before the adversary was able to deploy the ransomware. 

Given all this, the benefits of employing an EDR/MDR solution are:

1. The solution becomes part of your budget.  Employing an EDR/MDR solution is something you plan for, and include in your annual budget.  Breaches are rarely planned for.

2.  You now have definitive data illustrating the actions taken by an adversary prior to your containment and eradication procedures. You have a record of the commands they ran, the actions they took, and hence their behaviors.  You know exactly where they are within your infrastructure, and you can track back to how they got there, meaning that you can quickly contain and eradicate them.

3. Due to early detection and response, you now have definite data to support not having to report the breach.  Let's say that you detect someone on your network running the "whoami" command; this is a behavior that's been observed in many adversaries.  Alerting on this behavior will allow you to respond to the adversary during their initial recon phase, before they're able to perform credential theft, privilege escalation, and lateral movement.  All of their activity and behavior is recorded, and it's a short list because you've detected and responded to them very early in their attack cycle.  As 'personal data' was not accessed, you've obviated your need to report, and obviated costs associated with fines, notification, clean-up, etc.


Jared Greenhill said...

EDR adds huge visibility at the endpoint both in real time along with allowing a historical view (depending on the tool). I've also seen it start to replace full forensic investigations as many critical forensic artifacts can be either analyzed within the tool or retrieved and parsed offline. Examples include registry data at the system and user level (SYSTEM/SOFTWARE/NTUSER.DAT/USRCLASS.DAT, NTFS and NTFS journaling artifacts ($MFT/$USN/$I30).


Instrument EDR toolsets to save retrieved data using the EDR's API where available as storage varies by EDR solution.

Ingest EDR alerts and detections into a SEIM solution for tracking, metrics, visibility, alerting.

Considering deploying EDR widely as soon as possible. Network visibility/Full PCAP likely has a lot of SSL you may not have visibility into. It's also hard to tell where you have any visibility, better safe than sorry.

Harlan Carvey said...

Great stuff, Jared, I appreciate the comment!