Skip to content

NIS2_HISTORY_EVIDENCE.md

Latest commit

 

History

History
37 lines (29 loc) · 3.09 KB

NIS2_HISTORY_EVIDENCE.md

File metadata and controls

37 lines (29 loc) · 3.09 KB
Raw

NIS2 History Evidence Guidance

BaSyx provides technical controls that can support NIS2-aligned integrity, auditability, traceability, recovery, and tamper-detection requirements when deployed and operated correctly. Enabling history evidence does not make an operator NIS2 compliant by itself.

BaSyx Technical Controls

  • Canonical content_hash, payload_hash, previous_hash, and row_hash values protect history row integrity.
  • Append-only PostgreSQL history rows and optional guarded PostgreSQL mode support traceability.
  • Per-row WORM history_event artifacts provide tamper-evident recovery material for acknowledged writes while evidence storage is enabled.
  • Activation-time WORM abac_policy_version artifacts preserve the configured and materialized access-rule version that produced audited policy_id and matched_rule_id values.
  • Signed manifests and range digests support independent verification of selected history ranges.
  • CLI verification and recovery export detect missing, modified, reordered, conflicting, or unverifiable evidence.
  • Audit context fields record request, OIDC, ABAC, route, and trusted proxy metadata when configured and available.

Operator Responsibilities

  • Perform risk analysis and maintain information security policies.
  • Define incident handling, escalation, crisis management, and evidence preservation processes.
  • Operate backup management, disaster recovery, and restore drills.
  • Configure and monitor S3 Object Lock or equivalent WORM storage, including retention, versioning, IAM, MFA, and least privilege.
  • Generate, rotate, back up, and distribute signing and verification keys through controlled trust processes.
  • Monitor verifier findings and alert on critical drift or signature failures.
  • Manage vulnerability handling, patching, and dependency updates.
  • Assess infrastructure and provider supply-chain security.
  • Train staff and maintain cyber hygiene practices.
  • Validate legal and regulatory compliance with the operator's security and legal teams.

Deployment Notes

  • Use history.evidence.signing.publicKeyPath or BASYX_HISTORY_EVIDENCE_SIGNING_PUBLIC_KEY_PATH for manifest signature verification.
  • Run cmd/historyevidenceverifier from cron, Kubernetes CronJobs, or an equivalent scheduler. Treat non-zero exits and severity: error findings as alert conditions.
  • Use history.fullSnapshotInterval: 1 when each history row must be recoverable as a full WORM snapshot without diff replay.
  • With history.fullSnapshotInterval: N, recovery starts from the nearest WORM snapshot and replays WORM diff artifacts up to the requested row.
  • Recovery is bounded by the retention period and by the rows for which evidence storage was enabled.
  • The built-in recovery command exports verified JSON only. PostgreSQL restore should be performed through an operator-approved disaster-recovery procedure.

Avoid describing a deployment as "NIS2 compliant" based only on BaSyx configuration. The accurate statement is that BaSyx supplies technical controls that may support NIS2-aligned operation when combined with the required organisational and operational measures.