Methodology · Post-Mortem Analysis Engine

Why we publish only after the breach is confirmed.

The Post-Mortem Analysis Engine correlates Cipherwake's longitudinal scan history with publicly-confirmed breach disclosures. Its purpose is retrospective — never predictive in public. This page explains the correlation logic, the manual review gate, the rejection criteria, and the strict editorial line that defines what we will and will not publish.

The hard rule Cipherwake will not publicly state that a specific named third party "is being attacked," "may have been breached," or "is at elevated risk" before the affected party or a regulator has publicly confirmed an incident. Soft-framed warnings ("FYI we noticed unusual activity at X.com") are not permitted either. This rule is not a technical limitation; it is an editorial principle that holds even when our signal is high-confidence.

What this tool measures

For every domain Cipherwake has ever scanned, we maintain a longitudinal record:

Score history (every component, every probe, every measurement date).
Cert history from Certificate Transparency: every cert ever issued, its key fingerprint, lifetime, SANs, issuer.
Subdomain emergence + dormancy events.
Cipher / key-exchange policy changes detected at each scan.

The Post-Mortem Engine does not introduce a new measurement. It answers a different question: given a confirmed breach disclosure, what does our existing scan history say about the affected domain in the days, weeks, and months prior?

How we monitor for confirmed breaches

A scheduled cron job pulls from public, authoritative sources of breach disclosures:

HIBP (Have I Been Pwned) — the established gold standard for confirmed breach data.
SEC 8-K filings — material cybersecurity disclosure under Item 1.05 (mandatory since 2023).
Public-record incident feeds — Krebs on Security RSS, BleepingComputer, The Record, DataBreaches.net, Bitdefender / Mandiant / CrowdStrike public advisories.
Regulatory notices — state AG breach-notice databases (CA, NY, MA), HHS OCR breach portal (HIPAA reportable breaches).

We treat a breach as "confirmed" when it appears in at least one of: an SEC 8-K, an official statement from the affected company, a regulatory filing, or HIBP. Press reporting alone is not sufficient. Threat-actor claims (paste sites, leak forums) are not sufficient.

How retrospective drafts are generated

For each newly confirmed breach, the engine looks up the affected domain(s) in our scan history and computes:

Score trajectory in the 30 / 90 / 365 days before disclosure.
Cert issuance velocity — was there a 3σ deviation above baseline in the lead-up?
Key-reuse changes — did historical key reuse patterns change shortly before the disclosure?
Subdomain emergence — were unusual new subdomains observed?
Cipher policy regression — did supported ciphers degrade?
Lead time — earliest unambiguous anomaly date vs. public disclosure date.

If any of these surface a clear, technically defensible correlation, the engine generates a draft retrospective. Drafts include the timeline, the specific signal, and a plain-language technical explanation.

The manual review gate

Drafts are never auto-published. Each goes through a manual review with three explicit kill criteria:

Causation gap. Is there a plausible non-breach explanation for the signal — cloud migration, M&A activity, legitimate cert lifecycle ops, CT-issuer policy changes? If yes, kill.
Reproducibility. Could a competent analyst independently reach the same conclusion from public data? If our claim depends on a private artifact or non-replicable inference, kill.
Materiality. Is the signal lead time + magnitude actually meaningful, or are we publishing for the press cycle? "We saw 0.05σ above baseline 12 hours before disclosure" is not material; kill.

Empirically we expect most drafts to die at this gate. That is the point. The published rate is intentionally low. A single false attribution costs more credibility than fifty correct ones earn.

How it scores

The engine does not publish a score. Each draft is annotated internally with a confidence band:

Strong — multi-signal corroboration, > 30 days of pre-disclosure anomaly, no obvious benign explanation. Eligible for publication after review.
Moderate — single signal or shorter lead time. Reviewed but typically not published; saved for aggregate trend analysis.
Weak — coincidental-looking. Discarded.

What this tool does NOT claim

This is the section that earns the trust:

We do not claim causation. A pre-breach signal is correlation. We never say "this signal caused the breach" or "this signal would have prevented the breach."
We do not claim our tool would have prevented anything. Hindsight bias is the most common failure mode in retrospective security writing; we explicitly disclaim it.
We do not name third parties before public confirmation. Not even with hedge language. Not even with high-confidence signal.
We do not run real-time public dashboards "of who looks suspicious." The closest thing — Cert Anomaly Index — is aggregate-only and never names individual domains.
We do not claim our backtesting precision generalizes forward. Retrospective hits do not entitle us to make predictive public claims.
We do not include threat-actor attribution. We document signal; we do not name actors.

Trust signal The "What we don't claim" list above is longer than the "what we measure" list. That asymmetry is intentional. Anyone publishing post-mortem content faces strong pressure to overstate signal — for the press cycle, for sales decks, for follow-on coverage. We've codified the inverse pressure.

Permitted public surfaces

The Post-Mortem Engine produces three kinds of public output, in order of frequency:

Long-form retrospectives at /post-mortems/<slug> — published only after a breach is publicly confirmed; only "Strong" confidence band; only when manual review survives.
Aggregate Cert Anomaly Index — quarterly trend report; sector-level statistics with no individual domain naming.
Pro-tier private alerts — when one of our paying customers' own domains or vendor-portfolio domains shows a signal, we alert them privately. This is not a public surface.

Limitations + edge cases

Selection bias. We only have history for domains we've scanned. A breach at a domain we've never scanned produces no draft — the engine is silent, not negative.
Lookback distance. Cipherwake's scan history begins 2026; pre-2026 incidents have no longitudinal substrate.
Disclosure latency. Many breaches are disclosed weeks or months after the fact. Our "lead time" calculations use the disclosure date, not the actual incident date (which is often unknown).
False signal sources. Cert anomalies are commonly caused by infrastructure migrations, M&A integrations, CDN failover events, and CT-issuer policy changes — none of which are breaches. Manual review is calibrated against these.
No predictive guarantee. Backtesting precision against confirmed breaches does not transfer to forward prediction. We are honest about this in every retrospective.

Why this rule, written down

Real-time public claims about specific named third parties carry three categories of harm:

Defamation / tortious interference. Even hedged statements that imply fault toward a named entity create legal exposure. "FYI we noticed activity" is not a safe harbor.
Market manipulation. Signal about a publicly-traded company before regulator-confirmed disclosure can move stock.
False alarm at scale. A 60% precision rate sounds reasonable until you imagine the 40% — a major bank, a hospital network, a SaaS vendor — wrongly named on Twitter for a benign infrastructure event.

The post-confirmed-only rule eliminates all three. The cost is timeliness; the benefit is permanence — a published Cipherwake retrospective is something a serious analyst can cite without caveat.

Try it

Browse confirmed retrospectives at /post-mortems (when published).
Subscribe to /feed.xml for new retrospectives.
Disagree with an analysis? Send us a correction; we revise rather than defend.