Security leaders are often focused on the day-to-day functions of threat detection and response, and consistently challenged by the lack of visibility into attack surfaces and security context that current tooling and processes provide. They either don’t know where to focus their efforts or only focus on well-known attack surfaces, such as the traditional perimeter of websites, external IP addresses and endpoints.

Organizations that identify this lack of visibility internally are able to embark on the challenge of improving it by aiming to establish an attack surface management capability.

ASM is a core component of exposure management that organizations can leverage to enhance vulnerability management and validation, as well as other IT and security functions. ASM answers the big question of visibility by identifying the assets available to the enterprise and the risks associated with those assets.

Its core objectives include asset visibility and availability, security control compliance risks, and asset risk quantification.

Security leaders should seek a risk-based approach to implement a comprehensive ASM program that provides visibility into, and risk assessment of, the attack surfaces that matter to their organization. This approach often involves:

• Scope: Understanding the different attack surfaces to determine the scope of the ASM implementation, concentrating on business-focused issues rather than security issues only.
• Tooling: Applying the correct tooling, services and implementation methods to that attack surface scope.
• Process development: Developing and implementing suitable ASM processes.

Implementing tools and processes can be complex because of the various attack surfaces and technologies involved. There are four processes that organizations can use to integrate ASM into threat detection and response:

Identify

The process of managing an organization’s attack surfaces and mapping them to ASM tools will initially be overwhelming, even with a well-defined scope, as there are so many supporting and conflicting data points that can impair the process.

The key is to identify the right assets and data sources.

It is important for security leaders to evaluate telemetry sources that will help them better understand their attack surfaces. Asset sources come in two categories: Sources they control and manage regardless of how well they are run, and data their team does not manage but must ingest from other teams or public sources.

Security leaders should catalog all IT and security controls that have asset context before evaluating what to incorporate into their ASM process.

Not every organization will have access to the various data points, so it’s important to evaluate what sources to incorporate.

Remember that some attack surfaces, such as the external attack surface, will be more reliant on unmanaged data sources. This doesn’t invalidate the data, but it does raise the potential complexity of consuming and making sense of that data. Specialized ASM tooling can help organizations manage and make sense of disparate data.

Aggregate

Aggregating various data sources to get relevant context becomes more of an integration and data science exercise. Fortunately, data integration and aggregation have been addressed and implemented in many core technologies such as security information and event management, extended detection and response, IT service management, and other analytic tools.

ASM can leverage similar techniques, so establishing which vendor or technology to use will be key to success. This is where API-centric implementations will outperform proprietary ones, while homegrown implementations will struggle with different aspects of ASM aggregation.

Implementing the aggregation phase requires the following steps:

• Determine the platform that will manage the attack surface. Determining if the platform is hosted in the cloud or on-premises will have integration implications, as some sources will have integration limitations based on where the platform is hosted.
• Establish a unique asset identity. Security leaders can use an existing unique identifier from a tool or define a new one that makes sense for the organization. 
• Incorporate asset data context. Once the asset data sources are linked to a unique identifier, security leaders can aggregate and rationalize the asset context associated with different data sources. 
• Establish processes for unique challenges. Build processes to handle unique asset states, such as temporary or ephemeral assets, decommissioned assets and false positive context.

Assess risk

At this phase of ASM implementation, security leaders will already have established visibility into their assets. The next use case is assessing asset risk with the aggregated asset context.

This can be categorized into two assessments: Security compliance assessment includes identifying deficiencies in security control implementations, which can be a combination of “not implemented” and “misconfigured.”

Asset risk quantification requires quantification of risk based on the correlation of data sources.

Improve functions

ASM data can either improve asset accuracy in tools that are reliant on asset data, or improve existing processes with attack surface data. ASM can enhance functions in security operations and IT operations through exposure management and incident response.

Any well-functioning security operations center will have clear visibility into, and a thorough understanding of, its attack surfaces. Security professionals can keep these steps in mind to implement tools and techniques for improved attack surface management.