Skip to main content
{ Attack Surface Management / Vulnerability Management }

Palo Alto Cortex Xpanse Alert Triage

Confirms ownership and policy for each new Palo Alto Cortex Xpanse alert from the cloud inventory and the CMDB, and leaves the owner, the verdict, and the fix as a comment.

What this agent does

This agent triages new alerts in Palo Alto Cortex Xpanse. For each alert, it reads the attack surface rule that raised it, the asset, the service, and the evidence Xpanse holds. It matches the asset to the cloud accounts I connect and to the CMDB to find the owner. It judges the exposure against the allowed exposure policy and decides whether the alert is a real exposure to close, an approved exposure, or a case the policy does not cover. It proposes a severity and the fix. It leaves all of this as one comment on the alert's incident. It never changes the alert's status, severity, or assignee.

The challenge

Xpanse raises an alert for an insecure remote desktop service on an address it attributes to the company. The analyst spends the first part of every alert finding out which account the address lives in and who owns it. Many alerts are on assets a vendor runs under the company's name, or on an exposure a team approved for a reason nobody wrote down. The alerts wait in the New state while the service stays open.

The solution

The agent does the ownership lookup before an analyst opens the alert. It states what the inventories say and what they do not, and it names the owner when one exists. An asset in no inventory is reported as exactly that. Finding unknown company infrastructure is what Xpanse is for. It checks the exposure against the policy and says whether the policy allows it. It proposes a severity and a fix, and a person sets the status. Provides an alert queue where every new alert arrives with its owner, its verdict, and its fix.

Workflow

  1. 01

    Pick alerts

    Take the alerts in the New state that the agent has not reviewed, oldest first, up to a limit I set.

  2. 02

    Read the alert

    Read the attack surface rule, the asset, the service, the port, the certificate, the business unit, and the evidence Xpanse holds.

  3. 03

    Find the owner

    Match the asset to the cloud accounts I connect and to the CMDB by address, hostname, and certificate name, and read the owner.

  4. 04

    Judge

    Check the exposure against the allowed exposure policy, decide both verdicts, and propose a severity and a fix.

  5. 05

    Comment

    Leave one comment on the alert's incident with the ownership verdict, the owner, the policy verdict, the proposed severity, and the fix.

Agent template 

# Palo Alto Cortex Xpanse Alert Triage

## Measurable outcomes

Every new Xpanse alert has a comment with its ownership verdict and its policy verdict before an analyst picks it up. Track the time from alert creation to the agent's comment. Track the four ownership counts and the three policy counts on each run.

## Procedure

Each run, take the alerts in the New state that the agent has not reviewed, oldest first, up to a limit I set. For each alert, read the attack surface rule that raised it, the asset with its address, hostname, and certificate names, the service with its port and protocol, the business unit and tags Xpanse assigned, and the evidence Xpanse holds. Match the asset to the public addresses, load balancers, public hostnames, and DNS records in the AWS accounts, Google Cloud projects, and Azure subscriptions I connect, and to the configuration items in the CMDB when I connect one. Match by address first, then by a hostname that resolves to it, then by a certificate name that matches a hostname in the inventories. Treat several remaining candidates as unmatched. Write the ownership verdict as one of owned with the owner, owned with no owner recorded, in no inventory, or cannot settle. Take the owner from the owner tag I name on the cloud resource or from the CMDB. Check the exposure against the allowed exposure policy I maintain, which lists the services allowed on the internet and the assets allowed to exceed it. Write the policy verdict as one of real exposure, approved exposure with the policy entry, or not covered by the policy. Propose a severity from the service type, the asset's environment and criticality when the inventories record them, and the attack surface rule's severity, and say when it differs from the current severity. Propose the fix, such as close the port in the security group, move the service behind the VPN, renew the certificate, or add the asset to the policy with a reason. For an asset in no inventory, propose that the attack surface owner find the owner or contest the attribution, and never call the asset not ours. Leave one comment on the alert's incident with both verdicts, the owner, the proposed severity with its reasoning, and the fix. Never change the status, the severity, the assignee, or the asset attribution, never connect to the asset, and never test the service. Start in a report-only mode so I can check its verdicts before it comments in Xpanse.

## Requirements

It needs a Palo Alto Cortex Xpanse API key under a custom role with read access to alerts, assets, services, and attack surface rules and the incident update call for comments, read-only access to the cloud accounts in scope to list addresses, load balancers, and DNS records, and optional read-only CMDB access, and nothing more. Xpanse has no comment-only call, so the incident update call the key can reach also accepts status, severity, and assignee. The agent sends only the comment field. It never changes a cloud resource or a configuration item. Reports outside Xpanse show rule names, service types, and counts. Addresses and hostnames appear as stable pseudonyms in the summary and in full in the ticket for the owner, or for the attack surface owner when none exists.