What Counts for a DBA – Responsibility

Whose fault is it if a database is hacked and its contents appear on a hacker’s site? Sure, the hacker is the criminal, but could you, the DBA, have prevented the crime happening to your servers? In the end, the odium that follows a data breach descends on the company who is storing the data, and it will be the DBA, the custodian of the data, who is in the firing line.

There are so many ways that you can reduce the likelihood of a successful breach. Unless this is the first time an attack of a given type has ever been perpetrated, you can, and should, be prepared for known attack types. Consider how data is stolen from most online systems. It isn’t like television, where someone breaches your data center’s walls and uses some high tech device to decrypt your super-secret data. While that can happen I suppose, most security breaches come from simple, generally stupid, mistakes that are made by human beings allowing the bad guys to practically walk in the front door. If a data breach happens at your company, can you be confident that these mistakes were made completely contrary to your explicit, expert advice? Do you even know where the security loopholes are?

Take, for example, a SQL injection attack, which according to Information Week comprised 60% of all attacks on websites in 2010. This is a very simple problem to avoid by following coding standards that were around way before 2010, standards that even a novice could follow. What about a brute force password hack? A simple lockout mechanism on even a fairly large number of guesses might annoy a few weak minded users, but far less than when their private details become less private.

Customers can, of course, accidentally circumvent some of the security you provide. Sometimes it is a weak password that seems to meet strong password standards. Other times it is sharing a password. Brain-fade can cause customers to do something silly like conducting a television interview in their office, forgetting that they have their passwords pinned to a notice behind them. However, it is your responsibility to help your customer or employer avoid making this kind of mistake. Don’t allow them to use poor passwords. Ask if using an email address is a proper public key to personally identifiable information, and try to insist the customer uses two-factor authentication so the password is only part of the equation. Watch for failed login attempts. Don’t forget about SQL Injection, etc. While all of this may not be in the DBA domain, what you are protecting is data, so get involved and take responsibility. While the victim may be culpable, they cannot be given primary blame unless they completely ignore your advice (and, like, totally share their password!)

Of course, we can discuss all day who, in particular, is at fault when a server gets hacked and addresses and social security numbers are stolen. If you allow something stupid to occur, then at your next employer, the security discussion may have less to do with securing data and more to do with hamburger bun security, as in whether or not you are supposed to lock up the hamburger buns at night. Here is a tip. The answer about whether you need to lock up the bread will be the same as whether you should secure your customers data: “yes”.

How you log in to Simple Talk has changed

We now use Redgate ID (RGID). If you already have an RGID, we’ll try to match it to your account. If not, we’ll create one for you and connect it.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.


Simple Talk now uses Redgate ID

If you already have a Redgate ID (RGID), sign in using your existing RGID credentials. If not, you can create one on the next screen.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.