Not all attack surface is created equal: Why protecting security controls is critical

less than 1 minute read

Any exposed attack surface can be used by an adversary to gain or maintain access to your environment. Security controls are a uniquely high-risk part of your attack surface, because compromising a security control often provides an adversary with privileged and/or uniquely positioned access to the environment. And evidence shows that adversaries are capitalizing on exposed, vulnerable attack surface.

Compromising a security control gives the adversary the ability to perform one or more of the following:

• Manage devices
• Manage identities, including access control and management
• Alter external network access control policies, including: granting remote access to networks, allowing lateral movement between networks, or allowing network egress
• Modify, suppress, or remote logs, alerts, and other evidence of their activities
• Monitor investigative or response activities
• Access sensitive data (particularly problematic if the compromised control issues key material, or performs TLS interception a.k.a. man-in-the-middle)

By contrast, a compromised end user device or endpoint, e.g., a workstation or server, may provide some of the same abilities, but often in a much more limited capacity.

CISA Known Exploited Vulnerabilities (KEV) affecting security controls

3 minute read

Since its inception, I’ve been bullish on the value of the CISA Known Exploited Vulnerabilities (KEV) catalog, along with their periodic analysis of the top exploited vulnerabilities based on the same. The KEV catalog contains a concrete set of trailing indicators that tell you which vulnerabilities should be prioritized for patching or other forms of remediation.

For organizations with a mature, operational vulnerability management program, KEV is a valuable input. For the majority of organizations that do not have a vulnerability management program, it’s an excellent place to start. And if we’re being realistic, it’s a good alternative to doing nothing or addressing vulnerabilities ad hoc.

Enriching the Known Exploited Vulnerabilities data set

CISA makes the KEV data set available via CSV or JSON. I’ve been using the CSV version, which I’ve enriched in a number of ways, including identifying different types of products affected by these vulnerabilities:

• Security - Products designed explicitly to secure devices, networks, or otherwise. This includes endpoint and network protection.
• Edge infrastructure - Products used to connect networks, including protecting the network edge by use of access control lists or mechanisms. This includes most routers, firewalls, email gateways, and other devices that accept inbound traffic from the Internet for inspection or routing.
• Identity and Access Management - Products that provide identity, authentication, authorization, and other access management functions.

The set of products that fall into any of the above categories are treated collectively as security controls.

I also found it helpful to integrate the top exploited vulnerability lists into the same data set, which makes it possible to see some of the breakdowns below, as well as trends.

Known and top exploited vulnerabilities in security controls

Your security controls are a critical cross-section of your attack surface. While we’re busy using our security controls to monitor devices, identities, and other assets under our protection, adversaries are busy exploiting these controls, gaining tremendous leverage over (often many) victims.

As of October 2023, approximately 17% of KEV entries affect a security control.

More concerning than a known exploit in any security control is the appearance of security controls in CISA’s list of top exploited vulnerabilities. 33% of the top 12 exploited vulnerabilities in 2022 affected security controls. If we look at all 42 of the top exploited vulnerabilities in 2022, ~29% (still roughly 1/3) of the expanded set affected security controls.

The sad story of CVE-2018-13379 and CVE-2022-40684 (Fortinet FortiOS)

The top exploited vulnerability in 2022 was CVE-2018-13379, a path traversal vulnerability in the Fortinet FortiOS SSL VPN web portal. As the CVE ID suggests, this was assigned in 2018 but not published until June of 2019. Finding instantces to target was as easy as a Google search for intext:"Please Login" inurl:"/remote/login".

In 2019, a pair of exploits for CVE-2018-13379 appeared in Exploit-DB. One of these exploits was a Metasploit module, making exploitation of these systems push-button easy.

Four years after the CVE was assigned and three years after release of an exploit, CVE-2018-13379 was the most exploited vulnerability of the year, known to be leveraged by a variety of successful ransomware groups.

NOTE: This appears to have been used in conjunction with CVE-2022-40684, and it’s unclear why the former topped the last and the latter received an honorable mention.

What will happen in 2023?

It’s impossible to say what 2023’s top exploited vulnerabilities will be. But ongoing and widespread exploitation of products from Fortinet and Cisco, coupled with their place atop the KEV leaderboard as it relates to security controls, are likely to have a significant impact on top exploited vulnerabilities.

Takeaways

This is cursory analysis, but the quality of the underlying data set coupled with what we know about adversary behavior—in particular, that adversaries will always seek out high impact vulnerabilities for exploitation—tells us a lot about the importance of:

• Keeping security controls up-to-date, first and foremost. It’s best to take away the attack surface quickly and proactively.
• Being doubly sure that known exploited vulnerabilities across your attack surface are patched.
• Continuing to put pressure on software vendors to invest in product security, both proactively but also from an incident response and support standpoint.
• Acknowledging that our security controls are high value, high risk, often highly exposed, and treating them as such when it comes to monitoring and threat detection

Your security controls are (a huge) part of your attack surface

4 minute read

Security software is just software, subject to all of the same problems as any other type of software. And like so much of the software we find in the enterprise, security software has some predictable characteristics:

