From 90aca07539df7c38c0c2ae7c8c3f876c8b159c75 Mon Sep 17 00:00:00 2001 From: ZDDC Date: Mon, 4 May 2026 21:33:16 -0500 Subject: [PATCH] docs: federal compliance page (federal.html) + home-page cross-links MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A non-technical entry point for federal evaluators answering "can this go in our environment, and what would need to be added during ATO?" — the question that today only has an answer buried in the engineering README. Six sections, written for the procurement / decision-maker audience with engineers as the secondary reader: 1. Hero: ZDDC is designed to be deployed in regulated environments. 2. What's already in place — hardened TLS posture, pluggable OPA policy engine, federal-mode strict-least-privilege Rego, audit logging, vulnerability-disclosure policy, documented access- control model with a 5-minute verify-it recipe. 3. Supported deployment shape — diagram showing zddc-server on loopback behind a TLS-terminating proxy on a RHEL/UBI base. 4. What you'd add for full ATO — table of five integration items (FIPS-validated crypto, authenticated proxy↔server channel, RBAC, policy export, code-signed tool fetches) with plain-language summaries. 5. The two-track build plan — explains why the standard binary stays pure-Go and a parallel zddc-server-fips build is the right answer for federal customers. 6. Engineering reference — links into the in-repo gap analysis, ARCHITECTURE.md security section, and access-control reference for implementors. Linked from index.html in two places: a new feature bullet on the zddc-server (optional) section pointing at the page, and a "For federal evaluators" entry in the Learn-more list at the bottom. No engineering content here — federal.html is the procurement entry point. The deeper detail (NIST control numbers, library choices, effort estimates) lives in zddc/README.md § Federal-readiness gap analysis where engineers will look for it. Co-Authored-By: Claude Opus 4.7 (1M context) --- federal.html | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++ index.html | 2 + 2 files changed, 165 insertions(+) create mode 100644 federal.html diff --git a/federal.html b/federal.html new file mode 100644 index 0000000..e078620 --- /dev/null +++ b/federal.html @@ -0,0 +1,163 @@ + + + + + + Federal Compliance — Zero Day Document Control (ZDDC) + + + + + + + + + + + + + +
+
+ + + ZDDC + + +
+
+ + +
+
+

Federal Compliance

+

ZDDC is designed to be deployed in regulated environments — including US federal. The system's trust boundaries, configuration model, and audit surface were chosen with ATO in mind. This page walks through what's already in place, what an integrator would add when a customer engages on accreditation, and the supported deployment shape.

+
+
+ +
+ + +
+

What's already in place

+

These controls ship in every release today. No federal-specific build required to use them.

+
    +
  • Hardened TLS posture. The TLS 1.2 cipher suite list, curve preferences, and HSTS header are pinned to the federal TLS guidance (NIST SP 800-52 Rev. 2). Only AEAD ciphers; only forward-secret key exchanges; only modern curves. Weak suites cannot be negotiated even if a client offers them.
    • +
  • Pluggable policy engine. Access decisions can be delegated to an external Open Policy Agent server with the customer's own audited Rego rules. The default in-process engine and the OPA-delegated engine speak the same wire format, so customers swap by setting one environment variable.
    • +
  • Strict-least-privilege policy variant available out of the box. A parity-tested federal-mode Rego that enforces NIST AC-6 (parent denies are absolute; no leaf-level override) ships embedded in the binary. zddc-server --print-rego=federal emits it for use with the customer's OPA.
    • +
  • Structured audit logging. Every request is logged with the authenticated email, method, path, status, response size, and duration. Logs are JSON-line, ready for fluentd / Vector / SIEM pipelines.
    • +
  • Documented vulnerability-disclosure process. A SECURITY.md covering supported versions, reporting channel, response timeline, embargo workflow, and CVE assignment.
    • +
  • Cascading access control with explicit trust boundaries. The .zddc ACL model has documented invariants — root-only admin escalation gate, subtree-author authority limited to their subtree, default-deny when any .zddc exists. The access-control reference includes a five-minute verify-it recipe a security reviewer can run on their own deployment.
    • +
+
+ + +
+

Supported deployment shape

+

