FRD: FedRAMP-Compliant Platform Security
| Field | Value |
|---|---|
| ID | FRD-SEC-001 |
| Owner | David Holmes |
| Status | Draft |
| Last Updated | 2026-05-29 |
| Target Release | Platform v1 (security baseline from day one) |
| Type | Platform / cross-cutting capability |
| Complexity | XL |
| Target assurance | FedRAMP High + IAL3 / AAL3 / FAL3 (highest, dial-down per deployment) |
| Related Links | Security Overview, FedRAMP, NIST 800-63 (IAL/AAL/FAL), NIST 800-53, FRD-013 (Logging), FRD-014 (Audit Log Library), FRD: OSCAL Evidence Viewer |
Document Summary
This FRD defines an à-la-carte catalog of security control modules that, composed together, let the platform meet FedRAMP High (NIST 800-53 Rev 5) and the highest NIST 800-63-4 assurance levels (IAL3 / AAL3 / FAL3) from day one. Each module is independently deployable and maps to one or more NIST 800-53 control families, so a given deployment can select the subset its FIPS 199 categorization and Digital Identity Risk Management (DIRM) assessment require — Low, Moderate, or High — without re-architecting.
The design intent: build the hardest baseline once. Because FedRAMP High is a superset of SOC 2, ISO 27001, StateRAMP, and CMMC L2 controls, satisfying this FRD positions the platform to map down to any of those with evidence reuse rather than rework. See the Security framework decision guide.
Scope note: This FRD covers the technical controls the platform implements in software. FedRAMP authorization additionally requires an agency sponsor, a 3PAO assessment, and organizational/physical controls that are out of scope here (called out under Scope).
Introduction
Overview
Government and high-assurance commercial buyers gate procurement on security frameworks (FedRAMP, FISMA, StateRAMP, CMMC). Retrofitting these controls after a platform is built is expensive and slow. This FRD specifies the controls as discrete, composable modules so the platform is born compliant-capable and any control can be enabled, evidenced, and assessed on its own.
Goals
- Provide an à-la-carte module catalog mapped to NIST 800-53 Rev 5 families.
- Default each module to the highest assurance (FedRAMP High / IAL3 / AAL3 / FAL3), configurable down.
- Make evidence machine-readable (OSCAL) so authorization tracks the FedRAMP 20x direction.
- Prefer open-source, self-hostable, FIPS-validated building blocks (per procurement guidance).
Non-goals
- Obtaining an actual ATO (process/organizational, not software).
- Classified (IL6+) workloads.
Scope
In scope
- Technical control modules across the high-impact 800-53 families: IA, AC, AU, SC, CM, SI, RA, CP, IR, SR, SA, PT, CA.
- Identity assurance (IAL/AAL/FAL) implementation guidance.
- Machine-readable (OSCAL) SSP/evidence generation.
- Configurability of assurance level per deployment.
Out of scope
- Authorization mechanics: agency sponsorship, 3PAO/C3PAO engagement, SAR, ATO letter.
- Organizational/physical controls: PE (physical/environmental), most PS (personnel security) and AT (training) beyond what software enforces, facility security.
- Non-cloud (on-prem appliance) packaging.
- Procurement of commercial dependencies (covered in Tools and Software).
Users and Pain Points
| User | Pain Point |
|---|---|
| Platform engineer | No shared, pre-built control modules; reinvents auth, audit, crypto per app. |
| Compliance/security officer | Cannot produce an SSP or evidence without manual document archaeology. |
| CISO / Authorizing Official | Cannot tell which controls are met, partially met, or open. |
| Sales/GovCon lead | Loses deals because the platform can’t show a credible path to FedRAMP/StateRAMP/CMMC. |
| 3PAO assessor | Receives inconsistent, prose-only evidence that’s slow to assess. |
Definitions
| Term | Definition |
|---|---|
| FedRAMP High | The strictest common cloud baseline; ~410 NIST 800-53 Rev 5 controls. |
| FIPS 199 | Categorizes a system Low/Moderate/High by worst-case CIA impact. |
| IAL / AAL / FAL | Identity proofing / authentication strength / federation strength levels (800-63-4). |
| FIPS 140-3 | Validation standard for cryptographic modules (supersedes 140-2). |
| OSCAL | NIST machine-readable format for controls, SSPs, and assessment results. |
| POA&M | Plan of Action & Milestones — tracked remediation list. |
| ConMon | Continuous Monitoring — ongoing scanning, POA&M, reporting. |
| DIRM | Digital Identity Risk Management — 800-63-4’s risk-based level selection. |
| SBOM | Software Bill of Materials. |
Current State
The platform already has security-adjacent building blocks: a logging library (FRD-013), an audit log library (FRD-014), an authorization library, an API key manager, auth middleware + SSO, and an OSCAL evidence viewer. They are not yet composed into a coherent, level-selectable FedRAMP control set, and assurance levels (IAL/AAL/FAL) are not formalized. This FRD unifies them and fills the gaps.
Proposed Solution
A control-module catalog. Each module:
- Maps to one or more NIST 800-53 Rev 5 control families.
- Ships a highest-assurance default and a documented dial-down.
- Emits OSCAL implementation statements + runtime evidence for the evidence viewer.
- Prefers an OSS, FIPS-validated, self-hostable implementation.
Deployments compose modules to hit their target level. A profile (fedramp-low, fedramp-moderate, fedramp-high) selects the module set and configuration.
Requirements
Requirements are split into the à-la-carte Functional Requirements (the module catalog) and Non-Functional Requirements. Each functional module is independently shippable; IDs are stable for traceability into the OSCAL SSP.
Functional Requirements — the à-la-carte module catalog
Each row is a deployable module. Default = FedRAMP High / highest xAL. “Dial-down” notes the Moderate/Low relaxation.
Identity & Access (IA, AC)
| ID | Module | 800-53 | Highest-assurance behavior | Suggested OSS / standard | Dial-down |
|---|---|---|---|---|---|
| FR-IA-01 | Identity proofing (IAL3) | IA-12 | Supervised in-person or supervised-remote proofing; store evidence + decision | Integrate a proofing provider; record per 800-63A | IAL2 remote proofing; IAL1 self-asserted |
| FR-IA-02 | Authentication (AAL3) | IA-2, IA-2(1/2), IA-5 | Phishing-resistant, hardware crypto MFA only: FIDO2/WebAuthn keys, PIV/CAC. No SMS OTP. | Keycloak/Authentik + WebAuthn; PIV/CAC via PKCS#11 | AAL2 = MFA w/ phishing-resistant option offered |
| FR-IA-03 | Federation / SSO (FAL3) | IA-2, AC-14 | Holder-of-key assertions bound to an authenticator; OIDC/SAML | Authentik/Authelia/Keycloak as IdP | FAL2 encrypted assertion; FAL1 signed bearer |
| FR-IA-04 | Role/attribute access control | AC-2, AC-3, AC-6 | RBAC + ABAC; enforced least privilege; periodic access review | Authorization library | Fewer roles, manual review |
| FR-IA-05 | Separation of duties | AC-5 | Enforced incompatible-role checks; dual control for sensitive ops | Policy in authz library | Advisory only |
| FR-IA-06 | Session management | AC-11, AC-12 | Idle lock, absolute timeout, re-auth for step-up, concurrent-session limits | Better-Auth/Authelia session policy | Longer timeouts |
| FR-IA-07 | Privileged access mgmt + break-glass | AC-2(7), AC-6(5) | Just-in-time elevation, recorded break-glass, no standing admin | Vault/Authentik + audit | Standing admin w/ MFA |
Audit, Monitoring & Authorization evidence (AU, CA, SI)
| ID | Module | 800-53 | Highest-assurance behavior | Suggested OSS / standard | Dial-down |
|---|---|---|---|---|---|
| FR-AU-01 | Tamper-evident audit logging | AU-2, AU-3, AU-9 | Append-only, hash-chained/signed audit events; defined schema | Audit log library (FRD-014) | Standard immutable storage |
| FR-AU-02 | Log retention | AU-11 | ≥ 1 year online + 2 years offline (FedRAMP) | Loki + object storage lifecycle | Shorter retention |
| FR-AU-03 | Central aggregation + alerting (SIEM) | AU-6, SI-4 | Correlate, alert on security events, anomaly detection | Loki/Grafana + rules; Wazuh | Basic alerting |
| FR-CA-01 | OSCAL SSP + evidence automation | CA-2, CA-7 | Generate machine-readable SSP; collect runtime evidence | OSCAL evidence viewer | Manual SSP |
| FR-CA-02 | Continuous monitoring dashboard | CA-7 | Live control status, POA&M, scan results | Grafana + OSCAL feed | Periodic report |
Data protection & cryptography (SC, MP)
| ID | Module | 800-53 | Highest-assurance behavior | Suggested OSS / standard | Dial-down |
|---|---|---|---|---|---|
| FR-SC-01 | Encryption in transit | SC-8, SC-13 | TLS 1.2+ / 1.3, FIPS 140-3-validated modules, mTLS internally | Traefik/Linkerd, BoringCrypto/OpenSSL FIPS | TLS 1.2, edge-only |
| FR-SC-02 | Encryption at rest | SC-28, SC-13 | FIPS 140-3 module; per-tenant keys; full-disk + field-level for sensitive data | Postgres TDE/pgcrypto, LUKS | DB-level only |
| FR-SC-03 | Key & secret management | SC-12, SC-13, IA-5 | HSM/KMS-backed keys, rotation, no secrets in code | 1Password Connect / Vault + KMS | Managed KMS |
| FR-SC-04 | Data classification + DLP | MP-2, MP-4, SC-7 | Tag data by sensitivity; egress controls on classified data | Custom + policy | Tagging only |
Boundary, configuration & integrity (SC, CM, RA, SI)
| ID | Module | 800-53 | Highest-assurance behavior | Suggested OSS / standard | Dial-down |
|---|---|---|---|---|---|
| FR-SC-05 | Boundary protection / segmentation | SC-7 | WAF, default-deny network policy, microsegmentation, no flat network | Kyverno + NetworkPolicy, Traefik WAF | Edge firewall + segments |
| FR-CM-01 | Hardened baselines + drift detection | CM-2, CM-6 | CIS/DISA STIG baselines as code; detect & remediate drift | Kyverno, OpenSCAP, IaC | CIS Level 1 |
| FR-CM-02 | Change & configuration control | CM-3, CM-4 | All changes via GitOps + review; immutable infra | ArgoCD, signed commits | PR review |
| FR-RA-01 | Vulnerability scanning | RA-5 | Monthly OS/web/DB + container + IaC scanning | Trivy, OpenSCAP, ZAP | Quarterly |
| FR-SI-01 | Flaw remediation SLAs | SI-2 | High 30d / Moderate 90d / Low 180d remediation; tracked in POA&M | POA&M automation | Best-effort |
| FR-SI-02 | Integrity monitoring / malware | SI-3, SI-7 | FIM, image signing + admission control, runtime detection | Falco, cosign + Kyverno | Image scanning |
Resilience & response (CP, IR)
| ID | Module | 800-53 | Highest-assurance behavior | Suggested OSS / standard | Dial-down |
|---|---|---|---|---|---|
| FR-CP-01 | Backup & disaster recovery | CP-9, CP-10 | Encrypted, tested backups; documented RTO/RPO; cross-region | Velero, pgBackRest | Single-region backups |
| FR-IR-01 | Incident response | IR-4, IR-6 | IR plan, US-CERT/CISA reporting within required window, runbooks | GlitchTip + runbooks | Internal IR only |
Supply chain, SDLC & privacy (SR, SA, SI, PT)
| ID | Module | 800-53 | Highest-assurance behavior | Suggested OSS / standard | Dial-down |
|---|---|---|---|---|---|
| FR-SR-01 | Supply chain / SBOM | SR-3, SR-4 | Generate + verify SBOM per build; provenance attestation | Syft + cosign/SLSA | SBOM only |
| FR-SA-01 | Secure SDLC scanning | SA-11, SI-2 | SAST + DAST + secret scanning + dependency review in CI, gating | CodeQL/Semgrep, gitleaks, Dependabot | SAST + secret scan |
| FR-PT-01 | Privacy / PII controls | PT-2, PT-3 | Data inventory, consent, minimization, subject-access support | Consent module (FRD), data map | Inventory + notice |
US-person & residency (High/IL5): sensitive deployments require US-only data residency and US-person operators — a deployment/hosting control (e.g., GovCloud boundary), noted here for completeness though it’s infra, not app code.
Non-Functional Requirements
| ID | Requirement |
|---|---|
| NFR-01 | Every module emits OSCAL implementation statements; control status is queryable as data. |
| NFR-02 | Assurance level is configuration, not a fork: fedramp-{low,moderate,high} profiles select module sets. |
| NFR-03 | All cryptography uses FIPS 140-3-validated modules in approved mode. |
| NFR-04 | Controls fail closed (deny on policy-engine or authz failure). |
| NFR-05 | Enabling/disabling a module must not require changes to unrelated modules (independence). |
| NFR-06 | Performance: control overhead (authz, audit write) budgeted and measured; no unbounded latency. |
| NFR-07 | All control changes are themselves audited (meta-audit). |
API / Interface Requirements
- A policy/profile API to query the active profile and per-control status (drives FR-CA-02).
- Each module exposes a health + evidence endpoint consumable by the OSCAL evidence viewer.
- Identity modules conform to OIDC / SAML 2.0 / WebAuthn / PKCS#11 standard interfaces (no proprietary auth protocol).
Design Requirements
N/A for most modules (backend/platform). The continuous-monitoring dashboard (FR-CA-02) and evidence viewer have UI — they must use @dmwd-io/design-system primitives and follow the standard nine UI states. Defer UI specifics to the OSCAL evidence viewer FRD.
Accessibility Requirements
Any control UI (dashboards, consent, login/step-up) must meet WCAG 2.2 AA and be keyboard- and screen-reader-operable — high-assurance login flows (WebAuthn, step-up) are a common a11y failure point and must be tested.
Content & Documentation Requirements
- Each module ships a control-mapping doc (which 800-53 controls, how met) feeding the SSP.
- The Security docs area is the human-readable companion to this FRD.
Storybook Requirements
Only UI-bearing modules (dashboard, consent, login/step-up) need stories — all nine states, axe-clean, per the design-system rules. Backend modules are out of scope for Storybook.
Testing Requirements
| ID | Requirement |
|---|---|
| TEST-01 | Each module has unit + integration tests proving the control behavior (e.g., AAL3 rejects non-phishing-resistant authenticators). |
| TEST-02 | Negative tests: controls fail closed (authz denial, expired session, untrusted assertion). |
| TEST-03 | Crypto tests assert FIPS-approved algorithms/modes only. |
| TEST-04 | CI runs the SAST/DAST/secret/dependency scans from FR-SA-01 and gates on findings per FR-SI-01 SLAs. |
| TEST-05 | OSCAL output validates against NIST OSCAL schemas. |
| TEST-06 | Profile tests: fedramp-high enables the full High module set; dial-down profiles disable the documented deltas only. |
Dependencies
- FRD-013 (Logging), FRD-014 (Audit Log Library), Authorization library, API key manager, Auth middleware + SSO, OSCAL evidence viewer.
- FIPS 140-3-validated crypto provider; KMS/HSM; identity-proofing provider (commercial — IAL3).
- Procurement of any closed dependencies per Tools and Software.
Risks and Tradeoffs
| Risk | Mitigation |
|---|---|
| FedRAMP 20x is moving (rules finalize ~mid-2026). | Build OSCAL-native now; treat process specifics as configurable; track fedramp.gov/20x. |
| FIPS 140-3 validation constrains crypto library choice and can lag. | Use validated providers (BoringCrypto, OpenSSL FIPS); isolate crypto behind an interface. |
| IAL3 needs a proofing vendor (no pure-OSS path). | Treat as a pluggable, à-la-carte module; most deployments use IAL2. |
| Over-building for buyers who only need SOC 2/ISO. | Profiles let you ship Low/Moderate; High is opt-in. Controls map down for SOC 2/ISO evidence reuse. |
| Highest xAL hurts usability (hardware keys, step-up). | DIRM-based per-deployment dial-down; offer multiple phishing-resistant authenticators. |
Open Questions
- Which identity-proofing vendor for IAL3, and is IAL2 the practical default?
- Do we run a dedicated GovCloud boundary for High/IL5, or stay single-boundary at Moderate?
- Is StateRAMP/GovRAMP an early target (reuses this work) or later?
- Which FIPS 140-3 crypto provider becomes the platform standard?
Acceptance Criteria
- Module catalog (Functional Requirements) implemented as independently deployable units, each with OSCAL output.
-
fedramp-highprofile enables IAL3/AAL3/FAL3 and the full High control set; verified by tests (TEST-06). - All crypto FIPS 140-3-validated (NFR-03), proven by tests (TEST-03).
- Controls fail closed (TEST-02).
- OSCAL SSP generates and validates (FR-CA-01, TEST-05); status visible in dashboard (FR-CA-02).
- Vulnerability scanning + remediation SLAs operational (FR-RA-01, FR-SI-01).
- Each module’s control mapping documented for the SSP.
Implementation Notes
- Sequence: start with the modules already partially built (audit, authz, SSO, OSCAL viewer), then crypto (SC), then boundary/CM, then scanning/SI, then resilience/IR, then supply chain/SDLC.
- Express profiles and policies as code (GitOps) so the active control set is itself versioned evidence.
- Reuse, don’t reinvent — most modules wrap an OSS tool from the procurement stack; the platform value is the composition + OSCAL evidence, not bespoke crypto.
LLM Handoff Instructions
When implementing a module: (1) read the mapped 800-53 control text and the relevant security doc; (2) implement the highest-assurance default with a config flag for dial-down; (3) emit OSCAL implementation statements + a runtime evidence endpoint; (4) write negative/fail-closed tests; (5) never hand-roll cryptography — use a FIPS-validated provider; (6) record a Decision Record for any deviation. Do not claim FedRAMP “compliance” in code/docs — say “maps to control X-NN.”
Rollout Plan
- Baseline (Moderate): ship the Moderate profile module set — covers most gov SaaS.
- High delta: add IAL3/AAL3/FAL3, stricter SC/SC-7, cross-region DR.
- Evidence: OSCAL SSP + ConMon dashboard.
- Authorization support: package for a 3PAO/agency sponsor (process, out of code scope).
Migration and Backward Compatibility
Existing apps adopt modules incrementally; default profile for legacy deployments is Moderate with a documented gap list to High. No module may break apps that haven’t opted into it (NFR-05).
Decision Log
| Date | Decision | Rationale |
|---|---|---|
| 2026-05-29 | Build to FedRAMP High as the master baseline | Superset of SOC 2/ISO/StateRAMP/CMMC L2; map down with evidence reuse. |
| 2026-05-29 | À-la-carte modules keyed to 800-53 families, level by profile | Lets one codebase serve Low→High without forks. |
| 2026-05-29 | Default to IAL3/AAL3/FAL3, dial down via DIRM | 800-63-4 decouples the levels; support the max, let deployments relax. |
| 2026-05-29 | OSCAL-native evidence from day one | Aligns with FedRAMP 20x; automates the SSP. |
| 2026-05-29 | FRD only — not an ATO | Authorization needs an agency sponsor + 3PAO, out of software scope. |
Document History
| Date | Version | Change |
|---|---|---|
| 2026-05-29 | 0.1 (Draft) | Initial à-la-carte FedRAMP-High control-module catalog. |
Disclaimer. Not legal/compliance advice. Control counts, remediation SLAs, and FedRAMP 20x details are dated and cited in the Security docs; verify against fedramp.gov, NIST 800-53 Rev 5, and NIST 800-63-4 before relying on any figure. Mapping to a control is not the same as an authorization.