August 26, 2017 at 11:12 am
This is a question that I'd ask in a free form forum, but I couldn't find one. If I've missed it, please forgive me.
Yesterday at work we had a rude surprise sprung on us. Or perhaps I should say the DBA's did, but it will effect me as well. The head DBA said that none of our test databases can have real data in them. By that he meant that there should be no real first or last names nor SSN's. This was a huge surprise me everyone, lower level DBA's as well as developers such as myself. What was worse is no reason was given. It was just, "This is the law". This will have a huge impact upon business, as some practices have been around longer than I've been there. For example, one third party software solution that I'm involved in support for requires that when the user makes a mistake in entering data, and then we have to delete it because the app doesn't allow any user to edit or delete any data they've entered (I've talked about this before, so I won't rehash it here), we normally have the production database restored to test, perform the necessary data expunging using one of the 40 some odd SQL scripts for handling these problems, let the manager review the change in the test database and if the user agrees we do the same thing in production. Now, that's going out the proverbial window. And I know the users will hate our guts for doing that.
But for me the bottom line is, why are we being required to do this at all? The test databases are all on similar servers as our production databases. All behind our firewall. All protected by whatever authorization and authentication is used for the production databases. And in at least 1 case, the production and test database happens to be on the same database server. So, why are we having to go through what appears to me to be as useless and lengthy exercise for no reason at all?
I took some time yesterday to go for a walk with one of the mid level DBA's. She added more insight into this EDICT FROM ABOVE. She said that there was some audit, in which the auditors said we were out of some HIPAA compliance, by having real data in a test database. So, this is what's prompting me to post this message. I've worked with HIPAA compliance for at least 15 years. I have never heard of such a requirement. I've got half a suspicion that the auditors have found a "finding" in order to offer a solution - like they're trying to pad their own pockets. But, I could be wrong. My experience with HIPAA has for the most part been watching training videos on HIPAA that are done by my organization's HR department. (The one exception was when I and my supervisor of my previous job actually went to some HIPAA training by some government officials, but that was like 15 years ago.) Does anyone know if this requirement is for real? Is it really a part of HIPAA law? If no one knows for sure, does anyone know of a searchable repository of the HIPAA laws, those introduced in 1996 and 2008?
Rod
August 26, 2017 at 10:49 pm
HIPPA's requirements for test data are no different than it is for your production data. If there's a data breach, Uncle Sam isn't going to care if the leaked information came from your production database or a testing database... That said, it is a good idea to obfuscate personally identifiable information in your testing environments, simply due to the fact that more people have access to those environments.
We worked with our security team and determined that simply obfuscating the numeric portions of a persons SSN, DOB & street address was sufficient.
There's no reason to screw with peoples names, considering that peoples names are already publicly known... Hell I use my real first & last name and even include my middle initial as my user name... Having that information alone won't help anyone steal my identity.
August 27, 2017 at 10:36 am
That's useful Jason, thanks.
Rod
August 27, 2017 at 11:13 am
If anything, I'd verify with state/local HIPPA officials as there may be different rules at the state level that go beyond the federal rules. They should also be able to provide guidance and specific recommendations.
Another data point I failed to mention before, if you maintain geo coordinates like LAT & LON or GPS coordinates, you should obfuscate those as well.
August 27, 2017 at 5:59 pm
That's a good idea Jason, although I'm hard put to determine what state agency is the HIPAA authority. I'll try to find that out.
Concerning LAT & LON/GPS, none of the databases I'm concerned with have GPS data. However, the department I work for is quite large, I probably know at most 10% of all of the apps/databases we have. Some database might have that information, so that's good to know as well.
Rod
August 28, 2017 at 11:51 am
Doctor Who 2 - Sunday, August 27, 2017 5:59 PMThat's a good idea Jason, although I'm hard put to determine what state agency is the HIPAA authority. I'll try to find that out.Concerning LAT & LON/GPS, none of the databases I'm concerned with have GPS data. However, the department I work for is quite large, I probably know at most 10% of all of the apps/databases we have. Some database might have that information, so that's good to know as well.
HIPAA would be enforced by state Dept of Health. That said - while they might have additional HIPAA like requirements they add in, I am pretty sure that any of the extra requirements are NOT considered HIPAA itself.
Also do keep in mind that HIPAA fines often have little to do with actual data breaches. The ones I saw a fair amount of was no keeping up the log of who accessed what and whether those "who" had the appropriate business reasons (or compliant business partner agreements) granting them access (you have to keep a log of what *authorized* users are doing and which records they are accessing). If you only have that control mechanism in place on the prod server, or your ACL is looser on non-prod environments, you could still run afoul of the regs.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 28, 2017 at 4:09 pm
HIPPA is very broad. but Audit and logging of access to data is very important. even if application is showing data as read only, there should be a log what kind of data was displayed and to whom.
If data is being transmitted then make sure to deidentify all the personally identifiable information (PII), SSN, DOB. even ZIP especially if you are keeping xxxxx-xxxx format.
you can have real data in test database, but make sure it is secured as well.
August 29, 2017 at 9:03 am
Avi1 - Monday, August 28, 2017 4:09 PMHIPPA is very broad. but Audit and logging of access to data is very important. even if application is showing data as read only, there should be a log what kind of data was displayed and to whom.
If data is being transmitted then make sure to deidentify all the personally identifiable information (PII), SSN, DOB. even ZIP especially if you are keeping xxxxx-xxxx format.
you can have real data in test database, but make sure it is secured as well.
Our test data is secure exactly as production. Auditing and logging are both implemented, in the same way. The only difference is that we don't transmit any data out of the test db.
Kindest Regards, Rod Connect with me on LinkedIn.
August 29, 2017 at 2:11 pm
You may have already looked into this, but I found this summary of HIPPA guidelines provided by the agency that enforces compliance: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
I worked in a large healthcare organization, and the "general" understanding of being HIPPA compliant was having employees sign a NDA document and encrypting backups. They also disabled any CD/DVD/BluRay devices and USB ports for data transmission (which may be why they were only concerned with employees signing the NDA and encrypting backups). As a DBA in that organization, we restored and/or moved production data to test/dev/qa environments daily with no effort put into changing any of the underlying data. Now, I have no idea if that was a violation based on what HIPPA expects (by the way--it's a government policy, so it's frustratingly vague when it comes to application), but that's what was being done at that organization.
I would be very surprised to find out that it is an actual requirement of HIPPA compliance to de-identify data before transmitting (their terminology) to other environments like test/dev/qa (non-production). But...I've been surprised before, probably will be again. 🙂
Alan H
MCSE - Data Management and Analytics
Senior SQL Server DBA
Best way to ask a question: http://www.sqlservercentral.com/articles/Best+Practices/61537/
August 29, 2017 at 2:29 pm
SQL_Hacker - Tuesday, August 29, 2017 2:11 PMYou may have already looked into this, but I found this summary of HIPPA guidelines provided by the agency that enforces compliance: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
I worked in a large healthcare organization, and the "general" understanding of being HIPPA compliant was having employees sign a NDA document and encrypting backups. They also disabled any CD/DVD/BluRay devices and USB ports for data transmission (which may be why they were only concerned with employees signing the NDA and encrypting backups). As a DBA in that organization, we restored and/or moved production data to test/dev/qa environments daily with no effort put into changing any of the underlying data. Now, I have no idea if that was a violation based on what HIPPA expects (by the way--it's a government policy, so it's frustratingly vague when it comes to application), but that's what was being done at that organization.I would be very surprised to find out that it is an actual requirement of HIPPA compliance to de-identify data before transmitting (their terminology) to other environments like test/dev/qa (non-production). But...I've been surprised before, probably will be again. 🙂
Mu understanding is transmitting data withing the company network doesnt require deidentification of data. from dev to test or to prod surely doesnt require.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply