Customer Reviews

Cryptography in the Database: The Last Line of Defense

5 star:		(3)
4 star:		(3)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

Iorn mountain, UPS both had very drastic failures this year, backup tapes with thousands of customer records were lost. Everybody in the industry is scrambling to figure out how to encrypt the backup tapes. Most of us feel the option of simply making a backup of already encrypted data is a better choice than piping the backup through an encryption process. This book arrives in our hour of need and it has the feel of a been there, done that author.

The code examples are MySQL and Java 1.4.2 and really helped me understand just what needs to happen. The majority of the book is platform agnostic, so if you run a different platform it will still be valuable.

The book is well written, well edited, well laid out, what you expect to see from Addison-Wesley and Symantec Press.

The only thing that drove me crazy about the book is on page 163, the author recommends HSMs ( Hardware Security Model) for storing the keys to the kingdom, yup, yup, I agree, we all agree. And then he goes on to say, Java 1.4.2 does not support this -- ouch! However, his code examples are a nice work around using AES on the local engine which is good'nuff.

Got sensitive data? Then get this book!

To be honest, when picking up this book, I was not interested in implementation details and internals of database cryptography (part II), but more in enabling database security by means of encryption (part I). Therefore, I was coming more from the user vs developer perspective. I was even less interested in managing the database cryptographic project.

As a result, I enjoyed the part I on database security with motivations, attacks against databases, threat models and a primer on securing databases with cryptography. If you are "doing security" read part I, if you are implementing database encryption or record hashing - read the rest of the book.

Dr Anton Chuvakin, GCIA, GCIH, GCFA is a recognized security expert and book author. A frequent conference speaker, he also participates in various security industry initiatives and standard organizations. He is an author of a book "Security Warrior" and a contributor to "Know Your Enemy II", "Information Security Management Handbook" and the upcoming "Hacker's Challenge 3". He also published numerous papers on a broad range of security subjects. In his spare time he maintains his security portal http://www.info-secure.org and a blog at http://chuvakin.blogspot.com

When I pick up a Symantec Press book, I will either love them or dislike them. I never have mixed emotions about them. This book I love. His book should be titled, Database Security. While the primary focus is on encryption, the author dives into several topics I wish some of my past DBAs had known.

The book is divided into four major parts: Database Security, A Crpytographic Infrastructure, The Cryptographic project, and Example Code. I however would calssify the book into two major parts. The first part is reading and understanding some fundamentals that are very important. Throughout this first part, there are many graphical presentations to help the reader understand, in a graphical way, what the author is discussing. This is most visible in the third chapter entitled An overview of Cryptographic Infrastructure.

The second part of the book is actual code written in Java, and designed for plain SQL, the author does confirm that all examples work in MYSQL. The examples give common scenarios such as consumer input. Consumer input requires first name, last name, credit card information, the verification code and other fields. This example discusses and demonstrates a best practice model around that code.

Given the two parts above, this book is solid, and I would have recommended it. However, the author went a step further, and included information on security surrounding the database, penetration testing and methodologies for databases, architecture and design best practices, and so many other important points. This makes this book valuable to anyone working with databases.

The section breakdown is as follows:
* Database Security - Common Attacks Against Databases; Laws and Regulations; and Cryptography
* Cryptographic Infrastructure - Introduction to Keys, and Their Management; Engines and Algorithms; and Vaults, Manifests and Managers
* The Cryptographic Project - Outlines the Security Culture; Hardening, Classifications, and Policies; Securing Design; Securing Development; and Testing
* Example Code - Key Vaults; Manifest; Key Managers; Engines; Receipts and the Provider; The Consumer; Exceptions; and the System at Work.

Overall this book is geared to medium level technicians for best practices and coding examples. Although anyone working with databases in general could find something useful in this book, even if its design, architecture and implementation best practices.

Much attention has been focused on network attacks by crackers, and how to stop these. So powerful software like Snort and Nessus have emerged, with books dedicated to them. But Kenan describes a relatively overlooked situation, where you might have to encrypt your database. The main reason is confidentiality. You don't want unauthorised usage. Either for copying or changing.

Here, you still have to defend against network attacks, possibly by using the above tools. But now there is the chance that your users or sysadmins might have nefarious intent. So the book shows how to design a system such that various columns in a SQL table can be encrypted. Different keys could be used for different columns, though a given key might apply over several columns if you wish.

