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.
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....
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?
If I clone myself, can I call it a thread?
If a girl winks to us, can I call it a race condition?
All access to information can be governed with crypto keys. Either you have the rights to the information, or you don't. Even root can be managed: without the key, root can't see what's actually in the files. Backups still work, and even in the archives the files' contents are encrypted.
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.
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!
All my moley is unholy!
There's no doubt that running a secure OS and adhering to good practices (such as never do anything as root that doesn't have to be done by root) is increasingly important these days. One client I work with is running Openwall and it seems to be a good solution. There are many other security enhanced Linix possibilities, too, as well as OpenBSD - which I don't have direct experience with, but I hear it's pretty tight.
At home, I just keep up-to-date with Debian and practice careful management, but for any corporate systems, I'd start with a secure OS.
The antidote for misuse of freedom of speech is more freedom of speech.
-- Molly Ivins
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
I had another sig before, but this one is better
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.
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.
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.
How the hell is this informative.
A link to OpenBSD that says it is tight. Wow, I didn't even know what OpenBSD was before you posted that.
A link to a google search on selinux (spelled wrong in the link at that)
Wow, is that new, or maybe magic. I had no idea selinux existed. Must be new like OpenBSD.
And for the openwall link. WTF, Open wall is much more then a product. It is like saying my client needed a network wifi solution and decided to go with Cisco. WHAT PRODUCT ASSHAT?
That's all.
The parent is overrated as fuck and should be modded down into oblivion.
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.....
Hexy - a strategy game for iPhone/iPod Touch
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.
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.
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.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
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.
I had it earlier ...I think. It seems to have just disappeared :( Suppose I had better get another.
"punish the companies!!!", "take bill gates glasses and give'm to the poor!!!". well, not quite there but close. Still, besides the tone of the comment, I can see you believe that a 100% unbreachable security is possible. Kind of naive, would'n you say? Do you really believe that all the latest breaches happened because of the lack of "database cryptography"? If you don't know the answer, I'll give you a hint: no. The software apps are extremely complex. It's impossible to verify all the paths thru an application (the number is equal - no more, no less :-) - to infinity).
So hold your horses, don't get too excited, back to earth
I had another sig before, but this one is better
Whatever happened to "division of labor", "specialization" and "modularization"?
The poster sounds like a Microsoft ad:
I really don't understand the point of encrypting your database. A reasonably safe setup is this:
only http only http
Internet <-> Firewall <-> WebServer <-> Firewall <-> Application server <-> DB
or Reverse proxy
You put a webserver in between two firewalls and allow only http over these.
Next put your database behind the second firewall.
A webserver is somthing like apache webserver.
In the case of asp and iis you would use a reverse proxy.
The application server is something like iis or tomcat.
ODBC or jdbc is only spoken between app server and database.
This means that the application server must have password and encryption keys.
So I ask: how is encrypting the database going to help anything?
If somebody can hack trough 2 firewalls and steel the database url, userid and password. Then what is to keep him from steeling the encryption key???
Hint: Quit putting your key in the code
That will be $200, thank you.
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.
Another excellent resource on this theme is Translucent Databases by Peter Wayner.
Are you...Are you some kind of genius?
No, ma'am, I'm just a regular Slashdot reader.
...and failed at it, I can attest that this indeed is a real problem which isn't solved practically - yet. Means to solve it in a reasonable manner do exist but are very limited and carry a significant risk especially when one is dealing with an existing database measuring in tera bytes and already running at near full capacity. A major retalier in the US was audited and they found severe security flaws in their online system. Majority of it was to do with how the sensitive data such as Credit card and SS numbers were stored - plain text, in a non access controlled database! DBAs came and went and they could look at the credit card data and SSN numbers at their will which was the primary concern. We worked out a near fool proof cryptography mechanism on paper but were never able to clarify to them how would we deal with the reduced database performance without investing an additional cent worth on hardware!
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.
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
"I won't fail you. I'm not afraid."
"You will be. You will be."
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
HDGary secures my bank
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
... 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.)
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.
I can appreciate your attempt to reign in the GP perspective of punishing companies over security breaches. Like you wisely wrote, no usable security system is 100% invincible.
There is a middle ground in this debate, though, and I believe that is fining companies over negligent security practices. After a breach and theft of consumer data, an independent security audit can identify if the damage to consumers was the result of a corporate negligence towards security. In that case, they would be susceptible not only to fines, but also civil suits, I think. In the same way a property owner can be sued by visitors if they get hurt due to the owner's negligence in maintaining their safety. Since slip-and-fall lawsuits raise such negative conotations, I know this isn't the most palatable example, but that's what I've got for you!
Seth
$5 / month hosted VPS on linux = awesome!
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.
Granted, hard-coding those values is pretty absurd, but the single login does make sense, mostly financial, but in a very, very non-trivial way.
When you're sold an enterprise server for an enterprise app with a $1250 per-seat (much less named users) fee and you have 5,000 concurrent users, that's $6.25 million. You can buy the same server with five or ten user licenses for $40k. Provided the application is secure enough, the cost v. benefit of having per seat licenses just doesn't pan out. Cut another way, fine, you have named users passing through to the database and those logins come through the application. Does that _really_ make you much more secure if those logins can be compromised? Sure, you might sniff out the lowliest account, but if you can do that, you can sniff out the admin account as well. Where's the $6M advantage? I'm seeing a subtle variant of security-via-obscurity here. "Gosh, if they have to pick from thousands of accounts instead of dozens, we're secure!" Right.
Case in point: The state of California was sold a named user license by Oracle for $1.5 BILLION. That's right, name every goddamned user working on the State of California network. Not really much different than a per-seat license, but I suppose they could have saved, say, a billion, leaving them with a $500,000,000 database license. I believe the purchase orders -- and the careers of those who signed them -- were cancelled prior to payment.
So, where do you draw the line on this nonsense? 100 users? 1,000? 10,000? Does it really make a difference? If you can hack 1:100, what's the value of reducing it to 1:10,000?
Save yourself $6.30 by buying the book here: Cryptography in the Database. And if you use the "secret" A9.com discount, you can save an extra 1.57%!
in order to get to fines/civil suits, several things must happen:
- the breach/data theft should happen and be recognized as such (I think a lot of times companies don't even realize)
- there should be a way to find the way it happened (not always possible)
- there should exist some sort of definition for "negligence in security practices" (good luck)
- there should be some damage on the customers side, provable that it was caused by the breach in the first place (well?)
add to this any kind of license agreement in the first place and then just forget it
I had another sig before, but this one is better
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.
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"
HIPAA [specifies], more or less, that sensitive information must be encrypted within the database. That means the data at rest on disk must be encrypted.
That's not actually the case when it comes to HIPAA. Encryption is not a required element of the technical safeguards for data, it's only an addressable element. See section 164.312 part (a)(2)(iv) of the final Security Rule, which can be found in the Federal Register (volume 68 number 34 page 8378) or on my desk.
The regulation requires the covered entity to implement appropriate administrative, physical, and technical safeguards for protected health information. Encryption is just one element of those safeguards, and an optional one at that. Remember that HIPAA views security as including not only confidentiality, but also integrity and availablility of data. Encrypting data at rest would often be a marginal improvement to confidentiality at a potentially large risk to availablility (or even integrity). It may be a good idea in some security environments, of course, but encryption is not a blanket requirement of HIPAA.
(Even data in transit does not require encryption under HIPAA. It simply requires protection commensurate with the risk. Protected health information transmitted over a dialup line probably does not need encryption, whereas any transmission containing PHI over the internet certainly does need encryption.)
The attacks you suggest solving by database encryption can also be dealt with by policies regarding media disposal and backup media safeguards. A HIPAA covered entity is required to have a media disposal policy anyway, and offsite backup tapes are just another form of data in transit to be protected accordingly. Database encryption may be a valuable additional layer, but it's certainly not the only way to skin that cat.
(Incidentally, about half the Oracle DBAs at my EMR vendor are women.)
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
altogether since they allow now access thru internet... IMHO the degree of security of internet banking won't come close to the one of a vault (very complex systems vs rather simple - and because of that, verifiable - ones).
I had another sig before, but this one is better
I agree with many of the intelligent posts around the idea that "database encryption is just one small piece of the puzzle" - I agree that *selective* database encryption is one crucial piece to a defense-in-depth multi-layered security strategy.
Yet still, the is a fantastic well though out book. Its not a cure all, but a great book on this one segment of a good secure database solution.
For the beginner, just dive right in to page 37 and read the overview of Cryptographic structures. Then, stare at the diagram on page 41 for many hours and understand the workflow of this architecture.
For the advanced practicioner, a lot of this was review, but I got the most out of Chapter 8, "reqirements hardening" - although most clients think I'm paranoid when I talk security at the initial requirements gathering meetings, this small chapter helped my fine-tune my approach.
Horns are really just a broken halo.
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.
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
Is this a publically traded corporation? Is this really a hyper critical unpatched major security flaw that could expose the company and any of their customers to significant loss?
If so,all of the above, you have a ton more rights than what you may think, not only rights but some obligations most likely. Don't let management buffalo you or threaten you or scare you, get a nasty mercenary lawyer,give him the skinny then do exactly what he says to do, and you could walk away with a hefty sum, decent FU money.
It's better to report these things anonymously.
Then if they do nothing at all, you drop the bomb on BugTraq or Full Disclosure or wherever.
Can't retalliate when they don't know who you are.
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.
Firewalls provide perhaps a single security benefit -- they might buy you a small amount of time after an exploit is released before your network is hit (e.g. if someone releases a simple worm). They are not long-term solutions at all. "Personal firewalls" are a complete waste of time -- there are too many clever ways to subvert the things.
For a long time, I've been arguing that the kinds of people who deploy incredibly restrictive firewalls left and right (and then proceed to ram things like SOAP through the firewall because they just blew away the usefulness of their network and need a hack to try to get things working again) aren't doing anything but hurting network performance and increasing complexity -- they *still* have the same servers and clients going through their firewall, but now they spent a lot of money to essentially slow everything down.
A web browser is one of the most complex applications on your system, and has to deal with some of the most complex data, and some of this data is already intended to be executed. It also changes at a very rapid rate compared to most applications (compare, say, the evolution of Navigator-Mozilla-Firefox to Photoshop). It is, quite simply, *the* most attackable thing on your system.
What's the second most attackable thing on your system? Data files. Sure, programmers go to a lot of work to ensure that they have robust handling of malicious network input. But what about in their data file formats? Plus, these often change every time a new feature is added to an application. A virus that sits in a data file can spread even on an incredibly-locked down network, where the only common access that the machines on the network use is a file server. Common, well-examined file formats like MP3 (see Nullsoft's ID3 tag problems), JPEG (libjpeg's had security problems in the past that have hit Slashdot), and so forth have had their share of blemishes. How much more likely do you think it is that the case of a more complex format (Illustrator or Word, for example) that many, many holes still exist? Plus, while server admins may patch their servers, the number of people that use old versions of WinAmp is *immense* -- lots of these holes won't be closed for a long, long time.
But what do we get? Firewalls. Granted, Microsoft had an attitude for a while that computers didn't *have* to be secure against remote attacks, and the complex filesharing/IPC/etc systems were by default exposed to the remote world, and that if their software had holes that got attacked, then the network admin was at fault. Some use of firewalls were a response to that. A hell of a lot, though, isn't. Most firewalls are Band-Aids -- they may not do much, but it's easy to point at them as progress, and everyone feels a lot better.
Any program relying on (nontrivial) preemptive multithreading will be buggy.