Palo Alto Networks Cortex XSOAR Zero Trust Alarm Integration
Support Statement
This documentation is provided "as is" without support for 3rd party software. The level of support for this integration guide is best effort without any SLA on response time. No 3rd party product support can be provided by Superna directly. 3rd party components require support contracts. See EULA for more details.
Overview
SecOps automation is a key requirement to combat the never-ending threats to corporate data. Palo Alto Cortex SOAR enables playbooks and automation to reduce the time to detect and respond to cross-device threats. To support this automation, data from external security tools is vital to provide complete, accurate, and concise threat detection details that allow automation and SecOps teams to respond to threats across the corporate IT infrastructure.
Superna Defender Zero Trust API is the cornerstone technology used to integrate with SIEM, SOAR, and XDR platforms. This guide covers the basic field mapping used to push Ransomware Defender alerts into Cortex XSOAR.
Prerequisites
- Installed Ransomware Defender and/or Easy Auditor
- License key for the Zero Trust API
Solution Configuration in Cortex XSOAR and Defender Zero Trust
Step 1: Configure the Generic Webhook Content Pack
Configure the Generic Webhook content pack from the marketplace in the XSOAR GUI.
Reference the external blog post Pushing Events to XSOAR with Generic Webhooks for full setup details.
Create the webhook instance using the configuration values shown in the XSOAR GUI.
The mapper (incoming) will be blank when you first create the instance. You will edit the instance later in this guide.
Step 2: Configure the Zero Trust Endpoint in Ransomware Defender
The next step creates an Incident Mapping (incoming). Before you can complete that step, a sample of the Zero Trust alert payload needs to be sent into XSOAR to complete the mapping of the Defender Zero Trust schema to the incident schema used in XSOAR.
- Configure the Zero Trust endpoint in the Ransomware Defender Zero Trust tab.
- The endpoint URL is the IP address of the SOAR VM and the name of the webhook instance created above:
- URL format:
https://x.x.x.x/instance/execute/[instance-name] - Example:
https://x.x.x.x/instance/execute/defenderzt
- URL format:
- Add the Content-Type header with value application/json to complete the webhook configuration.
- Click Save to commit the configuration.
Step 3: Test the Webhook
Use the Test Webhooks button to send a sample payload. The response code should return successfully.
If you get a failed response, verify:
- Firewall port 443 is open from Eyeglass to the XSOAR VM
- HTTPS is enabled for webhook configuration per the blog article referenced above
The generic webhook incident created during the test can be deleted — it will not be used for the mapping steps. The mapping step requires the full payload of a lockout event to correctly create the mapping from the Zero Trust schema to the XSOAR schema. Only once the test is successful should you continue to the next steps.
Recommendations:
- Send only Critical events
- Send only event states relevant for SecOps investigation
Step 4: Send a Test Defender Lockout Event
Send a test Defender lockout event to XSOAR for field mapping.
The Security Guard feature cannot be used for this step, as it does not send webhooks to avoid flooding the security tool with test incidents.
Using a test AD or local user on the NAS cluster, create files with any of the banned file extensions in Defender — for example, files saved with the extension .locky. The number of files must exceed the critical threshold defined in your Defender settings.
Once the lockout event has been created in Defender, log in to the XSOAR console and verify that a new incident has been created.
Step 5: Create Incident Mapping (Incoming)
-
Select Get Data from Instance and choose your webhook instance (for example,
defenderzt). You should see the JSON payload from the Defender incidents on the right-hand side. Use the toggle arrows to select a critical-state incident that contains all needed fields. -
Click Auto Map to create common mappings found in both schemas.
-
To add the remaining field mappings, use the search box with Show All selected and type each of the field names below, entering the matching Defender field name to complete the mapping:
Cortex XSOAR Field Name Superna Defender Field Name Device Local IP clientIPs File Names files Protocol protocol Source Hostname nes Source username userName State state User SID user Severity severity -
Click Save and name the mapping SupernaDefenderZT.
Step 6: Update the Generic Webhook Instance
-
Select Exploit for the Incident Type.
noteOther incident types can be used. Exploit is recommended since this is an active exploit security event playbook.
-
Select SupernaDefenderZT for the incoming mapping.
-
Click Save and Exit.
Testing the Webhook and Viewing Enhanced Data
The configuration is now complete. You can test creation of a sample incident and build playbooks with the enhanced data mapped from Defender into the Exploit Incident Type.
- Create a new security incident in Ransomware Defender using the steps above.
- Verify the Incident Type is set to Exploit.
- Open the incident and view the mapped data on the War Room tab. This assists in investigations and running playbooks.
- Click full table view to search through the mapped field data.
Additional triggers and playbooks can now use the enriched data.
Example Playbooks Using Zero Trust Data
After the integration is complete, you can build automated responses such as:
- Disable Ethernet port — launch a playbook using the source client IP address from the Zero Trust alert
- Disable Active Directory user account — launch a playbook using the username from the Zero Trust alert