Strata Logging Service is Palo Alto Networks’ cloud-delivered log storage and aggregation platform for network and security products. It is the current name for Cortex Data Lake. The service ingests logs from Prisma Access, on-premises and virtual NGFWs, Cloud NGFW, and supported Cortex/other Palo Alto Networks services, stores them in a scalable cloud infrastructure, makes them searchable through Strata Cloud Manager or the standalone application, and can forward logs to external systems for long-term retention, SOC, or audit use.
Within Palo Alto Security Operations, Strata Logging Service is the evidence plane behind firewall, Prisma Access, and cloud-delivered network security operations. It should be sized and governed around incident-retention needs, forwarding integrations, region requirements, and log-type value—not treated as invisible vendor storage.
The service formerly known as Cortex Data Lake should be renamed in internal runbooks, diagrams, SIEM integrations, and procurement records to avoid confusion during support and migration work.
Centralized cloud logging removes local collector scaling work
Strata Logging Service provides a managed, fault-tolerant log infrastructure so teams do not need to size and maintain enough local Log Collectors for every growth event.
Existing on-premises collectors can still complement the cloud service in hybrid architectures.
Choose the architecture from retention, sovereignty, connectivity, and incident-response requirements rather than assuming local or cloud logging is always superior.
Onboarding should be measured by device and tenant coverage
Inventory every firewall, Prisma Access deployment, Cloud NGFW instance, and tenant expected to send logs.
Compare product/device inventory with Strata Logging Service inventory and last-log timestamps.
A central log platform can appear healthy while one newly created firewall or tenant never completed onboarding.
Storage quota should be allocated by log type and value
Current Strata Logging Service documentation supports allocating storage quota and retention by log type.
Threat, traffic, URL, decryption, system, configuration, and other log classes have different investigation value and volume.
Use expected daily ingest and business/legal retention needs to allocate capacity rather than splitting storage evenly.
Retention days are a function of incoming rate and allocated storage
Storage status shows available space and the number of days logs are retained based on incoming volume and quota.
A traffic spike or new onboarding can reduce effective retention if storage allocation does not change.
Monitor retention trend as a security metric; “30-day policy” is meaningless if actual ingest growth has silently reduced searchable history to 12 days.
Log Viewer and Explore support operational investigation
Strata Cloud Manager Log Viewer and the Strata Logging Service Explore interface provide search/filter/export over stored data.
Current 2026 query enhancements include ILIKE, NOT ILIKE, and NOT LIKE operators for more flexible pattern matching.
Security teams should standardize common hunt filters and teach analysts which fields are product-specific versus normalized across data sources.
External forwarding extends the retention and analytics model
Current service documentation supports forwarding logs to external systems such as syslog and HTTPS destinations, with additional product-specific forwarding options.
Use external forwarding when a SIEM, long-term archive, compliance repository, or independent forensic store is required.
Monitor forwarding health so the existence of a configured profile is not mistaken for proof that every log actually reached the downstream SOC.
Regional placement matters for data governance
Strata Logging Service operates in supported regions and product deployments must meet compatibility and region requirements.
Document where logs are stored, which tenants/devices send there, and whether the region matches internal policy and regulatory obligations.
Region changes should be treated as a data-migration and retention decision, not merely a console setting.
RBAC should separate log use from platform administration
Analysts need search and export capabilities; platform admins may need onboarding, quota, and forwarding configuration.
Use least-privilege roles so ordinary SOC users cannot alter retention, offboard devices, or disable forwarding.
Audit administrative changes because reducing quota or detaching a device can erase future evidence without generating an obvious detection alert.
Logging continuity should be monitored as a detection dependency
Alert on devices that stop sending logs, abrupt event-rate changes, forwarding failures, storage pressure, and tenant association changes.
Correlate logging health with Log Retention for Investigations so the platform’s technical retention supports the incident plan.
No-alert periods are suspicious when expected high-volume sources suddenly go silent.
Use cloud logging as evidence, not as the only copy by default
For high-risk or regulated environments, consider a second independent archive or SIEM forwarding path that preserves evidence outside the same operational control plane.
Define which store is authoritative for hot investigation versus long-term audit.
Test restoration/search from the external archive so retention does not depend entirely on one service or user interface.
Strata Logging Service succeeds when capacity and evidence requirements stay aligned
The mature design inventories every sender, monitors ingest and actual retention, allocates storage by log value, controls roles, forwards critical evidence, tests searches/exports, and tracks region requirements.
Managed logging removes infrastructure burden, but security teams still own the question of whether enough trustworthy history exists when an incident begins.
Log-type allocation should be reviewed after enabling new security subscriptions or features. Turning on additional threat, decryption, URL, DNS, or cloud telemetry can increase daily ingest significantly and shorten effective retention. Capacity planning should model security-feature growth, not only firewall count, because richer inspection can produce more logs per session.
Forwarding architecture should define delivery guarantees and failure queues. External HTTPS/syslog collectors can be unavailable or rate-limited; operations need to know whether Strata Logging Service retries, buffers, or drops after a condition and how to detect that state. Test downstream SIEM maintenance windows so the forwarding path’s real behavior is understood.
Search performance should be part of incident readiness. Very broad queries over long retention can be slow or expensive in analyst time. Standardize investigation pivots—user, source/destination IP, session, URL, rule, device, threat ID—and use indexed/filtered workflows before exporting large datasets blindly.
Export controls deserve governance because logs can contain usernames, internal IPs, URLs, file names, threat details, and sometimes sensitive application metadata. Limit bulk export permissions, audit who retrieves large datasets, and define approved destinations for forensic copies or data-science use.
Logging configuration on the source device still matters. Strata Logging Service cannot store an event a firewall or Prisma Access policy never generated. Review log-at-session-start/end choices, threat/URL/decryption logging, policy log settings, and device clock so the cloud service receives the evidence the SOC expects.
Retention policy should be tied to incident-dwell assumptions and regulatory needs. Different regions or business units may require different historical windows. Where one SLS allocation cannot satisfy all needs economically, forward selected log classes to a long-term archive rather than reducing hot retention for the entire estate.
Platform health should be monitored during network outages. A branch or firewall can buffer logs locally and upload later depending on product behavior and capacity. Distinguish event time from ingest time during investigation so a delayed upload does not make an old attack look newly active.
Multitenant and service-provider environments need clear tenant boundaries. Verify device association, role scope, forwarding destinations, storage allocation, and report access per tenant. A logging platform mistake can expose one customer’s traffic metadata to another even when the firewalls themselves are correctly segmented.
Strata Logging Service migrations from older Cortex Data Lake terminology should include API/integration checks. Dashboards, scripts, support procedures, and SIEM documentation may still reference CDL names or endpoints. Inventory these dependencies so a naming/product transition does not cause operational confusion during an incident.
Logging-service changes should be tested against SOC detections. If a device moves region, log format changes, or forwarding is reconfigured, confirm SIEM parsers, correlation rules, and retention dashboards still work. Logging is an upstream dependency of many controls, so changes should include downstream detection validation.
Cost and retention planning should include compression/normalization behavior only where documented by the service; security teams should budget from measured daily ingest rather than guessing from raw firewall byte volume. Keep a quarterly forecast for new sites, features, and traffic growth so retention does not erode between renewals.
Log forwarding destinations need schema/version monitoring. A downstream SIEM parser can break after source product fields evolve even though Strata Logging Service forwarding remains healthy. Validate sample events after PAN-OS, Prisma Access, or logging-service upgrades.
Administrative break-glass access should be documented for logging incidents. If normal SSO or tenant administration is unavailable, designated responders need a secure way to verify ingest and export critical evidence without granting permanent broad admin access.
Retention reduction should require approval from incident-response and compliance owners. Storage teams should not shorten history solely to solve a capacity alert; first evaluate quota increase, selective forwarding, or lower-value log classes so critical forensic history is preserved.
Retention dashboards should be reviewed before major incident-response exercises. Confirm that the log classes the exercise expects—traffic, threat, URL, system, configuration, authentication—actually remain searchable for the required window and can be exported or forwarded without privileged improvisation.
Log search standards should include saved examples for common investigations such as user-to-destination, policy hit, threat ID, URL, device change, and decryption failure. Reusable query patterns reduce response time and make investigations more consistent across analysts.
