To set up Attack Surface Testing for the first time, complete the following tasks:
To set up Attack Surface Testing, you must have a role that includes edit permission for Vulnerability Testing. To check your role-based permissions go to Settings → Configurations → Access Management → Roles, and select the role. Select the Components tab, and find Vulnerability Testing under Incident Response → Detections.
The EULA gives Cortex XSIAM permission to conduct attack surface testing scans. You only need to accept the EULA once. After accepting the EULA the Vulnerability Testing Configuration page opens automatically so you can select the targets for testing.
You only need to accept the EULA once, before you enable attack surface testing for the first time.
Navigate to Detection &Threat Intel → Attack Surface → Attack Surface Testing.
On the Welcome to Vulnerability Testing page, click Next.
Read the End-User Licensing Agreement and click Accept Terms.
After accepting the terms of the EULA, the Vulnerability Testing Configuration page opens and you can select the set of services to be tested.
Attack surface testing targets are directly-discovered services, which are definitively associated with an asset that belongs to your organization. You can choose to run attack surface tests on all your relevant directly-discovered services or you can specify a subset of services.
Specify the directly-discovered services upon which Cortex XSIAM will run attack surface tests. After the initial set-up, you can update this set of targets anytime.
Navigate to Settings → Configurations → Attack Surface → Attack Surface Testing.
To select specific targets, in the Target Testing section, make sure the toggle is set to Selected Targets, and click Edit Targets (or Add Targets if this is the first time you are selecting targets.)
To select all the targets, set the toggle to All Targets. This overrides your target selection.
Use the filter to define a set of targets from your list of services.
Click Save Targets.
After you complete the set-up tasks, Cortex XSIAM begins daily attack surface testing scans. You can perform the following post-setup tasks to access attack surface test results and change your attack surface testing configuration.
Attack surface test results are displayed on the Services page in the Inventory. The following fields in the Services table enable you to search for specific vulnerabilities.
Field | Description |
|---|---|
Confirmed Vulnerabilities | CVE IDs (or other vulnerability IDs) of the vulnerabilities that have been confirmed present on the service. Search this field for a specific CVE ID to find all the services that have a confirmed vulnerability with that ID. |
Confirmed Not Vulnerable | VE IDs (or other vulnerability IDs) of the vulnerabilities that have been confirmed to be not present on the service. Search this field for a specific CVE ID to find all the services that have are confirmed not vulnerable for that vulnerability. |
Vulnerability Test Result | Confirmed Vulnerable indicates there is at least one confirmed vulnerability on the service. Filter on this field to find all services with at least one confirmed vulnerability. |
Navigate to Assets → Asset Inventory → All External Services
Filter the Services table to find the services with a specific confirmed vulnerability.
Click on the filter icon at the top of the Confirmed Vulnerability ID column, and enter the vulnerability ID in the dialog box.
Click anywhere outside the dialog box to filter.
The list of services that are confirmed to have that vulnerability will display.
Click on a row in the table to display the details panel for that service.
On the service details panel, you can review the list of tests run, test dates, whether each test produced a confirmed vulnerable or confirmed not vulnerable result, evidence, and remediation guidance.
Click the arrow to the left of each test result to display the 14-day test history and the evidence payload returned by the service.
You can configure Cortex XSIAM to automatically enable or disable new attack surface tests when they are introduced. By default Cortex XSIAM enables new attack surface tests.
Navigate to Detection &Threat Intel → Attack Surface → Attack Surface Testing.
In the New Vulnerability Tests section, select Opt-in in the toggle to enable new tests by default or Opt-out to disable new tests by default.
View information about the available attack surface tests, and enable or disable tests on the Vulnerability Testing page. By default all tests are enabled.
Navigate to Policies and Rules → Attack Surface Testing.
Filter and sort the list of tests as needed to identify the tests you want to enable or disable.
Select one or more tests using the check boxes, and right click to Enable or Disable them.
Field
Description
Affected Software
Software names and versions impacted by this vulnerability.
CWE IDs
Common Weakness Enumeration ID as defined by MITRE.
Created
When Cortex XSIAM released this test.
EPSS Score Description
The Exploit Prediction Scoring System (EPSS) score indicates the likelihood that a vulnerability will be exploited in the wild. Possible values are 0 -100%.the higher the score, the greater the probability that a vulnerability will be exploited.
References
Research references and supporting documentation.
Remediation Guidance
Recommended steps for remediating or mitigating the vulnerability.
Severity Score
The CVE severity score is based on the NIST Common Vulnerability Scoring System (CVSS).
Services Found Vulnerable
The number of directly-discovered services owned by your organization that Cortex XSIAM has confirmed vulnerable with this test.
Status
Indicates whether the test is Enabled or Disabled.
Vendor Names
Name of the vendor whose product is impacted by the vulnerability.
Vulnerability IDs
CVE number or other public identifier for the vulnerability.
To view the IP address range Cortex XSIAM uses for vulnerability tests, navigate to Detection &Threat Intel → Attack Surface → Attack Surface Testing and refer to the Source IP Addresses section. We recommend adding this range to your organization's security tooling allow lists to avoid unnecessary alerting; however, we do not recommend modifying the configuration of your perimeter security controls to allow this traffic to pass. The aim of Attack Surface Testing is to confirm the exploitability of vulnerabilities from an attacker perspective.