Docs

Appearance

Cortex XDR → LAW CEF Integration ​

Purpose: Configure Cortex XDR to forward alerts and audit logs to Azure Log Analytics Workspace via syslog CEF, making them queryable in CommonSecurityLog alongside Palo Alto firewall logs.

Audience: Rory Status: Planned — not yet deployed

Architecture ​

Cortex XDR (cloud)
  │  syslog CEF / TCP 514
  ▼
Linux syslog forwarder VM  (Ubuntu 22.04)
  │  Azure Monitor Agent (AMA)
  │  Data Collection Rule → CommonSecurityLog stream
  ▼
cirius-logging-law-central  (workspace ID: 5d76d1f2)
  │
  ▼
CommonSecurityLog table — queryable alongside Palo Alto firewall CEF

The syslog forwarder is a lightweight Linux VM. The existing syslog VM in the AWS Logging account (038901680748) can serve as the PROD forwarder. A separate forwarder is needed for DDE.

Prerequisites ​

  • A Linux VM (Ubuntu 22.04) reachable from Cortex XDR's cloud IP ranges
  • AMA (Azure Monitor Agent) installed and connected to cirius-logging-law-central
  • DCR (Data Collection Rule) configured to collect syslog CEF data
  • Network: TCP port 514 open from Cortex XDR IP ranges to the syslog VM

Cortex XDR IP ranges: retrieve from Cortex XDR console → Settings → Configurations → Proxy → allowed IP ranges, or check Palo Alto documentation for your region.

Step 1 — Configure Cortex XDR Syslog Integration ​

  1. Cortex XDR console: https://ciriusgroup.xdr.us.paloaltonetworks.com
  2. Navigate to Settings → Configurations → Integrations → External Applications
  3. Click Add → Syslog Server
  4. Configure:
    • Name: LAW-CEF-Forwarder
    • IP Address: syslog VM IP
    • Port: 514
    • Protocol: TCP
    • Format: CEF
  5. Under Log Types, enable:
    • Alerts
    • Audit Log
    • Agent Reports
  6. Save
  7. Click Test to send a test event — verify the test event arrives in the syslog VM's log (check /var/log/cef.log after Step 2)

Step 2 — Configure rsyslog on the Forwarder VM ​

SSH into the syslog forwarder VM via Twingate or SSM.

Install rsyslog if not present:

bash
sudo apt-get update && sudo apt-get install -y rsyslog

Create a dedicated CEF configuration file:

bash
sudo tee /etc/rsyslog.d/10-cef.conf > /dev/null << 'EOF'
# Accept CEF events on TCP 514
module(load="imtcp")
input(type="imtcp" port="514")

# Write CEF events to dedicated log file
if $rawmsg contains "CEF:" then {
    action(type="omfile" file="/var/log/cef.log")
    stop
}
EOF

Set permissions and restart:

bash
sudo chmod 640 /var/log/cef.log 2>/dev/null || sudo touch /var/log/cef.log && sudo chmod 640 /var/log/cef.log
sudo chown syslog:adm /var/log/cef.log
sudo systemctl restart rsyslog
sudo systemctl status rsyslog

Verify rsyslog is listening on TCP 514:

bash
sudo ss -tlnp | grep 514

Step 3 — Install Azure Monitor Agent (AMA) ​

Option A — Azure Arc (recommended for AWS-hosted syslog VM):

  1. Onboard the VM to Azure Arc: az connectedmachine connect — generates an onboarding script to run on the VM
  2. Once the VM appears in Azure Portal → Azure Arc → Servers:
    bash
    az connectedmachine extension create \
  --name AzureMonitorLinuxAgent \
  --publisher Microsoft.Azure.Monitor \
  --type AzureMonitorLinuxAgent \
  --machine-name <vm-name> \
  --resource-group <resource-group> \
  --location eastus

Option B — Direct AMA install on Azure VM:

If the syslog forwarder is an Azure VM, install AMA via the Azure Portal:

  1. VM → Extensions + applications → Add → Azure Monitor Agent
  2. Follow the prompt to create or assign a DCR during install

