Lessons from the South Carolina Debacle

Paul Rosenzweig by Paul Rosenzweig, The Chertoff Group
Tuesday, December 04, 2012

In October 2012 approximately 3.6 million Social Security numbers and 387,000 credit and debit card numbers belonging to South Carolina taxpayers were potentially exposed to exploitation by cyber attacks that penetrated the servers operated by the South Carolina Department of Revenue. The hacker also pilfered 3.3 million unencrypted bank account numbers and 5,000 additional expired credit card numbers. Reflecting the reality that government cloud servers are also the repository of the personal information of their own employees, the South Carolina breach exposed personally identifiable information of some 1.9 million dependents. In sort, anyone who filed a South Carolina tax return since 1998 or works for the Department of Revenue is potentially affected. In addition to the costs of mitigating the breach, the state will be on the financial hook to provide those affected with one year of credit monitoring and identity theft protection for free. Total cost to the South Carolina taxpayer -- $12 million, and counting.

The most notable aspect of this debacle is how readily it might have been avoided. And I’m not in the least suggesting that the intrusion could have been prevented. Far from it. Those who work in cybersecurity understand that breaches are, to a very real degree, impossible to prevent. And that means that governments who use cloud based systems for operations (or for that matter simple server based systems) need to anticipate that breaches will occur.

Sadly, South Carolina had not made adequate preparations. Preliminary analysis by an outside review suggests that the state failed to have adequate access controls, possessed limited intrusion detection capabilitites and may have been burdened with an out of date security architecture. In addition, the intial intrusion appears to have been the product of a rather typical spear phishing email, of the sort that government employees ought to be aware of.

But all of that pales in comparison the the most significant failure: None of the Social Security numbers in the South Carolina system were encrypted. Nor were the bank account numbers. Thankfully most (though not all) of the credit card numbers were encrypted – only 16,000 of those were not. But that simple expedient was neglected throughout much of South Carolina’s database.

Perhaps, however, we should not be so harsh in judging South Carolina. It’s failure to encrypt taxpayer data stored in its databases reflects the Federal government’s equal disregard for the protective cloak of encryption technology for data at rest.

Federal publication 1075 sets the standards to be used in protecting taxpayer data. And it carefully provides that any taxpayer data that is transmitted across the network needs to be encrypted. With equal fervor, the Federal rules require that all computers and mobile devices that are used at alternate sites – i.e. outside of the main offices – must contain encrypted taxpayer data, in case the computer or device is lost or stolen. And, finally, the Federal standards appropriately say that when users access a revenue department’s system from a remote location by creating a virtual network conneciton, that connection must, again, be encrypted from end-to-end.

All of which seems to miss the forest for the trees. We have rigid standards about remote access and requirements to protect taxpayer data as it moves in transit from one location to another. Likewise we protec data as it travels in remote devices. But there are no encryption requirements – none – for the core data held in a state of federal tax database. This information, typically contained in a private cloud of some sort, can meet Federal security standards even if it is stored in an unencrypted form.

This is a suboptimal way to protect data on server systems. Security experts have known for quite some time that large data sets are an easy target for an adversary to access and exploit on servers or in the cloud environment.

So why the hesitancy to use encryption? The challenge lies in doing encryption efficiently and in a way that is easy to use. The truth is that current encryption solutions aren’t scalable and don’t deploy effectively in typical use environments for large databases. To take one example, they make customer searches for data records difficulty indeed. In other words, encryption of data at rest is still hard to use for the average user.

So South Carolina really teaches us two inter-related lessons. The first is the current static perimeter security methods are inadequate. Relying on them is, as the South Carolina hack demonstrates, a formula for disaster. But South Carolina also reminds that research is urgently needed on encryption solutions that are scalable and capable of being widely deployed. Unite we find that sort of solution large public databases will continue to be an attractive target.

Paul Rosenzweig formerly served as Deputy Assistant Secretary for Policy at the Department of Homeland Security. He is currently a Senior Advisor to The Chertoff Group, a global security advisory firm which advises clients on cybersecurity including cloud computing.

More information

Post a comment

Sign in to comment.

Not yet registered? Join the debate