We started talking about encryption in the Cloud in an earlier blog. We indicated that you could satisfy many compliance and privacy laws by “simply” encrypting everything in the Cloud. We described the three states that hold your data is out in the Cloud: data-in-motion, data-at-rest, and data-in-process. Last time we talked about encrypting data-at-rest in general. Now we will look at how moving to the Cloud impacts data-at-rest issues.
I am going to assume you have a security policy as we discussed in the prior blog, and that it contains detailed requirements around any data that must be encrypted to meet that policy. Such as:
- The data that must be encrypted, hopefully categorized in a way similar to what I called Classes of Data (CODs). All of the data belonging to one COD has the same security requirements.
- Who is allowed access to each COD, what I called last time the Communities of Interest (COIs).
- How long the data needs to be retained, and any requirements on certification of data destruction.
- Any requirements on re-keying or re-encryption.
What if you don’t have a security policy? Some common excuses I have heard about why a company does not have a security policy include:
- We have no sensitive data.
Possibly, but unlikely. If you have employees or customers, participate in the collection of funds from your customers, or share information with partners you probably have some data that is considered protected either by some compliance regulations or government privacy laws. Some non-disclosure agreements (NDA) require specific protection, including encryption, of any data received from the other party. You probably have an NDA with every one of your partners, and possibly with some of your customers.
- It is hard to create a good security policy.
Yep. There are companies that specialize in creating them for you. In any case, it is time and potentially monetarily expensive to create and maintain a good security policy. You should balance that cost with the risk of not having one.
- My employees will not put up with the increased aggravation of dealing with additional security requirements.
Too bad. This is part of doing business in the current regulated and litigious society. You need to protect your company’s reputation. We discussed in the first of the Cloud security blogs that 48% of all breaches are caused by insiders, accidently or otherwise.
Perhaps the best reason to have a good security policy is the advantage it gives you when you have a data breach. Even if you have not followed it exactly, the very fact that you have a policy shows intent. Several lawyers who specialize in defending companies after a data breach have said that if a company does not have a reasonable policy they do not stand a chance. The judges, juries, and compliance and government agents use the absence of a policy as an indication of carelessness – it must be your fault.
Of course, once you have a policy it is a good thing to at least make a good effort to follow it. I was talking with a consultant who specializes in PCI compliance (credit and debit cards). He indicated that one of his customers indicated that they did not bother to encrypt the data that the PCI standard required. He was a relatively small vendor, and “it is cheaper to pay the compliance fine than it is to encrypt the data.” While true, the cost of a data breach can be very expensive. According to Ponemon Institute, it costs more than $200 for each stolen record, not counting any government or compliance fines, or lost reputation.
Why all of this conversation about having a security policy? Because when you move to the Cloud, it is that policy which will determine what you can actually move to the Cloud and what requirements you need to place on your CSP (Cloud Service Provider). If you don’t have a good security policy, do not move anything to the Cloud until you have done a very careful analysis of the data you plan to move there.
The main data-at-rest issue with moving to the Cloud is the loss of control. You have a new partner who has physical and operational control over your data. You don’t know who has access. You don’t know where it is. The only way to have any confidence that your data is not being looked at is to encrypt it, and control the keys.
The easiest way to do that is to move your workload into a Infrastructure as a Service Private Cloud implementation. In this case you maintain a lot of control. You can continue to use your current encryption mechanism. Your data is isolated on some storage units assigned to you. Many CSPs will let you review their security policy, so you can determine that they can meet your security policy.
If it does not violate some other requirement, you can probably move up to Platform as a Service. This will allow you to take advantage of additional operational benefits of moving to the Cloud. Just make sure you can get any drivers or other software components required to support your encryption solution into the image supported by your CSP.
If, without considering your security requirements, you can take advantage of Software as a Service, you may be able to work with your CSP in a Private Cloud environment to include your existing encryption solution.
For performance reasons, many data-at-rest encryption solutions use a hardware appliance to do the encryption. Some CSPs will allow you to include that hardware in your Private Cloud. Many CSPs will provide their own data-at-rest encryption solution. Work with them to see if that solution meets your security policy. Pay particular attention to who owns and controls the encryption keys, and how those keys are protected from loss.
For example, many compliance regulations require that the operational staff with access to the data storage do not have access to the keys. Your CSP’s security policy may specify that separation. Work with the CSP and your auditors and compliance conformance testing group to make sure that what they claim to do matches your requirements, and that you can audit that compliance.
Another issue with key management is the potential requirement to re-key or re-encrypt the data periodically. When you re-encrypt data, you actually take all of the data, decrypt it from the old key, and then encrypt it with a new key. This can, obviously, take a long time. Some encryption products will allow you to continue to access the data while the data is being re-encrypted, but you will notice a performance hit.
Some encryption products use a different approach: they have a lockbox that contains the actual keys. Then a different user-based key is used to control access to the lockbox. Using the terminology form the last blog, a user may sign on and be given, by the identity management system, a key that identifies the COI the user belongs to. When the user wants access to data, that COI key is presented to the lockbox, which then uses the encryption key(s) for the CODs that COI can access. The user and any software the user is running never have the actual data encryption keys. To rekey the data, you just rekey the lockbox, giving each COI a different key. You don’t have to re-encrypt the data. If someone tries to get in with an old COI key, they will fail at the lockbox. Re-keying is very quick with no performance hit.
Check carefully with your compliance and privacy law regulations to see if you can periodically re-key instead of re-encrypt.
Logs, archive and dumps are often overlooked, and not just in the Cloud. In your own shop, this can be a problem, but can usually be mitigated by adhering to an appropriate security policy, and auditing access to those materials. In a Private Cloud, these considerations need to also be investigated and appropriate solutions negotiated. Again, check on the security policy and audit controls of your CSP.
Some CSPs are very reluctant to any use of encryption on data-at-rest unless they own and control the keys. As we mentioned earlier, de-duplication techniques do not work on encrypted data, and attempting to compress encrypted data can actually increase the size of the data.
Of course, laws can get in your way. The US Patriot Act allows the US government to demand the encryption keys from your CSP, and those keys might allow access to your data even if your company is not the target. It also requires that the CSP not tell you that they have given away the keys. Chinese law requires that the Chinese government be able to decrypt all data stored in China.
All that said, the Cloud can still provide some significant security advantages. Interested CSPs can afford to have the appropriate security policy, the audit procedures to verify adherence, and the security experts to quickly deal with problems. Some CSPs are working very hard to provide Private and Community Cloud products specifically tailored to meet certain compliance requirements. This is a fast moving market, and if today you should not move a workload into the Cloud because of compliance or regulations, check back in six months.
Some CSPs provide encryption for data-at-rest. This is usually done at the physical storage unit level or even controller level so the same key is used for all data in one or more physical storage devices. Since operational data such as logs are often stored in that same environment, there may be operational personnel with access to the keys and thus your data.
We are also seeing new security products created or being tailored for the Cloud. I mentioned the Unisys Stealth Solution for Network earlier. There is a companion product for SAN storage that provides separate encryption keys for each COD, and a certified lockbox to control access to those keys based on the user’s COI. Because the keys are controlled, a CSP using Stealth for SAN could implement a compliant data-at-rest solution even if the physical storage units are shared amongst multiple users. Stealth also can disperse encrypted data across multiple “places” including different CSPs, such that there is insufficient data at any one place to decrypt any of it, even if you have the keys, and such that you can recover your data even if you cannot access all of the different places.
The last word:
As always, make sure your contract with the CSP includes any audit access, their security policy, and other security related actions on their part.
One aspect often ignored when negotiating with a CSP is notification. How and when will your CSP notify you of a security breach? Breaches will happen, just like they will happen in your own shop. You need to deal with them quickly, and your CSP needs to tell you as soon as they suspect one may have occurred. This is a difficult subject to get in the contract. Lawyers tend to think that contracts specify what one party can do and what they cannot do, and what the penalties are when one party fails to comply. This kind of contract often rewards the wrong conduct by one or both parties. I have seen some contracts where the CSP promises nothing, so the customer has no protection. I have also seen contracts where the customer has required that there never be a security breach, and if there is the customer has the right to immediately move off that CSP with no financial penalty. Neither way is right. When there is a security breach, you don’t want to leave your CSP, you want to get the leak closed as quickly as possible, and unless the CSP was really negligent, keep doing business with them.
Keep your sense of humor.