As I watched the December 2021 Log4j situation unfold, the importance of IT asset visibility couldn’t have been clearer. So many security and IT teams struggle to maintain much-needed visibility into an increasingly complex and distributed IT environment because so much of an organization’s estate is unknown or undiscovered due to shadow IT, MA, and third party/partner activity. Without adequate visibility, moving to a desired state of application and infrastructure dependency mapping (AIDM) as a technology organization is impossible. Oh, and you can’t roll out critical patches to applications and systems that you don’t know about!
Forrester defines attack surface management (ASM) as “the process of continuously discovering, identifying, inventorying, and assessing the exposures of an entity’s IT asset estate.” Your attack surface is more than what’s internet-accessible — it’s your entire environment, and there’s a tremendous opportunity to integrate the external visibility from ASM tools and processes with internal security controls, the CMDB, and other asset and tracking and management platforms to completely map all the connections and assets in an enterprise.
Adopters of ASM solutions give high praise to the increased visibility, time savings, and the ability to prioritize risks. During our research interviews, a security engineer at an EMEA-based used car marketplace added, “[Our ASM tool] found 50% more assets than we thought we had.” And one network security architect at a US-based ISP stated that “[ASM] is a must-have security control.”
We have just published research on the ASM market, the key ASM use cases, and essential ASM integration points in enterprise security programs. While several firms offer ASM as a standalone solution, we’re increasingly seeing these standalone offerings get acquired (sound familiar?) by vendors providing threat intelligence, vulnerability management, and detection and response. I believe that ASM will be a standard capability in these categories within the next 12 to 18 months. The Log4j vulnerability saw to that just as it accelerated the criticality of open source software management and SBOMs.
We lay out several recommendations in our ASM report, but I’d like to highlight that ASM should be thought of as a program enabled by a tool, not just a tool or a capability. And it should be leveraged to bring groups with conflicting priorities together. If your organization is looking to achieve a desired state of application and infrastructure dependency mapping, aligning an ASM program’s goal around greater visibility and, in turn, observability — and positioning it as a key input to that desired state — will unite security, tech, and business leaders and teams in a way that vulnerability risk management and internal patching SLAs certainly never could.
In fact, an ASM program should be a fusion or matrix organization spanning multiple stakeholders, including infrastructure and operations, application development and delivery, security, risk, compliance, privacy, marketing, social media, and other functions.
This post was written by Senior Analyst Jess Burn and it originally appeared here.