How an external attack surface list goes stale

A perimeter list is usually assembled while preparing for an audit. Someone exports the DNS zone, someone copies addresses out of a cloud console, and a spreadsheet is born.

That day the spreadsheet is correct. The next day marketing asks for a subdomain for a landing page, a developer stands up a test environment, an integrator opens a temporary API — and none of it reaches the spreadsheet.

Six months on the spreadsheet exists as a document and is useless for decisions. The dangerous part is that because it exists, nobody goes looking for a better one.

A DNS zone shows only what you put in it. A service stood up in a cloud account with its own address does not appear there at all.

So the list is assembled from several sources: DNS records, certificate transparency logs, cloud account inventories, external scan results, and registrar data.

Certificate logs are particularly useful. Every public certificate lands in an open log, so `test-2.internal.example.uz` becomes visible the moment a certificate is issued — even if it was never published anywhere.

Every external asset moves through four states: found, confirmed, owned, monitored. Many organisations have the first and none of the other three.

Confirmation is needed because some of what automation finds is not yours: a shared hosting address, the old name of an acquired company, a similarly spelled domain belonging to someone else.

The third state is skipped most often and costs the most. An alert about an asset with no owner reaches nobody, and is therefore never closed.

"Owner: IT" is a tidy way of writing "unowned". An alert is opened by a person, not by a department.

A practical rule: two names per asset — a technical owner and a business owner. The first answers "what breaks if we turn this off", the second answers "who asked for this in the first place".

The second question looks bureaucratic and is the more useful of the two in practice: it is where you discover that a large share of the estate is no longer needed by anyone.

A subdomain points at an external service — cloud storage, static hosting, a forms provider — and later the resource in that service is deleted. The DNS record stays behind.

Now anyone who claims that name in the same service can publish content on your subdomain. This is called a subdomain takeover, and they will obtain a certificate too, because they pass domain control validation.

Finding such records is easy: isolate the ones whose target does not answer or reports "no such resource". The hard part is doing it regularly.

An external scan produces a list of open ports, and by itself that list says nothing about risk. Port 443 being open is normal.

What matters is what sits behind the port and in what state. A management console, a database, an API meant for internal use — none of these should have been on the external network.

So the list gains a third column: is this service supposed to be reachable from the internet? Every row answered "no" is worth more than the scan result itself.

A scanner produces hundreds of findings, each carrying a score. Those scores are external and know nothing about your context.

Correct ranking rests on three questions: is this asset reachable from the internet, does it hold real user data, and does a public exploit exist for this vulnerability?

Findings where all three answers are yes are usually a few percent of the list. Work starts with those few percent, not with the highest scores.

A living list has three properties. First, it refreshes itself: a new finding appears on its own rather than on request.

Second, every finding has an owner, and a change of owner is visible. Third, there is a metric: how long, on average, from discovering a new asset to confirming it.

That third number says the most. Hours means the process works. Weeks means you have a periodic report rather than a list.