How to reduce your external attack surface

NIST defines the attack surface as "the set of points on the boundary of a system, a system component, or an environment where an attacker can try to enter, cause an effect on, or extract data from, that system, component, or environment". An exposed service is one of those points whether or not it has a known vulnerability today.

Fixing a known issue removes one weakness, but the service stays exposed, together with every vulnerability nobody has found yet. The next zero-day finds the service exactly where it was. Closing a service nobody can justify removes the exposure itself, and with it every weakness in that service, known or not.

So the work of reducing the attack surface is not a patching programme. It is an inventory programme with a decision at the end of each line: this stays, with a reason and an owner, or this goes.

CIS Controls puts it in one sentence: "Enterprises cannot defend what they do not know they have." The list you already keep is the starting point, not the result. Start from what you know, which is your domains, your IP ranges and your cloud accounts, and let discovery find the rest.

"The rest" is where the risk lives: subdomains nobody registered in a spreadsheet, IP addresses that still answer, ports opened for a project that ended, certificates issued for names you did not know existed, and cloud resources created outside the platform team. Each of these is a point on the boundary, and each one is a candidate for step 2.

Discovery has to be continuous, not a one-off scan. A list made once is out of date within weeks, because the attack surface changes every time someone deploys something.

For every asset that is reachable from the internet, your organization should be able to answer four questions. An exposed asset that cannot answer them is a serious risk, so this is a process to run with discipline, not a form to fill in before an audit.

Two questions, not one. Does this service need to run at all, and does it need to be reachable from the internet? Many services pass the first question and fail the second. Management interfaces are the usual case: SSH, RDP, database ports, the admin pages of firewalls, routers and VPN concentrators, hypervisor and backup consoles. They have a business reason to exist and no business reason to be public. So the justification has to say why the service must be reachable from the internet, not only why it exists.

Writing it down is simple. One or two lines are enough. Say what the asset is, why it is exposed and, if you want, who approved it. If the exposure is temporary, say until when, and review it on that date. "Customer portal. Public by design, approved by the CISO in 2025." "SFTP for the payroll vendor. Temporary until 2026-03-31; review then."

Every exposure then ends in one of four places. It stays public, because it has a reason and an owner, and it is monitored from now on. It stays, but it leaves the internet: moved behind a VPN, an IP allow list or a private network, so the service keeps running and the exposure is gone. It is closed, because nobody can justify it. Or it turns out not to be yours at all, and it leaves the list. The second and third groups are the reduction. They are also the cheapest security work you will do this year: taking a service off the internet or closing it costs a ticket, and it removes every weakness in that service from the attack surface at once.

The same two fields do most of the day-to-day work afterwards. When a critical finding appears on an asset with an owner, the ticket goes straight to that team instead of starting with "whose is this?". The justification tells the team how critical the asset is, so the same vulnerability on a marketing microsite and on a payment API are not treated alike. And because the reason is written down, it survives the person who knew it.

An exposure is never an accident of the server alone. Something lets the traffic in: a firewall rule, a cloud security group, a load balancer listener, a port forward. So when the review says "this service leaves the internet", the change is made in that rule. And when the review says "this stays", the rule should allow exactly that service, to exactly the addresses that need it, and nothing more.

That makes the asset review and the firewall rule review one process seen from two sides. From the outside, discovery lists what is reachable. From the inside, the rule set says what was meant to be reachable. Compare the two lists. An inbound rule with no justified exposure behind it is either stale, so remove it, or it hides a service discovery has not seen yet, so check it. A justified exposure running on a rule wider than it needs is a rule to tighten. The documentation of a rule is the same line as the asset purpose: what, why, who approved it, until when.

The standards expect this review to be periodic. PCI DSS asks for a review of firewall and router rule sets at least every six months. Cyber Essentials asks for every inbound rule to be approved and documented with its business need, and for unnecessary rules to be removed when they are no longer needed. The external scan is the test of the rule set: what a scanner sees from the internet is what the rules actually allow, whatever the documentation says.

New subdomains appear, a port is opened for a test and never closed, a certificate is issued for a name nobody reviewed, a cloud resource goes public. Continuous discovery catches each of these as a new exposure that has to pass step 2 like every other.

Justifications age too. Review every one at least once a year, and whenever the owner changes. Review a temporary exposure on the date written in its justification. The standards set a floor here: PCI DSS asks for a review of firewall and router rule sets at least every six months, and CIS Controls v8 asks for the asset inventory to be reviewed at least twice a year. NIST's least-functionality control asks for the same thing in its own words: review the system periodically for unnecessary functions, ports, protocols and services, and disable or remove them.

ISO/IEC 27001 (Annex A 5.9) asks for an inventory of information and associated assets, with owners. PCI DSS asks for a current inventory of system components in scope (Requirement 12.5.1), for a documented business justification for every allowed service, protocol and port, and for a review of those rules at least every six months (Requirement 1; 1.2.5 and 1.2.7 in version 4). DORA (Article 8) asks EU financial entities to identify and document their ICT assets. CIS Controls v8 asks the asset inventory to record each asset's owner, its department and whether it was approved to connect to the network (Safeguard 1.1). NIST SP 800-53 (CM-7, least functionality) asks organizations to prohibit or restrict unnecessary functions, ports, protocols and services.

Some standards speak about internet exposure directly. PCI DSS prohibits direct public access between the internet and any system component in the cardholder data environment (Requirement 1.3; 1.4 in version 4). NIST SP 800-53 asks for publicly accessible system components to sit on subnetworks separated from the internal network, and for network traffic to be denied by default and allowed by exception (SC-7 and SC-7(5)). The UK's Cyber Essentials scheme requires that the administrative interface of the boundary firewall is not reachable from the internet unless there is a clear and documented business need and it is protected by multi-factor authentication or an IP allow list. CIS Controls v8 asks for automated vulnerability scans of externally-exposed assets at least monthly (Safeguard 7.6). And in the United States, CISA's Binding Operational Directive 23-02 (June 2023) orders federal civilian agencies to take networked management interfaces, SSH and RDP among them, off the public internet or put them behind zero-trust access control within 14 days of discovery. CISA's Cross-Sector Cybersecurity Performance Goals say it even more plainly: assets on the public internet expose no exploitable services, such as remote desktop protocol, and where such a service must be exposed, compensating controls prevent common forms of abuse (goal 2.W).

None of these asks you to run a scanner. Every one of them asks for the list and the decisions on it, which is why a disciplined asset review is worth doing before any audit asks for it.

Find it. Discovery starts from a seed, which is a domain, an IP range or a URL, or from a connected cloud account, and maps your domains, IP addresses, ports, websites, technologies and certificates. It keeps running, so a new exposure shows up as a new asset waiting for a decision.

Justify it, or close it. Asset review lists every domain and IP address in your scope, with the ports under each IP, and asks for a one-line Asset purpose and an owner for each. The health bar counts what still needs a purpose or a scope decision. The decision is part of the review: in scope means yours, keep it exposed and monitor it; out of scope means yours, but it should not be exposed, so close it; false positive means not yours. Every purpose keeps its history, so the reason survives the person who wrote it.

Keep watching. In-scope assets are scanned continuously, and you are notified about new assets, reachability changes and new findings. Owners route the work: each person's assets and findings appear under Assigned to me, and tickets pushed to Jira, ServiceNow or GitHub carry the owner. The asset inventory and compliance evidence reports are built from the same purposes and owners, so the audit artefact is a by-product of the review, not a separate exercise.

The feature list is on the features page, and the step-by-step guide to the review is in the documentation.