Cortex XSIAM Platform Architecture and Deployment
The Cortex XSIAM Platform Architecture and Deployment domain tests whether you can explain how Cortex XSIAM is delivered and how its components fit together: the cloud tenant and console, analytics and automation services, endpoint agents, and Broker VMs. Expect questions about data flow, deployment choices, and which component owns collection versus analysis.
Core architecture rules
- Cortex XSIAM is a cloud-delivered platform; the management console, analytics, automation, and data lake are operated by Palo Alto Networks. You do not deploy a management server on-premises.
- The Cortex XDR agent provides endpoint telemetry and response capability. It registers endpoints to the tenant and should be deployed with a tested policy.
- A Broker VM is an optional on-premises virtual appliance for local collection and proxying: syslog, network flow, SNMP, and agent traffic where direct egress is not allowed. It is not the analytics engine.
- Cloud connectors and APIs pull data directly from SaaS, cloud, and identity providers. Not every source needs a Broker VM.
- Plan for region and data-residency requirements, SSO, and redundant local collection. Broker VMs can be paired or replicated for continuity.
Worked example
A retailer has on-prem firewalls and endpoints that cannot reach the internet directly. Design: deploy two Broker VMs in the data center, send firewall syslog to the broker, allow the broker outbound to the XSIAM tenant, and install the Cortex XDR agent on endpoints configured to use the broker as proxy. Cloud AWS logs can use a cloud connector rather than the broker. Reasoning: the broker solves local collection and egress; cloud APIs avoid unnecessary hops.
Traps
Assuming every data source must traverse a Broker VM; treating the broker as the console; forgetting outbound 443; deploying one broker without redundancy; confusing agent telemetry with syslog collection.