Cisco AMP Response Integration via API

Purpose

This guide explains how to configure the Cisco AMP (now branded Cisco Secure Endpoint) Response integration in Logsign so that Incidents and Alarms can automatically, or an analyst can manually, take action on an endpoint from within Logsign: isolating a compromised host from the network, moving it into a different policy group, adding a file hash to an organization-wide blocklist, or looking up computer, event, group and audit data for investigation. This is not the log collection (poller) side of the Cisco AMP integration, which is documented separately and only reads events and audit logs. This is the Response (action) integration, configured under Settings > Integrations > Responses, that lets a Logsign correlation rule or manual incident action reach out to the AMP for Endpoints console and change its state.

Cisco AMP for Endpoints exposes a REST API (the same API family the poller uses) for both reading and writing data. Logsign authenticates to this API using HTTP Basic Authentication with a 3rd Party API Client ID and API Key, the same credential mechanism as the poller side, but the Response integration needs a credential with write access because several of its methods change endpoint state rather than just reading it.

Prerequisites

• Administrator access to the Cisco AMP for Endpoints (Secure Endpoint) console, specifically the Accounts menu where API Credentials are managed. Standard analyst accounts typically do not see this screen.
• Network reachability from the Logsign server to the region-specific AMP API host on port 443 (see Step 2 for the exact hosts).
• Knowledge of which regional cloud your AMP organization is provisioned in (United States, Europe, or Asia/Pacific/Japan/China). This is not something you choose in Logsign; it must match where Cisco actually hosts your organization, or every call will fail regardless of how correct the credentials are.
• For the isolation methods specifically (isolate and release), the target endpoint's AMP connector must support isolation. This depends on the connector's operating system and version; Cisco documents Windows connector isolation support, and a computer's isolation.available flag (visible through the list_computers or get_isolations methods below) tells you whether a given endpoint can be isolated at all. This has not been independently verified against every connector version; treat it as something to confirm per endpoint rather than assumed.
• The minimum Logsign version required for this specific Response integration was not found in the release notes reviewed for this guide and is not verified. Confirm with Logsign if you are running an older release and the Cisco Amp option does not appear under Settings > Integrations > Responses > +Device.

Step 1: Create a 3rd-Party API Client on Cisco AMP

If you already generated a Read-Only API credential for the Cisco AMP log-collection poller, do not reuse it here. This Response integration issues write requests (isolating a host, moving it between groups, adding a hash to a blocklist), which a Read-Only credential will reject with an authorization error. Create a second, dedicated credential instead, so the poller's read-only access and this integration's write access can be rotated or revoked independently of each other.

1. Sign in to your AMP for Endpoints console with an administrator account.
2. Go to Accounts > API Credentials (on some tenants this is under Accounts > Organization Settings > Features > Configure API Credentials).
3. Click New API Credential.
4. Enter an Application name that identifies this credential clearly, for example "Logsign Response Integration", to distinguish it from any read-only credential used elsewhere.
5. Set the Scope to Read & Write. This is required: Read-Only scope is enough for the lookup methods described below (listing computers, events, groups, audit logs), but the isolate, release, move-to-group and add-to-blocklist actions will fail with an authorization error under a Read-Only credential.
6. Click Create.
7. From the resulting API Key Details screen, copy both the 3rd Party API Client ID and the API Key immediately. Cisco displays the API Key value only once; if you close the panel without copying it, you must generate a new credential pair.

Because this credential can isolate or move any endpoint in your AMP organization and can add arbitrary file hashes to an organization-wide blocklist, treat it with the same care as a privileged service account. Restrict who inside your organization can edit the Logsign Response device configuration or trigger these actions from a playbook, independent of the AMP-side scope setting.

Step 2: Configure the Integration in Logsign

In Logsign, go to Settings > Integrations > Responses, search for Cisco Amp, click Configure, then +Device. Fill in the following fields:

Region table: AMP does not use a per-customer subdomain; only the region changes the host. Identify your region from your console's own URL (for example console.eu.amp.cisco.com means Europe), then use the matching API host below.

Format warning, verified against the integration's source code: the Domain field is used internally as a bare host, not a full URL. Enter only the host, for example api.amp.cisco.com. Do not include a https:// prefix and do not include a trailing slash or path. Correct: api.amp.cisco.com. Wrong: https://api.amp.cisco.com or api.amp.cisco.com/. If you enter a scheme prefix, the integration will try to resolve a host that literally contains "https://" and every call will fail to connect. This is a different rule from the Cisco AMP log-collection poller's URL field, which does expect the full https:// address; do not copy that value directly into this Domain field.

