Cloud in the Enterprise–Data Sovereignty

 

Australia.pngData and where it is actually located is a hot topic with the enterprise CIO/CTO’s that I speak with. They want to know why they should entrust their operations to our Virtual Private Cloud offerings. This is one area where HP provides value to local businesses—our Enterprise Cloud Services are all hosted onshore. This is at least true in most of the countries where we operate, and certainly the model in Australia and New Zealand.

 

On the flip side, given that the compute service runs in the cloud, i.e. on the Internet, why do we care where the data resides? Surely it’s almost by definition that it doesn’t really matter?

 

But the crux is that the actual physical location of data does matter. Let’s discuss some areas we do need to consider data (and labour) sovereignty:

 

Legal Requirements for Corporate Data (specifically PII)

We discussed the handling of Private Identifiable Information with respect to the cloud a couple of weeks ago. To recap briefly, the two legal considerations are:

  • Your country of registration – for Australian registered organisations you only have to report on the storing of PII data above a certain revenue size (I think $3m pa) and are obligated to store PII data in a country which has an equivalent legal requirement to Australia.
  • Contractual Jurisdiction – remember we discussed how important transparency of the cloud provider supply chain is? Well this has an impact on data sovereignty as well. Your primary cloud provider may host services onshore; however, some data or services providing access to that data may be hosted by a down level provider that hosts offshore. If there is a breach of contract, do you have jurisdiction to enforce the contractual obligations?

Ultimately, there are very few legal requirements to host data onshore. While it may be easier to navigate the letter of the law, and enforce contractual obligations within our sovereign jurisdiction, there is nothing legally preventing the hosting of (most) corporate data offshore.

 

Also, if you work for a multi-national company, chances are, much of your corporate data is already hosted offshore (within the corporate network). For example, when I worked at Microsoft my emails were all stored in Singapore, and many of the Sharepoint servers were in Redmond, in the US. At HP, I have corporate data stored in Singapore, Palo Alto, Houston, and Cupertino.

 

Industry Regulations

While there may not be legal requirements to host data onshore, there are a number of industries where the regulating bodies require onshore hosting. If you are a bank, building society or insurance company in Australia, you are required to comply with the Australian Prudential Regulation Authority (APRA) guidelines. This concept applies globally, with corresponding entities.

 

Similarly, in Australia, government and defence organisations need to comply with the Australian Government Information Management Office (AGIMO) and/or Defence Signals Directorate (DSD). Again, there are equivalent organisations in most countries.

 

To summarise, FSI and Government (including Education & Healthcare) organisations need to consider industry regulations, and are more likely to require data sovereignty onshore.

 

Additional IT Security Risks

Let’s look at the IT Security “Triad” as defined by ISC2: Confidentiality, Integrity, and Availability as it pertains to Data Sovereignty.

 

Confidentiality

Clearly the data stored offshore needs to be hosted in such a way as to preserve the confidentiality of that data. Notable cloud security breaches include the Sony Playstation Credit Card Details Hack, and more recently, the LinkedIn Password Hack.

 

Both of these events affected consumers more than corporates (apart from the service providers themselves) – but you wouldn’t want someone to access, say your Saasu or Salesforce password details and gain access to all of your accounting or CRM information.

 

In this, however, you need to be assured of the veracity of the provider’s provisions to maintain the confidentiality of your information. Their geographical location has little bearing on the logical access to that information.

 

There are two areas where a provider’s location can have bearing on the confidentiality of your data:

  1. When the physical server location is known. If you host a service on a physical server (or a virtual server where the physical host is known) the physical access to the computer in the data centre is vulnerable. Again, you need to be assured that your provider provides all of the policies and processes to restrict unauthorised access to the server. This could be difficult to audit in an offshore data centre.
  2. Where the logical server addressing needs to be confidential. If you host a service on a physical server (or VM as above) and the name or addressing of this server is confidential, then that data needs to be confidential and managed by onshore resources.  A good example is a document repository for a police intelligence unit. In this case we require both onshore data and labour sovereignty. Clearly there are very few instances where this is the case.

Integrity

As with confidentiality, there are a few areas of concern for the majority of corporate data with regard to the physical location of the service provider. As a client you need to be assured that the provider has the appropriate controls in place (authentication, authorization, encryption of data in transit and at rest) to ensure that the integrity of data.

Auditing these controls is certainly more difficult offshore than on, but it is not a show stopper.

 

Availability

Finally we come to availability of the information. Is the data available to you when you need it. Here there are four major risks.  A Denial of Service is derived through:

  1. Technical attack on the provider—In today’s environment, this is less likely to be determined by the country your information is hosted in (government data is obviously excluded from this generalisation), and more by the targeting of the provider organisation. There are examples of where this has happened, however. In the Spring of 2011, the Egyptian government effectively “switched off” the Internet in the country.
  2. Technology failure—For example, the network link fails. A recent illustration of this was the Amazon web Services outage in April 2011. Clearly putting data offshore increases the number of dependent technologies that can fail.
  3. Data seizure by a Government organisation—The most common concern raised here is arguably the US Patriot Act. It allows the US Federal Government to seize data of an individual or organisation under investigation within the USA, or on a site hosted by an US organisation. However, it must be noted that a) Australia has similar legislation and b) Countries have extradition agreements that would allow the same seizures to occur onshore anyway. We saw this with the Megaupload investigation.
  4. Leveraged hosting infrastructure—This occurs when a government organisation investigating someone else seizes your information.  In this scenario, you aren’t under investigation. But let’s say, the SAN that hosts your data, also hosts the data of an organisation being investigated. With the SAN being seized, you are effectively denied access to your information too.

Summary

Hosting your data offshore does increase the risk of losing access to that data (more technology dependencies) and introduces some new risks (seizure of leveraged infrastructure).  Here are my three thoughts on how this impacts our strategy for adopting cloud computing then:

  1. Ensure that you have total transparency of down level providers of cloud services.
  2. Determine the cost/benefit of services you wish to push to cloud, the associated risks with offshore hosting, and the cost/benefit of mitigating these risks vs. hosting onshore.
  3. Finally, ensure that effective security is built into your architecture whether deploying to cloud, or using traditional delivery technologies

 Security Strike.jpg

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Roger has been trying to get out of Information Technology since programming COBOL on mainframes in the late '80's. But no matter in which c...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.