Dealing with the Attack Surface Beyond Vulnerabilities

A good understanding of the attack surface is of prime importance in measuring and prioritizing risk. Here's how Tenable's data can allow security professionals to have a more realistic view of their exposure.

Standardized taxonomies have dominated the way cybersecurity professionals describe and talk about systems' security. Common Vulnerabilities and Exposures (CVE) severity scores have become the primary methods of measuring the security of a system and its attack surface. We believe a focus on CVEs and severity ratings fails to account for all the services, ports, and features in a system that remains broadly open to attack, as well as any future potential attack opportunities.

Reducing the exposure and attack surface of an environment involves not only patching relevant vulnerabilities but also being aware of the features of the environment. This broadly translates into running services and their configurations, and then hardening or turning them off if necessary, to reduce the chances of them becoming an attack vector. Measuring the attack surface is also particularly useful when trying to answer questions about the level of exposure of two states of a given environment over time.

In addition to enriched vulnerability data using threat intelligence, security professionals need wider visibility beyond vulnerability IDs and their scores, to include other critical aspects of the system that an attacker will attempt to compromise. Tenable's wide range of findings enables a more accurate representation of the attack surface, and related risk to the environment that cannot be expressed by vulnerabilities alone. This blog post explains what defines an attack surface and presents an example of how Tenable's data allows security professionals to have a more realistic view of their exposure.

What is an Attack Surface?

Most descriptions of the attack surface come down to defining those properties of the system which are most likely to be of potential interest to an attacker, counting what is countable, and then potentially mapping to the defensive measures most likely to minimize it. The phrase was introduced by Michael Howard in an MSDN Magazine article in 2003 in which he calculated the relative attack surface of different versions of the Windows operating system and discussed why users should install only the needed features of a product in order to reduce the amount of code left open to future attack. 

The properties of the attack surface are generally considered within a set of dimensions or themes. These represent the focus and interpretation under which the attack surface is measured. For instance, in the 2011 paper An Attack Surface Metric, the authors measured what they called the system's attackability, i.e., the likelihood of the system being successfully attacked, along three dimensions: method, channel, and data. The attack surface measurement would require the identification of the set of entry points and exit points (internal and external methods), the set of open communication channels, and the set of data items that the attacker can send into or receive from the system.

There are a variety of other definitions and interpretations of the attack surface. In the 2018 paper Attack surface definitions: A systematic literature review, the authors carried out a systematic literature review (SLR) on the use of the phrase “attack surface.” In addition to a sampling of some of the existing definitions, they identified six themes representing all of the interpretations of the attack surface in the literature; which are:

• methods; 

• adversaries;

• flows;

• features;

• barriers; and 

• reachable vulnerabilities. 


The theme of 'reachable vulnerabilities,' which focuses on the exposure associated with known vulnerabilities attackers can exploit in a system, dominates the way security professionals describe the security of their environments. The SLR study found, however, that the 'methods' and 'adversaries' themes are the most prevalent in the literature, while the 'vulnerabilities' theme is one of the least cited, along with the 'barriers' theme, which focuses on the security controls an attacker must overcome to breach a system.

Despite the different ways to reason about and measure the attack surface, what is constant in all studies is the way the community thinks about it; i.e., in terms of attack opportunities. Ultimately, the attack surface is best thought of as the nexus of those resources or features within a system — along any of the aforementioned dimensions — which can be seen as both potentially benefiting users and, conversely, aiding attackers, combined with their reachability or relevance to the environment in question. The next section will discuss the importance of non-CVE data produced by Tenable, and how it can help in reasoning about the attack surface.

Attack vectors

