Data Sovereignty – A Lesson from the Future

Posted on Updated on

  1. Data stored overseas should be accessible to US government, judge rules– Source Reuters
  2. Obama administration contends that company with operations in US must comply with warrants for data, even if stored abroad– Source The Guardian

With the rulings this summer that Microsoft must provide the US government with customer data even if it is stored outside of the United States, many organizations and individuals alike are concerned about data sovereignty and privacy – And they should be however, legal issues like data sovereignty and Safe Harbor are distractions from the real issue.

Let’s start with a definition of Data Sovereignty:

Definition: Data sovereignty is the concept that information which has been converted and stored in digital form is subject to the laws of the country in which it is located.

– Source TechTarget


If you are at all concerned about data security and privacy, it’s not just legal jurisdictions that you need to be worried about. Consider some of the more high profile security breaches over the past few weeks (let alone the past year) in both cloud services and private data centers:

  1. Hundreds of Intimate Celebrity Pictures Leaked Online Following Alleged iCloud Breach– Source Newsweek
  2. Prosecutors: Accused Russian hacker jailed here had 2.1 million stolen credit card numbers when arrested– Source – Fox
  3. Data Breach Bulletin: Home Depot Credit Card Breach Could Prove To Be Larger Than Target Breach– Source Forbes
  4. Russian Hackers Amass Over a Billion Internet Passwords – Source New York Times

The message to me is that it doesn’t matter where the data is, it isn’t safe. In fact one could argue that while the US DOJ, SEC or IRS having access to your data is a privacy concern, it is less of a threat than a major security breach like Home Depot etc.

So what’s the answer?

Obviously this is a complex problem and large organizations with lots of smart people have been struggling with it for years. I don’t have a simple answer nor should you expect one. I know that many of the technology problems we faced in the past have been solved – and even seem quaint Remember having to rewind VHS movies before DVDs? Or returning DVDs before Netflix? Since I can’t travel to the future to tell you what the solution will eventually be, let’s look to somebody who has seen the future. Namely Captain Jack Harkness.

Captain Jack Harkness

He definitely doesn’t want to get caught with his pants down while saving the earth. Notice that he is wearing both suspenders (braces for our British readers) and a belt? So what can we learn from this?

While taking all of the precautions that you can with data center processes is an important part of a security strategy, some additional steps can also be taken. Consider data encryption. Yes, the data may still be accessed by unauthorized parties but the data will be of little use to them if they can’t decrypt it. In a private data center that has been compromised, the data may still be safe.

In public cloud environments, data can be encrypted before it enters the vendors cloud. The keys can reside in the client’s data center or in a third party escrow facility. In order for the data to be useful, a double breach would be necessary.

The same holds true for data sovereignty. Who cares if the DOJ has your data if they can’t read it.

Of course all of this assumes that the level of encryption being used is sufficiently strong that it is non-trivial to decrypt it through brute force or other means.

What do you think the future holds for data sovereignty and security?

BitLocker To Go Best Practices

Posted on Updated on

BitLocker To Go is Microsoft’s removable media encryption solution. It uses the same underlying disk encryption technology as BitLocker (for fixed disks) but is designed to address the use cases around removable media. For example, sensitive data is copied to a USB key and lost. If the key is protected with BitLocker To Go, if the key is found, the data is unreadable on a device that hasn’t viewed the data previously without a PIN. This renders the data essentially useless except by an authorized user.

There are dozens of configuration options managed through policy objects that can be used to control BitLocker. There is plenty of information already on TechNet here.

I’m not going to get into the fine details of each individual policy. I’m going to provide a framework to help you decide what combination of configuration options will meet a particular use case. Most organizations need to understand how they want to implement BitLocker To Go. A good starting point is to by considering the following questions:

  1. Do you want to enforce the encryption of removable media or leave encryption to the user’s discretion?
  2. Do you want to prevent the reading of data from removable media not authored within the organization (E.g. read a key from a vendor, or a personal a user’s personal unencrypted key)
  3. Do you want to prevent writing to unencrypted removable media devices?

Most organizations will not want to leave the decision whether or not to encrypt removable media to the discretion of the end user. This involves a training burden and sound judgment by the end user. Ultimately there is no way to ensure or measure compliance.

Typically, an organization will want to ensure compliance. This involves creating a process to centrally encrypt USB keys and have a request/authorization process for users that need to right to keys.

  1. The scenario for USB keys is something like the following:
  2. Users can read from unencrypted USB keys (personal or from partners, vendors, etc.)
  3. Users are prevented from writing to unencrypted keys
  4. Users who need to write to a USB key go through the request and approval process.
  5. The Service Desk encrypts a key and delivers it along with the PIN and use instructions.
  6. Users are prompted for a PIN on first use of an encrypted key on a particular machine and can then write to the key
  7. If USB key is lost or stolen, it cannot be read except on a machine that has previously read the Key or by entering the PIN (or smartcard)

To implement the above scenario the following GPOs can be used as a starting point:

Group Policy


Allow users to apply BitLocker protection on removable data drives


Allow users to suspend and decrypt BitLocker protection on removable data drives


Do not allow write access to devices configured in another organization


Do not install BitLocker To Go Reader on FAT formatted removable drives


Require password for removable data drive


Allow Data Recovery Agent


Omit recovery options from BitLocker setup wizard


Save BitLocker recovery information to AD DS for removable data drives


Do not enable BitLocker until recovery information is stored in AD DS for removable data drives


Require use of smart cards on removable data drives