Attack Surface Management
Your attack surface is everything an attacker could try to reach: domains and subdomains, public IP addresses and open ports, cloud storage and databases, APIs, login pages, VPNs, SaaS tenants, code repositories, and the credentials that leak from any of them. Attack surface management (ASM) is the continuous process of discovering those assets, attributing them to owners, assessing their exposure, and shrinking or hardening them.
Attackers do this reconnaissance routinely, with the same public data sources defenders can use — DNS, certificate transparency logs, internet-wide scanners, and leaked data. Many breaches start with assets their owners forgot existed: a staging environment left online, an old marketing site on outdated software, a DNS record pointing at a deleted cloud resource. You cannot patch, monitor, or defend what you do not know about.
TL;DR
- Build the inventory from authoritative sources (cloud APIs, DNS zones, infrastructure as code) and external discovery (certificate transparency, internet scanning) — each finds what the other misses.
- Every asset needs an owner; unowned assets are where forgotten risk accumulates.
- Watch for the classic exposures: dangling DNS records (subdomain takeover), exposed admin interfaces, open storage, internet-facing databases, and forgotten environments.
- Treat the surface as continuously changing: alert on new hosts, new open ports, new certificates, and new public buckets.
- Feed findings into vulnerability management and fix the process that created the exposure.
- Only scan assets you own or are authorized to test.
Quick Example
Enumerate your subdomains from certificate transparency logs and check which still resolve — a quick external view of your web footprint.
Names nobody recognizes, and CNAMEs pointing at targets that no longer exist, are the findings to investigate first.
Core Concepts
What Belongs in the Inventory
Discovery Sources
Comparing the internal view (what you think exists) with the external view (what the internet sees) is where the most valuable findings come from.
Exposure Categories
- External attack surface — anything reachable from the internet.
- Internal attack surface — what an attacker who gains a foothold, or a malicious insider, can reach.
- Cloud attack surface — identities, policies, and resource configurations, often assessed with cloud security posture management tools.
Product categories reflect these: EASM (external attack surface management), CSPM (cloud security posture management), and CAASM (cyber asset attack surface management, which aggregates inventories).
Common Exposures
Subdomain Takeover
A DNS record such as promo.example.com CNAME old-campaign.cloudhost.example keeps pointing at a cloud resource after the resource is deleted. If an attacker can claim the same resource name, they serve content on your subdomain — phishing pages, cookie theft, or content-security bypasses. Prevent it by deleting DNS records in the same change that deletes the resource, managing both through infrastructure as code, and scanning for dangling records.
Forgotten Environments
Staging, demo, and test environments often run old code, use real data, and skip authentication. Put non-production environments behind SSO or a VPN, and give them an owner and an expiry.
Exposed Administrative Interfaces
Database consoles, Kubernetes dashboards, CI servers, and admin panels should never face the internet directly. Place them behind identity-aware access — see Zero Trust Architecture.
Public Data Stores
Storage buckets, search clusters, and databases exposed by a single configuration change remain among the most common causes of data leaks. Use organization-wide guardrails, such as blocking public storage access by default, and alert on any exception.
Best Practices
Make Infrastructure as Code the Source of Truth
When DNS records, cloud resources, and firewall rules are created and destroyed through code, inventory comes for free and orphaned resources become rare.
Attach Owners and Lifetimes
Tag every resource with an owning team and, for temporary environments, an expiry date. Route ASM findings directly to owners; findings without owners stall.
Monitor for Change
Alert on new subdomains in certificate transparency logs, new open ports on your ranges, newly public storage, and new cloud accounts. A change you did not expect is either shadow IT or an attacker.
Close What You Do Not Need
Each exposed service is something to patch, monitor, and defend. Removing unneeded endpoints, ports, and environments reduces risk more reliably than hardening them.
Scan Only With Authorization
Scan assets you own or have explicit permission to test, and coordinate with cloud providers' policies. Scanning third-party systems without permission can be illegal.
Common Mistakes
Deleting the Resource but Not the DNS Record
Inventory in a Spreadsheet
Unauthenticated Staging Environments
FAQ
What is attack surface management?
The continuous practice of discovering every asset an attacker could target — domains, IPs, cloud resources, APIs, SaaS, code — assigning owners, assessing exposure, and reducing it. It answers "what do we have, and what can attackers see?" before vulnerability management asks "what is wrong with it?".
How is attack surface management different from vulnerability scanning?
Vulnerability scanning examines known assets for weaknesses. Attack surface management finds the assets in the first place — including ones nobody knew about — and tracks their exposure over time. The two work together: discovery feeds the scanner.
How do we find shadow IT?
Compare authoritative inventories with external evidence: certificate transparency logs for your domains, DNS records, internet scans of your IP ranges, SSO and expense data for unknown SaaS, and public code search for your organization's name and domains.
What is a subdomain takeover?
An attacker claims a cloud resource that one of your DNS records still points to after you deleted it, then serves their own content on your subdomain. Deleting DNS records together with resources and scanning for dangling CNAMEs prevents it.
How often should we run discovery?
Continuously for change detection — new certificates, open ports, and public resources — and with a full reconciliation at least weekly. Attackers scan the internet constantly; quarterly discovery leaves months of blind spots.
Related Topics
- Security Operations & Defense — Where exposure management fits in the defensive loop
- Vulnerability Management — Prioritizing and fixing weaknesses in discovered assets
- DNS — How names resolve, and how dangling records happen
- Cloud Networking — Controlling what cloud resources expose
- Zero Trust Architecture — Putting internal tools behind identity-aware access
- IT Asset Management — Inventory and ownership for the wider organization