Federal-track deployments run zddc-server on loopback only, fronted by a TLS-terminating proxy. The proxy handles authentication (PIV/CAC via the customer's IdP), terminates TLS using a FIPS-validated module, and forwards plaintext to zddc-server over the local interface. zddc-server stays small, lean, and focused on file-tree access decisions; the proxy is where federal-mandated cryptographic boundaries live.

+
+   PIV/CAC user
+        │
+        ▼
+   ┌──────────────────────┐         (FIPS-validated TLS termination,
+   │  oauth2-proxy /      │          OCSP stapling, MFA, session mgmt)
+   │  nginx-FIPS /        │
+   │  stunnel-FIPS        │
+   └──────────────────────┘
+        │  loopback (HTTP, mTLS or signed JWT)
+        ▼
+   ┌──────────────────────┐         (Per-directory ACL via .zddc;
+   │     zddc-server      │          OPA-delegated for AC-6 strict;
+   │  on 127.0.0.1:8080   │          structured access log to stdout)
+   └──────────────────────┘
+        │
+        ▼
+   /srv/zddc  (RHEL/UBI volume, encrypted at rest by the platform)
+

The base image for the federal track is RHEL UBI 9 or equivalent (Rocky 9, Ubuntu Pro 22.04+) with the OS-level FIPS mode enforced kernel-side. Encryption at rest is delegated to the deployment platform (cloud KMS, LUKS, dm-crypt). Audit logs ship from the proxy and zddc-server's stdout to the customer's SIEM via the orchestrator's normal log pipeline.

+

This isn't a new architecture — it's the standard "small focused service behind a hardened proxy" shape that DoD reference designs already prefer. zddc-server's job is to be the small focused service.

+
+ + +
+

What you'd add for full ATO

+

None of these are forever-open questions; each is a roadmap-able piece of work that an integrator builds when a customer engages on accreditation. Engineering detail for each item lives in the federal-readiness gap analysis.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
WhatPlain-language summary
FIPS-validated cryptographyA separate zddc-server-fips binary built with Microsoft's FIPS-aware Go toolchain on a RHEL/UBI base. The validated cryptography belongs to the OS-level OpenSSL FIPS module; this binary uses it. See the two-track build plan below.
Authenticated proxy↔server channelToday the proxy and zddc-server trust each other via network isolation. For federal, the recommended path is a signed forwarding token (JWT) — proxy signs each request with its private key, zddc-server verifies with the published public key. mTLS available as an alternative when the customer already operates a private CA.
Role-based access controlThe current .zddc model grants access by email pattern. Federal AC-3(7) wants role-based grants populated from the customer's identity provider. The cascade syntax extends to express role allow/deny alongside email allow/deny; roles flow through the same OPA hook so customers running their own Rego pick them up automatically.
Policy export for change controlA command that walks the served tree and emits every directory's resolved access policy in JSON / Markdown / CSV. The change-control workflow checks the export into a Git repo; every .zddc change produces a diff that reviewers approve before deploy. NIST CM-3.
Code-signed tool fetchesWhen a .zddc file pins a tool to a URL, zddc-server today fetches and caches it with no integrity check. The federal answer is code signing: the release pipeline signs every published artifact once with a long-lived key; zddc-server verifies signatures before caching. The operator trusts a published public key once and never deals with hashes — no per-artifact tracking burden.
+
+ + +
+

The two-track build plan

+

Federal evaluators sometimes ask a perfectly reasonable question: "Does the standard zddc-server binary use FIPS-validated cryptography?" The answer is no, and that's by design.

+

FIPS validation is a property of the cryptographic module — typically the OS-level OpenSSL FIPS package shipped by Red Hat or Canonical, certified by NIST and tracked by certificate number. Building with the Microsoft FIPS-aware Go toolchain is what lets a Go program use that validated module instead of Go's stdlib crypto. But it requires linking against the host's OpenSSL, which:

+
    +
  • Eliminates the "single static binary" property of the standard build (validated OpenSSL must be present at runtime)
    • +
  • Ties the deployment to a RHEL/UBI-class OS (validated OpenSSL packages exist there; not on macOS or Windows)
    • +
  • Gains nothing for the ~95% of customers who don't need a FIPS certificate to procure the system
    • +
+

So when a federal customer engages, an integrator builds a parallel zddc-server-fips binary using the FIPS toolchain and ships it alongside the standard one. linux-amd64 only, RHEL/UBI base, validated OpenSSL on the host. Federal customers download the FIPS variant; everyone else downloads the lean pure-Go binary. The application code is identical between tracks — only the toolchain and the host OS configuration differ.

+

This way every customer gets the deployment shape that fits their environment without paying for ones that don't.

+
+ + +
+

Engineering reference

+

For implementors picking up federal-track work, the in-repo references include effort estimates, design trade-offs, library choices, and pointers to the existing code that each piece would build on.

+
    +
  • Federal-readiness gap analysis — every NIST control we know is incomplete, with the planned remediation. Per-item subsections cover FIPS, authenticated proxy↔server, policy export, and code-signed app fetches with implementation depth.
    • +
  • ARCHITECTURE.md § Server security model — commercial-vs-federal trust models side-by-side. Cooperating layers (auth, policy decider, ACL cascade, tool-rooted view, audit log) and what each one's actual job is.
    • +
  • Access-control reference — cascade rules, anti-patterns, worked deployment layouts (third-party-vendor folders, paired open/closed projects), and a five-minute verify-it-works recipe. Useful for the security-review reading too.
    • +
  • codeberg.org/VARASYS/ZDDC — source code, issue tracker, contribution docs.
    • +
+
+ +
+ + + + + + diff --git a/index.html b/index.html index d9637ce..52d4a14 100644 --- a/index.html +++ b/index.html @@ -177,6 +177,7 @@