Video: Managing Risk With External Attack Surface Management

Jack Ekolof:

My name is Jack Ekolof, and I'll be MCing the webinar today. I'd like to introduce Rob Kraus, Vice President of Security Services at Evolve Security, to kick things off with "Managing Risk with External Attack Surface Management."

Rob Kraus:

Thank you, Jack, I appreciate the introduction. Welcome, everybody, to today's webinar. We had about an hour scheduled, but I don't suspect it'll take quite that long, so thank you for taking time out of your day. Today, as you've probably seen in the abstract, we're going to decode what external attack surface management is and gain an understanding of what it entails, talk about how it can be used as a preventative tactic to bolster your organization's security, look at some historical analysis of the state of vulnerabilities in general and why external attack surface management is important, and cover how to overcome challenges and some strategic planning considerations.

A little about myself: I'm Rob Kraus, Vice President of our security services team here at Evolve Security. I head up the teams responsible for ensuring our client engagements are successful — the service delivery team, and our offensive security services and consulting teams who do the work for our clients and provide those valuable results.

Just the obligatory company overview: this isn't a sales call, it's more about spreading awareness of attack surface management in general. Evolve Security is a next-generation offensive security company, established in 2016 and headquartered in Chicago. We have a lot of traditional capabilities related to penetration testing, and we also offer attack surface management, application pen testing, and social engineering. We also have our roots in our cybersecurity academy, which focuses on reskilling and upskilling cybersecurity professionals — helping close the gap for people looking to get into the field and for organizations looking to hire qualified candidates.

So, let's decode external attack surface management. What is it? Today, organizations are focusing heavily on expanding — moving from legacy hardware, data centers, and on-prem servers, and embracing digital transformation, which involves relying on a lot of different technology and platforms. As you can imagine, although the intent is to reduce the attack surface, in some cases it actually expands. There's been widespread adoption of cloud technologies that bring together multiple capabilities organizations never had before, enabling greater flexibility, scalability, and cost efficiency. But with those adoptions come risks to keep in check. Organizations now have more complex environments — many of our customers have different parts of their infrastructure in different cloud providers, plus on-prem on top of that. A lot of our customers have infrastructure in AWS, some in Azure, and some hosted on-prem or in a data center using traditional IP addressing or CIDR ranges.

Even with all these capabilities, organizations are really struggling with traditional asset management. It's always been a challenge to focus on what and where their assets lie, how they're being managed, and who's responsible for them. With the proliferation of cloud services, that becomes a bigger problem — easier to deploy also means easier opportunities to accidentally shoot ourselves in the foot. So we have to constantly keep track of assets, who they belong to, and their criticality. To tackle those challenges, organizations need robust asset management strategies and tools specifically designed to address those complexities — and this is where attack surface management excels.

There's been a lot of discussion about attack surface management in the industry. I have a quick quote from Gartner: by 2026, 20% of companies will have more than 95% visibility of their assets, prioritized by risk and control coverage, by implementing attack surface management functionality. 2026 isn't too far away, and we're already seeing this transformation with our clients as we work through renewals. We have a lot of clients coming in, looking at legacy testing methodologies and starting to inquire more about attack surface management and how it can help.

Before we dive deeper into EASM (external attack surface management), let me draw a picture of why these discussions matter. Looking historically at the count of CVEs — Common Vulnerabilities and Exposures — think of these as researchers identifying vulnerabilities in software, hardware, and applications, reporting them to vendors, who then hopefully address them in a reasonable amount of time. CVEs are tracked by MITRE, which controls the issuance of CVE numbers. Back in 1999, the number of reported vulnerabilities was fairly small and slowly grew over time as researchers became more aware of responsible and coordinated disclosure. One point I want to highlight: between 2016 and 2017, there was a significant bump. From my research and my own experience reporting vulnerabilities, MITRE launched new tools and capabilities around early 2017 that made it much easier for researchers to register identified vulnerabilities and have CVE numbers assigned. So there wasn't a magical event in 2016 or 2017 — the ability to report them just became much easier. But despite that bump, we're on a very solid upward trajectory every year.

This year, as of this morning when I updated the number, there were 26,982 vulnerabilities reported year to date — and I bet if you go to the CVE Details website after this presentation, that number will have increased just since we've been on this call. That's a lot of vulnerabilities. Considering that the last time I checked, about 9.8% were deemed critical, that's a significant number of critical vulnerabilities — a 6% increase compared to end of year 2022, and a 16.4% increase compared to this time last year. I don't suspect that trend is going to slow down.

This is a screenshot I took this morning from cvedetails.com, outlining activity since yesterday, the last seven days, and the last 30 days. Something to point out is known exploited vulnerabilities — there's a list called the KEV (Known Exploited Vulnerabilities) list, which I believe is published by CISA and has well over a thousand entries. These are vulnerabilities being observed exploited in the wild as we speak.

