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. We recently talked about data-in-motion. This time, we’ll concentrate on data-at-rest.
In general, encrypting data-at-rest is a very complex problem. As you may have noticed, I like to separate big problems into about three smaller problems, and keep doing that until I have a clue how to deal with each of the tiny problems. For data-at-rest, I view the three top-level problems as Policy, Location, and Key Management.
Most companies have a security policy. A security policy has four sub-issues: defining the rules, promulgating the policy, verifying compliance with the rules, and reviewing the rules. The promulgation and verification pieces are not one-time events, but must be consistently and periodically repeated. However, they are not conceptually difficult.
Often forgotten is the review piece. I once was reading the security policy of a company to make sure that we configured a new application system to be compliant to it. There was no mention of email in the policy. You can guess in what millennium the policy was written, and how recently it had been reviewed. Your data changes, you add new applications, establish new partners who may bring their own security policies to the table, or the external compliance or privacy regulations may change. For example, the PCI SSC (Payment Card Industry Security Standards Council) released PCI DSS 2.0 in January, and you must be compliant with it in 2012. If you are required to be compliant with PCI DSS, you may need to update your security policy. I highly recommend that you review your security policy at least once a year, with additional reviews when some event occurs that may impact the data you store or the regulations that protect it.
The rules define what has to be protected, how it must be protected, who has access to the data, and how long it is to be kept. A lot goes into developing and maintaining a good security policy, far beyond the scope of this posting. We will focus exclusively on rules related to encryption.
Those rules define what has to be encrypted, how it is to be encrypted, and the rules for key management. Remember that the security policy is about an organization, and the source for understanding what should be in the rules comes from several sources: external requirements like compliance and privacy regulations, internal requirements from auditors or general corporate policy, and competitive requirements driven by what your partners and customer expect and may demand.
It is not necessarily easy to find all of these requirements. I was talking with a university a couple of years back about their data security needs. The first person I talked to said they didn’t have any special security issues. He was the Director of IT so I figured he knew, but the answer made no sense to me. I called another meeting with a wider set of attendees, and quickly found:
- The university handled their own student billing and used a credit card like mechanism for payment for everything from books to laundry. This application was protected by PCI DSS.
- They ran a health clinic on campus. It had data that was protected by HIPAA and HITECH.
- They had lots of information about each student, including SSN, address, phone numbers, and some personal information about parents. This information was covered by privacy laws that varied by the parents and students permanent address.
- The university had a strict security policy on how grades and tests could be accessed.
- The university was currently engaged in about a dozen grants from the US Department of Defense. While none of these were highly classified, there were three where the material was considered “sensitive” by the government, and the contract had specific security rules to protect that data.
- The university had additional grants from companies, and some of these also had contractual requirements on the protection of the data associated with the grant to protect the company’s competitive or proprietary data.
Different data will have different rules. If you think about the data you have on your computer(s) in your home, there are a lot of different categories involved.
- You have hundreds, probably thousands of pictures. These are an important record of your life. They are priceless in the real sense of the word – no amount of money can replace them if lost. They must be protected. However, in general, it doesn’t matter who might look at them. That picture of you in your bathing suit at 20 may be a little risqué, but you really did look good. In almost all cases, there is no value in encrypting your pictures.
- Ditto your music. And you can replace most of it with money.
- Your financial records are a different story. In most cases, you can with little difficulty recover from losing this data, although you might review Death in the Cloud. However, this data does need to be protected from being stolen and encrypting it is really good idea.
This points out two aspects of protecting data: protecting it from loss, and protecting it from unauthorized use. Both must be specified in your security policy, but in general encryption is associated with preventing unauthorized use. (In the next post I will describe a way to use an encryption solution to protect data-at-rest from both loss and unauthorized use.)
Your security policy needs to be based on the specific data being protected, not the application(s) that may be involved with them. That comes later. For example, the security policy would specify how you handle social security numbers. That SSN policy should be the same no matter where they are or what application is involved.
Now you have your policy, and it defines which specific type of data must be encrypted. Now to the second top-level problem: finding it. You have data everywhere. The obvious examples are disk storage containing your databases, other files like documents, and solutions like your email system. It also includes backup copies, archive data, and wandering storage units like thumb drives, portable disk drives (which now include cell phones), CDs and DVDs. Don’t forget all of your workstations and laptops, each with its own multi-gigabyte storage capability. You may also have some of your data at your partner’s locations. Are they following your security policy?
Categorizing all of these data structures and locations is a major undertaking. Some organizations simply decide not to: they treat everything with the highest degree of protection. This approach has the advantage that it is conceptually easy to state, and perhaps easier to implement. However, this usually adds a lot of additional cost and aggravation. Another popular way is to categorize by system or solution. We treat our financial system this way, our HR system that way. This allows you to more closely match your security policy, but often ignores the migrating data (e.g., email, thumb drives, local storage).
The other side of the “location” complication is who is allowed access. The organization that just encrypts everything the same way has essentially said that everybody who is allowed access to anything is allowed access to everything. Many compliance requirements restrict the roles of people who are allowed to see specific data elements. Even treating each system or solution separately often does not provide sufficient granularity. PCI DSS requires restricted access by role even within what you have probably implemented as a single application solution.
While not easy to do, what you really need is to define Classes of Data. Each Class of Data (COD) has a set of requirements in the security policy, including the roles of the users who are allowed access, the length of time the data should be kept, and any encryption key management requirement such as the rekeying interval. When you first try to do this, you may end up with overlapping CODs – the same data element is in more than one COD. The easiest thing to do is to split the CODs so that the overlapping elements are a new class with the requirements from the two (or more) containing classes. In the picture, COD 3 was created for the data elements that were in both COD 1 and COD 2. COD 3 would have all of the requirements of both COD 1 and 2.
Then map the data contained in the various locations to the CODs. Most, but not necessarily all, of these classes will need to be encrypted.
To use part of my university example above, the data associated with a grant would represent a COD. The grades and test data would represent another COD.
The end is not quite in sight. The next step is to determine who is allowed to see each class of data. If you have done the COD definition correctly, then anyone who is authorized to see one piece of data in the COD is authorized to see all of the data in the COD. You likely have groups of people who are authorized to see a COD or even a set of CODs. Let’s call a group of people who have the right and need to share the same set of CODs a Community of Interest (COI). People get assigned to a COI based on their role. Everyone in a COI is treated, from a security standpoint, as equal. There may be only one COD associated with a COI, or a single COI may have access to multiple CODs, and a single COD could be allowed access from multiple COIs. A given user might belong to one, many or no COIs based on what that individual was authorized to access.
Back to the university example. Every professor would likely belong to a “professor” COI. That COI would have access to the grades and test data COD. But so would a few administration staff so they could generate report cards or deal with questions from parents. Those people would likely not belong to the “professor” COI but to a “grades admin” COI. Similarly, each grant would likely have its own COI. Different professors, grad students and maybe others would belong to a grant COI only for the length of time they were working on that grant. A given professor might belong to the “professor” COI and several grant COIs at the same time.
One key attribute of a COI is that it needs to be flexible – people need to enter when they need access, and be removed from it as soon as they no longer need the access.
The last top-level piece is the requirements on managing the keys for the encrypted data-at-rest.
Every COD should have its own encryption key in order to keep access to only those users who are authorized. This also limits the damage if somehow a key is compromised. It also allows different rekey and re-encrypt options to occur as required. What it also means is that you need a fairly sophisticated key-management system to protect and manage the keys.
The last word:
The good news is that if you have a comprehensive security policy, and follow it, you have an easier job moving to the Cloud. Your security policy, as it relates to the CODs you will be moving to the Cloud, become the security requirements to your Cloud Service Provider. Next time we will talk about encrypting data-at-rest specifically in the Cloud.
Keep your sense of humor.