AZ-039 — Threat Model Consolidation and Residual Risk Canon v1

Status

Acest document definește canonul unificat pentru:

• threat model;
• clasele de adversari;
• suprafețele de atac;
• controalele de mitigare;
• și registrul de risc rezidual după toate etapele majore ale sistemului ATLAS ZERO.

După AZ-001 până la AZ-038, există deja:

• specificația protocolului și a subsistemelor;
• modelul de securitate și incident response;
• launch discipline, monitoring, stabilization și archive;
• upgrade, hard fork, key compromise și archive preservation;
• interfața de audit extern și exportul de dovezi.

AZ-039 răspunde la întrebarea: cum consolidăm într-un singur canon toate ipotezele de adversar, suprafețele de atac, controalele existente, limitele cunoscute și riscurile reziduale, astfel încât proiectul să poată spune exact ce apără, împotriva cui, cu ce dovezi și ce rămâne încă deschis sau acceptat?

Scopul documentului este să fixeze:

• taxonomia unificată a amenințărilor;
• clasele de adversari și capabilități;
• suprafețele de atac;
• mapping-ul threat -> control -> evidence -> residual risk;
• registrul canonic al riscului rezidual;
• regulile de reevaluare a riscului după launch, upgrade, incident și audit.

Acest document se bazează pe:

• AZ-002 până la AZ-038, cu accent direct pe AZ-008, AZ-015, AZ-017, AZ-027, AZ-031, AZ-032, AZ-033, AZ-034, AZ-035, AZ-037 și AZ-038.

Termeni:

• MUST = obligatoriu
• MUST NOT = interzis
• SHOULD = recomandat puternic
• MAY = opțional

1. Obiectiv

AZ-039 răspunde la 10 întrebări critice:

1. Care este threat model-ul unificat al ATLAS ZERO?
2. Ce tipuri de adversari și capabilități presupunem?
3. Ce suprafețe de atac sunt relevante?
4. Ce controale există deja și unde?
5. Ce dovezi susțin că acele controale există și funcționează?
6. Ce riscuri rămân deschise sau doar parțial mitigate?
7. Ce riscuri sunt acceptate explicit și de către cine?
8. Cum se reevaluează riscul după launch, upgrade, incident sau audit extern?
9. Cum se diferențiază risc teoretic, risc operațional și risc rezidual acceptat?
10. Cum evităm optimismul vag sau securitatea declarativă fără canon al riscului?

2. Principii

2.1 Threat model must be explicit and falsifiable

Threat model-ul MUST conține ipoteze verificabile și contestabile, nu doar limbaj general despre securitate.

2.2 Residual risk is normal, hidden risk is not

Riscul rezidual există întotdeauna. Problema reală este riscul nenumit, neclasificat sau neasumat explicit.

2.3 Controls matter only when scoped and evidenced

Un control fără:

• scope clar;
• precondiții clare;
• și dovadă de existență sau operabilitate, este slab.

2.4 Security claims must bind to artifacts and process

Afirmațiile de securitate SHOULD fi legate de:

• specificații;
• implementări;
• testare;
• monitoring;
• audit;
• runbooks;
• și arhive.

2.5 Threat model is living governance memory

Threat model-ul MUST evolua când apar:

• noi clase de bug;
• noi upgrade-uri;
• noi incidente;
• noi suprafețe de atac;
• noi limite operaționale.

2.6 Risk acceptance must be explicit

Un risc nu este „acceptat” doar pentru că nu s-a rezolvat încă. Acceptarea lui SHOULD fi explicită, scope-bound și temporal delimitată unde e cazul.

3. Threat model purpose

3.1 The threat model SHOULD answer:

• ce apără sistemul?
• împotriva cui?
• prin ce mecanisme?
• în ce limite?
• cu ce riscuri reziduale?

3.2 Rule

Threat model-ul MUST fie suficient de concret încât să poată alimenta:

• readiness;
• launch decisions;
• incident triage;
• audit exports;
• upgrade reviews;
• residual risk acceptance.

4. Threat model dimensions

4.1 Core dimensions

Threat model-ul SHOULD acoperi cel puțin:

1. asset model
2. adversary model
3. attack surface model
4. trust boundary model
5. control model
6. evidence model
7. residual risk model
8. re-evaluation model

4.2 Rule

Omiterea oricărei dimensiuni produce model de risc incomplet.

5. Asset model

5.1 Protected asset classes

ATLAS ZERO SHOULD considera cel puțin următoarele clase de active:

