Skip to main content
Lantern Home

 

Splunk Lantern

Integrating Cisco Secure Access with Splunk for essential SOC operations

  1. Last updated
  2. Save as PDF

Any software integration with Splunk requires four basic components:

  • Access: Getting data in
  • Store: Storing the data
  • Present: Presenting the data in meaningful ways
  • Invoke: Taking action based on the data

While that list sounds straightforward, implementation is often not. Those steps can occur in any order and any combination. For example, in security monitoring, you might need to access some data and then immediately present it, without storage. When storage is required, how you implement it influences license costs and software performance. 

That's why add-ons and apps are so useful. They take a lot of the configuration work out of your hands and do a better job at it than existing tools can. So if you plan to integrate Cisco Secure Access with the Splunk platform, this article explains how to use the supported add-on and app to simplify key use cases.

How to use Splunk software for this use case

Use case 1: I want every single event

For some organizations, Secure Access can produce 20-30 billion events, or 6 to 7 terabytes of indexed data, per day. Most companies don't need this, but if you are doing advanced correlation you might. If your Secure Access data is going to a Cisco-managed S3 bucket, some tools might have trouble accessing that bucket. The add-on resolves this issue by going to S3, bringing in event logs, and inserting them directly into the Splunk index of choice.

Best practices

  • Use S3 tools, like the AWS CLI, to determine how much data is in S3 and how much you are willing to bring into the Splunk platform.
  • Auto-recycle credentials. The Cisco-managed bucket invalidates credentials after 90 days, but you can configure the add-on to recycle them automatically via API.
  • Select all event types when you configure the add-on and select automatic discovery. Doing so prevents the need to map new log types manually. They are added, and the fields are extracted automatically and mapped to the Common Information Model.
  • Use your configuration date as the start date for bringing in logs. If you backdate, you'll have way too much data.

Use case 2: Push security events to any destination with an HTTP listener

This Secure Access feature uses webhooks to send security events and alert notifications to a location of your choice for faster notification. This mechanism gets actionable information to the Splunk platform quickly.

Best practices

  • Select all security events when configuring the push in Secure Access. This ensures that any new sources are automatically pushed as well. 
  • Separate webhooks for events and alerts to control the influx of data. You will need to configure two tokens in the add-on. 
  • Select the Splunk-native format for your events when configuring the Push Security Events integration in Secure Access. If you are format-agnostic, there will be a high cost of regex transformations on the Splunk side, which extends processing time. 

The following video shows the end-to-end configuration process.

Use case 3: Visualizations

The Cisco Secure Access App for Splunk uses public APIs to get data for visualization, which is faster than creating visualizations off the indexed data. While the speed the app provides is great, some stakeholders will want the data behind the visualizations. When you have both the Secure Access add-on and app, the data is readily available. You can drill down into the SPL from the visualizations to build new visualizations as needed.

Best practices

  • Define the time zone for each user who is logged in to the Splunk platform so that timestamps appear in local time. Otherwise, all events appear in UTC. 
  • Know which region your data is stored in. If you are in the United States and your data is in the United States but your Splunk server is in Europe, you might have trouble accessing data if the app is configured to only allow auto-detect of regions.
  • Monitor API usage in the app. The app uses a lot of APIs, and it also includes a set of APIs that show how you are using the APIs. The telemetry is exposed so you can see how API requests to the Splunk platform are performing. Are they succeeding or failing? Are you hitting rate limits? Are you using the APIs correctly?

For more best practices on app and API management, watch the full talk, Cloud Security APIs and Splunk: Best Practices In Practice.

Use case 4: Enrich and report

The investigate API in the app brings back enrichment data regarding different types of destinations. This includes risk scores, traffic seen, known threats and risks, whois data, associated malware samples from the domain, related domains, and more. The app also gives you the ability to take action on a related domain and apply enforcement while investigating:

  1. Right-click a related domain from the related domains panel and select a destination list to send it to.
  2. This triggers an API call that adds the destination to a destination list, which can then be attached to a policy-access rule or a DLP rule. 

You can also automate this process by using alert actions in the Splunk platform. 

Best practices

  • Define a separate index if you use alert actions to write enrichment information to reports. You can fill your index very quickly.
  • Start slow. If you get data from multiple threat intelligence providers, you might need to narrow your scope so that enforcement is only applied when needed and reports do not become too large to be effective.
  • Keep your investigate queries narrow so you don't hit rate limits. You might need to increase your purchase tier if you continuously hit the limit.

Additional resources

Now that you have an idea of how the Cisco Secure Access Add-on and App can help, watch the full talk from Cisco Live EMEA 2026, Cloud Security APIs and Splunk: Best Practices In Practice. In the talk, you'll see product walkthroughs and demos for each of the use cases covered in this article. 

In addition, the following resources might be of interest to you:

  • Written by Yaron Caspy
  • Engineering Product Manager at Cisco