Strata Logging Service is the centralized log store behind many Palo Alto Networks operational workflows. For a network analyst, its value is not simply retention. It provides a common place to search firewall and Prisma Access activity, correlate policy behavior, test troubleshooting hypotheses, and export evidence without treating every individual firewall as an isolated data source.
Palo Alto Networks renamed Cortex Data Lake to Strata Logging Service, and current documentation describes it as a cloud-delivered service that can ingest and store logs from products such as NGFWs and Prisma Access. The current Network Security Analyst certification explicitly includes Strata Logging Service as part of the analyst’s centralized-management and troubleshooting scope.
Start every investigation with a narrow question
Log systems become slow and confusing when the analyst begins with “show me everything.” Start with the question you need to answer: Which rule denied this connection? Which users reached this application? Did traffic from this source change after a policy push? Is a threat signature causing resets? Are connections arriving from a path the routing design did not predict?
Then choose the log type and time range that can answer the question. Traffic logs are useful for connection and rule behavior. Threat logs add security-inspection context. Audit logs help explain configuration or administrative activity. Other log types provide their own evidence. Selecting the correct record family reduces both query complexity and false conclusions.
The result should be an investigation trail, not a pile of exported rows.
Use time as a troubleshooting control
Current Strata Logging Service Log Viewer workflows require a time range and support custom ranges up to 30 consecutive days, while allowing access to older retained data within the service’s available history. For operational troubleshooting, a narrow range around the event is usually better than a month-long search.
Correlate timestamps with configuration pushes, user sign-ins, DHCP changes, routing events, software updates, and incident reports. If a failure began immediately after a push, query before and after that moment. If a roaming user changed networks, identify the exact period in which the source address mapping changed.
Exports are useful when an investigation must be shared or preserved, but remember that exported logs are normalized for downstream analysis and may use field names rather than the display labels analysts see in the UI.
Build queries from fields that prove or disprove the hypothesis
Strata Logging Service queries are Boolean expressions over log fields. Start with the most selective reliable field—often an address, user, application, rule, device, or session attribute—then add criteria only when they reduce ambiguity.
A useful troubleshooting query might combine a source address, destination address, and time range, then compare the rule and application fields across returned records. A hunting query may begin with an application or URL pattern and exclude known benign infrastructure. Avoid creating one enormous query before confirming each field contains the expected values.
The query builder can suggest fields and operators as you work. This is more than a convenience: it helps prevent silent failures caused by guessing at field names or data types.
Use pattern matching carefully
As of July 2026, Strata Logging Service added ILIKE, NOT ILIKE, and NOT LIKE operators for more flexible string and enum matching in supported query contexts. ILIKE is useful when capitalization should not determine whether a record matches, while NOT ILIKE and NOT LIKE help remove known noise from a result set.
Pattern matching is powerful but easy to overuse. A broad wildcard can return unrelated hosts, URLs, filenames, or users that happen to contain the same substring. Start with exact equality when possible, then move to patterns when the data genuinely varies.
Document complex saved queries. An analyst should be able to explain what population the query includes and what it deliberately excludes; otherwise a “clean” result may simply be a filter blind spot.
Read the important traffic-log fields together
No single field tells the whole story of a firewall session. Source and destination addresses establish endpoints. Source and destination zones show the policy path. The rule identifies the decision point. App-ID explains what the firewall recognized. User or device identity adds context. Session end reason, byte counts, and timing help distinguish a block from an application failure.
Compare these fields to the intended design. A destination address may be correct while the egress zone is wrong because routing changed. The expected user may be absent because User-ID mapping expired. An allow rule may match while a later threat or decryption action terminates the connection.
An evidence-first workflow uses Palo Alto firewall monitoring to move from an aggregate dashboard signal to the traffic, threat, or session records that explain it.
Correlate multiple log types before changing policy
Traffic marked as allowed can still fail because of decryption, threat prevention, URL policy, DNS security, or application behavior. Use a common time window and endpoint pair to correlate related records. If the traffic log says “allow” but the threat log shows a reset caused by a signature, changing the security rule will not fix the actual problem.
Audit logs are equally important when behavior changed unexpectedly. A rule move, object update, security-profile change, or administrative override may explain why traffic started behaving differently. Correlating enforcement and configuration evidence reduces speculation.
When there is no corresponding log record, consider whether the traffic reached the managed enforcement point at all. DNS, endpoint routing, upstream devices, and application failures can produce symptoms that users describe as “the firewall blocked me.”
Use saved queries as operational runbooks
Repeated incidents deserve repeatable queries. Save searches for high-value workflows such as validating a policy rollout, checking denied traffic to a critical application, finding sessions for a VIP, reviewing decryption failures, or tracing a user’s activity during an incident window.
Keep saved queries parameterized in concept even if the interface stores literal values. Document which fields an analyst should replace for a new case. A good query runbook explains what normal results look like and what deviations should trigger deeper investigation.
This makes Strata Logging Service part of operations rather than merely a forensic archive.
Respect visibility and retention limitations
Log analysis is only as complete as the telemetry sent to the service. If a rule does not log the relevant sessions, a device is not forwarding a log type, or a service integration is misconfigured, the absence of records does not prove the absence of activity.
Similarly, different products and licenses determine which logs and workflows are available. Validate the environment before designing an investigation that assumes every data source exists. For posture features such as zero-hit analysis, current Strata Cloud Manager documentation explicitly depends on traffic logs being available in Strata Logging Service.
A mature logging design therefore includes both query technique and telemetry assurance: know what should arrive, verify that it does, and monitor gaps.
Turn log findings into precise operational changes
The end of an investigation should be a specific conclusion: a rule order caused the wrong match; a user mapping was missing; a destination was translated unexpectedly; an application was identified differently; a security profile reset the session; or the traffic never reached the firewall.
Use that conclusion to make the smallest corrective change and then run the same query again. Compare pre-change and post-change evidence rather than relying on user reports alone. If the issue was configuration debt, feed it into cleanup or object redesign.
Across the current Network Security Professional and analyst-oriented roles, centralized visibility is increasingly inseparable from policy operations. Strata Logging Service becomes most valuable when analysts use it to connect intended configuration to observed behavior, one reproducible question at a time.
For investigations that span multiple devices, normalize the question before comparing records. Different firewalls may see different zones or local object names even when the business flow is the same. Focus on stable evidence such as endpoint identity, application, rule purpose, and timestamps, then account for the device-specific context. This prevents analysts from treating harmless naming differences as contradictory evidence.
Query performance also benefits from progressive narrowing. Start with a short time range and one high-confidence selector, verify that the expected records appear, then add additional conditions. If the result unexpectedly drops to zero after one clause, you have immediately identified the criterion that does not match the stored data. This is more reliable than writing a long expression and then guessing which component is wrong.
When exporting data for another team, preserve the query, time zone, log type, and time range with the file. Raw CSV rows without the retrieval logic are difficult to reproduce and can lead to different conclusions later. Good evidence is reproducible: another analyst should be able to run the same query against the same window and understand why those records were selected.
Saved searches should also be reviewed as the schema and query language evolve. The July 2026 additions to pattern matching are useful, but a newly available operator does not automatically make an old search better. Change a proven query only when the new expression improves precision, readability, or maintainability, and validate the revised result against known records.
For long-running investigations, keep a small evidence ledger containing the query text, the time window, the expected records, the actual result, and what was tested next. This prevents circular troubleshooting and makes handoff easier across shifts. It also helps distinguish a real absence of telemetry from a query that was accidentally narrowed too far.
Use log retention strategically. Routine operational searches may only need recent data, while investigations of periodic jobs, dormant accounts, or low-frequency attacks may need older history. Define which questions require longer retention and ensure the service configuration supports them before an incident occurs.