Why use Duplication Rules instead of Event Management for Security Operations

[R34rvi3w]

Hello all,

 So I know event management is the preferred means of dealing with INC in ServiceNow and that when one is using the default ServiceNow incident creation abilities, one can use the Duplication Rules. In our situation, we have so many things using inbound actions and rules, in this case ServiceNow is skipping over the default of Create Sec Ops Events about four or five down in priority and a whole new inbound rule was made to create SIR. The problem over time has been, for one this seemed overly complex and for two, it's been resulting in duplicate SIR every day for things that Duplication Rules could handle. I think the other challenge was the email parsing couldn't be used because of this. 

 Am I missing something here? If I want to get the proper functionality from SNOW SecOps and do things by the book, would you use event management and custom inbound rules or use the mechanisms that ServiceNow created specifically for this module? Best practices, thoughts all?

[R34rvi3w]

For more context, I have Proofpoint that sends alerts and then creates and alert via a custom inbound rule. I've not been a fan of this because it totally removes the email parsing and duplication rule functionality in SecOps, clearly designed for its own purposes (if not, SNOW would just tell everyone to make their own custom inbound rule for everything you're bringing in right?). 

As such, there is no means of event handling or parsing, nothing is parsed into m2m_task_observable and therefore workflows do not work as expected. I guess someone yesterday tried to say we should use event management to handle these Proofpoint alerts that when one sender sends a malware URL message to 100 receipients, it will create parent and child records. 

 This sounds like an awful idea for one, it ruins metrics because this if handled manually was only one incident with essentially 100 affected users. It also creates confusion for automated reporting in BI platforms, as they pull the incident description and close notes for high priority SIR. I would also think this would be awful for performance on the SNOW side of things too, because automation workflows would have to be ran inside of every parent and child incident - not to mention DoS my alert and mitigation sources - as we send API requests to block the sender 100 times, attempt to pull messages from mailboxes one at a time (instead of in one API request) and then moreover, resetting passwords/tokens and the containment of the phishing URL 100 times against the firewalls. 

 To me, this sounds absurd from a user and consumer of this solution. I would think there should be one SIR, created from Record SecOps Email Events and then using the Email Parsing into expected fields. For the 100 email alerts that will be received, the remainder 99 would then be handled by duplication rules and would somehow add the other 99 impacted users to the affected user field (this however may not work if one to one) or perhaps another field that would work like the observables, where all the other 99 or maybe all 100 would be listed in the same SIR - permitting workflow and automations to be ran as a whole and integrations to 3rd party API's are not exhausted.

[andy_ojha]

Hey there,

It sounds like you have another inbound email action that is potentially picking up emails you want targeted to SIR (perhaps the Condition on it is "greedy")...

The Duplication Rules are definitely a powerful and flexible feature as you pointed out here.

Is there an opportunity for you to consider using Tags with your SMTP configuration here?  If so, you could potentially investigate using Tags a means to have your emails sent to ServiceNow, explicitly match to the inbound actions you need here (i.e. Record SecOps Event), and bypass some of the lower ordered ones that seem to be winning now.

There is a post here that shows an example of configuring your Email Properties with Tags:
https://community.servicenow.com/community?id=community_question&sys_id=07bd56d6dbe13b844819fb24399619e2&anchor=answer_a83d4756dbedbb844819fb24399619ed&view_source=searchResult

This page in the docs site also shows using Tags with an email destination address when configuring the User Reported Phishing capability:
https://docs.servicenow.com/bundle/london-security-management/page/product/security-incident-response/task/create-email-matching-rules.html

If you have the ability to leverage SMTP Tags and do some testing, I would be curious to see if you get a win and bypass the inbound email actions currently winning.  This way you could leverage the SN SecOps Email processing features (i.e. Duplication Rules, User Reported Phishing, etc).

[R34rvi3w]

Unfortunately I do not as this is a very large instance and does not use SNOW Default SMTP. The mail server does not support those therefore I have created a separate identity to handle those going forward. In either case, I'm trying to get professional suggestions on best practices 

• Do we do what we are doing now, bypass the Record SecOps Email Events and use Custom Inbound Rules, attempt to get them to somehow perform proper parsing to m2m_task_observable and use event management to handle duplicate or additional notifications that need to be concatenated into the same SIR (we do not desire parent-child SIR)?
• Do we instead find a means to stop using Custom Inbound Rules and actions to create an SIR and instead, use a dedicated SMTP address (which will be defined in SecOps Email Properties) and then use both Email Parsing and Duplication Rules within the same app/module (wouldn't this be easier for Security Teams who rely on 3rd party support for adding new use cases/alert sources)

I'm hoping someone can answer this is more specifics as to which is better practice and why?

Thank you!

[andy_ojha · Accepted solution]

Hey there,

I understand and can surely appreciate the scenario you are tackling.

I would vote for putting effort and time towards investigating ways to leverage the baseline 'Record SecOps Email' inbound action -> where you might explore avenues such as using SMTP Tags, or working with your SN Platform Team to investigate opportunities to carve this inbound action out using some sort of condition targeting <sender>, <recipients>, <subject> or something from the message body / header.  It's a bit difficult to analyze this remotely without seeing what other inbound actions are winning / why; if you need help with that part, perhaps you can work with your internal SN Platform Team and / or SN HI Support.

In addition to the useful features you mentioned (dedup rules, parsing of observables) -> this capability also provides a neat way to preview the email message in HTML using the "New UI", and is a vehicle for using the mail blocking integrations with Exchange (which you may or may not potentially check out down the road).

Further, as time goes on - there will likely be enhancements made to the User Reported Phishing capability that you may miss out on.

I would put the effort towards getting the 'Record SecOps Email' inbound action to trigger and realizing the baseline benefits of this versus trying to re-create this in a custom fashion and always having to maintain that / keep up over time.