Threat Response - Integration with Imperva

The Imperva SecureSphere platform enables administrators to design access policies for sites and services within their network. By interfacing Imperva with Threat Response, dynamic policies can be created that will enable security teams to remove or restrict access to a server or service at the press of a button. Threat Response’s automated response capabilities can also be utilized to update policies in real time as users are reported in security alerts.

Supported Imperva systems include:

Platform	Version
SecureSphere	Supported: 11.5 Certified: 11.5

Connecting Threat Response to Imperva

Connecting to Imperva is simple, and is accomplished by way of Active Directory. Threat Response’s ability to manage groups in Active Directory allows security teams to place users into restrictive or monitoring groups as part of the incident response process. Imperva can then apply access policies based on these groups. In this chapter we will cover how to create a new group in Active Directory for Threat Response to synchronize to, and how to map this group to Imperva for use in security policies.

Synchronizing Threat Response to Active Directory

Threat Response will interface with Imperva through Active Directory. To facilitate this interaction, a Security Group should be created in Active Directory that can be used within Threat Response as part of the incident response process. When creating your group, ensure that the group’s naming convention fits within your security team’s workflow for identifying users that may pose a security threat.

For demonstration purposes here, we will utilize a group called PTR_Suspicious_Users. Any user reported in a security incident will be immediately placed into this group while an investigation commences. By doing this, we can restrict access to sensitive systems until we are able to determine if the user is a true threat, or until the problem has been remediated.

Note

It is recommended to name Security Groups utilized by Threat Response such that they are easily recognizable within your groups list in Active Directory. In our example, we have prefixed the group name with “PTR_” so that we know this is a group managed by Threat Response.

Once the group has been created, you can follow the steps below to link Threat Response to the group. You will first create a local list in Threat Response that analysts can place users into. You will then connect Threat Response to Active Directory, and create a list mapping to map the local list in Threat Response to the group in Active Directory.

Create a list in Threat Response

1. Log in to Threat Response.
2. Navigate to the Lists > User Lists page.
3. Click the blue Add (+) button to create a new user list.
4. Configured the following fields:
   • Name: Suspicious Users
   • Description: <list_description>
5. Save changes.

Create an Active Directory device in Threat Response

• Navigate to the Devices > Directory Servers page.
• Click the blue Add (+) button to connect to a new directory server.
• Configure the following fields:
  • Type: Active Directory
  • Name: <server_name>
  • Description: <description>
  • Hostname / IP: <ip_or_hostname>
  • Bind DN: <user_dn>
  • Password: <password>
  • Update Schedule: Every minute
  • Search Base: <ldap_search_base>
• Save changes.

Note

Setting the Update Schedule to Every Minute ensures that any pending updates will be synchronized to this device within 60 seconds. This can be adjusted to comply with your organization’s change policies.

Upon saving the change, you will see your new device appear in the table to the left. Ensure that the status icon changes to a green color prior to moving on.

Map the User List to the Security Group

1. In the device panel for your new device, locate the Mappings section.
2. Click the blue Add (+) button to connect to a new list mapping to the device.
3. Configure the following fields:
   • List: <user_list_name>
   • Name: <security_group_name>
4. Save changes.

Note

Upon clicking Save, Threat Response will connect to the device to ensure that the group exists, and then perform its first sync. Any existing data in the group will be overwritten at this time.

When the mapping is saved, Threat Response will immediately check the server to ensure the Security Group exists, and perform its first synchronization. The status of this update will be recorded in the Recent Updates section in the device panel. Before moving on, you should ensure that the synchronization was successful.

Creating a Global Object in Imperva to Pull Group Information

With the configuration completed in Threat Response, you can begin working in Imperva to complete the integration process, and begin building policies. The first task will be to create a Global Object in Imperva that references the Security Group created in Active Directory.

To create a Global Object referencing the Security Group:

• Log in to Imperva SecureSphere MX.
• Navigate to Setup > Global Objects.
• Click the green Add (+) button to create a new data set with the following parameters:
  • Name: <name_reflecting_security_group>
  • Columns: User, Security Group

• Click Create.
• Click to select the new data set and open its configuration.
• Set the following parameters in the Data tab:
  • No changes required.
• Set the following parameters in the Keywords and Relevance tab:
  • No changes required.
• Set the following parameters in the Query tab:
  • External System Type: LDAP
  • External System Name: <select_ldap_server>
  • Search Base: <ldap_search_base>
  • Search Scope: Subtree
  • Filter: (memberOf=<full_group_canonical_name>)
  • Query Attribute: Set the following for the query attributes:

Data set column	Query attribute	Match pattern	Subs. pattern
User	userPrincipalName	^([^@])@([^.])..*$	$2\$1
Security Group	memberOf	^CN=([^,]),.$	$1

• Set the following parameters in the Scheduling tab:
  • Occurs: Recurring, Custom, Every 1 minute(s)
  • Starting From: <current_date>
  • At Time: <current_time>

• Save changes.

With your data lookup changes saved, you can run a test from the Query tab. Click the Test Query button to perform the lookup. If users have been added to the Security Group, you will see them appear in the Sample Results table below.

Threat Response and Imperva are now linked together, and sharing information from the same Security Group. In the next section, we will discuss how to reference that group when building a Security Policy in Imperva.

Creating a Security Policy in Imperva

With Threat Response and Imperva joined together, you can now build policies that reference the Security Group. You should locate a server or service set that you want to apply an access restriction to. In our example here, we will create a simple policy that blocks database access for any user found in the Security Group.

To create the policy:

• Navigate to the Policies > Security page in Imperva.
• In the left-hand panel, create a filter to locate the server or service you want to apply the restriction to, and select the service.

• Click the green Add (+) button to create a new policy for the service.

Note

The policy should allow for Match Criteria to be defined. In our database example, we are using a generic policy type of: DB Service Custom.

• Click to select the policy and open its configuration.
• In the Match Criteria tab:
  • Action: Block
  • Severity: <set_desired_severity>
  • Followed Action: <set desired_followup_action>
  • Enabled: Yes
  • In the Available Match Criteria table, locate Database User Names (Lookup Data Set) and add it to the policy.
  • Expand the Database User Names (Lookup Data Set) match criteria, and configure the following:
    • Field: Database User Names
    • Operation: At least one
    • Search In: No changes required
    • Lookup Data Set: <data_lookup_object>

• In the Apply To tab, select the scope for the policy.
• Save changes.

Your policy is now configured, and this completes the basic components for integration. Additional Security Groups and policies can be created and applied to more services as needed.

Testing the Integration

With everything in place, you may want to perform a quick test to review synchronization times and confirm that everything is working as expected. Below is a quick set of steps that can be used to check each step of the integration.

To test and confirm the integration:

1. Create a new incident within Threat Response.
2. Open the incident and navigate to the Identity tab to view user details.
3. Click the Response button at the top of the page to execute a response as a security analyst would. The response should be set to add the user to your newly created list in Threat Response.
4. Open Active Directory, and then open the properties for the Security Group. Within about 1 minute, you should see the group updated to include the user.
5. Open Imperva, and then open the properties for the Data Lookup global object. Within about 1 minute, you should see the Data tab update to show the latest information from the Security Group.
6. Finally, attempt to access your database using the test account. Access should be restricted.

Note

Ensure that the incident references an IP associated with a username that you can test with. A test account with DB access would be useful in for the example scenario used in this document.