Purpose
This guide explains how to configure the Palo Alto Cortex XDR Response integration in Logsign so that an analyst can manually, or a correlation rule can automatically, isolate an endpoint, run a script, block a file hash, or update an incident on Cortex XDR directly from Logsign. This is not the log collection poller that brings Cortex XDR incidents and alerts into Logsign as events; it is a separate Response (action) integration, configured under Settings > Integrations > Responses, that lets Logsign reach out to Cortex XDR and take action.
Logsign authenticates to the Cortex XDR API using an API Key ID and API Key pair generated in the Cortex XDR console, and calls Cortex XDR's public API endpoints for incidents, endpoints, scripts, and hash exceptions.
Important: this is a different device configuration from the Cortex XDR log-collection poller. If your organization already set up the poller (see the "Palo Alto Cortex XDR integration via API" article), do not reuse that API key here. As explained in Step 1, the poller uses a Standard security level key, while this Response integration requires an Advanced security level key. The two are not interchangeable.
Prerequisites
- A Cortex XDR tenant with API access enabled and permission to create API keys (an account with administrative rights in Cortex XDR's Configurations area).
- An API key created specifically for this integration with Advanced security level (see Step 1). Do not reuse a Standard-level key created for the Cortex XDR poller or any other tool; the authentication scheme is different and a Standard key will not work here.
- Network connectivity from the Logsign server to your Cortex XDR tenant's API host on outbound HTTPS/443.
- Know your tenant's Cortex XDR FQDN (for example
<tenant>.xdr.us.paloaltonetworks.comor the EU/APAC equivalent for your region). You will enter a derived form of this in Step 2; see the format warning there, it is different from what the poller documentation asks for.
Step 1: Generate a Cortex XDR API key
- Log in to the Cortex XDR console with an administrator account.
- Open the Configurations section, then go to Integrations > API Keys.
- Click New Key.
- Under Security Level, select Advanced, not Standard. Advanced keys are authenticated by hashing the key together with a nonce and a timestamp on every request (Logsign's Response integration is built to do this automatically); Standard keys are sent as plain text and are not compatible with how this integration authenticates. If you select Standard here, the connection test and every action will fail with an authentication error.
- Under Role, do not select a broad administrative role such as Instance Administrator. Select or create a Custom Role scoped to only what this integration needs. At minimum, grant read access to Incidents & Alerts if you plan to use get_incidents, get_incident_extra_data, or get_action_status. If you plan to use any of the write/action methods (isolate, unisolate, update_incident, block_list_files, scan_endpoints, run_script, run_snippet_code_script, get_scripts), the role also needs edit/write access to the corresponding Endpoint Administration and Response Actions components in Cortex XDR's RBAC settings. The exact component names in the Custom Role builder have not been independently verified against a live console as part of this write-up (unverified); confirm the specific permission names on your Cortex XDR version before finalizing the role, and prefer granting only the components the methods you intend to use actually require rather than selecting all of them.
- Optionally enable an expiration date if your security policy requires periodic key rotation.
- Click Generate. Cortex XDR shows the API key value once. Copy it immediately and store it securely; it cannot be retrieved again later, only regenerated (which invalidates the old key and requires updating the Logsign device).
- In the API Keys table, note the ID column value for the key you just created. This is the Auth ID / API Key ID you will enter in Logsign in Step 2, separate from the key value itself.
Step 2: Configure the integration in Logsign
In Logsign, go to Settings > Integrations > Responses, search for Cortex Xdr, click Configure, then +Device. Fill in the following fields:
| Field | Required | Description |
|---|---|---|
| Device Name | Yes | A label of your choosing to identify this Cortex XDR connection inside Logsign. |
| Host | Yes | Your Cortex XDR tenant's FQDN, without any protocol prefix and without the api- prefix. See the format warning below; this integration adds both automatically, and entering them yourself will produce a broken address. |
| API Key | Yes | The Advanced-level API key value generated in Step 1. Logsign stores this encrypted at rest. |
| API Key ID (Auth ID) | Yes | The numeric ID shown next to the API key in the Cortex XDR API Keys table, not the key value itself. |
Format warning on the Host field: based on the current code, this integration builds the final API URL by prepending https://api- to whatever you type into Host. Enter only the bare tenant FQDN, for example tenant.xdr.us.paloaltonetworks.com, correct; not https://tenant.xdr.us.paloaltonetworks.com and not api-tenant.xdr.us.paloaltonetworks.com, both wrong. This is the opposite convention from the separate Cortex XDR log-collection poller's Host field, which asks you to type the api- prefix yourself and just omit https://. Mixing the two up is an easy mistake if you have already configured the poller.
A code-level review while writing this guide found that the way this Host value is currently assembled internally can produce a malformed request URL, which would cause every call (connection test and every method) to fail with a connection or URL error even when the Host, API Key, and API Key ID are all entered exactly as described above. This has not been confirmed against a live Cortex XDR tenant. If you configure this integration exactly as documented here and every action still fails immediately with a connection-level error rather than an authentication or permissions error, this is a known area under review; contact Logsign support and reference this article so the underlying behavior can be checked on your instance/version.
After saving, run Logsign's connection test on this device before relying on it in a correlation rule or manual action.
Available Methods
Once the device is configured, these methods become available as response actions in Incident/Alarm automation rules or as manual actions from the incident view.
get_incidents
Returns the list of incidents visible to the API key's role. Takes no parameters.
get_incident_extra_data
Returns full detail for a single incident, including its alerts, network artifacts, and file artifacts.
| Parameter | Required | Description |
|---|---|---|
| incident_id | Yes | The Cortex XDR incident ID to retrieve, typically taken from a field already present on the triggering incident/alert. |
update_incident
Updates fields on an existing incident, such as assignment, manual severity, or status.
| Parameter | Required | Description |
|---|---|---|
| incident_id | Yes | The Cortex XDR incident ID to update. |
| assigned_user_mail | No | Email address of the user to assign the incident to. |
| assigned_user_pretty_name | No | Display name of the assignee. |
| manual_severity | No | Overrides the incident's severity, expected values follow Cortex XDR's severity naming (for example low, medium, high). |
| status | No | New incident status, expected values follow Cortex XDR's status naming (for example new, under_investigation, resolved_threat_handled). |
| resolve_comment | No | Free-text resolution comment. Based on a code-level review, this value is not currently being forwarded to Cortex XDR (an internal parameter-mapping defect), so it may not appear on the incident even when filled in. This has not been independently confirmed on a live tenant; if resolve comments set from Logsign do not appear in Cortex XDR, set them directly in the Cortex XDR console instead until this is resolved. |
isolate
Places the specified endpoint into network isolation on Cortex XDR.
| Parameter | Required | Description |
|---|---|---|
| endpoint_id | Yes | The Cortex XDR endpoint ID (agent ID) to isolate. |
unisolate
Removes network isolation from a previously isolated endpoint.
| Parameter | Required | Description |
|---|---|---|
| endpoint_id | Yes | The Cortex XDR endpoint ID (agent ID) to release from isolation. |
get_endpoint / get_endpoints
Both return endpoint inventory data from Cortex XDR. Neither exposes any filter parameters in the current Logsign implementation, even though the underlying Cortex XDR API supports filtering; both currently return the full unfiltered result set from Cortex XDR (subject to Cortex XDR's own default page size).
block_list_files
Adds a file hash to the Cortex XDR block list (hash exceptions).
| Parameter | Required | Description |
|---|---|---|
| hash_list | Yes | Despite the parameter name, this accepts a single hash value per call, not a comma-separated list. To block multiple hashes, call this method once per hash. |
scan_endpoints
Triggers a malware scan on one or more endpoints, or on all endpoints.
| Parameter | Required | Description |
|---|---|---|
| filters | Yes | One of: all, endpoint_id_list, dist_name, group_name, scan_status. Select all to scan every endpoint in the tenant. |
| operator | Yes | One of: in, gte, lte. Still required even when filters is set to all, in which case its value is not actually used, fill in any value from the list to satisfy the form. |
| value | Yes | The value to filter on (for example a specific endpoint ID or group name). Also required but unused when filters is all. |
get_scripts
Searches the script library available for run_script.
| Parameter | Required | Description |
|---|---|---|
| field | Yes | One of: name, description, created_by, windows_supported, linux_supported, macos_supported, is_high_risk. |
| operator | Yes | Only in is supported. |
| value | Yes | The value to match against the selected field. |
run_script
Runs a predefined script from the Cortex XDR script library against a set of endpoints selected by filter.
| Parameter | Required | Description |
|---|---|---|
| script_uid | Yes | The script's unique ID, obtained from get_scripts. |
| field | Yes | Endpoint filter field, one of: name, description, created_by, windows_supported, linux_supported, macos_supported, is_high_risk. |
| operator | Yes | Only in is supported. |
| value | Yes | The value to match against the selected field to choose which endpoints run the script. |
| timeout | Yes | Script execution timeout, in seconds, as a string. |
| parameter_key | Yes | Name of a single script input parameter to pass. |
| parameter_value | Yes | Value for that script input parameter. Only one parameter key/value pair can be passed per call in the current implementation. |
run_snippet_code_script
Runs an ad hoc code snippet against endpoints selected by filter.
| Parameter | Required | Description |
|---|---|---|
| field | Yes | Endpoint filter field. |
| operator | Yes | Filter operator. |
| value | Yes | Filter value. |
get_action_status
Checks the status of a bulk/group action previously started by isolate, unisolate, scan_endpoints, run_script, or run_snippet_code_script (the action_id returned by those calls).
| Parameter | Required | Description |
|---|---|---|
| group_action_id | Yes | The action_id value returned by the method that started the action you want to check. |
A code-level review found that this method's underlying configuration schema lists different parameter names (field, operator, value) than what the code actually reads (group_action_id). If the Logsign action form for get_action_status shows fields other than a single ID value, this is a known inconsistency; contact Logsign support if you cannot get this method to return a result, referencing this article.
Notes and Limits
- This integration is separate from the Cortex XDR log-collection poller. They use different credentials, different API key security levels (Advanced here, Standard for the poller), and different Host field formatting conventions. Configuring one does not configure the other.
- get_endpoint and get_endpoints do not accept any filter parameters in the current implementation; both return Cortex XDR's default unfiltered endpoint list.
- block_list_files accepts one hash per call despite its parameter name suggesting a list.
- run_script and run_snippet_code_script only support filtering endpoints with the in operator, and run_script only supports a single script parameter key/value pair per call.
- The resolve_comment field on update_incident is not currently forwarded to Cortex XDR based on a code-level review; see the update_incident table above.
- Logsign's connection test validates that the Host, API Key, and API Key ID can authenticate; it does not verify that the API key's Custom Role has sufficient permissions for every write action (isolate, run_script, and so on). A successful connection test does not guarantee every method will succeed.
- Isolating an endpoint is disruptive: an isolated host loses normal network connectivity except for its connection back to Cortex XDR. If isolate is wired into an automated correlation rule rather than a manual analyst action, confirm the correlation logic is specific enough to avoid isolating hosts on a false positive.
Troubleshooting
| Symptom | Likely cause | What to check |
|---|---|---|
| Connection test or every action fails immediately with a connection, DNS, or malformed URL style error, even though Host, API Key, and API Key ID look correct | Either the Host value was entered with a protocol prefix or an api- prefix (see the format warning in Step 2), or the known Host-URL construction issue described in Step 2 is affecting this instance. | Re-check that Host contains only the bare tenant FQDN with no https:// and no api- prefix. If the error persists with a correctly formatted Host, contact Logsign support and reference this article. |
| 401 Unauthorized on connection test or any method | Wrong API Key or API Key ID, the API key was deleted or regenerated in Cortex XDR after Logsign was configured, or the key was created with Standard security level instead of Advanced. | Confirm the API Key and API Key ID (Auth ID) match a currently active key in the Cortex XDR API Keys table, and confirm that key's Security Level is Advanced, not Standard. Also check that the Logsign server's clock is reasonably in sync with real time; the Advanced authentication scheme includes a timestamp, and significant clock drift can cause authentication to be rejected. |
| 403 Forbidden, or an "insufficient permissions" style error on a specific method | The API key authenticates but its assigned Role/Custom Role does not include the Cortex XDR RBAC component that method needs (for example a read-only role trying to call isolate). | In Cortex XDR, open Configurations > Integrations > API Keys, identify the Role assigned to this key, and confirm it grants edit/write access to the relevant component for the method you are calling (see Step 1). |
| get_action_status returns nothing or an error | See the known manifest/parameter naming inconsistency noted under get_action_status above. | Confirm you are passing the action_id value returned by the original isolate, unisolate, scan_endpoints, run_script, or run_snippet_code_script call as group_action_id. If the Logsign form does not expose that field correctly, contact Logsign support. |
| update_incident appears to succeed but the resolve comment does not show up in Cortex XDR | Known limitation, see the update_incident table above. | Set the resolve comment directly in the Cortex XDR console until this is resolved. |
| run_script or run_snippet_code_script returns a result but the target endpoints did not run anything | The field/operator/value filter did not match any endpoints, or the script_uid is not valid for the endpoints' OS (a script that only supports Windows will not run against macOS or Linux endpoints even if the filter matches them). | Use get_scripts and get_endpoints/get_endpoint to confirm the script_uid and the filter values actually match the intended endpoints, and that the script's supported OS list includes those endpoints. |