The most trusted source for computer security training, certification and research.

Security Thought Leaders

<<Thought Leader Home

Introduction

Stephen Northcutt from the security laboratory conducts in depth interviews with the thought leaders in information security. For every novel security product, there is a thought leader, a man or woman of vision that sees the need and guides the creation of the security product. If there is someone missing whose voice you feel should be heard, drop me a note, stephen@sans.edu.

Table of Contents

Kevin Kenan, Managing Director, K2 Digital Defense

March 14th, 2008
By Stephen Northcutt


Imperva and a few other vendors are starting to understand the importance of database security and release product, but Kevin Kenan, Managing Director, K2 Digital Defense picked up on this long ago. He has agreed to be interviewed for the Security Thought Leader series in the SANS Security Laboratory and we certainly thank him for his time.


Kevin, how did you get started down this path?

Back in the early days of the Visa Cardholder Information Security Program, Symantec recognized that it would need to encrypt the cardholder information stored in the database. Since I had a background in cryptography and happened to be on the team responsible for the system in question, I was put in charge of taking care of the problem.


So, why did you feel that you had to build something, I have seen products that encrypt databases?

We looked at the solutions available on the market at the time, but none of them fully addressed our threat model or operational requirements. For example, key management and protection was often poor to non-existent, the capability to change keys on the fly was generally missing, we needed to be able to make encryption and decryption calls from stored procedures running in the database, and the solutions that directly linked the encryption and decryption to the database's access control mechanism didn't provide an appropriate level of security.


So when you tore into the project, what did you learn? It doesn't seem to be that complex of a problem?

These issues illustrate a common problem. When most folks first start a database encryption project, they don't realize that the encryption itself is the easy part. There are all sorts of libraries available to encrypt and decrypt data, and they are easy to use. Encryption functionality, however, is just the tip of the iceberg.


That is interesting Kevin, I certainly agree there are numerous facilities available to encrypt and decrypt! What do you see as the toughest problem in database security? What took some significant effort?

Key management is the difficult part. Encryption turns the problem of protecting all of your sensitive data into the problem of protecting one uber-secret: the key. If the key is stolen, the encryption is worthless. Unfortunately, people new to database encryption often focus just on the encryption and decryption functionality and relegate the key management issues to the sidelines.


Our readers are subject to a large number of regulations and standards, on the main I have heard that the Payment Card Industry's Data Security Standard is pretty logical and they actually give you some guidance. What do you think about it and what does it say about database security?

One of the reasons that I like the Payment Card Industry's Data Security Standard is that it stresses key management. Requirements 3.5 and 3.6 explicitly identify key management issues. Of course, that is one of the sections of the standard that lead the project managers to shake their heads as they realize that the relatively straightforward requirement of encrypting data has become much more complicated.


OK, that is interesting, please expand, where are the alligators lying in the swamp?

Legacy and third party applications are particularly troublesome. Some commercial solutions need to modify the database schema with views, rewritten tables, and stored procedures in order to work. Application vendors can get very grumpy when their schema is modified in this way--threats to void support contracts due to such non-approved modifications are not unheard of. Unfortunately, many application vendors respond to the database encryption requirement with quick fixes. I've seen vendors suddenly release a patch with encryption and say, "There, we've taken care of the problem." Peering behind the scenes, though, you might find that the key is hardcoded in the application and the same key is used by every customer. It won't take long for that key to hit the criminal underground.


Oh my, that is terrible. Reminds me of Bruce Schneier's concept of Security Theater, where there is lots of commotion and no useful action. I had hoped we were way past the point of hardcoding keys and passwords. Legacy applications are always a tough problem, are there any other gotchas we should be aware of?

Another problem with legacy and third party applications is that once the data is encrypted, you might find that the encryption breaks previously unknown processes further downstream in the data flow. For instance, in one case we had successfully encrypted credit card numbers only to find that a daily batch processing system, for some unknown reason, ran a validity check on the numbers (the last digit of a credit card number is a check digit). The numbers had already been validated earlier, so the validation was not necessary, but there it was. We ended up generating our own check digit and appending it to the number. The system worked fine after that.


Cryptography of data at rest is more important than ever in the face of the incredible number of data breaches. So, companies are going to look for solutions from vendors, do you have any tips for someone just starting their database encryption journey?

Today, the commercial solutions available for database encryption are much better, though buyers must still keep in mind all of the concerns mentioned above. Folks approaching a database encryption project should spend quality time upfront defining a threat model. Success in a database encryption project (measured by the hypothetical units of security per dollar) depends on understanding what threats you want the solution to defend against and then designing appropriately.


Now that sounds like solid advice right down the begin with the end in mind avenue! So of the approaches to defense in depth, it sounds like a threat vector analysis architecture is a pretty good bet. What do we need to do?

