By Jeff Gould
Utah’s Governor has just fired the state’s CIO over a data breach that let foreign hackers steal the social security numbers of 280,000 state residents. Why did this unfortunate episode happen, and what can we learn from it?
Here are the basic facts. Sometime back in March, Romanian data pirates hacked into a state database. Utah, like many states, maintains a database of Medicaid recipients that health insurance providers query to verify a patient’s entitlement status before paying for care. Unfortunately, the way the process works is badly designed: everyone who receives health care in Utah has their name queried, whether they are on Medicaid or not. The CIO can’t be held responsible for this poor workflow design choice. Most likely the politicians are to blame, or perhaps the state department that regulates health insurance in Utah.
But he can be – and was – held responsible for a series of unforced errors that made this Medicaid database a veritable privacy time bomb waiting to blow up. First, one of his employees (who apparently still has his or her job, though one hopes not for long) forgot to change the default password on the server that was hacked. The inference here is that sensitive personal data for hundreds of thousands of people was protected by nothing more than something like “password”. Second – and this is truly egregious – the state allowed queries containing people’s social security numbers and other personal data to remain on its servers for three months. Basic prudence and common sense would have commanded that the queries be purged immediately after use. Last but not least, the state failed to encrypt this sensitive data while it was stored on the server. That is, Utah’s IT department encrypted the data “in transit” (as most public cloud services also do these days), but not “at rest”. Had any one of these basic data protection measures been implemented, the data breach would not have occurred, hundreds of thousands of Utah residents would not now be facing an imminent threat of identity theft, and the CIO would still have his job.
Although Utah’s compromised database was not (so far as I know) hosted by a cloud provider, this incident does have some clear lessons for government agencies interested in cloud computing. The first is obvious, but bears repeating: stupidity kills. If you forget to update your server’s default password, or leave sensitive data lying around for months longer than you need it, you are simply lighting the fuse on your own time bomb. You can’t complain if you get blown up.
The second lesson is a little more technical in nature, but of greater importance than is commonly recognized in cloud computing circles: at rest encryption of sensitive data is no longer just a “nice to have” option, but henceforth an essential feature of a secure computing environment. Furthermore, it is essential not just for obviously sensitive things like data files full of social security numbers, but also for allegedly “commodity” applications like email. The latter of course contain all kinds of sensitive information both in message bodies and in attachments. Not many agencies are thinking of outsourcing sensitive databases like the one that was compromised in Utah. But many are looking to third party cloud providers like Google and Microsoft to replace aging and expensive in-house email systems.
It is worth pointing out that neither Google Apps for Government nor the standard version of Microsoft Office 365 currently offer good solutions for at rest encryption. Google offers something called “full disk encryption” where the encryption keys are controlled by the vendor. The Mountain View firm doesn’t disclose any details about how this feature is implemented other than a brief mention in published Google Apps for Government contracts. The feature’s name suggests that this is just an encryption of the entire server disk (something like BitLocker in Microsoft Windows). If that’s correct, then the feature doesn’t provide protection against outside hackers who succeed in accessing the server’s file system or against malicious insiders (hmm, do you trust Google to make sure it never hires a Bradley Manning?).
Microsoft Office 365 apparently doesn’t even offer this basic form of at rest encryption in its standard version. Microsoft does offer a high-end version of Office 365 for certain Federal agencies (known as BPOS-Federal) that implements true at rest encryption using functionality built into Microsoft’s Exchange email server. But that version is much more expensive than standard Office 365 and requires an on-premises Active Directory server. Microsoft has also announced a forthcoming “government community” version of Office 365 intended to compete head-to-head with Google Apps for Government. In my view this would be a very good opportunity for Redmond to launch at rest encryption as a standard and affordable cloud option. But so far Microsoft hasn’t said what the feature set on this new offering will include. We’ll just have to wait and see.
At rest encryption is the kind of obscure technical feature that many public sector procurement officers neglect to take into account when writing their RFPs. But its importance should not be underestimated. The FBI insists on it for local law enforcement agencies that access the bureau’s national criminal database system (known as CJIS). And the lack of this feature was one of the initial reasons for the Los Angeles Police Department’s rejection of Google Apps (though to fair, Google later partially addressed this issue by introducing the full disk encryption feature mentioned above).
Caveat emptor. It’s time for public sector cloud buyers to look more carefully at cloud service offerings that have evolved from consumer products (like Google Apps) or were originally designed for small business (Office 365). Agencies should be aware that cloud service providers aren’t likely to include complex but essential features like at rest encryption unless their customers demand it.