Phishing workflow issue with SIR and Proofpoint PhishAlarm and Analyzer

danielgarner
Tera Contributor

‎10-21-2022 12:17 PM

Running into an issue with ProofPoint PhishAlarm and Analyzer result enriching the SIR workflow and record. We are seeing in some situations with our config with the SIR flow design creating a PHIS with the SIR (best practice) is "too slow" and the PhishAlarm and PhishAlarm Analyzer results are "beating" or "outrunning" the PHIS/SIR creation. This race condition is causing duplicate records separating the parent SIR/PHIS record with the associated analysis from ProofPoint products.

First, has anyone else run into this situation? Second, if so, what is the common and proven fix to maintain the SIR/PHIS configuration while ingesting the PP Analyzer results to the related record?  

0 Helpfuls
  • 984 Views
1 REPLY 1

MikeD3
ServiceNow Employee
ServiceNow Employee

‎01-04-2023 07:10 AM

The following KB article might help with the issue first reported back in October.  This could be a timing issue described here: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0860057

Description

Emails having attachments sent from custom email account (ProofPoint) are sometimes stuck in a send-retry loop and actually sent many times 

One symptom is when we see the following information in a node log when the email is sent:

2020-09-07 07:46:28 (966) worker.7 worker.7 txid=f2294aaadb4f WARNING *** WARNING *** handling smtp exception: javax.mail.MessagingException: Exception reading response;
nested exception is:
java.net.SocketTimeoutException: Read timed out : Exception reading response
2020-09-07 07:46:28 (973) worker.7 worker.7 txid=f2294aaadb4f WARNING *** WARNING *** EMAIL.b0f70ea6db4f54d09a686b4bd39619c8: send-retry

This makes the customer believe that the SN instance might not be waiting for a long enough time to receive a response from a mail server.

Release or Environment

All

Cause

The SMTP timeout duration is something that ServiceNow set at code level and we cannot modify it. The default SMTP timeout is 60 seconds and the default SMTP max timeout is 300.

From the ServiceNow side the step to take is to validate if there is any business rule with current.update in the target or sys_email table. The KB0715782 article that discourages the use of current.update is confirmed by the official ServiceNow documentation page that states Avoid using current.update() in a business rule script.

Resolution

Usually, the loops stop by removing the attachment from the sys_email record. As ProofPoint is not a ServiceNow product and the issue occurs when using an external mail server, it is required to work with the email admin to examine the logs and troubleshoot further.
 
The solution has eventually worked by regular testing with a bit of process of elimination troubleshooting and narrowing down if the formatting of the messages is affecting the ProofPoint ability to allow the messages to be processed. For example, replacing <strong> with <b>, could help the messages to start going through without delay. It could be something as easy as that or much more complex.

Here is a list of external links outside ServiceNow scope that mentions this issue:
0 Helpfuls