Exposure Assessment: Thinking Like the Adversary

In February 2021, an operator at a water treatment plant in Oldsmar, Florida watched the cursor on his screen move on its own. Someone had logged into the plant's control system through TeamViewer, remote access software that staff had stopped using six months earlier but never removed. The computers involved shared a single password and sat directly on the internet with no firewall. Whoever accessed the system briefly increased the sodium hydroxide setpoint to a dangerous level before the operator reversed it.

Nobody at the utility had flagged that exposure, because nobody had gone looking for it from the outside. Exposure assessment exists to catch exactly that kind of blind spot. 

In this article, we examine what exposure assessment means in a cybersecurity context, how it fits into the broader risk assessment process, the elements a complete assessment needs to capture, and how the work actually gets done, including where open-source intelligence fits into finding exposure before someone else does.

What Is Exposure Assessment?

Exposure assessment is the process of figuring out what is actually reachable, by whom, and under what conditions. It answers a question that is easy to skip past: given that a weakness or a valuable target exists somewhere in the environment, is it actually reachable, and by whom?

That question matters because exposure and vulnerability are not the same thing. A weakness in a piece of software can exist for years without posing much real danger if the system running it sits behind layers of network controls and nobody outside the organization can reach it. The same weakness on an internet-facing system with no protections is a very different story. That's the distinction CISA's guidance on reducing internet exposure is meant to address. 

Without that distinction, every identified vulnerability tends to get treated as equally urgent, which is exactly the wrong outcome for a security team with limited time and limited staff. Two organizations running the same software can carry very different levels of real risk depending on what is actually exposed to the internet, what is exposed through a vendor, and what shows up in a search of open, public sources.

The View from the Inside vs. the View from the Outside

Most organizations already track internal records about their own environment. The problem is that those records describe intent and process, not what is actually visible to someone searching from the outside. Exposure assessment exists precisely because those two pictures rarely match.

Asset inventory versus internet-facing systems. An asset inventory documents what an organization believes it owns and runs. It says nothing about which of those systems can actually be reached from the open internet, which is a separate question that only external scanning can answer.

Known vulnerabilities versus exposed interfaces. A vulnerability list tracks weaknesses that have been identified and logged. An exposed interface is a weakness an outsider can actually reach and interact with right now, whether or not it ever made it onto that list.

Approved vendors versus vendor connections. An approved vendor list reflects who an organization has formally contracted with. The vendor connections visible externally often include integrations, subdomains, and access points that were never part of that formal review.

Managed accounts versus public credentials. A managed account list shows who is supposed to have access and through what system. Public credentials are the usernames, emails, and passwords tied to those same accounts that have already surfaced in breach data or open sources, whether or not anyone noticed.

Security controls versus personnel information. Technical controls like firewalls and access policies protect systems. They do nothing to prevent the personnel information, roles, routines, and affiliations that shows up in the open through social media and public records, and that an attacker can use without ever touching the network at all.

Where Exposure Assessment Fits in the Risk Picture

Exposure assessment doesn't happen in isolation. It's one piece of a larger risk assessment process, and understanding where it sits in that process is what keeps an assessment from turning into an unfocused list of findings with no clear sense of what matters most.

Risk assessment typically involves identifying what could go wrong, a software vulnerability, a misconfigured system, an exposed credential, or a gap in a vendor's own security, then weighing how likely that weakness is to be exploited and how severe the impact would be if it were. NIST's Guide for Conducting Risk Assessments frames this as identifying threats and vulnerabilities, then determining likelihood and impact to arrive at an overall risk determination.

Exposure assessment fits into that process without being a formally separate NIST step. It's the work of figuring out whether a given vulnerability is actually reachable, through what path, and by whom, which feeds directly into the likelihood side of NIST's calculation. A vulnerability that's completely unreachable has a very different likelihood of exploitation than the same vulnerability sitting exposed on the open internet, even though the vulnerability itself is identical in both cases.

That distinction matters in practice. Assessing exposure without connecting it back to what an exploited weakness would actually mean tends to produce a long list of findings with no clear sense of what to fix first, which is part of why CISA frames internet exposure reduction as a continuous process tied into an organization's broader risk management, not a one-time audit that gets filed away.

Why Exposure Assessment Matters

Security teams use exposure assessment to find internet-exposed management interfaces, routers, firewalls, and similar devices that should never have been reachable from the open internet in the first place. Critical infrastructure operators use it to find internet-connected industrial control systems that were never meant to be publicly reachable, but often are, due to legacy deployments or misconfigured remote access, much like the setup at Oldsmar.

Threat intelligence and OSINT teams use exposure assessment to understand what an adversary could learn about an organization's people or infrastructure just by searching public sources, without ever touching the internal network directly. That kind of visibility matters regardless of an organization's size, since attackers don't limit their reconnaissance to large, well-resourced targets.  

Vendor and supply chain relationships are an increasing focus of exposure assessment in their own right, since an attacker targeting one organization often finds it easier to go through a smaller, less secure vendor first. This is not a marginal concern: 35.5% of all data breaches in 2024 originated through a third-party compromise, an increase of 6.5 percent over the year before, which is exactly why vendor exposure deserves the same scrutiny as an organization's own infrastructure.

The Elements of a Complete Assessment

A thorough exposure assessment accounts for several things at once, and missing any of them tends to produce a finding that looks complete on paper but isn't useful for deciding what to fix first.

Where the exposure originates. This could be an internet-facing server, a cloud misconfiguration, a third-party vendor connection, an exposed management interface, or information about personnel sitting in the open on social media or public records.

How it gets from that source to whoever might exploit it. This is the pathway: a direct internet connection, a compromised vendor system, a phished employee, or simply a search engine that surfaces something that should have stayed private.

