External Attack Surface Management: What Good Looks Like

An external attack surface management program is working when exposure shrinks faster than it appears. Most programs stop well short of that. They produce an inventory of internet-facing assets, sort it by a severity score, and send a spreadsheet to a team that may or may not own what is on it.

That is discovery, and it is roughly the first third of the job. What decides whether the program changes outcomes is everything after it: knowing who owns each asset, establishing whether the exposure can actually be used against you, and closing it. This article sets out what each stage looks like when it works, where it usually breaks, and which measures separate a program from a scan.

Why the outside view carries weight

Attackers do not start with your architecture diagram. They start with what answers on the internet. The current evidence says that is where most intrusions begin.

Verizon’s Data Breach Investigations Report now puts vulnerability exploitation at 31% of initial access vectors, ahead of stolen credentials for the first time. Coverage of the same report put credential abuse at 13%.

Mandiant’s M-Trends report found exploits to be the most common initial infection vector, at 32% of intrusions, for the sixth consecutive year.

The same report estimates that mean time to exploit has turned negative, at about seven days before a patch is available. In practice, exploitation often starts before a fix exists, so patching speed alone cannot be the control.

Mandiant also reports threat clusters targeting edge and core network devices such as VPNs and routers, which typically lack EDR telemetry. These are the systems where you are most exposed and see least.

On the defender side, coverage of the Verizon report states that only 26% of vulnerabilities in CISA’s Known Exploited Vulnerabilities (KEV) catalog were fully remediated, with a median of 43 days to full remediation.

These figures come from different populations and methods, so they should not be added together. Read together, they describe one pattern: attackers move first on internet-facing systems, and the organizations that own those systems are slow to close what is known to be exploited.

Four stages, and what each should produce

A useful way to test any program is to ask what each stage hands to the next.

1. Discover

Discovery starts from what you know and expands outward: registered domains and brands, IP ranges and ASNs, cloud accounts, subsidiaries and recent acquisitions. It then widens through DNS data, public certificate transparency logs (the open record of issued TLS certificates, defined in RFC 6962), passive internet scan data and cloud provider APIs. Certificate logs are especially useful because they reveal hostnames that someone requested a certificate for and never entered in any inventory.

The output is a list of candidate assets, each with a confidence score for whether it belongs to you. A list without that score forces analysts to treat a lookalike domain and a production gateway the same way.

2. Attribute

Attribution connects each asset to a business owner, a function, an environment and what it touches: identity providers, sensitive data, internal networks. This is the stage most programs underinvest in, and it is where the value is. An unowned asset cannot be patched, retired or accepted. It can only be reported.

The output is a confirmed asset with a named team that has agreed to receive findings. Assets that cannot be attributed should escalate as exposure in their own right.

3. Validate

A scanner that reads a version banner and matches it to a vulnerability database is reporting a hypothesis. Validation confirms the service is reachable, identifies what it really is, checks whether authentication stands in front of it, and tests whether the specific condition for exploitation exists. Done safely, it removes a large share of false positives before they reach an engineering queue and builds the trust that makes the next ticket get read.

The output is confirmed exposure with evidence, or a clear record that the finding is unconfirmed.

4. Prioritize and close

Severity scores describe a flaw in general. Priority describes your situation. Rank by whether the flaw is known to be exploited (KEV listing, vendor advisories, threat intelligence), whether it is reachable without authentication, what the asset connects to, and what compensating controls exist. Exploit prediction scores such as EPSS from FIRST can help as one input, not as the decision.

Closure has three legitimate forms: patch, mitigate, or remove. Disabling an exposed management interface or restricting it to known addresses is a valid close when a patch is unavailable. What is not valid is closing a ticket without confirming the exposure is gone. The output is verified closure, or an accepted exception with an owner and an expiry date.

Where the risk appears

Exposure	Why it is missed	What to check
Edge and remote access devices	Often run by network teams outside the vulnerability program; limited endpoint telemetry.	Firmware against vendor advisories and KEV; management interfaces reachable from the internet; logs actually collected from the device.
Forgotten subdomains and dangling DNS	DNS records outlive the services they pointed to. A record aimed at a deprovisioned cloud or SaaS resource can sometimes be claimed by someone else.	Records pointing to resources you no longer hold. OWASP’s Web Security Testing Guide covers subdomain takeover testing.
Cloud services and storage	Created by product teams outside central IT, sometimes in accounts security does not know exist.	Public endpoints per cloud account, each mapped to an account owner.
Non-production environments	Staging, demo and test systems are reachable from the internet and often carry weaker authentication and real data.	Authentication strength compared with production; data actually present; trust paths into production.
Acquired and third-party-hosted assets	Mergers leave registrar accounts, domains and hosting contracts unmapped. Agencies host campaign sites under your brand.	Domain portfolio and registrar accounts; brand-bearing sites on infrastructure you do not control.
Login, SSO and API endpoints	The identity boundary becomes visible from outside here. Legacy protocols and unmanaged exceptions hide in them.	Authentication methods, MFA coverage and legacy protocol exposure.

