Think About Survivability and Design Your Network for Resilience as Threats Change…
Suddenly, an early 90’s Jean Claude Van Damme movie is relevant again, at least due of its name. Every security team that can fog a mirror is asking the question “what just happened at Target, and how do we make sure that doesn’t happen to us?”. The objective, of course, is to be a “hard target” – that’s a great goal for any security practice (although in the real world, it doesn’t involve bumping off the bad guy at the end of the movie).
Of course, we don’t have enough precise technical detail about the attack to allow full reconstruction, not to mention deconstruction. There are some thumbnail sketches circulating – quite a few teams have been involved in the forensic postmortem, and as happens in the rest of the world, the more people who are involved, the more leaks there tend to be.
Still, the details are deliberately insufficient to precisely replay the blow by blow of the breach. (There are rumors of some folks being reprimanded for the level of detail that has already leaked out.) This makes it tough to answer a CEO when they say “how can you tell whether the same thing could happen to us?” Still, the recent Target data breach provides clear lessons. The media machine would love to report on this as if there were some Dr. No level evil genius with a new super-secret super-powerful attack, but as usual, the details don’t seem so very advanced. Avoiding being the next Target isn’t about stealth research labs of counter-evil-geniuses (and counter-counter-evil-geniuses, and so on); it’s more to do with effectively implementing the basics.
What did Target miss?
We may never know the specifics in full detail, but the part of the attack getting the most attention is the memory scraper malware, installed onto the Point-of-Sale (PoS) equipment. I think it’s a mistake to focus too much on this stage, though. It would be a mistake, for example, to say “we have no PoS devices in our business, so it can’t happen to us”, or for that matter, “we have that same brand of PoS, so we must equally vulnerable”. This is perhaps akin to assuming that all red cars are basically the same. (Almost all vertebrates on earth have bilateral symmetry with four limbs but only one head – this doesn’t make all animals the same either!)
What I find important about the breach is that compromise of the PoS devices wasn’t enough. This is a common, but often overlooked, factor in most of the major breaches in recent years – for the bad guy, getting in is only half the challenge. The exact inbound attack mechanism varies, but generally, it’s not too hard to get in – after all, their intended victims are all attached to the Internet. Targets can’t just disconnect – they need the connectivity to take in transactions, or to support their partners and suppliers. The complexity of the attack surface – the total diversity of the ways a modern business lets in traffic from the outside – is hard to map, and rife with mistakes. (Hint: automated measurement of the size of your attack surface can be quite enlightening – but as Alton Brown would say, that’s another show.)
Target is just the latest breach in a long series (including previous major examples like Heartland, and even back to TJX) where the bad guys found a way to inject a pretty basic, small fragment of code into their victim. OK, but what good is that? If I can run an arbitrary bit of code on your PoS device, does that mean “all your cards are belong to us”? No, it doesn’t – I still have to get the data back out to me! This return path is the weak link in the attack chain.
Try as you might, you can’t really reduce your effective surface for attacks coming in to zero, because your business needs to continue to operate – all those PoS devices were doing real work, in a busy season. Taking them down, even once Target knew there was a problem, was no simple thing to do. (Imagine the awful calculus – the moment you know your PoS devices are hosting carder malware, someone in your company is going to ask “well, given that the main damage is already done, how much more do we lose per additional card number?”, then compare that to the dollars per hour for these PoS devices as they ring, ring, ring the Christmas season along! Oy …)
The attackers didn’t just get their malware onto the PoS devices, then sit back and let the data flood in – it doesn’t work like that. The PoS devices are in PCI scope (meaning they fall under the regulations set by the Payment Card Industry), and one of the top Section 1 rules for devices that store credit cards is they must NEVER be able to talk directly to the Internet. This is a good rule, and from what we know of the attack, Target was following this for their PoS terminals. How do we know? Because the attackers had to compromise an additional server inside the organization! They needed to stockpile the data streaming off the PoS devices, and then figure out how to get that data out.
When you start to think this way, it becomes similar to building a maze – how hard can you make it for data to get out? Given that the attackers will always find a way to exploit your attack surface, and given that you can’t just unplug from the network, you have to think about this second half of the story – you may not be able to stop all malware getting in, but you can make it useless for the attacker to do this if you can make it hard enough to get the data out! At the end of the day, cybercrime is about economics – attackers look to turn a profit, and the more you can slow them down, the more disincentive they will have to come after you. As you slow them down with your outbound maze, you also rapidly increase your odds of being able to detect them – watching one exit out of a maze is far easier than watching an open field!
Unfortunately for Target, it seems their maze wasn’t all that difficult. If you only follow the most basic advice (as in the PCI requirements), you block outbound access from the most critical data stores in your environment. But all this does is put one wall between your attacker and the malware they’ve dropped on you – that’s not too hard to get around. All they need to do is find a server that can talk to your critical locations, and can also talk to the Internet. One guy standing to the side of the wall, who can see the crown jewels and the attacker, is all they have to find. So you need to take another step – look at the devices on your side that can reach the crown jewels, and ask “can any of these either lose their access to the crown jewels, or lose their (direct) access to the outside?” You may be surprised how often this can be answered, especially now that you can tell the Target story to make tangible the risks of a machine that can see both the critical stuff and the outside.
Of course, like real world maze design, the problem can recurse – if your maze has three turns in it, I can try to build one with four. Two bits of good news, though – one optimistic, the other a little cynical. Optimistically, automation is a great help here – computers are good at mazes, both at designing them, and assessing real world examples.
You really can use technology to assess your maze – to see how survivable it would be if someone did manage to sneak malware past your defenses (which you know they eventually will, no matter how many “zero day” magic bullet widgets you invest in). Then there’s the point that each additional level in your outbound defenses increases the costs of your attacker, and at least in principle you can increase them to the point that they won’t bother you. Cynically, though, you don’t need anything like that much complexity – you only need to be a harder target than the next organization.
Cyber criminals are lazy, but that just underlines why thinking about your maze is key. My advice, if you want to avoid being the next Target, is to identify your core assets – the stuff that matters the most to your business – and ask whether those assets can see the outside. If they can, why is that? Databases don’t need to surf, after all. If they can’t, good for you, but now, which locations of yours can reach them, and how many of them can get out? The more you pursue this discipline, the harder you make it for today’s cyber thieves to reap any benefit from getting their malware into your environment.
Chasing every latest news story about some new exploit variant is a waste of time and energy – far better to think about survivability, to design your network for resilience as threats change. And if it all sounds too advanced for the chaos you have to live with, let me say that in my experience, even the first level question – “what can the critical servers reach?” – is enough to promote a new, healthy, and significant discussion with the business. As one CISO I work with likes to say, “sunlight is the best disinfectant”!
Tweet
Dr. Mike Lloyd is Chief Technology Officer at RedSeal Networks. He has more than 25 years of experience in the modeling and control of fast-moving, complex systems. He has been granted 20 patents on security, network assessment, and dynamic network control. Before joining RedSeal, Dr. Lloyd was CTO at RouteScience Technologies (acquired by Avaya), where he pioneered self-optimizing networks. Lloyd was previously principal architect at Cisco on the technology used to overlay MPLS VPN services across service provider backbones. He joined Cisco through the acquisition of Netsys Technologies. He holds a degree in mathematics from Trinity College, Dublin, Ireland, and a PhD in stochastic epidemic modeling from Heriot-Watt University, Edinburgh, Scotland.Previous Columns by Dr. Mike Lloyd:How Difficult Is Your Maze? How To Be A Hard TargetHow Was Your Year In Security?What Is Good Enough Security?Big Data Security Analytics: Building The War RoomBig Problems In Big Data
sponsored links
Tags: INDUSTRY INSIGHTS
Network Security
Incident Management
Data Protection
Security Infrastructure