• Not well understood - Compare how well you understand the platform and behavior of your favorite enterprise security suite to something like Windows, or even lesser-understood platforms like macOS and Linux.
• Lacking observability - And even if observability is possible, see previous statement.
• Poorly managed - So many security products are installed and largely forgotten, save for configuration updates. Out of date versions abound.
• Poorly designed and implemented - Again, security software is just software. And many companies building security products aren’t security companies—they’re software companies, and they invest in product security to the same degree that other software companies do (“just enough”). A special shout out to “enterprise suites”, bloated, complex, frankenstein-esque systems comprising dozens or hundreds of open source and proprietary components that even their creator cannot possibly understand, let alone secure.

Then there’s the kicker:

• Highly privileged, and packed with powerful features - Re-read the list above, and then think about this.

With great power . . .

The phrase “highly privileged, and packed with powerful features” is to some degree a necessary evil, though improved threat modeling and design would go a long way towards reducing the risk to customers.

Endpoint security product features like live response (really, sanctioned rootkits) are like Swiss Army knives for defenders and adversaries alike. Implementing product defaults that alert system owners of its use, strong multi-factor authentication for session initialization, and robust observability are the least that we should expect from a product subsystem that can silently gut an enterprise.

Identity is arguably the one security domain and set of controls that every organization should triple-down on, master, and monitor closely. If you’re managing identity security exceptionally well, you’ve eliminated more attack surface than we appreciate. And for this reason, identity and access management products are prime targets for adversaries and red teams alike. The same is obviously true of more traditional directory services, like Active Directory.

And this is to say nothing of completely bonkers products like TLS intercept devices. These are a terrible, horrible, no good idea for a variety of reasons. The simplest reason is that anything of extraordinary value will eventually end up in the wrong hands. And in the wrong hands, security products that undermine foundational security and privacy controls (e.g., encryption) will absolutely gut your enterprise.

. . . comes great opportunity

For adversaries, security products will always be enticing and high value targets. A zero day in a security product might not have the same reach as one targeting Windows or macOS, but adversaries can and do get significant mileage out of exploitation or abuse of security tooling.

So, not only are these security products part of your attack surface, they carry some extraordinary risk. The likelihood of exploitation may be lower than that of most widespread platforms and software, but when it happens, the impact can be catastrophic.

I do believe that computing platforms are getting more secure overall. The trend towards app store-style platforms lends to more restrictive default configurations, making it far more costly to introduce malicious software. And other successful technical controls continue to move upstream and are included by default in most end user and production computing platforms. But because security products are uniquely valuable, and because we’re taking away attack surface in these other areas, we’ll continue to see adversaries do an end run around traditional targets to go after identity providers and other security products instead.

Vulnerabilities.

One way that the shortcomings I list at the start—and there’s shared responsibility for these amongst vendors and users alike—come home to roost is vulnerabilities. Paying attention to software vulnerabilities in security products is particularly useful, as it may be the most objective means of understanding how often adversaries are weaponizing security products and using them to harm us.

Here are some of the receipts from last year alone, courtesy of CISA’s list of 2022 Top Routinely Exploited Vulnerabilities:

• CVE-2018-13379 - Fortinet FortiOS SSL VPN Path Traversal Vulnerability CVE-2021-20016 - SonicWall SSLVPN SMA100 SQL Injection Vulnerability
• CVE-2021-20021 - SonicWall Email Security Improper Privilege Management Vulnerability
• CVE-2021-20038 - SonicWall SMA 100 Appliances Stack-Based Buffer Overflow Vulnerability
• CVE-2022-1388 - F5 BIG-IP Missing Authentication Vulnerability
• CVE-2022-40684 - Fortinet Multiple Products Authentication Bypass Vulnerability
• CVE-2022-42475 - Fortinet FortiOS Heap-Based Buffer Overflow Vulnerability

I only examined the broader list (which surpassed the 1000 exploit mark as of September 2023), long enough to make my point. But there are plenty more:

• CVE-2020-5902 - F5 BIG-IP Traffic Management User Interface (TMUI) Remote Code Execution Vulnerability
• CVE-2022-41328 - Fortinet FortiOS Path Traversal Vulnerability
• CVE-2023-2868 - Barracuda Networks ESG Appliance Improper Input Validation Vulnerability
• CVE-2023-20269 - Cisco Adaptive Security Appliance and Firepower Threat Defense Unauthorized Access Vulnerability
• CVE-2023-27532 - Veeam Backup & Replication Cloud Connect Missing Authentication for Critical Function Vulnerability
• CVE-2023-27997 - Fortinet FortiOS and FortiProxy SSL-VPN Heap-Based Buffer Overflow Vulnerability

What do we do about it?

For starters, vendors must acknowledge that customers pay money for security products to reduce risk, but that their solutions often introduce new, significant risks. Threat model, design, build, and configure (by default!) accordingly.

On the enterprise side, CISA’s work to lower the vulnerability management noise floor is providing organizations with the thing that vendor solutions largely have not: The list of things you’d better patch right now. So, even if you don’t have or can’t afford a vulnerability management solution:

