Hey Tamara,
I appreciate that input. After doing what David suggested I noticed that I was getting incidents of delivered email that were URL. Well since they were delivered and determined that the URL was bad they were blocking it and is now not a concern. What I needed was the Issues API which from what you suggested I changed the script. Hopefully this will work.
As for the false positives, We regularly see incidents from ProofPoint that they flag as a bad URL or bad attachment that later gets closed as a false positive. We because their TAP events (emails that say if something needs addressed or not) work these incidents and can later be marked as a false positive. I would like, and was working on building a script that could do this, to have the update procedure check to see if the any of the previously determined incidents were marked as false positive and then close them automatically. This could either be done by the poller or could be something within the Resilient platform that uses the threatID or campaignID to look up the incident and determine if any changes have been done with them.
Hope this helps, but feel free to reach out again with any questions!
Thanks!
------------------------------
Nick Mumaw
------------------------------
Original Message:
Sent: Tue February 25, 2020 03:07 PM
From: Tamara Zlender
Subject: ProofPoint TAP Filtering
Hello Nick,
At the moment this function polls events for all clicks and messages relating to known threats within the specified time period. Endpoint /v2/siem/all is hardcoded in the code. As a workaround you could edit it in https://github.com/ibmresilient/resilient-community-apps/blob/8f4ffdebb5f0f5bf180ee22858b47bfaf681423b/fn_proofpoint_tap/fn_proofpoint_tap/util/proofpoint_common.py#L40 and use any of the other available endpoints:
/v2/siem/clicks/blocked Fetch events for clicks to malicious URLs blocked in the specified time period
/v2/siem/clicks/permitted Fetch events for clicks to malicious URLs permitted in the specified time period
/v2/siem/messages/blocked Fetch events for messages blocked in the specified time period which contained a known threat
/v2/siem/messages/delivered Fetch events for messages delivered in the specified time period which contained a known threat
/v2/siem/issues Fetch events for clicks to malicious URLs permitted and messages delivered containing a known attachment threat within the specified time period
/v2/siem/all Fetch events for all clicks and messages relating to known threats within the specified time period
We plan to make an update to have a separate setting in app.config to define the endpoint to use. I hope this will help.
David's suggestion is also a good one!
We do not auto update previously created incidents based on false positive flag. Could you tell me more about how this would work? I see in the TAP API documentation threatStatus has falsePositive value so maybe we could include something like this in one of the future releases.
Thanks,
Tamara
------------------------------
Tamara Zlender
Integrations Engineer - IBM Resilient
Original Message:
Sent: Mon February 24, 2020 12:59 PM
From: Nick Mumaw
Subject: ProofPoint TAP Filtering
I was wondering if anyone else had determined how to filter out the blocked events. I could write a script to do this in Resilient, but I would prefer to not have a million incidents created that are going to be automatically closed. I see that I can filter based on URL or Attachment etc... I want to also filter on if they were blocked or not.
Also does this auto update previously created incidents if they suddenly are marked as a false positive by ProofPoint?
Any help is greatly appreciated.
------------------------------
Nick Mumaw
------------------------------