Editorial and research policy

Why a security company publishes its research standards

Domain threat research is operational input. Someone reads it and then null-routes a name, files a UDRP complaint or wakes a legal team. If it is wrong, the cost lands on the reader, not the vendor.

You cannot audit our pipeline from outside, so the next best thing is knowing the rules we work under. Security marketing has a structural incentive to overstate — a threat that sounds larger sells more — and writing the standard down constrains it. This policy covers everything under threat intelligence and in resources.

Who writes

This material is written by the analysts who do the work it describes: the people who read certificate transparency feeds, file registrar abuse reports and sit through the handover of a hijacked domain. No content team turns their notes into articles.

The detail that matters here is procedural — which registrar responds to which evidence format, what an RDAP record omits that WHOIS still carried — and it does not survive a second-hand rewrite. Backgrounds for those roles are on our team page.

How research is produced

Observations come from a small set of named sources you can check yourself.

• Certificate transparency logs — issuance for names resembling a protected brand, with the CA, timestamp and full SAN list.
• Passive DNS — what a name resolved to and when, often the only proof infrastructure was shared before cleanup.
• Registrar and registry data — registration and expiry events, nameserver changes, status codes such as clientTransferProhibited, zone data where access permits.
• WHOIS and RDAP — registrant and registrar fields, with redaction routine enough that an empty field is evidence of nothing.
• Our own monitoring — detections from the domain monitoring and phishing protection work we run, subject to the confidentiality rule below.
• Work published by others — cited and linked, never restated as our own observation.

A single indicator is a lead, not a finding. A lookalike name in a CT log qualifies only once it resolves, serves content, gains an MX record, or sends mail failing alignment against the brand it imitates. We want two observations from independent sources before publishing, each timestamped, and what we could not check goes into the record too.

Observed and inferred are kept apart

"The MX records pointed at a third-party mail provider on that date" is an observation; "which suggests the operator intended to receive replies" is an inference. Merging them produces prose that sounds authoritative and cannot be verified.

Confidence and uncertainty

Attribution is the part of threat research that is wrong most often. Infrastructure is rented, resold, shared and abandoned; registration details are proxied, redacted or false; time zones, language artefacts and toolkit reuse are cheap to imitate and cheaper to misread. A finding can be entirely accurate about what happened and entirely wrong about who did it. So we say which of three things we mean, every time.

We do not name an actor without stating the basis

We do not attribute activity to a named group or a country unless the basis appears alongside the claim, and that basis has to be something you can weigh: infrastructure shared with a documented prior campaign, a reused TLS certificate, a registrant artefact surviving across registrations. "Consistent with" is not attribution, and we do not write it so it reads as one. If our basis is that someone else said it first, we say so and link to them.

Why over-confident attribution harms you

A defender has finite budget and one incident calendar. Told that a set of lookalike domains is a targeted campaign by a capable adversary, you escalate, brief an executive, involve counsel and possibly notify a regulator. Told the same domains are opportunistic bulk registration by someone monetising traffic, you file takedowns and move on. Both responses are right for their scenario and expensive applied to the other. Confidence that is not earned sends your defensive effort in the wrong direction while the real problem stays open.

A confident early claim also gets repeated, indexed and cited long after the evidence behind it has moved, and correcting an assertion quoted a dozen times is close to impossible. Where later evidence supersedes something we published, we say so on the page. Our threat reports are written to this standard.

Responsible handling of findings

Most findings involve somebody else's infrastructure: a compromised hosting account, a dangling CNAME, an open zone transfer, a mail server relaying spoofed mail. That third party is usually a victim, not material.

• We attempt contact first, via the registrar or hosting abuse address, an RFC 9116 security.txt, a national CERT, or the organisation directly.
• We allow reasonable time to remediate, and we honour an embargo we agreed to.
• We publish nothing that lets a reader reproduce an attack on a still-exposed target — no payloads, no paths, no live misconfiguration described precisely enough to follow. Once fixed, the class of issue is fair game.
• We do not test systems we have no authority to test; against third-party infrastructure our research is passive.
• We redact a victim's identity where naming them adds nothing a defender can act on.

This is the standard we ask of researchers who look at us, set out in our responsible disclosure policy. A vendor that demands coordinated disclosure for itself while publishing others' exposures on sight has a preference, not a policy.

Customer material is never research material

Anything learned during an engagement stays with it. Domains monitored, incidents handled, correspondence generated during a takedown, the shape of an estate: none of it appears in published research without written permission naming what may be said.

That includes anonymised write-ups — in a sector with distinctive domain portfolios, "a mid-sized European bank" is often identifiable to anyone who works in it — and statistics: we do not turn customer estates into numbers presented as general findings. The obligation outlives the contract.

Use of AI

We use AI tools and would rather tell you where than let you guess: clustering domain observations, summarising registrar correspondence, translating sources, drafting and editing text.

What they do not do is decide anything — not a confidence level, not an attribution, not whether a finding is corroborated. Every published piece is read and approved by a human analyst first, who checks that each claim traces to a source we hold, that observed and inferred are still separated, and that no citation or technical detail was produced from nothing. Fabricated-but-plausible sourcing is the characteristic failure of these systems. We do not publish unreviewed generated analysis.

Corrections

If you find an error, tell us at [email protected]: the page, the claim, and what the correct position is. We reply to general email within one business day.

Factual errors are corrected promptly. A material correction — anything changing a conclusion, an attribution, a confidence level, or an indicator you might have acted on — is noted on the page with what changed and when. We do not silently rewrite a published assessment.

Vulnerability reports use a different channel

A security issue in our own systems is not an editorial correction and does not belong in the general inbox. Send it to [email protected] under our responsible disclosure policy; the same address is in our RFC 9116 security.txt.

The channels differ on purpose. An editorial correction is handled in the open and ends as a public note on a public page. A vulnerability report needs the opposite: confidential handling, a remediation clock, and no detail until a fix is in place.

An active incident against your own domains is a third channel: [email protected], staffed around the clock with a stated 30-minute response. All three addresses are on the contact page.