Attack Surface Management Guide

Attackers find your forgotten servers, dangling subdomains, exposed admin panels and leaked keys with the same internet-wide scans and public data you could be using, and they often find them first. Attack surface management (ASM) is the continuous discovery, prioritisation, validation and remediation of everything an attacker can reach or learn about you. This guide covers external attack surface management (EASM), cyber asset attack surface management (CAASM) and how they fit with vulnerability management, the discovery techniques that matter (DNS, certificate transparency, cloud accounts, code repositories), reducing exposed services, and the metrics that show the surface is shrinking. It is written for vulnerability management, security operations and cloud teams, and is vendor-neutral.

Key takeaways

• Inventory is the precondition. CISA calls continuous and comprehensive asset visibility "a basic pre-condition for any organization"; you cannot patch, monitor or retire what you do not know exists.
• EASM and CAASM answer different questions. EASM looks from the internet inwards for what is exposed; CAASM joins your internal tools' data to show what you own and where controls are missing. Most organisations need both views.
• Reduction beats monitoring. Management interfaces, file shares and remote access protocols that do not need to be on the internet should come off it, not be watched.
• Secrets are attack surface. API keys and machine credentials in public repositories, container images, buckets and .env files are as exploitable as an open port.
• Every finding needs an owner. Discovery without ownership produces a growing list of unknown assets; tie each asset to an accountable team and a decommissioning process.

What attack surface management covers

An attack surface is the set of assets, services, identities and data an attacker can reach or learn about. ASM differs from vulnerability scanning in its starting point: scanners test the assets you give them, while ASM finds the ones you did not know to give them. The terms in the market overlap, so define them by the question they answer.

Gartner's term continuous threat exposure management (CTEM) describes a programme cycle rather than a tool, usually summarised as scoping, discovery, prioritisation, validation and mobilisation. Treat it as a useful frame: EASM and CAASM feed discovery, vulnerability and threat data feed prioritisation, testing feeds validation, and remediation workflows are mobilisation.

CISA's BOD 23-01 shows how discovery and testing differ in practice. It defines asset discovery as non-intrusive and usually requiring no special privileges, and vulnerability enumeration as needing privileged access through credentialed scans or agents. It requires US federal agencies to run automated asset discovery every 7 days across their entire IPv4 space and vulnerability enumeration every 14 days, including on roaming devices.

Discovering the external attack surface

Start from what you know (registered domains, IP ranges, cloud accounts, brand names) and expand your digital footprint by pivoting on each finding. The NCSC's asset management guidance lists domain names, IP address ranges, digital certificates and social media accounts as part of an organisation's internet presence, and advises combining active and passive data sources because procurement records miss free cloud services. Each discovery source has an attacker equivalent in MITRE ATT&CK's Reconnaissance tactic, which is the point: you are running the same reconnaissance before they do.

Open-source tooling covers much of this: masscan for fast port scanning, subfinder for passive subdomain enumeration, httpx for probing web services, Aquatone for screenshots of web hosts, and theHarvester, Recon-ng and SpiderFoot for OSINT collection. Run them only against assets you own or are authorised to test, and record the authorisation; internet scanning of third-party infrastructure can breach contracts and law.

Attribution is the hard part. A hostname on a shared CDN or SaaS platform may not be yours, and an IP that was yours last month may now belong to another cloud customer. Confirm ownership (DNS control, cloud account, contract) before raising a finding, and record a confidence level and a "last seen" timestamp, as the NCSC suggests for asset records.

Certificate transparency, DNS and subdomain takeover

Certificate transparency (CT), specified in RFC 6962 and updated as version 2.0 in RFC 9162, requires publicly trusted certificates to be recorded in "publicly auditable, append-only, untrusted logs of all issued certificates." RFC 6962 describes monitors that watch logs for certificates of interest, which is exactly what you want for your domains: every new certificate reveals a hostname, and an unexpected one reveals either shadow IT or mis-issuance. Use CT monitoring for discovery and as an alert source; remember that attackers read the same logs, so internal names in public certificates are public.

Subdomain takeover is the most common DNS finding with real impact. Microsoft's guidance describes it plainly: "A subdomain takeover can occur when you have a DNS record that points to a deprovisioned Azure resource," and "CNAME records are especially vulnerable." An attacker provisions a resource with the same platform hostname in their own subscription and receives your traffic. ATT&CK records the same pattern under T1584.001 Domains: "Subdomain hijacking can occur when organizations have DNS entries that point to non-existent or deprovisioned resources." The consequences go beyond defacement:

• Session theft: cookies scoped to the parent domain are sent to the hijacked subdomain.
• Valid TLS: Microsoft notes that the attacker "can use the hijacked subdomain to apply for and receive a valid SSL certificate".
• Secret leakage: if applications send OAuth credentials or other secrets to the subdomain, Microsoft advises treating them as exposed.
• Phishing and mail: authentic-looking subdomains and dangling MX records support phishing and mail interception.

