Cryptography in the Database

Ben Rothke writes "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."" Read on for Ben's review. Cryptography in the Database : The Last Line of Defense author Kevin Kenan pages 312 publisher Addison-Wesley rating 9 reviewer Ben Rothke ISBN 0321320735 summary Excellent reference for those that are serious about securing their corporate databases

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.

You can purchase Cryptography in the Database from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

I might be wrong here but...

[Volanin]

Isn't this exactly the kind of security that Reiser4 wants to address via its plugins system, while also adding more speed to the filesystems?

Openwall

[Broadcatch]

There's no doubt that running a secure OS and adhering to good practices (such as never do anything as root that doesn't have to be done by root) is increasingly important these days. One client I work with is running Openwall and it seems to be a good solution. There are many other security enhanced Linix possibilities, too, as well as OpenBSD - which I don't have direct experience with, but I hear it's pretty tight.

At home, I just keep up-to-date with Debian and practice careful management, but for any corporate systems, I'd start with a secure OS.

Re:Scare the holey moley?

[Jokkey]

Actually, Ranum tends to speak out against blind panics and failed attempts at security (see point #6) and attention-whoring. While I understand your point, I'm not sure that it's fair to accuse him of doing what he speaks against just because he says that the state of a particular facet of computer security is scary.

Re:Must agree altogether

[pegr]

Act! does this and it pisses me off. It's a special instance of the MS SQL Desktop Engine (you should already be worried) with a SE password known only to the app. There's a tool that you can use to reset it (probably where I'd start if I wanted to capture it), but you can't ever get it to reval it.
 
Write a PERL script that listens for connections and fakes the authentication routine. Point your app at the host running the script. Have the script record the authentication credentials the app uses. Have the script respond to the app with a "failed login" equivilent. Bingo, got your SA password... (Post it to Slashdot when your done, please...)

Re:Battlestar Galactica solution

[drinkypoo]

Unfortunately, that doesn't work in the real world. What you have in the really real world is networks that aren't connected to other networks, or more frequently, internal networks connected to other internal networks via firewall. It's rare that a computer by itself is useful any more...

Re:Must agree altogether

[IdleTime]

I wish I had mod points!

I work for a database company and I can assure you that there are several methods of access identification and internal encryption in the database (security in case the datafiles are stolen) etc.

But security is never a single thing but the sum of several layers of measures which combined give the best acceptable security level. Note! This is not the same as the best possible security level, such a level is not functional.

Database Security

[queenb**ch]

The fact is that most database engines (the entire database application) come with a fairly good security model that almost never gets implemented. There is typically very little done to most databases in the way of restricting user accounts to specific databases (not instances of the engine), tables, rows, columns, etc. One of the biggest lessons in this ought to come from the sheer number of SQL worms out there that look for instaces that don't have a SQL admin password set - DUH! The fact that these are still being issued means that DBA's still have not wised up enough to even set the password. If your security model is so lax that you can't be bothered to either set a password or change the factory default, you're not going to be concerned with minor details like patching your operating system and application, doing any kind of hardening, or setting appropriate access permissions.

The fact of the matter is that until more mandatory disclosure laws are passed companies will simply choose to ignore the simple basic things they can do to secure a database. Security to many (PHB) managers is a widget of some kind that they can buy and plug in to their network. This writer ignores a very simple flaw in his logic. Typcially, one compromises the database to get the box. If I own the box, encrypting the contents of the datbase won't help you any. It's going to have to be encrypted in such a way that it can be decrypted for use, unless you plan on turning all your data into MD5 hashes (evil grin).

Given the assumption that you want to be able to decrypt your data, you'll have to have the means to do so either stored on that box or on the receiving box, which is also likely on your network. If it's stored on that box, guess what, I've got access to it since UR ()WN3D. If it's another box, hey, I got this one so I can see what this one answers requests from and then I know what I need to ()WN next. Since your security on box was obviously lax enough to let me in, getting the next box down the line won't be any harder.

Mind you that all this assuming that I don't fire up the Beowulf cluster and just crack your encryption the hard way.

2 cents,

Queen B

Database encryption hasn't been important...

[ahmusch]

... but it sure is now, and here's two giant reasons why:

HIPAA
PCIDSS

Both specify, more or less, that sensitive information must be encrypted within the database. That means the data at rest on disk must be encrypted. Encrypting customer-sensitive information in the database will prevent exposure of customer sensitive information from:

Disk-scraping attacks (such as if the storage rep who replaces a failed drive in the SAN is ethically challenged)
Backup attacks (where a complete database backup can be restored and hacked)

What doesn't it save you from?
Users who have rights they don't need looking at data they don't need.
Users who don't need access to the system but have it anyway.
Poor security standards (not changing default passwords, insufficient password strength, etc).
The DBA, who can always log in and see whatever the heck he wants(I almost said he or she, but who am I kidding).
The SysAdmin, who can become the DBA, and can scrape the disks himself.

What are the costs of encryption?
1. It will cost you CPU cycles. (Don't even think about sending all the crypto calls over the wire to a hardware module -- it'll cut application througput in half).
2. You won't be able to have queries like "Select name from patients where ssn between '5030000000' and '503999999'" use indexes, as the ordering of crypto is gone forever.

What's being done about this?
Enterprise vendors are busy rolling out encryption solutions (the other security holes already have support around them, but often aren't implemented in applications.) DB2 lets you encrypt the file system, or tables, or values within tables.

Oracle lets you encrypt columns within tables with AES128, AES192, AES256, or 3DES. (You can also set it up so that the same value in 2 columns has the same ciphertext, which is a good thing.)

SQL Server's got... something, but I don't support it, so I don't care.

(PostgreSQL and MySQL users, I left you out on purpose. I said enterprise vendors, and I meant it.)

Re:Border security

[yosemitesammy]

Level 1 service provider ... recently passed PCIDSS v1.0 compliance ... auditor was Cybertrust, an approved auditor, and yes we have the 3rd party scans quarterly, and NO application aware firewall is required, either in the PCIDSS standard, OR the Audit Procedures.... I've got a ROC to prove it. Additionally some flawed items from PCIDSS are that certificates and password is sufficient for 2-factor authentication, that NAT is required as a security feature, and that *Compensating Controls* can be accepted by Visa instead of compliance with the PCIDSS standard ... IE: an additional firewall limiting access to cleartext database server rather than *actually* encrypting or rendering unreadable account # information in the database everywhere on disk or on tape.... see a big processor's example of a compensating control. I know for a *fact* that FDMS and VISA are current in violation of at least a portion of PCIDSS, as the routers and switches VISA deploys as part of a DEX package are not capable of SSH (v1 or v2) and neither is FDMS's equipment.

Money

[C10H14N2]

Granted, hard-coding those values is pretty absurd, but the single login does make sense, mostly financial, but in a very, very non-trivial way.

When you're sold an enterprise server for an enterprise app with a $1250 per-seat (much less named users) fee and you have 5,000 concurrent users, that's $6.25 million. You can buy the same server with five or ten user licenses for $40k. Provided the application is secure enough, the cost v. benefit of having per seat licenses just doesn't pan out. Cut another way, fine, you have named users passing through to the database and those logins come through the application. Does that _really_ make you much more secure if those logins can be compromised? Sure, you might sniff out the lowliest account, but if you can do that, you can sniff out the admin account as well. Where's the $6M advantage? I'm seeing a subtle variant of security-via-obscurity here. "Gosh, if they have to pick from thousands of accounts instead of dozens, we're secure!" Right.

Case in point: The state of California was sold a named user license by Oracle for $1.5 BILLION. That's right, name every goddamned user working on the State of California network. Not really much different than a per-seat license, but I suppose they could have saved, say, a billion, leaving them with a $500,000,000 database license. I believe the purchase orders -- and the careers of those who signed them -- were cancelled prior to payment.

So, where do you draw the line on this nonsense? 100 users? 1,000? 10,000? Does it really make a difference? If you can hack 1:100, what's the value of reducing it to 1:10,000?

Re:Doubly hard for Databases

[Rodness]

I disagree. SSL is only useful for protecting data in transit, where the data is only valuable in transit. Too many companies make the mistake that if data is protected while on the network, the databases don't matter. Then malicious intruders who hack in past the firewall have unfettered access to clear data.

Don't misunderstand me, SSL *IS* a useful part of a secure design, but it's only a part and is in no way a security solution in and of itself.

A more optimal solution is one which encrypts sensitive portions of the database. XML-Encryption and XML-Signature are good examples of how to represent data with sensitive bits encrypted and/or signed. It's the data in the database that's important, not the connections to the database, so it's the data which should be secured at all costs.

Using X509 certificates, data can be encrypted via a session key, which can then in turn be encrypted with the various certificates of people who require access to that data. A private key passphrase is then required to gain access to the private key, which gains access to the session key, which gains access to the data. Further measures can be taken such as key separation, where a certain number of private key fragments (ie the owners of those fragments) are required to recover the private key to gain access to the data.

Furthermore, if the database is encrypted then an intruder can't gain access. I completely agree with the statement that the database is the last line of defense, and should therefore be Done Right(TM).

My work revolves primarily around network security, and even in my own company I've watched divisions of people design applications with the intent of tacking security on later. Encryption is NOT a panacea, digital signatures are NOT a panacea. Intelligent key management infrastructure is difficult to do right, but investing the time and effort up front leads to the ability to easily leverage it and reap its benefits in many different ways down the road. Authentication, authorization, key escrow and recovery, nonrepudiation, and so forth. In addition to key exchange for sending encrypted data.

The people that stand up and shout about the evils of shared encryption keys have a point, shared keys are bad, but key management has evolved to the point where it's becoming useful in the real world. I've written a research paper on the subject (http://www.dodccrp.org/events/2005/10th/CD/papers /081.pdf), in which the concept of secured data is discussed in depth. Anyone interested in discussing it further is welcome to email me (email address is in the paper) or to directly message me through slashdot.

-Rod

Re:Doubly hard for Databases

[einhverfr]

Note that I stated in my post that certain data might need to be encrypted. The example I used was the credit card number as stated in the PCI-DSS.

In general, mixing relational databases and encryption opens up more problems than it solves. In many cases these can be solved (i.e. one hopes that the credit card number is not being used as a key ;-)) but this is not perfect. So my advice is still to use backend encryption *sparingly* because it breaks the majority of your backend features. I.e. you can't do proper reporting if the backend can't process the data. And if it is encrypted either the keys are accessible to an attacker or the backend functions are limited to data retrieval and your application will be required to do its own reporting (application-level views, for example).

Untrue for HIPAA

[peacefinder]

HIPAA [specifies], more or less, that sensitive information must be encrypted within the database. That means the data at rest on disk must be encrypted.

That's not actually the case when it comes to HIPAA. Encryption is not a required element of the technical safeguards for data, it's only an addressable element. See section 164.312 part (a)(2)(iv) of the final Security Rule, which can be found in the Federal Register (volume 68 number 34 page 8378) or on my desk.

The regulation requires the covered entity to implement appropriate administrative, physical, and technical safeguards for protected health information. Encryption is just one element of those safeguards, and an optional one at that. Remember that HIPAA views security as including not only confidentiality, but also integrity and availablility of data. Encrypting data at rest would often be a marginal improvement to confidentiality at a potentially large risk to availablility (or even integrity). It may be a good idea in some security environments, of course, but encryption is not a blanket requirement of HIPAA.

(Even data in transit does not require encryption under HIPAA. It simply requires protection commensurate with the risk. Protected health information transmitted over a dialup line probably does not need encryption, whereas any transmission containing PHI over the internet certainly does need encryption.)

The attacks you suggest solving by database encryption can also be dealt with by policies regarding media disposal and backup media safeguards. A HIPAA covered entity is required to have a media disposal policy anyway, and offsite backup tapes are just another form of data in transit to be protected accordingly. Database encryption may be a valuable additional layer, but it's certainly not the only way to skin that cat.

(Incidentally, about half the Oracle DBAs at my EMR vendor are women.)

Re:Battlestar Galactica solution

[tsotha]

Yes, and that's based in reality. Lots of DoD computers aren't networked. It's a pain to get the results you want from place to place (by some kind of storage media), but even if you were on the inside you'd have to be working on that project to get at the complete dataset.

Re:Firewalls irrelevant because of firewalls

[WoTG]

But that's the point. Almost anything can be encapsulated within proper HTTP packets over port 80 (for example). In fact, there are standards to do just that, such as SOAP. These will pass a statefull inspection because they are proper packets. You need something beyond statefull inspection, you need to be able to magically tell what is a "good" or "safe" http connection from a "bad" http connection.