Attack surface rules - Attack surface rules are used to identify risks in your attack surface. - Administrator Guide

Attack surface rules - Attack surface rules are used to identify risks in your attack surface. - Administrator Guide - Cortex CLOUD

Cortex Cloud Posture Management Documentation

Product

Cortex Cloud Application Security > Cortex CLOUD

License

Cloud Posture Management

Creation date

2025-01-22

Last date published

2026-06-10

Category

Administrator Guide

Abstract

Attack surface rules are used to identify risks in your attack surface.

An attack surface rule is a definition managed by Cortex Cloud that identifies risks on a customer's attack surface. Attack Surface Rules match on ASM global scan results to detect exposed or misconfigured customer-owned assets. When an attack surface rule is enabled, Cortex Cloud will generate findings as well as issues for observations that match that rule.

To view attack surface rules, navigate to Modules → Attack Surface → Policies → Attack Surface Rules.

The following table describes each field in the Attack Surface Rules table.

Field	Description
ASM Alert Categories	A categorization done by the Cortex Cloud 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. Issues 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 issue when it detects an instance of that rule. See Default attack surface rule enablement status for details about the default enablement status.

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.

Navigate to Modules → Attack Surface → Policies → Attack Surface Rules.
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 findings within 24 hours if any instances of that rule are detected on your attack surface. When you disable an attack surface rule, Cortex Cloud will stop creating new issues for that rule, but any existing open issues will remain open until you change the status.

Default attack surface rule severity

The Cortex security research team determines the default severity setting for an attack surface rule based on a number of details. We may adjust the default severity 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 organizations 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 organizations 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. a certificate expiring in 30 days).
Low	Low severity rules are unlikely to be consequential to most organizations. These include the following types of risks: 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), we will set the rule to enabled by default, regardless of the severity.

In general, most attack surface rules are disabled by default. This approach ensures that customers stay in control of their overall risk assessment. We encourage you to routinely review the attack surface rules and Enable them so they begin generating issues.

The internal Cortex decision to enable a rule by default weighs the likelihood of generating numerous issues that may not be relevant to all customers versus the risk of a customer missing something important to them.

Attack surface rule deprecation

Cortex Cloud is committed to providing the most accurate attack surface rules. Our security research team continuously reviews and refines the attack surface rules to ensure that our rules effectively reflect the evolving threat landscape and new technologies. When a rule is marked as "deprecated" in Cortex Cloud, it signifies that the rule is no longer recommended for active use by customers and is slated for eventual removal from the platform. A deprecated rule will continue to function for a transitional period, but deprecation indicates an important update in our recommended best practices and upcoming rule enhancements.