Email Parsing vs Inbound Email Actions

[SanjivMeher]

Do we need an inbound email action, when there is already an email parsing for security operations?

How is both different from each other and should both be used for processing inbound emails for security incidents or just email parsing.

[dan_tembe]

Sanjiv,

We have Security Ops package and here is my response based on my experience so far. 

1st - look at Security OPerations as a copy of Event Management (from ITOM). Basically the same tables for events and alerts - em_events & em_alerts are used to feed the Security OPerations table. 

Secondly, As far as I can see, all the integrations you have built into your ITSM can be reused to map into Sec Ops. 

So if you had emails coming as notifications from SIEM/HIDS/NIDS/VA tools you can parse them in "System Policy -Inbound Actions". Here you can either use the create a Security Incident, or create event.

In my design, I route everything into an event, then I can write rules before the events can be mapped to alerts and then task template & alert action to create a Security Operations Incident. 

As an added bonus, you can even take of your network or system alerts (if you have ITOM-Event management) and route those alerts into Security Operations Incident queue via same workflow. 

Hope this helps.

Thanks!
Dan

[jhon]

I did not think that you need any kind of inbound email action when you have security operations. i already have done this operation without inbound email action, but yes sometimes it creates a problem when you do this, so that time I suggest you go Gmail support USA for help, they told you the process which you will need to follow.

[Jon Williams]

Hi Sanjiv,

Inbound Email Actions and SecOps Email Parsers are very similar. There are a few differences, one being that SecOps Email parsing module allows you to specify 4 distinct Email Parsing inboxes (Security Operations tools, Security Incident tools, Vulnerability Response tools and Threat Intelligence tools). This gives you more flexibility to distinguish and separate where different alerts/emails are coming from based on the type of tool and the inbox that you've configured for them. 

With Inbound Actions you also don't have the separation from the rest of the platform as you do with SecOps Email parsing, giving you the ability to keep SecOps parsers limited to the Security team(s). This also means that you need to be an admin to create or edit Inbound Actions and SecOps Email module only requires the sn_sec_cmn.admin providing more accessibility. 

SecOps Email also has:

- Duplication Rules that you can configure to Update SIR's, Create New SIR as Child or prevent further update/creation without having to create multiple rules for a specific Alert type or tool

- Easier to use (almost code-less) Field Transforms to specify what fields to put data in from the email 

- Ability to specify a Field Separator for emails that have multiple sets of data

- User Reported Phishing Rules to handle suspected phishing emails sent or forwarded from users in the form of an EML Attachment

I hope this clarifies everything a little better for you!

Thanks,

Jon W

[SanjivMeher]

Thanks. I understand the whole logic later. These are my findings.

The biggest disadvantage is I can't specify a contain in Email parser To field.For ex, if I want to check all email received by sirt@mycompany.com should be parsed, parser only works if To has only sirt@mycompany.com. But if there are more than just sirt@mycompany.com, it doesn't work. 

You also can't default a value using email parser. For ex, If I want to set the criticality to 2, I can't do that.

Also if you have parser setup, your inbound action doesn't work.