> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xpanse/attack-surface-rules.md). # Attack surface rules 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. When you disable an attack surface rule, Cortex Xpanse will stop creating new alerts based on that rule, but any existing open alerts will remain open until you change the status. ## 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	Critical severity is used for the highest priority findings, such as validated discovery of publicly accessible, exploitable vulnerabilities with business impact. For example: Some attack surface rules that generate alerts from positive attack surface test results are critical by default.
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. ## Attack surface rule deprecation Cortex Xpanse 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 Xpanse, 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xpanse/attack-surface-rules.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.