Looking at vulnerability history over time, you can see from 2018 the total has significantly increased — from 16,557, to 17,344, all the way up to last year at 25,227. But the point I want to make is this: if we think about legacy testing and keeping tabs on what our network looks like, we can no longer rely on prior methods. For many years, the industry standard — and guidance even from compliance organizations — indicated it's acceptable to have a quarterly vulnerability scan and an annual pen test. I hate to say it, but I really argue that point with these numbers. Back in 2022, there was an average of 1,941 vulnerabilities identified every quarter, with 190 of those critical on average. I would not sleep well at night thinking a quarterly vulnerability scan or an annual pen test makes sense. This leads into the proposition of using services like external attack surface management (ASM).

When trying to identify vulnerabilities, one of the key things we focus on is key performance indicators to track — two of those being mean time to identify and mean time to remediate. Mean time to identify refers to how long it takes to identify a vulnerability in your environment. Under the prior standard of quarterly scans and annual pen tests, that mean time to identify is very large, which then extends your mean time to remediate — the metric for how quickly you can address a vulnerability once identified, based on its criticality and potential impact. With services like EASM, you keep more of a constant touch, focused on real-time, continuous assessment of your external attack surface. Instead of waiting 90 or 120 days for your next quarterly scan to find out your problems, you find out closer to real time, so you can prioritize those risks and address them.

When we look at reducing potential impact through effective risk identification, the goal with ASM is to get more "left of the attack." If you're familiar with the Lockheed Martin Cyber Kill Chain, it defines an attack path in seven steps: reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives. With EASM, we're trying to get left of the attack — identifying and mitigating vulnerabilities early enough to make reconnaissance unsuccessful for attackers. Unless attackers have a vested interest in a specific organization, they're still very much targeting organizations that are targets of opportunity. So don't make yourself the easy target — get out there and identify the vulnerabilities and risks before the attackers do, and chances are, in many cases, they'll pass you by. That's not always true — with APT threats or focused attacks for political agendas, attackers won't give up as easily — but in general, attackers still go after the most loosely guarded secrets.

On the EASM lifecycle: it's a systematic approach to identify, assess, and manage vulnerabilities closer to real time. EASM helps organizations maintain visibility into potential entry points for attackers — web applications, network infrastructure, cloud services, third-party integrations, and more. Gaining a clear understanding of what your attack surface looks like at any day and time helps reduce risk, bolster business continuity, and improve overall cyber resilience.

All the lifecycle steps are critical, but EASM is still on the leading edge of Gartner's hype cycle, so the lifecycle looks slightly different between vendors. In general, any vendor should focus on these core steps. Reconnaissance: what do we know about the organization, and what information is out there we could potentially use against it? Discovery: interrogating the systems identified during reconnaissance and determining what services are running and what could be exploited. Asset identification: more formally declaring the asset types identified, their scope, and what they mean to the organization. Vulnerability identification: identifying misconfigurations, poor cyber hygiene, and sensitive data related to assets — and it should be very clear, whether you're talking to Evolve Security or anybody else, what that means as a deliverable or process. Some vendors will just use an automated scanner, go scan assets, and say "here's your report, good luck" — with no validation, incorrect results, or potentially missing major gaping holes.

At Evolve Security, we use a hybrid approach. We use some automation to aid with vulnerability identification, but we also have an offensive security operations center that validates all identified vulnerabilities, determines potential impact based on what we know about the organization, and takes a step further by performing opportunistic penetration testing against the services we identify. So it's not just a vulnerability scan and a notification — if we identify a vulnerability, we validate it and then try to exploit it if it's exploitable, which provides value because we can determine whether we can get a foothold in the organization. So risk validation is part of that step — validating the risk is legitimate and assigning severity, impact, and scope. And lastly, mitigation recommendations: providing highly curated, validated vulnerabilities to stakeholders so they can prioritize managing the risks. In short, this process lets organizations take the information they receive, apply it, and move the needle to make a meaningful impact on their security posture.

On the challenges: a large part of the EASM process is identifying risks the organization may not be aware of. We work with customers across many vertical markets — manufacturing, financial, healthcare. The common denominator is that they usually have a pretty good idea of their known assets — "I have these CIDR ranges, these web servers at these providers, these parts of my infrastructure in the cloud" — but it's the unknown assets, unknown services, and shadow IT risks that really impact them.

