Attack surface management, including the half you do not own.

Your attack surface is the complete set of points where an unauthorized party could attempt to enter, extract data from, or interfere with your systems. It is usually split three ways:

• The external, or digital, attack surface — everything reachable from the internet without credentials. Domains, subdomains, IP ranges, exposed services and ports, cloud storage, certificates, login portals, APIs, third-party scripts running on your pages.
• The internal attack surface — what becomes reachable once someone is inside: shares, lateral paths, over-privileged accounts, unsegmented networks.
• The human attack surface — the people who can be phished, impersonated, or socially engineered, and the information about them that makes that easier.

The definitional trap is the word “your”. An attack surface is defined by reachability, not by ownership: the marketing site an agency stood up on a domain you paid for, the SaaS tenant a team bought on a card, the supplier portal branded in your name, the acquired company’s legacy estate nobody has decommissioned. None of those are on your asset register. All of them are on your attack surface, and an attacker draws no distinction.

Attack surface management is the practice of continuously discovering what is exposed, deciding what should be, and removing or protecting the rest. Four activities, repeating:

1. Discovery — find what exists, including what you did not know about.
2. Inventory and attribution — establish what each asset is, who owns it, and whether it is genuinely yours.
3. Assessment and prioritization — what is exposed, how badly, and what to fix first.
4. Reduction and monitoring — remove what should not be there, protect what should, and watch for the next change.

The reason this cannot be an annual exercise is that attack surfaces do not grow by plan. They grow by ordinary work: a developer opens a port for a demo, a certificate renews on a subdomain nobody remembers, a migration leaves the old environment running, a supplier stands up a portal in your name, a team buys a SaaS product and connects it to your identity provider. Each is individually reasonable. Collectively they are the reason a penetration test scoped from your asset register misses the thing that eventually gets exploited.

The category has acquired a shelf of acronyms — EASM for the external surface, CAASM for a consolidated asset view, ASM as the umbrella. They matter less than the question underneath: can you enumerate what is reachable in your name today, and would you know tomorrow if that changed?

Attack surface discovery starts from what is publicly knowable about an organization and works outward — the same starting position an attacker has, and deliberately so. An inventory built from your own records can only contain what you already knew; the assets that cause incidents are by definition not in it.

Discovery typically works from:

• Domains and DNS — registration records, subdomain enumeration, historical DNS, and the dangling records that point at deprovisioned cloud resources somebody else can now claim.
• Certificates — certificate transparency logs are a public, near-real-time record of hostnames being brought online, including ones nobody announced.
• IP space and hosting — netblocks, autonomous system data, and cloud tenancy attributed back to the organization.
• Service and technology fingerprinting — what is listening, what software it runs, what version, and whether it should be exposed at all.
• Corporate structure — subsidiaries, brands, acquisitions and regional entities, each carrying an estate that may never have been integrated.

Attribution is the difficult half and the one that separates useful tooling from noisy tooling. Deciding that a host is yours — rather than a name-similar company, a customer, or a shared platform — is a judgment call, and a discovery system that gets it wrong in either direction produces either false alarms or false comfort. When evaluating tools, ask how attribution is decided and how you dispute it; attack surface management tools compares the field on exactly that.

A one-off assessment tells you what was exposed on a Tuesday. It is genuinely useful once, and its value decays from the moment it is delivered — because the exposures that matter are created by ordinary change, and change does not wait for the next engagement.

Attack surface monitoring is the same discovery running continuously, with alerting on what is new or newly wrong: a service that appeared, a port that opened, a certificate about to expire, a technology that just picked up a critical vulnerability, a host that moved. What makes it a control rather than a feed is triage — who receives it, how quickly, and what they are expected to do. An alert stream nobody owns produces the same outcome as no monitoring at all, more expensively.

Two measures are worth tracking, and neither is the raw asset count: time from exposure appearing to being detected, and time from detection to remediation. Both are reportable to a board, both improve with practice, and both connect a security budget to something a non-specialist can evaluate.

The path into an organization increasingly does not start at that organization. It starts at a supplier with legitimate access, a managed service provider with administrative credentials, a software vendor whose update mechanism is trusted, or a subsidiary acquired with an estate that was never assessed. From the attacker’s side these are not adjacent to your attack surface — they are your attack surface, because they lead to the same place.

The awkward consequence is that managing your own exposure well is a partial control. You can hold your external surface to a high standard and still be reached through a supplier whose standard you never saw. And the assurance process most organizations rely on for that — a questionnaire, answered annually, by the supplier — is the one instrument in security that gets its data from the party with the least interest in an unflattering answer.

The same discovery techniques work on a supplier, without their cooperation, because they operate on public evidence. That is the whole idea behind rating third parties from the outside: you can see a vendor’s exposed services, expiring certificates, leaked credentials and infrastructure changes on the day they happen, and you never have to wait for a form to come back. Supplier risk management covers how that works, and third-party risk management covers the wider program it belongs to.