How access actually happens. This is the route, whether an exposed remote management port, a stolen credential, or a supply chain compromise through a trusted vendor. The Oldsmar case shows how ordinary this route can look in practice: no exploit was involved, only remote access software left reachable from the open internet.

How long the exposure persists, and how often it recurs. A system left internet-facing for months is a very different risk than one exposed briefly during a misconfigured deployment window.

Who or what is actually affected. This includes which systems, datasets, or personnel are exposed, and how sensitive they are, since a public-facing website and a system holding customer data carry very different consequences even if the technical exposure looks similar on paper.

Approaches to Exposure Assessment

There is more than one way to approach this work, and the right choice depends on how much precision a given decision requires. Some assessments are qualitative, describing exposure in relative terms like low, moderate, or high. This works well for an initial sweep across a large environment, but it doesn't hold up well when prioritizing which of hundreds of findings needs attention first.

Others adapt something like CVSS-style severity scoring to exposure specifically, balancing speed and precision. Fully quantitative assessments assign specific values, such as how many internet-facing assets exist or how long a given exposure has persisted, and are generally what's needed to justify a specific remediation decision.

There's also a difference in how uncertainty gets handled. A deterministic approach treats the current known environment as the full picture, which is simple to communicate but can go stale fast. A probabilistic approach instead accounts for the fact that new assets and exposures appear continuously, producing a picture that reflects a range of likely conditions.

CISA's own guidance leans toward the probabilistic approach, recommending continuous exposure assessment rather than a periodic review. Most mature security programs don't pick one approach and stop: they run a broad, lower-precision sweep first, then apply rigorous, quantitative assessment to the findings that actually warrant it.

The Assessment Workflow

A solid exposure assessment tends to move through five stages, and the order matters as much as the content of each one.

Defining the problem comes first: which systems, networks, vendors, and decisions this work needs to support. Without this step, the work tends to sprawl into an unfocused inventory exercise that never gets prioritized.

Collecting the data draws on both internal scans and external reconnaissance, since the two rarely show the same picture. One review of federal civilian infrastructure found more than 13k internet-facing hosts across over 50 organizations, hundreds of which were exposed in ways internal review had never flagged. 

Modeling and correlating the data connects what's visible externally with what's known internally, the kind of gap that left Oldsmar's dormant remote access software unnoticed for months.

Estimating the exposure combines all of that into an actual assessment: which assets are reachable, through what path, and how significant each one is.

Assessing the uncertainty comes last, being honest about what hasn't been checked and how quickly the picture could be out of date. This is frequently the weakest link in exposure programs, since environments change faster than most assessment cycles can keep up with.

Common Exposure Assessment Mistakes

A handful of mistakes keep undermining otherwise reasonable exposure assessments. Relying only on an internal asset inventory almost always misses systems that were stood up outside normal processes, forgotten after a project ended, or exposed through a vendor rather than directly. That's exactly what happened with Oldsmar's forgotten TeamViewer install. 

Treating exposure assessment as a one-time audit rather than a continuous process leaves organizations blind to new exposure that appears the moment something changes. Focusing only on technical systems while ignoring what's exposed about personnel through open, public sources is another common gap, even though that kind of exposure often enables a more targeted technical attack.

Underestimating vendor exposure, on the assumption that a contractor's security is someone else's problem, frequently becomes the actual entry point into a network. And presenting findings without prioritization produces a long list of exposed assets with no clear sense of which ones actually matter most.

Exposure Assessment Best Practices

Good data matters more than a sophisticated model, since an assessment built on an outdated asset inventory will miss exactly the kind of shadow infrastructure that tends to be the most exposed. Assumptions should be written down clearly, so anyone reviewing the work later can judge whether they were reasonable.

Exposure needs to be checked from the outside, not just the inside, since an internal asset list rarely matches what's actually visible from the open internet. It also helps to know which exposures actually matter most, weighing sensitivity and business impact rather than technical exposure alone.

None of this should be treated as a one-time task. CISA's own guidance is explicit that exposure assessment needs to be an ongoing, continuous process rather than an annual checkbox, since networks and vendor relationships change constantly.

The Takeaway

Exposure assessment is the part of risk assessment that turns a theoretical weakness into a grounded, prioritized picture of what an adversary could actually reach and exploit. Done properly, it means looking at the environment from the outside as well as the inside, and being honest about how quickly that picture can go stale.

Organizations that treat this as a continuous discipline, rather than an annual audit, are in a far stronger position to close gaps before an adversary finds them first, the kind of gap that turned a forgotten remote access tool into a national news story.

FAQ

What is exposure assessment?

It is the process of identifying what systems, data, or personnel are actually reachable from outside an organization, through what path, and how significant that reachability is given the sensitivity of what's exposed.

How is exposure different from a vulnerability?

A vulnerability is a weakness that could potentially be exploited. Exposure is whether that weakness is actually reachable by an outside party. A serious vulnerability on an isolated internal system carries far less real risk than a minor one on an internet-facing system.

Why does open-source intelligence matter for exposure assessment?

Open-source and external reconnaissance techniques show an organization what is actually visible from outside, which frequently differs from what an internal asset inventory shows.

Who typically needs to do exposure assessment?

Security teams, critical infrastructure operators, threat intelligence and OSINT teams, and any organization managing third-party vendor relationships all rely on exposure assessment to understand their real attack surface.

How often should exposure assessment happen?

CISA's own guidance recommends treating it as a continuous, ongoing process rather than a periodic review, since networks and environments change often enough that a snapshot taken months ago can no longer be trusted.

Want to see how exposure looks from the outside in? Book a personalized demo with one of our specialists and discover how SL Crimewall helps security teams map the exposure traditional scans miss, personnel, vendor relationships, and infrastructure connections hiding in the open.