We had a client a couple of weeks ago with a very small external-facing infrastructure — less than 10 hosts in their external presence — but they had three systems stood up as a shadow IT issue. They'd been stood up for a marketing campaign, and a network engineer had left management interfaces on external interfaces, pointing to an internet point of presence that nobody was aware of, until we started interrogating those services. So one of the big challenges we continuously see isn't necessarily the known assets — it's good to have that inventory and validation, but what are the unknown assets and shadow IT issues? Do I have domain names registered, DNS, IP CIDR ranges, cloud services? Quite often in briefings with our customers, we get positive feedback like, "We forgot about that system we set up two years ago — it's still out there, it's quite vulnerable, and yes, it's tied to our infrastructure." Within minutes or hours, we see clients take down those services and request a retest to make sure the threat is mitigated. A win for everybody.

When we talk about the exposed attack surface, it's far wider than just traditional services like web and email. When you think about all the different types of data and services we provide day to day, it's easy to imagine the potential risks. Just to be clear, although current industry offerings for ASM are maturing, the definition of ASM will vary across vendors. EASM is a good preventative control, but we're not saying it's a silver bullet that provides active defense against active attacks — think of EASM as managing your exposed attack surface proactively.

When engaging with our customers, we think about what it takes for them to be successful and the value proposition. By implementing EASM, you give yourself the capability for early detection. Organizations may have SIEM controls with active monitoring of network traffic, but a lot of organizations don't have any integration of their vulnerability and risk management overlaid on what they're seeing from their SIEM. ASM provides early detection of what's potentially impactful, so you can minimize impact and prevent costly breaches. If we reduce the attack footprint and mitigate risks, we minimize downtime and losses from potential attacks. It also helps with avoiding regulatory fines and working with insurance companies — just like safe-driver discounts on car insurance, cybersecurity insurance providers look at your hygiene: are you doing the blocking and tackling, the core security principles?

In our platform, we have controls and capabilities that support compliance and regulatory investigations related to risk management. We help clients subject to governance, risk, and compliance (GRC) or insurance requirements show they have a living, breathing vulnerability risk management program: "We identified the vulnerability on this day, validated it on this day, remediated it on that day" — living proof through our logging and statuses, which is valuable in discussions about insurance premiums and with auditors. Protecting brand reputation is another passive benefit — defacements, data dumps, and disclosures still happen, and helping prevent you from getting into a bad situation in the first place is one of those detective controls. And one of the last things most CFOs like to hear: yes, we can invest in detective controls to bolster security, but that also minimizes potential losses, freeing up capital to reinvest in and grow the company.

On other ASM implementation considerations: we want to identify, discover, inventory, and classify the systems we're aware of, and apply risk scoring and security ratings to the vulnerabilities we identify. A challenge for organizations without a mature process is: "Evolve identified a critical vulnerability that just popped up — what's our SLA to manage it based on GRC or our internal policies?" That's homework and potential discussion we have with clients. Continuous monitoring and remediation are important considerations, as is notification and awareness — the processes for communicating between your vendor and your EASM solution. Thankfully, at Evolve we have good collaboration tools and patent-pending tools: video escalation, a live attack feed, and real-time notifications to clients of newly discovered assets and vulnerabilities, which streamlines that process.

Just as a very high-level perspective — this is by no means a deep dive into what attack surface management looks like from an Evolve delivery standpoint — here's the overview. We look at your external attack surface, bring you on as a client, and apply our service delivery team to work directly with your team. We do the homework on scoping and key assets, build out your profile, and then move into initial baselining: we discover systems, ports, and protocols related to your scope, identify vulnerabilities, and risk-rank them, all made available in the Darwin attack platform with various communication methods. After we define that initial baseline and know what good looks like, we move into penetration testing. So right out of the gate, across the entire infrastructure, you're not only getting initial vulnerability identification, but also a full-blown external penetration test by a dedicated pen testing team — W2, US-based employees — delivering, on top of the EASM, a traditional penetration test. So we satisfy both the vulnerability testing requirements and the penetration testing requirements that meet the rigor of many compliance initiatives.

Once we complete the initial baseline, we move into continuous monitoring — constant scanning for new IP addresses, ports, and protocols, identifying potentially new vulnerabilities, and performing manual penetration tests on anything that differs from the baseline. If a new host pops up tomorrow, we immediately jump in, perform the risk assessment, validation, and opportunistic pen testing on the ports and services, and report back. So you're not waiting until your next pen test cycle to get true results — you're getting pen tested basically all the time as new services come online. And even if we don't see any changes after baselining, Evolve has determined that we'll still conduct a weekly vulnerability identification exercise, touching your entire infrastructure weekly to identify new vulnerabilities — because, as we pointed out, there are always new vulnerabilities being identified and new detection capabilities being published, and it's important to stay on top of that. Lastly, beyond the real-time data in the report, to help satisfy GRC requirements, we publish quarterly reports on the risks and vulnerabilities identified and the deltas between your baseline and where you are today, so you can really see the needle moving.

That's all I have for today's presentation.