Attack surface tests - Attack surface tests are designed to minimize the potential impact to scanned and tested services. - Administrator Guide - Cortex XSIAM - Cortex - Security Operations

Cortex XSIAM Documentation

Product
Cortex XSIAM
Creation date
2024-03-06
Last date published
2025-12-14
Category
Administrator Guide
Abstract

Attack surface tests are designed to minimize the potential impact to scanned and tested services.

Cortex XSIAM has an extensive set of attack surface tests for CVEs and other risks that affect externally-facing services and can be confirmed with controlled testing. Our attack surface testing is layered on top of our existing attack surface management (ASM) global scanning infrastructure, which distributes requests across a broad time range to minimize the impact to scanned and tested services.

We perform external scans only, which means we only test directly-discovered services accessible from the public internet and that you selected for testing. To further decrease test load and the possibility of impacting a service, we map attack surface tests to service classifications, enabling us to run tests only on the relevant services in your approved set of targets. For example, we only run Apache attack surface tests against your Apache services.

Note

Attack surface testing scans are typically not CFAA compliant, meaning that they may attempt more extensive fuzzing to confirm or deny the presence of a CVE. Additionally, some attack surface tests are more intrusive than others. Tests are labeled with the level of intrusiveness, so you can decide whether to run more intrusive tests.

New attack surface tests are added at the discretion of the Cortex XSIAM Security Research Team when new vulnerabilities are announced.

Attack surface tests for default credentials

Attack Surface Testing does not perform authenticated tests; however, we do have attack surface tests focused on the detection of applications that are using manufacturer default credentials. These attack surface tests attempt to log in to specific business operations systems, IT, and networking devices with default credentials, but don't perform any operations if login is successful and will never change the state or configuration of a tested service.

You can identify attack surface tests for default credentials by looking at the test Name field, which typically includes Default Credentials , and the Vulnerability ID field, which uses the prefix DEFAULT-CRED-.