Reducing Your Own Footprint: the Defensive Audit

5. Search for stray content. Apply the search-engine techniques to each domain: indexed documents, directory listings, unlinked administrative pages, error messages.

6. Inspect published documents. Sample the documents the organisation publishes and extract their metadata. Check for improper redaction.

7. Review people exposure. The email format, the staff list, technologies named in profiles and talks, and senior staff who are impersonation targets.

8. Check code and secrets. Search public repositories for the organisation's domains and internal names; scan for committed credentials.

9. Check registration data. WHOIS and registry records for exposed personal contact details and, importantly, for domain expiry dates.

10. Write it up as findings with decisions, which is the next section.

The three decisions

For every item found, exactly one of three decisions, and stating them explicitly is what makes the audit a piece of work rather than a list of worries.

Remove it. The item serves no purpose and can go: the forgotten test host is decommissioned, the stray spreadsheet is deleted, the directory listing is disabled, the improperly redacted document is withdrawn and reissued. This is the best outcome and should be used wherever possible, because it eliminates rather than manages.

Restrict it. The item is needed but not by everyone: the administrative interface is moved behind authentication or restricted to an internal network, the document is moved behind a login, the verbose error page is replaced with a generic one for the public and kept in the server-side log.

Accept and defend. The item cannot reasonably be removed, and here the audit's honesty matters. You cannot make your senior staff unfindable, or stop certificates for your host names being published, or prevent the software you run being fingerprinted. For each accepted exposure, name the control that makes it insufficient:

The right-hand column is the whole argument of the module in miniature: since reconnaissance cannot be prevented, security must not depend on it failing. An organisation whose defence is that an attacker will not find out what it runs has no defence at all.

What "obscurity is not security" does and does not mean

The slogan is often stated too strongly, and a good answer distinguishes.

It is true that obscurity must not be the control you rely on. A system protected only because its address is unpublished is protected by a fact you do not control and cannot verify, and it fails completely the moment the address leaks, which the earlier chapters showed happens routinely through certificates, archives and indexes.

It is also true that needless disclosure is a gift. Publishing an exact version number, an internal architecture, or a complete staff directory costs the organisation nothing to avoid and saves an attacker real effort. Reducing it is worth doing.

The reconciliation: obscurity is a valid supplementary measure and an invalid primary control. Reduce your footprint because it raises the attacker's cost, and never let anything depend on the reduction having worked.

A worked example, and the journal practical

This is the practical to record in the journal, and it can be done entirely lawfully against your own institution or a system you own.

Meera audits her college. Working only from third-party sources:

• Hosts. Certificate transparency gives fourteen host names; the college's IT department recognises nine. Five unknown hosts, of which two respond and three do not. One is a results portal from an old academic year still serving pages.
• Technology. The old portal discloses a web-server version with two published High-severity flaws. The main site suppresses its version.
• Stray content. A restricted search finds an indexed spreadsheet of student contact details and an open uploads directory.
• Documents. Metadata from four published PDFs yields the staff account naming convention and an internal file-server name.
• People. The email format is public; around eighty staff are listed on professional networks.
• Registration. One secondary domain expires in five weeks with no auto-renewal.

Her findings, with decisions:

The most valuable line is the first, and it was not a vulnerability in the ordinary sense. It was an asset nobody knew about, found by a free, lawful, passive technique. That is what this chapter exists to teach.

What beginners get wrong

• Treating the audit as tidying. Its main product is an inventory correction, and unknown assets are the most dangerous ones.
• Trying to remove everything. Much exposure is necessary. The discipline is to decide remove, restrict, or accept-and-defend, and to name the control for every acceptance.
• Relying on obscurity. It is a supplement, never a primary control. Anything that depends on an address staying secret is undefended.
• Auditing once. Exposure regrows continuously as people publish, provision and leave. It is a recurring exercise, and certificate transparency monitoring makes part of it continuous.
• Skipping the reconciliation step. Enumerating hosts is only half the work; comparing them with the asset register is where the finding is.
• Forgetting domain expiry. A lapsed domain can be re-registered by anyone and used to impersonate the organisation.

Quick revision

• Run reconnaissance against yourself: free, lawful, passive, and it measures your real exposure rather than guessing at it.
• Procedure: list domains, enumerate hosts (certificate transparency, DNS, indexing services, archives), reconcile against the asset inventory, profile technology, search for stray content, inspect document metadata, review people exposure, check repositories for secrets, check registration and expiry, write findings with decisions.
• The main product is often an inventory correction: unknown assets are unpatched, unmonitored and the most dangerous the organisation owns.
• Three decisions per item: remove, restrict, or accept and defend, and every acceptance must name the control that makes the exposure insufficient.
• Obscurity is a valid supplementary measure and an invalid primary control: reduce the footprint to raise the attacker's cost, but never depend on it.
• Repeat it; exposure regrows.

Test yourself

1. What is the most valuable finding a footprint audit typically produces, and why?

Assets the organisation did not know it owned, such as forgotten subdomains, test systems or cloud services. They are the most dangerous assets it has, because nothing unknown is patched, monitored or backed up, and no one will notice its compromise.

1. State the three decisions available for each item found, and the requirement attached to the third.

Remove it, restrict it, or accept it and defend against its use. Every acceptance must name the specific control that makes the exposure insufficient, such as multi-factor authentication against a discoverable email format, or patch management against a fingerprintable version.

1. In what sense is "obscurity is not security" true, and in what sense is reducing your footprint still worthwhile?

It is true that obscurity must never be the primary control, since it depends on a fact you neither control nor can verify and fails entirely once the information leaks. Reducing the footprint remains worthwhile because needless specifics cost nothing to withhold and save an attacker real effort, so obscurity is a legitimate supplementary measure.

1. Why must the host-enumeration step be followed by a reconciliation step?

Because the security value lies in the difference between what is discoverable and what the organisation's asset register records. Enumeration alone produces a list; comparing it with the inventory identifies the unknown, unmanaged assets that constitute the real finding.

1. Why is a footprint audit a recurring exercise rather than a one-off project?

Because exposure regrows continuously as staff publish material and talks, departments provision new hosts and cloud services, certificates are issued, and people join and leave. Parts of it, such as monitoring certificate transparency for your own domains, can be made continuous.