Requiring that government data be stored domestically and handled by U.S. citizens is counterproductive.
It’s 11 p.m. Do you know where your data is? If your enterprise has transitioned to the cloud for data storage the answer almost certainly is “no.” Portions of it might be in Malaysia; other bits in Antigua.
Today, governments across the globe are deeply uncomfortable with that answer -- but they don’t need to be. Just a small application of technological magic through encryption at rest can dispel concerns about data’s location.
The underlying problem is familiar to most cloud-sophisticates. Cloud architecture is a distributed network. Optimizing efficiency means locating server farms wherever energy and labor costs are cheapest. And, given the speed with which information transits the network, there is no need to build data centers close to where the data users reside -- data can be almost anywhere in the world in milliseconds.
But the widely-distributed nature of cloud storage systems poses a problem for government users. There is something fundamentally problematic for them with the notion that Federal government data -- IRS records, for example -- might be stored on servers in, say, India. The specter of non-U.S. citizens having physical control over and access to U.S. data understandably gives the government pause. The same is true of almost every other country in the world.
As a result, many federal, state and local governments and agencies are starting to require that their data remain within geographic control.
Taking this school of thought further, the U.S. government is engaged in an opaque rule-making process that is poised to create a requirement that federal data be stored at a U.S. location and handled only by U.S. citizens. These restrictive rules will doubtlessly increase the cost of cloud services used by all levels of the U.S. government -- perhaps by as much as 50 percent to 100 percent over standard public cloud rates. After all, almost by definition, the distributed cloud network is the most efficient (read: cheapest) and any limitations on that distributed architecture will cost money.
The domestic location requirements are almost certainly a mistake. Insisting on geographical boundaries creates a false sense of security that nothing detrimental can happen to sensitive data as long as it resides within U.S. borders; this simply isn’t true. More importantly, the requirement is technologically difficult to implement and throws overboard the very efficiencies that motivate transition to the cloud in the first place.
There is an easier solution -- encryption at rest. A system of encryption where the customer controls the encryption keys solves many of the security problems that have bedeviled public clouds for the government. It would eliminate the need to insist on U.S.-only location for government cloud data centers and support personnel. All that is required is to implement an architecture that enables customers to apply encryption to data at rest before that data is transitioned to the cloud and for their customers to be the sole holders of their own encryption keys. This sort of architecture is not technically difficult; many cloud service providers do it now.
Encryption-based technology already provides a measure of protection for most Internet financial transactions. The encryption of cloud data protects critical information without becoming an onerous burden to users seeking to capitalize on the efficiencies of cloud computing. What’s critical is how the encryption system is structured. If a customer relies solely on vendor-provided encryption (and a vendor promise of confidentiality) that places too much trust in the cloud service provider. The better solution from a security standpoint is to locally encrypt data prior to transfer, and then use the provider’s encryption, if possible, as a second level of security.
Onsite encryption at rest allows a cloud user to effectively replicate existing onsite control over data. There is no reason a customer should have to give up that same degree of control when transitioning to the cloud. Consumers should be in the position of not having to worry that their cloud vendor will use the data or user information from the cloud for the vendor’s own purposes (for example, data mining for ads). With the customer in charge of the encryption keys, users can maintain exclusive control of their data and the cloud provider will have no access to it.
If the at-rest encryption solution is implemented then it just doesn’t matter who works at the server farm or where the data is located, since no one can see the data except the customer. And that means that we can dispense, for example, with the location and citizenship requirements and store U.S. government data at the cheapest and most efficient cloud data center available -- even if it’s in Canada instead of America.
Another advantage of at-rest encryption is it negates some of the legal obstacles that could arise from a globally distributed network, both for governments and for private citizens. One concern has been that government data overseas might be subject to foreign law (and, reciprocally, some overseas are concerned about the application of U.S. law to their data held in America). But encryption answers much of that problem. The cloud service provider can’t be compelled to provide data to which it has no access. In effect, Google can’t give up encryption keys it doesn’t have.
In short, at-rest encryption helps customers preserve some of the benefits of maintaining data on the premises. To be sure, encryption comes with its own security problems -- most notably key management -- but those pale in comparison to the challenges associated with the geographic mandate.
Challenging Old Business Models
So what’s the problem? Why do some in the industry resist this solution?
In part it is because encryption with customer controlled keys is inconsistent with portions of their business model. This architecture limits a cloud provider’s ability to data mine or otherwise exploit the users’ data. If a provider does not have access to the keys, they lose access to the data for their own use. While a cloud provider may agree to keep the data confidential (i.e., they won’t show it to anyone else) that promise does not prevent their own use of the data to improve search results or deliver ads. Of course, this kind of access to the data has huge value to some cloud providers and they believe that data access in exchange for providing below-cost cloud services is a fair trade.
Also, providing onsite encryption at rest options might require some providers to significantly modify their existing software systems, which could require a substantial capital investment. Nor have any major customers, like the U.S. government, seen fit to demand onsite encryption as a service. Instead, federal customers have been content to find other solutions (like the geographic/citizenship rule) as preferred options. So in some ways, there is a disconnect between what the vendors can provide and what the customers think they need.
Finally beyond industry resistance, there is another unintended consequence of these geographic limitation rules. They will destroy the ability of U.S. cloud vendors (such as Microsoft and Google) to sell government cloud services in most overseas markets. Other countries are concerned about the risks of offshore data location and that is the number one obstacle to greater adoption of U.S.-provided cloud services by foreign governments.
For example, in Australia the government recently decided to ban outright the use of foreign-based cloud services by Australian government agencies (even for email or storage). Thus, the current U.S. rule-making is effectively destroying the ability of American cloud vendors to access the world market. And this at a time when these vendors have a huge advance in the scale, scope and technical maturity of their cloud service offerings. But we should be under no illusion: if the U.S. government refuses to allow foreign-data center location for cloud services, foreign governments will be certain to follow the U.S. example.
It’s 11 p.m. You don’t really need to know where your data is. As long as you know it is safely wrapped in an at-rest encryption cocoon, you should feel secure.
Richard Falkenrath was the Deputy Homeland Security Advisor to the President from 2002 to 2004. He is currently a principal at The Chertoff Group, a global security advisory firm. Paul Rosenzweig formerly served as Deputy Assistant Secretary for Policy at the Homeland Security Department. He is currently a senior advisor to The Chertoff Group. They are contributors to SafeGov.org, a forum for IT providers and experts dedicated to promoting responsible cloud computing solutions for the public sector.