Saturday, March 29, 2014

Analyzing the Target Breach "Kill Chain Analysis" Report

-- If you haven't read it yet, the document "A "Kill Chain" Analysis of the 2014 Target Data Breach" is a must read for anyone in the role of enterprise [cyber] defense.

I've been studying recent breaches through the looking glass of the "Lockheed Martin Kill Chain". If you'd like a primer on the importance and background of the kill chain methodology you should read Rodrigo Bijou's fantastic analysis. The LM kill chain methodology for examination and defense from an attack is actually quite brilliant. It's not necessarily revolutionary - but enterprise security professionals now have a structured and documented way of trying to thwart attackers, and learn from breaches. So it's fair to say that this is something everyone in defense (and oddly enough, offense) should know like the back of their hand.



Chairman Rockefeller of the Committee on Commerce, Science and Transportation commissioned this report to better help Senators, and laymen, better understand what exactly happened at Target - and how the attack could have possibly been thwarted against the backdrop of the Kill Chain. I've read and re-read this document a few times and here are my notes. I'm also posting a link to a grab the PDF with my highlights (my copy has highlights and notes in the left margin starting on page 7, you may have to actually download it to see the highlights).

  • WR-1, WR-2 - This highlight is interesting, for me, in part because of the social engineering aspect. Many vendors (just look at your favorite security vendor website) tout their high-profile clients on their websites (sometimes without actually getting permission!) and like Target some enterprises disclose the vendors and various other 3rd parties that work with them - for example their audit firms. This is a big deal because we now know as a fact that 3rd parties are often the avenue into even the most sensitive networks. If you've done a good job with your network perimeter security, the attacker only has to find one of your vendors who has a drop "behind the firewall" and they're in. Often times these 3rd parties have little to know security of their own so owning them is, sadly, trivial. I'm not commenting on Fazio Mechanical Services' security - because I know nothing about them - but I'm willing to bet they don't have a large, full-time security organization and great awareness programs to keep their employees from clicking on links and downloading random PDFs from Nigerian Princes ...I'd be thrilled to be wrong. This isn't a commentary on that specific vendor - but on all 3rd parties which don't have security as a core requirement (at least until now?) of their business.
    Fallout: Enterprises will be even more paranoid about sharing who they do business with and who they give access to their networks. Also - and this is even more likely - there will be a mad rush to audit all of the 3rd party vendors and providers who have access or do business with the company. What you're likely to see is a phenomenal uptick in 3rd party security assessments and organizations who do this sort of thing will have more work than they can handle for the next 2-3 years. The sad thing is most enterprises have somewhere around 10x the 3rd parties - which have access to their network in some fashion - than they can possibly audit in the course of a year. This does not bode well for enterprises which have failed to do proper network segmentation, separating their internal network from 3rd parties (semi-trusted) in a DMZ of some kind. There will likely be a mad rush to re-engineer many enterprise networks to remove as much 3rd party access, or at least restrict it, as possible. Also, you're about to see a major re-write in social media policies for many enterprises, attempting to limit what employees can disclose and share about the companies they work for.
    Watch this space, 3rd party and vendor access is going to be the talk of security for a while.
  • WR-3: Is anyone really surprised that Fazio used a free, non-commercial version of a basic anti-malware tool? They're a mechanical services company, they probably have "an IT guy" that's a part-timer who manages their outdated, unpatched, and poorly secured computers at the office. Yes, it's poor form to use a non-commercial product in a commercial setting - and I'm sure they'll rectify that - but I'm willing to bet that companies that fit Fazio Mechanical's profile all have similar issues.
    Fallout: Various companies fitting that "industrial services" profile who would never otherwise give security a second though are going to be saddled, like it or not, with new requirements with a heavy focus on security come contract renewal time. Prepare for audits!
  • WR-4: I won't comment much beyond what I already said in WR-3, except to say that if companies like RSA who make security their business have employees who can be tricked into opening malicious links and payloads - industrial services" companies like Fazio Mechanical have absolutely no prayer of thwarting a social engineering attack.
    Fallout: "Train everyone" will be the battle cry as part of the new security requirements (see above) - this will last as long as it's on the forefront of everyone's mind which should be 1-2 months then fade away until it becomes an issue again. How fitting.
  • WR-5: Two-factor authentication for external access, while no longer requiring an actual rocket scientist, is still not trivial. Nor is two-factor authentication, done right, cheap. I see a few different problems here with this bit of the paper. First and foremost this was likely an exercise in 'scope reduction' for the PCI-DSS audit. Like organizations I've been a part of in the past which needed to be PCI-DSS compliant  (and knew it was going to be a monumental effort) there was clearly a conscious effort here at Target to reduce scope down to the systems and networks that directly interacted with cardholder data. The Ariba system (which is a spend management system for thing like generating POs and purchasing) was probably removed from scope for the PCI-DSS audit (thereby skirting the two-factor requirement there) and probably not seen as high risk enough to require two-factor authentication otherwise. So there it was, a username and password to get into their Ariba system... actually I've used the Ariba system a number of times at different companies and it's typically a browser-based app over https... so there should have been a single port from a range of IPs to a single (or range of) IP addresses like so: src [vendor IPs or vendor network] --> tcp/443 allow --> [Ariba system]. this probably wasn't the case here - so there was clearly a firewall policy and network segmentation failure. The two-factor authentication, I believe, in this case may be a bit of a red herring...
    Fallout: Fire up the sales folks who are selling two-factor authentication... 
  • WR-6: Hold the phone. Somehow having a 3rd party vendor's credentials gave the attacker rights to upload code to the PoS systems?! There is either a massive, gaping hole in this story or this is the world's loosest system configuration. Stealing Fazio's credentials to access the Ariba system, heck even if there was a VPN involved, shouldn't get you anywhere near the access required to upload code onto PoS systems. Of course, unless these PoS systems were on a non-segmented network, with wide-open access. IF this is the case, there should be hell to pay as that would be an unforgivable sin. I suspect it's not quite this simple, and there is more to the story we simply don't know, at least for now that's what I'm going to tell myself.
    Fallout: Rampant, uninformed speculation until someone actually (if ever) comes out with the real whole truth.
  • WR-7: This, ladies and gentlemen, is a catastrophic failure in operational security. Sadly, and without being overly dramatic, this is probably "as good as it gets" across much of the enterprise space from the retail vertical, to industrial and manufacturing, to medical and pharma ... detection of malice on our networks is something we (collectively as security professionals) are abysmal at. There's a reason many of the breaches that have been exposed in the last year or so have gone undetected - some for years - and that is because we have failed the enterprise. We continue to spend money on prevention and completely forget (or willfully ignore?) the what-if scenario where the attacker is inside our network rooting around and we need to find them quickly. I'm disappointed, but not necessarily with Target (ok, not just with Target) at the collective abilities of enterprise security professionals for detecting malicious activity on our networks and infrastructures. We depend heavily, almost exclusively in many, many cases, on pattern-matching IPSes and such. Things that don't match patterns may as well be invisible. This is unforgivable as well.
    It's time to get over ourselves, and adjust strategies - right now. We will be breached, all of us at some point, and the only thing that matters at that time is how quickly we can detect and shut down the breach... all the prevention in the world is worth crap if you don't have a what-then strategy.
    Fallout: Maybe, finally, enterprise security organizations will start to give detection, response and resolution of malicious activity on their networks the time and resources they deserve. I'm not saying abandon prevention, just ... stop giving it 100% of your resources and focus proportionately on detection and response for the next decade or so. I'm probably wishful thinking again though.
  • WR-8: One of two things happened here to allow C&C activity to go right out to the Internet. Either a) the attacker found a way out to the Internet Target's enterprise security organization didn't know about, or b) Target's enterprise security organization isn't egress filtering. In the year 2014, I'd like to believe (a) is more likely, but I wouldn't be my paycheck in a company the size and complexity of Target. It's easy to say do egress filtering but to actually do it, 100% of the time on 100% of the ingress/egress points is - quite frankly - operationally difficult.
    Fallout: If your enterprise doesn't already have a firewall audit tool, now is the time to get one and use it...extensively. Also, maybe it's time to review your Internet access strategy and architecture? Maybe audit every once in a while to make sure one of your satellite offices, or some rogue business leader hasn't gotten a DSL connection running into his office. Most importantly - egress filter as if it was a matter of life and death. Seriously.
  • WR-9: I read this, thought to myself - "Yup, absolutely" ... then read it again and laughed out loud. The reason I'm laughing out loud is two-fold. While there are literally gobs of tools which will readily profile a user ID for you, and tell you when that user is doing something out of the ordinary this is operationally difficult, and probably pretty expensive. Also, this requires you to profile your users, and actually do role-based access, with concepts like least-privilege ... you're doing all those, right? Not.
    Fallout: I'd love to think that one day every enterprise will have a baseline profile for its network traffic and users. That day is not today. I don't even see that day on the near horizon. Nice thought though... and if you've got some cash and a few enterprise security people sitting around doing nothing it would be  fantastic project to embark on right now.
  • WR-10: So ... NGFW is a thing, since about ... 2008?. Also, firewalls. I don't feel the need to flog this corpse of a horse, right?
    Fallout: I suspect nothing changes. Most of you out there probably don't even have an up-to-date and accurate network map, much less well-defined egress perimeters and layered filtering.
  • WR-11: My head exploded right here. Somehow the attackers were able to FTP out to the Internet, to a dump servers. Who uses FTP still? And for those still forced to use FTP, please tell me you don't have an "ANY/FTP > ANY" rule in place on your egress firewalls. Come on, this is not advanced security people, this is remedial stuff they teach you on day 1 of network engineering. Ancient old protocols, when you have to use them - and I know many enterprises are stuck using them - need to be heavily source/destination filtered. Absolutely ridiculous...
    Fallout: Firewall audits. Again, audit every rule, make sure you've locked down your egress from your network and that packets can't just leak out ... this stops many of these threats and forces them to get more creative.