Logsign authenticates to the AMP API using HTTP Basic Authentication, sending the Client Id as the username and the Api Key as the password on every request, the same scheme Cisco documents for this API. There is no separate token exchange or login step.

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. They fall into two groups: lookup methods that only read data (safe to run freely, useful for investigation and for finding the connector_guid, group_guid or file_list_guid values the action methods need), and action methods that change something on Cisco's side.

Lookup and investigation methods

All of the following issue a GET request and do not change any AMP configuration. They are useful both for direct investigation from a playbook and for looking up the identifiers (connector_guid, group_guid, file_list_guid) that the action methods below require.

move_computer_to_a_group

Moves an endpoint into a different AMP policy group, which changes which policy (and therefore which detection/protection settings) applies to it. A common automated use is moving a compromised or suspicious host from its normal group into a stricter "Triage" or "Quarantine" group as a first-response step, ahead of or instead of full network isolation.

Unverified, read directly from the integration's source code: the request this method sends is a PATCH to /v1/groups/{connector_guid} with {"group_guid": "..."} as the body, using the endpoint's connector_guid as the path parameter under the groups resource. Cisco's own published guidance and community examples describe this operation as a PATCH to /v1/computers/{connector_guid} instead, with the same body. This is a discrepancy found by reading the code, not a live test result (no test tenant credentials were available while writing this guide). Test move_computer_to_a_group against a non-critical endpoint before relying on it in an unattended playbook rule, and if it fails, this discrepancy is the first thing to check.

put_isolation

Places the endpoint into network isolation: AMP blocks all network traffic to and from the host except its own communication with the AMP cloud, a standard first-response containment step for a suspected compromise.

This only works if the endpoint's connector supports isolation and reports isolation.available: true. Check this with get_isolations or list_computers first; not every connector OS/version supports isolation, and this has not been independently verified per platform as part of this guide.

delete_isolation

Releases a previously isolated endpoint back onto the network, reversing put_isolation.

add_sha256_to_file_list

Adds a SHA-256 file hash to an existing Simple Custom Detection list (an organization-wide blocklist). Once added, every endpoint whose policy references that list will treat any file matching the hash as malicious, which in practice blocks or quarantines it wherever it is seen across the organization, not just on one endpoint.

Because this action affects every endpoint referencing the target list, not just the one involved in the triggering incident, treat it as an organization-wide action rather than a per-host one when deciding whether to automate it unattended.

Notes and Limits

• There is no dedicated "unblock hash" or "remove from group" convenience method distinct from what is listed above. To undo a move, call move_computer_to_a_group again with the original group_guid. To undo a blocklist entry, that must be done from the AMP console itself; no remove-hash method is implemented here.
• The move_computer_to_a_group request path described above (PATCH to the groups resource using the connector_guid, rather than the computers resource) is a discrepancy identified from source code review and is not live-verified. Confirm this works against your own tenant before depending on it in production automation.
• group_guid is a required input for both put_isolation and delete_isolation in Logsign's form, but the value is not actually transmitted to Cisco as part of the isolation request; it exists only to satisfy Logsign's own input validation. This does not affect the outcome of the isolation call itself, but do not expect changing it to change which group the isolation applies against.
• Isolation availability depends on the endpoint's connector (operating system and version). Always check isolation.available (via list_computers or get_isolations) before calling put_isolation; calling it on an unsupported endpoint is expected to fail.
• Cisco enforces an hourly rate limit on this API, communicated through the X-Rate-Limit-Limit / X-Rate-Limit-Remaining / X-Rate-Limit-Reset response headers, and returns HTTP 429 when it is exceeded. A busy playbook that calls lookup methods frequently (for example list_computers or list_events on every alarm) shares this same limit with the action methods; a burst of investigation calls can leave less headroom for an isolate/move action later in the same hour.
• This is a separate API credential from the one used by the Cisco AMP log-collection poller (which only needs Read-Only scope). Rotating or revoking one does not affect the other, but keep track of which credential is which so a rotation does not accidentally break both integrations at once.
• This integration covers the endpoint/computer, group, isolation, event, audit log, and Simple Custom Detection surfaces of the AMP API. It does not cover policy creation/editing, Orbital queries, or other AMP console modules; those are out of scope for this Response integration.

Troubleshooting