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

bpolo · ‎01-24-2019

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 · ‎01-28-2019

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.

View solution in original post

SanjivMeher · ‎01-24-2019

We usually create security request and from request, we create incidents.

If multiple request comes, we make one as parent and rest all as child. It is good to create multiple request or incident, so that we know how many users are affected and all individual users are notified.

So I would suggest, you allow creating incidents and ask your analysts to make rest of the incidents as child of the incidents.

Please mark this response as correct or helpful if it assisted you with your question.

bpolo · ‎01-25-2019

Thanks for your reply, Sanjiv! We did consider parent/child, but we dont want to create that many SRs for the same issue. For example there could be 50 emails sent in relating to the same Security Incident.

andy_ojha · ‎01-25-2019

Hey there - as you continue exploring and testing the 'Duplication Rules' feature there are some dependencies to consider around how it would work with emails of different formats. Sanjiv's alternate method is also something to consider, though the process would be different for the analysts when using Security Requests.

Are these emails coming in via the 'User Reported Phishing' mechanism, or via emails that are handled and parsed via the 'Security Operations | Email Processing | Email Parsing' config, or both?

The key will be determining which {fields} on the SIR you want to aggregate by when working with the Duplication Rules.

Even though emails will be in different formats, the duplication rules will look at the values on fields on the SIR record itself. So the emails with "different formats" would be normalized when SIR records are created, and the duplication rules work off the normalized data regardless of the email format.

Some values on the SIR are set regardless of content of the message body (e.g. Category and Subcategory) and some are set based on content of the email message being parsed out and placed into a field on the SIR record (e.g. Affected user, Source IP, Short description, etc).

The key exercise is to look at what {field:values} or (transforms) are being performed on emails received that create SIR records - and the values being set on {fields} within the SIR record. This would drive how you could leverage the aggregation from duplication rules, based on a set of specific {fields}.

bpolo · ‎01-25-2019

Thanks very much for your response, Andy!

These emails in general would be coming from the Email Processing/Parsing (although some might be phishing) where a compromised account would send messages to many different users, and then they all in turn forward the message to an email address like postmaster@xxx. Some users might add wording to the email, so they would not all have the same content, even though they all relate to the same compromised account. We somehow need to aggregate what ios coming in on the email, rather than what is set up on the SR, as that is what needs to be decided, do we create a new SR, or does the email relate to an existing SR. Thanks!