Step 4 — Create a Data Collection Rule (DCR) ​

The DCR tells AMA what to collect and where to send it.

  1. Azure Portal → Monitor → Data Collection Rules → Create
  2. Basics:
    • Name: dcr-cortex-cef-prod
    • Region: same as your LAW workspace region (East US)
    • Platform type: Linux
  3. Resources: add the syslog forwarder VM
  4. Collect and deliver:
    • Add data source → Linux Syslog
    • Facility: syslog (or local0–local7 depending on how rsyslog is configured)
    • Minimum log level: Info
    • Destination: Log Analytics Workspace → cirius-logging-law-central (workspace ID 5d76d1f2)
    • Stream: Microsoft-CommonSecurityLog

Important: Use Microsoft-CommonSecurityLog for CEF data, not Microsoft-SecurityEvent. The Microsoft-SecurityEvent stream requires Sentinel to be enabled on the workspace. cirius-logging-law-central has Sentinel enabled, so both work — but Microsoft-CommonSecurityLog is the correct stream for CEF/syslog data and lands in the CommonSecurityLog table.

  1. Save and assign to the syslog forwarder VM

Step 5 — Verify Data Flow ​

Allow 10–15 minutes after configuration, then verify in LAW:

kql
CommonSecurityLog
| where TimeGenerated > ago(1h)
| where DeviceVendor contains "Palo Alto"
| where DeviceProduct contains "Cortex"
| project TimeGenerated, DeviceName, Activity, SourceUserName, SourceIP, Message
| order by TimeGenerated desc

If no results after 15 minutes:

  1. Check rsyslog is receiving data: sudo tail -f /var/log/cef.log — send another test event from Cortex XDR console
  2. Check AMA is running: sudo systemctl status azuremonitoragent
  3. Check DCR assignment: Azure Portal → DCR → Resources → confirm the syslog VM is listed
  4. Check network: confirm TCP 514 is reachable from Cortex XDR IP ranges to the syslog VM NSG/security group

Useful KQL Queries ​

kql
// All Cortex XDR alerts in the last 24h
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceVendor contains "Palo Alto" and DeviceProduct contains "Cortex"
| project TimeGenerated, DeviceName, Activity, SourceUserName, SourceIP,
    DestinationIP, Severity, Message
| order by TimeGenerated desc

// Cortex alert count by severity
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor contains "Palo Alto" and DeviceProduct contains "Cortex"
| summarize Count = count() by Severity, bin(TimeGenerated, 1d)
| render timechart

// Cross-correlate Cortex alerts with Palo Alto firewall CEF
CommonSecurityLog
| where TimeGenerated > ago(4h)
| where DeviceVendor == "Palo Alto Networks"
| summarize Sources = make_set(DeviceProduct), AlertCount = count() by SourceIP
| order by AlertCount desc

Known Issues ​

IssueCauseResolution
Microsoft-SecurityEvent returns 400 InvalidPayloadWrong DCR stream for non-Sentinel workspaceUse Microsoft-CommonSecurityLog stream
CEF events arrive in Syslog table instead of CommonSecurityLogDCR stream misconfiguredUpdate DCR to use Microsoft-CommonSecurityLog stream
Cortex CEF Message field contains nested JSONCortex alert format varies by typeParse with parse_json(Message) in KQL
Port 514 connection refusedNSG/security group blockingAdd inbound rule for TCP 514 from Cortex XDR IP range
AMA not forwarding on Azure Arc VMArc connectivity issuesCheck Arc agent: sudo systemctl status himds

DDE Environment ​

The DDE environment needs a separate syslog forwarder and a separate DCR pointing to the same LAW workspace but with source_system = 'DDE' tags. Cortex XDR for DDE is on the same console but alerts can be filtered by endpoint group. Configure a second syslog server in Cortex XDR pointing to the DDE forwarder VM IP.

  • runbooks/cortex-xdr-operations.md — Cortex XDR console operations
  • security/edr-cortex-xdr.md — EDR architecture and MDE passive mode
  • runbooks/edr-silence-escalation.md — when Cortex goes silent during an attack

Internal use only — Cirius Group