Slashdot Mirror
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.
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.
I can't tell you how many times I've seen apps all using the same credentials to log into the database... The ID and password are hardcoded into the app, and it's the same for all the vendor's customers. And no, these aren't little one-off apps for small businesses, these are enterprise apps. I've also taken advantage of this fact for pen testing....
I have certain programs on my computer that can get past my firewall for various reasons. I often wonder about some of the biggest heists in the world, they're usually done by someone on the inside. If your network is locked down and something from the inside punches a hole in it how do you control any of that?
Generation Trance: What generation are you?
At least in California, the data compromise notification law makes a specific exception for encrypted data (which is usually on backup tapes).
It may be just me, but I honestly have to question whether someone can really be a "security guru" when they tell me that something should "scare the holey moley" out of me (or anyone, for that matter). That kind of sensationalism just leads to blind panics and failed attempts at security that actually makes thing less secure than they originally were.
What's more, someone who actually knows something about security (whether it's computer security or not) should not have to resort to that kind of attention-whoring, anyway - so if someone still does, it also makes me wonder just how competent they really are.
quidquid latine dictum sit altum videtur.
On the new Battlestar Galactica, the rule is you don't connect critical computers to other computers. This limits the damage the bad guys can do.
There was that one episode....
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Sorry, but it needn't be that hard to do, given the right tools; the author is really scaring off the troops fm even attempting it.
You need to design against what's widely accepted as the most usual scenario, intrusion by an insider. Requirements shd include not less than the following:
Protect against data visibility even in the worst case, a massive physical compromise of the entire database.
Compromised access to any single record must not lead directly to compromised access to any other record.
I did field-level encryption against these requirements at a major federal agency, and the result got blessed by the security troops there.
What I've seen happen is that there's two different cultures working here: When you ask the application guys what they're doing re database security/encryption, they'll too often reply " It's a network problem, so go talk to those guys. " Ask the network guys what they're doing re the same thing, they'll too often reply " That's an application problem, so go talk to the application troops. "This hurdle needs to be cleared if there's any hope for progress.
First you need to allow more then just http through the 2nd firewall since it needs database access...
Second, firewalls really don't do that much for you. They stop things like blaster which attack an open port on the operating system, but let's fix the damn oeprating system to patch those holes, not just cover them up with a rug.
You don't really have to "hack through" a firewall. The hack is you leaving any ports open. If I can get through http, that's all I need. The real protection should be that all incomming and outgoing traffic from http will not harm your system in any possible way.
It looks like the main purpose of crypting your personal data in a database is so that people that have access to the database cannot read the information in plain text. If you're using Oracle, you can put permissions on each of the individual columns to mimic the same results crypting your database would produce. These people are really just worried about their data readers opening a sql client and just extracting information, kind of like how you're luggage goes through an airplane. We'd like to think that the workers there won't steal anything out of our luggage, but we sure as hell won't put our luggage through without a lock on it at least.
Security to me is a huge deal, but beyond my application level security and the permissions I put on the data, most other things are out of my control. The solutions people propose do nothing but delay me in my work that I should be doing instead.
I'd rather push all of this burden to the people that can really make the difference in this field. The manufacturer's of the software that run our systems (os) and the servers (apache/mysql/ms*/etc.), you make those secure, and we won't have to be this damn paranoid.
Secure software is not impossible.
You can't just encrypt your data and share keys. If you do, then the compromise of a key provides access to that data. If someone hacks into your network, maybe that key will be found somewhere on a system that they compromise. Then, they can actually evesdrop on the database connections and pull data as it is being sent across the wire without authenticating.
A better solution (and one that PostgreSQL uses) is to use SSL to secure the connection and thus encrypt the traffic to and from the server. Yes, if you compromise the database server, you get the data anyway, but in the other approach, if you compromise the key management server, you might get far more than the data. Note that PostgreSQL also supports client-side certificates which, while not perfect, provide an added layer of security (cient-side SSL is a host authentication mechanism, not a user authentication mechanism so normal login requirements still apply-- basically now you have 2-factor authentication).
The second vital area is that of access control. Encrypting your data doesn't do you any good if you don't adequately lock down access. Shared database accounts? No. Use one account per *user* and use groups/roles for access control.
Finally, encrypting some data in the database might be required by some applications (for example, if you store credit card transactions in your database so you can later reverse a charge, the PCI-DSS requires that the number is encrypted in storage). But encrypting most data will simply prevent your relational model from working properly.
LedgerSMB: Open source Accounting/ERP
You just fine them. Negligence has nothing to do with it. If their oracle database has an exploit, too bad - they should have made oracle agree to pay in the event of a breach. Oracle won't do that? Hmmm. As the business folks are so happy to point out, the free market will find a solution.
I suggested something similar a couple years ago after the big blackout. All the utilities were clamoring for handouts from the government to modernize the power grid. My solution would be to force them to pay X amount per hour to each customer that goes without power. People got all defensive... Oh, they'd go out of business and stuff like that. So what? Let them go bankrupt - someone will buy the pieces and spend a bit to make upgrades. Airlines want a bailout? F-them. Let them go under and sell the assets to competitors - air service will not suffer.
If you want to play capitalism, you have to be willing to take a risk - its part of the game. If the downside is always protected you're cheating (the public). Same applies here. If you want customer data to be secure, you've got to have penalties for data loss - the market will figure out the solution. People always jump to the opposite end and say no one will play because they can't afford to. Duh! Just don't make the penalties astronomical, but do make them hurt a bit.
No one is willing to use negative feedback on corporations though, so evolution on a larger (national?) scale will eventually take care of things.
That's why application layer firewalls are such a big deal. They are supposed to understand what data and more importantly what kind of data specific apps from both sides are supposed to be generating and filter at that level. They can be a royal pain to design and keep running. With custom apps, however, it's a whole different story.
One of the great concepts I learned at my last training was the idea of compartmentalization. This is after many other layers of defense, but the idea is even if you are compromised, they get nothing of real value.
There also many, many other ways to add protection: gambits, exclusion, audit-traps, active detection, etc.
Like the author, one of my big concerns is with poorly written apps. Anytime anything is specifically designed to release data but has restrictions on who gets what and how, you have a security concern. I have seen companies go to such extremes as pushing data to the screen as one big jpeg to keep from anything grabbing said data (of course, there are tools that can grab visual data from graphics just like humans now). My biggest concern is the original and still number one concern of all types of security: corruption from within. Be it sabotage, espionage, or unintentional damage (virus) the equipment and personnel inside an organisation is always more dangerous than those outside it.
And that's when manageing your information through compartmentalization and multilayer defense, etc. come in. You may get in systems, but you are not getting anything of real value and you aren't getting out again.
[RIAA] says its concern is artists. That's true, in just the sense that a cattle rancher is concerned about its cattle.
Even if data transfer is one way you still need the other way because of how TCP/IP works with acknowledgements and retransmit requests. Your idea of removing wires would break all network communication.
This seems like a very odd quote to use to introduce this book, because one of the things Ranum seems to be talking about is that use of encryption and complex protocols can make security worse.
Why worse? Because the firewall, mainstay of our security efforts, becomes less and less effective. In the old days, your firewall could give a fairly cursory glance at packet headers, and have a good shot at catching the bad ones. Now, the packet header isn't so useful, because there is complex stuff inside the packet --- protocols are layered three deep or more.
That's why we need security at the application layer, instead of at the network transport layer --- the network transport layer just doesn't "know" enough to catch threats. What makes this really scary is that there is less of a bottleneck for the threats. It's nice as a defender to have a bottleneck you can protect. If the bottleneck goes away, and you have to protect all the applications, that's pretty scary.
Cryptography isn't going to give us a lot of help here, IMO. Yes, when our security has been breached, it can give a second line of defense, but that's about all (and even that seems a little suspect in a world with keystroke loggers).
I used to work for a software company that is the second largest player in their market. Their software is in use at companies tracking the time records of 40,000+ employees. Within two months of hire - as a phone support tech - I was able to write an application that would bypass the security auditing of the system, open the internal database and write in false clock in-out times for an employee. I showed how to automate this process in a semi-random way so that you could never come to work, but you would show in the database as punching in and out every day at different times. Their reaction? "No one will do that." I thought about selling my application, and still do.
First, where does Oracle store that magical key? Somewhere OBFUSCATED? We all know about security by obscurity right?
Than, PostgreSQL implements stored procedures and triggers which makes it easy to automate encrypting of columns too, or do any transformation on reading/writing from your records automatically. (Yes, function based indices and other goodies too.)
Quite likely someone already wrote something like this, and maybe it is even in your contrib/ directory. But it sure is more sensibly named than DBMS_OBFUSCATION_TOOLKIT.
Last, I bet Postgres supports more languages for programming embedded procedures in than either Oracle or DB2.