Security Posture

Post-Quantum Cryptography

QUORUM uses ML-DSA-65 (CRYSTALS-Dilithium, as standardized in NIST FIPS 204) for signing audit attestations and evidence packages. ML-DSA provides security against both classical and quantum adversaries using lattice-based cryptography.

All forensic evidence packages and audit ledger entries carry ML-DSA-65 signatures. This means evidentiary integrity is preserved even in a future where ECDSA or RSA signatures could be forged by a quantum-capable adversary.

Key properties

• Public key size: 1,952 bytes. Signature size: 3,309 bytes.
• Security level: NIST Level 3 (equivalent to AES-192 classical, quantum-resistant).
• Signing is performed in a WASM module (src/wasm-pq-crypto) compiled from the reference C implementation.
• Private keys are held exclusively in the Vault secret store and never written to disk.
• All TLS sessions use TLS 1.3 with ECDHE forward secrecy for transport; ML-DSA applies to at-rest attestations.

{
  "algorithm": "ML-DSA-65",
  "standard": "NIST FIPS 204",
  "signature": "4d3e1a7f...",
  "publicKeyId": "pqk_2026_03",
  "signedAt": "2026-05-18T14:32:07Z"
}

Merkle Audit Ledger

Every decision event, forensic case update, and SAR filing is appended to a cryptographic Merkle audit ledger. The ledger is append-only and provides mathematical proof that any individual record has not been altered or deleted — without requiring access to the full ledger.

Structure

Each audit record is SHA-256 hashed and inserted as a leaf in a binary Merkle tree. The tree root is recomputed on every append. Records include a hash chain back-pointer to the previous record's hash, providing dual redundancy: Merkle inclusion proofs for random-access verification, and a hash chain for sequential integrity.

POST /api/institutional/v1/audit-ledger/verify
{
  "leafHash": "sha256(record)",
  "proof": [
    { "position": "left",  "hash": "a1b2..." },
    { "position": "right", "hash": "c3d4..." }
  ],
  "expectedRoot": "e5f6..."
}
→ { "valid": true, "computedRoot": "e5f6..." }

Guarantees

• Record integrity: any modification to a stored record invalidates its inclusion proof.
• Ordering integrity: the hash chain back-pointer makes record reordering detectable.
• Auditor independence: inclusion proofs can be verified by a third party without access to the full ledger.
• The ledger root hash is published to each evidence package — a sealed forensic report carries a snapshot of the ledger state at the time of case creation.

Behavioral Biometrics & Continuous Identity Verification

QUORUM does not rely solely on point-in-time authentication. The Continuous Identity Verification (CIV) system re-scores every authenticated request against a live behavioral baseline using seven passive signal channels collected by the browser SDK.

Signal channels

Z-score analysis

Each signal is compared to the user's rolling baseline using Welford's online variance algorithm (incremental — no full dataset required). The behavioral score is the weighted sum of per-signal Z-scores. CIV is applied by the civGuard() middleware on every authenticated institutional API request.

The CIV system is specifically designed to catch session hijacking scenarios where an attacker obtains a valid token (via phishing, credential stuffing, or XSS) but then exhibits different behavioral characteristics than the legitimate user.

Zero Trust Administration

No standing administrative access exists to any QUORUM infrastructure component. All privileged operations require just-in-time (JIT) credential issuance with a maximum 4-hour TTL.

Access model

• Administrative credentials are issued by HashiCorp Vault on-demand and revoked automatically at TTL expiry.
• All internal service-to-service authentication uses mutual TLS (mTLS) with short-lived certificates. No shared secrets between services.
• Database and Redis connections accept only certificates issued by the internal CA — no password authentication is enabled on any data tier.
• SSH access to the production host requires hardware MFA (FIDO2) in addition to certificate authentication.
• Every administrative action is logged to the append-only audit ledger with the operator's identity and the ML-DSA-signed timestamp.

Atomic Handshake protocol

