Getting acceptable value out of SecOps Incident Observables with automatic creation

[R34rvi3w]

Hello all,

 I have recently had an instance of Security Operations installed in our environment that we are struggling to get value out of. The current situation has us getting an incident created, then once its created - the analyst has to take the artifacts (i.e. Observables) which are blatantly in the description or short description and then manually add them as an IOC or observable. This is NOT what we expected from any SOAR solution, because the others can take an incident, take any observables given them by the incident and enrich those against an external CTI solution. We were told Recorded Future worked with the solution, now we are doing a POC and after speaking with their leadership - it turns out this is not entirely true. There is an app, but it doesn't return risk scores or do any of what it can do from other platforms. 

 If one has the observable, such as a URL, IP, hash value - we should be able to immediately parse those from specific field mappings into the IOC observables. Additionally, we should be able to automate the workflow to perform the lookup. In my current instance, this does not occur but I speculate it should. Does anyone else have automatic observables from incident data being added and enriched automatically so analysts do not spend time manually entering data that is already in the incident (or defanging it from an email) for TI use?

Thank you!

[Alex Cox]

Hey there,

The Security Incident and Threat Intel apps can indeed do everything you're mentioning here. A lot of this comes down to what info is placed where, and what rules are enabled / configured.

There a ton of ways this can be done, so specific solutions require a little more detail about the incoming information.  Maybe we can take a look at one of your use cases? 

For example you mentioned that there is data coming into a description field - can you share more info about the source of that data, and how the integration was setup? 

Usually our integrations and implementations push/pull data directly into the observable fields to prevent the need for manual entry where possible, just as you're expecting.

[R34rvi3w]

Hello Alex,

 First to all, I want to thank all of you for replying to my messages. I can't say how surprised I am by how alive the community is! So with Proofpoint alerts, they come right into SNOW (forget the SIEM, it send its own alerts). They also go into the SIEM but are very high-fidelity and actionable. I have the user, their IP, their User Agent from the browser and the URL they clicked. The subject is generic like "URL Defense Alert" but the content is pretty good.

 The moment, I have no workflows, no observables added for each of the SIR's that get generated.. and yes, someone paid for pro services and they won't be paying again. I personally didn't call it complete but it's what people these days refer to as "agile" project development...

 I will be having a meeting with the new admin of the platform tomorrow but I need some action items for him to work on and I'll need to have an understanding of what needs to happen for success. This community is awesome, thank you!

[Alex Cox]

Hi R34rvi3w,

I'm glad to see the community can help!

In "ServiceNow speak" - you might want either a Business Rule or a Workflow/Flow to create custom triggers for enrichment, where the integration or implementation is not providing what you'd like.

For example: business rules can watch any type of record and any combination of fields on them, and create a trigger. That trigger can do basically anything (it can run a script of your design).

Let's say there is an IP in your Description or Short Description fields that you want to pull out and load into threat intel. It's more ideal to load threat intel data directly into fields like "source_ip", "destination_ip", "malware_hash" etc,  but sometimes this isn't possible.

In this case you could make a business rule that:

• Fires when "Description" (or another field) is changed on a Security Incident
• Runs a script that:
• • Parses that field for an IP with regex
  • If it finds it,  adds that IP to the source_ip  or destination_ip field
  • Saves the change
• Once that field is filled in - threat intel snags the value in there, adds it as observable, and triggers the Threat Lookup within I think 30 seconds or a minute.

Workflows / Flows are a lot more powerful and visual - you can trigger them off of many of the same things,  but they provide a flow chart style interface to managing the logic.

[Adam Horwitz]

Hi R34rvi3w,

Our Security Incident Response solution does work with Recorded Future, and many other threat intelligence solutions. Typically the observables are ingested through a SIEM alert at time of security incident creation. The integration maps the observables to the appropriate ServiceNow fields fields for observables, host/CI, etc. You can of course add observables later, and threat intelligence lookup will run automatically but the intent is that this has already happened by the time the analyst first sets eyes on the incident. The description field is not parsed for IOCs because that's not what the field is used for.

You didn't mention the SIEM you're using. There are pre-built integrations for Splunk QRadar, ArcSight, LogRhythm, etc, in store.servicenow.com. These are specific integrations for "Security Operations" not ITSM. There's also a pre-built integration for Recorded Future at https://store.servicenow.com/sn_appstore_store.do#!/store/application/497b16314f64b6009c4031124210c7.... Are you using any of these?

We recommend that customers use a qualified/experienced implementation partner or our professional services for implementation. We are not a point solution. There is more capability with our solutions, and it is therefore a little more involved to initially implement. Once implemented, it is easier to extend the solution with additional integrations.

I recommend reaching out to your ServiceNow account team.