The book uses a symmetric key cryptosystem. It downplays a PKI system. Those are slower. Plus their forte might be for distributed systems. Here, the scenario is more likely to be a central data centre.

There are several excellent system diagrams that nicely describe the data flow, and the various software (and perhaps hardware) players that make up the system. In essence, there needs to be an entire key management system along with a cryptographic engine. The former handles requests for a key by generating one and an alias for the key. Plus it stashes away the keys, preferably in a separate computer. There is even the necessity for a key to encrypt the keys!

Kenan also explains a "honeycomb". You may have heard of a honeypot, which is a dedicated computer or maybe an email account, that is used to attract crackers and spam. Well, a honeycomb could be a table in the database used for a similar purpose. Or even some rows in a given table. If these are accessed, software alarms go off, because no normal usage of the database should do so. Nifty idea.

Code examples for a simple system implementation are given in Java. Though if you are considering this book, you are likely no tyro in whatever language you use. The Java code is straightforward enough to be understandable and recoded.

Noted security guru Marcus Ranum has observed that "these days, with the kind of plug-ins that come in your typical browser, combined with all the bizarre undocumented protocols used by new Internet applications; makes it highly unlikely that a firewall is doing anything more complex than a thin layer of policy atop routing. As such, the applications behind the firewall are now more critical to security than the firewall itself. Which should scare the holey moley out of you."

Taking Ranum's observation to the next level, it is not only the applications that need to be secured, but databases also. The theme of Cryptography in the Database - The Last Line of Defense is that databases, being the main repository for critical consumer and business data, are often not given the adequate level of security that they deserve.

Large databases often contain terabytes of data. This data often contains R&D, client, customer data and more, that if compromised, could wreak havoc on an organization; both from a public relations perspective, in addition to a regulatory perspective. In a large customer driven organization, a database breach can wreak havoc on tens of thousands of customer records. With all of that, companies will spend large amounts of money on the security appliance of the month, but often let their databases sit unprotected.

Cryptography in the Database is a valuable book in that it shows how a formal methodology is required to adequately protect large corporate databases. The emphasis of the book is on designing and integrating a cryptosystem into the database to protect it against the various threats that are specifically launched against corporate database systems.

The books 4 parts contain 21 chapters. Part one is brief overview of the need for database security, along with related threats to database, and also covers the basic concepts of cryptography and encryption.

Part two provides a comprehensive synopsis on the cryptographic infrastructure necessary to secure corporate databases. Chapter 3 goes into details on how to set up an effective key management scheme. Such a scheme is crucial as the author notes that all it takes is the loss of a single 128-bit key, and gigabytes of data can become inaccessible.

Part two also creates a sample cryptographic architecture that is flexible and modular so that it is easily adaptable to various situations. The author notes that such systems can be difficult to manage if they become overly complex, and the challenge is to find the right balance between security and complexity on one side, and usability on the other. Creating an effective cryptographic database infrastructure. is not an elementary task given the different requirements of security and functionality.

Chapter 3 details the various entities that go into a complete cryptographic architecture, including the cryptographic engine, and the various controls around the crypto keys. The chapter provides a good overview of the key life cycle. Historically, controls around the key life cycle are crucial. One of the ways the Allies were able to break the German Enigma cipher machine during World War II was that the German's reused their crypto keys, which obviates much of the security that cryptography can provide. Had the German's not done that, the outcome of the war may have been dramatically different.

Part 3 details the issues that need to go into the entire cryptography project. Kenan notes that for security to be effective, it must be dealt with at the commencement of a project and must permeate the overall design and seep into every line of code. Also, in the long term, developing a culture of security depends on looking at security as an opportunity to provide extra value. Where security fails is when it is viewed merely as a series of checklists that are meant to get in the way.

Chapter 9 shows how data flow diagrams can be used by a database analyst to better understand how a system works. These data flow diagrams are valuable as that they show the various inputs into the system and where potential failures can crop up.

Part 4 provides various Java code examples of the cryptographic infrastructure that were detailed in the previous 12 chapters. The example code is meant to show how to implement the primary functionality of the various components that the book describes.

One of the popular terms in security today is data at rest, which refers to all data in storage. Businesses, government agencies, and others need to deal with attacks on data at rest, which more often then not will be found on databases.

