Whose responsibility is data security?

This is an important question and one that you need to ask yourself.

Last week this article was released about a faculty researcher at University of North Carolina at Chapel Hill.

The article describes how the University recently found out that a machine that stored 180,000 social security numbers (used for research) was compromised back in 2007. The University is now hanging out the researcher to dry and not claiming any fault of their own. There is no report yet on what is happening with the programmer/system admin that she hired to maintain the system.

One thing I have tried to stress in the numerous talks and courses I have done on security is that developers should consider the possibility that they could be held responsible if their application gets hacked.

So whose responsibility is it to make sure your systems are secure? UNC seems to think it was the researchers responsibility. The critics of UNC's decision to punish the researcher feel that it was a "Systemic institutional failure", which, to me, translates to, "There was not a process in place to ensure that research data was secured, so it is the system's fault".

I suspect the blame should fall on both sides.

A lot of REALLY stupid things happened here. Let's see how many we can find.

1. A researcher was allowed to store sensitive patient information on a machine that she controlled with the help of an unqualified administrator
2. No vetting of the researchers or administrators abilities to secure a computer was done
3. The SSNs were (I am assuming) stored in plaintext on the machine
4. The machine was connected to the Internet
5. SSN's were collected instead of some other unique ID (I am assuming that storing SSNs was not strictly needed)

There could be other stupid things, what do you think?

From this story I see two HUGE lessons that we developers and system admins should take away from this (not counting those taken from the list above):

1. You could be blamed for a breach that happens with your application/server. Take care with your applications. Plan your security from the start. And go fix your legacy applications.
2. It could be YEARS before you discover a breach. They can happen without you EVER finding out. What may seem secure now maybe not be. Keep records of your efforts. Show due diligence in your security practice. Show that you may every reasonable effort "at the time" to make your application secure. And keep management informed of what you are doing. If, 4 years from now, they find out that back in 2011 you were breached, you can show your records and demonstrate that you did what you were supposed to do.