The TLCTC tools were eleven separate single-file apps. They shared a menu and a cluster number, and nothing else. This update adds three tools that work from the same source — the 59 attack-path records in the repository — and answer three questions the others could not: which cluster follows which, and how fast (Path Atlas); how reproducibly do analysts classify (Classification Trainer); and where do your detection and containment times beat the attacker (Δt Race). Before building them, the existing tools needed repairs: four of them opened blank from a clone, and two carried cluster wording that errata had already corrected. Everything runs in the browser; nothing you load is sent anywhere.
First, the Repairs
The tools on this site were maintained as copies of the tools in the repository, with site-only additions. Over time the two drifted apart, and the repository copies drifted from the framework. A review found four problems.
- Blank from a clone. Eight of the eleven tools loaded their libraries from paths that exist only on this web server. Opened from a downloaded repository, the Control Matrix, CBP, Threat Radar and Threat Modeling tools showed an empty page, and both explorers lost their layout.
- Old canon. The CBP app still carried the generic vulnerability of
#4from before the v2.3.1 erratum, and the Threat Radar still described#8with “hardware or facilities”, which the v2.5.1 erratum removed. - Two sources. Several site copies were behind the repository (one still declared its cluster text “verbatim from v2.3”), and nothing kept them in step.
- A live bug. The Tech Enablers Radar opened with an empty grid until you loaded an example: the page tried to draw the grid before its code had been compiled.
The repository is now the only source. The site build copies each tool over and swaps the public library links for the site's own copies, so the site makes no third-party requests and a clone works from disk. A new check runs with every validation: embedded generic vulnerabilities and definitions must match the current dictionary word for word, cluster descriptions may not use wording an erratum retired, and every library a tool loads must have a local copy. The two canon errors and the Tech Enablers bug are fixed.
Path Atlas: Which Cluster Follows Which
The repository holds 59 attack-path records — incidents and patterns from public reporting, each a sequence of classified steps with the time between them. The Path Atlas reads them together. Its centre is a 10×10 transition matrix: rows are the cluster of a step, columns the cluster of the step that follows. Next to it, the velocity panel shows how fast each transition happens, as the four velocity classes and as fastest, median and slowest time. Every number opens the steps behind it.
#4 → #1 selected: 59 transitions in 37 records, median 5 minutes, 23 of them under a minute.Across the 59 records the Atlas counts 331 classified steps and 273 transitions. The five most frequent:
| Transition | Count | Records | Median Δt | Under a minute |
|---|---|---|---|---|
#4 → #1 Identity Theft → Abuse of Functions | 59 | 37 | 5 min | 23 |
#1 → #1 Abuse of Functions, repeated | 38 | 22 | 2 h | 3 |
#7 → #1 Malware → Abuse of Functions | 28 | 23 | 10 s | 12 |
#1 → #7 Abuse of Functions → Malware | 26 | 21 | 4.5 min | 11 |
#1 → #4 Abuse of Functions → Identity Theft | 25 | 15 | 10 min | 4 |
Paths start most often with #9 Social Engineering (24 of 59) and #4 Identity Theft (13), and end most often in #1 Abuse of Functions (39). The picture that emerges is familiar but now countable: a credential is used, and minutes later a legitimate function is doing the attacker's work.
Two counting rules matter. A parallel group — (#X + #Y), steps without a meaningful order — links to the step before and after it, but never forms a transition within itself. And an unresolved step (? or …) breaks the chain: counting X → Y across a gap would claim an adjacency the evidence does not show. The Atlas reports how many links were lost that way (one, here).
The 59 records are curated and AI-assisted analyses of public reporting. The statistics describe these records, not the threat landscape: a transition is frequent here partly because the reports that were analysed describe it often. The Atlas is built for your own corpus — import a folder of your Layer-3 incident files and it computes the same view over them, in the browser, without storing them.
Classification Trainer: How Reproducible Is TLCTC?
The core paper is candid about what has not been shown yet. Its limitations section begins: “Empirical validation is outstanding. The reproducibility claim — that independent analysts, guided by the axioms and boundary tests, classify the same incident the same way — is testable but not yet tested at scale.” The Classification Trainer makes that test something anyone can run.
It has three modes.
- Practice. You get one step from a real attack path and choose its cluster. Scenarios are drawn evenly across the ten clusters, so rare ones come up as often as common ones. After you answer you see the record's classification, the canonical definition and generic vulnerability of both clusters when they differ, the original analysis, and the dictionary text of every rule it cites.
- Study. Several analysts enter the same study code and receive the same fixed set of scenarios, balanced across clusters, with no feedback. Each downloads a rating sheet at the end.
- Results. Load the rating sheets and the trainer computes how much the analysts agree beyond chance (Fleiss' κ, overall and per cluster), how each analyst compares with the record, and which scenarios split the group.
#4, and R-CRED explains why.Building it meant solving one problem first. The step notes in the records were written as analyses, not as exam questions: 291 of the 331 step notes name a cluster number, a rule, an axiom or a cluster in so many words. The trainer keeps only the sentences that describe what happened, and drops every sentence that names a cluster, cites a rule or axiom, uses boundary notation or argues the classification. A test checks the whole corpus for leftovers on every build. That leaves 303 usable scenarios, unevenly spread: 134 for #1, only 2 for #5.
One more caution is built into the tool itself. The answer key is the classification in the record — one analyst's reviewed reading, not ground truth. Agreement between independent analysts is the reproducibility measure; disagreement with the key is a finding to discuss, and sometimes a reason to revise the record.
Δt Race: Where You Stop the Attacker
Attack velocity is a time, and time can be compared with the defender's own. The core paper (§7.2) defines the Detection Coverage Score in two forms, read at the 90th percentile of the defender's times:
DCS_d = TTD_P90 / Δt (detection)
DCS_c = TTC_P90 / Δt (containment)Below 1 you act before the attacker completes the transition; above 1 the step completes first. Only containment stops a transition: detected in time but contained too late means the step was seen and completed anyway. The Δt Race applies this to every transition of an attack path. You enter your time to detect and time to contain per cluster — or import them from a Control Matrix export — and the Race shows, transition by transition, who wins, and names the first transition you would contain.
Run the Active Directory ransomware cascade from the corpus against a defender who detects within an hour and contains within eight: one transition out of fifteen is contained, the #7 → #1 step that took about a day. Every other step takes between five minutes and an hour. Cut the times to two minutes to detect and five to contain, and eight transitions are contained — the other seven are seen, but containment arrives exactly as the attacker moves on, with no buffer. That is the point the application paper makes about velocity: at minutes, the investment that matters is automation and playbooks; below about a minute, no detection is fast enough, and the answer is architecture that denies the step.
The time per transition can come from the path itself or from the corpus. Where a transition has been observed many times, the core reads its distribution at the fast tail (P10), and the Race can use exactly that from the Atlas corpus. It also checks each transition against DCS targets per velocity class; the defaults are the example values of the application paper (§10.3), meant to be replaced with your own. One convention is the tool's, not the framework's, and the page says so: a transition X → Y is measured against your times for X, the step the attacker is leaving.
How the Pieces Fit
The three tools share their data and their rules. The attack-path records are bundled once, from the repository, for the browser. The counting rules — how transitions, parallel groups, gaps and times are read — live in one shared module that the Atlas and the Race both use, and that the build tests against the corpus. The trainer quotes cluster definitions and rule statements from a file generated from the framework dictionary, so a change to the canon reaches the tools without anyone copying text by hand. Each tool exports its results as JSON, so the numbers can travel to other tools and reports.
They also serve the three audiences TLCTC is written for. Security operations can read the Atlas as a map of what follows what, and how fast. Governance can use the Race to turn “how fast do we detect?” into “fast enough, for which transitions?”, with targets derived from risk appetite. And anyone who classifies — analysts, developers mapping weaknesses, trainers of both — can practise on real steps and measure how consistently a team applies the rules.
All three run in the browser, on this site or from a clone of the repository. Files you import are analysed in the open tab and are not stored or sent. Only your own inputs — Race times, an unfinished study — are kept in your browser's storage so a reload does not lose them.
What Comes Next
- An agreement study. The trainer can produce the first inter-rater numbers for TLCTC. If you teach or run a team of analysts, agree on a study code, let everyone rate the same set, and load the sheets under Results — the agreement figures are computed on the spot.
- Out-of-scope cases in the trainer. The corpus contains only Attack-row steps, so the trainer cannot yet practise the R-SCOPE decision that a step is Abuse of Rights and has no cluster at all.
- The corpus in the Attack Path Architect. The Architect still offers around twenty built-in examples; the 59 records should be available there as well.
- More paths. Every incident analysed and added to the repository makes the Atlas and the corpus P10 in the Race more informative.
Try Them
Sources. The numbers in this post come from the 59 records in attack-paths/ of the TLCTC repository (corpus hash dbeea95f), computed by the tools described. Detection Coverage Score and velocity classes: TLCTC core paper §7.2; DCS as a key control indicator and the example targets per velocity class: TLCTC application paper §10.2–10.3; the reproducibility quote: core paper §8. The Race scenario uses illustrative defender times, not measurements from any organisation.