Threat Response - Integration with CyberArk

Integration between Proofpoint Threat Response and the CyberArk Solution helps mitigate the risk of a potential breach by making it difficult for attackers to access an organization’s IT infrastructure, disable security controls, steal confidential information, commit financial fraud and disrupt operations.

Proofpoint Threat Response integrates with CyberArk Privileged Account Security Solution through Active Directory. Upon receiving the security event Threat Response can manually or automatically place the user associated with the security event into a pre-determined Active Directory group. When that quarantined user tries to utilize privileged credentials, the CyberArk Privileged Account Security Solution can immediately implement higher security controls around that user’s privileged access rights and capabilities on critical assets.

The integration between Proofpoint Threat Response and CyberArk was developed around CyberArk’s PVWA Ticketing Integration framework, which allows the system to validate whether a user has been quarantined before granting access to a Privileged Account (Show, Copy, or Connect).

Threat Response interfaces with CyberArk 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.

Synchronizing Threat Response to Active Directory

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.

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.

Step 1: 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.

Step 2: Create an Active Directory device in Threat Response

1. Navigate to the Devices > Directory Servers page.
2. Click the blue Add (+) button to connect to a new directory server.
3. 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. 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.
   • Search Base: <ldap_search_base>
4. Save changes.

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.

Step 3: 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>. 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.
4. Save changes.

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.

Configuring CyberArk

Because this integration is done through Active Directory, you must have CyberArk already configured with AD before proceeding. The PVWA relies on your AD Domains and on the quarantine groups, created by Threat Response:

The code is delivered through a single DLL file (ProofpointValidator.dll); the interaction with Threat Response is governed by a specific set of Ticketing Parameters described in the Configuration section of this document.

The integration defines a hierarchy: Domain -> Rule -> Condition. Where Domain and Rule are mandatory. These are defined in the Ticketing System parameters section on the PVWA Administration page. You can specify as many parameters as required. The parameters can be specified in different hierarchies and levels and are transferred to the integration module in an xml object when a user clicks on Show, Copy, or Connect. Based on the logic defined by these parameters, the integration module determines if the user will be denied access. See Appendix 1 for an example of the XML object.

Installation

Copy ProofpointValidator.dll to %inetpub%\wwwroot\PasswordVault\Bin on the PVWA server, then restart IIS.

Configuration

Log-in to the PVWA as a vault administrator user, then go to ADMINISTRATION and click on Options:

Right-click on Ticketing Systems and select Add System:

On the Properties section enter the following information:

• Name: You can enter any value.
• Assembly: Corresponds to the name of the dll file provided in the package. You must enter ProofpointValidator as shown here.

After clicking Apply, Proofpoint will appear under Ticketing Systems. Right click on it and select Add Ticketing Parameters:

A new Ticketing Parameters section will appear under Proofpoint. Right click on it and select Add Parameter:

Name this Parameter Message and enter a generic message you want the PVWA to display when denying access to a quarantined user. This message will apply to all Domains in your AD.

You will be able to define additional messages, which will follow the generic message, providing specific details, in the following subsections. Repeat the process to add a new parameter called Domain. The value of this parameter must be one of your Active Directory domains:

This integration release supports only one type of rule, ExcludeGroup, which is one of the AD groups maintained by Threat Response containing quarantined users. However, you can add multiple rules per domain. Right Click on Domain to Add a Rule:

A rule by itself is sufficient to deny access to a quarantined user. You can also add conditions to the rule to further refine what a quarantined user will be allowed to access, based on properties of the target account (refer to Appendix 2 for more details). For example, let’s say we want to limit the quarantine to Database devices only while allowing him/her access to all other device types:

You should also define a specific message (optional) to the Rule (ExcludeGroup) or Condition (DeviceType), which will be concatenated to the generic message, to add more details. You should have one Message parameter per rule, or per condition.

Enabling the integration for the relevant platforms

Enable Threat Response Integration (Ticketing System) for platforms where you want to deny quarantined users. Log-in to the PVWA as a vault administrator user, go to ADMINISTRATION and click on Platform Management. Select your platform and click on Edit:

If you do not already have an active Ticketing System, then expand UI & Workflows, click on Ticketing System, and set both EnterTicketinginfo and ValidateTicketNumber to Yes. Then click OK:

Note

If you have multiple ticketing systems you can enable only some of them for a specific platform, please refer to section “Integrating with Ticketing Systems” of the “Privileged Account Security Implementation Guide” documentation.

Testing

To test, login as a quarantined user, select an account belonging to the DeviceType you entered, and click on Show. You should see the Ticketing System dialog:

Click on OK and you’ll see the error message denying access to password:

Appendix 1: XML example

<TicketingParameters>
    <Parameter Name="Message" Value="Access denied by Proofpoint" />
    <Parameter Name="Domain" Value="CYBERARK.local">
        <Parameter Name="Message" Value=" [CYBERARK.local] " />
        <Parameter Name="NotMemberOfGroup" Value="Proofpoint-InfectedUsers">
            <Parameter Name="Message" Value=": Quaratined Infected User (Proofpoint-InfectedUsers)" />
        </Parameter>
        <Parameter Name="NotMemberOfGroup" Value="Proofpoint-PCI-BlockedUsers">
            <Parameter Name="Message" Value=": Quarantined PCI Access (Proofpoint-PCI-BlockedUsers)" />
            <Parameter Name="REGEX:PolicyId" Value="(PCI)">
                <Parameter Name="Message" Value=" - Platform matched PCI" />
            </Parameter>
            <Parameter Name="REGEX:SafeName" Value="(PCI)">
                <Parameter Name="Message" Value="- Safe Matched PCI" />
            </Parameter>
        </Parameter>
        <Parameter Name="NotMemberOfGroup" Value="Proofpoint-Database-BlockedUsers">
            <Parameter Name="Message" Value=": Quarantined Database Access (Proofpoint-Database-BlockedUsers)" />
            <Parameter Name="DeviceType" Value="Database">
                <Parameter Name="Message" Value=" - Target Device is Database" />
            </Parameter>
        </Parameter>
        <Parameter Name="NotMemberOfGroup" Value="Proofpoint-DomainAdmin-BlockedUsers">
            <Parameter Name="REGEX:PolicyId" Value="Domain" />
            <Parameter Name="REGEX:SafeName" Value="(Domain)" />
        </Parameter>
        <Parameter Name="NotMemberOfGroup" Value="Proofpoint-Vendor-BlockedUsers">
            <Parameter Name="REGEX:UserName" Value="vendor" />
        </Parameter>
    </Parameter>
</TicketingParameters>

Appendix 2: Supported properties for conditions

You can add conditions to rules to further refine what a quarantined user will be allowed to access, based on properties of the target account, or the requesting user.

Property	Description
SafeName	The Safe where the requested account is stored.
MachineAddress	The address of the machine specified on the account, if it exists.
TransparentMachine Address	The address of the machine used in a transparent connection, if it exists.
UserName	The name of the user specified on the requested account.
PolicyId	The name of the platform specified on the requested account.
RequestingUser	The name of the user requesting the account.

In addition to the properties listed above, all target account properties are available, such as: DeviceType, Port, Database, LogonDomain, etc.

Supporting exact match comparisons or regular expressions you can add logic like:

• Do not allow if the DeviceType is “Database” or “Operating System”
• Do not allow if SafeName or PolicyID has PCI in their name

If the property name is prefixed with REGEX: the value will be used as a regular expression comparison, otherwise it will be used as an exact match: