Are Data Breaches Preventable?
When it comes to data breaches, 2014 was a difficult year for the U.S. retail industry. The FBI warned of this a year ago in the wake of the Target and Neiman Marcus data breaches. The increasing concern in both the industry and government was justified, as we saw many high profile attacks. Beginning with Target, there were data breaches at at least 9 prominent national brands, over half of them linked to malware installed on Point of Sale (POS) terminals.
It is interesting that although analysis of network traffic is an important part of detecting the activity of malware, as demonstrated by systems such as FireEye and NetWitness, I haven’t seen much play given to the role that network security, in particular network segmentation, should be playing in preventing data breaches and mitigating their severity.
Preventing Data Breaches With Least Privilege
An important security principle is called Least Privilege, which means that users (or processes) should be given all of the rights needed to do their jobs and no more. While we usually think of least privilege in terms of application and data entitlements, you should apply it to network connections as well. Give then pivotal role that POS terminals have played in the big retail data breaches, let’s apply least privilege to the network activity of a POS terminal: a POS terminal should have all of the network access required to perform its function and no more. That means that the only inbound connections that should be permitted are authenticated connections from the systems that manage the terminal, and only on the ports required for management. The only outbound connections that should be permitted are to the specific services required to process transactions.
The best way to enforce network least privilege in this case is to put the terminals on an isolated network protected by a firewall. Only the connections required by least privilege should be permitted to traverse the firewall. Obviously there should be no way for these systems interact with external networks. Software updates need to be distributed from internal servers only, and digitally signed whenever possible.
Note that this also applies to the servers that support the POS terminals. All payment processing and all persistent data stores holding payment card or customer information should be on networks protected by firewall rules that apply least privilege. So just as the POS terminal needs to connect through its firewall to process payment, the firewall around the payment systems will need to let in connections from the POS terminal to processing services.
This prescription is not lightweight. It adds internal firewalls to the infrastructure, and complexity to the design of any system that uses sensitive data. But economic impact of large data breaches can be overwhelming, wiping out months of profits and ending C-suite careers. Investment in prevention is money well spent.
I’m of the strong opinion that many breaches could have been prevented by proper network segmentation. Probably had the POS terminals been isolated they never would have been breached in the first place, but even had they been breached their data could not have been exfiltrated without first compromising the systems that support the terminals. And those would have also been protected by enhanced network security.
Obviously there are complexities. One of the breached brands was a national restaurant chain. Managing firewalls around a few POS terminals and a local server in each restaurant is not a zero burden. It’s a different problem than segmenting the network of a big box store full of registers. However even for the small-branch problem, virtual LANs (VLANs) and Virtual Private Networks (VPNs) provide the means to virtually segment the network and lock down access to both the POS terminals and any local supporting servers.
Let’s not oversimplify, though. Data breaches are not just about network security. Almost every data breach starts with compromised account credentials, usually obtained by good social engineering, such as spear-phishing. As we discussed in an earlier post, the Varonis-Ponemon study showed that most enterprises give employees way more data access than they need to do their jobs, which increases the value of any single compromised account. So a combination of social engineering, loose data access controls, and loose network access controls grants intruders a wide range of access on a compromised network.
In one of the highest profiles cases, the initial compromise wasn’t even at the retailer. One of their suppliers was hacked and the intruders got the contractor’s credentials for logging into the retailer’s vendor portal (for functions such as invoicing). That web server was vulnerable to attack, and had good enough connectivity to the rest of their network that they were able to start their reconnaissance (including obtaining domain admin credentials) from there. Proper network segmentation would have done a lot to limit the damage from the breached web servers. That server should not have been able to reach anything not related to its function. Arguably, it should not have been joined to the same domain as internal systems, either. Together closing those two holes would have made this a minor event.
Other industries have been hit with high profile breaches as well, such as entertainment, finance, and healthcare. In the ones where we know the cause, there is a common pattern of an initial compromise being exacerbated by a failure to enforce least privilege on data access, network access, or both.
For all the differences from case to case, these breaches have a depressing sameness about them.” Steve Bellovin notes:
One reason that airplanes are so safe is that crashes are investigated by government agencies, the results are published, and the lessons from one crash go into future airplane design, pilot training, and technology to prevent another. There’s nothing like that in the computer world, which is one reason why we see the same failures over and over again.
Steve suggests that we start treating cyber incidents the same way, with a governmental Major Cyberincident Investigations Board, which would be mandated to investigate major incidents and publish their findings. He notes that the combination of independence and transparency would allow the industry to actually learn why bad things happen, and change in response. Perhaps we can stop having (in the words of Yogi Berra) “déjà vu all over again.”
For a while I worked as a security architect at a bank headquartered in a country with strong bank secrecy laws. Because this was taken quite seriously, we had a network segmentation architecture that was a wonder to behold. At the time I thought it was too complex and put a lot of burdens on application design. After the past few years of data breaches, I’m not so sure. As in all such friendly disagreements, the truth likely lies between us. But I suspect that my former colleagues were closer to it than I was.
Restricting access to the network (and to data) is difficult and painful, but can go a long way to preventing data breaches or keeping their scope small. We need to stop considering it optional.