• ASSET_CONSENSUS_TRUTH
• ASSET_FINALITY
• ASSET_STATE_INTEGRITY
• ASSET_BVM_BOUNDEDNESS
• ASSET_AUTHORIZATION_INTEGRITY
• ASSET_WITNESS_AND_PROOF_INTEGRITY
• ASSET_ECONOMIC_SAFETY
• ASSET_GOVERNANCE_CORRECTNESS
• ASSET_RELEASE_AND_GENESIS_PROVENANCE
• ASSET_OPERATOR_CONTROL_PLANE
• ASSET_KEY_MATERIAL_AND_ROLE_BINDINGS
• ASSET_ARCHIVE_AND_AUDIT_TRUTH

5.2 Rule

Fiecare risc SHOULD spună explicit ce active afectează.

6. Adversary classes

6.1 Standard adversary classes

ATLAS ZERO SHOULD distinge cel puțin:

• ADV_EXTERNAL_UNPRIVILEGED
• ADV_SPAMMER_ECONOMIC
• ADV_BYZANTINE_VALIDATOR
• ADV_COLLUDING_VALIDATOR_SET
• ADV_COMPROMISED_OPERATOR
• ADV_COMPROMISED_SIGNER
• ADV_MALICIOUS_INTEGRATOR
• ADV_WITNESS_OR_ORACLE_FORGER
• ADV_RELEASE_SUPPLY_CHAIN_ATTACKER
• ADV_GOVERNANCE_ABUSER
• ADV_ARCHIVE_TAMPERING_ACTOR
• ADV_INTERNAL_MISCONFIGURATION_ACTOR

6.2 Rule

Adversary class MUST be explicit in risk records and threat mappings.

7. Adversary capability model

7.1 Capability classes SHOULD include:

• network observation
• message replay
• message delay
• spam/flooding
• limited signature theft
• full key compromise
• partial validator collusion
• majority validator collusion assumptions if modeled
• malformed object crafting
• supply-chain substitution
• operator misconfiguration leverage
• archive copy tampering
• disclosure timing manipulation

7.2 Rule

Threat records SHOULD distinguish capability from intent.

8. Trust boundaries

8.1 Core trust boundaries

The model SHOULD identify:

• protocol boundary
• node-local boundary
• signing boundary
• operator control boundary
• governance boundary
• release/build boundary
• archive boundary
• external audit/export boundary

8.2 Rule

Controls SHOULD be mapped to specific trust boundaries, not only to broad system labels.

9. Attack surface families

9.1 Recommended families

• canonical encoding and hashing
• transaction validation
• state transition logic
• BVM verifier/runtime
• consensus and finality
• witness/proof verification
• economics and spam surfaces
• governance and emergency powers
• release/build pipeline
• genesis and launch artifacts
• key lifecycle and signing
• operator tooling and configuration
• monitoring and incident handling
• archive and evidence export

9.2 Rule

Every major subsystem SHOULD appear in the attack surface map.

10. Threat classes

10.1 Standard threat classes

ATLAS ZERO SHOULD support at least:

• TH_DETERMINISTIC_DIVERGENCE
• TH_FINALITY_FAILURE
• TH_UNAUTHORIZED_STATE_CHANGE
• TH_AUTHORIZATION_BYPASS
• TH_BVM_BOUNDEDNESS_ESCAPE
• TH_WITNESS_FORGERY_OR_MISUSE
• TH_ECONOMIC_DOS_OR_SPAM
• TH_GOVERNANCE_CAPTURE_OR_MISACTIVATION
• TH_RELEASE_OR_GENESIS_SUBSTITUTION
• TH_KEY_COMPROMISE
• TH_OPERATOR_MISCONFIGURATION
• TH_ARCHIVE_CORRUPTION_OR_LOSS
• TH_AUDIT_EXPORT_MISREPRESENTATION

10.2 Rule

Threat classes SHOULD be stable enough for longitudinal risk tracking.

11. Threat record object

11.1 Canonical structure

ThreatRecord {
  version_major
  version_minor

  threat_id
  threat_class
  asset_root
  adversary_class
  capability_root
  attack_surface_root
  trust_boundary_root
  severity_potential
  likelihood_class
  exploitability_class
  notes_hash?
}

11.2 severity_potential

• low
• medium
• high
• critical
• systemic

11.3 Rule

Threat records SHOULD be reusable references for control and residual risk records.

12. Control model

12.1 Control classes SHOULD include:

• protocol invariant
• deterministic encoding rule
• semantic version gate
• conformance test suite
• formal validation rule
• cryptographic attestation
• operator checklist
• monitoring alert
• incident runbook
• launch checkpoint
• archive verification schedule
• governance review gate
• key revocation path

12.2 Rule

Controls MUST be typed and scope-bound.

13. Control record object

13.1 Canonical structure

ControlRecord {
  control_id
  control_class
  control_scope_hash
  protected_asset_root
  mitigated_threat_root
  implementation_ref?
  process_ref?
  evidence_requirement_root?
  effectiveness_class
}

13.2 effectiveness_class

• preventive
• detective
• corrective
• recovery
• deterrent

13.3 Rule

A control SHOULD say whether it prevents, detects, limits or recovers.

