Attack Surface Rules - User Guide - 2 - Cortex XPANSE - Cortex - Security Operations

Cortex Xpanse Expander User Guide
Product
Cortex XPANSE
Version
2
Creation date
2024-03-28
Last date published
2024-04-17
Category
User Guide
Solution
Cloud
Abstract

Cortex Xpanse attack surface rules can be customized for your organization's specific needs and priorities.

An attack surface rule is a definition managed by Cortex Xpanse that is used to identify risks in an attack surface. It defines what Xpanse is looking for and the associated risk. Xpanse creates an alert when it detects an instance of that rule. For example, Insecure Apache Web Server could be a rule that looks for any instances of Apache with a detected version earlier than 2.30.1, so if Xpanse sees any services that are running an earlier version, Xpanse creates a new alert.

The Attack Surface Rules page (Rules → Attack Surface Rules) displays a table view of all the attack surface rules along with key information about each rule. The following table describes each field.

Field

Description

ASM Alert Categories

A categorization done by the Xpanse security research team often with input from customers or in reference to published materials such the the BOD-22-01 or BOD-23-02 from CISA.

Description

Description of what the attack surface rule is looking for.

Estimated Alert Count

Estimated number of alerts that Xpanse will create if this attack surface rule is enabled.

Has Remediation Rule

Indicates whether a remediation path rule has been created for this attack surface rule.

Applies only to systems with the Active Response addon module.

Modified

Date of the most recent update to the attack surface rule.

Remediation Guidance

Guidance on how to remediate or mitigate the alerts created by this attack surface rule.

Rule ID

ID for this attack surface rule.

Rule Name

Name of the attack surface rule.

Severity

Severity of the risk identified by the attack surface rule. Alerts are created with the same severity as the attack surface rule that triggered them. See Default Attack Surface Rule Severity for default severity settings.

Status

Enabled or Disabled. An enabled attack surface rule creates an alert when it detects an instance of that rule. See Default Attack Surface Rule Enablement Status for details about the default enablement status.

There are over 700 attack surface rules, with new rules added frequently. To identify new and recently modified attack surface rules, sort the Attack Surface Rules table by the Modified column.

To request a new attack surface rule, contact your Customer Success representative.

Manage Attack Surface Rules

On the Attack Surface Rules page you can enable or disable rules and change the severity to align with your organization’s specific needs and priorities.

  1. Navigate to Rules → Attack Surface Rules.

  2. Select one or more rules and right-click to perform one of the following actions:

    • Enable or Disable the rule—Some rules are enabled by default, but many are designed to be opt-in.

    • Change the default Severity of the rule—All attack surface rules have a predefined default Severity setting of Low, Medium, or High. Critical is never a predefined default, but you can set it as the default.

When you first enable an attack surface rule, you can expect to see new alerts within 24 hours if any instances of that rule are detected on your attack surface.

Default Attack Surface Rule Severity

The Xpanse security research team determines the default severity setting for an Attack Surface Rule based on a number of details. Xpanse may adjust the severity level when new threat information becomes available. Changes to the default severity will never override any changes you make to a rule’s severity.

Default Severity

Description

Critical

None of the attack surface rules are rated as Critical by default. This severity is reserved for customers to elevate the attack surface rules or individual issues they deem critical for their organization.

High

High severity rules identify risks that most of our customers would consider important to remediate in a timely manner. This primarily includes known insecure versions of software with published high or critical severity CVEs and external services that are inherently risky to expose directly on the internet.

For example:

  • A known-insecure version of software with a known high-score CVE. These may include CVEs with weaponized exploits.

  • Devices and services that are inherently risky to be exposed to the public internet (RDP, building control systems, databases, etc). These are often targets for opportunistic attackers who are scanning the internet and can use brute force or use other tactics to gain access to an organization’s systems.

Medium

Medium severity rules identify risks that we believe some customers would consider important to remediate, but may not be important to everyone.

For example:

  • A service type with known vulnerabilities that could reasonably be expected to be publicly visible on the internet but where we cannot infer insecure versions with high confidence.

  • A service that may or may not be expected to be publicly visible on the internet

  • Something that an organization may or may not be expected to remediate (e.g. Certificate expiring in 30 days).

Low

Low severity rules are unlikely to be consequential to the majority of our customers. These include the following types of issues:

  • Services that could be expected to be exposed to the internet, but where the attack surface rule will not exclusively surface vulnerable instances (in these cases, they may be paired with a higher priority "insecure" version of the rule for known vulnerable instances).

  • Services that could be of interest but pose minimal attack surface risk. Attack surface rules that capture these services exist primarily for visibility purposes.

  • Low-signal findings where reliably detecting the service is considered low confidence. Attack surface rules where the impact of exposure is high but the detection signal is low are also classified as Low severity.

Default Attack Surface Rule Enablement Status

Attack surface rules are Enabled or Disabled by default. You can change the enablement status for a rule or set of rules at any time.

If a rule is made available to only a select set of customers (typically due to customer request), Xpanse will set the rule to Enabled by default, regardless of the severity.

In general, most attack surface rules are defaulted to Disabled unless they are associated with trending threat events within the Threat Response Center (TRC). This approach ensures that customers stay in control of their overall risk assessment. We encourage customers to routinely review the attack surface rules and Enable them so they begin generating alerts.

The internal Xpanse decision to set a rule to Enabled weighs the likelihood of generating numerous alerts that may not be relevant to all customers versus the risk of a customer missing something important to them.