Prevention is a process fix more than a tool: add "Remove DNS entry" to the decommissioning checklist, delete the record before or with the resource, use provider alias records that empty automatically when the target is deleted, use custom domain verification records where platforms offer them, and keep a catalogue of DNS records pointing at cloud and SaaS hostnames with an owner for each. See the DNS Security Guide.

Exposed services and admin interfaces

CISA's BOD 23-02 targets the most dangerous class of exposure: networked management interfaces of routers, switches, firewalls, VPN concentrators, proxies, load balancers and out-of-band server management such as iLO and iDRAC, reachable over HTTP, HTTPS, FTP, SNMP, Telnet, TFTP, RDP, rlogin, RSH, SSH, SMB, VNC or X11. Agencies must, within 14 days of discovery, either remove the interface from the internet or protect it with "a policy enforcement point separate from the interface itself." That rule is a sound default for any organisation.

The pattern repeats across incidents: the ShadowRay attacks on exposed Ray AI clusters stole cloud credentials and AI tokens, and the Tesla Kubernetes cryptojacking began with an open console holding AWS credentials. See the Firewall Management Guide and the ZTNA Guide.

Where identity fits: exposed secrets and NHI credentials

For many organisations the most exploitable part of the external attack surface is not a port but a credential: an API key in a public repository, a cloud access key in website JavaScript, a token baked into a container image, or a .env file served by a web server. These non-human identity (NHI) credentials often carry broad, long-lived permissions and no MFA. Include them in ASM scope:

• Public code and packages: scan your organisation's and employees' public repositories, packages and gists. GitHub secret scanning "scans your entire Git history on all branches" and runs automatically for free on public repositories, and its partner programme notifies providers "so they can take action, such as revoking the credential." The Toyota T-Connect key exposure sat on public GitHub for five years.
• Web roots: test your own hosts for exposed .git directories and .env files. The 230 million AWS cloud environments campaign fed on exposed .env files, and misconfigured Git servers leak deployment credentials at scale.
• Container images and front-end code: the Docker Hub secrets leak exposed cloud, CI and AI keys in public images, and Football Australia's AWS keys in website code opened 127 storage buckets.
• Open databases and storage: the Moltbook database exposure leaked 1.5 million AI agent API keys from an open database.
• Shadow AI and SaaS: AI tools and agents adopted outside IT hold API keys and OAuth grants that no inventory records. See the Shadow AI Discovery Guide.

When a secret is found, the response is revocation and rotation first, history rewriting second; GitHub's own advice is to "rotate the affected credential immediately". Then trace its use since the exposure date. See the Secrets Management Guide, the API Key Management Guide and the Leaked Credential Response Playbook.

Prioritising and validating findings

ASM produces volume. Prioritise on exposure and consequence, not on count:

1. Confirm ownership: discard or route assets you cannot attribute; never scan or test what you do not own.
2. Exploited or exploitable now: internet-facing assets running software with a CISA Known Exploited Vulnerabilities (KEV) entry, management interfaces, valid leaked secrets and dangling DNS records go first.
3. Asset criticality: NIST CSF 2.0 ID.AM-05 asks that assets be "prioritized based on classification, criticality, resources, and impact on the mission". A login page for the payroll system outranks a marketing microsite.
4. Validate safely: confirm the service is reachable, the version is affected and the secret is live (provider validity checks or a harmless authenticated call) before escalating. ID.RA-01 asks that vulnerabilities be "identified, validated, and recorded".
5. Test attack paths periodically: penetration tests and red team exercises show whether exposures chain into something serious; the NCSC recommends that tests include the identification of devices, which checks the inventory itself.

Low-cost external help exists for some sectors: CISA's Cyber Hygiene Vulnerability Scanning service, free to eligible US public bodies and critical infrastructure, "continuously monitors and assesses internet-accessible network assets" with weekly reports and ad hoc alerts on "potentially risky services and known exploited vulnerabilities". CISA states that organisations "typically reduce their risk and exposure by 40% within the first 12 months".

Remediation workflows and ownership