14. Threat-to-control mapping

14.1 Canonical structure

ThreatControlMap {
  map_id
  threat_id
  control_id
  mitigation_scope_hash
  expected_effect_hash
}

14.2 Rule

Major threats SHOULD map to more than one control where reasonable. Defense in depth matters.

15. Evidence model

15.1 Evidence classes SHOULD include:

• spec section ref
• conformance corpus ref
• test result ref
• simulation result ref
• audit finding ref
• incident record ref
• monitoring profile ref
• launch/stabilization decision ref
• archive verification ref
• operator checklist ref

15.2 Rule

Threat mitigations without any evidence link SHOULD be treated conservatively.

16. Control evidence record

16.1 Canonical structure

ControlEvidenceRecord {
  evidence_id
  control_id
  evidence_class
  evidence_ref
  evidence_scope_hash
  timestamp_unix_ms?
}

16.2 Rule

Evidence SHOULD bind to the control and the scope where it was observed or verified.

17. Residual risk model

17.1 Need

Even after controls exist, some risk remains.

17.2 Residual risk SHOULD capture:

• remaining uncertainty
• known limitation
• bounded exposure
• open dependency
• operational fragility
• insufficient evidence
• accepted but not eliminated risk

17.3 Rule

Residual risk is not “all risk not mentioned elsewhere”. It must be explicitly recorded.

18. Residual risk record

18.1 Canonical structure

ResidualRiskRecord {
  version_major
  version_minor

  residual_risk_id
  linked_threat_id
  affected_asset_root
  residual_risk_class
  severity_residual
  likelihood_residual
  exploitability_residual
  current_control_root
  evidence_root?
  acceptance_status
  owner_role_class
  review_due_hash?
  notes_hash?
}

18.2 residual_risk_class examples

• open_unknown
• bounded_known_gap
• operational_dependency
• monitoring_gap
• ecosystem_dependency
• not_yet_mitigated
• accepted_tradeoff
• temporary_during_transition

18.3 acceptance_status

• unaccepted
• proposed_for_acceptance
• accepted_temporarily
• accepted_until_mitigation
• accepted_long_term
• retired
• invalidated

18.4 Rule

Residual risk MUST have owner and status.

19. Residual risk acceptance

19.1 Acceptance SHOULD require:

• explicit scope
• explicit owner
• explicit severity/likelihood statement
• explicit rationale
• explicit review boundary or permanence class
• evidence that controls actually exist where claimed

19.2 Rule

Critical or systemic residual risks SHOULD require stronger acceptance authority than low ones.

20. Residual risk canon

20.1 Definition

Residual Risk Canon = authoritative set of active residual risks for a given scope.

20.2 Canonical structure

ResidualRiskCanon {
  canon_id
  scope_hash
  active_risk_root
  retired_risk_root?
  review_window_hash
  timestamp_unix_ms
}

20.3 Rule

Launch, upgrade and stabilization decisions SHOULD be able to reference the active residual risk canon.

21. Risk review triggers

21.1 Threat and residual risk SHOULD be reevaluated when:

• new critical bug discovered
• incident opens
• upgrade or hard fork proposed
• launch readiness reviewed
• stabilization review completed
• archive verification fails materially
• key compromise occurs
• external audit reveals new gap

21.2 Rule

Risk canon MUST evolve when system truth changes materially.

22. Risk review object

22.1 Canonical structure

ThreatRiskReviewRecord {
  review_id
  review_scope_hash
  threat_root
  residual_risk_root
  findings_root
  review_result_class
  timestamp_unix_ms
}

22.2 review_result_class

• no_material_change
• updated_risk_posture
• new_critical_risk
• risk_reduced
• risk_invalidated
• requires_governance_attention

22.3 Rule

Review records SHOULD be archivable and linked to decisions.

23. Severity and likelihood semantics

23.1 Severity SHOULD measure blast radius to protected assets.

23.2 Likelihood SHOULD measure plausible occurrence under defined adversary capability and current controls.

23.3 Exploitability SHOULD capture how feasible attack execution is in practice.

23.4 Rule

These dimensions SHOULD not be collapsed into one vague number in canonical records.

24. Threat posture by lifecycle phase

24.1 Different phases change risk posture:

• pre-launch
• launch window
• early mainnet
• steady state
• upgrade rollout
• incident response
• post-incident recovery
• long-term archive preservation

24.2 Rule

A threat may be acceptable in one phase and unacceptable in another. Risk canon SHOULD be phase-aware where relevant.

25. Launch-specific risk canon linkage

25.1 Launch readiness SHOULD bind to:

• threat classes relevant to launch artifacts
• operator readiness risks
• finality and monitoring risks
• residual risks accepted for launch scope

25.2 Rule

GO decisions SHOULD not exist in isolation from residual risk canon.

