Scoping monitoring so it produces action — Domain Security Fundamentals

Monitoring fails far more often through excess than through absence. A feed producing two hundred alerts a day is read for a week and ignored for a year, and the organisation is worse off than before, because it now believes it is watching.

Start from the response, not the detection

The scoping question

For each thing you are considering watching: what would I actually do the next time it fires? If the honest answer is "look at it and move on", do not watch it.

This inverts the usual order, and it is the only version that survives contact with a real team. Detection you cannot act on is not a partial win; it is a tax on attention that makes the alerts you can act on harder to see.

The prerequisite: know your own estate

Before any monitoring, you need a definitive list of the domains and hostnames you own. Without it every alert begins with an internal investigation to establish whether the thing is yours, and that cost is what kills the programme.

# build the inventory first
- registrar exports, every registrar, including ones marketing uses
- expense records for domain registrations
- CT log search for your brand, to find names you did not know about
- ask marketing, who will remember three you did not find

The channels, in order of yield

Channel	Watches for	Yield
CT for your own domains	Certificates for hostnames under your domains that you did not authorise.	Highest. Low volume, high specificity, and it catches takeovers and shadow IT.
DNS change monitoring on your own domains	NS, MX or DS changes you did not make.	High. Very low volume, and a hit is close to an incident by definition.
Newly registered domains matching your brand	Registrations of typos, combos and homographs.	Medium. Needs tuning, and a recent registration is the strongest single early signal.
CT for lookalike names	Lookalikes standing up infrastructure.	Medium, and it pairs well with registration data.
Broad brand mentions	Your brand anywhere.	Low. This is the one that generates the noise.

Note the ordering: watching your own estate outranks watching the world. It is cheaper, quieter, more actionable, and almost always skipped in favour of the more exciting outward-facing feed.

Tier the findings

A single alert stream forces every finding to be equally urgent. Three tiers, with different destinations:

Act now. A lookalike with an MX record, or with a certificate and live content. It is ready to be used. Page someone.
Look this week. A lookalike registered but not yet resolving. Worth watching, not worth waking anyone.
Record only. Parked, unrelated, or plainly defensive registrations by someone else. Into the log; no notification.

The signals that move something up a tier are consistent: recent registration, an MX record, a fresh certificate, live content resembling yours, and a word from the access or money lists in the combosquatting lesson.

Where automation stops

Automatable	Needs a person
Generating permutations of a brand	Deciding whether a specific domain is a threat or a legitimate unrelated business
Checking registration, DNS and CT for each	Judging intent from ambiguous content
Filtering against your own inventory	Choosing between monitoring, a takedown, and legal action
Prioritising by the signals above	Writing the abuse report, and escalating when it is ignored
Alerting on a change	Everything after the alert

Do not automate the response

Automated takedown requests against a false positive are a real cost imposed on a real business, and a registrar that receives several from you stops treating your reports as credible — which is expensive precisely on the day you need them to act quickly. Automate detection and triage; keep a human on the action.

Scope is not set once

Review it quarterly against two questions: which alerts produced action, and which produced nothing. Anything in the second category for two consecutive quarters should be narrowed or switched off. Monitoring that is never pruned always trends toward noise, because adding a source is easy and removing one feels like reducing coverage.

Write down what you excluded and why. A scope with no stated exclusions is one nobody has thought about, and the exclusions are where the judgement actually is.

Knowledge check

A team proposes monitoring every newly registered domain containing their brand string, alerting immediately on each. The brand is a common English word. What is the most likely outcome?

Good coverage, because a common word means more variants to catch.
High alert volume dominated by unrelated legitimate registrations, so the feed stops being read — leaving them worse off than with no monitoring, because they believe they are watching.
It works, provided they automate a takedown request for each match.
Low volume, because new registrations matching a specific string are rare.

Not this — Good coverage, because a common word means more variants to catch. More matches is not more coverage. A common word matches a large number of unrelated legitimate registrations, and volume without specificity is what stops a feed from being read.

Correct — High alert volume dominated by unrelated legitimate registrations, so the feed stops being read — leaving them worse off than with no monitoring, because they believe they are watching. The failure mode this lesson exists to prevent. The fix is not to stop monitoring but to narrow it: require a second signal — an MX record, a certificate, live content, or a word from the access and money lists — before anything alerts, and route everything else to a log nobody is paged for.

Not this — It works, provided they automate a takedown request for each match. That converts a noise problem into a reputation problem. Automated takedown requests against unrelated businesses get your reports deprioritised by the registrars you will one day need to act quickly.

Not this — Low volume, because new registrations matching a specific string are rare. For a common English word they are not rare at all. This assumption is exactly what makes the proposal seem reasonable before it is deployed.