[New Integration] Cisco Secure Access

## Problem

Cisco Umbrella customers are being moved to Cisco Secure Access, and when they move, their Elastic
integration stops working properly. Elastic has no Secure Access integration. The Umbrella package
we do have will appear to keep working against a Secure Access tenant while silently dropping half
the data.

## Why now

**Cisco announced end-of-sale for Umbrella SIG and DNS on 1 September 2026.** The migration
path is Cisco Secure Access, Cisco's SSE platform.

| Milestone | Date |
|---|---|
| Announcement | 1 September 2026 |
| **End-of-sale** | **31 January 2027** |
| Last date to renew or add to a subscription | 31 January 2028 |
| End of support | 31 January 2029 |

Source: [Cisco Umbrella SIG and DNS EoS/EoL notice](https://www.cisco.com/c/en/us/products/collateral/security/security-cloud/umbrella-sig-dns-eol.html).

Two consequences for us:

1. **Migration demand starts now and peaks over the next 18 months.** Renewals stop being an option
after January 2028, so the bulk of the customer base moves between now and then. Every Elastic
customer running `cisco_umbrella` today is in that population.
2. **The window to be ready ahead of the wave is roughly the next two quarters.** Customers
migrating their SSE platform reassess their SIEM data pipeline at the same time. Being absent at
that moment is when accounts get lost, not when they get won.

## What breaks if we do nothing

Pointing the existing `cisco_umbrella` package at a Secure Access tenant does not fail loudly. It
fails quietly, which is worse:

- **Half the data never arrives.** Six of Cisco's twelve log types are unhandled entirely — file
events, remote access VPN, zero-trust network access, ZTA flow, ZTA enrollment and network
connectivity. That is the whole zero-trust and VPN-as-a-service story, which is precisely what
customers are moving to Secure Access *for*.
- **The log types that do work lose fields.** Web loses 22 of 57 columns, DLP 10 of 35, firewall 4
of 40. Nothing errors, so nobody notices until an investigation comes up short.
- **Cross-service investigation is impossible.** Cisco added a correlation identifier that links a
single flow across web, firewall and intrusion events. The Umbrella package drops it on every
record.

A customer in this state believes they have Secure Access visibility in Elastic. They do not.

## Goals

1. Ship a first-class `cisco_secure_access` integration covering **all twelve log types** Cisco
exports, so no customer needs to reach for the Umbrella package.
2. Make the migration from `cisco_umbrella` a documented, low-friction path with dashboards that
feel familiar.
3. Cover the zero-trust, VPN and intrusion telemetry that is unique to Secure Access — the reason
customers are moving in the first place.

## Non-goals

- **Changing or extending `cisco_umbrella`.** The schemas have diverged too far for one package to
serve both cleanly. Umbrella stays as-is for its remaining supported life.
- **Automating the tenant-side migration.** Moving a customer from Umbrella to Secure Access is
Cisco's process, not ours. We handle the telemetry once they have moved.
- **Real-time or sub-minute collection.** Cisco's export cadence is ten minutes. That is the
platform's floor, and it is appropriate for the audit and hunting use cases this serves.

## Scope

**Collection method: AWS S3 log export.** This is the path Cisco built for SIEM ingestion and the
one it points customers at. Cisco's own documentation rules out the alternative: *"The Reporting API
does not support bulk data retrieval. If you must export all your data or large data collections,
you can enable logging to Amazon S3."* Both bucket models are supported — the Cisco-managed bucket
(no AWS account needed on the customer side) and a customer-owned bucket.

**Twelve data streams**, one per Cisco log type:

| Data stream | What it covers |
|---|---|
| `dns` | DNS queries and verdicts — highest volume, and the continuity story for Umbrella customers |
| `web` | Full HTTP transactions: URL, method, status, file hashes, malware disposition, TLS, and generative-AI application usage |
| `firewall` | Cloud firewall flow records with byte and packet counts |
| `intrusion` | IPS signature detections with severity, attack classification and CVEs |
| `dlp` | Data-loss detections, including email scanning |
| `audit` | Administrative changes with before/after values |
| `ztna` | Zero-trust access decisions with endpoint posture — the richest security content in the product |
| `file_event` | File dispositions, threat names, archive contents |
| `ravpn` | Remote access VPN session lifecycle |
| `ztna_flow` | Byte-level zero-trust flow records |
| `ztna_enrollment` | Device enrollment lifecycle |
| `network_tunnel` | Tunnel and BGP connectivity diagnostics |

Dashboards and setup documentation ship alongside the data streams, not after them. Documentation
must cover the Umbrella-to-Secure-Access migration path, the per-stream licence tier requirements,
and Cisco's operational constraints on log delivery.

## Future enhancements

Both are researched and understood, and neither should gate the migration-driven work above.

- **Asset and identity inventory streams.** Cisco's API exposes endpoint inventory, ZTNA private
resources, the connector fleet and API credential inventory as point-in-time snapshots rather
than events. These would populate the entity store and add asset context to the S3 telemetry —
endpoint protection posture in particular is strong material. The endpoint inventory alone
surfaces devices in states like *unprotected*, *uninstalled* or *misconfigured*. Schema and
entity-mapping analysis is already complete.
- **Push Security Events via webhook.** Cisco's only low-latency path, delivering security
detections in near real time rather than on the ten-minute S3 cadence. Constrained: security
detections only rather than full traffic, capped at three integrations per organisation, and
Cisco does not document its retry or delivery guarantees. Worth revisiting once the S3 streams
are established and we understand whether customers are asking for the latency.

## Success criteria

- All twelve log types ingested with complete field coverage against a live tenant — not just
against documentation.
- A published migration path from `cisco_umbrella`, including what changes in field names and
dashboards.
- No Secure Access customer is advised to use the Umbrella package.
- Adoption tracked among the existing `cisco_umbrella` install base as they migrate. Target to be
agreed with the field once we can see the migration curve.

## Prerequisite

**A Cisco Secure Access test tenant** with S3 export enabled, on the Advantage package and the
current log format version. This is a hard blocker, not a detail. Cisco's published field
documentation contains errors we have already identified, and two log types cannot be implemented
correctly from documentation alone. Nothing meaningful starts until this exists, and it should be
secured before any delivery date is committed.

---

**Sources:** [Cisco Umbrella SIG and DNS end-of-sale and end-of-life notice](https://www.cisco.com/c/en/us/products/collateral/security/security-cloud/umbrella-sig-dns-eol.html) · [Cisco Security Cloud EoS/EoL notices](https://www.cisco.com/c/en/us/products/security/security-cloud/eos-eol-notice-listing.html) · [Upgrade from Umbrella to Secure Access](https://umbrella.cisco.com/umbrella-to-secure-access-migration)

Start by securing the required Cisco Secure Access test tenant with Advantage and current S3 log exports, then compare its live records with the existing cisco_umbrella package. Define the twelve data streams, complete field coverage, dashboards, and migration documentation, including licence and delivery constraints. Done means all twelve streams ingest correctly against the live tenant and the migration path is published.

Written by the indexing model from the issue text.