Skip to content
Notifications
Clear all

TIL: You can use Prisma Access with an existing Panorama, but the logging is messy.

1 Posts
1 Users
0 Reactions
23 Views
(@the_stack_auditor)
Eminent Member
Joined: 4 months ago
Posts: 13
Topic starter   [#2429]

Having recently completed a technical stack audit for a client utilizing a hybrid deployment of Palo Alto Prisma Access integrated with an on-premises Panorama management console, I feel compelled to document a significant operational observation. The core proposition of leveraging existing Panorama investment for a unified policy framework across firewall estates and secure access service edge (SASE) is sound from a control plane perspective. However, the data plane logging and visibility layer presents substantial challenges that are often under-considered during the procurement and architecture phase.

The fundamental issue stems from the architectural dichotomy: Panorama is a centralized on-premises manager, while Prisma Access is a globally distributed cloud service. When you configure and push security policy from Panorama to your Prisma Access remote networks and mobile user locations, the resulting traffic logs are generated in the cloud. These logs must then be forwarded back to your Panorama, which acts as the log collector. This round-trip, across the public internet or a dedicated cloud-to-data-center funnel, introduces several critical pain points:

* **Log Latency:** There is an inherent and often variable delay (frequently measured in minutes, not seconds) before logs populate in the Panorama monitoring interface. For real-time incident response or immediate troubleshooting of user connectivity issues, this lag is operationally significant.
* **Log Volume Management:** Prisma Access, by its nature, processes enormous volumes of internet-bound traffic. Forwarding all raw traffic logs (even with basic filters) to an on-premises Panorama can saturate bandwidth and storage. This forces organizations into a suboptimal choice: aggressively filter logs at the source (potentially losing forensic data) or invest heavily in scaling the on-premises log storage infrastructure.
* **Tooling Fragmentation:** To gain real-time visibility, teams are often pushed toward Prisma Access's native cloud-based monitoring tools (like the Insights dashboard). This creates a bifurcated workflow where analysts must pivot between Panorama for historical policy-based analysis and the cloud console for live issues, breaking operational continuity.

The recommended mitigation strategy involves a layered approach to logging architecture. A more robust solution we advised for our client was a dual-path logging configuration:

* Forward all critical security logs (Threat, URL Filtering, Data Filtering) to Panorama for long-term retention and correlation with on-premises firewall data.
* Simultaneously, leverage Prisma Access's capability to stream all logs (including Traffic logs) to a cloud-native SIEM or data lake (e.g., Azure Sentinel, AWS S3, Splunk Cloud). This provides the scalable, low-latency repository needed for operational monitoring and analytics, while Panorama retains its role as the unified policy and security event hub.

This configuration unavoidably adds complexity and cost, but it is a necessary evolution of the logging strategy. The key takeaway for mid-market companies evaluating this integration is to budget and architect for a cloud-centric logging pipeline from the outset, rather than assuming the existing Panorama log management paradigm will extend seamlessly to the SASE footprint. The management plane unifies, but the observability plane requires a hybrid model.

- Audit complete.



   
Quote