Personally Identifiable Information (PII) and Data Encryption

, 2013-06-07

Enigma GermanHitting close to home, SC Governor Nikki Haley noted that after the SC Department of Revenue breach was reported, that the IRS didn't require the data to be encrypted:


“As I am sure you are aware, an international hacker recently breached the South Carolina Department of Revenue’s computer system exposing the personal information of all electronic tax filers in my state,” she wrote to IRS Acting Commissioner Steven T. Miller. “While this incident was entirely caused by a malicious criminal hacker, the investigation of how this breach occurred has unfortunately revealed that the IRS does not require encryption of stored tax data, only transmitted data.”


The IRS tried to refute this, saying they "had a long list of requirements." It turned out she was correct, and you can see the evidence in IRS Publication 1075, which states (for data at rest):


While encryption of data at rest is an effective defense-in-depth technique, encryption is not currently required for FTI while it resides on a system (e.g., in files or in a database) that is dedicated to receiving, processing, storing or transmitting FTI, is configured in accordance with the IRS Safeguards Computer Security Evaluation Matrix (SCSEM) recommendations and is physically secure restricted area behind two locked barriers. This type of encryption is being evaluated by the IRS as a potential policy update in the next revision of the Publication 1075.


Then we see that the Department of Homeland Security had a data breach, and once again, PII data was taken. That PII data was unencrypted. 


As a result of this vulnerability, information including name, Social Security numbers (SSN) and date of birth (DOB), stored in the vendor’s database of background investigations was potentially accessible by an unauthorized user.


This begs the question, "When are we going to get serious about encrypting personal information?" I know there are challenges to doing so, especially for older systems. Also, when it comes to SQL Server, not everyone can afford Enterprise Edition licenses where you get Transparent Data Encryption starting in SQL Server 2008. I also know there's concern because encrypted files don't compress well, so when you take a backup and it's encrypted and then try to pass it over to a system that dedupes data and attempts to compress, you don't get such good results. However, at some point we've got to accept that this is part of the cost of doing business and look to do a better job of encrypting data.


With respect to SQL Server we have options. Among them:

  • Built-in encryption within the database (at the "field" level)
  • Transparent Data Encryption at the database level (which also ensures native backups are encrypted)
  • Third party backup products that support encryption
  • Third party encryption products that offer similar capabilities to TDE


It's a matter of identifying what needs to be encrypted, the proper solution, and accepting the cost. To say it's not required, the excuse used by Haley, is just that, an excuse. As IT professionals we should press for the right solution. I realize this is ultimately a business proposition. However, if we're not bringing up the discussion, we're part of the problem.





Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.


1,567 reads

Networking - Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I'd like to talk about social networking. We'll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let...


1,530 reads

Speaking at Community Events - More Thoughts

Last week I posted Speaking at Community Events - Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I've got a few more thoughts on the topic this week, and I look forward to your comments.


360 reads