As I looked at December 2021 log4j situation developed, the importance of IT asset visibility could not have been clearer. Many IT and security teams struggle to maintain much-needed visibility in an increasingly complex and distributed IT environment because much of an organization’s assets remain unknown or undiscovered due to shadow IT, mergers, and acquisitions. and the activity of third parties/partners. 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 deploy critical patches to apps and systems you don’t know about!
This is where attack surface management comes in.
Forrester defines attack surface management (ASM) as “the process of continually discovering, identifying, inventorying, and evaluating exposures from an entity’s IT asset estate.” Your attack surface is more than what’s accessible over the Internet: it’s your entire environment, and there’s a great opportunity to integrate the external visibility of ASM tools and processes with internal security controls, the CMDB, and other security platforms. asset tracking and management to map all connections and assets in a company.
Adopters of ASM solutions praise the increased visibility, time savings, and ability to prioritize risks. During our investigative interviews, a safety engineer in an EMEA-based used car market added: “[Our ASM tool] we found 50% more assets than we thought we had.” And a network security architect at a US-based ISP stated that “[ASM] It’s an essential security check.”
Where is the ASM market headed?
We’ve just published research on the ASM market, key ASM use cases, and essential integration points for ASM in enterprise security programs. While several companies offer ASM as a standalone solution, we are increasingly seeing these standalone offerings being purchased (sounds familiar?) by vendors that provide threat intelligence, vulnerability management, and detection and response. I think ASM will be a standard capability in these categories within the next 12-18 months. The Log4j vulnerability took care of that just as it throttled the criticality of open source software management and SBOM.
Get together, right now, about ASM
We made several recommendations in our ASM report, but I’d like to stress that ASM should be viewed as a tool-enabled program, not just a tool or a capability. And it should be used to bring together groups with conflicting priorities. If your organization is looking to achieve a desired state of application and infrastructure dependency mapping, align the goal of an ASM program around increased visibility and, in turn, observability — and position it as a key gateway to that desired state — will bring security, technology, and business leaders and teams together in a way that vulnerability risk management and internal patch SLAs certainly never could.
In fact, an ASM program should be a parent or merger organization that encompasses multiple stakeholders, including infrastructure and operations, application development and delivery, security, risk, compliance, privacy, marketing, social networks and other functions.
This post was written by Senior Analyst Jess Burn and originally appeared here.