NIS2 (Directive (EU) 2022/2555): TLCTC Pain Points & Fixes

The TLCTC lens in 30 seconds

• Strategic layer (10 clusters): #1 Abuse of Functions | #2 Exploiting Server | #3 Exploiting Client | #4 Identity Theft | #5 Man‑in‑the‑Middle | #6 Flooding Attack | #7 Malware | #8 Physical Attack | #9 Social Engineering | #10 Supply Chain Attack.
• Operational layer: Every real attack is a sequence (e.g., #9 → #7 → #4), not an effect (“ransomware”).
• Axioms that matter for NIS2: Threats are causes, not outcomes; credentials are control elements (Axiom X), so their theft is a compromise; clusters are universal across IT/OT/IoT/cloud.

Main NIS2 pain points (from the TLCTC perspective)

1. 1) No common, cause-based threat taxonomy

   Problem: NIS2 requires entities to report incidents and even name the “type of threat/root cause,” but it doesn’t define a standard dictionary. Labels mix actors, effects, and tools.

   TLCTC impact: Data is not comparable across sectors or borders; trend analysis and guidance degrade.

   Fix: Make Attack Path (TLCTC) a mandatory line in every notification and final report; publish quarterly first‑cluster distributions.

2. 2) “Significant incident” thresholds ignore first‑cluster context

   Problem: Significance is gauged by impact, not by initiating cause.

   Impact: Two events with the same impact but different starting points (#9 vs. #2) get the same priority—misallocating prevention budgets.

   Fix: Add a cluster‑weighted triage: track and prioritize the top initiating clusters for your sector/state.

3. 3) Risk management mixes logic abuse (#1) with code defects (#2/#3)

   Problem: Everything is pushed into generic “vulnerability management.”

   Impact: #1 Abuse of Functions (design/scope) gets treated like coding bugs, so reviews and KPIs miss the mark.

   Fix: Keep separate risk sections and controls for #1 vs #2/#3 (constrained workflows, business‑rule guards, least privilege vs. SAST/DAST/patch SLAs).

4. 4) Credentials treated as "data,” not system controls (#4)

   Problem: Breaches due to token replay or password theft are still framed as data incidents.

   Impact: Post‑incident actions focus on cleanup instead of redesigning trust.

   Fix: Mandate phishing‑resistant, device‑bound credentials and PAM; treat #4 as a primary cause class in risk registers and audits.

5. 5) Update/transport trust not proven (#5 MitM)

   Problem: Entities claim TLS and signing but cannot show pinning, transparency logs, or device‑bound verification.

   Impact: Attack paths like #5 → #7 remain viable across sectors.

   Fix: Require evidence for #5 controls in audits and incident post‑mortems; verify update provenance end‑to‑end.

6. 6) DoS resilience (#6) under‑modeled in reporting and KPIs

   Problem: Flooding and capacity abuse are often logged as generic “availability incidents.”

   Impact: No learning loops on API quotas, back‑pressure, or scrubbing; same outages repeat.

   Fix: Include #6 test artefacts (rate‑limit, graceful degradation) in risk files and supervisory checklists.

7. 7) Execution control model missing (#7 Malware)

   Problem: Patching and EDR are present, but what can execute and with what rights is undocumented.

   Impact: Environments still run foreign code/LOLBAS.

   Fix: Ship an explicit execution policy (allow‑listing, namespaces/jails, signed‑only modules, runtime egress controls) and attest it.

8. 8) Physical surface (#8) treated as a separate domain

   Problem: Physical access enables #4/#7, yet is siloed from cyber risk files.

   Fix: Integrate #8 scenarios (debug ports, local extraction) into cyber risk and response testing.

9. 9) Supply‑chain risk noted but not quantified (#10)

   Problem: Vendors disclose SBOMs, but pipeline, signer, and distribution exposures remain opaque.

   Fix: Add a #10 exposure score and attestations (isolated builds, protected signers, provenance, reproducible builds, secured CDNs).

10. 10) Incident forms collect effects; attack‑paths are optional

    Problem: Staged reporting exists, but cause is free text.

    Fix: Add a short, mandatory Attack Path (TLCTC) line to early warning, 72‑hour update, and final report.

11. 11) CSIRT analytics lack a common cluster language

    Problem: National CSIRTs share data but taxonomies differ.

    Fix: CSIRTs and the Cooperation Group recommend TLCTC as the baseline for incident/root cause classification and advisories.

12. 12) Cross‑framework confusion (NIST, MITRE, ISO) persists

    Problem: Entities struggle to connect controls (NIST CSF) and TTPs (MITRE ATT&CK) to causes.

    Fix: Maintain a 10×5 TLCTC × NIST CSF matrix and map operational techniques back to clusters.

Common NIS2 attack‑path patterns (ready for your forms)

• Credential replay in remote access: #9 Social Engineering → #4 Identity Theft → #1 Abuse of Functions
• Remote code via server bug: #2 Exploiting Server → #7 Malware → #4 Identity Theft
• Update channel downgrade: #5 MitM → #7 Malware
• Supplier build compromise: #10 Supply Chain → #7 Malware → #4 Identity Theft
• API flood on public service: #6 Flooding Attack

Use these to tag incidents and trend first cluster over time.

Implementation kit (drop‑in, no law changes required)

• Add Attack Path (TLCTC) to early warning, 72‑hour notification, and final report.
• Keep a TLCTC Risk Register per entity: top 3 initiating clusters, controls, and verification artefacts.
• Build a 10×5 TLCTC × NIST CSF matrix; mark “local” vs “umbrella” controls.
• Require suppliers to attest #10 exposure and cluster coverage in contracts.
• CSIRTs publish quarterly cluster distributions and targeted advisories (e.g., surge in #5 on remote management).