Losing Control Of Almost Everything In The Cloud

Attorney Mark D. Rasch is the former head of the U.S. Justice Department's computer crime unit and today serves as Director of Cybersecurity and Privacy Consulting at CSC in Virginia.

As retailers embrace the cloud for its flexibility and convenience, they might want to also consider a very serious potential for loss of control. Legally, we're talking three different types of control loss: Your loss of access to the data; your customers' loss of the ability to access your services; and the potential for your confidential data to become government public records and to then find its way to your competitors.

Paranoid? Not any more. Recently, the U.S. Government, in cooperation with the Government of New Zealand, took down the copyright pirate site "MegaUpload" and had its founder arrested and detained awaiting extradition. Irrespective of the merits of the copyright infringement lawsuit, the government is now seeking to seize and possibly destroy all of the site's content, including non-infringing content shared on the P2P site. Family photographs, video, documents or other records that merely reside on the site have already been subject to U.S. and N.Z. inspection, seizure and copying. Now it may be destroyed.

Add to this the fact that the U.S. Government may be introducing legislation allowing the government to "take over" companies' IT infrastructure if it believes the company is not doing an adequate job of security, and we create just what merchants seeking to jump into the cloud don't want—fear and uncertainty.

The MegaUpload case points out one of the problems with outsourcing, generally, and the cloud, in particular. As more content and activity migrates to the cloud, more unlawful activity will also migrate to the cloud. This is not just copyright infringement or botnets, but garden variety frauds, swindles and thefts.

In addition to illegal activity, other activities that governments may want to limit or suppress, such as online demonstrations, protests or political activity, will occur on cloud providers. A government may seek evidence from cloud providers, may seek to stifle or prevent activity or may seek to shut down or seize cloud providers or their customers' data. If the government believes that the activity is systematic or, worse, that the cloud provider itself is engaged in unlawful conduct, the government may seek to seize all of the operations of the cloud provider.

The nature of cloud is such that it is likely to be subject to legal process and demand virtually (pun intended) anywhere. Thus, a U.S.-based entity, storing information or documents on a "cloud" provider with facilities in Denmark, Peoples Republic of China and South Africa may find its documents or records seized by law enforcement or other agents in any of these countries. With Mutual Assistance in Legal Affairs Treaties (MLATs), any country could ask the assistance of any other country to take down an offending cloud provider, seize the records and send them to the other country.

The problem is not always solved by geography. A U.S. customer of a U.S.-only cloud provider still runs the risk of either that provider or a user of that cloud running afoul of the laws in Bulgaria or Singapore, or that the U.S. Government on behalf of those requesting nations may take down that cloud provider and seize its "information assets." Remember that the user may not have done anything wrong and may not be the subject or target of the seizure.

Years ago, I was involved in a case where a client wire-transferred funds from one bank to another, and the money travelled through the Bank of Credit and Commerce International (BCCI). Because BCCI was suspected of criminal activity, its assets were seized—and those assets included my client's funds. The client lost their money, because the bank had committed an unrelated crime and the U.S. Government seized the bank's funds. The same is true of the cloud.The same is true of the cloud.

The users of MegaUpload were told that the storage was safe and secure and that MegaUpload would never share their data with anyone. As the Grateful Dead explained, "if you've got a warrant, I guess you're gonna come in."

The benefit of the cloud for retailers is that they can go "all in." Everything becomes "as a service." Customer data, inventory, supply chain, marketing, sales and HR all become services to be outsourced to third parties anywhere in the world. But if any government anywhere around the world decides that either the cloud provider or one of the cloud users is doing something improper, it may seize the entire cloud—with the innocent retailer's data.

Contract language may not help here, because the actions of the government may act as a force majure preventing the cloud provider from complying with contractual obligations. What is worse, unlike a "search and seizure," where the government seeks evidence of criminal conduct (and must, at least in the U.S., limit what it can look at and use), when the government "seizes" the cloud provider's assets not as evidence but as fruits of illegal activity, it may not be required to give it back to a so-called "innocent owner," like the merchant.

The legislative proposal causes similar concerns. Much of the U.S. "critical infrastructure"—transportation, telecommunications, energy, chemicals, banking, etc.—are held by the private sector. The government has a legitimate interest in ensuring and promoting both privacy and security in that infrastructure, for national security reasons. As such, it has long been proposed that participants in this critical infrastructure have a security and privacy "scorecard," some set of reasonable standards or goals against which they are measured. This necessarily implies that there be some type of "carrot" or "stick" to encourage compliance or punish noncompliance.

What the legislation (as yet undisclosed) suggests is that, at least for government contractors, if a member of the critical infrastructure fails to meet the standard, the government has the right to essentially "take over" the IT infrastructure to make it compliant. Good idea? Horrible idea?

Hard to say. The devil is always in the details. Many government contracts permit the government to ensure compliance with the contract and regulations and, under certain circumstances, to take over for the contractor. If a contractor was, for example, running an unsafe railroad on behalf of the government, it would not be unreasonable to allow the government to step in and say (particularly after trying to get the contractor to comply) "Hey, let us run it." On the other hand, nobody ever really passes an IT security audit.

Security is a process, not a goal. There will always be areas of noncompliance, failure to meet a standard or trying to adapt a new or old technology to a standard. Should every company in the critical infrastructure worry that an exception to one issue in an audit means that the government will not only take over the infrastructure but, like in the MegaUpload case, have access to everything on the infrastructure? I certainly hope not.

So what is a retailer to do? Don't panic. Decisions about when and how to adopt new technologies (like the cloud) or to outsource IT infrastructure to third parties must be made on a rational cost/benefit basis—as long as you appropriately weigh the true costs and benefits. After considering cost savings and security, retailers must ask, "how will this benefit my business" and "is it worth the risk?" Finally, retailers must ask "how do I manage the risk I am taking?" This may mean having a disaster recovery plan independent of a primary cloud provider, retaining certain key features in-house or otherwise taking plans in case of a government take over. Remember that the risk of this happening is low. But when you put all your eggs in one basket, you should make sure that the basket is safe.

If you disagree with me, I'll see you in court, buddy. If you agree with me, however, I would love to hear from you.

—Sophia Shahnami, a legal researcher and writer in Winter Park, Fla., contributed to this column.