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 think most companies know the importance of security on firewall, server, application and database, but trying to get a budget for such measures is another matter.
So maybe to most companies, extreme-security is a gamble they are willing to take, or they simply don't value customer data as much as customers do.
We have seen so many cases of stolen university data, or even credit card details, but when have we heard a Press Release saying "no worries, the data is crypto-protected with this how-many-bit technology".
Rock that crushes, Paper & Scissors that don't matter.
The larger point of database security measures notwithstanding, I think the days of the "dumb" application-blind firewall are over.
Most companies that handle credit cards in modest amounts are required by their providers to use application-aware systems like Teros, which inspect every detail of every transaction across the border at the highest levels - providing a redundant check in the form of a policy controlling things like what cookies and querystring values can accompany a request for a particular path, and looking for things like cookies appearing that you didn't set, or form values being submitted that weren't in the HTML form you sent out...
Tired of Political Trolls? Opt Out!
The only way to convince companies to spend the money to protect consumer data is to make it more expensive for the company not to implement basic safety features by punishing companies monetarily for loss of consumer data such as social security numbers and birth dates on a per consumer or record basis. Other consumer information such as name/telephone number is obviously not as critical and should not be subject to monetary fines/punishment. Every company that stores SS#s or Drivers License or Passport numbers would then have a financial motivation to do everything possible to protect critical consumer information or not use/store it at all. Given all the national security issues, this should be easy to justify since identity theft was identified by the Administration as a national security threat. As for protecting the company's own information, it should be pretty easy to show the cost of losing the data versus the cost of implementing a security feature. If you notify your boss in writing of the consequences, then if data is breached, he/she will be accountable.
many times I've seen apps all using the same credentials to log into the database...
How exactly is this bad?
The whole purpose of the -database- is to make it easier for everyone to access data. Anyone who deals with databases knows never to rely on database security for... security.
Why would you want to add an extra layer of security/encryption between your app and the database??? Or put -more- load on the database? A busy database can barely keep up with the loads as they are... (storing terabytes in Oracle, here)
Besides, in a properly designed tiered architecture, nobody -but- the app server can access the database, and nobody can access anything -but- the app server (that's what firewalls are for). The app of course can do whatever it wants when it comes to security.
All this business about `encrypting' data or relying on database security doesn't apply to everyone---not by a long shot.
The problem with data security on an open network is not the lack of adequate technology or know-how because current methods of securing computers do work. Otherwise, our electronic commerce systems would have collapsed years ago. The problem is that hackers look for and often find ways of getting around the security barriers by exploiting defects in the underlying software. A network's security is thus intimately tied to the reliability and robustness of the network's software. Security companies have no way of guaranteeing that the various software modules used in their systems are defect-free. This uncertainty is the Achilles' heel of the security industry. The solution is to move away from algorithmic software and adopt a non-algorithmic, signal-based, synchronous software model.
Point of fact, you don't implement crypto yourself. That is the most horrid mis take that anyone can make. Let the security professionals implement it, and just use it. They are far more paranoid that you are and are far better to do this specialised way of coding.
Security is a feild in which you must have a good level of mastery of many different areas otherwise you are a liability. If you don't got that, then don't implement a system. Use one that someone else has written.
IMO, this book will make too many people think that they are good enough to do what they can't do. I can only imagine how many insecure system will be developed because of it.
With Knoppix it is almost stupid to connect a standard PC to the net. If you need a second PC you can now get notebooks for under $400. For most organizations I bet one of these PC's with Knoppix is cheaper than securing an employee's primary PC considering security software and administration. And is a whole lot more secure. Add a thumb drive with sever restrictions if some network crossover is required. Knoppix is very configurable if you need to make custom implementations.
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?
You don't. If someone has access (user or physical) you have no real defense. You have to trust the people you give access to and hope that the repucussions of wrong doing keep them honest.
Platform advocacy is like choosing a favorite severely developmentally disabled child.
1) Use your firewall to block everything except port 80.
2) Invent a generic TCP/IP tunneling protocol over HTTP (like SOAP); call it TP.
3) Tunnel all your network traffic through TP.
4) Problem solved!
The beauty of this system is that you can run TP over TP as many times as you wish, adding as many layers of security as you feel necessary to keep you from shitting your pants over the big bad hackers who are pwnz0ring j00r data.
There must be a master key somewhere, so the database itself can see all the unencrypted data. If not, then indexes are meaningless as the fields to be indexed would be gibberish and not subject to any form of ordering. Database performance would tank and large systems would be unusable.
This master key must then be highly guarded. If it is kept on the machine, it is subject to pillage just like any other compromised machine and the encryption does no good. If it isn't, then whenever the database service is restarted the key must be fetched.
The current forms of database protections -- views & user rights -- limit the data available to the various users. These are usually not properly implemented and can provide a great deal of protection in shared databases.
-Charles
Learning HOW to think is more important than learning WHAT to think.
Firewalls have become largely irrelevant because they stop people from doing things, so people specifically design applications to easily pierce a firewall!
Thus, the firewall becomes less and less relevant with time.
Originally, the great designers of IP gave us any number of protocols, and 65,534 ports in each protocol. Different applications could use different ports, and these ports would identify what application you wanted to connect to. Port 80 was used for web traffic, Email uses port 25. This gives incredible room for growth and expansion, and was "a good design". (TM)
Firewalls block all but ports 80, 25, 443, and maybe a few others. Thus, many applications are now built using ONLY one of these ports!
So now, we have the dog, the kitchen sink, Instant Messaging, RSS, XML/RPC, and god knows what else tunnelled over port 80. Dude, Like where's my firewall?
So, push comes to shove, there are no real shortcuts without a long term price.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Apparently, "slavemowgli" believes that you cannot use humorous or colorful language if you want to be taken seriously.
Calling attention to a common problem is hardly sensationalism. For it to be sensationalism, it would require exaggerations, and unsubstantiated claims. Something like, "Unencrypted databases make firewalls and other network protections completely irrelevant [overstatement], and will cost industry more in the next few years than all the phishing and spyware in the world [unsubstantiated]."
That would be cheap sensationalism, not just colorful writing.
I had forgotten how much cooler teenagers look when they are smoking. Oh, wait
Which is why, my friend, next time this happens, you say nothing.
It is the job of the people getting paid (management) to hire competent developers to protect the data of consumers of products made by the company owned by shareholders. If these people fail in their duty, the company should lose enough money to make the shareholders hopping mad and terminate and sue the management team.
The shit has to hit the fan before things get better.
"Piter, too, is dead."
You know, where you _review_ the book? As in whether the book is high-quality, or not. As in whether the author is a good writer, or not. As in whether the contents are relevant, or not. As in whether I should buy the book rather than some other book.
Instead, we get a synopsis of what the book covers, plus a blurb for why the topic is important. Yes, securing databases is important! Yes, Part 4 provides Java examples! But why do I want to buy THIS book about securing databases? Why do I want to buy THIS book with Java examples?
They should have some sort of guidelines to follow. They could call them "Slashdot Book Review Guidelines". The guidelines could include points like "Is the book readable as well as technically accurate?" and "How gracefully do you expect the content to age?" That would be amazing.
Then there's data which will only ever be accessed or changed by the user themselves, so why not encrypt it with their password (which isn't stored in the database either) -- it might be inconvenient not being able to "just go in and fix stuff" if the user forgets their password, but sometimes it's worth it for when the database gets cracked and you can say for sure that no information was revealed.
These approaches only work when used sparingly and only for information that doesn't need to be presented differently by the backend (i.e. for reporting). All a translucent database is, is a data storage engine. It is not and will never be practicle on an enterprise, production RDBMS for reasons that RDBMS's do plenty of intelligence things that cannot be done if you cannot access the data.
Translucent databases are fine as far as they go, but if you are going to do that, why use an RDBMS anyway? The relational model really breaks down when you start trying to make the data inaccessible to the backend, and as such an RDBMS becomes nothing more than a standard interface for accessing rows that could just as easily be stored/accessed using an OODB.
Again, some data may need to be encrypted. But this needs to be a last resort rather than a first impulse and used as sparingly as possible to guarantee the required level of security.
LedgerSMB: Open source Accounting/ERP