How to create only one Security Incident from multiple emails or reports for the same issue arriving into the instance

[bpolo]

At times we get multiple emails (that might not always be in the same format) for the same security issue (ex. a compromised account). We are not wanting to create Security Incidents for each email regarding the same issue, but only one. Please can anyone advise how one has done this. I do see there is the option on Duplication Rules to set a Duplicate Action to "Do not create or update records". This could work if the emails are coming in the same format, but how would one do this if the format of the emails are coming in in different ways for the same issue. Thanks!

[andy_ojha]

Got it.

Have you explored / tested the 'User Reported Phishing' capability with Security Incident Response?

This would fit the use-case you're describing in the context of users reporting suspicious emails to be investigated and handled.  In London, users would have to send the suspicious email messages to ServiceNow as an attachment (e.g. Forward as an attachment). 

When a user forwards the suspicious email message as an attachment to ServiceNow, the original copy of the suspicious email won't be available for modification.  The user can modify the message they are sending to ServiceNow (body, subject, etc) - but they are not touching the content of the malicious email attached to that message as a file.

Using this method in London, a new Security Incident Response record would be generated with:

- Source = Email
- Category = Phishing
- Short description = User Reported Phishing - Subj: <SUBJECT OF ORIGINAL SUSPICIOUS EMAIL MSG>
- Affected user = ServiceNow user account linked to the person that sent the malicious email to SN as an attachment

There is an opportunity from here, to possibly leverage the SIR Duplication Rules and aggregating with the following fields --> (Source, Category, and Short description) fields -- Affected user, would not be leveraged here...

Primarily, you'd be keying off the 'Subject' of the suspicious email message that was reported to ServiceNow, to correlate matching SIR records that relate to user reported email messages.

There's no predicting phishing campaigns that offset their email subjects and rotate words, etc - but at least you would be able to deduplicate reported emails based on the exact same subject as matching condition.

Would recommend you explore / test the User Reported Phishing capability first, then look at how the SIR Duplication Rules could be applied to this scenario and continue to test the the Duplication Rules with all other inputs you have feeding SIR to prove out functionality and identify possible conflicts (i.e. if you have monitoring tools / a SIEM feeding SIR via email messages)...

Ref: https://docs.servicenow.com/bundle/london-security-management/page/product/security-incident-response/concept/sec-inc-created-from-user-rpt-phishing.html

[bpolo]

Thanks again Andy, for all your VERY helpful input. Leveraging the suspicious email as an attachment would be best. I guess the only challenge with that is that how does one train all clients to attach the suspicious email rather than forward the email when they are reporting the issue.  

[andy_ojha · Accepted solution]

Hey there - yes, that can be indeed a challenge to train end users to follow.

Even without ServiceNow SIR in the picture; if an end-user only forwards a suspicious email message to a security team for analysis - a big part of the picture is missing without providing the actual original email message as an attachment.

Your security analysts likely want to investigate certain content of a suspicious email message that is only available if an end-user sends the original email message as an attachment to a target mailbox; i.e. the content of an email header, etc.

It's worth the effort of coming up with a solution for; whether it be through awareness training or a technical solution.

There are some popular paid solutions / open source solutions out there that introduce a new button on various email clients, such that users can click that button from an email client to "report a suspicious email" - which then handles creating a message with the suspect email as an attachment, and sending it to a defined target mailbox.

[cashmere]

Hi, thanks for sharing this information, I found it very useful.