How Faultline works

Faultline collects public records about cyber incidents and sorts them by how strong the evidence is. It shows what each source published and links to it. It does not add conclusions of its own.

Fast and verified pull in opposite directions

Proof that an attack happened arrives hours or days after the attack. A site that waits for proof is slow, and a site that reports everything at once repeats rumors. Faultline shows a record as soon as a source publishes it and labels how much evidence stands behind it.

The evidence ladder

Rules the site follows

• Every record links to the source it was read from.
• No AI model writes, summarizes or classifies anything on the site. Each line is assembled from fields in the source record.
• Nothing is called an attack unless the source says so. A leak-site post is shown as a claim. An outage is shown as an outage with the cause not known.
• Nothing is guessed. If a source gives no country or sector, the record says so.
• Two records are joined only when the source data links them. Records are never merged because the names look alike.
• If a source cannot be read, the site says it is down. It does not show a zero or an old number as if it were current.
• The site links to ransomware.live’s record of a leak-site post, never to the leak site.
• Vulnerability records sit in their own lists and are not counted as incidents.
• The globe draws no attack paths, because no source says where an attack came from.

Counts and times

• All times are UTC.
• A count covers the region, time window and filters selected on the board.
• Some sources date a record to the day and not the minute. Those are counted by calendar date, so the 24 hour view includes today and yesterday.
• The time on a leak-site claim is when the post was first seen. The intrusion, if there was one, happened earlier.
• A source that reaches back less far than the selected window is flagged on its rung of the ladder.

How a sector is assigned

In order, the first rule that applies wins:

• The sector field in the source record, or the SEC industry code on a filing, or the sector CISA puts on an advisory.
• A narrow match on the organization’s own name, such as “water authority” or “hospital”.
• An official domain ending, such as .gov or .edu.
• Otherwise the record is Unclassified.

Open any record on the board to see which rule placed it. Water utilities are usually filed under energy or government by the sources, so a name match on phrases like “water district” is checked first.

The activity level and the forecast

What is measured

Both numbers count new ransomware leak-site claims as recorded by ransomware.live, by the day each post was first seen. They count posts, not intrusions, and they say nothing about any one organization.

Activity level

The number of claims in the last seven complete days, compared with every seven-day stretch in the past year. “Busier than 90% of weeks” means 90% of those stretches had fewer claims.

Forecast

The forecast is the number of new claims expected in the next seven days. It uses about 13 months of daily counts, each post counted on the day it was first seen. The expected daily rate is a weighted average in which a day’s weight halves every 28 days, pulled slightly toward the long-run average. The seven-day total is then described by a negative binomial distribution, whose spread is fitted to how far past weeks landed from what was expected. The 80% range runs from the 10th to the 90th percentile of that distribution.

How the model was chosen

Four approaches were tested on the same 14 months of history: assuming next week repeats last week, a trailing average with Poisson spread, a self-exciting model of the kind used for earthquake aftershocks, and the one described above. The two simple baselines were badly overconfident. Their 80% ranges held less than 60% of the time on the busier series. The self-exciting model found no day-to-day excitation in this data: a burst of posts on one day did not raise the next day’s count. It scored about the same or worse, with less reliable ranges, so the simpler model is the one in use.

Track record

Every past forecast is replayed with only the data that was available on its day, then compared with what happened. The site reruns this each time it updates, so the numbers below are current. A new seven-day forecast is made every day, so these forecasts overlap and are not independent tests.

Loading the track record.

Misses are in claims per week. Where the range held less than 80% of the time, the ranges have been a little too narrow, and where it held more, a little too wide.

Where the forecast falls short

• One group publishing dozens of victims in a day cannot be foreseen. That is why the ranges are wide.
• A sector with very few past claims, such as water, cannot be forecast or tested. The site shows only its base rate.
• Sector comes from the source’s own label, so a mislabelled claim lands in the wrong series.
• There is no single score for the chance of a major outage. That needs a history of real outages to test against, which the connected sources do not carry.

Sources

Not connected yet

• The US Department of Health and Human Services breach portal, the official list of large health data breaches. It has no data feed and needs its own reader.
• US Department of Energy electric disturbance reports (form OE-417), which are published in batches.
• State attorney general breach notices, which every state publishes in a different format.
• Attack traffic and outage data from network operators such as Cloudflare Radar, which needs an access key.

What this site cannot tell you

• Most incidents are never published anywhere. An empty list means no source published a record, not that nothing happened.
• It cannot tell you whether a claim is true. Only the named organization or an investigator can.
• It does not predict attacks on any organization.