Plan: ATO Pathway & Continuous Compliance Framework

On this page

Status

Step Description Status

1

Plan file and nav entry

Done (2026-03-21) — MR !49

2

NIST-to-architecture mapping document

Done (2026-03-21) — MR !49

3

FedRAMP Moderate baseline alignment checklist

Done (2026-03-21) — MR !49

4

StateRAMP variant for state agency deployments

Done (2026-03-21) — MR !49

5

Pre-assessment readiness checklist

Done (2026-03-21) — MR !49

6

Continuous compliance monitoring (link alerts to controls)

Done (2026-03-21) — MR !49

7

Documentation, commit, push, MR

Done (2026-03-21) — MR !49

Issues: TBD
Branch: feature/ato-pathway

Context

CRAIG tracks NIST SP 800-53 controls as database records in the nist_controls table (20+ controls seeded across key families: AC, AU, CM, IA, SC). However, these controls are not mapped to actual architectural decisions — they’re just status records.

For a CCWIS to process Title IV-E data in production, it needs an Authority to Operate (ATO) from the state’s CISO or equivalent authority. The ATO process requires demonstrating that security controls are implemented, tested, and continuously monitored. Currently:

  • No FedRAMP or StateRAMP alignment documented

  • No mapping between NIST controls and CRAIG’s architecture

  • No pre-assessment checklist

  • "ATO" appears zero times in the codebase

  • External reviewers have flagged this as a credibility gap

This is primarily a documentation deliverable with one small code enhancement (linking alerts to NIST controls).

Scope

In scope:

  • NIST-to-architecture mapping document (how each control is implemented in CRAIG)

  • FedRAMP Moderate baseline alignment (which controls are met, partially met, or not applicable)

  • StateRAMP variant with state-specific guidance

  • Pre-assessment readiness checklist for deploying agencies

  • Link breach detection alerts to NIST control assessments

Out of scope:

  • Completing an actual ATO process (requires a specific deploying agency)

  • FedRAMP authorization (federal process, requires agency sponsorship)

  • Third-party security assessment (operational activity)

  • SSP (System Security Plan) template — too agency-specific

Design

Step 2: NIST-to-Architecture Mapping

File: docs/modules/ROOT/pages/nist-architecture-mapping.adoc — new page

Maps each NIST control family to CRAIG’s implementation:

Control Requirement CRAIG Implementation

AC-2 Account Management

Manage system accounts, enforce access policies

Keycloak OIDC with 6 roles (admin, supervisor, caseworker, eligibility_worker, icpc_coordinator, readonly). Account lifecycle managed in Keycloak admin console. JWT claims enforce RBAC per endpoint.

AC-3 Access Enforcement

Enforce approved authorizations

Extension<Claims> middleware on all protected routes. require_caseworker_or_above(), require_supervisor_or_above(), require_admin() checks per handler. Role hierarchy enforced.

AC-6 Least Privilege

Employ principle of least privilege

6 granular roles. Caseworkers cannot access admin functions. Readonly role for auditors. Public intake has no auth (appropriate for anonymous reporting).

AU-2 Event Logging

Define auditable events, produce records

Wildcard RabbitMQ subscriber captures all 23+ event types. audit_log table records timestamp, user, service, action, resource, success/failure. Comprehensive coverage.

AU-6 Audit Review

Review and analyze audit records

GET /v1/security/audit with pagination, filtering, search. Biennial security review workflow. (Enhanced by breach detection plan.)

CM-2 Baseline Configuration

Establish and maintain baseline configs

Docker images built from rust:1.94-alpine. Cargo.lock pins all dependencies. Infrastructure-as-code via docker-compose. Configuration via environment variables with documented defaults.

CM-6 Configuration Settings

Establish mandatory configuration settings

CRAIG_<SERVICE>__* environment variables. configuration-reference.adoc documents all settings. Session cookies: HttpOnly, SameSite=Lax, Secure (configurable).

IA-2 Identification & Authentication

Uniquely identify and authenticate users

Keycloak OIDC with PKCE (Authorization Code flow). JWT with RS256 signing. JWKS validation with key rotation support. Token expiry enforced.

IA-5 Authenticator Management

Manage authenticator credentials

Keycloak handles password policies, credential storage (bcrypt). No passwords stored in CRAIG. API keys for partner integration use SHA-256 hashing.

SC-7 Boundary Protection

Monitor and control communications at boundaries

