Evolving VERIS — Replace the Action Axis, Expand the Attribute Axis

Verizon's VERIS — the Vocabulary for Event Recording and Incident Sharing — is the data spine behind the DBIR and a quietly important piece of cybersecurity infrastructure. Thousands of incident reporters, ISAC feeds, and downstream dashboards speak its dialect. That install base is exactly why VERIS deserves a careful evolution rather than a clean-sheet replacement.

But the careful evolution has to be honest about where VERIS breaks. Its core A4 model — Actor, Action, Asset, Attribute — was designed for statistical incident sharing, not cause-oriented analysis. That design choice is the root of every structural problem the framework has accumulated since 2010.

This post lays out a two-part evolution: replace Action outright (it has to go — it's the cause-side classification VERIS was always missing) and expand Attribute from a flat CIA tag into the full Bow-Tie consequence chain. Actor demotes to metadata. Asset becomes topology. The four-letter mnemonic survives; the semantics get repaired.

The Structural Problem: A4 Has No Bow-Tie Spine

VERIS records incidents but never declares where the System Risk Event sits. The pivot point between cause and consequence — what TLCTC calls the SRE, the moment of Loss of Control / System Compromise — has no representation in the schema. Causes and outcomes coexist on a flat tuple without semantic separation.

This is structurally what TLCTC Axiom III explicitly forbids: outcomes (Attributes) and causes (Actions) live in the same record without disambiguation. The result is that two incidents with the same VERIS Attribute can have entirely different cause chains — and the schema can't tell you which.

VERIS records what was lost. TLCTC asks why it was lost. Both questions matter; only one can drive control investment.

Per-Action Deficiencies

Malware (VERIS) ≠ #7 (TLCTC)

VERIS treats "Malware" as a top-level Action with sub-varieties like Adware, Backdoor, Capture stored data, Click fraud. Most of these are outcomes, persistence states, or DREs — not causes. TLCTC's R-EXEC rule requires #7 to be recorded at the moment of Foreign Executable Content execution, paired with the enabling cluster (#3 client exploit, #9 social engineering, #10 supply chain). VERIS records the malware and loses the cause that delivered it.

Hacking is a grab-bag

VERIS sub-varieties under "Hacking" span four distinct TLCTC clusters:

• Exploit vuln → #2 or #3 (per R-ROLE)
• Use of stolen creds → #4 (per R-CRED, with the acquisition recorded as a separate upstream step)
• MitM → #5 (gaining position is again a separate upstream step)
• Brute force → typically #4, sometimes #1 (lockout-policy abuse)
• DoS → #6 or #2/#3 (per R-FLOOD)

One VERIS bucket; five TLCTC discriminations lost.

Social ≈ #9, but flat

VERIS records "Social" as a single Action. TLCTC requires the chain: #9 → #4 for credential harvest, #9 → #7 for malware delivery, #9 → #1 for function abuse like wire-transfer fraud. Without R-HUMAN's mandate to separate the manipulation step from the technical follow-on, the analytic granularity disappears.

Misuse conflates #1 and #4

"Privilege abuse" by an authorized insider abusing legitimate function scope is #1. "Use of stolen creds" by the same insider is #4. VERIS sees one actor and calls both "Misuse"; TLCTC sees two distinct generic vulnerabilities — one is the inherent trust designed into functions, the other is authentication credentials being applied as identity. Different causes, different controls.

Error and Environmental are not threats at all

VERIS includes Error ("Misconfiguration", "Misdelivery", "Programming error") and Environmental ("Fire", "Flood", "EMI") as Actions. TLCTC Axiom V says control failure is not a threat category. Axiom II scopes the framework to cyber threats; environmental events are operational/BCM risks. Both belong on separate dimensions, not on the threat axis. VERIS conflates them with attacker-driven causes, which makes any DBIR statistic that mixes them difficult to interpret.

What VERIS Lacks That TLCTC Has

1. No causal chain semantics. Every real incident is a sequence; VERIS records one Action varietal at a time. SolarWinds in VERIS becomes "Hacking" or "Malware". In TLCTC: a path with topology and velocity.
2. No velocity (Δt). Without Δt and the four velocity classes, records can't drive control posture — architecture vs. SOAR vs. SIEM vs. threat hunting are unanswerable.
3. No bridge or internal topology. No trust boundary or responsibility sphere — fatal for supply chain and third-party incidents.
4. No native control mapping. TLCTC's 10 × (6 × 2) matrix produces direct CSF coverage; VERIS records sit beside CSF but don't map to it.
5. No falsifiability. VERIS categories are conventions; TLCTC clusters are defined by axiomatic generic vulnerabilities — disputable, testable, refinable.
6. Actor as a primary axis. External / Internal / Partner is treated as structural; TLCTC reduces it to TI metadata (Axiom IV).

The Evolution: A4 → A4⁺

The four-letter mnemonic stays. Analysts still record Actor, Action, Asset, Attribute. What changes is the semantic content of each axis:

Replacing the Action Axis

The legacy enum has to go. The replacement is mechanical — TLCTC already provides every field needed:

• cluster — strategic (#1…#10) or operational (TLCTC-XX.YY)
• delta_t_to_next — velocity to the following step
• topology_boundary — for bridge clusters and sphere crossings
• fec_executed + fec_recorded_in_step_id — R-EXEC enforcement
• evidence_refs — pointers to logs, telemetry, forensic artifacts

Mechanical migration of legacy Action varietals

Expanding the Attribute Axis into SRE → DRE → BRE

The current Attribute axis only records the technical data outcome. It misses the SRE pivot and ignores business consequences entirely. The evolved axis becomes a three-level consequence record matching the TLCTC Bow-Tie right-hand side:

Level 1 — SRE (System Risk Event)

• Boolean: did Loss of Control / System Compromise occur?
• Δt from the cause-side terminal step to the SRE — the detection-and-intervention window
• Containment outcome (contained at SRE / progressed to DRE)

Level 2 — DRE (Data Risk Event)

• C — Loss of Confidentiality
• I — Loss of Integrity
• Av — Loss of Availability (data gone or unreachable)
• Ac — Loss of Accessibility (data present but unusable — ransomware, lockout)

Multiple DREs per incident permitted; each carries its own Δt from the SRE. The Av/Ac distinction alone is a meaningful upgrade — VERIS today cannot tell you whether ransomware encrypted the files (Ac) or wiper malware deleted them (Av), even though the recovery posture is categorically different.

Level 3 — BRE (Business Risk Event)

• Boolean: did Loss of Control / System Compromise occur?
• Δt from the cause-side terminal step to the SRE — the detection-and-intervention window
• Containment outcome (contained at SRE / progressed to DRE)

Level 2 — DRE (Data Risk Event)

• C — Loss of Confidentiality
• I — Loss of Integrity
• Av — Loss of Availability (data gone or unreachable)
• Ac — Loss of Accessibility (data present but unusable — ransomware, lockout)

Multiple DREs per incident permitted; each carries its own Δt from the SRE. The Av/Ac distinction alone is a meaningful upgrade — VERIS today cannot tell you whether ransomware encrypted the files (Ac) or wiper malware deleted them (Av), even though the recovery posture is categorically different.

Level 3 — BRE (Business Risk Event)

• Regulatory notification triggered
• Financial loss (direct, recovery, fines)
• Operational disruption (SLA breach, outage duration)
• Reputational impact
• Legal and contractual exposure
• Customer or counterparty harm

Each BRE carries a Δt from its triggering DRE. This makes the consequence chain measurable the same way the cause chain is — variable-length, time-stamped, comparable across incidents.

What an Evolved Record Looks Like

A 2025-era credential-stuffing incident under legacy VERIS:

The same incident under the evolved schema:

Same fields, same analyst workflow. The record is now causally comparable to other incidents, velocity-quantified for control posture, and consequence-decomposed for risk reporting.

Migration Strategy

What This Buys VERIS and DBIR

The DBIR's core product — population-level statistics on what's actually happening in incidents — gets sharply better:

• Cluster-level frequency, with sub-cluster precision when evidence supports it
• Edge-level frequency (#9 → #4 vs. #9 → #7 — currently invisible in DBIR)
• Velocity distributions per cluster — the missing dimension for control investment ROI
• DRE distributions decomposed (C vs. Av vs. Ac — ransomware, destruction, and leak finally distinguishable)
• BRE quantification independent of DRE — same data breach, very different business impact across sectors

Bottom Line

VERIS is an early, well-intentioned attempt at the problem TLCTC solves axiomatically. Its A4 model ships three structural defects: Action conflates causes, outcomes, and non-threats; Actor and Attribute sit on the same axis as Action, blurring the Bow-Tie; and there is no chain, no Δt, no native control mapping.

The pragmatic path is evolution, not replacement. Replace Action with TLCTC outright — there is no half-measure that recovers the cause-side classification VERIS was always missing. Expand Attribute into SRE → DRE → BRE — the right-hand side of the Bow-Tie is where business-relevant outcomes actually live. Demote Actor to metadata. Recast Asset as topology.

Verizon keeps the DBIR. The cybersecurity community gets a record format that is finally cause-disciplined. The four-letter mnemonic survives; the framework underneath it works.

VERIS asked the right question seventeen years ago: how do we record incidents in a comparable way? It just didn't have a cause-side taxonomy to anchor on. TLCTC is that anchor.