1. Sign up for CISA advisories
2. Patch top exploited vulnerabilities first
3. Patch known exploited vulnerabilities in all of your free time

Lastly, don’t just rely on your security products to monitor the rest of your attack surface. Treat your security products as a critical cross-section of your attack surface, and monitor it as closely as you monitor anything else.

Discussion on LinkedIn

Breaking down exposure management

2 minute read

While participating in some industry analyst research, I was asked how I’d walk someone through and connect these concepts. This is a paraphrased version of the talk track (with some visuals based on prior work).

I’ve continued to think about the convergence of a number of foundational security activities into a more holistic exposure management practice (and ultimately, exposure management products). Those activities include, asset, attack surface, attack path, and vulnerability management, among others. In this case, we’ll look at them hierarchically.

Situational awareness: Assets and attack surface

Asset management is foundational to information technology governance and cybersecurity hygiene. We often say that we can’t detect what we can’t see, but this overlooks the fact that we can’t do anything at all to protect an asset that we don’t know about in the first place. Asset management takes into account the subjects of processes like procurement, ownership, maintenance, periodic inventory or other forms of discovery, and more. Of course, not all assets that an organization will manage are cybersecurity or information assets, but it’s better to be greedy when it comes to intake of asset data, so that you can exclude assets that aren’t in scope versus making assumptions.

Every asset management activity is an opportunity to identify and manage your attack surface.

Attack surface management involves continually validating the presence, state, and key attributes of assets you know about, and actively seeking assets you don’t yet know about or understand (i.e., assets not captured as part of asset management processes). The goal of this activity is to enrich your asset data set with the information needed to know what needs protecting, and ultimately to continuously take the steps needed to protect at-risk assets.

Your security controls are part of your attack surface!

Attack surface management may be best thought of as an umbrella activity within which a number of lower-level, highly conextual activities exist.

Context and depth: Attack paths, vulnerabilities, intelligence, and more

Attack path management, which starts with how an adversary might gain initial access to any part of our attack surface, and progresses into understanding the various ways they can progress by way of identities, applications, systems, networks, and more. This can range from very simple to very in-depth:

• Elementary: Understanding asset accessibility. For instance, are assets accessible only via internal networks, or are they connected directly to the Internet? Are web-based portals also protected by key material, or can anyone access the login screen?
• Intermediate: Understanding asset components and behavior? What does the system look like when observed under normal operating conditions? What user, application, or underlying platform behaviors might be present if it is under attack?
• Advanced: Understanding the asset in the context of a holistic threat model, including whether the system is subject to targeting by adversaries with exceptional capabilities or motivations.

Vulnerability management, best thought of as a peer to attack path management, as most initial access stems from some identified and manageable class of vulnerability, including software, configuration, process, or human/user.

Good attack surface management solutions also incorporate ongoing activities like network scanning and cloud posture management (technically a form of configuration vulnerability management). They also includes oversight activities like penetration testing and red teaming, aimed at validation assumptions about your attack surface and your ability to defend it against adversaries.

Ultimately, the synthesis of all of this data integrated with high quality threat intelligence, to help you prioritize what’s likely and understand what’s possible, should result in understanding which of your assets are most exposed so that you can take action to mitigate risk.

Dave Aitel (and friends) on BlackHat, DEF CON, and infosec culture Permalink

2 minute read

The Vegas security conferences used to feel like diving into a river. While yes, you networked and made deals and talked about exploits, you also felt for currents and tried to get a prediction of what the future held. A lot of this was what the talks were about. But you went to booths to see what was selling, or what people thought was selling, at least.

But it doesn’t matter anymore what the talks are about. The talks are about everything. There’s a million of them and they cover every possible topic under the sun. And the big corpo booths are all the same. People want to sell you XDR, and what that means for them is a per-seat or per-IP charge. When there’s no differentiation in billing, there’s no differentiation in product.

I sat out BlackHat and Defcon this year, for the first year in many, and I’ve spent much of the past week catching up with folks who did go and getting their perspective. The recurring theme has been “it’s different”, but I think I would have told someone the same last year, or the year before that.

My day-to-day interests aren’t what they were nearly 20 years ago when I started working in the information security industry. I’m much more interested in product and operations, in particular how we think about outcomes, value, and ultimately driving defenders’ costs down while driving adversary costs (way) up.

That said, I still get enjoyment from novel research and deep technical topics despite feeling like I have to work much harder to understand them. And more so than the content, I have a deep appreciation for the relatively small number of folks who led our industry for decades, most or all of them with deeply technical backgrounds and expertise, having built tools or technologies that are still considered foundational to this day. Industry conferences are a bellwether for the broader industry, the skills and talent that we develop, and the products or solutions we build. And so I am always very interested in how those who have seen infosec grow from a hacker-centric counterculture into a thriving industry perceive conferences in particular.

Dave’s post to the venerable Dailydave mailing list struck a chord with me, as it clearly did with others, several of whom are on my short list of industry giants. The discussion is well worth a read.

If you’ve been in this business for a while, you have a dreadful fear of being in your own bubble. To not swim forward is to suffocate.