October 18, 2011 at 10:19 pm
Comments posted to this topic are about the item Protecting Data
October 18, 2011 at 10:31 pm
If your test data is truly too close to real data, then it probably should be secured just like prod. If you can't obfuscate it efficiently enough, then secure it better.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
October 18, 2011 at 10:44 pm
"If that is true, then we then need secure development environments and treat them like production servers".
Yes and no. If you are off shoring or have a third party develop your solutions then I would agree you need to anonymize your data. If your development team is part of your organisation then anonymizing your data is pointless and sends the wrong message to your programmers. It is pointless as normally such a task is performed by programmers anyway. It sends the wrong message as if you cannot trust your internal programmers with your data then who can you trust and trust is a two way street.
I have been a programmer for nearly 20 years and I consider the privacy of corporate data and corporate information of paramount importance. I have been privy to such sensitive information and I can say programmers are generally all round top you beaut guys (except for the odd nitwit). The Australian Computer Society (ACS) is strong on ethics as part of its membership and the ethical use of corporate data falls into this category - and this is the reason why.
Not taking anything away from the importance of data and the security around it I believe there is a larger issue that needs some highlighting – the gender issue – where are all the women progs? I have met 5 in 20 years – and 2 of these were at CBit and I only met these briefly.
C'mon! Women Progs of the world Unite.
..back to Visual Basic 6...nanoo nanoo.....
October 19, 2011 at 12:28 am
If you're using production data, then it depends how strongly you're wanting to anonymize it.
Changing names/genders/dob/addresses etc is probably enough to protect the data at a basic level as long as it is done with excruciating attention to detail.
But say someone has a complete old dataset - they may be able to match key values with the new data and make quite meaningful links to the new dataset.
So that means changing keys in a random manner, and that's a whole new ball game: it's probably way more trouble than it's worth.
The only way to truly anonymize data is to aggregate it.
The conclusion is, then, use completely fictional test data or secure your dev environment.
I'm often staggered by the lack of good security around test and dev environments; the same orgs that have locked-down-so-tight-it-hurts production systems quite often have short, weak passwords on their test system (granted, these are often protected by VPNs or IP-based remote login restrictions, but I think these are given more weight than they deserve - for example, it doesn't protect from users who are already on the VPN). And production data is regularly copied to test systems.
Don't even get me started on datasets on USB sticks or laptops ...
October 19, 2011 at 3:08 am
I think it can be very difficult to get randomised data in a test environment that is also vaild - by this I mean reflects current working processes as accurately as possible. The way that system users affect live data (mistakes et al) is hard to replicate. If this is not achieved then any development work, such as reports for example, may not work correctly when applied to the Live data.
If the development staff are in-house then they are bound by internal IT policies and so should be trusted with using the data in the correct way and not abusing their position. If not then disciplinary procedures are in place to tackle the issue.
If the development staff are external - ie to support a system that has been bought in, there is only so much work that can be done on anonymysed data. For example if a bug occurs on a particular live record it can be near enough impossible to recreate without looking at the live record. To tackle any potential issues with external developer we have strict control on how these access sysetms, for how long, and also who can access our data. For example we insist that they are CRB checked due to access to child information.
October 19, 2011 at 3:36 am
Just to answer one of your points, I'm not worried about rouge developers, as they're easy to spot by their colouring, and we just avoid employing red people. 🙂
-------------------------------Oh no!
October 19, 2011 at 3:46 am
I think there are compliance issues here, as well. In the UK, the Data Protection Act covers data that can be used to identify a living individual. As far as I know, it forbids the use of data for any purpose other than that for which it was collected, which I suppose must include testing.
John
October 19, 2011 at 5:57 am
Im amused by "rouge" developers!
We should do what we can do. Correlation requires a lot more effort, so we should make them spend the effort if they do access to the test/dev data.
October 19, 2011 at 6:14 am
On occasion I've restored Prod data to QA or Dev to troubleshoot a Prod issue. It would be useless if it was obfuscated. And because of that, I see no good reason for QA or Dev to be less secure.
Also, when deploying changes, enhancements, etc. I don't want surprises in Prod because security is different that QA.
October 19, 2011 at 6:25 am
I think it really does depend. As has been mentioned, sometimes when troubleshooting an issue you need to have an exact copy of production to be sure you are addressing it correctly. In this case the security of the test/dev environment needs to be locked down like production.
I also think it depends on the size of your shop. I've always worked in small shops where the developers have access to all environments, so obfuscating data for the development environment really didn't matter since a rogue or rouge employee could still steal the data. If you are in a larger environment where developers do not have production access, then I can see the value in obfuscating data.
I think others have said, really the security should be maintained at the same level throughout the environments.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
October 19, 2011 at 7:47 am
Kevin Gill (10/19/2011)
Just to answer one of your points, I'm not worried about rouge developers, as they're easy to spot by their colouring, and we just avoid employing red people. 🙂
The Native American in me wonders what you mean by that... 😛
October 19, 2011 at 7:51 am
There are many compliance and policy laws in the US that govern the access and obfuscation of personal and/or financial data companies create and collect. This data usually could cause someone harm if it was made publicly available.
October 19, 2011 at 8:10 am
SanDroid (10/19/2011)
Kevin Gill (10/19/2011)
Just to answer one of your points, I'm not worried about rouge developers, as they're easy to spot by their colouring, and we just avoid employing red people. 🙂The Native American in me wonders what you mean by that... 😛
You'd be ok as long as you didn't come in speaking French.
Or wearing too much makeup.
-------------------------------Oh no!
October 19, 2011 at 9:27 am
All the concern about protecting data, yes as a DBA you may have a significant role to insure that sensitive data is protected. But how many of you have shops that are not protected from outsiders "listening in". By that I mean who is responsible for securing your desktop/laptop computers your internal network (generally copper wire), from emitting EMR (electrical magnetic radiation) signals ?
If my question seems strange read this article and then think about checking where you work. True not the responsibility of a DBA, except maybe to have your system checked by others.
http://cryptome.org/tempest-leak.htm
Remember the fuss over GOOGLE's street view work and what GOOGLE was able to record and save.
October 19, 2011 at 9:37 am
Kevin Gill (10/19/2011)
SanDroid (10/19/2011)
Kevin Gill (10/19/2011)
Just to answer one of your points, I'm not worried about rouge developers, as they're easy to spot by their colouring, and we just avoid employing red people. 🙂The Native American in me wonders what you mean by that... 😛
You'd be ok as long as you didn't come in speaking French.
Or wearing too much makeup.
Not funny, appears racist. Probably was not intended that way but best to leave it instead of digging deeper.
Not all gray hairs are Dinosaurs!
Viewing 15 posts - 1 through 15 (of 28 total)
You must be logged in to reply to this topic. Login to reply