Free Newsletter
Register for our Free Newsletters
Access Control
Deutsche Zone (German Zone)
Education, Training and Professional Services
Government Programmes
Guarding, Equipment and Enforcement
Industrial Computing Security
IT Security
Physical Security
View All
Other Carouselweb publications
Carousel Web
Defense File
New Materials
Pro Health Zone
Pro Manufacturing Zone
Pro Security Zone
Web Lec
ProSecurityZone Sponsor
ProSecurityZone Sponsor
ProSecurityZone Sponsor
ProSecurityZone Sponsor
ProSecurityZone Sponsor
ProSecurityZone Sponsor

The principles of solid encryption key management

Protegrity : 27 January, 2009  (Special Report)
Ulf Mattson, the Chief Technology Officer of Protegrity, answers questions on critical aspection of managing the encryption key security chain
Without a doubt, sound key management is at the crux of a solid encryption program. Unless an organization establishes a systematic approach to generate, rotate and store its keys, its encryption activities are largely futile.

And yet, many enterprises still continue to fly by the seat of their pants when it comes to this critical part of the encryption security chain. In this Q&A, Protegrity Corporation CTO Ulf Mattson discusses the reasons why enterprises still remain lax about key management. He follows up by offering enterprises pointers on how to improve their key management practices and what to look for from a key management vendor.

Why is key management such an important part of encryption?

I would say that unless your keys are secure, you will not have a secure encryption solution. That's the foundation or a solid encryption implementation.
Key management is critical in all environments. Without it there is little reason to encrypt.

Key management is very often overlooked, so people in many cases end up with an inferior key management system. When they discover this, either after a breach or after a security review, it's an embarrassment and panic starts to spread.

Why is key management so often overlooked?

I think it's because it is hard to implement, hard to understand and few people understand how to do it. It seems so easy to just have a key and use it to decrypt and encrypt. Most people don't care about how the key is generated or how good the key is and don't consider threats to the key.

If you really review the different threat scenarios on your system, including the key management, then it will be obvious that these are the keys to your kingdom and you need to properly protect the keys. People overlook that security review in many cases.

How should organizations approach key management, then?

People should really step back and look at the key management security chain and look for the weakest link. Fix the weakest link but don't be fanatic about it. Know your biggest vulnerabilities and risks. Take appropriate measures to find best practice solutions to address those vulnerabilities but be holistic and reasonable about it. For example, some people worry about protecting their keys in memory. It is possible to do that, but you should really take a step back and look at your systems and ask, "Is that the most vulnerable point in my system?"
No, probably not. You probably have a lot of other exposures that you could spend your time on.

A lot of organizations would do well to look at the PCI DSS regulations regarding how you do your key management. PCI is very serious about encryption and yet they aren't requiring organization to use HSMs or FIPS 140-compliant key management solutions. These kinds of solutions are not for common use.

What have key management vendors done wrong in past and how can buyers be sure they are picking the right solution?

I would say one main issue is that you have seen too many point solutions. There are a lot of key management systems out there that are designed for one database brand or for one operating system. This makes it hard for an organization to implement enterprise-wide key management.

Things are starting to change in the industry, though. We have players in the industry that have taken steps to implement enterprise-wide key management systems, so it will get better.

I would also say it is a limited value if your system only does key management. A higher value is to provide key management together with enablers; functions that can use the keys and encrypt your databases, your files and applications. A mature solution should combine a good key management system with encryption agents or plug ins for DB2, Teradata, Oracle and other platforms.

Vendors who have been doing this for ten plus years are focused on solving the whole problem, from key management all the way to encrypting data on different platforms. That is what you get from a mature solution. The less mature solution is missing those endpoints that are doing the encryption jobs for you.

That is an issue because today most database products are not open for centralized key management. For example, the newest Oracle version cannot receive the key from a central key manager. It is the same thing with the newest SQL server, the newest Informix release and so on. So you sit there with the central key management system but there's no way to use the keys when you're using a point solution.

It is a bit of a limited value to buy key management systems that do not provide endpoint encryption capabilities that are really hooked into these database systems.

What are some good best practices that organizations should be implementing with their key management systems?

I think one important step is regulating separation of duties. You have the key custodian and make that a separate role and responsibility that is carried out outside your operations systems, away from your data management and database activities. It should be a separate key management system and it should be auditable.

Another best practice is defining different key classes. You should have different rules regulating the keys that lock down your most critical data. The type of data the key is protecting should make the difference between whether it should be generated in hardware or software, or if the key should be stored or cached on a local distributed system. It will also determine how often the key should be replaced.

With less critical data you can go for more operationally efficient models of key management with lower cost lower administration models and higher performance. It is always a balance.

Some vendors tell their clients, "All of your keys are very secure; they're locked away in a remote location."

But sometimes they are so secure that you can't even use them. You've got to be realistic, especially when the data in question isn't of high criticality.

Are there any special concerns that apply to smaller enterprises? Do they need to do things differently?

Yes, the size of the organization can affect how an enterprise goes about separating key management duties. Some organizations don't have enough IT staffers to give different roles to different people.

One approach is to assign that responsibility to, say, a DBA. The important aspect here is that when that DBA is performing his key management, then he is switching roles and logging in as the key custodian. It means providing a separation and logging within the system so you have full accountability of the DBA's actions. You still have the problem of having one person that is capable of both accessing the data and setting the security policy for access to data. So it's not a perfect model regarding separation of duties, but it is auditable and that's a very good step in the right direction
Bookmark and Share
Home I Editor's Blog I News by Zone I News by Date I News by Category I Special Reports I Directory I Events I Advertise I Submit Your News I About Us I Guides
   © 2012
Netgains Logo