Database Insecurity

Let’s take a look at some of the database breaches of 2012.  There are a few interesting points to consider.  The first is, do not store anything that you do not absolutely need to.  If you do not absolutely need to store credit card information, do not store it.  I don’t care if your shop is supposedly PCI compliant (fat lot of good that does you); get rid of the credit card number after you use it.  This might not work as well for ongoing subscription-based services, but it saves the embarrassment (not to mention potential legal liability) from losing this data.  Even if the information is encrypted (or “encrypted” if you try to roll your own encryption mechanism and get it wrong), if the key is available to the attacker, your encryption is worthless.

From there, if you do have to store information, store it securely.  Look at internal attackers:  volunteers, disgruntled employees, corporate spies, malicious governments, that kind of thing.  What is the minimum amount of information these people need?  Look at what the organization is collecting.  Is there a reason to collect all of that?  By “a reason,” I mean something more than “Marketing said so.”

In the article, the author asks, “The more I read, the more I thought: ‘Why don’t the database administrators understand how vulnerable their records really are?'”  There are a couple of reasons for this.  The first one is that many database administrators do not understand security very well.  They may not know of built-in tools (such as SQL Server’s Transparent Database Encryption) or paid products that help secure the database.  They may not realize that you should encrypt and protect the backups the same as you do the servers.  But the second reason is that database administrators provide a service.  It is not necessarily their job—or they may not be allowed—to provide that service in the most secure manner.  Third-party products have specified schemas and don’t want client DBAs to muck about with them.  They may force poor practices (like giving a web-based account sysadmin rights) or have backdoors built in.

In addition to vendor-related problems, don’t forget about the rest of the company.  Developers creating databases likely will not understand good security practices, and so without an energetic DBA (with enough organizational cache to pull this off!) to step in and say “What you’re doing is unsafe; here is a better way,” bad stuff gets through.  Poor decision-making higher up the line can also hurt things:  those sales and marketing guys need direct access to the database from their laptops and the brass say to put the database server out in the DMZ.  This is a horrible, horrible idea, but unfortunately quite common.  Alternatively, the more accounts you create, the more likely somebody’s going to have a bad password.  And when your CIO or CEO says that everybody needs to be a sysadmin (because it’s the business’s database, not IT’s, so the business people should be able to do what they need!), that guy in sales with a password which matches his custom license plate means your CIO gets to explain how your company “follows security best practices” even though they got owned and happened to lose a million credit cards and plaintext passwords.

Advertisement