After reading Cryptography in the Database, the reader can understand why database cryptography must be implemented in a methodological fashion, since incorrectly implemented cryptography can often be worse than no cryptography at all. With that, database administrators, architects and others who have input into the design of database security are highly advised to read Cryptography in the Database.

Databases are far too critical to an organization to be left unsecured, or incorrectly secured. The database is indeed the last line of defense in an organization. Books such as this are thusly vital to ensure that the last line of defense is not easily breached.

I purchased the book in attempt to figure out a "best practice" way to encrypt information in a web-facing business database.

I think the book delivered a best-practice approach, but I didn't find it as useful as I'd hoped despite learning a lot both theoretically and practically.

There are a number of caveats I wish I'd known about this book, in rough order of importance:

1) If you aren't using HSM hardware to store the keys, this book's practical usefulness appears to decline a fair bit, a point the author seems to acknowledge. Your key information ends up stored in databases or systems which themselves can be compromised. There's a lot of machinery to encrypt the keys and replace them over time, but fundamentally you are just raising barriers with this approach, not really securing anything (as far as I can tell). It seemed like a lot of implementation complexity for a mild amount of obscurity, as far as I was concerned (since the book is published!) If, say, you have a webserver connecting to a database and your webserver is compromised, and the attacker can get to your database, the encryption here will slow, but not stop them. If only the database or its backup is compromised though, his stuff is great; it'd be hard to recover the data. But that's not the threat model I think most web-facing database companies are concerned about; there the webserver gets compromised first. In a webserver+database-noHSM model, I'm not sure all the obscurity his system provides is worth the implementation complexity-- a simpler alternative approach that provides most of the benefits would have been helpful.

2) The book's approach does not describe/give-code-for any practices or infrastructure in which one might store (or migrate) some information (e.g. credit cards) offline in an attempt to secure it, placing the information online only temporarily (e.g. when doing recurring billing, sending email blasts with personal information, etc).

3) The book does not cover any asymmetric encryption techniques, dismissing them early on since they "aren't necessary for solving the problems in which we're interested". Maybe I'm missing something, but it would seem to me that if the usage/data-retrieval model for one's application allowed use of offline private keys (or a password to unencrypt an private key) entered at the time of data retrieval, data in the database could be stored write-only by an application (using a public key stored in a database) and delivered read-only only-to-an-authorized-user without ever storing the key information necessary for read-able retrieval in any online database. (This assumes the information never needs to be read by the application without the user present.)

4) The Java code is fairly helpful but, as the author notes, it's a prototype and you will need to add alerting and exception handling for any production system.

All this doesn't make the book "bad"; it's a very good primer on symmetrically encrypting information in a database and managing the entire security process surrounding that. I concur with the other good reviews here; it probably is a 4-5 star book for most people. But I found myself just hoping for something simpler (given the assumption of no HSM) and/or more secure (when facing different usage constraints) than what I was left with.

I kind of went in expecting this to be some form of "marketing spiel" for someone's embedding of crypto tools into one or another DBMS. I was pleasantly surprised, instead, to see that this was much more an "analytical" work; something of an account of some of the practices at Symantec.

What is particularly laudable is that they start not by explaining crypto technologies, but rather motivating things by enumerating a threat model. Sensitive data needs to be protected from various sorts of attacks that can come from outsiders as well as insiders, the latter requiring *much* more care as they may legitimately need to have access.

The assumption (which seems entirely valid) is that crypto keys need to be particularly carefully managed as a *very* tightly restricted database of their own.

The examples quite conspicuously *don't* involve cryptography taking place inside the database; that practice is one that would necessarily be equivalent to giving all of the keys to the DBAs and/or system administrators, as they control database engine deployment. Instead, crypto activity takes place outside the database; secure applications require a particularly secured portion of the application infrastructure.

The one place that they get a bit "hand-wavy" is in proposing that Hardware Security Modules are the only really forcible way to achieve strong security. I tend to agree with that doctrine; I suspect they intentionally glossed over it in that their approach of using standard Java libraries for all of their examples did not admit the ability to use HSMs. Implementing an HSM requires going to a great deal of trouble, and that feels like it ought to be a subsequent project for another book.

In view of emerging sorts of privacy legislation that mandate keeping data secure, this looks like one of the books that anyone storing sensitive information should read and heed...