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.

Adrian J. Moreno's Gravatar This sort of thing is extremely common in the education sector. When I was at UNT in the mid 90's, our student ID was our SSN and our ID cards had our SSN printed on them for all to see. Most of our data was stored and related back to our SSN. in the late 90's steps were taken to stop that practice and remove or encrypt all SSNs stored in the system.

I agree that fault lies on both sides here. Their computing department should have been monitoring the system built by the researcher and they should have audited the system on a regular basis. The researcher should have gone to their IT department to check on standard practices for storing the kind of data that would be involved with the project.
# Posted By Adrian J. Moreno | 2/1/11 12:34 PM
TallTroyM's Gravatar I'm curious what others do to protect their sensitive data if it's required to be stored (SSN for example). I'm aware you could use the CF encrypt & decrypt functions, but how would do you a search on these values if needed, or a wildcard search in particular?
# Posted By TallTroyM | 3/17/11 2:38 PM
Jason Dean's Gravatar It would be easy enough to do a full-text search (if you used the same key for every entry).

I don't know how you could do a wild card search. But frankly, I also can't think of a use case where you would want to (should). If you don't know the FULL SSN, why would you need data for everyone's who was similar?
# Posted By Jason Dean | 3/17/11 4:20 PM
TallTroyM's Gravatar SSN is just an easy example, but there is other Personally Identifiable Information (http://goo.gl/iEoSV), or PII, that auditors in healthcare would like to see encrypted in the database. I can encrypt it going in, and I can encrypt it coming out. However, for fields like last name and first name that they might want to do a wildcard search on, and if these are encrypted, it could be difficult. I'm just looking to see if someone has done something like this or has any suggestions. Having them type the complete last name in the form, encrypting and comparing the encryption would work I guess.
# Posted By TallTroyM | 3/17/11 5:36 PM
Jason Dean's Gravatar In my opinion, encrypting first name and last name or any other mundane data like that is a complete waste of resources. I cannot imagine a good reason to encrypt any personal data other than SSN and Credit Card numbers.
# Posted By Jason Dean | 3/17/11 5:49 PM
TallTroyM's Gravatar Because names, address, phone, fax, email are some items that are considered Protected Health Information (http://goo.gl/msjr), the auditors for the lab would like them to be encrypted if at all possible in the database. This way if someone is able to access the database, even as the DBA account, the values are encrypted.
# Posted By TallTroyM | 3/17/11 6:50 PM
Jason Dean's Gravatar The data can be encrypted without encrypting the individual fields. For example, some DBMSs (MSSQL 2005?, Oracle) can encrypt the data itself, and it will take care of decrypting when the data is requested. This would satisfy the need for encryption but still allow wildcard searches.

You can also encrypt the file system itself.

Many ways to skin a cat. But I believe that having the application encrypt and decrypt the data at the field level in unneeded overkill and will cause more problems than it solves. I would recommend looking into the other options.
# Posted By Jason Dean | 3/17/11 7:17 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner