Cisco Shows How Splunk Can Turn Network Alarms Into Risk-Based Security Evidence

Detection engineering is rarely just about writing a search query.

Security teams also need to understand the underlying data, validate detection logic, normalize fields, decide how findings should appear to analysts, assign appropriate risk, and provide a practical path for investigation.

Cisco recently detailed how it used Splunk Detection Editor (Alpha) to build a risk-based detection around Cisco Secure Network Analytics (SNA) during Black Hat USA 2026.

The workflow takes active SNA alarms, associates them with the source systems responsible for the observed activity, and adds that information to the Splunk Enterprise Security risk index.

According to Cisco, the process brought SPL development, sample-data testing, field normalization, risk configuration, investigation drilldowns, and scheduling into a more unified workflow.

Why risk-based alerting matters

Traditional detections often generate an alert whenever their search conditions are met.

That approach can work well for high-confidence activity, but it can also leave analysts with numerous isolated alerts that need to be reviewed individually.

Risk-based alerting takes a different approach.

Instead of treating every observation as a separate incident, a detection can generate a risk event associated with an entity, such as a system or user. Multiple observations involving the same entity can then contribute to a broader risk picture.

Splunk Enterprise Security stores these observations in its risk index. Risk incident rules can correlate activity involving the same entity and surface a risk notable when the accumulated activity meets the configured conditions for investigation.

For Cisco's SNA use case, this means an individual network alarm does not necessarily have to become another standalone analyst alert.

Instead, it can become another piece of evidence.

For example, an SNA alarm associated with a source system can contribute to that system's risk history. If the same system also generates relevant firewall, DNS, or other security detections, those observations can be considered together.

The important shift is from isolated alerts to connected risk evidence.

Splunk Detection Editor brings the workflow together

Cisco's experience focused on the Splunk Detection Editor (Alpha) as a workspace for developing the detection.

The editor provides an environment where the author can work on SPL while also configuring other parts of the detection.

According to Cisco, the SPL editor provides syntax highlighting, field completion, formatting, and potential improvement suggestions. Search results appear directly below the editor, allowing the author to change the search and immediately review how the returned events change.

The surrounding configuration areas cover elements such as:

• Detection scheduling

• Conditions

• Response actions

• Risk configuration

• References

• Investigation drilldowns

This matters because a detection is more than its underlying query.

A technically valid search is only one part of the process. The resulting event also needs to contain useful information, map to the right entity, contribute appropriate risk, and support the analyst's next step.

Cisco's approach was therefore to develop the search and the analyst workflow together.

Testing the detection against sample data

One of the capabilities Cisco highlighted was the ability to associate sample events with the detection.

A search can be syntactically correct and still produce unexpected results.

For example, a field may not exist consistently across events. A destination value could represent multiple systems. A field referenced in a risk message might not actually be returned by the completed search.

Cisco used representative SNA events to test these conditions.

The testing helped confirm that:

• The source IP was populated consistently

• Duplicate alarm IDs were removed

• The alarm description was available

• Aggregate destination values were handled correctly

• Fields required by the risk response were present

• The final results contained useful analyst context

This created a shorter feedback loop between modifying the SPL and seeing how the detection behaved with actual data.

It also helped address a common detection-engineering challenge: data does not always arrive in exactly the same structure.

Normalizing network data with SPL

The detection itself used SPL to search for active SNA alarms, remove duplicate alarm IDs, and normalize fields that could appear under different names.

Cisco provided the following example:

| eval src=coalesce(src_ip, source_ip, src)
| eval dest=coalesce(dest_ip, target_ip, dest)
| eval description=coalesce(alarm_type_description, description)

The purpose was to provide consistent src, dest, and description fields regardless of which underlying SNA field was populated.

This normalization becomes particularly important when the resulting fields are used elsewhere in the detection.

A consistent source field, for example, can help ensure that the same entity is represented consistently when risk events are generated.

The editor's field completion and syntax validation supported the development process, while the integrated results made it possible to check whether the normalized fields were actually populated as expected.

Using CIM and finding-field references

Cisco also used the Detection Editor's reference tools while designing the detection.

The Common Information Model (CIM) Reference allows detection authors to browse data models, datasets, and fields.

Cisco used it when determining how SNA-specific fields could be normalized into names that were more consistent with other Splunk security data.

The Finding Fields Reference addresses a different part of the workflow.

It helps determine which fields should be available when an analyst views a finding or investigates the detection.

Together, these references shift the focus from a basic question - Does the search return results? - to a more useful one:

Will those results make sense to an analyst investigating the activity?

Turning the source IP into a risk object

One of the most important configuration choices was identifying the entity that should receive the risk event.

For this detection, Cisco selected the source IP.

The configuration described in the source was:

When the detection runs, the source IP receives a risk event with a score of 10.

Cisco emphasized that the score should not be interpreted as a declaration that the system is compromised. Instead, it represents one piece of evidence contributing to the system's broader risk picture.

The choice also demonstrates why field normalization matters.

If different detections use inconsistent representations of the same entity, correlating those events becomes more difficult. Using a consistent risk object gives the security platform a common entity around which observations can be associated.

Cisco said the initial score of 10 was used for observation and tuning. The source also notes that a future version could vary the score according to factors such as SNA alarm severity, category, confidence, or asset importance.

Those possible changes are described by Cisco as future tuning considerations rather than capabilities implemented in the reported detection.

Why the destination was not always treated as a threat object

The destination IP provided useful context, but Cisco did not treat every destination as a threat object.

The reason was data precision.

Some SNA alarms can refer to a single target, while others describe activity involving multiple destination IP addresses.

Assigning one destination as the threat object when the original alarm represents multiple destinations could create an inaccurate impression of what the event actually identified.

Cisco therefore retained the destination as a threat object only when the alarm did not indicate multiple targets.

When an alarm represented an aggregate destination, the threat object was left empty while the destination information remained available as supporting context.

This is an important detection-engineering principle:

Security data should not be presented with more precision than the underlying telemetry supports.

Making the risk event understandable to analysts

Risk events still need context.

Cisco configured the following risk message:

Cisco SNA $signature$ alarm associated with source $src$: $description$

The tokens are populated with values from the matching event when the detection runs.

This gives the analyst a concise description of:

• The Cisco SNA signature

• The source system involved

• The alarm description

Cisco also used sample data to validate that the required token fields were actually available.

The Detection Editor could warn when it could not validate a token, prompting another review of the search output before the detection was enabled.

That validation step is significant because an otherwise functional detection can still provide a poor analyst experience if its resulting risk event lacks the context required to understand it.

Connecting detection to investigation

Generating a risk event is only part of the workflow.

The analyst also needs a way to understand what happened around the event.

Cisco created an investigation drilldown called:

Recent Corelight, FTD, DNS, and Palo Logs for $risk_object$

The drilldown uses the source IP as its pivot and searches related network activity across:

• Cisco Secure Network Analytics

• Corelight

• Cisco Secure Firewall

• Palo Alto Networks

• DNS data

The returned information can include connection direction, ports, protocols, firewall actions, applications, DNS queries, URLs, signatures, network zones, and bytes transferred.

This creates a direct transition from detection to investigation.

Instead of receiving a risk event and then manually constructing multiple searches, the analyst can use the configured drilldown to examine supporting network activity around the same source.

Scheduling and enabling the detection

After validating the search and response configuration, Cisco scheduled and enabled the detection.

When a qualifying SNA alarm is identified, the detection creates a risk event associated with the source system.

Those events can then accumulate alongside observations generated by other detections involving the same entity.

A risk incident rule can subsequently surface the combined activity when it meets the conditions for investigation.

This distinction is central to the workflow.

The goal is not simply to turn every SNA alarm into another analyst alert.

Instead, the alarm becomes risk evidence that can contribute to a larger security story.

What the Cisco example shows about modern detection engineering

Cisco's example highlights a broader industry shift toward treating detection engineering as an end-to-end workflow rather than a search-writing exercise.

A detection needs several components to work together:

1. Reliable telemetry
   The underlying data needs to contain the information required by the detection.

2. Normalized fields
   Different field representations need to be handled consistently.

3. An identifiable risk object
   The detection needs to associate the activity with a meaningful entity.

4. Appropriate risk scoring
   The score should represent evidence rather than automatically imply compromise.

5. Analyst-readable context
   Risk events need enough information to explain why they were generated.

6. An investigation path
   Analysts need a practical way to examine related activity.

7. Validation before deployment
   Sample data and actual event results remain important even when the SPL is syntactically valid.

The Cisco example brings all of these elements together around SNA data and Splunk Enterprise Security.

The importance of testing an Alpha detection workflow

Cisco also noted an important limitation of the Detection Editor experience.

Because the Detection Editor is identified as an Alpha capability, validation warnings could still require additional review.

Cisco specifically noted that token validation could be conservative even when the required fields were present in the final results.

As a result, testing the detection against actual events remained important before enabling it.

This is particularly relevant for detection engineering because a successful deployment depends on more than whether a query executes.

The fields, risk object, message tokens, threat-object logic, and investigation workflow all need to behave as expected.

Why this approach matters for security teams

For security operations teams, the most notable aspect of the example is the connection between network telemetry, risk, and investigation.

A network detection can generate valuable evidence without necessarily requiring a separate analyst interruption for every individual event.

When multiple observations are associated with the same entity, the resulting context can provide a more useful basis for deciding whether an investigation is warranted.

For enterprises, this could mean designing detections around entities and investigative context rather than treating every security signal as an isolated alert.

The announcement highlights a broader industry shift toward more context-driven security operations, where detection engineering considers not only whether suspicious activity can be identified, but also how that activity should contribute to an analyst's investigation.

Final takeaway

Cisco's SNA example demonstrates how a network alarm can be connected to a broader risk-based detection workflow in Splunk Enterprise Security.

The process starts with active SNA alarms and moves through SPL development, field normalization, sample-data testing, CIM and finding-field references, risk configuration, analyst-facing messaging, investigation drilldowns, and scheduling.

The resulting detection does more than report that an alarm occurred.

It associates the activity with a source system, adds a risk event, preserves relevant context, and provides analysts with a path into supporting network activity.

The Detection Editor (Alpha) was particularly useful because these tasks could be developed within a more unified workflow.

The larger lesson is straightforward: effective detection engineering is not only about finding suspicious activity. It is also about deciding which entity the activity belongs to, how much risk it represents, what context the analyst receives, and what happens next.

For Cisco's Black Hat USA 2026 SNA use case, those pieces were brought together into a single risk-based detection workflow.