How to build an inventory of internet-facing assets

Assets lose their owner when the person or supplier who created them moves on. A marketing agency stands up a campaign site on a subdomain. A vendor asks for a CNAME record so its helpdesk can sit under the company domain. A domain goes on a staff member's personal card because that was quicker than a purchase order.

The person leaves or the contract ends, and the DNS record, virtual machine or registration keeps running. Expiry notices go to a mailbox nobody reads, and nobody left has the authority to switch the asset off.

Unowned assets create two problems. A forgotten host misses patches, so known vulnerabilities stay open. A CNAME that still points at a deleted cloud resource or a closed vendor account can be claimed by another customer of the same platform, who then serves content on your subdomain. Microsoft's guidance on preventing dangling DNS entries and subdomain takeover describes this for Azure resource types, and the same risk applies on any platform that lets a customer claim a name without proving control of the DNS zone.

Both the Essential Eight and ISO/IEC 27001 call for the inventory. The ASD Essential Eight Maturity Model, under patch applications at Maturity Level One, asks for an automated method of asset discovery used at least fortnightly to support vulnerability scanning. Annex A control 5.9 in ISO/IEC 27001:2022 covers an inventory of information and other associated assets, including their owners.

In Azure, Resource Graph lists public IP addresses across every subscription the signed-in account can read:

``` az graph query -q "Resources | where type =~ 'microsoft.network/publicipaddresses' | project name, subscriptionId, resourceGroup, ip = properties.ipAddress, attachedTo = properties.ipConfiguration.id" ```

A public IP list undercounts. App Service, storage accounts and other platform services answer on default hostnames without a public IP resource, so query those resource types as well and read the hostnames each one serves. For web apps:

``` az graph query -q "Resources | where type =~ 'microsoft.web/sites' | project name, subscriptionId, hosts = properties.enabledHostNames" ```

Publicly trusted certificate authorities log the certificates they issue to the public CT logs. Search a log search service for each registered domain, including the wildcard form. A hostname that appears in the logs and nowhere in your DNS zone export is a retired name, a live host managed elsewhere (a vendor, a second DNS provider or an account you have not found yet), or a name that was issued a certificate and never went live. Resolve the name to tell which.

For vendor-hosted subdomains, check that every CNAME target still resolves:

``` dig +short CNAME help.example.com dig help.example.com ```

NXDOMAIN on a name that carries a CNAME means the target is gone. Some platforms answer with a generic "site not found" page instead, so open the hostname in a browser as well.

An owner is a named person in a role who can approve a change to the asset and its retirement. A team or supplier goes in a contact field. When an owner leaves, their assets pass to their manager until someone else is named.

Keep the inventory as a register with the same fields for every entry:

Each asset type carries its own duties. The domain owner holds the registrar account, keeps auto-renew and registrar lock on, and puts multi-factor sign-in and a shared role mailbox on the account so renewal notices do not go to a departed employee. The certificate owner knows whether renewal is automated or manual and receives expiry notices. The host owner receives scan findings and decides on patching.

In Azure, record the owner as a tag and enforce it with Azure Policy. The built-in policy 'Require a tag on resource groups', assigned with the tag name set to owner, denies a new resource group without that tag. Assign 'Inherit a tag from the resource group if missing' as well so resources carry the tag, and check tag values at each review, since the policy tests that the tag exists, not that the person still works there.

Anything nobody claims gets a temporary owner, usually the IT manager, and a deadline to be claimed with a purpose or scheduled for retirement.

Deleting a cloud resource before its DNS record leaves the record pointing at a name another customer can claim. Work through retirement in this sequence:

Domains need separate treatment. Once the registry releases a lapsed domain, another party can register it and receive its mail. Keep any domain that sent email or appeared in customer correspondence registered, and publish a null MX record, an SPF record that authorises no senders and a DMARC policy of p=reject. Let a domain lapse only when it was never used for mail or customer contact.

Normal business activity moves the inventory out of date:

Each source of drift has a control that updates the register at the point of change. Make a register entry part of every DNS change request, including the records a vendor asks for at onboarding. Add registrar, DNS and cloud accounts to the offboarding checklist. Set Azure Monitor activity log alerts on the `Microsoft.Network/publicIPAddresses/write` and `Microsoft.Web/sites/write` operations. Watch certificate logs for your domains, since a new certificate is often the first public sign of a campaign or event site. Review expense lines for hosting, domains and SaaS each quarter.

Run a full reconciliation pass, then repeat it each quarter. Automated discovery between passes runs at least fortnightly where the business works to Essential Eight Maturity Level One. The pass works through these steps:

Once the register is complete, set the monitoring scope by the registered domains and public address ranges, so hosts under them are in scope, including assets still waiting on an owner or scheduled for retirement. Scheduled external scans then look for new hosts, exposed services, vulnerable software, TLS problems and weak email authentication across that scope. A host that turns up in a scan with no register entry means a drift control failed, and it needs an entry and an owner alongside any finding on the host itself.

Get advice when a CNAME target fails to resolve, when certificate logs show live hosts nobody can place, or when the estate spans tenants and registrar accounts the business cannot reach.

Black Shard runs the monitoring as a managed service. Assay scans the agreed footprint on a schedule and diffs each scan against the last, and Black Shard engineers read the change list against what the business runs and write what to fix first. The attack surface management page covers what the scans check and how scope and cadence are agreed.