EASM: Finding and Owning the Assets Nobody Claims

Q: What is external attack surface management and how is it different from vulnerability scanning?

Vulnerability scanning tests a list of assets you already know about for known weaknesses. External attack surface management starts from the opposite direction: it discovers, from the internet's point of view, every asset that can be attributed to your organisation — domains, subdomains, IP ranges, certificates, cloud resources, SaaS tenants, exposed management interfaces — including the ones missing from your inventory, and then determines whether each should exist, who owns it, and what state it is in. The difference matters because a large share of initial access now comes through exposed assets nobody was scanning, such as a forgotten staging host, an acquired company's VPN, or a DNS record pointing at a deleted cloud resource. Scanning finds vulnerabilities in the known; EASM finds the unknown and gives it an owner so that scanning and patching can apply.

Q: Where do unknown internet-facing assets usually come from?

The recurring sources are shadow cloud accounts created on corporate cards outside the organisation's cloud hierarchy; third-party and agency deployments under company subdomains that outlive the contract; dangling DNS records pointing at released cloud IPs, deleted storage buckets or decommissioned platform apps; mergers and acquisitions that bring in domains, IP ranges, certificates and legacy appliances nobody inventoried; staging, preview and QA environments left running, often with production data; employee-installed developer tools such as CI runners, notebooks and dashboards on public IPs; edge and management devices such as VPN concentrators and firewall admin interfaces owned by a network team whose records never reached security; and lapsed or defensive domain registrations. Each source leaves different attribution evidence — billing records, DNS change history, procurement contracts, cloud tags, SSO logs — and a good programme integrates those sources rather than relying on scan data alone.

Q: Why is attribution the hard part of EASM rather than discovery?

Discovery is largely solved by public data. Certificate transparency logs record every publicly trusted certificate, passive DNS records every name that has resolved, registrars publish WHOIS data, cloud providers publish their IP ranges, and internet-wide scanners index every listener. Open tools and commercial platforms fuse these sources and will find your exposed assets within days. What none of them can do is say which team inside your company is accountable for a given host, whether the business still needs it, and who is authorised to turn it off. Until an asset has an owner it cannot be patched, monitored or decommissioned, and any vulnerability finding attached to it stays a number in a report. Attribution requires internal signals — DNS change history, cloud account ownership and tags, identity-provider application inventories, procurement and billing records, code repositories referencing the hostname — scored into a confidence and stored with the evidence so that disputes over ownership can be settled.

Q: What is a dangling DNS record and how does it lead to subdomain takeover?

A dangling DNS record is a CNAME or A record that still points at a resource that no longer exists: a cloud IP address that was released, a storage bucket or platform app that was deleted, or a vendor host whose contract ended. Because the name still resolves and the target namespace is often first-come-first-served, an attacker can create a resource with the same name at the provider and the organisation's subdomain now serves the attacker's content under the organisation's brand, cookies and, in some configurations, certificates. Microsoft's guidance on the subject describes exactly this pattern for Azure resources. The asset that gets exploited no longer exists — only its name does — which is why scanning for vulnerabilities cannot fix it. The control is a lifecycle rule: DNS records are deleted before the resources they point to, enforced in the decommissioning workflow and in cloud change pipelines, and EASM continuously checks for names whose targets do not resolve to something the organisation controls.

Q: How often should an organisation run external asset discovery?

CISA's Binding Operational Directive 23-01, issued in October 2022, gives a defensible floor for US federal civilian agencies: automated asset discovery at least every 7 days, vulnerability enumeration across all discovered assets at least every 14 days, ingestion of results into the central dashboard within 72 hours, and the ability to start on-demand discovery within 72 hours of a request. For most enterprises those cadences are a reasonable minimum for a weekly sweep. Cloud-heavy estates need something faster, because a new public listener can be created by a developer and found by internet-wide scanners within an hour; there, discovery should be event-driven from cloud audit logs, DNS zone changes and certificate transparency subscriptions, so that a new asset is attributed and assigned a state within hours, with the weekly external sweep as the backstop that catches what internal telemetry missed.

Q: What should happen to assets that nobody claims?

They should be decommissioned by default after a timed notice period. This is the single policy decision that determines whether an EASM programme reduces risk or merely measures it. Without a default-to-off rule, the ownerless queue grows indefinitely, because there is never anyone arguing for turning an asset off and always someone worried that it might matter. The workable pattern is a notice to the most likely owner with the attribution evidence attached, a fixed window such as 14 days, and then a safe decommission sequence: delete the DNS record first, then revoke the certificate, then a monitored soak period during which the asset is dark but recoverable, and only then delete compute and storage. That sequence means turning off the wrong asset costs an hour of recovery rather than an outage, which is what makes the policy politically survivable.

Q: Should EASM findings be prioritised by CVSS score?

No. The first prioritisation question for an externally exposed asset is not how severe its vulnerability is but whether the asset should exist at all; a critical CVE on a host that should have been deleted two years ago has one correct remediation and it is not a patch. For assets that should exist, prioritise by exploitation evidence rather than theoretical severity: cross-reference exposed technologies against CISA's Known Exploited Vulnerabilities catalog and use EPSS probabilities, because attackers exploit what is exposed and being exploited in the wild, and the DBIR and M-Trends data both show exploitation of internet-facing vulnerabilities as the leading initial access vector. Edge and management devices such as VPN concentrators deserve particular attention, since KEV-listed vulnerabilities in that category are typically exploited within days of disclosure.

Q: How does EASM relate to breach and attack simulation, CIEM and the security data lake?

They are adjacent layers of the same problem. EASM produces the authoritative inventory of what is exposed and who owns it; breach and attack simulation consumes that inventory as its target list to test whether controls actually stop attacks against those assets; cloud infrastructure entitlement management addresses the parallel sprawl of permissions inside the cloud, produced by the same organisational gap in which many systems record what exists and none record who is accountable. The security data lake is where they meet: DNS logs, cloud audit events, identity-provider inventories and EASM findings are correlated there, which is how external scan results get corroborated against internal telemetry and how a newly discovered listener can be treated as an incident-grade event rather than a weekly report line. Buying EASM without integrating it into those systems produces a fourth dashboard rather than a governed attack surface.