Welcome to Part II of our Zero Trust blog series. If you haven’t had a chance to read Part I on the origins of Zero Trust, you can check it out here.
Why did I spend all of those words in my first post detailing a history of a seemingly unrelated framework of Zero Trust? I’m glad you asked. To get there, we need to dial into what precipitated the need for Attack Surface Management in the first place.
Though it likely originated at some point before this resource, the first mention I could locate of the term attack surface was referenced in a document called ‘Attack Surface Analysis Cheat Sheet’ dating back to July of 2013. This article specifically calls out that “the focus here is on protecting an application from external attack,” and goes on to mention that the “point of Attack Surface Analysis is to understand the risk areas in an application…and to notice when and how the Attack Surface changes and what this means from a risk perspective.” Unsurprisingly, this overlaps with much of the content coming out of the Open Web Application Security Project (OWASP) community around this time and since. The current version of this document can be located here.
Without unpacking all of the content in the above 2013 cheat sheet, this first conceptual model of attack surface focuses strictly on applications while remaining sufficiently broad as to encapsulate other points where an attacker could gain entry to a system. The authors specifically call out that “Attack Surface Analysis is usually done by security architects and pen testers.” What is the goal? Pen testers are going after any and every asset they can locate when probing an organization’s security perimeter (within their scope). Servers host running applications, and knowing a.) that these servers are running, and b.) what’s running on these servers is widely regarded as one of the first steps to securing an organization. Yet, as has been proven again and again, organizations don’t always know what is operating on their ever-extending and evaporating perimeters.
The many interpretations of Attack Surface Management
As with many security tools, someone saw an opportunity to automate and build out solutions to solve the challenge of maintaining a complex hardware and software inventory. Some companies expanded their offerings (RiskIQ) and others like CyCognito (2017) were founded to begin to focus more specifically on highlighting what attackers running recon on organizations from the open internet would see. Despite this, by July 2017 through December of 2018 this article was curated and published in the Information and Software Technology Journal Volume 104 analyzing 644 prior works which used the term ‘attack surface’ and noted: “71% of the papers used the phrase without defining it or citing another paper. Additionally, we found six themes of definitions for the phrase `attack surface.’” Their conclusion was that practitioners should “choose a definition of attack surface appropriate for their domain.”
According to the above researchers, the six themes that had developed under the attack surface umbrella by late 2018 were: Methods, Adversaries, Flows, Features, Barriers, and Reachable Vulnerabilities. For a term intentionally coined to encompass many aspects of vulnerabilities, it’s not surprising many solutions would develop nuanced takes on how to tackle the issue. Adding to the challenge, any time an emerging category comes to bear in a market, there is inevitably a lot of confusion. It’s a knife fight out there between companies vying for every tiny piece of attention they can get — and if there’s the slimmest chance the latest trending hashtag applies to what their product can do, it gets ‘bandwagoned’ onto from every possible angle. So, as the terms ‘attack surface’ and ‘Attack Surface Management’ began to become more popular, more companies began to attach themselves to the ASM category to some degree. This happened (and still happens to an extent) in the Zero Trust world, and is absolutely happening now with respect to the Attack Surface Management category.
Googling “what is attack surface management” today returns a generally consistent response that has consolidated around the original ‘Cheat Sheet’ article referenced above. The themes focus on the scanning of known assets, the discovery of unknown assets, internal vs. external-facing asset scanning and/or discovery, and continuous monitoring of these assets— all with a strong emphasis on exploitable vulnerabilities.
Parallels to Zero Trust emerge
However, though there is a broad consensus, the specifics are where confusion is created and the parallel to the Zero Trust begins to emerge. Does vulnerability management legitimately relate to attack surface management? Based on the above, it does. However, it is an aspect of Attack Surface Management that focuses entirely on what is known. Other aspects of Attack Surface Management include: Cloud Security Posture Management (CSPM), Cloud Application Security Management (CASM), Cloud Attack Surface Management (also CASM), Cyber Asset Attack Surface Management (CAASM), and a number of others.
Categorically, Attack Surface Management must encompass more than just scanning known assets once a week or once a month. Misconfigurations happen and are exploited exponentially faster than they used to be — in as little as 7 minutes from a recent real world Incident Response event I learned of. Attack Surface Management must be dynamic and proactive, leveraging extensive data gleaned from the entire internet to lead defenders to the most egregious and difficult-to-locate offenders on their network, and do so in record time, continuously.
It’s time to think of Attack Surface Management differently
Just as Zero Trust is a framework and a journey, it’s becoming clear that Attack Surface Management is as well. Moreover, because ASM is intimately tied to discovering and remediating vulnerabilities, it aligns nicely with the ‘Don’t Trust Anything’ mantra of Zero Trust. In this way, Attack Surface Management is a critical addition to the Zero Trust framework and is the perfect complement to enterprise security. More to come on this in the next installment.
