TLDR: Proactive external attack surface management (EASM) has become increasingly important than ever before as organizations face an expanding threat landscape and unprecedented level of attacks. Crowdsource hacker Luke “hakluke” Stephens details what it means, how to implement it, and how to make sure you don’t make errors while doing so.
I have a history of creating my own custom “bug bounty automation” systems to automate the process of performing reconnaissance, vulnerability discovery at asset prioritization. These days it’s called “External Attack Surface Management” (EASM). In essence, EASM is hardly a new concept. The name has become fancier since Gartner listed EASM as an emerging product but the concepts are very similar. It has been interesting watching the security industry at large catching onto this trend.
There are several reasons why EASM has become so prevalent in recent years. To name a few:
The difficulty of creating, editing, and deleting external infrastructure has diminished, meaning that organizations are more likely to have larger, more dynamic external footprints. With digital assets scattered all over the Internet coupled with improper security oversight and hygiene, organizations must ensure that they have a full understanding of their external attack surface. The dynamic nature of increasing cyberattacks makes it harder to defend with traditional practices.
Attackers have already adopted it.
Defenders stand the best chance against attackers by adopting their continuous monitoring methods and remediating bugs before they are discovered and exploited.
The methodology was popularized by many bug bounty hunters who became successful by focusing solely on large-scale reconnaissance and vulnerability scanning. It quickly became obvious that many larger organizations had vulnerable systems online because they were simply not aware that they existed.
As with any trend in tech, everyone wants to grace the world with their take on EASM. Now there are publicly available blog posts, webinars, YouTube videos, podcasts, bumper stickers, T-Shirts, mugs, and more. I’ve been consuming them all! These takes have placed anywhere from excellent through to downright wrong, and dangerous. It’s so important that the EASM advice we put out is good advice because the proliferation of this idea is still in its early stages, where a few popular blog posts sending the wrong message have the potential to derail the whole concept.
Mistake #1 🙅♂️ Confusing EASM with asset discovery
One of the common mistakes I’ve seen is confusing a full EASM program with continuous reconnaissance. Continuous reconnaissance is a significant part of any good EASM program, but it is not the whole thing. The larger part of the EASM puzzle is managing the risks associated with the assets that are discovered. The key is actually in the name – it’s called External Attack Surface Management, not attack surface discovery.
So, what exactly does it mean to manage an attack surface? Here are some examples:
- Using a vulnerability scanning solution to consistently scan the assets found in the discovery phase.
- Developing a method of triaging the risk associated with each asset, based on risk markers and discovered vulnerabilities.
- Prioritizing assets to investigate manually based on their risk scores.
- Manually reviewing assets with high-risk scores, potentially with a penetration test.
- Regularly reviewing results to ensure that the external-facing assets are meant to be external.
- Cleaning up unused VPSs, DNS records, 3rd party accounts, code repositories, etc.
- Remediating discovered vulnerabilities.
Many of these tasks may already be performed as a security function without implementing an EASM program; the difference is that an EASM program allows tasks to be performed with more impact and purpose, because they are better informed.
Mistake #2 🙅♀️ Viewing EASM as distinct from the rest of security
Many people view EASM as another chore for the already-overburdened security team. Another dashboard to check, another Chrome tab, more notification fatigue. EASM should not be like this. It is not a separate task, rather it is a concept that integrates with your existing security processes – similar to how a Secure Development Lifecycle such as MSDL slots into a development lifecycle.
When EASM is implemented correctly, it should actually reduce tasks (and stress) on the security team by offering extended automation and prioritization to their existing workflow.
Mistake #3 🙅 Not going wide enough, or deep enough
When I visualize EASM programs, it looks something like this:
When I say going “wider”, I am referring to implementing each stage of the EASM program (discovery, assessment, prioritization, remediation). When I say going “deeper” I am referring to improving the quality of each stage.
There is always room to improve an EASM program – once all of the stages are being performed, it’s just about constantly iterating on each stage, improving it with more data, better data, better review processes, more accurate prioritization, etc.
The Ultimate EASM Program 🌈
I could keep talking about mistakes all day, but I think it’s time to switch gears. It’s time for some EASM inspo and what it could look like to have an efficient tool working 24*7.
You are a SOC analyst that implemented an EASM program at your company.
A notification pops up where your EASM tool just discovered a dangling DNS record.
Your EASM tool then discovered that a few client-side libraries have fallen into EoL on some of your public facing web applications. You scroll through them and click “send to Jira”, which automatically sends the details to the development team’s ticketing system for remediation.
Another notification! Your EASM solution discovered an S3 bucket in the wild containing your customer data. Time to raise an incident. Thankfully, you’re able to take it offline before too much damage is done.
Without an EASM tool, you wouldn’t be able to monitor any of these issues and vulnerabilities.
Hence, it’s easy to say that a good EASM program will make your life easier and company safer – not harder.
Luke Stephens a.ka. hakluke. Currently living on the Sunshine Coast, in Australia, I recently resigned from my role as the Manager of Training and Quality Assurance for Bugcrowd to start my own consultancy, Haksec. I do a lot of penetration testing and bug bounties and create content for hackers. Check out my Youtube channel.
Where Detectify comes in
There is no silver bullet when it comes to protecting the external attack surface or your web applications. You need a modern security toolbox that leverages crowdsourced security to help you continuously monitor and scan your assets for anomalies. Automated vulnerability security tools like Detectify go well with bug bounty programs and manual pentesting by maintaining a constant level of automated security testing. See what Detectify will find in your attack surface with a free 2-week trial. Go hack yourself!