This article was updated. See sections in pink below for new information.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
We need a better way.<\/p>\n\n\n\n
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. <\/p>\n\n\n\n
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. <\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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)<\/em> and 2) this workaround requires PowerShell and the Active Directory Module for PowerShell (Mac > Windows, but my job wouldn’t give me a MacBook)<\/em>. I am aware there is a cross platform PowerShell available at https:\/\/aka.ms\/pscore6<\/a>, however I do not know if this will work. Good Luck if you decide to try it. Let me know if it works.<\/p>\n\n\n\n See https:\/\/adamtheautomator.com\/install-powershell-active-directory-module\/<\/a> for instructions on getting the PowerShell module installed. Without it, the scripts below will just produce errors.<\/p>\n\n\n\n This script uses the known “Department” from the User Information screen in DRA as input.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n User gets Department, Department gets list of members. Copy\/Paste the list of members into DRA, and you have a rule for a Department.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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”.<\/p>\n\n\n\n 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!<\/p>\n","protected":false},"excerpt":{"rendered":" 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 … [Read more…]<\/a><\/span><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12,20],"tags":[44,43,42,46,45],"class_list":{"0":"entry","1":"post","2":"publish","3":"author-siteuser","4":"post-411","6":"format-standard","7":"category-professional","8":"category-technical","9":"post_tag-counterbreach","10":"post_tag-dra","11":"post_tag-imperva","12":"post_tag-rules","13":"post_tag-whitelist"},"_links":{"self":[{"href":"https:\/\/andrew.the-espositos.net\/blog\/wp-json\/wp\/v2\/posts\/411","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/andrew.the-espositos.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/andrew.the-espositos.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/andrew.the-espositos.net\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/andrew.the-espositos.net\/blog\/wp-json\/wp\/v2\/comments?post=411"}],"version-history":[{"count":8,"href":"https:\/\/andrew.the-espositos.net\/blog\/wp-json\/wp\/v2\/posts\/411\/revisions"}],"predecessor-version":[{"id":420,"href":"https:\/\/andrew.the-espositos.net\/blog\/wp-json\/wp\/v2\/posts\/411\/revisions\/420"}],"wp:attachment":[{"href":"https:\/\/andrew.the-espositos.net\/blog\/wp-json\/wp\/v2\/media?parent=411"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/andrew.the-espositos.net\/blog\/wp-json\/wp\/v2\/categories?post=411"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/andrew.the-espositos.net\/blog\/wp-json\/wp\/v2\/tags?post=411"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}PowerShell Script Workaround<\/h4>\n\n\n\n
# code to getDept.ps1\n# Get all AD users in a Department\n$Dept = Read-Host -Prompt 'Department Name'\n$Raw = Get-ADUser -filter {Department -eq $Dept} | select SamAccountName -ExpandProperty SamAccountName\n$Out = ($Raw -join \",\")\n$Out<\/pre>\n\n\n\nPS C:\\Users\\Andrew\\Scripts> .\\getDept.ps1\nDepartment Name: Data Scientists\ntombillings,marthaking,debbieshort,jimbarker,markrustle,heathersands<\/pre>\n\n\n\n
# code to getUsersDept.ps1\n# Display a User's Department from AD\n$User = Read-Host -Prompt 'User Name'\n$Out = Get-ADUser -Properties * -Idendity $User | select Department -ExpandProperty Department\n$Out<\/pre>\n\n\n\n
PS C:\\Users\\Andrew\\Scripts> .\\getUsersDept.ps1\nUser Name: debbieshort\nData Scientists<\/pre>\n\n\n\n
Updated:<\/h2>\n\n\n\n
# Code to getTeam.ps1\n# Search AD for all the users under a manager\n$User = Read-Host -Prompt 'Users CN (username)'\n$Manager = Get-ADUser -Properties * -Identity $User | select Manager -ExpandProperty Manager\n$raw = Get-ADUser -filter {Manager -eq $Manager} | select SamAccountName -ExpandProperty SamAccountName\n# Format the output\n$out = ($raw -join \",\")\n# Display the output\n$out<\/pre>\n\n\n\n