Managing Whitelist Rules for Departments
This article was updated. See sections in pink below for new information.
I’ve run into a scenario where I feel like I’m chasing my tail; I can’t get on top of the Issues and Incidents created in DRA. It seems like my whitelist rules are growing exponentially. Managing these rules are a constant challenge. I had been trying to create rules by users and event types; however, I have come to the realization that this is just not sustainable.
We need a better way.
It would be fantastic if Imperva allowed you to make a rule for a user’s department. I’ve put the suggesting into the User Voice Feature Request system; jump over there and up-vote it please, so they fix it faster. However, before they program a new feature, I have just come up with a work around to allow the easy creation of DRA Whitelist rules for whole Departments and not just for individuals.
Use Case
I have many department of people that are power users, not DBAs, but statistical data scientists. They go into our data warehouse and pull billions of records out for statistical analysis. Although they may hit the same databases over and over again, they are always creating new, complex queries to answer the business question of the day. Today, I may find user-A touching database-1; so, I search for existing rules, none-found, make a rule user-A/database-1. Tomorrow I see user-A touching database-2; so, I search for existing rules, found one, modify it, add database-2. Then, user-B comes along, and touches both database-1 and database-2; so, I search for an existing rule, none-found, make a rule for user-B/database1,database2.
With a limited group of users and databases, this wouldn’t be an issue. I work at a corporation with many of these departments, hundreds of databases, and thousands of database users. It’s a real issue. I’m battling to keep on top of hundreds of new Issues created daily. I think this has been the source of my migraines recently.
Apology and Prerequisites
Let me take the time here to apologize. I am sorry for two things: 1) I cannot share screen shots of my environment for illustration purposes (security and confidentiality) and 2) this workaround requires PowerShell and the Active Directory Module for PowerShell (Mac > Windows, but my job wouldn’t give me a MacBook). I am aware there is a cross platform PowerShell available at https://aka.ms/pscore6, however I do not know if this will work. Good Luck if you decide to try it. Let me know if it works.
See https://adamtheautomator.com/install-powershell-active-directory-module/ for instructions on getting the PowerShell module installed. Without it, the scripts below will just produce errors.
PowerShell Script Workaround
This script uses the known “Department” from the User Information screen in DRA as input.
# code to getDept.ps1
# Get all AD users in a Department
$Dept = Read-Host -Prompt 'Department Name'
$Raw = Get-ADUser -filter {Department -eq $Dept} | select SamAccountName -ExpandProperty SamAccountName
$Out = ($Raw -join ",")
$Out
A very straightforward script. You put in the Department that is displayed in DRA, and you get a coma delimited list of usernames to put back into DRA.
PS C:\Users\Andrew\Scripts> .\getDept.ps1 Department Name: Data Scientists tombillings,marthaking,debbieshort,jimbarker,markrustle,heathersands
The next script uses the known username from DRA and outputs the user’s department. Then the department can be used in the script above.
# code to getUsersDept.ps1 # Display a User's Department from AD $User = Read-Host -Prompt 'User Name' $Out = Get-ADUser -Properties * -Idendity $User | select Department -ExpandProperty Department $Out
User gets Department, Department gets list of members. Copy/Paste the list of members into DRA, and you have a rule for a Department.
PS C:\Users\Andrew\Scripts> .\getUsersDept.ps1 User Name: debbieshort Data Scientists
These are my first PowerShell scripts. I’m surprised at how concise and powerful PowerShell scripting is. I’m very impressed. I think I’ll be doing a lot more PowerShell scripting in the future.
Updated:
In testing and quality assurance, it was brought to my attention that “Department” was sometimes too broad a category. For example: when I used my corporate CN, I got everyone on my team, everyone on the Oracle DBA team, everyone on the MSSQL DBA team, and all the other DBA teams. I shouldn’t have the same rights and privileges as a DBA nor should DRA rules apply to me the same as they do to the DBAs; however, we are in the same Department. So, I needed a way to limit the user list to just people who had an identical job role.
The Manager is the answer. A field that the DRA tool and all user records have in common is the user’s manager. I created a separate script to grab all users with a specific user’s manager to get a “Team”.
# Code to getTeam.ps1
# Search AD for all the users under a manager
$User = Read-Host -Prompt 'Users CN (username)'
$Manager = Get-ADUser -Properties * -Identity $User | select Manager -ExpandProperty Manager
$raw = Get-ADUser -filter {Manager -eq $Manager} | select SamAccountName -ExpandProperty SamAccountName
# Format the output
$out = ($raw -join ",")
# Display the output
$out
Of course, if your AD isn’t populated with accurate information this won’t work well, but then again, neither will DRA for that matter. Good Luck!
Daniel
Noice. I haven’t played a lot with PowerShell, but I have noticed it isn’t bad when I do. Doesn’t Imperva’s import from AD work with Risk analytics?
Andrew Esposito
Yes, but you can’t create a rule based on the Department of the user, just the OS User or DB User. Nothing about the Team or the Department. Now when I see Tom do something, I make sure to put everyone in Tom’s team or department in the rule. Because if it’s business as usual for Tom, it’s also business as usual for everyone else who’s a Data Scientist.