The Atomic Handshake is an additional layer of proof-of-presence for institutional API calls. It forces the caller to complete a cryptographic challenge/response cycle before each sensitive operation, binding the request to a single-use Redis state token with a 30-second TTL. Replayed or stolen requests are rejected because the state has already been consumed (collapsed).

This protocol was designed to frustrate automated replay attacks and SSRF-leveraged request forgery even if an attacker obtains a valid bearer token.

Container Hardening

The QUORUM API container is built from a minimal Alpine Linux base with explicit defense-in-depth controls applied at the Node.js runtime and OS levels.

Non-root execution

The container creates a dedicated quorum user (UID 1001, GID 1001) and drops all root privileges before the process starts. The container cannot be used to escalate to root even if the Node.js process is compromised.

Node.js Permission Model

The API process runs with Node.js's experimental permission model enabled, using explicit allowlists for filesystem and network access. Any operation outside the allowlist raises a ERR_ACCESS_DENIED exception rather than silently succeeding.

node
  --enable-source-maps
  --experimental-permission
  --allow-fs-read=/app,/tmp,/proc/self,/etc/ssl,/etc/resolv.conf,/etc/hosts
  --allow-fs-write=/tmp,/app/storage,/app/.healer
  --allow-worker-threads
  --allow-net
  dist/index.js

Filesystem write access is limited to three paths: /tmp (ephemeral), /app/storage (evidence packages), and /app/.healer (compliance auto-heal state). Any attempt to write outside these paths fails immediately — the attacker cannot modify the application code, configuration, or private key material at runtime.

Multi-stage build

The production image is built from a three-stage Dockerfile. The deps and builder stages compile the application; only the compiled dist/ directory and required runtime assets are copied to the final production image. Build tools, devDependencies, and source files are not present in the deployed container.

Health check

Docker's built-in health check probes /health every 15 seconds. A container that fails 3 consecutive health checks is automatically replaced by the orchestrator.

Supply Chain Security

QUORUM's CI/CD pipeline runs five security jobs on every push and pull request, and on a weekly automated schedule.

Automated pipeline controls

Dependabot configuration

Both npm and Docker dependencies receive weekly automated update PRs. Production and development dependencies are grouped separately. All updates require review from a designated maintainer before merge.

Runtime Monitoring (Falco)

QUORUM runs Falco in the production container host, monitoring kernel syscalls in real time. Falco rules are scoped specifically to the quorum-api container and fire on any behavior outside the expected process profile.

Active rules

CRITICAL-priority Falco alerts trigger PagerDuty pages. WARNING alerts are aggregated into the operational dashboard and reviewed during business hours. All Falco events are forwarded to the OpenTelemetry collector for correlation with application traces.

Network Segmentation

The QUORUM production environment uses layered network controls from the edge to the application process.

Edge (nginx)

• TLS 1.2 minimum, TLS 1.3 preferred. SSLv3, TLS 1.0, and TLS 1.1 are not negotiated.
• HSTS with a 1-year max-age and includeSubDomains.
• Content-Security-Policy restricts script sources to self and the Google Fonts CDN only.
• X-Frame-Options: DENY prevents clickjacking.
• Rate limiting at the nginx level: contact endpoint capped at 5 requests/minute per IP before the application layer is even reached.
• Static file extensions (.py, .sh, .sql, .env, .md) are denied at the edge.

Application layer

• JA3/JA4 TLS fingerprint analysis identifies known malicious client fingerprints and routes them to the deception sandbox.
• IP block list enforcement (Redis-backed) with sub-millisecond lookup.
• Request scanner detects probing patterns (path traversal, SQL injection probes, scanner user agents) and routes to an isolated honeypot rather than returning 403 — depriving attackers of useful feedback.
• Behavioral fingerprint enforcer cross-references request patterns against the fraud engine's known-bad signature library.
• The global rate limiter at /api is applied before tenant resolution, preventing enumeration attacks from consuming database resources.

Internal

• The API process may only connect outbound to explicitly allowed service ports (enforced by both Falco and the Node.js permission model).
• No direct internet access from the database or Redis tier — all external calls route through the API process.
• Kafka is used for internal event streaming; the broker is not exposed outside the container network.