• Route to owners automatically: map assets to teams through cloud account tags, DNS zone ownership and CMDB records, and open tickets in the owner's queue with evidence and a due date.
• Set exposure SLAs: for example, management interfaces and valid leaked secrets within 24 to 72 hours, dangling DNS within days, unknown assets attributed or removed within 14 days (matching BOD 23-02's 14-day window).
• Prefer removal: decommission unused assets rather than hardening them; CIS Safeguard 1.2 expects unauthorised assets to be removed, denied remote connection or quarantined, with the process run weekly.
• Fix the source: for each recurring finding, change the process that produced it, such as adding DNS clean-up to decommissioning, account-level public access blocks for storage, pre-commit and push-time secret scanning, and SSO in front of new admin tools.
• Close the loop: rescan after remediation and close the ticket only on verified absence.
• Handle third parties: agencies, suppliers and acquired companies often run your domains. Put ASM findings and response times into contracts. See the Third-Party Access Guide.

Implementing an ASM programme

1. Seed (weeks 1 to 2): collect registered domains, registrar accounts, IP ranges, cloud accounts and subscriptions, code hosting organisations and brand names from IT, finance and legal. Name a single accountable owner, as the NCSC recommends.
2. Discover passively (weeks 2 to 4): CT logs, passive DNS, WHOIS and scan databases. No traffic touches your assets, so this needs no change approval and cannot break anything.
3. Attribute and baseline: confirm ownership, assign owners, and record the baseline counts you will measure against.
4. Scan actively, in a pilot: start with low-rate port and service scans of a few owned ranges, with the network and SOC teams informed so alerts are expected. Expand once you have confirmed no service impact; roll back by pausing schedules and reducing rate.
5. Connect CAASM sources: join cloud, endpoint, identity and scanner data to find coverage gaps, such as servers without EDR or cloud accounts outside central logging.
6. Operationalise: owner routing, SLAs and exceptions with expiry dates, then weekly reporting to the owner's management line.
7. Reduce: run quarterly campaigns against the largest categories (exposed management interfaces, unused domains, public buckets), tracking the count down.

Choosing an approach

• EASM first when the main risk is unknown internet exposure: many domains, frequent marketing sites, acquisitions or decentralised cloud adoption.
• CAASM first when you know your perimeter but cannot answer coverage questions (which assets lack EDR, patching or logging) because data is spread across many tools.
• Small organisations: a domain list, CT monitoring, free secret scanning on public repositories, a scheduled external port scan of your own IP ranges and account-level public access blocks cover most risk. Eligible public bodies can use free national services such as CISA Cyber Hygiene.
• Large organisations: a commercial or internal platform pays off when you need continuous discovery across hundreds of domains and accounts, ownership mapping and ticket integration. Judge products on attribution accuracy and false positive rate, not raw asset counts.
• Build or buy: open-source tooling is capable but the effort is in attribution, deduplication, ownership and workflow, not in scanning.

Detection and measurement

Alert on change, not just state: new certificates for your domains, new DNS records pointing to cloud platforms, newly opened ports on owned ranges, storage policies switched to public, and new secrets detected in code. Feed these to the SOC alongside DE.CM-01 network monitoring. Metrics:

• Unknown asset rate: share of discovered internet-facing assets not in the inventory, and time to attribute them.
• Exposed management interfaces: count over time, with a target of zero.
• Mean time to remediate exposures: by category, against SLA.
• Dangling DNS records: open count and age.
• Valid secrets found externally: count, time from exposure to revocation, and repeat offenders by team.
• Coverage gaps: percentage of assets missing EDR, patching or logging, from CAASM correlation.

Framework mapping

Common failure patterns

• Inventory from procurement only: free cloud tiers, card-paid SaaS and staff-created test tenants never appear. The Midnight Blizzard breach started in a forgotten test tenant.
• Decommissioning that forgets DNS and credentials: the resource is deleted but its CNAME, API keys and service accounts live on.
• Scanning only the known ranges: vulnerability scans of the CMDB's IP list miss the assets ASM exists to find.
• Treating code repositories as out of scope: the Private-CISA GitHub leak exposed AWS GovCloud admin keys in a contractor's public repository for six months.
• Findings without owners: dashboards fill with unattributed assets that nobody may switch off.
• Counting assets instead of reducing exposure: a growing inventory is not progress; a shrinking count of exposed services is.

Practitioner checklist

• Name one accountable owner for the attack surface inventory and collect domains, IP ranges, cloud accounts and code hosting organisations.
• Monitor certificate transparency logs and passive DNS for your domains.
• Scan owned IP ranges and cloud public endpoints at least weekly, with authorisation recorded.
• Remove management interfaces from the internet or put them behind a separate policy enforcement point within 14 days.
• Add DNS record removal and credential revocation to every decommissioning checklist.
• Enable secret scanning and push protection on all repositories and scan public images and packages you publish.
• Block public access to storage at account or organisation level.
• Route findings to owners with SLAs and verify closure by rescanning.
• Correlate CAASM data to find assets missing EDR, patching or logging.
• Report exposure metrics monthly, with targets that go down.

Standards and references

• CISA: BOD 23-01, Improving Asset Visibility and Vulnerability Detection on Federal Networks
• CISA: BOD 23-02, Mitigating the Risk from Internet-Exposed Management Interfaces
• CISA: Cyber Hygiene Services
• NCSC: Asset management
• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• CIS: Control 1, Inventory and Control of Enterprise Assets
• IETF: RFC 6962, Certificate Transparency
• Microsoft Learn: Prevent dangling DNS entries and avoid subdomain takeover

Related NHI Mgmt Group resources: Secrets Management Guide · API Key Management Guide · Shadow AI Discovery Guide · DNS Security Guide · Threat Intelligence Guide