Integrating Cisco Secure Network Analytics (SNA) with Enterprise Security and RBA

Prerequisites

• Splunk Enterprise Security 7.3.2 or later
• Active use of Cisco Secure Network Analytics for network/flow data security analysis
• SNA configured to send Converged Security Alerts to the Splunk platform, including MITRE ATT&CK context

Getting started

The following diagram illustrates the intended data flow after integration. Cisco SNA performs the primary analytics on network flow data, sending results to the Splunk platform and Splunk Enterprise Security for further correlation. Analysts can also pivot back into Cisco SNA from alerts displayed in the Splunk platform or Splunk Enterprise Security through a custom workflow action (not covered in this article).

Configure SNA to send Converged Security Alerts to the Splunk platform

SNA Converged Security Alerts can be forwarded to the Splunk platform via syslog, REST, or webhook. The recommended method is using a webhook to integrate with the Splunk platform through REST, sending HTTP POST payloads with alarm data, using the configured webhook URL (in SNA), to the HTTP Event Collector (HEC) configured in the Splunk platform.

1. Configure an HTTP Event Collector (HEC):
   1. Create a new HEC with default settings, naming it something like "SNA Splunk."
   2. Adjust global settings if needed, although you can likely leave these as default. SSL in Splunk Web is optional.
2. Access the Splunk Services collector page and copy the certificate.
3. In SNA, go to Central Management > Trust Store and add the certificate.
4. In Response Management, create a new webhook action to point to the HTTP Event Collector that you previously configured.
5. Attach the webhook action to the desired rule.

When configured, search the Splunk platform and validate that you receive the necessary alerts. A sample alert is shown below:

Define SPL to capture SNA alerts in correlation searches and detections

Cisco SNA generates hundreds of unique detections based on flow data it is analyzing in real time. These detections come in two different types of outputs: security alarms, and Converged Security Alerts. Combined, these outputs can generate hundreds or thousands of unique detections per day. For that reason, it is not practical to create "like for like" detections in Splunk Enterprise Security, as that would likely result in unnecessarily high SVC usage (leading to increased costs) and potential performance issues.

Instead, it is recommended to use a "one-to-many" approach, where you'll create one or two correlation searches to capture all Cisco SNA Converged Security Alerts to generate the applicable risk events for this type of output. Below are descriptions of security alarms and Converged Security Alerts in Cisco SNA. For the purposes of risk-based alerting, we are only going to focus on the Converged Security Alerts, as these already contain the necessary MITRE context to integrate seamlessly with RBA.

To detect and create risk events for SNA Converged Security Alerts, while capturing MITRE context, run the following search.

index=* sourcetype=httpevent alert_type=*
| eval orig_rule="Secure Network Analytics"+" - "+alert_type
| rename device_ips AS src alert_type AS signature mitre_technique_id AS annotations.mitre_attack
| stats count BY host src signature orig_rule alert_description alert_next_steps annotations.mitre_attack time_first_observed time_last_observed time_resolved

Create risk events for all SNA Converged Security Alerts

To create risk events based on the search above, you'll need to embed risk attribution into SPL (allowing dynamic handling of multiple SNA alert types within a single correlation search) rather than using static risk annotations. Because you're building a one-to-many type of detection, and there are going to be several different SNA alerts and MITRE ATT&CK techniques that will need to be assigned at search time, this approach helps you avoid using the dropdown box in the correlation search editor. That box can only assign a static value that would apply to all of the unique signatures that are passed through SNA's converged security analytics.

1. In the Correlation Search settings, name your search, assign app context, create a description, and define the SPL.

   

2. Leave the Annotations section empty, as the MITRE technique will be added through the configured SPL.

   

3. Configure the time range, trigger conditions, and throttling as you normally would. If you are only sending these to the risk index, you will need to configure the risk analysis adaptive response action by using the alert_description variable as the risk message and assigning a standard risk score to apply to the risk object field (in this case, src). You can always configure custom risk factors to adjust risk based on the specifics of the SNA alert.

   

Update risk analysis data model

Update the risk analysis data model to include custom fields like orig_rule. Disable acceleration, add the auto-extracted field, and then re-enable acceleration for proper indexing. The screenshot below shows you what the data model should look like after you've added this field.

Create notables for low likelihood/high impact SNA alerts (optional)

For specific low likelihood and high impact alerts, you can optionally configure notables using the standard method with notable adaptive response actions alongside risk analysis.

Customize out-of-the-box (OOTB) risk notables to account for SNA risk rules

There are two OOTB risk notables included with Splunk Enterprise Security:

• ATT&CK Tactic Threshold Exceeded for Object Over Previous 7 Days
• Risk Threshold Exceeded for Object Over Previous 24 Hours.

You'll need to modify the SPL below to properly account for the SNA focused risk rules.

Validate SNA alerts are represented in risk notables

Review the notable index and the Incident Review section of Splunk Enterprise Security. Ensure that the notables are being generated as expected, and the orig_source field includes the original alert description from the SNA alerts (where applicable).

Verify

Verify the following components to ensure the end-to-end set up has been completed correctly:

1. Risk rule(s) created to account for Cisco SNA converged security alerts.
2. Risk analysis data model updated to account for custom fields.
3. Risk notables customized to account for SNA focused risk rules.
4. Risk notables generating as expected.
5. Risk notables contain SNA alert descriptions/signatures in the orig_source field.

Additional resources

Splunk Professional Services can provide hands-on Cisco SNA guidance for you and your team. Click here to learn more about working with Professional Services.