question Re: Security incident inbound email action has a confusing condition in SecOps forum

Security incident inbound email action has a confusing condition

Ravish Shetty — Fri, 23 Aug 2019 19:42:01 GMT

hi all,

we have the email inbound action part of the security incident response application and it has this out of box condition which I am not sure of

is it expecting recipients to have 'sn_si' in the email address? if that is the case, do we provision a mailbox with that text in the email address and use that mailbox to create security incident tickets? I can always modify the condition but don't want to customize this action.

Re: Security incident inbound email action has a confusing condition

Mohit Kaushik — Fri, 23 Aug 2019 19:55:44 GMT

Hi Ravish,

By the above screenshot of conditions it looks like it requires the recipients to have that sn_si in their email address, then only it will create or update the incident. I am not sure whether that is a required condition for this. But you can do it other way round by creating a custom action and action and make this one as false. In that way you will be having the main action as well and if you want to use it again just make the active true for the same.

Hope that helps you. Please mark it helpful if it really helped you.

Thanks,

Mohit Kaushik

Re: Security incident inbound email action has a confusing condition

SanjivMeher — Fri, 23 Aug 2019 20:40:06 GMT

I dont think, thats an OOB inbound actions. Someone must have modified it.

But for Security Operations, we usually use an Email parser.

Re: Security incident inbound email action has a confusing condition

Ravish Shetty — Fri, 23 Aug 2019 21:52:50 GMT

based on the updated by and updated date it looks like it was part of the OOTB setup

Re: Security incident inbound email action has a confusing condition

SanjivMeher — Fri, 23 Aug 2019 23:58:24 GMT

Ok..I see that too

I think you need to change that with your company's id.

For ex, we check if recipient is csirt@mycompany.com. So you can replace sn_si with csirt or any email id thats used by your company.

Re: Security incident inbound email action has a confusing condition

andy_ojha — Sat, 24 Aug 2019 17:43:04 GMT

Hey Ravish - Yes, that is an older (prior to Kingston) baseline SIR inbound action that is still kicking around. I believe the condition is mocked up to provide an example / leading point for configuring this (or cloning and adjusting this).

You may want to check out some of the newer (introduced in Kingston+) SIR Email Processing capabilities introduced into the SIR app, since that specific inbound action was around. These are meant to be configured and tuned for your use-cases, such that you do not need to touch `Inbound Email Actions`.

In the app nav menu, check out Security Operations > Email Processing ...

You will see several modules here.

You can configure inbound emails for scenarios such:

- Security tools to send emails to SN and create SIR records

- Users to report phishing / suspicious emails by sending them to SN as an attachment (this feature is pretty neat, it parses artifacts from the msg attachment to create Observables that can be used for Threat Lookups and other slicing and dicing)

- Ad-hoc users to send emails to SN to create SIR records

Using these capabilities offers duplication / aggregation capabilities, parsing capabilities - in bit more 'configuration friendly way', than the platform Inbound Action. Also, users with the <sn_si.admin> role, can modify these configs; whereas Inbound Actions at the platform level are not necessarily accessible to users only having the <sn_si.admin> role.

The [Email Parsing] Module, essentially allows you to create your own configurations to control what to do when an email is received (based on criteria such as subj, recipients, body text, etc) - and you can use this to parse data / set values on the target SIR records that are created.

If you are curious, you can check out the Inbound Email Action called "Record SecOps Email Events". This acts a front, to the Email Processing capabilities, and leverages the configurations you make within the Email Processing configs (i.e. SIR Email Parsing Rules). There are two Inbound Email Actions called "User Reported Phishing", that acts as a front, to the User Reported Phishing configurations you make (sender, subject, body, etc) (one covers new msgs and one covers fwd msgs).

Using the [Email Parsing] or [User Reported Phishing] here allows you configure what you need, without having to touch the `Inbound email actions`, and with only having the <sn_si.admin> role.

The one caveat to not needing to touch these Inbound Email Actions, may occur when custom Inbound Actions were introduced onto the SN Platform with very broad conditions and a low Order number that it is ran with; sometimes the Order number may need to be adjusted on these "SecOps" Inbound Email Actions (this may involve working with someone who has the platform <admin> role)...

Reference:

https://docs.servicenow.com/bundle/madrid-security-management/page/product/security-operations-common/concept/email-parsing.html

https://docs.servicenow.com/bundle/madrid-security-management/page/product/security-incident-response/task/create-email-matching-rules.html

Re: Security incident inbound email action has a confusing condition

Ravish Shetty — Mon, 26 Aug 2019 21:37:22 GMT

hi Andy, I activated the plugin in Madrid so I am not sure why I see a Kingston inbound action.

Re: Security incident inbound email action has a confusing condition

andy_ojha — Mon, 26 Aug 2019 21:46:53 GMT

Hey Ravish - You will see this `Email Inbound Action` on a fresh Madrid install SIR.

There are some components introduced in earlier versions of the product, that are also included in the current release (such as this inbound email action).

I would try to use the new SecOps email handling capabilities (i.e. Email Parser) rather than this inbound action, for the use-cases you might be looking at.