obfuscation tool or method for servicenow?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-10-2017 02:01 AM
My company is going to be storing sensitive data as part HR Case information on its production environment. We don't intend to copy any of this data to our non production environments so we will set up a data exclude on the HR Case, Task and Profile tables but now we face a challenge as how to carry out effective testing of any fixes and enhancements.
One approach to this problem could be to create a subset of data from Production and apply some means of obfuscation. Has anyone done this? How difficult did you find it and what method did you use?
What other approaches could be taken?
- Labels:
-
HR Service Delivery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-10-2017 02:20 AM
Hi Ed
This topic is interesting and your worry regarding the data security is natural and genuine.Last year We had implemented a application for HR and they are very much conscious and sensitive for their data.
Like you mentioned that you have added all the related tables in exclude table list so that the data do not spill out through other instance, we also did the same
We have also setup a notification if someone tries to impersonate a user having that particular HR role then HR group notified and a lot other investigation carries out.
Earlier we also faced a lot of challenges in bug fixing and post production testing. In all the cases our developer was working with one HR person for each bug fixing and testing.Now the system is stabilized
Sometimes we use to create some dummy data in test instance to replicate the issue and to find the root cause.
Regards,
Harsh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-12-2017 05:09 AM
hi Harsh
So you were only testing in non prod to replicate issues and check fixes?
We will also have a need to regression test every release of new functionality into our production environment to ensure the change has not broken anything and in order to do so I'm thinking we will need to create some dummy data that can be reused each time we do a release. I'm thinking that will need to export some data from Prod make some obfuscation changes to it the case info and then create a new relationship so that the data points at some test accounts rather than real people within the organisation. Sounds like a lot of work to me so hopefully I can find some way to make it easily repeatable.
By the way we prevented impersonation of anyone with a HR role which may offer improved security than reporting after the fact...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-12-2017 08:07 AM
Yes, for the testing we setup dummy data and our testing team and business do a lot of testings.I know that this is a challenging and tough task but no other options. If we find any other solution for this,will let you know.
Our servicenow data administrators and the admin users have impersonation role.it is around 10-12 users. So if anyone of these users do the impersonation then a notification is generated to HR.This is to put more security.
Regards,
Harsh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-12-2017 08:13 AM
Hello Ed,
One option for you is to create a series of test records in the various tables. Once you have those, export the tables in XML format and save them for future reference.
Then, when you clone the prod instance over your dev or test instance, you can "import XML" to those tables from your saved files.
No obfuscation is necessary.
EDIT:
One advantage of using explicit test data is that you can cover a wide range of behavior in your software which may not be exercised with live data.
In other words, a couple of records with variety may exercise more test cases than a million records which are all pretty much the same.