Attack Surface Management: From Passive Scanning to Active Security Testing

Traditionally, approaches to Attack Surface Management (ASM) went something like this: A business scanned its own IT estate to discover assets and understand what its attack surface actually included. We can think of this as Phase I.

Following the completion of an asset inventory, they assessed each of their assets to identify risks and vulnerabilities, such as open ports, certificate issues, DNS misconfigurations, and more. If a risk was detected, an alert would be created and forwarded along to the party responsible for fixing it. This would be Phase II.

Relying on Phases I and II exclusively worked in a world where passive observation of security issues was enough to warrant an alert. But now, security teams are overwhelmed with alerts, and more context is needed to justify generating an alert for an already overloaded team.

To give a specific example, many organizations are using thousands of software products and the CVE volume is through the roof– so which ones need to be prioritized and remediated first? As CSO Online notes, “The growing attack surface is extending the security/software developer gap, increasing vulnerabilities, and slowing security investigations.” It’s not helpful to simply issue an alert every time unpatched software with a known CVE is detected.

In light of these new challenges, ASM must now go a step further: ASM needs to move from passive to active. In this new stage, which we can call Phase III, the ASM tool uses advanced automation to attempt exploitation of CVEs and other common security issues, which surfaces the most critical risks in an organization’s external attack surface.

The three phases of Attack Surface Management

The historical evolution of ASM involves three basic phases of phases:

• Phase 1 – mapping: The first phase focused on discovering the attack surface by scanning IT resources and using public data sources, such as DNS records, WHOIS data, SSL/TLS certificates, and other metadata. The goal was to discover the full extent of the attack surface– including shadow IT assets that were not known to the security team– and creating a complete inventory of all the assets that you needed to defend.
• Phase 2 – assessment: Going a bit further, the next phase of ASM centered on more sophisticated exposure assessment. In addition to looking for risks like shadow IT, you also identified security issues with the assets on the inventory. This could be DNS misconfigurations, outdated encryption protocols, open ports, or unpatched software with known CVEs.
• Phase 3 – active security testing: phase 3 takes risk assessment to the next level by determining whether detected issues are actually exploitable. In other words, it doesn’t simply generate lists of passively-observed risks; it tells you which risks can actually be exploited by threat actors to breach your organization.

The importance of active security testing in ASM

The main reason why phase 3 Attack Surface Management is so crucial is simple: Due to the scope and complexity of modern IT estates, businesses are often inundated with alerts about CVEs in the software running on their assets.

Responding to each and every one is not practical. Instead, teams need to be able to determine which risks translate to actual threats, as well as how severe each threat is.

This active testing concept aligns with the practice that Gartner has labeled stage 4. Validation of Continuous Threat and Exposure Management (CTEM) – meaning the continuous, real-time assessment of threats and exposures to identify which ones require a response.

This is where active security testing and CVE prioritization come in. Through practices like automatically simulating the exploitation of known CVEs or mimicking attacks such as credential stuffing, SQL injection and path traversal, teams can detect in real time which of the vulnerabilities within their attack surfaces are actually exploitable by threat actors. Thereby vulnerability alerts are validated in order to prioritize the ones that put organizations most at risk.

Why conventional CVE prioritization is not enough

At this point, you may be thinking: “My team already prioritizes CVEs based on severity ratings, so why do we need CTEM and active security testing?”

The answer is that conventional approaches to CVE prioritization – which rely on techniques like examining software versions to determine whether a particular installation is vulnerability, as well as ranking vulnerabilities based on CVSS scores in CVE databases – don’t go far enough because they don’t tell you whether or how easy it is to exploit a particular vulnerability within your particular environment.

To get that level of insight, you need active security testing. You need, in other words, to simulate actual attacks. This is the best way – when used alongside threat intelligence and the EPSS scoring system – to collect highly accurate, highly relevant data about where your greatest risks and threats lie.

It’s also an essential step for any effective CTEM program. Continuously assessing threats and exposures is significantly boosted by actively scanning for and testing vulnerabilities, as opposed to more traditional methods of CVE prioritization. While threat intelligence and EPSS scoring are extremely useful, they don’t actively attempt exploitation. Active exploitation prioritizes CVE alerts by identifying if the necessary environmental conditions for exploitation are present and deprioritizing those that do not meet the criteria.

The role of active exposure scans in ASM prioritization lists

To illustrate what active security testing and scanning means in practice, consider how a solution like Cyberint’s Active Exposure Validation (AEV) capability extends beyond typical CVE detection and prioritization techniques.

Cyberint’s (now a Check Point Company) Active Exposure Validation performs automated tests to uncover common security issues in your organization’s digital assets that fall outside the scope of a vulnerability database. It provides alerts on risks that don’t have an assigned CVE number, such as vulnerabilities in your organization’s own web applications.

Identifying unknown risks

Note, too, that active security testing and AEV aren’t merely about evaluating the risk level of known CVEs. They also help you discover vulnerabilities that traditional vulnerability detection techniques would miss.

AEV performs automated tests to uncover common security issues in your organization’s digital assets that fall outside the scope of a vulnerability database. It provides alerts on risks that don’t have an assigned CVE number, such as vulnerabilities in your organization’s own web applications, which are used exclusively by your customers.

For example, a major vulnerability in a hospital’s natively-developed patient management system would primarily affect the hospital and its patients, but wouldn’t typically be assigned a CVE. After all, exploitation of a vulnerability in that system would only affect the organization that developed it (in this case, the hospital) but no other third-party organizations would be impacted. The patients’ data could be exposed but they are implicitly trusting the hospital to safeguard their data when they make a decision to use them as a healthcare provider.

AEV tests your web apps for common security issues that could harm you, but not necessarily other third-party companies. These issues could lead to major security risks for your organization and potentially your clients and customers too, so it’s crucial you know about them.

Choosing an ASM solution with active exposure validation

For these reasons, it’s no longer enough to settle for ASM solutions that merely discover assets and list generic risks based on known CVEs. You need ASM tools and capabilities (like Cyberint, now a Check Point Company’s AEV) that can also scan and actively test your resources and applications on a continuous basis and provide real-time insight into which vulnerabilities are ripe for exploitation.

Learn more about how Cyberint takes ASM to the next level by requesting a demo.