Threat Response - Integration with TAP

This document covers all aspects of Threat Response integration with Proofpoint Targeted Attack Prevention (TAP) service.
Proofpoint TAP monitors email flow for malicious content, such as malicious URLs and objects. Upon detecting that an email delivered to a user contains malicious content, the TAP service can generate an alert to Threat Response for further investigation.

Targeted Attack Protection Demo

Configuring the Proofpoint TAP Event Source

The steps below describe the process of creating a Proofpoint TAP event source in Threat Response. Once configured as alert source, the Targeted Attack Prevention service will notify Threat Response when malicious content is detected in customer emails, and will generate an incident in Threat Response.

Generate TAP Service Credentials

First, you will need to generate TAP service credentials.

1. Login to the TAP dashboard at https://threatinsight.proofpoint.com
2. Navigate to Settings > Connected Applications
3. Click Create New Credential
4. Name the new credential set and click Generate
5. Copy the Service Principal and Secret to a notepad

Warning

It is important that you copy these credentials; they will not reappear and are not retrievable after the light-box has been dismissed.

Gather TAP Base URL and Customer ID

To enable TAP Dashboard integration within Threat Reponse, you’ll need to gather some information from TAP. This integration allows for linking back to the TAP Dashboard from incidents and alerts in Threat Response, to view additional threat and campaign information.

1. Login to TAP dashboard at https://threatinsight.proofpoint.com
2. Copy the the URL area as shown on the image below
3. The first part becomes the Base URL in Threat Response, and the second part becomes the Customer ID.

Example

In the example above, we copied:
https://threatinsight.proofpoint.com/cb015b47-5fcd-5e19-f058-f9c8c333a602

Now, we can obtain:
- Base URL: https://threatinsight.proofpoint.com
- Customer ID: cb015b47-5fcd-5e19-f058-f9c8c333a602

Create an Event Source in Threat Response

As a final step, you need to create an event source in Threat Response to receive alerts from Proofpoint TAP. You will need to input the configuration parameters (service credentials, Base URL, and Customer ID) for TAP alert source to work properly.

1. Log in to Threat Response.
2. Navigate to the Sources page.
3. Click the blue Add (+) button next to Sources to bring up the New Source panel.

• Set the following fields:
  • Type: Proofpoint TAP
  • Name: provide the name of the event source
  • Description: provide the description of the event source
  • Link events: enable to let Threat Response automatically group events into incidents
  • Alert types: this options lets you choose what alerts you want Threat Response to be pulling from TAP
    • Delivered attachment threats: These are TAP alerts for emails delivered with malicious attachments
    • Permitted clicks: These are TAP alerts for emails delivered with malicious URLs that were clicked on prior to condemnation (URLs have been re-written)
    • Unprotected URLs: These are TAP alerts for emails delivered with malicious URLs (URLs have not been re-written)
    • Delivered URLs: These are TAP alerts for emails delivered with malicious URLs that were not clicked on prior to condemnation (URLs have been re-written) - this shouldn’t be checked as it can significantly increase your alert volume
    • Impostor messages: These are TAP alerts for emails delivered and classified as impostor messages
  • Enter service principal and secret for authentication (details here)
  • Enable TAP Dashboard integration: This option will enable the in-context redirection to TAP dashboard whenever you click on the campaign or threat data links associated with your incidents and alerts
  • Enter Base URL and Customer ID so that Threat Response can connect to TAP (details here)
• Save changes.

TAP Alert Severities in Threat Response

The various alert types generated by TAP map to specific severities in Threat Response. The mappings are as follows:

TAP Alert Type	Threat Response Severity
Permitted Click	Critical
Unprotected URL	High/Major
Delivered Attachment	High/Major
Impostor Message	High/Major
Delivered URL Threat	Informational

To determine the TAP alert type when the severity is High/Major, navigate to the Raw Alert on the Alert Details page and search for tap_alert_type.

Best Practice Match Conditions

There are 6 match conditions for the TAP source as part of Threat Responses best practices.

1. Permitted Click - PHISH

   This alert means that a URL was delivered to the end user and believed to be safe at the time of delivery. However, some time later, the user has clicked on the URL, it was sandboxed in parallel and determined to be a phishing attack. From this point onwards, all other users who received this link will be presented with the TAP block page preventing them from accessing the threat.

   In this example we quarantine the message, close all email related incidents (incidents with the same Message ID and recipient email address) and leave the current critical incident open.

   Threat Response has built in Active Directory Responses to let the users account be disabled, password forced to be change or password invalidated automatically when the alert is processed. More details on this type of response can be found under Active Directory Responses.

   Beyond quarantining the email, the investigating team will need to begin their account remediation process – it is not enough to simply quarantine the email and move on. The users account protection is the highest priority when this match condition is triggered.

   

2. Permitted Click - MALWARE

   This alert means that a URL was delivered to the end user and believed to be safe at the time of delivery. However, some time later, the user has clicked on the URL, it was sandboxed in parallel and determined contain malware. From this point onwards, all other users who received this link will be presented with the TAP block page preventing them from accessing the threat.

   In this example we quarantine the message, close all email related incidents (incidents with the same Message ID and recipient email address) and leave the current critical incident open.

   Beyond quarantining the email, the investigating team will need to begin their endpoint protection process – it is not enough to simply quarantine the email and move on. It’s important to note the end point that is at risk in this situation, the IP/system details on where the click occurred from is available on the TAP Dashboard.

   

3. Delivered Attachment/Unprotected URL - PHISH

   This alert means that an attachment/unprotected URL was delivered to the end user and determined to be a phishing attack post delivery. There is no way to detect if the user has interacted with the threat since the URL could not technically be rewritten and an email gateway cannot determine if an attachment was opened post delivery (eg: PDF, Word docs. etc.)

   Since there is no confirmed interaction with the threat, these types of alerts carry a lower severity (Major) compared to the permitted click alerts which have the highest severity (Critical).

   Beyond quarantining this email, the investigating team should check the logs to validated if any of the URLs have been visited.

   Note: the incident will auto-close if there was a successful quarantine. If the quarantine was unsuccessful, the investigating team should review the incident to determine the cause of the quarantine failure (no valid smtp address, Exchange throttling, couldn’t find the message etc.)

   

4. Delivered Attachment/Unprotected URL - MALWARE

   This alert means an attachment/unprotected URL was delivered to the end user and determined to contain malware post delivery. There is no way to detect if the user has interacted with the threat since the URL could not technically be rewritten and an email gateway cannot determine if an attachment was opened post delivery (eg: PDF, Word docs. etc.)

   Since there is no confirmed interaction with the threat, these types of alerts carry a lower severity (Major) compared to the permitted click alerts which have the highest severity (Critical).

   Beyond quarantining the email to prevent the user from accessing the malicious content in the future, the investgating team should begin checking the endpoints, firewall logs, proxies, SIEM etc. In this scenario, Proofpoint has no insight into which end point may be affected.

   Note: the incident will auto-close if there was a successful quarantine. If the quarantine was unsuccessful, the investigating team should review the incident to determine the cause of the quarantine failure (no valid smtp address, Exchange throttling, couldn’t find the message etc.)

   

5. Delivered Impostor

   This alert means that an end user has responded to an Impostor/BEC message after delivery. You can identify the user at risk and respond to this incident outside of TRAP.

   

6. Delivered Spam

   This alert means that spam was delivered to an end user, TRAP will attempt to quarantine the email as a courtesy to the end user, to clean up delivered spam but regardless of whether the quarantine was successful or not, the incident will be closed. This is because nothing further is required from the administrator team, no investigation is usually required if a quarantine fails.