So all-in-all an interesting document and analysis from the Kill Chain perspective. Sadly there are 3 lessons to take away from this mess:

  1. Target, much like countless other enterprises out there, failed at doing the basics of good network and security hygiene. Egress filtering, network segmentation, least-privilege - these are all fundamentals boys and girls ... and you're still doing them wrong.
  2. No matter how much cool technology you have (Target had Fireeye!) it won't save you if you've completely failed to operationalize it. The box won't save you. Buying the thing, installing, and turning it on is only the very beginning of how a security technology provides value. Getting value means operationalizing the kit - building workstreams, competencies, and learning to maintain properly. 
  3. Detect. Respond. Resolve. If you're still focusing your resources and spending on prevention you're ... how do I put this delicately ... screwed. Please consider that the attacker will thwart (typically while laughing at you) your advanced prevention strategies as they send an email to your CEO with their foothold malware attached, and he/she readily opens it forgetting all training and common sense because it's a picture of a dancing monkey. Think beyond prevention and ask yourself if you've properly prepared your organization for the what-then.

Whew! Sorry this post is so long - but there's a lot to talk about. Sadly, and I feel like I'm a broken record here, it's the same old operational and basic failures over, and over, and over, and over, and over and ...

I welcome your comments, questions, and further analysis. Also snark, I love snark.

No comments:

Google+