This document provides detailed steps for a customer to achieve Cortex XDR Events / Telemetry forwarding to Google Security Operations (SIEM/Chronicle).
You can contact google-tech@paloaltonetworks.com if you have any further questions.
Cortex XDR Event Forwarding to Google SecOps (Chronicle) Solution
The telemetry data is pulled into an intermediary bucket in the customer tenant and the native integration is set up from there.
The following diagram demonstrates this.
Steps To Setup The Integration (with an example)
Create Required GCS Bucket
The customer creates a GCS bucket in the Customer/MDR tenant. Let’s call it Project1
For this example, we are using the following bucket (your bucket name will be different)
cortex-xdr-events-destination - Used to hold the XDR telemetry data temporarily.
Make sure that the bucket is in the same region as the customer’s Chronicle Region.
Set up Cortex XDR Event Forwarding
Setup the Cortex XDR event forwarding and download the service account key. We will call it xdr_sa_key.json going forward. For the complete guide to event forwarding please refer to this link. The following screenshot shows the customer performing this action. At the end of this step the customer must have
- Storage Path (GCS Bucket URL)
- Service account JSON key.
Secret Manager Setup
Create a secret called EVENT_FRWD_CRTX_KEY and add the contents of the SA
JSON xdr_sa_key.json as the value of the secret
Set up Native Chronicle Feed Integration
- Create a new feed by navigating to SIEM Settings - Feeds - ADD NEW.
- Provide a feed name and select options as shown below. Click GET A SERVICE ACCOUNT. Click Next.
- Provide the bucket name and select the options as shown below. Please add a namespace if that’s relevant to you/ your customer. It is recommended to add an ingestion label. Copy the service account name.
Review the details added and Submit
- The feed should be available in feeds now (the feed name in the example below is different as we are using a feed created earlier)
- For now, disable the feed. We will enable it later.
IAM Setup
The Cortex XDR service account created during the event forwarding setup already has access to the source bucket. Now go ahead and provide the Storage Object Admin and Storage Legacy Bucket Reader access to this service account on the bucket (cortex-xdr-events-destination) created in Step 1. Also, grant the account (the chronicle service account, see below when you adding feeds in Chronicle) created during feed creation of the Storage Object Viewer (roles/storage.objectViewer)
Set up the Solution (One-time setup)
- Enable Following APIs
- Cloud Run
- Artifact Registry
- Open Cloud Shell and download the code using:
git clone https://github.com/PaloAltoNetworks/google-cloud-cortex-chronicle.git
- cd google-cloud-cortex-chronicle/ The contents of this directory are shown below
- Open the file env.properties with the editor of your choice. Update the values of the variables as shown below. Job Schedule minutes can be adjusted based on the size and frequency of data pushed by Cortex.
REGION=us-central1 # update this to the region you want
REPO_NAME=panw-chronicle # The repo name to create
IMAGE_NAME=sync_cortex_bucket # The image name to create
GCP_PROJECT_ID=xdrxxxxxtion # update this to your project ID
JOB_NAME=cloud-run-job-cortex-data-sync # The Cloud Job name to create
PROJECT_NUMBER=80xxxxx9 # update this to your project number
# JOB ENV VARIABLES
SRC_BUCKET=xdr-us-xxxxx-event-forwarding # update this to Cortex XDR GCS bucket
DEST_BUCKET=cortex-xdr-events-destination # Update to the GCS name you created
SECRET_NAME=EVENT_FRWD_CRTX_KEY # Need to match exactly the secret you created
JOB_SCHEDULE_MINS=30
- Provide execute permissions to the deploy.sh using the command
chmod 744 deploy.sh
- Run the deploy.sh using command ./deploy.sh. This step does following
- Creates an artifact registry repository
- Build an image for a cloud run job
- Pushes the image to the Artifact registry
- Creates a Cloud Run Job using this image
- Creates a trigger for this cloud run job every JOB_SCHEDULE_MINS minutes (configured in env.properties)
- After the script finishes, you would need to grant permission to access the Secret Manager Secret you created before to the service account (you can see the service account used by the Cloud Jobs from the script output; see below).
Grant permission through the Secret Manager -> Permissions (Secret Manager Secret Accessor):
Verify setup
- Verify if artifacts mentioned above are created.
- You can wait for JOB_SCHEDULE_MINS minutes or perform the following steps to force execute the job. This is required/recommended to be done only once to test.
- Go to the Cloud run job. In your case, it might show “no executions” in the status.
- Now check the destination bucket
- It should have the files downloaded from the XDR Bucket
- Download one of the files and unzip it and note down one or more event ids as shown below
- Now go to Chronicle - SIEM Settings - [Your Feed Name] -> Enable Feed
- Search for the event id in Chronicle with RAW search / UDM search (you may have to wait for a few minutes for UDM search). You should find the event in the Chronicle.
Regular Usage & Monitoring
- You do not have to change anything going forward for this integration.
- The feed should remain enabled from this point forward unless you want to troubleshoot.
- You can change the schedule based on your requirements. Recommended 30 minutes initially when there’s too much data in the source bucket and gradually reducing to about 5 minutes as things stabilize. You can change that directly on the trigger as shown below
- Monitor the Job Run execution History in Cloud run.
Cloud Billing Costs
Predominantly this solution uses the following resources that are billed.
- GCS cloud bucket
- Cloud Run Batch job
- Artifact Registry
Assuming the deployment region to be us-central1 about 10GB of data persistently stored every day and a cloud run job that runs every 10 minutes for 30 days, the estimated cost is about USD 10 per month.
These are approximate costs. Your costs may vary based on the amount of data and the frequency of the job.
Troubleshooting
- If the data is not available in the Chronicle
- Check if the feed is enabled
- Check the cloud run job logs
- For the very first time, the job may have to deal with GBs of data if you had the forwarding setup enabled for many days. Please check the job logs and wait for it to finish.
- Wait for a few minutes if the event is from a recent file
- Sometimes Cortex sends older files, so try to expand the search time range by a few hours.
- Troubleshooting the Cloud run job
- Check for logs for any errors
- If there are no files logged by the job please check with Cortex XDR support as the files may not be present in the source bucket.
- How to reduce GCS costs?
You can set up the Lifecycle Management rule to delete the object after 14 days. Follow the steps shown in the screenshots below
Uninstallation
Go to the installation folder, provide execute permissions to the uninstall.sh, and execute it by using the command
chmod 744 uninstall.sh && ./uninstall.sh