Edge devices deserve a specific note. Joint guidance from the UK National Cyber Security Centre and the cyber agencies of Australia, Canada, New Zealand and the United States asks manufacturers to ship forensic logging and protective monitoring features on by default. That helps, but the guidance puts the burden on producers. Owners still need to confirm that logs from these devices reach their monitoring, because a device that cannot be investigated after compromise is a long-term liability.

What good looks like

Dimension	What usually passes for it	What good looks like
Coverage	Percentage of known assets scanned.	The share of discovered assets that were not in any inventory, tracked as a trend. A falling unknown share means the inventory is catching up with reality.
Ownership	An asset list with “IT” as owner.	A named team per asset that accepts findings. Unattributed assets trigger escalation instead of sitting in a list.
Validation	Scanner output forwarded as findings.	Findings confirmed as reachable and exploitable before they enter an engineering queue, or labeled unconfirmed.
Prioritization	CVSS sorted high to low.	Known exploitation, authentication requirements, what the asset connects to and compensating controls, combined.
Speed	One patch SLA for everything.	A shorter clock for actively exploited, internet-facing issues, with mitigation accepted as closure when no patch exists.
Verification	Ticket closed means closed.	Closed when rediscovery confirms the exposure is gone.
Change detection	Periodic scans.	New exposure surfaced soon after it is created, tied to DNS, certificate and cloud account changes.

Measures worth reporting

These are recommended measures, not benchmarks. Set targets from your own baseline.

Share of confirmed assets with a named owner.

Unknown-asset rate: confirmed assets found by discovery that were absent from inventory.

Median time from discovery to attribution.

Time from confirmed exposure to verified closure, reported separately for actively exploited issues.

Recurrence: exposure that returns after closure, which points to a process gap rather than a technical one.

Exceptions that expired without a decision.

Connecting exposure to threat and attack paths

Two questions turn an exposure list into a decision. First, is anyone exploiting this class of weakness now? Threat intelligence answers that, and it is why exposure management programs that ignore it end up sorting by severity. Second, what does this asset reach? An exposed system that holds a privileged credential or sits one hop from an identity provider is a different problem from the same system in isolation. Attack path analysis answers that question, and it is where an external finding connects to the identity, cloud and application boundaries that the rest of the security program protects.

Where programs fail

•  Scope is treated as given. The program scans the domains in the CMDB. The exposure sits in the domains someone forgot.

•  Findings outrun ownership. Volume goes up, response goes down, and the program is blamed for noise it did not create.

•  No concept of intended exposure. Some services are meant to be public. Without a record of what should be reachable, every discovery looks like a problem or none does.

•  The identity layer is separate. Exposed login and management surfaces are identity boundary problems and belong in the same conversation as identity controls.

•  Discovery runs on a schedule, change does not. Teams deploy and create DNS records daily. A monthly cycle describes the past.

Questions to test your program

**1.  **How many internet-facing assets did discovery find last cycle that were not in your inventory, and who found out why?

**2.  **What share of confirmed assets has a named owner who has acknowledged it?

**3.  **Which edge devices send logs to your monitoring, and which do not?

**4.  **If a vulnerability on the KEV list affected an internet-facing system today, how long until it is fixed or mitigated, and who decides?

**5.  **When did you last confirm that a closed exposure was actually gone?

**6.  **Which non-production systems are reachable from the internet, and what trust do they have into production?

**** A practical first step: choose one business unit, run discovery from its known domains and IP ranges, and count how many confirmed assets have no owner. That number says more about program maturity than the total asset count does.

Sources

**1.  **Verizon. Data Breach Investigations Report (initial access vector findings). https://www.verizon.com/business/resources/reports/dbir/

**2.  **SC Media. Coverage of the Verizon DBIR: vulnerability exploitation as top initial access vector and KEV remediation figures.

**3.  **Google Cloud Threat Intelligence (Mandiant). M-Trends report: initial infection vectors, exploitation timing and edge device targeting. https://cloud.google.com/security/resources/m-trends-executive-edition

**4.  **UK National Cyber Security Centre with partner agencies from Australia, Canada, New Zealand and the United States. Guidance on securing edge devices and forensic and monitoring specifications for device producers. https://www.ncsc.gov.uk/news/cyber-agencies-unveil-new-guidelines-to-secure-edge-devices-from-increasing-threat

**5.  **CISA. Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

**6.  **IETF. RFC 6962: Certificate Transparency. https://www.rfc-editor.org/rfc/rfc6962

**7.  **FIRST. Exploit Prediction Scoring System (EPSS). https://www.first.org/epss/

**8.  **OWASP. Web Security Testing Guide. https://owasp.org/www-project-web-security-testing-guide/