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!

[R34rvi3w]

Unfortunately, I can't reach out to them because I do not manage the instance or even manage ServiceNow. Instead I am the one responsible for using and getting value out of the app therefore I would be the SME to define acceptance. 

 I'm somewhat familiar with the way SNOW works and I do have a personal dev instance, however I could not install SecOps app and associated modules (perhaps because I've never done that before!). The app is new the people administrating the SNOW instance therefore I've chosen a DIY approach. While we did purchase pro services, it seems they never bothered to configure any actual enrichment (because it wasn't in scope) and here we are. 

The SIEM does send alerts to SNOW just fine, however we have certain data sources that are "high-fidelity", meaning their use   is limited for any aggregation or correlation. For example, some like Cofense Triage are very direct and are "User Reported Phishing" for where I'd like to use that data in that module. Others like Proofpoint are also very high level, if you clicked a phishing link for creds - it sends an email and generates and alert in the SIEM. In this case, sending to SNOW SecOps is good enough for actionable response and workflows, however at the moment - it just makes an email and an SIR - nothing more.

RF app is installed, however I'm not sure how to get it to enrich anything when every SIR has no observables... 

I'm not entirely sure what I should be "reviewing" with the new SNOW admin...

[Eric Feron]

Hello R34rvi3w,

what version are you running? London, Madrid or other?

This will help us to answer your question better and faster.

Thanks,

EF

[R34rvi3w]

Hello Eric,

 The version is London.

[andy_ojha · Accepted solution]

Hey there,

As Alex mentioned, the SecOps Security Incident Response product is built to handle this scenario.  Having an analyst manually sort through a body of text and creating observables is not the happy path.  

For the ProofPoint integration, are these coming through an email message to ServiceNow?

If so, you should check out the sample "Email Parser" configurations that are included with the SIR product (but turned off).  Navigate to (Security Operations -> Email Processing -> Email Parsing).

You will notice that each of the sample Email parsers contain one or more transforms to a table called [sn_ti_m2m_task_observable].

The Observables in ServiceNow can be associated to more than one SIR record -i.e. many-to-many (m2m).

When ProofPoint (or similar sources), are creating Security Incidents you can have Observables automatically created and associated to the SIR record:

• You can map the field transformations from the email message to fields such as
  - Source IP
  - Destination IP
  - Malware URL
  - Malware Hash
  - Referrer URL
• There is Business Rule called "Handle Deprecated Observable Fields", that takes these values and will establish Observable records to be associated to the SIR 
• As the name of the Business Rule calls out -> these are "deprecated" fields that are not quite used for Threat Intelligence / Observable purposes anymore - as an Observable can be associated to many SIR records
  
  
• The better approach would be to leverage an Email Parser config, similar to the ones included in the baseline SIR Product and map fields like Source IP Address to the [sn_ti_m2m_task_observable] table such that they are associated to the SIR record

This way your analysts can easily view the Observables associated to the SIR record without having to do this manually.

Also, if you have the Threat Intelligence plugin / license -> the Observables will be enriched through external sources you configure (such as VirusTotal, PhishTank, HaveIbeenPwned, ThreatCrowd, etc).  The analyst would be able to open the SIR record, see the associated Observables, see the count of similar SIR records also associated to the same Observable, and see the "Threat Lookup Results" for each Observable and Threat Intel source - simply just by opening the SIR record that was created without any additional manual work.