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?

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. 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 programmers or admins of some sort. If a data breach happens at your company, can you be confident that these mistakes were made completely contrary to your explicit 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 have been around for years, 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 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. Other times it is sharing a password. Brain-fade can cause customers to conduct 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, or at least insist the customer uses two-factor authentication when doing so. Watch for failed login attempts, avoid SQL Injection, and so on. While not all of this may 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. However, 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.

Louis Davidson (Guest Editor).