Getting Data In

Anonymize data based on user role

soe_hlawin
Explorer

How to mask or Anonymize data in Splunk 5.0.4 based on role, such that one role (such as Admin) can search and see the data as it was indexed whereas another (such as User) can search and see only masked data ?

Tags (2)
1 Solution

sideview
SplunkTrust
SplunkTrust

I think you could create a scripted lookup in python, put this into transforms.conf to run automatically for all your sourcetypes or hosts or whatever is easier.

scripted lookups:
http://docs.splunk.com/Documentation/Splunk/5.0.4/Knowledge/Addfieldsfromexternaldatasources#Set_up_...

Although what you're doing isn't really "looking up" anything per se, you have all of python at your disposal and you are free to modify any and all field values as they pass through your automatic lookup.

And then I think you can have a particular transform only take effect for certain roles? That part I'm not sure about but as a last resort you could in theory put the role logic into the python too. Avoid actually making rest calls at all costs. Hopefully the role is available somehow in the arguments to the scripted lookup, but as a last resort you could have some other automation create an easy-to-access manifest of users and roles to get the information cheaply.

There are however a number of pretty bad problems you'll then run into. For one thing users seeing the anonymized text will still be able to click on things, but they'll always get zero results for such searches (zero at best. 😃

View solution in original post

sideview
SplunkTrust
SplunkTrust

I think you could create a scripted lookup in python, put this into transforms.conf to run automatically for all your sourcetypes or hosts or whatever is easier.

scripted lookups:
http://docs.splunk.com/Documentation/Splunk/5.0.4/Knowledge/Addfieldsfromexternaldatasources#Set_up_...

Although what you're doing isn't really "looking up" anything per se, you have all of python at your disposal and you are free to modify any and all field values as they pass through your automatic lookup.

And then I think you can have a particular transform only take effect for certain roles? That part I'm not sure about but as a last resort you could in theory put the role logic into the python too. Avoid actually making rest calls at all costs. Hopefully the role is available somehow in the arguments to the scripted lookup, but as a last resort you could have some other automation create an easy-to-access manifest of users and roles to get the information cheaply.

There are however a number of pretty bad problems you'll then run into. For one thing users seeing the anonymized text will still be able to click on things, but they'll always get zero results for such searches (zero at best. 😃

soe_hlawin
Explorer

Hi, I finally managed to find a way to get the user info to the external lookup script. But this approach doesn't suffice the requirement.
As per the said approach, I was supposed to input and output _raw from the lookup script. This is not working, and I doubt if it is feasibile. With a _raw input, I am able to output any other field but not _raw. Any clue?

0 Karma

soe_hlawin
Explorer

Hi, point noted. But I am unable to retrieve the user/role in the python script to have the logic implemented.
To have the user/role in the search results as a field, one has to deliberatly pipe some command. This defeats my purpose for role based masking.

Any suggestion about how to send user/role info to the external scripted automated lookup?

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...