Skip to main content

CC3.2 — Fraud risk assessment

Status: Partially implemented (technical fraud surfaces catalogued; insider-fraud playbook target week 22) Owner: Agent #38 (Senior Compliance Lead, SOC 2 + ISO 27001) Last reviewed: 2026-05-28 Next review: 2026-08-28

Trust Services Criteria reference​

The entity considers the potential for fraud in assessing risks to the achievement of objectives. The control covers the identification of fraud scenarios (external + internal + collusive), the assessment of the entity's susceptibility, the analysis of factors that may indicate an increased likelihood of fraud, and the linkage to compensating controls.

How ZeroAuth meets this control​

Fraud scenarios are catalogued in the threat model and in the BFSI pain-points document. docs/plan/bfsi-v1/01-pain-points.md enumerates P-4 ("insider abuse — a bank operator with DB access could fabricate or destroy audit records") and P-7 ("bank cannot evidence the audit log to its own regulator") as the two highest-impact internal-fraud surfaces ZeroAuth's product is designed to neutralise.

The threat-model rows that cover external fraud:

  • A-01 cross-tenant data read — an authenticated tenant attempts to read another tenant's data (docs/threat_model.md row A-01). Mitigation: every SQL path takes (tenant_id, environment) and embeds them in the WHERE; the source-level guard tests/tenant-isolation.test.ts (commit a1bbc47) asserts every router.<verb> declaration on /v1/* carries the authenticateTenantApiKey middleware. 14 intentionally-public exceptions live in PUBLIC_ROUTE_EXCEPTIONS with ≥ 20-character justifications.
  • A-02 replayed proof verification — an attacker replays a captured proof within the 5-minute window (row A-02). Mitigation: timestamp window + nonce format check in src/services/zkp.ts; within-window replay test is the named gap.
  • A-05 credential stuffing + email enumeration on console — per-IP rate limiter on signup + login (row A-05). Closure of the rate-limit gap is tracked as audit-finding C-10.
  • A-15 raw biometric on the wire — payload smuggling raw biometric bytes (row A-15). Closure: source-grep tests/biometric-rejection.test.ts (commit c09c081) plus runtime defence at the validator layer once ADR 0016 is fully rolled out (commit 76f8d4e for the ADR; install lands C-022 sprint 2).
  • A-27 demo-bypass via did:zeroauth:demo:* — the bypass branch in submitProof accepted any did:zeroauth:demo:* without crypto verification. Closed in commit 02e1734 (P0 audit finding C-1). Threat-model row A-27 captures the residual risk.

The internal-fraud catalogue is centred on the audit chain. Pain point P-4 demands that an insider with DB access cannot rewrite an audit row undetected. ADR 0013 (commit 27ed93c) introduces the per-tenant SHA-256 hash chain over audit_events; the chain is implemented in commit a475ed8 and the integrity-verification endpoint at commit d634b2d. Every audit write must go through appendAuditEvent in src/services/audit.ts; direct INSERT INTO audit_events is detected by tests/audit-chain.test.ts (commit c09c081).

ADR 0014 (commit 27ed93c) layers the on-chain anchor — each tenant's chain terminal hash is anchored daily on Base L2 via the AuditAnchor contract (commit d6c6a4e). The anchor lets the bank's own auditor verify "this chain existed at this point in time and has not been re-written since" without trusting any ZeroAuth process — the strongest available technical defence against internal fraud.

Internal-fraud collusion (a DBA + an SRE both compromised) is named in ADR 0013 as "what the chain does NOT defend against" — mitigated by the on-chain anchor (ADR 0014) and the external cryptographer review of src/services/audit.ts engaged Phase 0 week 4. The HSM-backed signer migration (week 48, per compliance roadmap D-Q4-06) further reduces single-point-of-collusion risk.

The structured fraud-scenario walkthrough across product-, technical-, and operational surfaces is the gap. The first formal "fraud risk assessment" working session is on the compliance roadmap week 22 calendar (2026-10-12), with output docs/compliance/fraud-risk-assessment-v1.md.

Evidence references​

  • docs/threat_model.md — rows A-01, A-02, A-05, A-15, A-27, A-28 cover the named fraud surfaces.
  • docs/plan/bfsi-v1/01-pain-points.md — P-4 (insider abuse) + P-7 (audit-log evidence) as anchor pain-points.
  • ADR 0013-audit-log-hash-chain.md (commit 27ed93c) — hash chain for in-DB tampering defence.
  • ADR 0014-on-chain-anchor-cadence.md (commit 27ed93c) — daily on-chain anchor for external verifiability.
  • Commit a475ed8 — audit hash chain implementation.
  • Commit d634b2d — /api/admin/audit-integrity endpoint.
  • Commit c09c081 — appendAuditEvent enforcement test.
  • Commit 02e1734 — closure of demo-bypass C-1.
  • Commit a1bbc47 — cross-tenant source-level guard.
  • Commit d6c6a4e — AuditAnchor.sol contract.

Open gaps + remediation roadmap​

  • Formal fraud-risk-assessment session + writeup — target week 22 (2026-10-12), Agent #38 lead + Agent #26 + Agent #36.
  • Insider-fraud playbook — what does the operator do when the drift-detector alerts? Target week 14 (2026-08-24).
  • Cross-tenant data-read alert — audit_events.action = 'cross_tenant_query_blocked' row is noted in docs/threat_model.md row A-01 as an audit-signal gap. Target Phase 1 sprint 2.
  • Replay-within-window test for A-02 — named gap in docs/threat_model.md. Target Phase 1 sprint 2 alongside the per-verifier nonce table.

Test or audit query​

Auditor reads docs/threat_model.md rows A-01, A-02, A-15, A-27 to confirm the fraud surfaces are catalogued. Then git log --oneline -- src/services/audit.ts contracts/AuditAnchor.sol should return commits a475ed8, d634b2d, d6c6a4e — proves the defence is in place.