Cyberthreats do not rely solely on software vulnerabilities. There are many additional attack vectors that are merely features of the system but can lead to a breach through further enumeration, data leaks, errors (in configuration or human errors), etc. For instance, according to the 2020 Verizon Data Breach Investigations Report (DBIR), two-thirds of breaches featured either hacking or error actions, and 80 percent of hacking actions involve either stolen passwords or brute-forcing. Exploitation of vulnerabilities (within malware and hacking actions) had a lower prevalence, and it's on a downward trend according to DBIR data (in both the 2020 and the 2021 reports). Using incident data as a proxy, and mapping Tenable's findings into threat actions and attack vectors, help defenders with their risk calculation and provides clearer insight of their exposure and attack surface.

Incident and breach actions would highlight the exposure of specific services, e.g., a brute-force attack would be linked to remote login services, or any other service or API exposed to potential credentials/key attack. Such services are also open to attack in case of future (still undiscovered) vulnerabilities and weaknesses, and can facilitate the attacker's post-exploitation activities. They are possible attack points and should be part of the attack surface measurement regardless of their current vulnerability status. Table 1, below, presents examples of features that are found in environments across the board, which constitute potential attack vectors. 

An example of incident data is the VERIS community database (VCDB), which is an effort to capture security incidents that are publicly disclosed and shared by the community. It is based on the VERIS framework, which is a set of metrics designed to provide a common language for describing security incidents in a structured and repeatable manner.

Table 1. Example of system data relevant in measuring the attack surface.

Source: Tenable, May 2021.

Measuring an attack surface

Most security operations teams use labeling of alerts and incidents. This might be  based on metrics similar to the ones used in the VERIS framework, in order to create better insight or help with automation. Context around the incident — especially answering the question "what action affected the asset?" — is what helps in risk calculation by deducing the prevalence of the threat action and associated attack vector. Each attack vector will then have a weight. For instance, based on the global prevalence noted in both the 2020 and 2021 DBIR, we can presume that externally exposed services would have a high weight in the attack surface calculation given the prevalence of brute-forcing and the use of leaked credentials. 

The mapping of all findings, including the broader functionality found on the system, into threat actions present in incident reports, provides a more accurate measurement of risk than if we consider only vulnerabilities. This is also important in the identification of the different parts of the system that need prioritized mitigation or further protection. The overall measure of the attack surface can be a simple weighted sum, where the weight (based on the prevalence) is multiplied by a simple count of the features of the system exposed to the attack vector.

Example of how Tenable data can be used to measure the attack surface

The following example of measuring the attack surface is based on an analysis of anonymized aggregated data from 20 environments and considers four attack vectors (see Table 2). 

Each attack vector shown below is associated with activity identified around a set of Tenable plugins. For example, hits from plugins associated with a VNC service are linked to the first attack vector (remote login services). Each attack vector is given a weight. Both incident data and the severity of the risk scenario can be used to deduce the attack vector weight. For instance, remote login services will have the highest weight given that it is a primary candidate for attack. Note that the weights have been set manually for this example and can be changed, along with the attack vectors, if the incident/breach data shows that certain vectors are more relevant than others within a given environment. 

Table 2. Example attack vectors and possible threat actions.

Source: Tenable, May 2021.

Figure 1. Absolute attack surface.

Figure 2. Normalized attack surface — by the number of considered assets.

Source: Tenable, May 2021.

Conclusion

To achieve meaningful and practical risk and security measurement, it's essential to take into account knowledge from the attacker landscape as well as the defender landscape. While standardized taxonomies provide a useful way for presenting and sharing information, they provide little flexibility, making it difficult to achieve a complete view of all aspects of a system an attacker could attempt to compromise. 

We believe it's important for cybersecurity professionals to rethink how the attack surface is defined. In addition to considering the impact of known vulnerabilities, defenders also need to take a wider view of all possible attack points and use a data-driven approach to measuring the importance of each one within their environments to improve prioritization of remediation efforts and reduce cyber risk. 

Learn more

• View the webinar It May Be Time to Stop Freaking Out About Too Many Vulnerabilities
• Read Tenable's 2021 Vulnerability Intelligence Report
• Download Tenable's 2020 Threat Landscape Retrospective