Finding and Prioritizing Your External Attack Surface

An external attack surface is everything about your organization that someone on the internet can reach or learn about: domains, hosts, services, applications, cloud storage, exposed credentials and third-party connections. It is rarely identical to the asset list in your inventory. Marketing launches a microsite, a developer leaves a test server running, an acquisition brings unknown domains. Each is a way in that nobody is watching.

This article sets out a simple cycle: discover, validate, prioritize, act and repeat.

Key takeaways

• Your inventory and your real exposure differ; discovery has to start from the outside.
• Discovery is a recurring activity, not a project, because the surface changes constantly.
• Prioritize by exploitability, exposure and business impact, not by severity score alone.
• Evidence of active exploitation should move an issue to the front of the queue.
• Every discovered asset needs an owner, or it will not be fixed.

Why asset visibility comes first

Asset management is a named category in the NIST Cybersecurity Framework 2.0, covering inventories of hardware, software, services and data, and the prioritization of assets by importance to the organization's objectives and risk strategy ^[1]. Visibility is also the premise of continuous monitoring, which NIST describes as providing visibility into organizational assets and awareness of threats and vulnerabilities ^[2].

Government practice reflects the same logic. CISA's Binding Operational Directive 23-01, written for US federal agencies, requires automated asset discovery every 7 days, covering at minimum the agency's entire IPv4 space, and starting vulnerability enumeration on discovered assets every 14 days ^[3]. You are not bound by that directive, but it shows that discovery is expected to be frequent and systematic rather than occasional.

Step 1: Seed and discover

Start with what you know, then widen the search the way an outsider would.

• Seeds: registered domains and brand names, known IP ranges, cloud account identifiers, and the names of subsidiaries and recently acquired companies.
• Expansion: subdomains, DNS records, certificate transparency logs, IP ranges tied to your organizations, and services answering on those addresses.
• Beyond hosts: public code repositories, exposed storage, forgotten admin panels, mobile apps, and third-party platforms hosting your content or login pages.

OWASP defines an application's attack surface as the sum of all paths for data and commands into and out of it, including the code protecting those paths and the valuable data it handles, and notes that a first map will be incomplete and should be refined over time ^[4]. Apply the same mindset to the whole organization: list entry points, group them by type, and expect to revise.

Step 2: Validate and assign ownership

Raw discovery output is noisy. Before ranking anything, confirm each item:

1. Is it ours? Match against registrations, contracts and cloud accounts. Look-alike domains and third-party hosted assets need separate handling.
2. Is it live? Record what responds, on which ports, and what it appears to run.
3. What does it do? Identify the business function and the data it touches.
4. Who owns it? Assign a named person or team. Unowned assets are the ones that stay exposed longest.

Example (fictional): a discovery run for a regional retailer finds 140 hostnames. The inventory lists 95. Of the 45 new ones, 30 are expired campaign pages, 10 are staging servers, 3 belong to a former supplier integration, and 2 are an old remote access gateway. Validation turns a long list into a short set of decisions: retire, secure, or transfer.

Step 3: Prioritize with context

A severity score tells you how bad a flaw could be in general. It does not tell you how likely it is to be used against you. Combine several signals:

• Known exploitation. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with reliable evidence of exploitation in the wild, and CISA recommends that all organizations monitor it and prioritize fixing what it lists ^[5]. Treat a match as an input that raises priority sharply.
• Likelihood of exploitation. The Exploit Prediction Scoring System estimates the probability that a published vulnerability will be exploited in the next 30 days, and publishes a daily score for each one ^[6]. It is a useful tiebreaker among many findings.
• Exposure. An administrative interface open to the whole internet outranks the same flaw behind a VPN. Authentication, rate limiting and network restrictions all reduce practical risk.
• Business impact. Weigh the data, the revenue process and the regulatory obligations attached to the asset.
• Compensating controls. Note what already limits exploitation, such as a web application firewall rule or strong multi-factor authentication, but do not let it close the issue permanently.

A simple model works well. Assign each finding a tier:

1. Tier 1, act now: listed as exploited, or internet-facing with a critical flaw on a sensitive system. Target remediation or a mitigation within days.
2. Tier 2, schedule: high severity on exposed assets, or elevated exploitation probability. Fix within the next patch cycle.
3. Tier 3, plan: lower likelihood or limited exposure. Fix through normal maintenance.
4. Tier 4, accept or retire: documented risk acceptance, or decommission the asset entirely.

The best remediation for an unneeded asset is removal. Retiring a forgotten server closes every present and future flaw on it at once.

Step 4: Act and record

For each Tier 1 and Tier 2 item, create a ticket with the asset, the owner, the exposure, the recommended fix and a due date. When a vendor update is not immediately possible, CISA's guidance for known exploited vulnerabilities is to apply mitigations or workarounds as temporary protection and move to the official patch when it is released ^[5]. If a product is end-of-life and cannot be updated, plan to remove it from the network ^[5].

Keep a short record of each decision, including accepted risks with an expiry date. This also produces the evidence that auditors and regulators ask for.

Step 5: Repeat and measure

Run discovery on a fixed schedule, for example weekly for the most exposed ranges, and compare each run with the last. New assets and new open ports should trigger review the same day. Track a few measures that show direction rather than perfection:

• Percentage of discovered assets with a named owner.
• Number of new, previously unknown assets per cycle.
• Time from validated finding to remediation, by tier.
• Age of open Tier 1 and Tier 2 items.

Integrate the process with change management so that launching a new domain or service automatically adds it to the inventory, and tie the results into your wider risk register.

A realistic expectation

No discovery method is complete. Some assets sit behind third parties, and attackers may know about things you do not. The aim is a surface that is smaller, better understood and watched continuously, with the most dangerous exposures closed first.

Organizations that want this run as an ongoing service rather than a periodic exercise can look at Valtrenix's Attack Surface Management capability.

Sources

1. The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, NIST. nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
2. NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations, NIST. csrc.nist.gov/pubs/sp/800/137/final
3. BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks, CISA. cisa.gov/binding-operational-directive-23-01
4. Attack Surface Analysis Cheat Sheet, OWASP Cheat Sheet Series. cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html
5. Reducing the Significant Risk of Known Exploited Vulnerabilities, CISA. cisa.gov/known-exploited-vulnerabilities
6. Exploit Prediction Scoring System (EPSS), FIRST. first.org/epss