CORS with explicit method list (GET, POST, PUT, DELETE, OPTIONS). Configurable origin allowlist. Rate limiting on public endpoints. CAPTCHA on intake forms. No direct database access from web UI (BFF pattern).

SC-8 Transmission Confidentiality

Protect confidentiality of transmitted information

HTTPS enforced via Keycloak redirect URIs. Session cookies with Secure flag. JWT bearer tokens over TLS. S3-compatible object storage (Garage) for documents.

SC-13 Cryptographic Protection

Employ cryptographic mechanisms

JWT RS256 (Keycloak). ECDSA P-256 for JWS report signing. SHA-256 for API key hashing. TLS for all inter-service communication.

SI-10 Information Input Validation

Check validity of inputs

SQLx compile-time query validation (prevents SQL injection). ammonia HTML sanitization on public intake. CHECK constraints on all enum columns. Reference data validation via craig-reference crate.

Full mapping covers all 20+ seeded NIST controls.

Step 3: FedRAMP Moderate Baseline Alignment

File: docs/modules/ROOT/pages/fedramp-alignment.adoc — new page

FedRAMP Moderate requires ~325 controls. Organize as:

  • Fully Implemented (~40%): Controls addressed by CRAIG’s architecture

  • Partially Implemented (~30%): Controls that need deployment-specific configuration

  • Inherited (~20%): Controls provided by hosting infrastructure (cloud provider, network)

  • Not Applicable (~10%): Controls that don’t apply to CCWIS (e.g., physical access)

Step 4: StateRAMP Variant

File: docs/modules/ROOT/pages/stateramp-alignment.adoc — new page

StateRAMP uses a subset of FedRAMP controls. Document state-specific considerations:

  • State CISO approval process

  • State data residency requirements

  • State-specific encryption standards

  • Integration with state identity providers (replace Keycloak with state IdP)

Step 5: Pre-Assessment Readiness Checklist

File: docs/modules/ROOT/pages/ato-readiness.adoc — new page

Actionable checklist for deploying agencies:

  • Deploy CRAIG services with TLS termination

  • Configure Keycloak with agency’s identity provider

  • Set CRAIG_WEB__SESSION_SECURE=true in production

  • Configure CORS origins (not wildcard) for production

  • Enable container scanning in CI/CD pipeline

  • Commission penetration test

  • Complete NIST control assessment (use /v1/security/nist to track)

  • Establish data sharing agreements with exchange partners

  • Configure backup and disaster recovery

  • Document incident response procedures

  • Conduct biennial security review (use /v1/security/reviews)

  • Submit System Security Plan to authorizing official

Step 6: Link Alerts to NIST Controls

Small code enhancement: when a security alert is created (from breach detection plan), cross-reference it with relevant NIST controls.

Add nist_control_ids JSONB field to security_alerts table, populated with the control IDs relevant to the alert type:

  • failed_auth alerts → AU-2 (Event Logging), AC-7 (Unsuccessful Logon Attempts)

  • privilege_escalation alerts → AC-6 (Least Privilege), AC-3 (Access Enforcement)

  • bulk_data_export alerts → AC-4 (Information Flow), AU-6 (Audit Review)

This creates a direct link between detected anomalies and compliance controls.

Files Touched

File Change

docs/modules/ROOT/pages/nist-architecture-mapping.adoc

New: control-to-code mapping

docs/modules/ROOT/pages/fedramp-alignment.adoc

New: FedRAMP Moderate checklist

docs/modules/ROOT/pages/stateramp-alignment.adoc

New: StateRAMP variant

docs/modules/ROOT/pages/ato-readiness.adoc

New: pre-assessment checklist

docs/modules/ROOT/nav.adoc

Add pages under Operations section

docs/modules/ROOT/pages/index.adoc

Update alpha warning to mention ATO pathway docs

Verification

  1. All new .adoc pages build in Antora without errors

  2. Cross-references between pages resolve correctly

  3. NIST mapping covers all seeded controls

  4. FedRAMP alignment covers key control families

  5. Readiness checklist is actionable for a deploying agency

Documentation Updates

  • docs/modules/ROOT/nav.adoc — add 4 new pages under Operations

  • CHANGELOG.adoc — entry under Unreleased

  • docs/modules/ROOT/pages/roadmap.adoc — add ATO pathway item and tick it

  • docs/modules/ROOT/pages/index.adoc — update alpha warning to reference ATO docs

Edit this page · latest