Playbook: Prioritizing an External Attack Surface

Discovery is the easy part of attack surface work. Modern tools will return thousands of hosts, certificates, services and findings. The hard part is deciding which dozen deserve attention this week. This note describes one way to do it that holds up under review. Adjust the thresholds to the organization. The sequence is what matters.

Why the outside view matters

An externally reachable service can be probed by anyone, without credentials and without first compromising anything. For that reason, exploitation of public-facing applications is a documented initial access technique in MITRE ATT&CK (T1190), and exposed remote services appear as a separate one (T1133). CISA’s Known Exploited Vulnerabilities catalog is a practical place to check how often edge and remote-access products appear among vulnerabilities with confirmed exploitation. Review it against your own technology list, not against a general claim.

That is why external exposure is a distinct prioritization problem. The question is not only how severe a flaw is. It is whether someone can reach it, whether they would want to, and whether you would notice.

Step 1. Fix the scope and the baseline

Start with what the organization believes it owns. Collect registered domains and subdomains, IP ranges and ASNs, cloud accounts and subscriptions, brands, subsidiaries and recent acquisitions. Then compare discovery output against internal records such as the CMDB, DNS zones, cloud inventories and certificate issuance.

Sort every discovered asset into one of four groups:

• Known and owned. Matches internal records with a named owner.

• Known, no owner. Recognized but nobody claims it.

• Unknown. Appears in discovery with no internal record. This group needs attribution before anything else.

• Not yours. Third-party hosting, look-alike domains or false attribution. Handle through a separate process, such as takedown or supplier contact.

Record an attribution confidence for each unknown asset. A wrong attribution wastes effort and, worse, can lead a team to scan or change a system that belongs to someone else.

Step 2. Confirm and enrich

For each in-scope asset, establish whether it is live and what it is running. Capture the service and version where it can be determined, authentication behavior, TLS configuration, hosting provider, and any network protection in front of it. Treat fingerprinting as indicative. Banners can be wrong, and a content delivery network can hide the real origin.

Step 3. Classify the exposure type

Type tells you how much the exposure matters before you have looked at a single finding.

Step 4. Rank with a small set of factors

Use a few factors consistently rather than a long weighted formula that nobody can explain. Five work well.

1. Exploitation evidence. Is the weakness listed in the CISA KEV catalog? Is exploit code public? What does its EPSS score suggest? EPSS estimates the probability that exploitation activity will be observed for a CVE over the next 30 days. Its authors do not publish official thresholds, so set your own and test them against your results.

2. Reachability and authentication. Can it be reached without credentials? Does the vulnerability require authentication or user interaction?

3. Asset importance. Does the system front something critical, such as identity, payment, customer data or an operational dependency? Link to your crown jewel list.

4. Compensating controls. Is the service behind an allow-list, a web application firewall rule, MFA or a gateway that blocks the vulnerable path? Count controls only when they have been verified.

5. Fix feasibility. Is there a patch or configuration change, an owner who can act and a change window? A difficult fix may need an interim mitigation while the real fix is scheduled.

CVSS base scores describe the technical severity of a flaw. They do not describe the probability of exploitation or the importance of the system affected, so use them as an input, not as the ranking.

Map the results to four tiers. The response times below are illustrative targets for an organization to set for itself. They are not requirements.

For an external reference on timelines, CISA Binding Operational Directive 19-02 sets remediation deadlines for US federal agencies on internet-accessible systems: critical vulnerabilities within 15 calendar days and high-severity within 30, counted from initial detection. It binds federal civilian agencies, not private organizations. It is still a useful benchmark, and its choice to start the clock at detection is worth copying.

Step 5. Assign, mitigate and track

Every item at Tier 0 to 2 leaves this step with a named owner, a response and a due date. If the owner is unknown, treat the missing owner as the first finding and escalate it to someone who can assign one. Where a full fix will take time, choose an interim measure: restrict by source address, place behind a VPN or access proxy, disable the unneeded service, apply a virtual patch at a web application firewall, or remove the DNS record. Log exceptions with an expiry date and a compensating control. An exception with neither is simply a delay.

Step 6. Verify from the outside

Confirm closure by looking at the asset the way an attacker would. Rescan from an external vantage point, and check more than the original port or hostname. Test alternative hostnames, IPv6 addresses, other ports and protocols, and the origin address behind any content delivery network. Teams often fix the one finding in the report and leave the same service reachable another way.

For Tier 0 items where exploitation was possible, patching does not prove the system is clean. Check logs and system state for signs of earlier compromise before treating the item as closed.

Step 7. Keep it running

An attack surface changes whenever someone creates a DNS record, issues a certificate, opens a cloud account, launches a campaign site or acquires a company. Schedule discovery to run continuously or at a regular interval, and connect it to events that should trigger an immediate review: a new KEV entry for a product you run, a merger or divestiture, a major cloud migration, a new certificate for an unfamiliar hostname.

Common failure modes

Limits to keep in mind

• Outside-in tools see what is reachable and responds. They cannot see internal paths to the same asset.

• Coverage and attribution vary between tools. Compare two sources for important ranges.

• Version-based findings are inference until confirmed. A service may be patched, backported or protected in ways the banner does not show.

• A ranked list is a decision aid. Context, such as an upcoming launch or a known campaign against your sector, can justify moving an item.

Sources

1. Cybersecurity and Infrastructure Security Agency. Known Exploited Vulnerabilities Catalog. cisa.gov

2. Cybersecurity and Infrastructure Security Agency. Binding Operational Directive 19-02, Vulnerability Remediation Requirements for Internet-Accessible Systems. cisa.gov

3. FIRST. Exploit Prediction Scoring System (EPSS), model documentation. first.org

4. FIRST. Common Vulnerability Scoring System (CVSS), specification document. first.org

5. MITRE. ATT&CK Enterprise: T1190 Exploit Public-Facing Application; T1133 External Remote Services. attack.mitre.org