External attack surface management: a practical guide

External Attack Surface Management (EASM) continuously discovers and controls assets visible from the internet: domains, subdomains, IP addresses, certificates, cloud services, applications and APIs.

Scanning one known range misses the system most likely to cause trouble: a legacy supplier panel, test subdomain, storage left after migration or server purchased outside the normal process.

Discovery needs multiple seeds

Start with official domains, ASNs, IP ranges, cloud organisations, certificates, repositories and brand names. Expand relationships through certificate SANs, nameservers, historical DNS and other technical identifiers.

Automated correlation is a hypothesis, not proof of ownership. Shared hosting and SaaS produce false positives. Confirm assets through technical owners or organisational evidence.

Inventory requires ownership and lifecycle

Record for every asset:

• business and technical owner;
• environment and criticality;
• data and function;
• supplier and contract;
• exposed protocols and technology;
• last verification date;
• maintenance or retirement plan.

“Unknown” is a result requiring investigation, not a permanent inventory category.

Risk-based prioritisation

An open port is not automatically a vulnerability. Prioritise:

• administration and remote access;
• actively exploited CVEs;
• default or expired credentials;
• dangling DNS and subdomain takeover;
• public storage containing data;
• ownerless unauthenticated APIs;
• unsupported software;
• exposed secrets and repositories.

Combine exposure with exploitability, asset value and mitigating controls through the vulnerability-management process.

EASM is a closure process

Every finding needs an owner, due date and verification trail. Remediation may be patching, network restriction, DNS takeover, migration, formal acceptance or service removal.

Retest externally after closure. A completed ticket does not prove that the port, domain or bucket is no longer reachable.

Integrate with change

Effective EASM receives events from domain registration, cloud organisations, CI/CD and CMDB. It detects new certificates, public endpoints and DNS-provider changes quickly.

Define an emergency path for ownerless assets while controlling the risk of disabling a legitimate service. Ownership evidence and an escalation contact are essential.

Implementation checklist

1. Define organisational seeds and brands.
2. Discover domains, IPs, certificates, cloud and SaaS.
3. Confirm ownership and remove false positives.
4. Assign owner, criticality and lifecycle.
5. Prioritise risk rather than port count.
6. Integrate ticketing, CMDB and vulnerability management.
7. Verify fixes from the internet.
8. Measure time from asset appearance to identification and control.

EASM complements organisational OSINT. Its outcome should be a smaller attack surface, not merely a larger inventory.

---

Validating a discovered asset

A scanner result is a hypothesis until ownership is confirmed. Correlate DNS, certificates, cloud data, repositories and the CMDB, then contact the domain or service owner when uncertain. Do not invasively test an asset without clear scope and authorisation. Its record should include business owner, environment, data, provider and last-verification date.

The key metric is not hosts found but time from exposure to ownership and risk closure. Monitor new subdomains, certificates, administrative ports, dangling DNS and expired services. Confirm closure from the Internet because a cloud-console change does not always remove the public path.

Removal must distinguish required, unknown and abandoned assets. Do not disable a system merely because it is absent from the CMDB; it may serve a customer or supplier integration. Restrict exposure, preserve evidence and escalate through domain ownership, cloud account or cost centre first.

Sources: NIST CSF 2.0, CISA CDM, NIST SP 800-53 Rev. 5.