Encryption: A Unified Approach
Fundamental Policies, Transparency are KeyOrganizations looking to implement encryption should consider taking a unified approach, says Karen Scarfone, who coauthored NIST's encryption guidance.
"[I'm] not saying that the same tool needs to be installed on every host by any means," says Scarfone, who left the National Institute of Standards and Technology in 2010 and founded a consultancy a year later. Instead, organizations should implement fundamental policies underlying the decisions surrounding encryption.
"An organization should have a policy that requires all its users and its system administrators to use strong encryption algorithms," she says in an interview with Information Security Media Group [transcript below].
"If you require encryption, but you only require any encryption, then you're going to get weak solutions that attackers can work around," Scarfone explains.
Authentication also goes hand-in-hand with encryption, she says. "Sometimes we get focused on installing things like full-disk encryption on laptops and we forget for a minute that you need to secure that with additional authentication mechanisms as well," Scarfone says. "You're adding some complexity for users."
There will be definite tradeoffs when incorporating encryption, along with authentication, she admits. "Ideally, you want to make it as transparent to the user as you can."
In the interview, Scarfone explains the:
- Relatively simple approach most organizations can take to encrypt data;
- Synergy between encryption and authentication;
- Challenges cloud computing presents in encrypting data.
As a senior computer scientist a NIST, Scarfone co-authored, edited and reviewed numerous technical reports, papers and articles on system and network security topics. In 2011, she founded Scarfone Cybersecurity, where she writes, edits and reviews a wide range of technical publications and standards for NIST and authors articles, white papers and books for other clients on information security and risk management.
Failing to Encrypt
ERIC CHABROW: Why does it seem that every organization fails to encrypt vital data? Is encryption too hard or too expensive to implement?
KAREN SCARFONE: Encryption is definitely not too hard to implement. We've had viable encryption solutions around for many years now. There's a variety of products out there that can do just about anything that you need done in terms of encryption. I definitely don't think it's an issue of encryption being too hard.
In terms of cost, likewise, solutions that are out there have been out there for a long time so they're not cost-prohibitive anymore. Thinking of the cost of antivirus software and other security controls that we take for granted, paying for software such as full-disk encryption software is really not much different. Also, a lot of operating-system vendors including Microsoft and Apple have built in full-disk encryption software into their products. In terms of costs per seat for encrypting all of your laptops, really those things can be achieved now just through the operating system without adding any controls on.
Identifying the Problem
CHABROW: Do you have any idea what you think the problem is?
SCARFONE: I can share an anecdote with you that might illustrate some of what's going on. I just had a call a few weeks ago from a state agency and they were doing some assessments after a breach had occurred, and they found a NIST publication on storage encryption and contacted me. Their questions really circled around, "Is there a specific law or regulation that requires sensitive data to be encrypted?" In a round-about way, I told them no, that what you have to do is take a risk-based approach, that the same data in different contexts may be sensitive or not sensitive, and that it's too difficult to make a law that basically would enforce that.
I came up with an example of a Social Security number. We all think of a Social Security number as something that needs to be protected, and in most cases it does. In some cases, for example, after people pass away, the Social Security Administration releases their Social Security numbers publicly so that they can be used to detect identity theft and other forms of financial fraud involving stolen Social Security numbers. In those contexts, it's public information and there's no need to safeguard it.
It becomes very complicated very quickly when you think about all the different pieces of information about a person and what pieces do you need to be encrypting under what circumstances. Coming up with a law to say in black and white what should or shouldn't be encrypted is really prohibitively difficult. What you need to do is do that risk-based assessment. You need to look at your situation [and] your context of the data. You need to look at what risks are being posed against your data, and you need to think about what security controls are already in place and make a decision for your organization in your case if encryption is needed. I explained all this to the state agency and the response I got back was, "Oh, so there's nothing requiring us to do this." It's a pretty big disconnect and I kind of went and explained it again from a different angle and they kept coming back with, "But we're not required to do it."
That really surprised me. I didn't think that we were still at that state today. I thought that organizations had a better understanding of risk-based assessments and considering in a particular circumstance what would or wouldn't be appropriate. It's not like this is something cutting-edge that an organization might not be aware of. We all have awareness from the news of all the data breaches that have been taking place.
Unified Approach
CHABROW: As an organization looks at encryption, should it be a common approach throughout the organization, throughout the enterprise, or should each individual unit have its own approach to encryption?
SCARFONE: I think in a lot of ways it makes sense to have a unified approach throughout the organization. [I'm] not saying that the same tool needs to be installed on every host by any means, but fundamental policies underlying the decisions about the encryption. For example, there are strong encryption algorithms and weak encryption algorithms. An organization should have a policy that requires all its users and its system administrators and such to use strong encryption algorithms. If you require encryption but you only require any encryption, then you're going to get weak solutions that attackers can work around.
By the same token, authentication goes hand-in-hand with encryption. Sometimes we get focused on installing things like full-disk encryption on laptops and we forget for a minute that you need to secure that with additional authentication mechanisms as well. You're adding some complexity for users. You're adding an additional authentication they have to perform. There are some definite tradeoffs when you're adding encryption. Ideally, you want to make it as transparent to the user as you can.
CHABROW: Who should be making the determination about encryption?
SCARFONE: That should be made high up in the organization. You need to be considering the risk to the organization as a whole if you're not encrypting data. You need, again, policies that cover the whole organization, that are looking at the sensitivity level of data and setting some guidelines or requirements throughout the organization that say these types of data must be encrypted at rest, must be encrypted in transit.
CHABROW: Organizations that have an enterprise chief information security officer, maybe perhaps it should be under that person's jurisdiction?
SCARFONE: I would think that would be an appropriate place for it.
Managing Cryptographic Keys
CHABROW: One of the challenges in encryption is the management of the cryptographic keys. How can it be surmounted?
SCARFONE: That's a good question. Key management is something that we've never really gotten terribly good at. Key management is just an inherently difficult thing. You're taking a key, which is by definition something that's valuable only [if] it's a secret, and you're trying to safeguard it. In terms of things like key escrow, which is a term you don't hear too much anymore, it becomes a little comical where you're taking a key and you're making up back-up copies of a key and storing them in different places, and every time you do that you're putting the key at more risk. It becomes sort of a catch 22. You're trying to safeguard something, but in the process of safeguarding it you're actually making it more likely to be compromised. It's a real struggle.
Definitely organizations seem to not understand the basics of key management. They don't understand or they're not aware of principles like updating keys periodically. They issue a key and just sort of forget about it. A lot of organizations with things like storage encryption will have their own passwords that can basically override the user's passwords, that they can recover that data if the user forgets their credentials. That's a very valuable thing because it's safeguarding the information, but then it creates another path in to get that data. There's always balance between safeguarding the information, availability versus safeguarding the information confidentiality.
Synergy Between Authentication, Encryption
CHABROW: Earlier you were talking about synergy with authentication and encryption. Can you expand on that a bit?
SCARFONE: The easiest example to think of is somebody who has a laptop with full-disk encryption on it. Before it can be encrypted, it's going to present them with some sort of authentication request, whether that is a password or cryptographic token. It's going to ask them in some way to authenticate who they are before it will even decrypt the storage on the laptop. If the authentication is trivial, if the user's password is 1234 or something like that, then it's hardly of any more value than having no password at all. And if there's no password at all, that storage encryption does no good. Anybody could beat that laptop and get access to the information.
What we find a lot of the time is organizations find that their users are resistant to remembering another password, which is understandable. We throw so many passwords at users and we expect them to memorize all these different strains of information, so a lot of organizations have chosen to use the same password for full-disk encryption as they do for operating system encryption, and while that makes things more convenient it also reduces security because if one of those passwords is compromised, now the other one is compromised as well since they're the same. It's a difficult compromise to make. How many passwords can you realistically expect somebody to memorize and type in?
Then, all the support costs that you have when you increase authentication standards, users forgetting things, users stumbling when they type, can become a substantial support burden if you have really strong authentication requirements for your encryption. But if you don't, then you're encryption is at risk of being compromised. It's a tough balance to strike.
Mobility, Cloud Challenges
CHABROW: We've entered this new era of mobility and cloud computing. What challenges do they present in encrypting data with multiple devices and multiple locations?
SCARFONE: The cloud presents a whole new series of challenges. One of the popular things now is to use cloud services to back up your data. Again, while that's great for supporting the availability of information, it really stinks for supporting the confidentiality of information. You may go through all these measures to make sure that your users' data is encrypted on their laptops and their smart phones and their tablets, and then they activate a cloud service and all their data goes unencrypted off into cloud storage somewhere and the organization is not even aware of it a lot of the time. The organization has then lost complete control over that data. It's automatically being copied to a cloud somewhere and who knows what security measures are being put against that.
Particularly with BYOD devices, where an organization may not have any control over the use of cloud back-up services, it can be a real problem with this sensitive data just sort of floating about, going off to unknown cloud locations. I don't have any sort of silver-bullet answers for how you take care of that. You can certainly use enterprise mobile device management software that can help to restrict what goes on in the device, sort of sandboxing the organization's data on a mobile device to make sure that it doesn't get routed through a cloud service. There are also other encryption techniques. Again, the mobile device management software a lot of times can make an encrypted container on the phone. Even if the phone is unlocked, the user would still have to authenticate again to get into the encrypted container and that may be sufficient to keep the cloud from getting a copy of data.
CHABROW: If you encrypt data and then you transfer that data to another service, say on the cloud, if someone tried to access it, you wouldn't need some type of key to read it?
SCARFONE: It all depends on how you've encrypted the data. Say I have a laptop and I've encrypted an individual file on that laptop. In most situations, that encryption is going to stay with the file. Whether I put the file on the cloud or I e-mail it to you or wherever I send that file, the encryption is going to stay with it and protect it. If it's something like full-disk encryption where it's encrypting the entire storage media, that encryption normally does not go with the data. If I do the same thing, if I transfer the file to the cloud, if I e-mail you the file, that encryption does not go with it. Organizations need to pay a lot of attention to the mobility of the encryption itself. It definitely depends on what type of solution is in place, especially with things like operating-system built-in encryption. That's generally not going to be transferring outside of the operating system. You take a file off that computer and put it somewhere else, you're going to lose all the protection that encryption was providing.