Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Databases Books Media Programming Software Security Book Reviews IT

Cryptography in the Database 209

Posted by samzenpus from the keep-your-secrets-secret dept.
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.
This discussion has been archived. No new comments can be posted.

Cryptography in the Database More

Cryptography in the Database

Comments Filter:

  • Money Talks (Score:5, Insightful)

    by fembots ( 753724 ) on Wednesday November 30, 2005 @02:35PM (#14149632) Homepage
    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 [slashdot.org] data [slashdot.org], or even credit card details [slashdot.org], but when have we heard a Press Release saying "no worries, the data is crypto-protected with this how-many-bit technology".

    • you won't hear it (Score:3, Interesting)

      by ChipMonk ( 711367 )
      At least in California, the data compromise notification law makes a specific exception for encrypted data (which is usually on backup tapes).

    • Re:Money Talks (Score:2, Insightful)

      by BlogPope ( 886961 )
      but when have we heard a Press Release saying "no worries, the data is crypto-protected with this how-many-bit technology".

      Because what good is 4096-bit encryption when the application, the weak link, has to know the key to decode it? Proper application/network/security design solves this problem, and while encryption might be a part of it any idiot who says "no worries, its protected by ROT-13 (or whatever) encryption" reveals himself to be that idiot.

    • Re:Money Talks (Score:5, Insightful)

      by Feyr ( 449684 ) on Wednesday November 30, 2005 @03:13PM (#14149931) Journal
      working for a software company, i'd say most developper see encryption as a panacea.

      as a real world example. we developped an application which i was asked to beta test (im the sysadmin, i dont do software devel). within 5 minutes i had hacked the application, had full access to the database and every users' passwords.

      when i pointed out the app was flawed, their answer was "that's ok, we'll add encryption to the database before releasing it". in this case the whole design was flawed, encryption in the database would have stopped me for 10 minutes instead of 5. to this day they still haven't fixed it (thankfully, they haven't sold it yet either)

      moral of the story: design your apps properly. don't rely on the buzzword du jour. encryption is a tool, not a panacea. and good security is HARD to design.

      and more importantly, database encryption is mostly snake oil. usually if a hacker get to your database, he found your application first, and he has the key to decrypt your super-secure-2048bit-encrypted-database. it will slow him down for a few more minutes, that's all

      • Doubly hard for Databases (Score:5, Interesting)

        by einhverfr ( 238914 ) <chris,travers&gmail,com> on Wednesday November 30, 2005 @03:59PM (#14150383) Homepage Journal
        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.

        • 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
          • 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
        • The obvious (but perhaps offtopic) thing missing from that list is what some people call "Translucent databases", i.e. a database which is secure against someone with root access to it.

          In the simplest case, that means not storing information that isn't required; what the database doesn't know it can't reveal. e.g. why did the SpreadFirefox.com crack reveal phone numbers? Why are universities' computers haemmoraging SSN's and dates of birth? Just don't store them unless they're specifically required.

          For ot

          • 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 diff

    • Re:Money Talks (Score:3, Insightful)

      by Qzukk ( 229616 )
      Database encryption makes as much sense as drive encryption. Works great, unless they get it while it's running, and face it, the vast majority of database apps are not on a laptop that can walk away. When it comes down to "improving security" there are better things to throw money at than the processor and development time required to encrypt your database.

      Firewalls, proper network design, proper user and access credentialing, proper system maintenance, even proper hardware decomissioning techniques, all

  • Must agree altogether (Score:5, Interesting)

    by pegr ( 46683 ) on Wednesday November 30, 2005 @02:35PM (#14149634) Homepage Journal
    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....

    • Re:Must agree altogether (Score:5, Interesting)

      by TheRealMindChild ( 743925 ) on Wednesday November 30, 2005 @02:44PM (#14149706) Homepage Journal
      While you and I would love to beat the skull of the programmers involved, I shamefully admit I was part of several projects in the same situation you just stated. The problem was, though, the same problem IT deals with everyday... it is a bad decision forced on by management. I remember one day getting REEEEEEEEEMED and practically fired because I "voiced concern" about such. Within the screaming and yelling was reasoning like "No one can get the password", "Even if they did, how would they know what to do with it?", "Nobody wants to remember another password", and my favorite "If you knew what you were doing, this wouldn't BE a security issue". You can't make this crap up. So like everyone else in the world, I did was I was told....

      • Re:Must agree altogether (Score:4, Interesting)

        by mcrbids ( 148650 ) on Wednesday November 30, 2005 @03:48PM (#14150282) Journal
        Really should get to work, but can't pass this up..

        Sometime in 2002, I found a security hole in the implementation of a particular Credit Card processing company's online processing software while implementing an interface between it and an application I was tending to.

        It was the very worst type of security hole - one that would let me order whatever I like from any of their customers without paying a thin dime, without doing anything exotic at all. (EG: File->Save Page; Edit the html file, use it to submit a post with altered values)

        I sent in a simple summary of the security issue found, and included sample code and explicit instructions for what to do and when to recreate the issue, in its entirety. And, I sent it to every email address I could find or think up for this company, along with my contact information and expressed my desire and willingness to assist their engineers. I even detailed a way to completely close the security hole with a minimum of fuss.

        Nothing happened for some 6 months. (!)

        Then, I got a phone call, from somebody who didn't identify himself. He identified me, in a most nervous and rattling fashion. He went on and on about how it "wasn't a security hole", and "nobody works likee that", and how "nobody would exploit it" and even told me what I might be thinking! I said nothing - this guy scared the hell out of me, even though I made perfectly clear my intentions. He went on and on, for perhaps 10-15 minutes, and I was silent the whole time. He never once asked me a question, other than to identify me!

        Finally, he hung up, and that was it. I've never heard or seen anything since, and I've had the same email addresses and contact info. I have never publicly revealed the company involved, and don't intend to. If they get screwed by the security hole, they clearly deserve it.

        But I sure as hell refuse to do business with them!
        • 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.

        • i know of an online store that will still let you edit the URL to change the final billing amount, though i think their ordering system is hand processed so hopfully the human filling the order would see the problem

          • i know of an online store that will still let you edit the URL to change the final billing amount

            I know of a certain online bookstore that would let you do hand edit the rating you gave book reviews (since fixed) without doing any validation.

    • Unix scripts always take the cake. They have login/pw hardcoded into them to perform automated admin tasks. Then of course they get backed up, printed out, shared, etc. A nice big security leak.
    • Or how about the gazillions of web applications and intranet code where the webserver MUST connect as the user that owns the database? Garrr... just stick a grenade in your server, it's faster.

    • Money (Score:3, Informative)

      by C10H14N2 ( 640033 )
      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,
    • No problem, just store the ID and password in the app as an encoded string. When the app starts up, it just decodes it using the ... Oh, wait.

  • I might be wrong here but... (Score:3, Informative)

    by Volanin ( 935080 ) on Wednesday November 30, 2005 @02:38PM (#14149647)
    Isn't this exactly the kind of security that Reiser4 [namesys.com] wants to address via its plugins system, while also adding more speed to the filesystems?
    • 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?

      I'm sure that all those enterprise DB users will very, very shortly convert all their DBs to Reiserf4.

  • This has been a concern of mine for a while! (Score:3, Interesting)

    by GecKo213 ( 890491 ) on Wednesday November 30, 2005 @02:41PM (#14149678) Homepage
    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?
    • 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.
    • 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?

      I'll put specific names where you've only talked generally. At work, I have a brand new Windows XP Pro machine. It had a built-in firewall which is designed to prevent internet access (in or out) w

      • At work, I have a brand new Windows XP Pro machine. It had a built-in firewall which is designed to prevent internet access (in or out) without specific permission from me, the user and Administrator of that computer.

        You don't have a firewall, you have a program that attempts to implement a network policy on your PC. As you found out, it can be compromised.

    • You'll need some physical security of course. Given that plus SE Linux, the only info that gets out will be what the insider can remember in their head. (it is illegal to retain their head)

      With SE Linux, you can prevent an app from accessing both secret info and the Internet. An employee may get access to both, but interprocess communication is restricted in a way that blocks leaking the info.

      Some extra words to Google for: "Mandatory Access Control"
    • The majority of corporate data theft is by malicious insiders. The second most frequent cause is accidental (selling harddrive full of data). Malicious remote attacks are probably less then 10%. This is conjecture ofcourse. It is hard to get real numbers on malicious insiders and harder still to get numbers on accidental causes. These numbers don't include the popular worms and trojans which don't usually access coporate data.
  • 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-w
    • Actually, Ranum tends to speak out against blind panics and failed attempts at security [ranum.com] (see point #6) and attention-whoring [ranum.com]. 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.

    • 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 [unsubstantiat

  • Border security (Score:5, Insightful)

    by Concern ( 819622 ) * on Wednesday November 30, 2005 @02:43PM (#14149690) Journal
    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...
    • I put a great deal of blame on Microsoft for thier pushing of web services and SOAP as "firewall friendly", an incredibly stupid phrase that every security admin in the industry should have jumped all over them for. I place a good amount of blame on anal retentive and power tripped security admins who make asking for and implementing changes in firewall rules such a horrible pain that technologies that bypass those rules were recieved so well. I place an equal amount of blame on retarded managers who create
    • Agreed, I have been a big fan of application aware firewalls for a long time. There is no way that a simple firewall can protect a server and a network, when it's the applications that are allowed internet access that are getting compromised.

      An application firewall is the answer IMO, it's all about defense in depth.

      • So called application firewalls are snake-oil. It is just another bad hack attempting to fix broken services. The only way an application firewall can work is if it is a feature complete version of the service that needs protecting. It is easier to fix the broken service.

  • where is the "encrypting the monitor" book? (Score:4, Funny)

    by ranjix ( 892606 ) on Wednesday November 30, 2005 @02:45PM (#14149714)
    since the apps are too simple and encryption is needed on all layers, I do expect a book like the one in the subject. ONLY the persons allowed (with special glasses) will be able to understand the warped rays of light coming from the monitor, for everybody else will look like BSOD...
    hey, you heard it here first
    • You can get something much like that now, in the form of displays which require the wearing of specially polarized glasses to view. I know you can get LCDs, dunno if they have over-screens for CRTs but I would assume they do. I don't think they have them "printed" with a BSOD yet, though :)

  • Punish Companies Monetarily (Score:4, Insightful)

    by dotslashdot ( 694478 ) on Wednesday November 30, 2005 @02:47PM (#14149734)
    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.
    • In general, you do not want to set a specific fine amount, otherwise buisinesses can do a fight club-esque calculation to figure out if something is worthwhile. (This is the whole point behind tort reform, companies want to do calculations like the recall calculation described in that movie).

      What you want is juries given the power to charge whatever they see fit, with the company being completely liable, then you'll see companies quaking in their boots, actually taking steps to insure security, with crimina

  • Battlestar Galactica solution (Score:3, Interesting)

    by davidwr ( 791652 ) on Wednesday November 30, 2005 @02:50PM (#14149759) Homepage Journal
    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....
    • 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...
    • 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.

  • Network Security's Achiles' Heel (Score:3, Insightful)

    by MOBE2001 ( 263700 ) on Wednesday November 30, 2005 @02:57PM (#14149816) Homepage Journal
    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.

  • This book is potentially dangerous (Score:5, Insightful)

    by Secret Rabbit ( 914973 ) on Wednesday November 30, 2005 @02:58PM (#14149821) Journal
    The last line of defense? What's going to stop someone if they own the system? Poke poke poke, oh, looky lou, I've found a key.

    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.

    • Ummmm.... I think you're missing the point. As I understand the reviews, both here and on Barnes and Noble's website, the author is not talking about implementing new cryptographic algorithms or processes. He is simply discussing their use in a database environment.

      It is entirely possible to, say, use the Blowfish algorithm to encrypt all of the data in a specific table without being an expert in cryptography.

      Unfortunately, the review didn't go into enough detail to say this for certain, but I expect

      • It's not just implementing new crypto algorithms that causes security failures; implementing new processes, new protocols, new ways of using the same crypto primitives you know and trust do it too.

        Using your example, it is indeed entirely possible to use Blowfish to encrypt all the data in a table. But, if you do it in a naieve way, the protection afforded by the (perfectly good choice of) primitive will be reduced or lost entirely.

        The GP poster was probably more worried about this kind of error. Read Bruce

        • Using your example, it is indeed entirely possible to use Blowfish to encrypt all the data in a table. But, if you do it in a naieve way, the protection afforded by the (perfectly good choice of) primitive will be reduced or lost entirely.

          I can see your point. However, the level of expertise required to implement security at this level doesn't rise to the level of expertise required to implement a completely new crytographic algorithm (while, to me, it looked like the original poster was implying that

          • If you have knowledge of security, you know why this is a bad idea.

            If an application can access data on the backend, so can a thief who either breaks in through that application, or who manages to gain login access to the machine, because THE APPLICATION NEEDS THE CRYPTOGRAPHIC KEY. All the encryption in the world is useless if the key is known by Alice, Charlie, AND Bruce.

            The only valid use I can think of for encrypting information that goes into the database is a public key system. For example, let's sa
            • You are correct. And I'll admit I was curious when I read the Barnes and Noble review that the the book concerns the use of private keys instead of public. I'll withhold judgement on that until I've read the book (it's the first book I've seen reviewed on /. that I've actually considered buying), but I'd be interested to see how the author plans on effectively securing the private keys to the various portions of the database.

              I'll still stand by my statement that it should be possible to present a techni

  • I've never been so scared by a slashdot story in my whole life! Help! What do I do? Where do I go for help?!? WHAT'S THAT SHADOW BEHIND MY MONITOR!! AGHHHHHRRGGHHH!@&73.23.....
  • Anyone who can access the code for your web application can read the decryption key for an encrypted database. So I am not sure that data encryption a very useful feature in relational databases.
    • Hint: Quit putting your key in the code

      That will be $200, thank you.
      • Put part of the key hidden in the code (that the production admins never see), another part of the key in a config on the production server (that the developers never see), and hash them together to generate the real key. If that isn't paranoid^H^H^H^H^H^H^H^Hsecure enough, generate the key offline and load it into hardware modules that can apply the key but not cough it back up.

        That'll be $350 and two karma points, thanks. :-)
    • Hint: There are such things as non-web based apps. More importantly, there any many different ways of getting to databases that have nothing to do with web applications.
  • The most fragile point in any computer-based security system is the point at which an attacker can interface with the system.

    With regard to databases, one means of preventing illicit data retrieval is to implement a one-way directional data filter. In a business setting, this can be achieved by removing the (server-side) TX wires from the Ethernet cable.

    • 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.

      • If you use TCP/IP. But I was thinking UDP/IP. Barring that, IP is encapsulated in Ethernet frames, which offers another possibility for the intrepid.

        I do wonder how to figure out whether the data was written successfully, however.

    • doyou regularly use thermonuclear weapons to kill flies? configuring a firewll to prevent anything but very specific messages, ack, retransmit requests etc. would be much more sane and would allow you to have a consistant database
    • In a business setting, this can be achieved by removing the (server-side) TX wires from the Ethernet cable.

      Role playing is a good way to discuss this suggestion. I'll play the role of your ethernet switch, and you be the server...

      YOU: Here I am, server A! Ready for packets

      ME: (silence)

      YOU: Not the chatty type, ay! OK.

      ME: (silenece; then suddenly) OK, I've got a packet for machine A! Machine A's not on my list, which one of you is it?

      YOU: I'm right here!

      ME: I'm looking for machine A!

      YOU: I'M RIGH

  • Why it Doesn't get Done (Score:3, Interesting)

    by Anonymous Coward on Wednesday November 30, 2005 @03:14PM (#14149933)

    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.

    • 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.

      It is both... so ROT13 at each level.

  • Simple security solution (Score:4, Insightful)

    by Urusai ( 865560 ) on Wednesday November 30, 2005 @03:28PM (#14150093)
    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.

  • Master Key and Indexes (Score:3, Insightful)

    by chill ( 34294 ) on Wednesday November 30, 2005 @03:29PM (#14150102) Journal
    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
    • No. There mustn't. The field just insn't indexed in a meaningful way. Security is just another tradeoff.

      Which makes sense in terms of the popular example of a credit card number. For a credit card tender, you would probably store your internal transaction number, a point of service location identifier, date/time, transaction type (sale, refund, etc) credit card processor transaction reference number, and the credit card number.
      Why in this scenario does credit card number need to be indexed? You'll normally
      • Correct. I should have specified. If you're encrypting the ENTIRE database, then indexes become meaningless. If you're talking about just encrypting a column or two it becomes feasable.

        I work on a daily basis with databases that average 50-60 Gb in size. Not using indexes is not an option. Basic queries go from seconds to hours.

        The problem still remains, that SOMETHING needs to be able to read the data. That something then needs the decrypt key. If that something is then compromised, encryption is me
    • 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.

      That's rather defeatist.
      • Who needs to order the table? Give them a token which allows them to maintain an index of the obscured IDs.
      • Who needs to handle references and JOINs? Let them use the hashed version of the ID.
      • Who needs to do statistics on the data (e.g. totals from a sales column)? G

  • Firewalls irrelevant because of firewalls (Score:5, Insightful)

    by mcrbids ( 148650 ) on Wednesday November 30, 2005 @03:31PM (#14150119) Journal
    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.

    • Application level (Score:3, Interesting)

      by charnov ( 183495 )
      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 compro
    • Get a good firewall. Use statefull packet checking and tell it to enforce rules that limit whats able to run on a given port (so only HTTP over port 80 etc). Block outgoing connections from unknown ports. Hey, presto your secure. The problem is not the firewalls, its that people dont want to secure their networks becuase it limits what they can use them for.
      • 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.
    • Actually most of my traffic is routed through port 443 of a machine whose ssh daemon took apache-ssl's place... Praised be putty's awesome http tunneling abilities :p

  • "I won't fail you. I'm not afraid."

    "You will be. You will be."

  • Database Security (Score:3, Informative)

    by queenb**ch ( 446380 ) on Wednesday November 30, 2005 @03:58PM (#14150375) Homepage Journal
    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... (Score:5, Informative)

    by ahmusch ( 777177 ) on Wednesday November 30, 2005 @04:02PM (#14150413)
    ... 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.)

    • Oracle lets you encrypt columns within tables with AES128, AES192, AES256, or 3DES.

      psql=> update table set column = encrypt(column, 'password', 'aes'); (PostgreSQL and MySQL users, I left you out on purpose. I said enterprise vendors, and I meant it.)

      Well, both PG and MySQL can do this. Don't leave them out.

    • Untrue for HIPAA (Score:3, Informative)

      by peacefinder ( 469349 )
      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 t

    • 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.

      no, HIPAA most certainly does not specificy that sensitive data within a database must be encrypted. such a very, very strict interpretation is something vendors looking to make a dime off of HIPAA would make you believe. if this was really true, you really would not be able to do data warehousing and decision support (which happens to be my meal ticket) in t

    • 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).

      This is one area where I think you're probably off base. There are lots of female DBAs out there, and some of them are quite good. I would say about half the DBAs I've known in my career have been women.

  • I wish Slashdot did book reviews. (Score:5, Insightful)

    by shess ( 31691 ) on Wednesday November 30, 2005 @04:26PM (#14150695) Homepage
    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.

  • Odd Ranum quote (Score:3, Interesting)

    by rpg25 ( 470383 ) on Wednesday November 30, 2005 @05:01PM (#14151073)

    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).

Slashdot Top Deals

Reality must take precedence over public relations, for Mother Nature cannot be fooled. -- R.P. Feynman

Close