26. Upgrade-specific risk canon linkage

26.1 Upgrade rollout SHOULD bind to:

• version-compatibility risks
• mixed-fleet risks
• migration risks
• key rotation or operator error risks
• rollback infeasibility risks

26.2 Rule

Major upgrades SHOULD carry an updated residual risk canon for the rollout scope.

27. Incident-specific risk canon linkage

27.1 Incident handling SHOULD update:

• threat understanding
• exploited capability assumptions
• control effectiveness
• new residual risks or retired assumptions

27.2 Rule

A serious incident with no risk canon update is a missed learning event.

28. Archive-specific risk canon linkage

28.1 Long-term archive preservation SHOULD track:

• silent corruption risk
• restore failure risk
• verifier tool obsolescence risk
• format-decay risk
• cross-copy inconsistency risk

28.2 Rule

Preservation risk belongs in the same canon, not in a separate forgotten silo.

29. Threat model consolidation object

29.1 Canonical structure

ThreatModelCanon {
  version_major
  version_minor

  canon_id
  canon_scope_hash
  asset_root
  threat_root
  control_root
  residual_risk_canon_ref
  evidence_root?
  timestamp_unix_ms
}

29.2 Rule

This object represents the consolidated current view, not every historical draft.

30. Control effectiveness reevaluation

30.1 Controls SHOULD be reevaluated when:

• tests fail
• incidents bypass them
• audits question them
• operators cannot execute them
• monitoring fails to detect what it promised
• archive verification reveals preservation weaknesses

30.2 Rule

Control presence is not the same as control effectiveness.

31. Threat model evidence gaps

31.1 Some risks exist because evidence is weak, not because design is obviously broken.

31.2 Evidence gap classes MAY include:

• untested edge
• limited simulation
• no red-team coverage
• missing external audit
• insufficient operator rehearsal
• insufficient mixed-fleet exercise

31.3 Rule

Evidence gaps SHOULD themselves be represented as residual risk contributors where material.

32. Threat model export and audit

32.1 External audit interfaces SHOULD be able to export:

• threat canon subset
• residual risk canon subset
• control evidence mapping
• acceptance records for declared residual risks

32.2 Rule

External security claims SHOULD be backed by exportable threat/risk evidence where possible.

33. Governance interaction

33.1 Governance SHOULD be able to review:

• active critical/systemic residual risks
• acceptance history
• retired risks
• risks reopened by upgrades/incidents
• control failures requiring constitutional or policy action

33.2 Rule

Risk canon SHOULD be governance-visible for material classes, not hidden inside engineering notes.

34. Anti-patterns

Systems SHOULD avoid:

1. saying “secured by design” with no threat records
2. mixing adversary class and likelihood in vague language
3. treating controls as effective because they exist on paper
4. no owner for residual risk
5. accepting risk implicitly by schedule pressure
6. not updating threat model after incident or hard fork
7. keeping archive preservation risk outside security canon
8. reducing all security posture to one numeric score
9. hiding evidence gaps inside optimistic prose
10. maintaining separate inconsistent threat models across teams

35. Formal goals

AZ-039 urmărește aceste obiective:

35.1 Unified security memory

The system has one coherent canon linking threats, controls, evidence and residual risks.

35.2 Honest residual risk accounting

Remaining risks are named, owned and reviewable.

35.3 Lifecycle-aware risk posture

Launch, upgrade, incident and preservation phases can each express current risk posture clearly.

35.4 Audit and governance usability

Threat and residual risk records can feed decisions, audits and future hardening.

36. Formula documentului

Threat Model Canon = explicit assets + adversaries + attack surfaces + typed controls + evidence mapping + active residual risk register + scheduled re-evaluation

37. Relația cu restul suitei

• AZ-017 definește readiness.
• AZ-030 definește decision ledger.
• AZ-032 definește stabilization review.
• AZ-038 definește exportul de dovezi.
• AZ-039 le leagă pe toate într-un canon coerent al amenințărilor și riscurilor reziduale.

Pe scurt: AZ-039 este memoria de securitate consolidată a întregii suite.

38. Ce urmează

După AZ-039, documentul corect este:

AZ-040 — Formal Conformance Claim Framework

Acolo trebuie fixate:

• cum formulăm formal afirmațiile de conformitate;
• ce tipuri de claims există;
• ce dovezi sunt necesare pentru fiecare;
• și cum evităm afirmațiile de compatibilitate sau corectitudine care sunt prea vagi pentru a fi auditate.

Închidere

Un sistem matur nu este doar cel care are multe controale. Este cel care poate spune, într-o formă unificată și onestă: acestea sunt amenințările, acestea sunt controalele, acestea sunt dovezile, acestea sunt limitele, și acestea sunt riscurile pe care încă le purtăm.

Acolo începe securitatea care poate fi guvernată și auditată, nu doar sperată.