Why EASM Projects Fail: Three Pitfalls to Avoid
According to the 2023 edition of the Verizon Data Breach Investigations Report, over 83% of breaches come from outside the organization. Yet despite this large majority, many organizations have no complete inventory of their externally exposed assets, much less the knowledge of if they are potentially vulnerable. The key to solving this problem is to deploy a security technology known as external attack surface management (EASM), and to make sure to avoid three well-understood pitfalls in deployment. I’ll draw upon CyCognito’s experience in deploying EASM over the past five years to explain pitfalls to avoid in order to make your project a success.
What is EASM?
The concept of EASM is simple: Look at your organization from the outside and determine which of your exposed assets is an attractive target. In other words, act like an attacker doing recon. This collection of assets – websites, applications, cloud infrastructure, devices – is what’s known as the attack surface. EASM automatically and continuously looks for all assets that compose your attack surface and tests them to determine if they are vulnerable. It automates the process of acting like an attacker doing recon.
Gartner recommends attack surface assessment technologies like external attack surface management (EASM) as a key pillar in organizations’ exposure management strategy. By understanding their potential exposures before attackers do, security teams can get ahead of the game. Rather than waiting for an attack to occur and determining how their defenses fared, exposure management recommends a proactive approach to security, rather than the conventional defensive approach.
Knowing Your Attack Surface
Understanding your organization’s attack surface is no small task. Based on our research here at CyCognito, the average enterprise customer has 50,000 externally exposed assets. Large enterprises can have several times that number. What’s more, these numbers can fluctuate by as much as 10 percent on average per year, as assets are added, moved or retired. Keeping track manually is just untenable. Assuming an analyst knows about an asset, correctly documenting its IP address, name, type, owner, location, included technologies, related assets, known vulnerabilities and threats would take at least 30 minutes per. That’s 25,000 hours.
On top of the daunting task of cataloging assets is testing it. Even if there is a known vulnerability for, say, a JavaScript library, database, or other piece of software, it doesn’t necessarily mean it’s exploitable. The only way to know is to go beyond simple recon and do some probing. EASM products are tested continuously, typically daily or weekly. They do so quietly so as not to disrupt production systems. The output is a prioritized running list of potential vulnerabilities for security analysts to investigate.
The Top Three Pitfalls of EASM Projects
Here at CyCognito, we have deployed EASM across thousands of organizations and millions of assets. These are three common pitfalls we have encountered and how we coach customers on how to address them.
1. Too much data – After spinning up a new EASM tool, security leaders can find their teams drowning under an increased workload, unable to take action on any alerts without first investing hours – we’ve found that it takes on average 3-10 hours or work to investigate one asset – of manual work. We’ve also found that 1 in 3 assets are less urgent in context than their CVSS score would indicate. If everything’s a priority, nothing is, so the project gradually becomes less and less urgent until it dies a slow death.
The key to avoiding this pitfall is prioritization. Working solely off of a CVSS score can be misleading. Thinking again like a hacker, the three things you need to know about an asset are,
1) Is it easy to find? 2) Is it exploitable, and 3) Is it attractive to attackers? An e-commerce platform – easily accessible to users and directly linked to valuable data like payment cards – with known exploits would hit this trifecta.
2. Ignoring unknown assets – As mentioned above, an attack surface’s size fluctuates by an average of 10% every month; many external assets are unknown to an organization, and new assets appear regularly. If a team’s EASM product relies on them to supply a list of assets to monitor, then by definition, their attack surface is missing those dangerous, unknown assets and security teams might not realize these unknown unknowns aren’t being monitored. Once a security incident happens, this illusion is shattered, and the EASM project is declared a failure.
We notice this issue a lot in distributed organizations with several divisions or brands. These divisions might cover different geographic areas or be different brands owned by a common parent company. Some may have been fully integrated into the larger organization and share security and IT resources, while others are recent acquisitions with completely different networks, systems and software supply chains. If the initial discovery process does not cover all divisions and brands, then, from the start, assets will be missed. We’ve had more than one uncomfortable meeting with a security leader who criticized the accuracy of our EASM platform, only to learn that they were unaware of an acquisition or joint venture from the past few years.
Security teams need to fully understand their organization before they start scanning for assets. The EASM product should then be set up to scan continuously so that new assets are captured and retired assets are identified.
3. Integration with existing processes – An EASM solution can feel shiny and attractive at first, but if it fails to integrate into existing security processes or feeds, it is likely to wither and die without becoming part of the entire security ecosystem. With average remediation times already stretching into weeks or months, anything that slows teams’ workflows doesn’t have staying power.
The main issue we see here is not that organizations fail to connect their EASM to a ticketing system. It’s that they don’t know who to contact. A key piece of creating the catalog of assets is ownership. Which organization does that AWS instance belong to, and who is the developer responsible for maintaining that API? EASM has advanced to the point where it can automatically determine which organization owns which asset. Once this is done, individuals or queues responsible for maintaining these assets can be populated into the EASM system.
Remediation on assets can be done effectively when an issue arises.
EASM has come a long way in a relatively short period. Advances in AI have made it even smarter, able to determine more about the characteristics of assets and to provide a richer, more complete picture of an organization’s attack surface. So, if you avoid the pitfalls above, EASM can provide a great defense against two-thirds of your breach problem.