Identifying relevant threats is one of the places where regulatory mandates to encrypt fall short. A system that encrypts and manages keys so as to protect against system administrators looks very different from a system that is simply trying to protect against stolen backup tapes. Organizations need to be careful about buying more or less than they need, and regulatory requirement to encrypt often don't provide strong guidance in making that determination. It is up to the organization to understand their threats and encrypt appropriately.


Kevin, as you know database access is facilitated by more and more web forms every day. Can you give any specific guidance on what someone who has an Internet facing web form should do?

Good question. Application security needs to be layered on top of a strong encryption strategy. I could talk about both of these topics all day, but I'll just make a few key points. First, web applications absolutely must filter all input coming from the browser. SQL injection exploits rely on the attacker sending funky data to the application. Filtering will help prevent that. Second, web applications should use some sort of prepared statement to execute queries; avoid creating raw SQL queries by concatenating user input into SQL.

Finally, watch out for encryption products that automatically decrypt data for "authorized" users. If an attacker discovers a vulnerability in the web application that allows him to pull data directly from the database, then the encryption may prove useless since the attacker's queries will look like they're coming from the authorized web application. The encryption solution will happily decrypt the data and hand it over. I prefer to set up database encryption so that it offers another layer of defense against web-based attacks.


This has been a great interview in terms of threat analysis, but performance also matters. What is the biggest performance and tuning mistake rookies make when they implement database encryption?

In many cases, the impact is not as severe as people fear. Rookies inevitably want to encrypt too much. Strong encryption should only be applied to the most sensitive information, and that information is often not needed for high performance indexing or searching. However, in those cases where it is needed, keep in mind that anything that makes it easier for your database to search also makes it easier for an attacker to discover the information you are trying to keep secret.

Like so many things in security, a balance must be achieved.


Thank you for that Kevin, what are you hoping to see in this part of the industry over the year or two?

Going forward, I'm hoping to see more applications provide standardized hooks that will allow crypto providers to easily plug in to the application. Sensitive information would flow into the application for processing. When the application is ready to store the information in the database, it first calls the crypto provider to encrypt the data. The crypto provider handles all the encryption and key management. Similar hooks would be available to support decryption.


Where can I go to get more information?

 My book, Cryptography in the Database, covers the issues and architectures described above. Also, I'm talking about database encryption on my blog at http://www.0xC0DEShop.com. Code from the book is also available at my blog, as is Chapter 2. If you want to learn more about cryptography in general, a great place to start is with the Handbook of Applied Cryptography by Menezes, Oorschot, and Vanstone. It is available online for free! See http://www.cacr.math.uwaterloo.ca/hac/. I also highly recommend Practical Cryptography by Ferguson and Schneier. It gives excellent advice and puts cryptography into perspective--crypto not a magic bullet.

Ross Anderson's Security Engineering is not read widely or deeply enough. It is one of the few books that show how security needs to be approached holistically and with solid analysis. Simply throwing a firewall here, an IDS there, and sprinkling some crypto on the database does not make an organization secure.

I'm starting work on a project to produce an open source database encryption tool and key management suite. I've talked to several organizations that really want an open source solution in this space. I'm still in the beginning stages and am evaluating technology, but much of the architecture will follow what I outlined in my book. Stay tuned!


Fantastic, it is an amazing book! One of the traditions of the Security Laboratory is to offer a bully pulpit, an opportunity for you to share a message with a lot of readers. What is the most important message you have for the security community?

Spend more time listening to the business side of your organization. So many of us in security come from a deeply technical background and that's where we are most comfortable. We see our mission as battling the wily attacker. The real "battle," though, is being carried out in the boardroom. Unless we are successful in demonstrating real risk to the business leaders, we won't be appropriately equipped to defend against attackers. Take the marketing director or VP out for a beer.

Oh, and also carefully protect and manage your encryption keys!


Can you tell us just a bit about yourself? How did you get involved in cryptography? What do you do when you are not in front of a computer screen?

My involvement in cryptography is really that of an "engineer." Cryptographic algorithms are finicky tools that require lots of study and care to use correctly. Many systems have been broken not because the cryptographic algorithm was bad, but because of a detail in the implementation. My interest in crypto springs from a childhood fascination with ciphers, codes, and games: how do you exploit the rules of a system to bring about unexpected behavior. When I studied math at the University of Oregon, I naturally gravitated toward crypto and ended up doing my honors thesis on DES and differential cryptanalysis.

I spend most of my free time with my family. I used to do a lot of biking, hiking, and rock climbing, but with a young family, a lot of that has been put on hold. As the kids get older though (the youngest just turned 3), we're hoping to start geocaching. Hiking, technology, and treasure hunting combined! The perfect activity for an Oregon tech family. When every one goes to bed, and my clients are momentarily quiet, I pick up one of my guitars. With Native Instruments' Guitar Rig and Ableton's Live (and a lot of audio editing), I'm the next Jeff Beck *smile*
<<Thought Leader Home

SSI Application Security-Secure Coding-skyscraper

Contact us: (301) 654-SANS(7267)
Monday - Friday 9am-8pm EST/EDT