Automated Remediation Capabilities Matrix

Learn about the specific ASM automated remediation and enrichment capabilities and criteria.

This document describes the Active Response fully automated remediation and enrichment coverage for attack surface alerts discovered by Cortex Xpanse.

The following definitions are used:

Attack Surface Rule—The Attack Surface Rule that triggered the creation of an alert.
Automated Remediation Method—The method Cortex Xpanse uses to automatically remediate or rectify an attack surface alert.
Automated Remediation Criteria—The conditions that must be met for the automated remediation options to be available for execution.

This document contains the following information:

Automated remediation options and criteria

The table below lists the fully automated remediation options that are currently available with Active Response, including the remediation methods, relevant attack surface rules, and automated remediation criteria.

Attack Surface Rule

Automated Remediation Method

Automated Remediation Criteria

Elasticsearch
Insecure Bitvise SSH Server
Insecure OpenSSH
Insecure SFTPGo
Kubernetes ControlPlane Component
LDAP Server
Libssh
MongoDB Server
MySQL Server
Netbios Name Server
Nfs Rpcbind Server
OpenSSH
Postgres Server
RDP Server
Rpcbind Server
Smb Server
SNMP Server
SSH Server
SSH Terrapin Attack
Telnet
TFTP Server
Unencrypted FTP Server

Restrict port access

1. Service must be running on an AWS EC2 instance, Google GCE instance, or Azure VM on an account that has been configured with read/write access. Additionally, we can support On Prem assets that are managed with Palo Alto Networks Firewalls.

2. At least one potential service owner must have been discovered.

3. The associated service or asset must be a non-production instance. This is determined by either:

1. A tag on the associated asset that is indicative of being a development server, from a CSP or VM integration. Development servers have no external users and run no production workflows. These servers may be tagged “dev” or other non-production terms like “pre-production”, “user acceptance testing”, or “qa”.

2. Xpanse attributing the “Development Environment” service classification to the associated service using purely public information.

This can be disabled by setting the BypassDevCheck playbook input.

4. A tag on the associated asset that is indicative of being a development server, from a CSP or VM integration. Development servers have no external users and run no production workflows. These servers may be tagged “dev” or other non-production terms like “pre-production”, “user acceptance testing”, or “qa”.

5. Xpanse attributing the “Development Environment” service classification to the associated service using purely public information.

This can be disabled by setting the BypassDevCheck playbook input.

Insecure OpenSSH

Patching vulnerable software

1. Service must be running on an AWS EC2 instance.

2. Attack surface rule ID has to be Insecure OpenSSH.

3. AWS EC2 of platform type Linux Ubuntu.

4. AWS SSM agent is active.

5. At least one potential service owner must have been discovered.

6. The associated service or asset must be a non-production instance. This is determined by either:

A tag on the associated asset that is indicative of being a development server, from a CSP or VM integration. Development servers have no external users and run no production workflows. These servers may be tagged “dev” or other non-production terms like “pre-production”, “user acceptance testing”, or “qa”.
Xpanse attributes the “Development Environment” service classification to the associated service using purely public information.
- This can be disabled by setting the BypassDevCheck playbook input.

Elasticsearch
Insecure Bitvise SSH Server
Insecure OpenSSH
Insecure SFTPGo
Kubernetes ControlPlane Component
LDAP Server
Libssh
MongoDB Server
MySQL Server
Netbios Name Server
Nfs Rpcbind Server
OpenSSH
Postgres Server
RDP Server
Rpcbind Server
Smb Server
SNMP Server
SSH Server
SSH Terrapin Attack
Telnet
TFTP Server
Unencrypted FTP Server

Isolate endpoint from the network

1. Service must NOT be running on an AWS EC2 instance, Google GCE instance, Azure Compute VM, or managed On-Premise with Palo Alto Networks Firewalls.

2. The asset must be managed by Cortex XSIAM Endpoint Security or Cortex XDR Prevent or Pro.

3. At least one potential service owner must have been discovered.

4. The associated service or asset must be a non-production instance. This is determined by either:

A tag on the associated asset that is indicative of being a development server, from a CSP or VM integration. Development servers have no external users and run no production workflows. These servers may be tagged “dev” or other non-production terms like “pre-production”, “user acceptance testing”, or “qa”.
Xpanse attributes the “Development Environment” service classification to the associated service using purely public information.
- This can be disabled by setting the BypassDevCheck playbook input.

Unclaimed S3 Bucket

Placeholder S3 Bucket Created

The AWS S3 integration has been configured with read/write access.

Automated Remediation Methods

The table below provides details about each of the Active Response fully automated remediation methods.

Automated Remediation Method

Details

Restrict Port Access

This method varies based on the available control surface and the asset associated with the alert.

AWS
EC2: Replaces the security group that is allowing the risky service to be exposed to the public internet with a new security group that only allows access via an internal network. See additional playbook details here.
Google Cloud
GCE: The remediation steps for risks exposed on Google Cloud GCE operate by tagging the GCE instance with a network tag referencing two new firewall rules—one to allow internal traffic to the exposed port and the other to block the port from internet access. The new firewall rules follow this naming convention remediation-<allow

Isolate Endpoint from the Network

This method is available when the requirements for the Restrict Port Access method have not been met and the asset associated with the alert has a Cortex XDR or XSIAM endpoint security agent.

Note

This remediation method operates by isolating the asset that is exposed to the public internet and halting all network access on the endpoint except for traffic to Cortex XSIAM or XDR. See additional playbook details here.

Patch vulnerable software

This method is available when the AWS Systems Manager agent is active, platform requirements (Ubuntu) are met and for attack surface Insecure OpenSSH.

The remediation is applied by upgrading the existing vulnerable Insecure OpenSSH software to a newer, patchable version.

Create placeholder S3 Bucket

This method is used solely for remediating Unclaimed S3 Bucket alerts.

These alerts are resolved by creating an empty S3 bucket with no external access that matches the organization’s undefined DNS CNAME record. See additional playbook details here.

Supported Automation Integrations

The table below lists the supported Active Response automation integrations, the possible enrichment values for each integration, and the permission requirements.

Integration Name

Active response templates

The table below describes the default format and wording for emails and tickets created by Cortex Xpanse for ASM alerts. To create custom emails and tickets, see Playbook Configuration.

Field

Value

Notification Email Subject

A new security risk was identified on an external service owned by your team

Notification Email Body HTML

Infosec identified a security risk on an external service potentially owned by your team:

${alert.details} Remediation Guidance: ${Remediation Guidance}

Remediation Notification Email Subject

A new security risk was addressed on an external service owned by your team

Remediation Notification Email Body HTML

<!DOCTYPE html> <html lang="en"> <body> Infosec identified a security risk on an external service potentially owned by your team: ${alert.name} Alert Details: ${alert.details} Action Taken: ${alert.asmremediation.[0].Action} Action Outcome: ${alert.asmremediation.[0].Outcome} </body> </html>

ServiceNow Incident Title

Cortex ASM Alert:

${alert.name}

ServiceNow Incident Description

Infosec identified a security risk on an external service potentially owned by your team:

${alert.name} 

Description:

${alert.details} Remediation Guidance: ${Remediation Guidance}

PreviousTroubleshoot Active Response NextActive Response FAQ

Last updated 26 days ago

Was this helpful?