Skip to content
Building a SOC with...
 
Notifications
Clear all

Building a SOC with Palo Alto Cortex - what does the full stack look like?

3 Posts
3 Users
0 Reactions
7 Views
(@crm_trailblazer_7)
Estimable Member
Joined: 3 months ago
Posts: 129
Topic starter   [#18247]

I've been tasked with evaluating Cortex XSIAM as the core of a new SOC build-out. The marketing slides are predictably vague about what you actually need to buy and run. "AI-powered" doesn't run queries.

Before I trust a single vendor demo, I need to see the real, physical stack. From what I've pieced together through docs and conversations, building a SOC on Palo Alto's Cortex platform typically involves several components. I want this verified and filled in.

Here's my current understanding of a "full stack" deployment:

* **Core Platform:** Cortex XSIAM (Security Incident & Attack Management). This is the brain, combining SIEM, SOAR, and their analytics. You're ingesting logs here.
* **Data Collection & Forwarding:** You need to get logs to XSIAM. This often involves:
* **Cortex Data Lake (CDL):** For Palo Alto Networks firewall traffic (Strata, Prisma).
* **Cortex XDR Agent:** For endpoint telemetry (PC, Mac, Linux servers).
* **Cortex XSOAR:** For orchestration playbooks and as an additional data source/action hub.
* **Third-party connectors:** For everything else (network appliances, cloud services, other security tools). These are often "apps" built for XSOAR or direct integrations.
* **Management Consoles:** You'll be switching between:
* XSIAM UI for investigation, dashboards, automated case management.
* XSOAR UI for playbook development and manual automation tasks.
* Possibly separate panes for XDR agent policy management.

The big questions I have are about the practical, daily reality:

1. **Data Ingestion & Cost Control:** XSIAM pricing is ingestion-based. What are the concrete strategies for filtering noise *before* it hits the platform? Are you running a separate log shipper (e.g., Cribl) in front, or relying solely on Palo Alto's built-in mechanisms?
2. **The XSOAR Dependency:** For a mature SOC, is XSOAR now just a component *within* XSIAM, or is it still a separate, mandatory purchase? If separate, how deep is the integration? Do playbooks authored in XSOAR execute natively within XSIAM's case workflow?
3. **The Analyst Workflow:** What does a Tier 1 analyst's screen actually look like? Are they primarily in the XSIAM "Cases" view, with XSOAR playbooks running as automated actions in the background? Or are they constantly toggling between applications?

I need specifics, not theory. If you're running this stack, tell me:

* Your actual data sources and approximate EPS/GB/day.
* How you handle non-PAN data (e.g., a CrowdStrike alert or an AWS CloudTrail log).
* A sample playbook structure for a common alert, like a phishing email report.

```python
# Example of what I'm looking for - a pseudo-playbook outline.
# Trigger: Email reported by user via email plugin.
# Steps:
# 1. Enrich sender address with Threat Intelligence (XSIAM native or external API).
# 2. Search XSIAM logs for other emails from same sender/domain in last 24h.
# 3. If malicious, isolate affected endpoint via XDR API.
# 4. Create case in XSIAM, populate with all artifacts.
# 5. Notify analyst team via Slack.
```

Who's running this in production and can break down the moving parts?


Show me the query.


   
Quote
(@calebh)
Eminent Member
Joined: 7 days ago
Posts: 41
 

You're on the right track, but let me add a crucial layer that often gets missed: the licensing and capacity dimension. Your "full stack" is incomplete without it.

The physical stack depends heavily on your licensed data types and volumes. For instance, "Cortex XSIAM" isn't a single SKU. You license data ingestion per GB/day by category (Network, Endpoint, etc.). The *need* for CDL or XDR agents hinges on whether you're bringing in those specific data types. You might also be looking at a separate SOAR instance (XSOAR) if your XSIAM license doesn't include the full orchestration capacity you need.

Also, don't underestimate the hidden compute. Those third-party connectors and analytic models run somewhere - often on customer-provisioned VMs or containers that aren't part of the core platform sale. Ask your SE for the deployment guide appendix listing all the required VMs, their specs, and who hosts them. That's where the rubber meets the road.


Trust the data, not the demo.


   
ReplyQuote
(@bookworm42)
Estimable Member
Joined: 2 weeks ago
Posts: 88
 

You're missing a real-world cost sink: the infrastructure to run the connectors and any custom parsing. Those third-party "apps" in the marketplace aren't freebies. They either consume credits in the cloud or require you to spin up VMs in your own environment. I've seen teams burn three months just figuring out the log forwarder for a legacy IDS that doesn't have a native JSON output.

Also, don't assume XSIAM includes full XSOAR capabilities out of the box. The "SOAR" in XSIAM is a subset. If you want advanced playbooks, custom integrations, or case management outside the incident timeline, you're looking at a separate XSOAR license. That's another SKU, another set of compute resources, and another team to manage it.

Your list has the right components, but the "full stack" is as much about the operational overhead and licensing gotchas as it is about the technology. Have you modeled the data ingestion growth for the first 12 months? Palo's pricing gets sticky when you blow past your committed GB/day.



   
ReplyQuote