commit 8712e932580a09979475b437878344dfc9264718 Author: Chris Tonjes Date: Wed Sep 30 12:14:24 2026 -0400 Initial YPMS planning and ATO artifacts Pre-development state; no code yet. Delivery model: in-house build by DOES OIT on Azure Government, matching the DCYWP / OWC / Employer 360 pattern. Stack decision (2026-09-30): Python 3.12 / FastAPI / SQLAlchemy / Postgres, aligning with OWC. System Owner / ISSO / AO: Chris Tonjes (DOES CIO). Role concentration recorded in SSP §5 with risk-acceptance rationale. Source functional and security requirements derived from the prior YPMS RFP (Solicitation Docxxxxx, April 2025) — 54 C.5.7 security requirements and Appendix E non-functional requirements — treated as source specifications, not as Contractor obligations. Documents included: - CLAUDE.md, OVERVIEW.md — project router and program-level summary - SYSTEM_SECURITY_PLAN.md v0.3 — NIST 800-53 Moderate baseline SSP - NIST_800_53_CONTROL_MAPPING.md v0.2 — full control-family mapping with in-house ownership tags and evidence-artifact expectations - POAM.md v0.1 — 62-item POA&M seeded from tailorings, open decisions, missing companion docs, and pre-ATO deliverables; two items closed - PRIVACY_IMPACT_ASSESSMENT.md v0.1 — full PIA covering minors, SSN, banking, FERPA-covered OSSE records, CFSA foster/ward flags, and the dormant emergency health-record path - ARCHITECTURE.md v0.1 — forward-looking design blueprint, OWC-aligned - PHASE0_PLAN.md v0.1 — framework vendor-in, auth, RBAC, audit, Registrant vertical slice, 501 stubs for remaining entities - TODO.md — 12-section working checklist tied to POA&M IDs - OLA_RESPONSE_2026-09-30.md — Q&A for OLA / City Administrator Co-Authored-By: Claude Opus 4.7 (1M context) diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..1305fed --- /dev/null +++ b/.gitignore @@ -0,0 +1,62 @@ +# Python +__pycache__/ +*.py[cod] +*.egg-info/ +.venv/ +venv/ +.pytest_cache/ +.mypy_cache/ +.ruff_cache/ +.pyre/ +.pytype/ + +# Test / coverage +.coverage +.coverage.* +htmlcov/ +coverage.xml +.tox/ + +# Build +dist/ +build/ +*.whl + +# Environment / secrets +.env +.env.* +!.env.example + +# Local DB +*.db +*.sqlite +*.sqlite3 +pg_data/ + +# Docker +.docker/ + +# OS +.DS_Store +Thumbs.db + +# Editors / IDEs +.vscode/ +.idea/ +*.swp +*.swo +*~ + +# Node (if we end up with a client/ later) +node_modules/ +npm-debug.log* +yarn-debug.log* +yarn-error.log* +.pnpm-debug.log* + +# Logs +*.log +logs/ + +# Alembic scratch (real migrations are checked in under migrations/versions/) +alembic/ diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md new file mode 100644 index 0000000..4cf4daf --- /dev/null +++ b/ARCHITECTURE.md @@ -0,0 +1,662 @@ +# Architecture — YPMS Phase 0 + +**Document version:** 0.1 (Draft) +**Date:** 2026-09-30 +**Author:** Chris Tonjes, DOES CIO +**Companion to:** [`CLAUDE.md`](CLAUDE.md), [`OVERVIEW.md`](OVERVIEW.md), [`SYSTEM_SECURITY_PLAN.md`](SYSTEM_SECURITY_PLAN.md), [`NIST_800_53_CONTROL_MAPPING.md`](NIST_800_53_CONTROL_MAPPING.md), [`POAM.md`](POAM.md), [`PRIVACY_IMPACT_ASSESSMENT.md`](PRIVACY_IMPACT_ASSESSMENT.md) + +This document lays out the architecture YPMS will be built to. It follows the OWC pattern — same stack, same framework instincts, same delivery discipline — with YPMS-specific adjustments for the youth-workforce domain, the four-population identity model, and the integration-heavy data flows. + +--- + +## 1. Purpose and scope + +YPMS replaces seven legacy tools that today run DOES Office of Youth Programs (MBSYEP, HSIP, MBYLI, CRESP, and future OYP programs). See [`OVERVIEW.md`](OVERVIEW.md) for the program-level summary and the legacy-tool inventory. + +Phase 0 delivers the **framework and scaffolding**: identity, RBAC, audit, generic CRUD, and empty entity stubs. Domain logic (eligibility engine, matching, timekeeping, payroll, integrations) lands in phases 1–N. + +Explicit non-goals for this architecture document: + +- Not a rehash of the source RFP. That's captured in the SSP Appendix C traceability. This doc talks about the target-state system. +- Not a UI style guide. Screen designs are a separate phase-1 artifact. +- Not an operational runbook. That belongs in `CONTINGENCY_PLAN.md` and `INCIDENT_RESPONSE_PLAN.md` once authored. + +--- + +## 2. Guiding principles + +1. **Align with OWC where alignment is free.** Same stack, same framework instincts, same test discipline. Two systems sharing patterns is two systems that stay maintainable. Where YPMS's problem shape genuinely differs, we diverge with a written reason. + +2. **Source-RFP traceability is load-bearing.** Every substantive feature traces to a source-RFP requirement (`C.5.x.y`) or a NIST control. Auditors trace forward from RFP → code; developers trace backward from code → why. The `NIST_800_53_CONTROL_MAPPING.md` Appendix C is the durable index. + +3. **Minors first.** ~27,000 registrants are minors, some under 18. Every design choice — auth, consent, retention, display — starts from that constraint. Parental co-consent, IAL2 proofing before payroll, SSN masking, foster-status role scoping are all consequences. + +4. **Data-driven over code-driven** where the requirement is a policy that will change. Eligibility rules (source RFP Appendix D), permissions matrix, program definitions, retention policy, notice text — these all live in seed data or the DB, not in Python conditionals. Rule changes are DB / seed updates, not deploys. + +5. **Integrations are boundaries.** SSA, OSSE, CFSA, DC MAR, payroll vendor, LMS all sit outside the trust boundary. Every integration is a service in its own module with its own retries, its own audit, and its own kill switch. When (not if) a partner has an outage, YPMS should degrade sensibly, not crash. + +6. **Every state-mutating action emits an audit row.** Same rule as OWC. Enforced in the CRUD service and route factory so you can't accidentally write a handler that bypasses it. PII-touching reads are audited too (source RFP `C.5.6.9` #5). + +7. **Phased delivery, phase plans authoritative.** OWC's `PHASE{N}_PLAN.md` pattern is proven — small phases, explicit in/out scope, current phase plan wins over older ones on conflict. Same pattern here. + +--- + +## 3. System context + +``` + ┌─────────────────────────────────────────┐ + │ External identity providers │ + │ ┌──────────┐ ┌──────────────────┐ │ + │ │ Entra ID │ │ Social-media │ │ + │ │ (staff) │ │ IdPs (youth)* │ │ + │ └──────────┘ └──────────────────┘ │ + └────────────────┬────────────────────────┘ + │ OIDC / OAuth + ▼ + ┌───────────────┐ ┌─────────────────────┐ ┌───────────────┐ + │ Youth / │ HTTPS │ │ HTTPS │ DOES staff │ + │ Parent portal ├─────────►│ YPMS App │◄─────────┤ portal │ + │ (mobile-first)│ │ (FastAPI / Jinja / │ │ (internal) │ + └───────────────┘ │ HTMX) │ └───────────────┘ + │ │ + ┌───────────────┐ HTTPS │ ┌───────────────┐ │ + │ Host / ├─────────►│ │ Postgres │ │ + │ Employer │ │ │ (Azure Gov, │ │ + │ portal │ │ │ private ep) │ │ + └───────────────┘ │ └───────────────┘ │ + │ │ + │ Integration │ + │ adapters (below) │ + │ │ + └──┬──┬──┬──┬──┬──┬──┘ + │ │ │ │ │ │ + ┌──────────────────────────┘ │ │ │ │ └────────────────────────────┐ + │ ┌────────────────────┘ │ │ └──────────────┐ │ + ▼ ▼ ▼ ▼ ▼ ▼ + ┌─────┐ ┌────────┐ ┌───────┐ ┌────────┐ ┌────────┐ ┌────────────┐ + │ SSA │ │ OSSE │ │ CFSA │ │DC MAR │ │ LMS │ │ Payroll │ + │(API)│ │(CSV) │ │(CSV) │ │(API) │ │(API) │ │ vendor │ + └─────┘ └────────┘ └───────┘ └────────┘ └────────┘ │ (API) │ + └────────────┘ + + ┌───────────────────────────────────────┐ + │ DOES OIT infrastructure telemetry │ + │ ┌─────────────────────┐ │ + │ │ Sentinel / OCTO │ │ + │ │ SOC │◄────────┼──── log stream + │ └─────────────────────┘ │ + └───────────────────────────────────────┘ + + * Social-media login for youth is limited to browsing / pre-application. + IAL2-equivalent proofing (Login.gov or SSA verification) is required + before banking/payroll actions. See PIA §12.3 and YPMS-POAM-033. +``` + +--- + +## 4. Guiding architectural choices + +### 4.1 Why the OWC framework + +OWC has an in-repo framework at `src/owc/framework/` and `src/owc/security/` that: generic-CRUD's every entity, enforces data-driven RBAC, emits audit for every state change, and lets a new entity be scaffolded in ~100 lines. YPMS has fewer distinct entities (~25 at Go-Live) but the same pattern applies: application, registrant, parent, host, worksite, position, job posting, enrollment, program, cohort, orientation, timesheet, payroll batch, transportation voucher, note, attachment, audit row, permission, role, user, session, notification, integration event, eligibility rule, event schedule. + +**YPMS Phase 0 vendors the OWC framework in.** Copy — don't submodule — because the two projects can and should evolve independently once YPMS diverges. Vendored code carries a comment naming the OWC commit it was copied from so we can pull upstream fixes deliberately. If the vendored code needs a YPMS-specific change, it stays inside `ypms/app/framework/` and doesn't bleed back. + +### 4.2 Why data-driven RBAC + +The source RFP `C.5.7.29`–`C.5.7.34` mandates group + individual assignment, role-based access control, and admin-managed role definitions. That plus DOES-specific role realities (OYP eligibility examiners vs. payroll admins vs. hearing officers vs. read-only reporting analysts) means the permission matrix will change repeatedly during and after build. **Same DB-plus-seed pattern as OWC.** Refinements are seed updates, not deploys. A superuser role (`DOES_SYSTEM_ADMIN`) bypasses checks the same way `ARKCASE_ADMINISTRATOR` does in OWC. + +### 4.3 Why audit lives in the framework, not in domain modules + +NIST AU-2 / AU-3 / AU-12 and source RFP `C.5.7.39`, `C.5.7.48`, `C.5.7.49` require recording actor, action, resource, and before/after state on every consequential event. If audit emission lived per-handler, every new endpoint would be a chance to forget. Instead, `CRUDService` emits an audit row for create/update/delete/restore, and the router factory emits one even for 501 stubs. **You can't write a route that mutates state without producing an audit row.** Same rule as OWC. + +Additionally, YPMS audits **PII-touching reads** on sensitive-data screens (source RFP `C.5.6.9` #5) — a stricter posture than OWC needs. Achieved by decorating sensitive-record read handlers with an `@audit_read("pii_access")` decorator that flows through the same emission path. + +### 4.4 Why soft delete + version history are mixin defaults + +Same as OWC: base mixins make Archive and Version-history the default rather than retrofitting per-entity. Hard-delete via `CRUDService.hard_delete()` for admin scenarios only. YPMS adds a **PII purge** hard-delete path used by retention automation (§9 of PIA) — separate code path from user-initiated delete, always logged with the retention rule that triggered it. + +### 4.5 Why JWT plus an OIDC-shaped interface + +Phase 0 needs working auth without wiring three external IdPs (Entra ID for staff, an external IdP for youth/host, social-media OAuth). Local username/password + JWT solves that. The shape of `get_current_user` and `security.create_access_token` is OIDC-compatible — Phase 1 swaps the implementation (issuer, JWKS-based verification, refresh tokens) without changing every caller. Same pattern as OWC. + +**YPMS-specific twist**: because there are four user populations with different assurance requirements, the token payload includes an `iam.assurance_level` claim (values: `pre_application`, `standard`, `payroll_authorized`, `staff`, `admin`). Authorization decisions on payroll-touching actions require `iam.assurance_level >= payroll_authorized`, which is only issued after IAL2 proofing. This lets us ship pre-application flows in Phase 1 without waiting on the proofing integration. + +### 4.6 Why pbkdf2_sha256, not bcrypt + +Same reason as OWC: bcrypt 4.x has a runtime incompatibility with passlib's loader on Python 3.12+. Reassess when migrating to argon2id. Password hashing only applies to local-user accounts (initial DOES staff, test users); production staff use Entra ID / SSO, and youth/host external identity is either social-media OAuth or federated to Login.gov. + +### 4.7 Why every stub still fires RBAC + audit + +Same as OWC. Deferred actions return 501 but the request still flows through `require_permission` and emits an audit event. Permission gaps surface at Phase 0 review, not at Phase N feature-completion. + +### 4.8 Why Postgres in dev, SQLite in tests + +Same as OWC. Dev uses Postgres in Docker; tests use SQLite for sub-second runs; anything Postgres-specific (FTS, JSONB ops, address-tsvector search) lives in `framework/search.py` and gets its own Postgres-only test path. + +### 4.9 Why server-rendered Jinja + HTMX for the internal portal, more JS for public + +The internal DOES staff portal is form-heavy, keyboard-driven, and used by ~90 people. OWC's Jinja + HTMX pattern is a proven fit and keeps front-end complexity manageable. The public youth / parent / host portal has a wider audience (~35,000), more responsive-design requirements, and mobile-first expectations from the source RFP (`C.5.21.1`). We reserve the option to build the public portal as a richer client (Vite + React or SvelteKit) rendered by the same FastAPI backend, deciding at Phase 3 kickoff based on how far HTMX carries us. + +### 4.10 Why source RFP wording is treated as spec, not gospel + +The source RFP is the authoritative statement of what OYP needs YPMS to do. But some of its wording predates current standards: + +| Source RFP | Wording | What we build | +|---|---|---| +| `C.5.6.15` | "SSL" | TLS 1.2 minimum, 1.3 preferred, FIPS-approved cipher suites | +| `C.5.7.6` | "unique identifier + shared secret answer" | MFA for staff and admin; MFA above-standard for payroll-authorized youth actions | +| `C.5.7.9` | "FIPS 140-2" | FIPS 140-3 where available; 140-2 acceptable during deprecation window | +| `C.5.7.24` | "Level 3 security" | Treat as NIST 800-63 IAL3/AAL3 pending AO clarification | +| `C.5.3.1` glossary | "Youth: DC resident participants between 99–24 years old" | 14–24 per program-specific eligibility | + +These tailorings are documented in the SSP Appendix D and control-mapping §5. The build follows the tailored level. + +--- + +## 5. Layered architecture + +``` +┌────────────────────────────────────────────────────────────────────────┐ +│ Presentation │ +│ ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │ +│ │ Youth/Parent portal │ │ Host/Employer portal│ │ Internal portal │ │ +│ │ (public; TBD Vite/ │ │ (public; same as │ │ (Jinja+HTMX, │ │ +│ │ HTMX at Phase 3) │ │ Youth stack) │ │ OWC-style) │ │ +│ └─────────────────────┘ └─────────────────────┘ └─────────────────┘ │ +│ Cross-cutting: WCAG 2.1 AA · Language Access · print-friendly views │ +└────────────────────────────────────────────────────────────────────────┘ + │ +┌───────────────────────────────────▼────────────────────────────────────┐ +│ API / application │ +│ FastAPI routers per entity, generated by the vendored OWC router │ +│ factory. Each router: RBAC-gated, audit-emitting, versioned URL space. │ +│ │ +│ ┌───────────────────┐ ┌────────────────────┐ ┌────────────────────┐ │ +│ │ Public API │ │ Internal API │ │ Admin API │ │ +│ │ (rate-limited, │ │ (staff-scoped, │ │ (bulk, config, │ │ +│ │ anti-bot on │ │ keyboard-friendly │ │ data-model mgmt) │ │ +│ │ peak windows) │ │ UX) │ │ │ │ +│ └───────────────────┘ └────────────────────┘ └────────────────────┘ │ +│ │ +│ Domain services: eligibility engine · matching · timekeeping · │ +│ notifications · reporting · consent lifecycle │ +└────────────────────────────────────────────────────────────────────────┘ + │ +┌───────────────────────────────────▼────────────────────────────────────┐ +│ Framework │ +│ Vendored from OWC: CRUDService · router factory · RBAC · audit · │ +│ soft-delete/version mixins · JWT/OIDC-shaped auth · pagination · │ +│ search hooks · seed loader │ +│ YPMS-added: PII-read audit decorator · retention purge · parental- │ +│ consent lifecycle helper · integration-event queue │ +└────────────────────────────────────────────────────────────────────────┘ + │ +┌───────────────────────────────────▼────────────────────────────────────┐ +│ Data │ +│ ┌─────────────────────┐ ┌────────────────────┐ ┌────────────────────┐│ +│ │ Postgres flexible │ │ Azure Blob (docs, │ │ Azure Key Vault ││ +│ │ server (Azure Gov) │ │ photos, resumes) │ │ (FIPS 140-3 HSM) ││ +│ │ private endpoint │ │ private endpoint │ │ keys, secrets ││ +│ └─────────────────────┘ └────────────────────┘ └────────────────────┘│ +│ Alembic migrations, immutable once merged. Row-level PII fields │ +│ encrypted at the app layer (SSN, banking, TFN); rest via TDE. │ +└────────────────────────────────────────────────────────────────────────┘ + │ +┌───────────────────────────────────▼────────────────────────────────────┐ +│ Integrations (external) │ +│ Each integration is a service module with retries, circuit-breaker, │ +│ audit, and kill switch. All calls TLS 1.2+; auth via KV-stored secrets.│ +│ See §7. │ +└────────────────────────────────────────────────────────────────────────┘ +``` + +### 5.1 Repository layout (planned) + +Matches OWC's `owc-system/src/owc/` shape: + +``` +ypms/ +├── ARCHITECTURE.md (this file) +├── CLAUDE.md +├── OVERVIEW.md +├── TODO.md +├── SYSTEM_SECURITY_PLAN.md +├── NIST_800_53_CONTROL_MAPPING.md +├── PRIVACY_IMPACT_ASSESSMENT.md +├── POAM.md +├── OLA_RESPONSE_2026-09-30.md +├── PROJECT_PLAN.md (to be authored — mirrors OWC/PROJECT_PLAN.md) +├── PHASE0_PLAN.md (to be authored) +├── README.md (runnable quickstart; to be authored) +├── CONTRIBUTING.md (ground rules; to be authored) +├── Dockerfile +├── docker-compose.yml +├── pyproject.toml +├── alembic.ini +├── migrations/ +├── src/ypms/ +│ ├── __init__.py +│ ├── main.py (FastAPI app + router registration) +│ ├── framework/ (vendored from OWC + YPMS additions) +│ ├── security/ (JWT, RBAC decorators, password hashing) +│ ├── seed/ (permissions matrix, eligibility rules, program defs, notice text) +│ ├── youth/ (Registrant entity) +│ ├── parent/ (Guardian entity + consent lifecycle) +│ ├── host/ (Host, Worksite, Position, JobPosting) +│ ├── program/ (Program, Cohort, EligibilityRule) +│ ├── application/ (Application, EligibilityDecision, Certification) +│ ├── enrollment/ +│ ├── orientation/ (LMS integration adapter) +│ ├── timekeeping/ (TimeEntry, Timesheet) +│ ├── payroll/ (Payroll vendor adapter, PayrollBatch, TaxDocument) +│ ├── integrations/ +│ │ ├── ssa.py (SSA BSO SSN verify) +│ │ ├── osse.py (CSV ingest, retention) +│ │ ├── cfsa.py (CSV ingest, retention, role-scoped display) +│ │ ├── dc_mar.py (Address verify) +│ │ ├── lms.py +│ │ └── payroll_vendor.py +│ ├── reporting/ (Native reports replacing MicroStrategy) +│ ├── notifications/ (Email, SMS via DOES-approved provider) +│ └── admin/ (User mgmt, role mgmt, workflow rules, broadcasts) +├── tests/ +│ ├── framework/ +│ ├── security/ +│ ├── integrations/ (with recorded fixtures) +│ └── ... +├── client/ (public-portal richer client if we go that way — Phase 3 decision) +└── docs/ + ├── brs-coverage.md + ├── nist-mapping.md + ├── data-flow-diagrams/ + └── compliance/ + ├── ssp/ + ├── controls/ (one file per NIST control, OWC pattern) + ├── poam/ + └── evidence/ +``` + +--- + +## 6. Data architecture + +### 6.1 Core entities (conceptual) + +| Entity | Purpose | Notable fields | +|---|---|---| +| `Registrant` (Youth) | Person applying to and participating in OYP programs | name, DOB, SSN (encrypted, masked in display), address, demographics, contact, immigration-doc references, banking (encrypted), tax elections, minor-flag | +| `Guardian` | Parent/guardian of an under-18 registrant | name, contact, relationship, consent records | +| `ConsentRecord` | Consent artifacts | consent scope, notice-version, timestamp, IP, granter identity, revocation-timestamp | +| `Host` | Employer participating as a placement site | name, business address, tax ID, contact, verified-flag | +| `HostContact` | Named individual at a host | name, title, contact, role at host | +| `Worksite` | Physical location where placements happen | address, host, supervisor, safety attestation | +| `Position` | Placement opening at a worksite | title, description, hours, dates, hourly rate, program eligibility | +| `JobPosting` | Public-facing view of a Position | derived from Position; public-fields only | +| `Program` | OYP program definition | name (MBSYEP, HSIP, MBYLI, CRESP, ...), year, dates, eligibility rule set | +| `Cohort` | Named subset within a Program (e.g. SIT, SYP, Global) | Program, name, dates | +| `EligibilityRule` | Rule row driving auto-eligibility (data-driven, from source RFP Appendix D) | rule id, predicate, effect (`eligible`, `ineligible`, `categorical`), applies-to-program | +| `Application` | A registrant's application to a program | Registrant, Program, cohort, status, submitted-at, decision, decision-actor | +| `EligibilityDecision` | Outcome of running rules on an application | decisions, rule-hits, categorical-eligibility flag | +| `Certification` | Staff certification event on an application | actor, attestation, evidence documents | +| `Orientation` | Orientation completion tracking (via LMS) | Registrant, program, completion-status, completion-date | +| `Enrollment` | Registrant enrolled in a program placement | Registrant, Program, Cohort, Position, dates, status | +| `TimeEntry` | Single hours record | Enrollment, date, hours, submitted-by, approved-by | +| `Timesheet` | Weekly/period rollup of TimeEntry rows | Enrollment, period, entries, approval status | +| `PayrollBatch` | Batch sent to payroll vendor | period, timesheets, sent-at, vendor batch id, reconciliation state | +| `TaxDocument` | W-2 / 1099 reference | Registrant, year, doc-type, source (vendor-generated), retrieval-uri | +| `TransportationVoucher` | Voucher tracking | Registrant, Program, amount, issued-at, redeemed-at | +| `Attachment` | Uploaded document | owner-entity, filename, mime, size, virus-scan-status, encrypted-uri | +| `Note` | Free-form note associated with an entity | subject, body, actor, entity, timestamp | +| `IntegrationEvent` | Every outbound / inbound integration call | integration, direction, request-summary, response-summary, status, retry-count, timestamps | +| `Notification` | Every notification sent | recipient, channel, template, sent-at, delivery-status | +| `EducationRecord` | OSSE-ingested enrollment record (FERPA-scoped) | Registrant, school, grade, status, ingest-batch | +| `FosterIndicator` | CFSA-ingested foster/ward flag (Title 4-scoped) | Registrant, status, ingest-batch, current-only | +| `AuditRow` | Framework-emitted audit | actor, action, entity, entity-id, before, after, timestamp, request-id | +| `Role`, `Permission`, `RoleAssignment` | Data-driven RBAC | seed-loaded | +| `User`, `UserSession` | Authenticated principals across all populations | username, IdP, assurance level, mfa-verified | + +### 6.2 Relationship highlights + +- `Registrant` is the spine. Everything user-facing hangs off it. +- `Guardian ↔ Registrant` is many-to-many but constrained: at most one `active` guardian per under-18 registrant at a time (guardianship handoffs require staff action and a full consent chain replay). +- `Application` is per `(Registrant, Program, Program.year)` — a youth applying to MBSYEP 2027 and HSIP 2027 has two Applications. +- `EducationRecord` and `FosterIndicator` are **join-only visible to role-scoped users**. Neither ever appears on host- or supervisor-facing views. This is an application-layer enforcement, not just RBAC — the API omits the fields from responses that lack the required scope, even if the caller has read on `Registrant`. + +### 6.3 Encryption strategy + +- **Postgres TDE** covers the whole database at rest (Azure-managed). +- **App-layer encryption** for the most sensitive columns: SSN, banking account number, tax ID, immigration-doc image references. Encrypted with keys resolved from Key Vault at request time; decrypted only in memory during processing; never logged. This is above-TDE defense-in-depth for the columns most attractive to an insider or a compromised-app scenario. +- **Blob encryption** for uploaded documents: envelope-encrypted with per-blob DEKs wrapped by a KV-managed KEK. +- **Display masking** for SSN (source RFP `C.5.7.50`) and banking (last-4 only). Masking is applied in the serializer, not just the UI, so API consumers see masked values too. + +### 6.4 Retention automation + +Retention rules from the PIA §9 are encoded in the framework: + +- Each entity declares a `retention_policy` on its model. +- A nightly job scans for records past their retention envelope and executes the policy: soft-delete + tombstone, hard-delete (with audit), or archive-and-scrub-PII depending on the class. +- CFSA-ingested `FosterIndicator` rows purge older-than-two-years annually as a distinct job with a lower error tolerance. +- OSSE-ingested `EducationRecord` rows purge older-than-two-years annually. +- Banking data purges at end of active-payroll status. + +--- + +## 7. Integration architecture + +Each integration follows the same shape: adapter module, config in Key Vault, IntegrationEvent audit on every call, retry with exponential backoff, circuit-breaker, kill-switch env flag. + +### 7.1 SSA (Business Services Online) — SSN verify + +- Outbound API to SSA BSO with SSN and identity elements. +- Called during eligibility determination (post-application, pre-enrollment). +- Governed by the SSA Electronic Information Exchange agreement — `YPMS-POAM-022` (renewal). +- Response cached only for the current eligibility decision — not retained after the decision emits. +- Kill-switch: if SSA endpoint is unreachable, applications queue with a `pending_ssa_verify` status; staff can retry manually or approve with alternate documentation per policy. + +### 7.2 OSSE — school enrollment CSV + +- Inbound secure file transfer (Azure Storage with a private endpoint, or a DOES-hosted SFTP surface with strict IP allowlist). +- Ingest process: fetch → validate schema → dedupe by Registrant → write `EducationRecord` rows → archive source file. +- Every ingest run creates a batch id; every produced row references the batch id for provenance. +- Governed by the DOES–OSSE data-sharing agreement — `YPMS-POAM-020` (renewal). +- FERPA overlay: role-scoped access enforced at the application layer, not just RBAC. + +### 7.3 CFSA — foster / ward-of-state CSV + +- Same shape as OSSE. Different agreement (`YPMS-POAM-021`), different retention (annual purge of older-than-two-years), stricter role scoping (support-service triage only; never displayed to hosts). + +### 7.4 DC MAR — address verify + +- Outbound API for address validation and canonicalization. +- Called at application submission and at every address change. +- Fallback: if DC MAR is unreachable, user-entered address is accepted and flagged for staff review. + +### 7.5 Third-party payroll vendor — hours + payments + tax forms + +- Bidirectional API. Vendor selection outstanding (`YPMS-POAM-023`). +- Outbound: `PayrollBatch` sends approved `Timesheet` rows. +- Inbound: vendor confirms processing and returns `TaxDocument` references. +- Reconciliation is a distinct process: for every batch sent, we wait for confirmation within N business days; unreconciled batches raise alerts. +- Vendor DPA governs breach notification and PII handling. + +### 7.6 Third-party LMS — orientation completion + +- Bidirectional API. Vendor TBD. +- Outbound: enrollment notification (Registrant + Program). +- Inbound: completion status flag only. No LMS-owned PII flows back into YPMS. + +### 7.7 Entra ID — staff identity + +- OIDC federation. Staff authenticate via DOES Entra ID tenant with conditional-access MFA (`YPMS-POAM-030`). +- No local staff passwords in production. Local password auth is used only in dev/test environments and for a small number of pre-Entra bootstrap accounts. + +### 7.8 Youth / host external identity + +- Options tracked in `YPMS-POAM-050`: + 1. Local username / password for youth and host self-registration, plus Login.gov federation option. + 2. Social-media OAuth for browsing / pre-application only; step up to Login.gov before payroll actions. +- The `iam.assurance_level` claim on the JWT gates payroll-touching actions regardless of which IdP issued the initial token. + +### 7.9 Sentinel — SIEM sink + +- Log stream via Azure Diagnostic Settings + custom Log Analytics tables where needed. +- DOES OIT ships application audit events; DC OCTO SOC correlates and alerts. +- Log-schema agreement with OCTO SOC is `YPMS-POAM-043` M1. + +### 7.10 Notifications — email + SMS + +- Email via a DOES-approved provider (likely the same one OWC uses; confirm at Phase 1). +- SMS via a DOES-approved provider. +- Both providers see minimal PII in payloads — never SSN or banking; often just a name and a secure URL. +- Delivery failures raise staff alerts for time-sensitive notices. + +--- + +## 8. Security architecture + +Full detail is in the [SSP](SYSTEM_SECURITY_PLAN.md) and the [control mapping](NIST_800_53_CONTROL_MAPPING.md). Architecture-level highlights: + +### 8.1 Authentication + +- **Staff**: Entra ID + conditional-access MFA (`YPMS-POAM-030`). +- **Youth / host**: external IdP or local account; `iam.assurance_level` gates high-risk actions. +- **Under-18 youth**: additional parental co-consent workflow (see §8.5). +- **Local passwords** (dev/test only): pbkdf2_sha256 per OWC choice (§4.6). + +### 8.2 Authorization + +- Data-driven RBAC via the vendored OWC framework (§4.2). +- `iam.assurance_level` gates a small set of high-risk actions above the base RBAC (payroll enrollment, banking change, immigration-doc access, foster-status view). +- Row-level access ("only your caseload") is a Phase 1+ enhancement — not in Phase 0. Same trajectory as OWC. + +### 8.3 Transport and at-rest + +- TLS 1.2+ (target 1.3) on all endpoints, public and private (`YPMS-POAM-031`). +- Certificates issued through Azure Front Door / App Gateway (managed cert renewal). +- Postgres TDE + app-layer encryption for the highest-sensitivity columns (§6.3). +- Blob envelope encryption with KV-managed KEKs. +- All keys in Azure Key Vault (Gov / HSM), FIPS 140-3 (`YPMS-POAM-032`). + +### 8.4 Boundary + +Three zones matching source RFP `C.5.7.23`: + +- **Untrusted**: public internet, mobile clients, unauthenticated portal. +- **Transition**: WAF + App Gateway; TLS termination; rate limiting; authentication. +- **Trusted**: FastAPI app, Postgres, Key Vault, blob storage — private endpoints only, no public ingress. + +### 8.5 Consent and parental co-consent + +Because parental co-consent for under-18 registrants is a first-class flow (PIA §6.3), it's a real subsystem, not a checkbox on a form: + +- Under-18 registrant provides parent contact. +- YPMS sends a secure link to the parent; parent creates account or authenticates. +- Parent explicit-grants consent per notice-version; a `ConsentRecord` row is created. +- The registrant's `Application.eligibility_gate` requires an unrevoked active `ConsentRecord` for the notice-version in force. +- Parent portal exposes view / update / export / revoke on the child's data. +- Consent revocation triggers the individual-rights workflow (PIA §7). + +### 8.6 Audit and monitoring + +- Framework-emitted audit on every state change (§4.3). +- PII-read audit on sensitive-record reads (`@audit_read`; source RFP `C.5.6.9` #5). +- All audit rows tagged with request id, actor, target, action, before/after. +- Audit stream to Sentinel (`YPMS-POAM-043`). +- Monthly privileged-user audit review by ISSO (that's Chris, dual-hatting per SSP §5). + +--- + +## 9. Deployment architecture + +### 9.1 Environments (per source RFP `C.5.5.1`, minimum two lower + prod) + +| Env | Purpose | Data | Access | +|---|---|---|---| +| **dev** | Developer sandbox, feature branches | Synthetic only | DOES OIT engineers | +| **test** | Integration testing, UAT | Synthetic + optionally anonymized subsets | DOES OIT + OYP UAT users | +| **prod** | Production | Real PII | Named production users; JIT admin | + +Dev and test are sanitized of production PII. Any refresh of dev/test from prod runs through a scrub-and-synthesize pipeline that overwrites SSN, banking, addresses, and any FERPA/CFSA-ingested rows with synthetic equivalents. + +### 9.2 Azure Government topology + +``` + Azure Front Door (WAF, DDoS, TLS termination, rate limiting) + │ + ▼ + App Gateway (private endpoint termination for internal portal) + │ + ▼ + ┌──────────────────────────────────────────────────────────┐ + │ Resource group per environment │ + │ │ + │ ┌───────────────────┐ ┌────────────────────────────┐ │ + │ │ App Service / │───►│ Postgres flexible server │ │ + │ │ Container Apps │ │ (private endpoint) │ │ + │ │ (FastAPI) │ └────────────────────────────┘ │ + │ └───────────────────┘ │ + │ │ │ + │ ├──► Azure Blob (private endpoint) │ + │ │ │ + │ ├──► Azure Key Vault (Gov / HSM) │ + │ │ │ + │ └──► Azure Diagnostic Settings ──► Log Analytics│ + │ │ │ + │ ▼ │ + │ Sentinel (OCTO) │ + └──────────────────────────────────────────────────────────┘ +``` + +Compute choice — App Service vs. Container Apps vs. AKS — is a Phase 0 sub-decision. Default is **Azure App Service for Containers** unless OWC has already picked something different, in which case we match. (OWC currently runs in Docker; we'll confirm OWC's Azure Gov deployment target at Phase 0 kickoff.) + +### 9.3 IaC and CI/CD + +- **IaC**: Bicep (matches Azure-native tooling and OCTO templates). Tracked in `infra/`. +- **CI**: GitHub Actions (or Azure DevOps, matching OWC — confirm at Phase 0). +- **Pipeline gates**: unit tests, SAST (ruff + a security-focused linter like bandit), SCA (pip-audit or safety), secret scanning (gitleaks), SBOM (CycloneDX; `YPMS-POAM-042`). +- **Deploy**: environment promotion (dev → test → prod) with approvals for prod. +- **Migrations**: Alembic auto-applied via a migration container at deploy time; migrations are immutable once merged (OWC hard rule). + +### 9.4 Failover and backup + +- Azure paired region for backup storage (inherited FedRAMP-High geo-redundancy). +- Application-tier redundancy via App Service instance count (min 2 in prod). +- Postgres flexible-server high availability with zone-redundant standby in prod. +- **Failover-during-patching** capability required by source RFP `C.5.6.13` — achieved through blue/green or rolling deploy against the load balancer. +- Restore drill annually (`YPMS-POAM-044`). + +--- + +## 10. Cross-cutting concerns + +### 10.1 Logging + +- Structured JSON (`ypms.log.record` shape); one line per event. +- Request ID propagated end-to-end. +- Sensitive fields (SSN, banking, passwords, tokens) never logged, ever. A `sanitize_for_log` helper strips them before emit. +- Logs go to stdout (Azure App Service picks them up), thence to Log Analytics, thence to Sentinel. + +### 10.2 Error handling + +- Errors are logged with request id and category (source RFP `C.5.6.9` #3, `C.5.7.43`). +- User-facing error messages are non-exploitable (no stack traces, no DB messages, no version strings). +- Errors on integration calls raise circuit-breaker warnings after N consecutive failures. +- Errors on payroll batches are staff-alertable; payroll cannot silently drop hours. + +### 10.3 Notifications + +Every consequential state change has a corresponding notification design: + +- Application submitted → confirmation to registrant + guardian. +- Eligibility decided → notice to registrant + guardian. +- Certification approved / rejected → notice. +- Enrollment confirmed → welcome notice. +- Timesheet approved → notice. +- Payroll processed → notice with masked amount and last-4 of account. +- Password change → notice via preferred channel (source RFP `C.5.7.14`). + +### 10.4 Internationalization and accessibility + +- DC Language Access Act obligations require multi-language delivery. Notices and portal content templated with a language key; translation review process is an operational activity, not a code activity. (`YPMS-POAM-081`) +- WCAG 2.1 AA target: automated checks in CI (`axe-core` or equivalent), manual audit pre-Go-Live (`YPMS-POAM-082`). +- Keyboard navigation and alternative-keyboard shortcuts per source RFP `C.5.21.2`, `C.5.21.24`. + +### 10.5 Peak-window scaling + +- MBSYEP application window is a hard peak. Auto-scaling on App Service configured with pre-warm before the window opens. +- Anti-bot / rate-limit rules on public endpoints tuned for the window (`YPMS-POAM-101`). +- CDN / Front Door caches static content aggressively during the window. + +--- + +## 11. Non-functional targets + +| Property | Target | Source | +|---|---|---| +| Availability (rolling 30 days) | 99.5% | Source RFP `C.5.6.17` | +| Response time (webserver request → response) | ≤ 1 second | Source RFP `C.5.6.27` | +| Concurrent-user scaling | 50%/year growth headroom | Source RFP `C.5.6.20` | +| Browser support | Latest Chrome/Edge/Safari/Opera (source RFP `C.5.6.11`); no IE despite the source RFP mentioning it (deprecated) | Tailoring | +| Mobile support | Mobile-first for public portal; portable-device support for internal (`C.5.21.1`) | Source RFP | +| Backup cadence | Daily (`C.5.8.21`) | Source RFP | +| Restore RTO | Within SLA envelope; ≤ 4 hours target for full restore | Derived | +| RPO | ≤ 1 hour (point-in-time restore) | Derived | +| Peak-load capacity | Sustained MBSYEP application window + 3× spike headroom | Program-owner input; validate at Phase-8 load-test | + +--- + +## 12. Delivery phases + +OWC's `PHASE{N}_PLAN.md` pattern is the template. The current phase plan is authoritative over older ones on conflict. + +| Phase | Scope | Illustrative deliverables | +|---|---|---| +| **Phase 0 — Foundation** | Framework vendor-in, auth (local + JWT), RBAC, audit, base CRUD, dev/test envs, CI/CD, migration harness | `main.py`, `framework/`, `security/`, first migration, one working entity (Registrant), 501 stubs on all others | +| **Phase 1 — Applications and identity** | Registrant + Guardian + ConsentRecord, application intake, parental co-consent workflow, Entra ID for staff | Public registration; staff portal shell; consent lifecycle | +| **Phase 2 — Eligibility** | EligibilityRule seed from source RFP Appendix D, eligibility engine, DC MAR + SSA integration | Applications flow through auto-eligibility to a decision | +| **Phase 3 — Public portal decision** | Vite/React vs HTMX-only for youth/host portal; whichever chosen, complete public UX baseline | Live public portal at usable state | +| **Phase 4 — Host + worksite + posting** | Host registration, Worksite, Position, JobPosting, matching | Hosts can register and post; youth can browse | +| **Phase 5 — OSSE + CFSA + LMS integrations** | CSV ingest pipelines, retention automation, role-scoped surfaces | Data-sharing agreements complete; ingest live | +| **Phase 6 — Enrollment + orientation** | Youth-program matching → enrollment; LMS orientation tracking | End-to-end from application to enrollment | +| **Phase 7 — Timekeeping + payroll** | Timesheets, payroll batches, payroll-vendor integration, tax-doc reference | End-to-end from enrollment to payment | +| **Phase 8 — Reporting + admin** | Native reports replacing MicroStrategy; workflow-rule management; broadcast notifications | Feature-complete for MBSYEP season | +| **Phase 9 — Hardening** | Load test, pentest, SCA remediation, accessibility, Language Access, docs | ATO submission package | +| **Phase 10 — ATO + Go-Live** | Independent Control Assessment, AO decision, cutover | Production | + +--- + +## 13. Open questions + +Mirrored from SSP Appendix D and control-mapping §5 to avoid drift. Each has a POA&M id. + +1. **"Level 3 security"** (`YPMS-POAM-051`). Interim posture: treat as NIST 800-63 IAL3/AAL3 — the more demanding reading. +2. **Youth identity model** (`YPMS-POAM-050`, `YPMS-POAM-033`). Recommendation: social-media login for browsing only; step-up to IAL2 (Login.gov) before payroll actions; parental co-auth for under-18. +3. **PCI DSS scope** (`YPMS-POAM-052`). Expected out of scope (payroll is ACH via vendor). Confirm at Phase 7 payroll-vendor selection. +4. **Health-record CSV path** (`YPMS-POAM-053`). Recommendation: defer to an emergency-scoped extension with its own PIA addendum; do not include in steady-state boundary. +5. **Retention** (`YPMS-POAM-054`). Interim retention posture is in PIA §9; formalize with DOES records officer before Phase 8. + +--- + +## 14. What Phase 0 deliberately does not do + +Following the OWC pattern of stating non-goals up front: + +- **No frontend beyond an admin shell.** Public portal UX is Phase 1+. +- **No domain workflow.** Eligibility engine, matching, timekeeping, payroll integration are Phase 2+. +- **No integrations.** SSA, OSSE, CFSA, DC MAR, LMS, payroll adapters are Phase 5+ (SSA earlier if eligibility is on the critical path). +- **No row-level RBAC.** Phase 0 is "can role X do action Y on entity type Z?" Row-level ("your caseload only") comes with the eligibility phase. +- **No NIST-control code beyond the technical subset.** Policy/org controls (PM, PL, PS, AT families) are policy work, tracked in POA&M, not code. +- **No production data.** Dev and test are synthetic-only until sanitization pipelines and data-sharing agreements are complete. + +--- + +## 15. Alignment with OWC — what we borrow directly + +To keep two systems maintainable by one team, we lean hard on OWC's patterns. Everything below is copied or adapted from OWC unless YPMS's problem shape genuinely requires deviation. + +- Stack (Python 3.12 / FastAPI / SQLAlchemy 2.x / Alembic / Postgres / SQLite-in-tests). +- Framework directory structure and generic-CRUD pattern. +- Data-driven RBAC with a super-role bypass. +- Audit-in-framework rule; every state change and every stub emits. +- Soft-delete + version-history mixins. +- JWT + OIDC-shaped auth. +- pbkdf2_sha256 for local passwords (until argon2id migration). +- Postgres in dev, SQLite in tests. +- `PHASE{N}_PLAN.md` cadence and phase-current-wins rule. +- CONTRIBUTING.md hard rules (migrations immutable, no `--no-verify`, tests required on framework, no domain logic in framework/security). +- `docs/compliance/{ssp,controls,poam,evidence}/` layout. +- The DCYWP `NIST_800_53_CONTROL_MAPPING.md` DCYWP-style ✅/🟡/❌/🔵/📋 status vocabulary once code starts landing (control mapping is at 📝 today because there's no code yet). + +Where YPMS diverges: + +- **Four-population identity model** (staff, youth, parent, host) is more elaborate than OWC's mostly-staff model. +- **`iam.assurance_level` claim** to gate payroll-touching actions is YPMS-specific. +- **Parental co-consent lifecycle** is a real subsystem, not a checkbox. +- **PII-read audit decorator** on sensitive-record reads. +- **Retention automation** is more elaborate because of FERPA + CFSA + banking timing rules. +- **CSV ingest pipelines** (OSSE, CFSA) are a subsystem OWC doesn't have. + +--- + +**End of draft v0.1.** diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000..d19655b --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,68 @@ +# `ypms/` — Youth Program Management System + +Project directory for **YPMS**, the modernized case-management platform for DC DOES Office of Youth Programs (OYP). Serves MBSYEP (Marion S. Barry Summer Youth Employment Program), HSIP, MBYLI (SIT / School Year / Global Education), CRESP, and future OYP programs. + +**In-house build**, matching the DCYWP / OWC / Employer 360 pattern — DOES OIT writes and owns the code. The prior YPMS RFP (Solicitation `Docxxxxx`, April 2025) is retained as a **source of functional and security requirements**, not as a Contractor procurement. + +## Project identity + +| Field | Value | +|---|---| +| System | Youth Program Management System (YPMS) | +| Business owner | DOES Office of Youth Programs (OYP) | +| Technical owner | DOES OIT / CIO | +| Delivery model | **In-house build by DOES OIT** | +| Stack | **Python 3.12 / FastAPI / SQLAlchemy / Postgres** (OWC alignment, decision recorded 2026-09-30) | +| Hosting | Azure Government Cloud (aligned with OWC and Employer 360) | +| Source requirements | Prior YPMS RFP (Solicitation `Docxxxxx`, April 2025) — Appendix A–F functional, Appendix E non-functional, C.5.7 security catalogue | +| Status | Pre-development as of 2026-09-30 | +| FY27 designation | DOES Strategic Initiative for FY27 (confirmed by OLA) | +| Go-live target | Beginning of DC FY2027 per source RFP; effective slip acknowledged pending team formation and architecture | +| ATO baseline | NIST SP 800-53 Rev. 5 Moderate | + +## What this directory holds + +Planning, requirements, ATO, and operations artifacts for YPMS, and — once development starts — the application source code. Layout matches OWC: a single Python package with FastAPI routers, SQLAlchemy models, Alembic migrations, and a client bundle. See `owc-system/` for the reference. + +Anchor docs: + +- `CLAUDE.md` — this file +- `OVERVIEW.md` — plain-English summary of what YPMS is, users, programs, timeline +- `TODO.md` — team formation → architecture → build → ATO → go-live checklist +- `SYSTEM_SECURITY_PLAN.md` — draft SSP v0.2 +- `NIST_800_53_CONTROL_MAPPING.md` — full control statements with in-house ownership tags and evidence artifacts +- `POAM.md` — 62-item POA&M seeded 2026-09-30 +- `OLA_RESPONSE_2026-09-30.md` — OLA / City Administrator Q&A +- Companion ATO artifacts to be authored: `FIPS_199_MEMO.md`, `PRIVACY_IMPACT_ASSESSMENT.md`, `INCIDENT_RESPONSE_PLAN.md`, `CONTINGENCY_PLAN.md`, `RULES_OF_BEHAVIOR.md` + +## Distinctions from other projects here + +- **Not DCYWP.** DCYWP (root of the parent directory) is in-house for youth **work permits** under §32-202 / §32-206. YPMS is in-house for youth **workforce programs** — different scope, different statute, different business owner (OYP vs. Office of Wage Hours). Same DOES OIT tech ownership. +- **Not OWC.** OWC has its own AO-locked FISMA Moderate ATO with an October 2026 submission. YPMS has its own boundary, but will likely inherit stack decisions, Azure Gov deployment patterns, and Sentinel integration from OWC to move faster. +- **Not UIBS.** UIBS is the adult Unemployment Insurance modernization — separate program. +- **Not Employer 360.** Employer 360 is the shared employer master. YPMS's employer/host records are a candidate downstream consumer of Employer 360 once E360 lands; YPMS should not reinvent employer matching. + +## Working conventions + +- **Source-requirement traceability.** The RFP C.5.7 catalogue (54 security requirements), C.5.6 infrastructure, C.5.8 database, and Appendix E non-functional list are the source of functional and security requirements. Every SSP / control-mapping statement traces back to a `C.5.x.y` requirement or a NIST control. Auditors read these; keep the trace intact. +- **In-house evidence model.** Evidence for controls is repo file paths (`ypms/app/...`), Alembic migration files, CI/CD configuration, and log samples — the OWC pattern. Not Contractor deliverables. +- **Ownership tags in control mapping.** `DOES OIT` for controls implemented in code/config; `Hybrid` for DOES OIT + DC OCTO enterprise services; `Inherited` for Azure Gov FedRAMP High or DC OCTO enterprise; `Organizational` for DOES policy/process/training. +- **Data-sharing agreements are load-bearing.** OSSE (FERPA) and CFSA (DC Code Title 4) exchanges cannot be built without executed paper first. Same for SSA and payroll-vendor selection. Track those explicitly in `TODO.md` and `POAM.md`. +- **The source RFP wording sometimes lags NIST.** Examples: RFP says SSL (deprecated → build to TLS 1.2+); FIPS 140-2 (sunset → build to FIPS 140-3); `C.5.7.6` "unique identifier + shared secret" (not MFA → build MFA above this floor). Where the RFP wording is worse than the modern standard, build to the standard and note the tailoring in the SSP. + +## Open policy questions (as of 2026-09-30) + +Recorded here so they don't drift out of view; each is also in the SSP Appendix D and tracked in `POAM.md`. + +1. What is **"Level 3 security"** in source RFP `C.5.7.24` — an internal maturity level, NIST 800-63 AAL/IAL 3, or something else? Feeds `YPMS-POAM-051`. +2. **Youth identity model** — social-media login for pre-application only, with full identity proofing (Login.gov or SSA) required before banking/payroll actions? Parental co-auth for under-18? Feeds `YPMS-POAM-050`, `YPMS-POAM-033`. +3. Is **PCI DSS** actually in scope? Payroll is ACH via third-party vendor; if no card processing, this de-scopes. Feeds `YPMS-POAM-052`. +4. Should the **dormant COVID-era health-record CSV path** be in the steady-state boundary, or deferred to an emergency-scoped extension with its own PIA? Feeds `YPMS-POAM-053`. +5. **Retention** for audit logs, case records, backups — align with DOES records schedule and OYP program-specific retention. Feeds `YPMS-POAM-054`. + +## Resolved decisions (as of 2026-09-30) + +- **Stack:** Python 3.12 / FastAPI / SQLAlchemy / Postgres (OWC alignment). `YPMS-POAM-040` closed. +- **ISSO, AO, and System Owner:** Chris Tonjes (DOES CIO). Role concentration recorded in SSP §5 with risk-acceptance note. `YPMS-POAM-002` and `YPMS-POAM-090` closed. +- **IaaS:** Azure Government Cloud (aligned with OWC and Employer 360). +- **SIEM sink:** DC OCTO Sentinel. diff --git a/NIST_800_53_CONTROL_MAPPING.md b/NIST_800_53_CONTROL_MAPPING.md new file mode 100644 index 0000000..e2dff8a --- /dev/null +++ b/NIST_800_53_CONTROL_MAPPING.md @@ -0,0 +1,474 @@ +# NIST SP 800-53 Rev. 5 Control Mapping + +**System:** Youth Program Management System (YPMS) +**System Owner:** District of Columbia Department of Employment Services (DOES) +**Document version:** 0.2 (draft — in-house build reframe) +**Date:** 2026-09-30 +**Author:** DOES CIO +**Companion to:** [`SYSTEM_SECURITY_PLAN.md`](SYSTEM_SECURITY_PLAN.md) + +--- + +## 1. System Categorization (FIPS 199 / FIPS 200) + +| Security Objective | Categorization | Rationale (see SSP §2 for detail) | +|---|---|---| +| **Confidentiality** | Moderate (High-sensitivity subsets) | Minors' PII, SSN, banking, FERPA-covered OSSE records, CFSA foster/ward flags. | +| **Integrity** | Moderate | Eligibility decisions gate paid employment; wage/tax computations flow to third-party payroll. | +| **Availability** | Moderate | 99.5% SLA; MBSYEP peak windows are hard deadlines. | + +**Resulting baseline:** NIST 800-53 **Moderate**. See SSP §2.3 for overlays (FERPA, SSA data-exchange, DC OCTO IT policy, PCI DSS conditional). + +--- + +## 2. Scope and Methodology + +YPMS is an **in-house build by DOES OIT** on Azure Government, matching the DCYWP / OWC / Employer 360 delivery pattern. DOES OIT writes the code, operates the Azure Gov tenant, and owns evidence collection. This document maps controls to **who implements them, where the evidence lives (repo file paths, configuration exports, log samples, DOES-authored companion docs), and what remains organizational vs. inherited**. + +Ownership model matches DCYWP's SSP: the vast majority of technical controls are DOES OIT; physical/environmental controls are inherited from Azure Gov FedRAMP High; some controls are Hybrid with DC OCTO enterprise services (Entra ID for staff identity, Sentinel for SIEM, endpoint program for managed devices); a substantial number are Organizational (DOES policy, process, training). + +### Status legend + +- 📝 **Planned (DOES OIT)** — required, will be implemented in the codebase or Azure tenant, no evidence yet (pre-development). +- ✅ **Implemented** — evidence exists in the repo, pipeline, or Azure tenant. Populated once development starts. +- 🟡 **Partial** — some objectives met; named gaps require additional code, configuration, or operational artifacts. +- 🤝 **Hybrid** — DOES OIT + DC OCTO enterprise or a third-party vendor (payroll, LMS, IdP). +- 🔵 **Inherited** — satisfied by Azure Government FedRAMP High, DC OCTO enterprise services, or a vendor's own authorization. +- 📋 **Organizational (DOES)** — DOES policy, process, training, or governance artifact. On the DOES ATO-package punch list. +- ⚠️ **Source-RFP gap / SSP tailoring** — source-RFP wording does not fully meet the Moderate baseline; SSP tailors above the source-RFP floor. Build must reflect the tailored level. +- ❓ **Open decision** — awaiting AO or DOES CIO disposition; tracked in SSP Appendix D and `POAM.md`. + +### Ownership legend + +- **O** — DOES OIT (implements in code/config in this repo) +- **D** — DOES (CIO, ISSO, HR, Privacy Officer, OGC, or OYP as noted) +- **H** — Hybrid (DOES OIT + DC OCTO enterprise, or DOES OIT + third-party vendor) +- **I** — Inherited (Azure Gov FedRAMP High, DC OCTO enterprise, or third-party vendor authorization) + +### Source-RFP citations + +Citations like `C.5.7.9` refer to the prior YPMS RFP (Solicitation `Docxxxxx`, April 2025), used here as **source functional and security requirements**, not as Contractor obligations. Where a control has no source-RFP driver but is required by the Moderate baseline or SSP tailoring, the source-RFP-ref column is blank and the note explains the source of the obligation. + +### Evidence artifacts + +The "Evidence expectation" column names what DOES needs to see for that control to pass an independent assessment. Evidence sources are the DCYWP-style stack: repo file paths (`ypms/server/...`), migration files, CI/CD configuration, Azure resource configuration, DOES-authored companion docs (in `ypms/`), and continuous-monitoring output (log samples, scan reports, access-recert records). + +--- + +## 3. Control Family Summary + +| Family | Controls Mapped | 📝 DOES OIT | 🤝 Hybrid | 🔵 Inherited | 📋 Org / DOES | ⚠️ Tailoring | ❓ Open | +|---|---:|---:|---:|---:|---:|---:|---:| +| AC — Access Control | 14 | 10 | 2 | 1 | — | 1 | — | +| AT — Awareness & Training | 4 | — | 2 | — | 2 | — | — | +| AU — Audit & Accountability | 11 | 9 | 1 | — | 1 | — | — | +| CA — Assessment, Authorization, and Monitoring | 7 | 1 | 2 | — | 4 | — | — | +| CM — Configuration Management | 10 | 6 | 2 | — | 2 | — | — | +| CP — Contingency Planning | 8 | 3 | 2 | 2 | 1 | — | — | +| IA — Identification & Authentication | 11 | 8 | — | — | — | 2 | 1 | +| IR — Incident Response | 8 | 2 | 4 | — | 2 | — | — | +| MA — Maintenance | 4 | 2 | 1 | 1 | — | — | — | +| MP — Media Protection | 6 | — | — | 6 | — | — | — | +| PE — Physical & Environmental | 12 | — | — | 12 | — | — | — | +| PL — Planning | 5 | 1 | — | — | 4 | — | — | +| PM — Program Management | 12 | — | — | — | 12 | — | — | +| PS — Personnel Security | 8 | 1 | 3 | — | 4 | — | — | +| PT — PII Processing & Transparency | 6 | 1 | 2 | — | 3 | — | — | +| RA — Risk Assessment | 7 | 3 | 2 | — | 2 | — | — | +| SA — System & Services Acquisition | 12 | 8 | — | — | 4 | — | — | +| SC — System & Communications Protection | 17 | 14 | — | 3 | — | 1 | — | +| SI — System & Information Integrity | 12 | 10 | 2 | — | — | — | — | +| SR — Supply Chain Risk Management | 6 | 3 | 3 | — | — | — | — | +| **Totals** | **180** | **82** | **26** | **25** | **41** | **4** | **1** | + +The Moderate baseline contains ~261 controls including enhancements; the ~80 not enumerated here are either subsumed by their parent control's row, deferred to the architecture kickoff, or apply only to specialized subsystems (e.g., AT-3(5) for practical exercises, SC-15(4) for microphone/camera). Those will be added at v0.3 once the architecture lands. + +Status distribution will shift from 📝 to ✅/🟡/❌ as the codebase materializes; refresh at every phase gate. + +--- + +## 4. Detailed Control Mapping + +### AC — Access Control + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **AC-1 Policy and Procedures** | 📋 | D | — | DOES OCTO IT Security Policy applies (`C.5.7.53`). DOES ISSO owns YPMS access-control procedure document. **Evidence:** signed DOES Access Control Policy, RoB (`ypms/RULES_OF_BEHAVIOR.md`). | +| **AC-2 Account Management** | 📝 | O | `C.5.7.4`, `C.5.7.5`, `C.5.7.7`, `C.5.7.29`, `C.5.7.47` | Admin enable/disable; auto-disable on inactivity; 12–64 char alphanumeric IDs; group + individual assignment via Entra ID; no re-issue of deleted or previously-assigned IDs. **Evidence:** account-lifecycle event samples from Sentinel; documented account-provisioning workflow in `ypms/RULES_OF_BEHAVIOR.md`; quarterly access-recert records; DOES OIT personnel-access roster per source RFP `C.5.8.16`, `C.5.8.17` adopted as internal policy. | +| **AC-2(1) Automated Account Management** | 📝 | O | `C.5.7.4`, `C.5.7.31` | Automated inactivity-disable; real-time and scheduled access-right changes. **Evidence:** configuration screenshot of inactivity threshold; audit log showing an auto-disable event. | +| **AC-2(3) Disable Inactive Accounts** | 📝 | O | `C.5.7.4` | Organization-defined inactivity threshold (`[TBD]` — recommend 90 days for staff, 180 days for youth accounts). **Evidence:** configured threshold value + audit sample. | +| **AC-2(4) Automated Audit Actions** | 📝 | O | `C.5.7.36`, `C.5.7.39` | All account create/modify/enable/disable/remove actions auto-logged. **Evidence:** log samples. | +| **AC-3 Access Enforcement** | 📝 | O | `C.5.7.21`, `C.5.7.27`, `C.5.7.28`, `C.5.7.31`, `C.5.7.48` | Server-side authorization on every action; admin-only view/change of access rights; enforce authorizations per access-control policies. **Evidence:** access-control matrix showing every role × object; penetration-test evidence that unauthenticated and lower-role users cannot reach protected functions. | +| **AC-4 Information Flow Enforcement** | 📝 | O | `C.5.7.23` | Trusted / transition / untrusted zone segmentation; untrusted systems cannot reach trusted-zone systems directly. **Evidence:** network architecture diagram (from the DOES OIT architecture document — `YPMS-POAM-040`); Azure NSG / firewall rule export. | +| **AC-6 Least Privilege** | 📝 | O | `C.5.7.32`, `C.5.7.33`, `C.5.7.34` | RBAC over defined objects; one login per staff, role-mediated access; admin maintains role-based security. CFSA foster/ward data and OSSE FERPA records reachable only by role-flagged users. **Evidence:** role catalogue with data-class access mapping. | +| **AC-6(1) Authorize Access to Security Functions** | 📝 | O | `C.5.7.28` | Only administrators can view/change access rights. **Evidence:** role catalogue. | +| **AC-6(2) Non-Privileged Access for Non-Security Functions** | 📝 | O | `C.5.7.33` | Staff use non-privileged accounts by default for routine work. **Evidence:** account-inventory review. | +| **AC-6(5) Privileged Accounts** | 📝 | O | | Named, approved list of privileged users. **Evidence:** privileged-user roster + quarterly recert. | +| **AC-6(9) Log Use of Privileged Functions** | 📝 | O | `C.5.7.36` | Auto-log all admin actions including account create/modify/enable/disable/remove. **Evidence:** log samples. | +| **AC-6(10) Prohibit Non-Privileged Users from Executing Privileged Functions** | 📝 | O | `C.5.7.27`, `C.5.7.32` | Enforced server-side. **Evidence:** pentest evidence. | +| **AC-7 Unsuccessful Logon Attempts** | 📝 | O | `C.5.7.10`, `C.5.7.11` | Lockout after 5 attempts; user notified on revocation. **Evidence:** configured threshold; audit sample of a lockout event and notification. | +| **AC-8 System Use Notification** | 📝 | O | `C.5.7.37` | Notification banner before granting access. **Evidence:** screenshot of banner; DOES-approved banner text on file. | +| **AC-11 Session Lock** | 📝 | O | `C.5.7.3` | Idle-timeout session lock with re-authentication. **Evidence:** configured timeout value. | +| **AC-11(1) Pattern-Hiding Displays** | 📝 | O | | Screen obscured on lock. **Evidence:** UX walkthrough. | +| **AC-12 Session Termination** | 📝 | O | `C.5.7.3` | Idle session termination with re-authentication. **Evidence:** configured timeout value; log sample of a session-terminated event. | +| **AC-14 Permitted Actions Without Identification or Authentication** | 📝 | O | | Limited to public content (program info, job postings, application intake as unauthenticated entry). **Evidence:** enumeration of unauthenticated endpoints. | +| **AC-17 Remote Access** | 🤝 | O, D | | All access is remote by architecture. MFA required for staff and admin via Entra ID conditional access (see IA-2). **Evidence:** Entra CA policy export; endpoint-compliance policy (source RFP `C.5.6.30`). | +| **AC-17(1) Monitoring and Control** | 📝 | O | `C.5.6.9` #19 | SIEM monitoring of remote access. **Evidence:** SIEM feed. | +| **AC-17(2) Cryptographic Protection** | 📝 | O | `C.5.6.15`, `C.5.7.9` | ⚠️ Source RFP says SSL; **SSP tailors to TLS 1.2 minimum, TLS 1.3 preferred, FIPS-approved suites**. **Evidence:** TLS configuration audit; qualys/ssllabs-equivalent report. | +| **AC-18 Wireless Access** | 🔵 | I | | Inherited from DOES endpoint program / DC OCTO. | +| **AC-19 Access Control for Mobile Devices** | 🤝 | O, D | `C.5.7.35`, `C.5.6.30` | Mobile-platform design conforms to encryption, access control, application security; endpoints comply with DC OCTO policy. **Evidence:** MDM configuration for DOES-managed devices; mobile-web hardening statement in the architecture document. | +| **AC-20 Use of External Systems** | 🤝 | O, D | | Governs host/employer access and third-party integrations (payroll, LMS, social-media login, DC MAR). **Evidence:** ISA/MOU inventory (see §11 of SSP). | +| **AC-22 Publicly Accessible Content** | 📝 | O | | Public content reviewed before publication; PII filters. **Evidence:** editorial workflow doc. | + +### AT — Awareness and Training + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **AT-1 Policy and Procedures** | 📋 | D | | DOES annual security awareness policy. **Evidence:** policy document. | +| **AT-2 Literacy Training and Awareness** | 🤝 | O, D | `C.5.9` | DOES annual awareness for staff and any contracted individual developers. Source RFP §C.5.9 informs the user-population training plan. **Evidence:** training completion records; content library. | +| **AT-2(2) Insider Threat** | 📋 | D | | Insider-threat awareness content in the annual training. **Evidence:** module inclusion. | +| **AT-3 Role-Based Training** | 🤝 | O, D | `C.5.9`, `C.5.27.3` | Adjudicators, eligibility examiners, payroll admins, hearing-adjacent staff; two DOES team members trained on Requirements Management Tool. **Evidence:** role-training matrix, completion records. | +| **AT-4 Training Records** | 📋 | D | | DOES-maintained. **Evidence:** training records system. | + +### AU — Audit and Accountability + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **AU-1 Policy and Procedures** | 📋 | D | `C.5.7.53` | DOES OCTO logging policy applies. **Evidence:** policy. | +| **AU-2 Event Logging** | 📝 | O | `C.5.7.39`, `C.5.6.9` #4 | Comprehensive event set: root/admin actions, audit-log access/modification, successful and unsuccessful logon attempts, password changes, system-level object create/delete, all PII/sensitive-data interactions, role changes, shutdown/restart, file access authorized and unauthorized, user logon events, plus DOES-defined additions. **Evidence:** event-catalog document; SIEM sample stream. | +| **AU-3 Content of Audit Records** | 📝 | O | `C.5.7.15`, `C.5.7.48`, `C.5.7.49`, `C.5.6.9` #8, #11, #12, #13 | What/when/where/source/outcome/identity; sufficient to reconstruct events; unique transaction ID per transaction; before-and-after transaction history; communication send/access logging. **Evidence:** log-record specification; log sample. | +| **AU-3(1) Additional Audit Information** | 📝 | O | | Extended fields for financial-adjustment events (payroll approval, banking change, eligibility change). **Evidence:** log sample. | +| **AU-4 Audit Log Storage Capacity** | 📝 | O | | Sized for `[TBD]` retention (see AU-11). **Evidence:** capacity plan. | +| **AU-5 Response to Audit Logging Process Failures** | 📝 | O | `C.5.7.26`, `C.5.6.9` #23 | Alerts to admins and additional roles on security compromise; user-account lockout alerts; logging-pipeline health monitoring. **Evidence:** runbook + alert-configuration screenshot. | +| **AU-6 Audit Record Review, Analysis, and Reporting** | 🤝 | O, D | `C.5.6.9` #19–22 | Sentinel aggregation into meaningful security intelligence; alerts on business-rule/workflow thresholds. DC OCTO SOC consumes the feed. **Evidence:** Sentinel correlation-rule inventory; SOC alert-triage runbook. | +| **AU-7 Audit Record Reduction and Report Generation** | 📝 | O | `C.5.6.9` #20 | Configurable aggregation and reporting. **Evidence:** report templates. | +| **AU-8 Time Stamps** | 📝 | O | `C.5.7.40` | All critical system times synchronized. **Evidence:** NTP configuration; sample logs showing consistent UTC/ISO-8601 timestamps. | +| **AU-9 Protection of Audit Information** | 📝 | O | `C.5.7.41`, `C.5.6.9` #6 | Audit information and audit tools protected from unauthorized access, modification, and deletion; role-based access to audit logs. Sentinel ingestion moves logs to a separate trust boundary. **Evidence:** ACL export on audit store; Sentinel workspace RBAC. | +| **AU-11 Audit Record Retention** | 🤝 | O, D | `C.5.7.42` | Organization-defined; **DOES recommendation: 1 year online, 3 years archived** (align to DOES records schedule — `[TBD]`). **Evidence:** written retention policy; archive location and format. | +| **AU-12 Audit Record Generation** | 📝 | O | `C.5.7.39`, `C.5.6.9` #17, #18 | Automated audit trails for all system components; system-generated security audit trail; SANS Information Logging Standard compliance. **Evidence:** component inventory × logging coverage table. | +| **AU-14 Session Audit** | 📝 | O | `C.5.6.9` #5, #7 | Searchable log of all screens accessed by user; sensitive-data screen access monitored and recorded. **Evidence:** search-tool demo; log sample. | + +### CA — Assessment, Authorization, and Monitoring + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **CA-1 Policy and Procedures** | 📋 | D | | DOES ATO governance. **Evidence:** policy. | +| **CA-2 Control Assessments** | 📋 | D | | Independent assessment (SCA) prior to ATO; annual reassessment. **Evidence:** SCA report. | +| **CA-2(1) Independent Assessors** | 📋 | D | | Independent from DOES OIT delivery team. **Evidence:** engagement letter. | +| **CA-3 Information Exchange** | 🤝 | O, D | `C.5.6.3`, `C.5.6.4` | ISAs/MOUs per SSP §11 (SSA, OSSE, CFSA, DC MAR, payroll vendor, LMS vendor, DC OCTO Sentinel, NOC). **Evidence:** executed ISA/MOU inventory. | +| **CA-5 Plan of Action and Milestones (POA&M)** | 📋 | D | | Maintained as `ypms/POAM.md`. This document's ⚠️ tailoring rows and ❓ open items seed the initial POA&M. **Evidence:** POA&M with monthly review cadence. | +| **CA-6 Authorization** | 📋 | D | | AO decision required pre-Go-Live. **Evidence:** signed ATO letter. | +| **CA-7 Continuous Monitoring** | 🤝 | O, D | | SSP §15 defines cadence. **Evidence:** monthly monitoring reports. | +| **CA-8 Penetration Testing** | 📝 | O (supports), D (commissions) | | Annually and after major releases (`YPMS-POAM-061`). **Evidence:** pentest report + remediation POA&M items. | +| **CA-9 Internal System Connections** | 📝 | O | | Documented internal component connections. **Evidence:** component-connection register. | + +### CM — Configuration Management + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **CM-1 Policy and Procedures** | 📋 | D | | DOES CM policy. **Evidence:** policy. | +| **CM-2 Baseline Configuration** | 📝 | O | `C.5.6.13`, IEEE 828-2012 | Application baseline in the repo (Dockerfile / compose / IaC); DOES-approved tool/software list. **Evidence:** baseline files in `ypms/`; CM plan (see CM-9). | +| **CM-2(2) Automation Support for Accuracy and Currency** | 📝 | O | | IaC (Bicep or Terraform) maintains Azure baseline. **Evidence:** tool inventory; IaC repo path. | +| **CM-2(3) Retention of Previous Configurations** | 📝 | O | | Rollback-capable baseline history via git. **Evidence:** git log. | +| **CM-3 Configuration Change Control** | 🤝 | O, D | `C.5.6.13`, `C.5.6.17` | DOES CIO approves changes; 30-day advance notice for maintenance windows; NOC coordination; emergency-change track. **Evidence:** change-record register; monthly change-review minutes. | +| **CM-4 Impact Analysis** | 📝 | O | `C.5.8.12` | Required before database migrations affecting programs already in production. **Evidence:** impact-analysis template + sample; migration review discipline. | +| **CM-5 Access Restrictions for Change** | 📝 | O | | Only DOES OIT delivery leads have merge rights on `main`; branch protection + code review required. **Evidence:** git branch-protection settings; Entra group ACL. | +| **CM-6 Configuration Settings** | 📝 | O | `C.5.6.5`, `C.5.6.6`, `C.5.6.7` | Admin-configurable security controls; CA configuration; DB/space/performance configuration. DOES OIT establishes secure baseline (CIS Azure Foundations benchmark + DOES overlays). **Evidence:** baseline settings export; Azure Policy assignment. | +| **CM-7 Least Functionality** | 📝 | O | | Unused features disabled. **Evidence:** enabled-feature inventory. | +| **CM-7(1) Periodic Review** | 📝 | O | | Quarterly review of enabled features. **Evidence:** review record. | +| **CM-8 System Component Inventory** | 📝 | O | `C.5.6.13` | Comprehensive tool/software list with licensing and upgrade path. **Evidence:** SBOM (CycloneDX, per release, from CI) + tool inventory. | +| **CM-8(1) Updates During Installation and Removal** | 📝 | O | | Inventory auto-updated via CI pipeline. **Evidence:** tooling. | +| **CM-9 Configuration Management Plan** | 📝 | O | | `ypms/CONFIGURATION_MANAGEMENT_PLAN.md` (to be authored; also serves source RFP §C.5.12 Change Management Plan). **Evidence:** signed plan. | +| **CM-10 Software Usage Restrictions** | 📋 | D | `C.5.6.13` | DOES-approved software list; license terms respected. **Evidence:** approved-software list. | +| **CM-11 User-Installed Software** | 📋 | D | | End-user installation prohibited on managed endpoints (DOES OCTO endpoint policy). **Evidence:** MDM policy. | + +### CP — Contingency Planning + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **CP-1 Policy and Procedures** | 📋 | D | | DOES contingency policy. **Evidence:** policy. | +| **CP-2 Contingency Plan** | 🤝 | O, D | `C.5.6.17`, `C.5.6.13` | `ypms/CONTINGENCY_PLAN.md` (to be authored). RTO/RPO envelope set by 99.5% SLA; failover-during-patching required. **Evidence:** signed plan. | +| **CP-2(1) Coordinate with Related Plans** | 🤝 | O, D | | Aligned with DOES BC/DR, DC OCTO enterprise plans, and payroll-vendor continuity plan. **Evidence:** cross-reference matrix. | +| **CP-2(3) Resume Mission and Business Functions** | 🤝 | O, D | | Recovery within SLA. **Evidence:** test results. | +| **CP-3 Contingency Training** | 🤝 | O, D | | Role-based CP training. **Evidence:** completion records. | +| **CP-4 Contingency Plan Testing** | 🤝 | O, D | | Annual tabletop + functional element (failover exercise). **Evidence:** exercise report. | +| **CP-4(1) Coordinate with Related Plans** | 🤝 | O, D | | Joint test with payroll vendor and DC OCTO. **Evidence:** joint after-action. | +| **CP-6 Alternate Storage Site** | 🔵 | I | | Inherited from Azure Government (geo-redundant storage / paired region). **Evidence:** Azure FedRAMP High artifact. | +| **CP-6(1) Separation from Primary Site** | 🔵 | I | | Inherited. | +| **CP-7 Alternate Processing Site** | 🔵 | I | `C.5.6.18`, `C.5.6.29` | Redundant multi-tier architecture with paired-region failover. **Evidence:** architecture doc; failover test. | +| **CP-9 System Backup** | 📝 | O | `C.5.8.14`, `C.5.8.21` | Azure Backup with daily cadence; documented backup and restore procedures. **Evidence:** backup schedule, restore-drill result (`YPMS-POAM-044`). | +| **CP-9(1) Testing for Reliability and Integrity** | 📝 | O | | Annual restore drill. **Evidence:** drill report. | +| **CP-10 System Recovery and Reconstitution** | 📝 | O | | Documented reconstitution runbook. **Evidence:** runbook. | + +### IA — Identification and Authentication + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **IA-1 Policy and Procedures** | 📋 | D | | DOES identity policy. **Evidence:** policy. | +| **IA-2 Identification and Authentication (Organizational Users)** | 📝 | O | `C.5.7.38`, `C.5.7.36` | Unique user ID per user; admin actions tied to individual identity. **Evidence:** IdP integration record. | +| **IA-2(1) MFA to Privileged Accounts** | ⚠️ | O | `C.5.7.6` | Source RFP `C.5.7.6` permits "unique identifier + shared secret answer" — **insufficient by NIST 800-63B AAL2**. **SSP tailors above the source RFP: MFA required for all privileged and staff accounts** via Entra ID conditional access. **Evidence:** Entra CA policy export; sample log showing MFA challenge (`YPMS-POAM-030`). | +| **IA-2(2) MFA to Non-Privileged Accounts** | ⚠️ | O | | Same tailoring: MFA for all staff-role accounts. **Evidence:** as IA-2(1). | +| **IA-2(8) Access to Accounts — Replay Resistant** | 📝 | O | | Modern MFA protocols. **Evidence:** protocol inventory. | +| **IA-2(12) Acceptance of PIV Credentials** | 📋 | D | | DC OCTO enterprise: no PIV in scope; DOES employee credentials via DOES SSO. **Evidence:** IdP config. | +| **IA-3 Device Identification and Authentication** | 📝 | O | | Device certificates for managed endpoints. **Evidence:** MDM cert deployment. | +| **IA-4 Identifier Management** | 📝 | O | `C.5.7.7`, `C.5.7.38`, `C.5.7.47` | 12-alphanumeric minimum; unique per user; no re-issue of deleted IDs. **Evidence:** IdP configuration; audit sample. | +| **IA-5 Authenticator Management** | 📝 | O | `C.5.7.8`, `C.5.7.12`, `C.5.7.13`, `C.5.7.14`, `C.5.7.45`, `C.5.7.46` | User-established and changeable passwords; admin reset with forced change; expiration; email/SMS notification on change; complexity/reuse/length policy; masked entry. **Evidence:** password-policy configuration; user-communication template. | +| **IA-5(1) Password-Based Authentication** | 📝 | O | `C.5.7.9`, `C.5.7.45` | FIPS 140-2 crypto (SSP tailors to FIPS 140-3 forward alignment); policy per RFP. **Evidence:** cryptographic-module cert; policy document. | +| **IA-6 Authenticator Feedback** | 📝 | O | `C.5.7.46` | Masked password entry. **Evidence:** UI walkthrough. | +| **IA-7 Cryptographic Module Authentication** | 📝 | O | `C.5.7.9` | FIPS 140-2 validated modules (SSP tailors: FIPS 140-3 where available). **Evidence:** module cert; usage inventory. | +| **IA-8 Identification and Authentication (Non-Organizational Users)** | ❓ | O | `C.5.3.2`, `C.5.7.30` | Youth and host authentication; LDAP-compliant; social-media login option. **Open decision (SSP §17.D):** identity model for minors — recommend social-media login for browsing/pre-application only, with IAL2-equivalent identity proofing (Login.gov or SSA verification) before banking/payroll actions. **Evidence:** identity-flow design; risk-acceptance memo. | +| **IA-11 Re-authentication** | 📝 | O | `C.5.7.3` | On session timeout; SSP tailors: also on privilege elevation and sensitive-action (banking change, eligibility change, payroll approval). **Evidence:** flow diagrams. | +| **IA-12 Identity Proofing** | ⚠️ | O | | RFP silent; SSP requires IAL2 equivalent for payroll-eligible actions. **Evidence:** identity-proofing design; vendor selection (Login.gov / SSA). | +| **IA-12(2) Identity Evidence** | 📝 | O | | Documentary evidence collected during proofing. **Evidence:** proofing runbook. | +| **IA-12(5) Address Confirmation** | 📝 | O | `C.5.6.3.d`, `C.5.6.2` | DC MAR address validation. **Evidence:** integration record. | + +### IR — Incident Response + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **IR-1 Policy and Procedures** | 📋 | D | | DOES / DC OCTO CISO IR policy. **Evidence:** policy. | +| **IR-2 Incident Response Training** | 🤝 | O, D | | DOES OIT and DC OCTO CISO IR-role training. **Evidence:** completion records. | +| **IR-3 Incident Response Testing** | 🤝 | O, D | | Annual IR exercise. **Evidence:** exercise report. | +| **IR-4 Incident Handling** | 🤝 | O, D | `C.5.7.26`, `C.5.6.9` #19 | `ypms/INCIDENT_RESPONSE_PLAN.md`. DOES OIT IDS/IPS + Sentinel feed the pipeline. **Evidence:** signed IRP; playbooks. | +| **IR-4(1) Automated Incident Handling Processes** | 📝 | O | `C.5.6.9` #21–23 | Alerts on business-rule/workflow thresholds and account lockouts. **Evidence:** playbook automation. | +| **IR-5 Incident Monitoring** | 🤝 | O, D | | SIEM + SOC monitoring. **Evidence:** monitoring dashboard. | +| **IR-6 Incident Reporting** | 🤝 | O, D | `C.5.8.18`, `C.5.8.19`, `C.5.8.20` | **Immediate** notification of unauthorized disclosure through DOES OIT → DC OCTO CISO; **24-hour** disclosure report; **2-business-day** remediation report. Plus federal-agency notification for SSA/OSSE/CFSA exchanges per each agreement. **Evidence:** SLA in internal policy; notification-template inventory. | +| **IR-7 Incident Response Assistance** | 📝 | O | | DOES OIT on-call rotation. **Evidence:** on-call roster. | +| **IR-8 Incident Response Plan** | 📋 | D | | `ypms/INCIDENT_RESPONSE_PLAN.md`. **Evidence:** signed plan. | + +### MA — Maintenance + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **MA-1 Policy and Procedures** | 📋 | D | | DOES maintenance policy. **Evidence:** policy. | +| **MA-2 Controlled Maintenance** | 📝 | O | `C.5.6.17` | 30-day advance notice for maintenance windows; NOC coordination. **Evidence:** maintenance-window log. | +| **MA-3 Maintenance Tools** | 🤝 | O, D | | Approved-tools list. **Evidence:** tool inventory. | +| **MA-4 Nonlocal Maintenance** | 📝 | O | | Remote maintenance via MFA + audited channels. **Evidence:** access-method design. | +| **MA-5 Maintenance Personnel** | 🤝 | O, D | `C.5.8.16`, `C.5.8.17` | DOES OIT roster of personnel with production data access, refreshed at least quarterly. **Evidence:** access roster. | +| **MA-6 Timely Maintenance** | 📝 | O | `C.5.6.13` | DOES OIT patch cadence; failover during patching. **Evidence:** patch-window log. | + +### MP — Media Protection + +*No physical media in the target architecture. Endpoint media controls inherited from DC OCTO endpoint program for DOES-managed devices; storage media controls inherited from Azure Government.* + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **MP-1 Policy and Procedures** | 🔵 | I | | DC OCTO endpoint policy. **Evidence:** policy. | +| **MP-2 Media Access** | 🔵 | I | | DC OCTO endpoint policy. | +| **MP-3 Media Marking** | 🔵 | I | | N/A — no removable media in scope. | +| **MP-4 Media Storage** | 🔵 | I | | DC OCTO endpoint policy. | +| **MP-6 Media Sanitization** | 🔵 | I | | Inherited from Azure Government. **Evidence:** Azure FedRAMP High artifact. | +| **MP-7 Media Use** | 🔵 | I | | DC OCTO endpoint policy. | + +### PE — Physical and Environmental Protection + +*Fully inherited from Azure Government FedRAMP High authorization for hosted components; DC OCTO endpoint program for DOES-managed devices.* + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **PE-1 Policy and Procedures** | 🔵 | I | | Inherited. | +| **PE-2 Physical Access Authorizations** | 🔵 | I | | Inherited. | +| **PE-3 Physical Access Control** | 🔵 | I | | Inherited. | +| **PE-4 Access Control for Transmission** | 🔵 | I | | Inherited. | +| **PE-5 Access Control for Output Devices** | 🔵 | I | | Inherited. | +| **PE-6 Monitoring Physical Access** | 🔵 | I | | Inherited. | +| **PE-8 Visitor Access Records** | 🔵 | I | | Inherited. | +| **PE-9 Power Equipment and Cabling** | 🔵 | I | | Inherited. | +| **PE-10 Emergency Shutoff** | 🔵 | I | | Inherited. | +| **PE-11 Emergency Power** | 🔵 | I | | Inherited. | +| **PE-12 Emergency Lighting** | 🔵 | I | | Inherited. | +| **PE-13 Fire Protection** | 🔵 | I | | Inherited. | +| **PE-14 Environmental Controls** | 🔵 | I | | Inherited. | +| **PE-15 Water Damage Protection** | 🔵 | I | | Inherited. | +| **PE-16 Delivery and Removal** | 🔵 | I | | Inherited. | +| **PE-17 Alternate Work Site** | 🔵 | I | | Inherited (DC OCTO remote-work policy for DOES staff). | + +**Evidence for PE family:** Microsoft Azure Government SSP (referenced), FedRAMP High authorization letter, and Customer Responsibility Matrix showing PE-family inheritance. + +### PL — Planning + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **PL-1 Policy and Procedures** | 📋 | D | | DOES planning policy. | +| **PL-2 System Security and Privacy Plan** | 📝 | D | | `ypms/SYSTEM_SECURITY_PLAN.md`. | +| **PL-4 Rules of Behavior** | 📋 | D | | `ypms/RULES_OF_BEHAVIOR.md` with variants for staff, host, youth/parent. | +| **PL-4(1) Social Media and External Site Restrictions** | 📋 | D | | Include in RoB. | +| **PL-8 Security and Privacy Architecture** | 📝 | O | `C.5.5.5` | DOES OIT architecture document — `YPMS-POAM-040`. **Evidence:** signed architecture document in `ypms/`. | +| **PL-10 Baseline Selection** | 📋 | D | | Moderate baseline documented (SSP §2.3). | +| **PL-11 Baseline Tailoring** | 📋 | D | | Tailoring documented in this file (⚠️ rows). | + +### PM — Program Management + +*Organizational; DOES / DC OCTO CISO Office. Inheritance documented in DOES organization-wide security program plan (`[TBD]`).* + +| Control | Status | Owner | Implementation & Evidence | +|---|---|---|---| +| **PM-1 Information Security Program Plan** | 📋 | D | DOES ISPP. | +| **PM-2 Information Security Program Leadership Role** | 📋 | D | DOES CIO / ISSO. | +| **PM-3 Information Security and Privacy Resources** | 📋 | D | Budget planning. | +| **PM-4 POA&M Process** | 📋 | D | Enterprise POA&M process. | +| **PM-5 System Inventory** | 📋 | D | DC OCTO system inventory. | +| **PM-6 Measures of Performance** | 📋 | D | Enterprise metrics program. | +| **PM-7 Enterprise Architecture** | 📋 | D | DC OCTO enterprise architecture. | +| **PM-8 Critical Infrastructure Plan** | 📋 | D | DC infrastructure plan. | +| **PM-9 Risk Management Strategy** | 📋 | D | DOES risk-management strategy. | +| **PM-10 Authorization Process** | 📋 | D | DOES / DC OCTO authorization process. | +| **PM-11 Mission and Business Process Definition** | 📋 | D | OYP mission documentation. | +| **PM-14 Testing, Training, and Monitoring** | 📋 | D | Enterprise T&T program. | + +### PS — Personnel Security + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **PS-1 Policy and Procedures** | 📋 | D | | DOES personnel-security policy. | +| **PS-2 Position Risk Designation** | 📋 | D | | DOES HR position risk designation. | +| **PS-3 Personnel Screening** | 🤝 | O, D | | DOES HR for staff and any contracted individual developers; DC OCTO clearance requirements apply. **Evidence:** background-check records. | +| **PS-4 Personnel Termination** | 🤝 | O, D | `C.5.8.17` | Access removed on termination; quarterly personnel-with-data-access roster review highlights deletions. **Evidence:** termination checklist; roster. | +| **PS-5 Personnel Transfer** | 🤝 | O, D | | Role-change access adjustment. **Evidence:** transfer checklist. | +| **PS-6 Access Agreements** | 🤝 | O, D | | RoB acknowledgment binding at onboarding and role change. **Evidence:** signed RoB records. | +| **PS-7 External Personnel Security** | 🤝 | O, D | `C.5.8.16`, `C.5.8.17` | Applies to any external (non-DOES-OIT) personnel granted YPMS data access — payroll vendor, LMS vendor, contracted individual developers. Quarterly personnel-with-data-access roster review flags external names. **Evidence:** roster. | +| **PS-8 Personnel Sanctions** | 📋 | D | | DOES HR sanction processes. **Evidence:** policy. | + +### PT — PII Processing and Transparency + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **PT-1 Policy and Procedures** | 📋 | D | | DOES privacy policy. | +| **PT-2 Authority to Process PII** | 📋 | D | | Documented in `ypms/PRIVACY_IMPACT_ASSESSMENT.md`. Legal basis: DC Code Title 32. | +| **PT-3 Personally Identifiable Information Processing Purposes** | 📋 | D | | Documented in PIA. | +| **PT-4 Consent** | 🤝 | O, D | | Consent flows for youth and parents; separate parental co-authentication under consideration. **Evidence:** consent-flow screens. | +| **PT-5 Privacy Notice** | 🤝 | O, D | `C.5.7.19` | Presented at first youth/host contact; language-access variants. **Evidence:** notice content on file. | +| **PT-6 System of Records Notice (SORN)** | ❓ | D | | Applicability review by DOES Privacy Officer. **Evidence:** privacy-officer determination memo. | +| **PT-7 Specific Categories of Personally Identifiable Information** | 📝 | O | | SSN, banking, FERPA-covered records, CFSA foster/ward status — enumerated in SSP §13 and enforced by role-based access. **Evidence:** data-classification register + ACL export. | + +### RA — Risk Assessment + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **RA-1 Policy and Procedures** | 📋 | D | | DOES RA policy. | +| **RA-2 Security Categorization** | 📋 | D | | `ypms/FIPS_199_MEMO.md`. | +| **RA-3 Risk Assessment** | 🤝 | O, D | | Initial RA before ATO; annually thereafter; on major change. **Evidence:** RA report. | +| **RA-3(1) Supply Chain Risk Assessment** | 📝 | O | | Third-party and fourth-party disclosure in architecture document. **Evidence:** SBOM + third/fourth-party register. | +| **RA-5 Vulnerability Monitoring and Scanning** | 📝 | O | `C.5.7.52` | Cyber-threat detection and remediation; authenticated and unauthenticated scans monthly; container image scans in CI on push (`YPMS-POAM-062`). **Evidence:** scan schedule + reports. | +| **RA-5(2) Update Vulnerabilities to be Scanned** | 📝 | O | | Feed updates. **Evidence:** feed configuration. | +| **RA-5(5) Privileged Access** | 📝 | O | | Authenticated scans with privileged access. **Evidence:** scan configuration. | +| **RA-7 Risk Response** | 📋 | D | | POA&M-driven. **Evidence:** POA&M. | +| **RA-9 Criticality Analysis** | 🤝 | O, D | | High-value components identified. **Evidence:** criticality register. | + +### SA — System and Services Acquisition + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **SA-1 Policy and Procedures** | 📋 | D | | DOES / DC OCP acquisition policy. | +| **SA-2 Allocation of Resources** | 📋 | D | | FY27 budget line. **Evidence:** budget approval. | +| **SA-3 System Development Life Cycle** | 📝 | O | `C.5.2` | Agile SDLC matching OWC and DCYWP patterns; discipline adopted from source RFP `C.5.2`. **Evidence:** SDLC document. | +| **SA-4 Acquisition Process** | 📋 | D | | Applies to third-party components (payroll, LMS, SaaS subcomponents). **Evidence:** procurement records + contracts. | +| **SA-4(1) Functional Properties of Controls** | 📝 | O | `C.5.7` (54 items) | Source RFP §C.5.7 catalogue is the functional-properties statement. **Evidence:** this document (Appendix C traceability). | +| **SA-4(2) Design and Implementation Information for Controls** | 📝 | O | | DOES OIT design docs describe how each control is implemented. **Evidence:** design docs in `ypms/`. | +| **SA-8 Security and Privacy Engineering Principles** | 📝 | O | | SSDLC adherence. **Evidence:** SSDLC document. | +| **SA-9 External System Services** | 📝 | O | `C.5.6.3` | Payroll, LMS, address verification, social-media IdPs, DC MAR — each with security assurance. **Evidence:** vendor register + SIG-Lite / SOC 2 collection. | +| **SA-10 Developer Configuration Management** | 📝 | O | `C.5.8.4`–`C.5.8.11` | Data-model deliverables (conceptual/logical/physical ERDs, data dictionary, integrity rules, CRUD matrix, denormalization rationale). **Evidence:** deliverables in `ypms/`. | +| **SA-11 Developer Testing and Evaluation** | 📝 | O | source RFP §C.5.10 | Unit / functional / non-functional / UAT with evidence. **Evidence:** test reports; CI test results. | +| **SA-15 Development Process, Standards, and Tools** | 📝 | O | | DOES OIT SSDLC standards. **Evidence:** SSDLC document. | +| **SA-22 Unsupported System Components** | 📝 | O | `C.5.6.13` | Third-party dependencies tracked in SBOM with upgrade path. **Evidence:** SBOM + upgrade-path statement. | + +### SC — System and Communications Protection + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **SC-1 Policy and Procedures** | 📝 | O | `C.5.7.53` | Aligned to DC OCTO IT security policy. **Evidence:** policy alignment memo. | +| **SC-4 Information in Shared System Resources** | 🔵 | I | | Inherited from IaaS. | +| **SC-5 Denial-of-Service Protection** | 📝 | O | | WAF + rate limiting on public endpoints. **Evidence:** config export. | +| **SC-7 Boundary Protection** | 📝 | O | `C.5.7.23` | Trusted/transition/untrusted zone segmentation. **Evidence:** architecture diagram + firewall rules. | +| **SC-7(3) Access Points** | 📝 | O | | Limited public ingress. **Evidence:** ingress inventory. | +| **SC-7(4) External Telecommunications Services** | 📝 | O | | Documented external services with ISAs. | +| **SC-7(5) Deny by Default / Allow by Exception** | 📝 | O | | Default-deny firewall posture. **Evidence:** ruleset export. | +| **SC-7(7) Split Tunneling for Remote Devices** | 📝 | O | | No split tunneling from managed devices. | +| **SC-8 Transmission Confidentiality and Integrity** | ⚠️ | O | `C.5.6.15`, `C.5.7.25`, `C.5.7.20` | Source RFP says SSL; **SSP tailors to TLS 1.2 minimum, TLS 1.3 preferred, FIPS-approved cipher suites**. All PII encrypted in transit. **Evidence:** SSL Labs–style report; TLS config (`YPMS-POAM-031`). | +| **SC-8(1) Cryptographic Protection** | 📝 | O | `C.5.7.9` | FIPS 140-2/-3 cryptography for transmission. **Evidence:** module cert. | +| **SC-10 Network Disconnect** | 📝 | O | `C.5.7.3` | Idle-session network disconnect. **Evidence:** timeout config. | +| **SC-12 Cryptographic Key Establishment and Management** | 📝 | O | `C.5.7.9` | Key management via Azure Key Vault (Gov / HSM). **Evidence:** key-management design; rotation policy (`YPMS-POAM-032`). | +| **SC-13 Cryptographic Protection** | 📝 | O | `C.5.7.9`, `C.5.7.25` | FIPS 140-3 cryptography (140-2 acceptable during deprecation window) at rest and in transit. **Evidence:** module cert + usage map. | +| **SC-15 Collaborative Computing Devices** | 📝 | O | | Camera/mic access disabled by default in workspace tooling. | +| **SC-17 Public Key Infrastructure Certificates** | 📝 | O | `C.5.6.5` | Certificate Authority configuration for integrations. **Evidence:** CA config. | +| **SC-18 Mobile Code** | 📝 | O | | Only signed mobile code allowed. | +| **SC-20 Secure Name/Address Resolution Service (Authoritative)** | 🔵 | I | | Inherited from IaaS. | +| **SC-21 Secure Name/Address Resolution Service (Recursive)** | 🔵 | I | | Inherited. | +| **SC-22 Architecture and Provisioning for Name/Address Resolution** | 🔵 | I | | Inherited. | +| **SC-23 Session Authenticity** | 📝 | O | `C.5.7.20` | Anti-CSRF, secure cookies, per-transaction integrity for financial actions. **Evidence:** session-management design. | +| **SC-28 Protection of Information at Rest** | 📝 | O | `C.5.7.25`, `C.5.7.50` | Encryption at rest for all PII (Postgres TDE + envelope encryption for blobs); SSN masked/anonymized in display (`YPMS-POAM-080`). **Evidence:** DB encryption config; SSN-handling design. | +| **SC-28(1) Cryptographic Protection** | 📝 | O | `C.5.7.9` | FIPS-approved cryptography for at-rest data via Azure Key Vault. **Evidence:** module cert. | +| **SC-39 Process Isolation** | 🔵 | I | | Inherited from IaaS + COTS platform. | + +### SI — System and Information Integrity + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **SI-1 Policy and Procedures** | 📝 | O | `C.5.7.53` | Aligned to DC OCTO IT security policy. | +| **SI-2 Flaw Remediation** | 📝 | O | `C.5.7.52`, `C.5.6.13` | Cyber-threat remediation; failover-during-patching. DOES OIT patch cadence: Critical within 15 days, High within 30. **Evidence:** patch SLA statement; patch-window log. | +| **SI-2(2) Automated Flaw Remediation Status** | 📝 | O | | Patch dashboard. | +| **SI-3 Malicious Code Protection** | 📝 | O | | Upload scanning for document uploads; endpoint AV on managed devices. **Evidence:** AV product + scan-on-upload config. | +| **SI-4 System Monitoring** | 📝 | O | `C.5.7.26`, `C.5.6.9` #19–23, `C.5.6.22` | IDS/IPS with alerts; Sentinel with configurable aggregation and business-rule alerts; performance monitoring. **Evidence:** monitoring inventory (`YPMS-POAM-043`). | +| **SI-4(2) Automated Tools for Real-Time Analysis** | 📝 | O | `C.5.6.9` #19 | Sentinel. **Evidence:** workspace record. | +| **SI-4(4) Inbound and Outbound Communications Traffic** | 📝 | O | | Network monitoring. **Evidence:** monitoring dashboard. | +| **SI-4(5) System-Generated Alerts** | 📝 | O | `C.5.6.9` #21–23 | Alerts on thresholds and lockouts. | +| **SI-5 Security Alerts, Advisories, and Directives** | 📝 | O | | DOES OIT subscribes to relevant advisory feeds (CISA, Microsoft Security Response Center, NIST NVD). | +| **SI-7 Software, Firmware, and Information Integrity** | 📝 | O | | Signed artifacts + integrity checks on deploy. | +| **SI-7(1) Integrity Checks** | 📝 | O | | On startup and periodically. | +| **SI-8 Spam Protection** | 🤝 | O, D | | Inbound-email spam protection at DOES enterprise level. | +| **SI-10 Information Input Validation** | 📝 | O | `C.5.7.44`, `C.5.6.2`, `C.5.6.3.b`, `C.5.6.3.d` | Character set / length / numerical range / format / content validation with trusted-source restriction; address, age, residency data checks; SSA SSN verification; DC MAR address validation. **Evidence:** input-validation rules; sample validation-failure log. | +| **SI-11 Error Handling** | 📝 | O | `C.5.7.43`, `C.5.6.9` #2, #3 | Corrective information without adversary-exploitable disclosure; consistent error handling; all errors logged. **Evidence:** error-response inventory. | +| **SI-12 Information Management and Retention** | 🤝 | O, D | | Aligned with DOES records schedule. **Evidence:** retention policy. | +| **SI-16 Memory Protection** | 🔵 | I | | Inherited from IaaS / OS. | + +### SR — Supply Chain Risk Management + +| Control | Status | Owner | RFP Ref | Implementation & Evidence | +|---|---|---|---|---| +| **SR-1 Policy and Procedures** | 📋 | D | | DOES / DC OCTO supply-chain policy. | +| **SR-2 Supply Chain Risk Management Plan** | 🤝 | O, D | | SCRM plan referencing third-party components (payroll, LMS, DC MAR, IdPs) and open-source dependencies. **Evidence:** SCRM plan. | +| **SR-2(1) Establish SCRM Team** | 📋 | D | | DOES SCRM POC assigned. | +| **SR-3 Supply Chain Controls and Processes** | 📝 | O | `C.5.6.13` | Approved-software list; upgrade path. **Evidence:** approved list. | +| **SR-5 Acquisition Strategies, Tools, and Methods** | 📋 | D | | Applies to third-party components DOES procures. | +| **SR-6 Supplier Assessments and Reviews** | 🤝 | O, D | | Vendor and fourth-party disclosure and review. **Evidence:** vendor register. | +| **SR-8 Notification Agreements** | 🤝 | O, D | `C.5.8.18`–`C.5.8.20` | Breach-notification clauses flowed down to payroll / LMS / SaaS contracts. **Evidence:** contract clauses. | +| **SR-10 Inspection of Systems or Components** | 📝 | O | | DOES right-to-inspect provision in vendor contracts. | +| **SR-11 Component Authenticity** | 📝 | O | | Signed artifacts + provenance; CI enforces signature check on deploy. **Evidence:** SBOM + signing infrastructure. | + +--- + +## 5. Tailorings and open items summary + +### ⚠️ SSP tailorings above the source-RFP floor + +| Ref | Source-RFP wording | SSP tailoring | Rationale | POA&M | +|---|---|---|---|---| +| SC-8 / AC-17(2) | `C.5.6.15` says "SSL" | TLS 1.2 minimum, TLS 1.3 preferred, FIPS-approved suites | SSL is deprecated; SSL Labs shows real vulnerabilities in any SSL version | `YPMS-POAM-031` | +| IA-2(1)/(2) | `C.5.7.6` says "unique identifier + shared secret answer" | MFA required for all privileged and staff accounts | NIST 800-63B AAL2 minimum for staff-role accounts in a Moderate system | `YPMS-POAM-030` | +| IA-7 / SC-12 / SC-13 | `C.5.7.9` says FIPS 140-2 | FIPS 140-3 where available; 140-2 acceptable during deprecation window | 140-2 is sunset for new validations | `YPMS-POAM-032` | +| IA-12 | Source RFP silent | IAL2-equivalent identity proofing for youth before payroll actions | Minors' PII + banking + SSN requires proofing above social-media assertion | `YPMS-POAM-033` | + +### ❓ Open decisions (mirrored to SSP Appendix D) + +| Ref | Question | Owner | POA&M | +|---|---|---|---| +| Stack | Python/FastAPI (OWC alignment) or Node/Express (DCYWP alignment) | DOES CIO | `YPMS-POAM-040` | +| Level 3 security | What is "Level 3 security" in source RFP `C.5.7.24`? | AO | `YPMS-POAM-051` | +| IA-8 | Identity model for minors — social-media login scope vs. full proofing before payroll | AO / DOES CIO / OYP | `YPMS-POAM-050` | +| PCI DSS scope | Is any card processing actually in scope? | OYP + procurement | `YPMS-POAM-052` | +| Health-record CSV | In-boundary steady state, or emergency-scoped extension? | AO + Privacy Officer | `YPMS-POAM-053` | +| Retention | Records schedule for audit logs, case records, backups | DOES records officer | `YPMS-POAM-054` | + +### 📋 DOES-authored companion artifacts (path from this doc) + +- [`SYSTEM_SECURITY_PLAN.md`](SYSTEM_SECURITY_PLAN.md) — this document's parent +- `ypms/FIPS_199_MEMO.md` — to be authored +- `ypms/PRIVACY_IMPACT_ASSESSMENT.md` — to be authored +- `ypms/INCIDENT_RESPONSE_PLAN.md` — to be authored +- `ypms/CONTINGENCY_PLAN.md` — to be authored +- `ypms/RULES_OF_BEHAVIOR.md` — to be authored +- `ypms/POAM.md` — to be authored; seeded by ⚠️ tailorings and ❓ open items above + +--- + +**End of draft v0.2 (in-house build reframe).** diff --git a/OLA_RESPONSE_2026-09-30.md b/OLA_RESPONSE_2026-09-30.md new file mode 100644 index 0000000..6e81042 --- /dev/null +++ b/OLA_RESPONSE_2026-09-30.md @@ -0,0 +1,58 @@ +# YPMS — OLA Questions Response + +**Re:** Modernization of the Marion Barry Summer Youth Employment Program Web-Based Data Management System (YPMS) — DOES Strategic Initiative FY27 +**Prepared for:** OLA / City Administrator +**Date:** 2026-09-30 + +--- + +## 1. What data will populate in this system? + +Applicant and participant records (youth, hosts/employers, parents/guardians, DOES staff) including: + +- **Identity:** name, DOB, address, phone/email, parent/guardian contact +- **SSN** (for SSA cross-match; masked in display) +- **Education:** school enrollment status ingested from OSSE +- **Eligibility:** age, residency (validated against DC MAR), foster/ward-of-state flag from CFSA +- **Program participation:** applications, certifications, orientation completion, enrollments, job matches, worksite assignments +- **Employment:** hours worked, resumes, job preferences +- **Financial:** banking for direct-deposit payroll, tax info, W-2/1099 records via the third-party payroll integration +- **Operational:** host/employer registrations, worksites, job postings, transportation vouchers, communications, audit logs + +## 2. How much of this data will be provided to the public? + +Very little. The public surface is limited to available programs and dates, host-employer job postings, application forms, static help and training content, and aggregate program information. No individual PII is exposed publicly. Press and public reporting uses de-identified counts; FOIA responses go through DOES OGC with PII redacted. + +## 3. Will the system contain information on students served across fiscal years, broken out by sub-programs? + +Yes. The system tracks program details year-over-year and supports each OYP sub-program as a first-class object — MBSYEP, HSIP, MBYLI (SIT / School Year / Global Education), CRESP, and any future OYP program. Reporting is in scope; MicroStrategy (the current reporting tool) is one of the legacy components YPMS replaces. Historical participant data with sub-program breakdowns is retained per DOES records schedule. + +## 4. Is there something similar for other workforce programs at DOES? + +Partially, but nothing consolidated the way YPMS will be: + +- **Adult unemployment insurance:** UIBS — being modernized separately. +- **Adult workforce services:** Geographic Solutions' Virtual One-Stop (VOS). +- **Workers' compensation:** OWC — a separate DOES modernization on its own ATO path. +- **Youth today:** fragmented across seven legacy tools (Host/Participant Application, Scanning, Transfer, TMS timekeeping, MicroStrategy, PF3 admin backdoor, manual payroll scripts) — YPMS consolidates these. + +YPMS is the youth-specific consolidation; it doesn't replace anything on the adult side. + +## 5. Will the system house SYEP participants' personal information — addresses, SSN, banking, etc. — and are there privacy concerns? + +Yes. YPMS will store address, SSN, DOB, banking for direct-deposit payroll, tax info, parent/guardian contact, school records (FERPA-covered, from OSSE), foster/ward status (from CFSA), and — under emergency scenarios — health records. + +Privacy concerns and how they are addressed: + +| Concern | Mitigation | +|---|---| +| Population is primarily minors — heightened stewardship required | Strict role-based access; data minimization by reusing eligibility across programs; parental co-authentication under consideration | +| SSN is a high-value identity-theft target | Masked/anonymized in display; encrypted at rest and in transit using FIPS-validated cryptography | +| Banking data | Encrypted; passed to the third-party payroll vendor via secured integration; payroll processing itself lives outside YPMS | +| School records (OSSE) | Handled under FERPA; requires a formal DOES–OSSE data-sharing agreement | +| Foster/ward status (CFSA) | Confidential under DC Code Title 4; access limited on need-to-know | +| Detection and response | IDS/IPS and SIEM required; unauthorized disclosures are reported immediately through the DOES OIT → DC OCTO CISO chain, with a full internal report within 24 hours and a remediation plan within 2 business days | +| Assurance baseline | NIST 800-53 Moderate; DC OCTO IT policies; SSA electronic exchange requirements | +| Records-access oversight | DOES OIT maintains and reviews a full list of personnel with data access, updated at least quarterly with additions and deletions tracked | + +**Open questions flagged for the AO:** whether social-media login is acceptable for minors without full identity proofing before payroll actions, and treatment of the dormant health-record ingest path. YPMS will be built in-house by DOES OIT and hosted on Azure Government, matching the OWC and Employer 360 posture. diff --git a/OVERVIEW.md b/OVERVIEW.md new file mode 100644 index 0000000..fcca430 --- /dev/null +++ b/OVERVIEW.md @@ -0,0 +1,106 @@ +# YPMS — Overview + +**One line.** An in-house DOES OIT build that replaces seven legacy tools currently used by the Office of Youth Programs to run MBSYEP and related youth workforce programs. Matches the DCYWP / OWC / Employer 360 delivery pattern. + +## Why we're building it + +The current OYP system landscape is fragmented across seven tools that don't share data: + +| Legacy tool | Purpose | Fate under YPMS | +|---|---|---| +| Host/Participant Application | Program applications | Replaced by unified intake | +| Scanning Application | Certify application information | Replaced by in-line certification | +| Transfer Application | Place and transfer youth | Replaced by matching engine | +| TMS (Time Management System) | Youth time tracking | Replaced by online time management | +| MicroStrategy | Reporting and visualization | Replaced by native reporting + BI | +| PF3 (People First backdoor) | Admin login tool for host-app edits | Replaced by RBAC admin functions | +| Manual payroll (scripts + email approvals) | Payroll processing | Replaced by third-party payroll vendor integration | + +Consolidating these into a single DOES-owned system is the substance of the modernization. + +## Programs served + +| Program | Population | Notes | +|---|---|---| +| **MBSYEP** — Marion S. Barry Summer Youth Employment Program | Youth ages 14–24 | Locally funded; highest peak-load driver; hard summer deadlines | +| **HSIP** — High School Internship Program | Grades 9–12 | School-year enrichment and internships | +| **MBYLI** — Marion Barry Youth Leadership Institute | Year-round | Includes Summer Intensive Training (SIT), School Year Program (SYP), Global Education | +| **CRESP** — Career Ready Early Scholars Program | Middle-school students | 11 career-exploration tracks (STEM, culinary, law/global affairs, etc.) | +| Future OYP programs | — | System must accept new program definitions end-to-end (application → completion) | + +## User populations + +| User | Estimate | Access | +|---|---|---| +| DOES staff, contractors, vendors | ~90 | Internal portal, SSO / DOES global directory | +| Host employers | ~1,500 | Self-service web portal | +| Youth (registering + participating) | ~27,000 | Web / mobile; identity model under review — see CLAUDE.md open question 3 | +| Parents / guardians | ~7,400 | Web portal | +| Other agencies | ~100 | Web portal or interconnection | +| **Total** | **~36,000** | Scale target: 50%/year growth | + +## Integrations + +| Partner | Purpose | Notes | +|---|---|---| +| SSA (Business Services Online) | SSN verification, wage data | SSA electronic-exchange requirements apply | +| OSSE | School enrollment records | FERPA — data-sharing agreement required | +| CFSA | Foster / ward-of-state status | DC Code Title 4 — MOU required | +| DC MAR | Address verification | DC OCTO service | +| Third-party payroll vendor | Time → payroll → tax forms | Vendor selection outstanding; DOES OIT owns the integration on our side | +| Third-party LMS | Orientation completion tracking | Vendor TBD | +| DC OCTO Sentinel | Security telemetry (SIEM stream) | Same pattern as OWC | +| Social media IdPs | Youth account login | Risk-managed; not sufficient for payroll actions on its own | + +## Delivery model + +DOES OIT builds and operates the system. **Stack: Python 3.12 / FastAPI / SQLAlchemy / Postgres**, aligned with OWC. Hosting is Azure Government Cloud, matching OWC and Employer 360. Continuous monitoring runs into DC OCTO Sentinel. + +## Timeline (as of 2026-09-30) + +| Milestone | Target | Status | +|---|---|---| +| Source requirements captured (from prior YPMS RFP) | 2025-04 | Done | +| ISSO and AO designated in writing | 2026-09-30 | ✓ Chris Tonjes (DOES CIO) as System Owner, ISSO, and AO | +| Stack decision recorded | 2026-09-30 | ✓ Python 3.12 / FastAPI / SQLAlchemy / Postgres (OWC alignment) | +| FIPS 199 memo signed by AO | 2026-10-31 | Not started (`YPMS-POAM-001`) | +| Architecture document | 2026-11-30 | Not started (see `YPMS-POAM-040` follow-on) | +| Azure Gov tenant + non-prod environments | 2027-01-15 | Not started (`YPMS-POAM-041`) | +| CI/CD pipeline with SAST/SCA/SBOM | 2027-01-31 | Not started (`YPMS-POAM-042`) | +| Data-sharing agreements (OSSE, CFSA, SSA, payroll vendor) | Q1 2027 | Not started (`YPMS-POAM-020` – `YPMS-POAM-023`) | +| ATO artifacts (SSP, PIA, IRP, CP, RoB, control mapping) | Q4 2026 – Q1 2027 | Draft SSP v0.2, control mapping v0.1, POA&M v0.1 | +| Iterative build (Agile — matches OWC / DCYWP delivery cadence) | 2027 | Not started | +| Independent Control Assessment (SCA) | Pre-Go-Live | Not scheduled | +| Penetration test | Pre-Go-Live | Not scheduled | +| ATO decision | Pre-Go-Live | Not scheduled | +| **Go-Live** | Beginning of FY2027 per source RFP; effective slip acknowledged | Not started | + +## Compliance posture + +- **NIST SP 800-53 Rev. 5 Moderate baseline.** +- **NIST SP 800-171 Rev. 2** for CUI handling. +- **FIPS 140-3** target (140-2 acceptable during the deprecation window). +- **FERPA** overlay for OSSE-sourced educational records. +- **DC Code Title 4** for CFSA-sourced foster/ward records. +- **SSA Electronic Information Exchange** requirements for SSN cross-match. +- **Section 508 / WCAG 2.1 AA**. +- **DC Language Access Act of 2004**. +- **PCI DSS** — only if card processing is in scope (probably not). +- **DC OCTO IT Security Policy**. + +## FIPS 199 (provisional) + +**Moderate / Moderate / Moderate**, with High-sensitivity data subsets (FERPA OSSE records, CFSA foster/ward flags, dormant COVID-era health records) treated by role-based least privilege rather than by pulling the aggregate rating up. The AO's FIPS 199 memo (`YPMS-POAM-001`) formalizes this. + +## What good looks like at Go-Live + +- Single youth portal from application through payroll for all OYP programs. +- One host/employer portal. +- One staff workspace replacing PF3 and the various admin tools. +- Payroll runs off online time-tracking, not scripts and emails. +- Reports run natively; MicroStrategy retired. +- ATO signed by the DOES Director before production data flows in. +- OSSE and CFSA exchanges in place with executed agreements. +- Sentinel receiving telemetry via DC OCTO. +- Daily backups running with tested restore. +- POA&M managed and reviewed monthly. diff --git a/PHASE0_PLAN.md b/PHASE0_PLAN.md new file mode 100644 index 0000000..4cb707e --- /dev/null +++ b/PHASE0_PLAN.md @@ -0,0 +1,291 @@ +# YPMS — Phase 0 Plan + +**Phase:** 0 — Foundations (runnable local skeleton) +**Depends on:** `ARCHITECTURE.md` v0.1, `SYSTEM_SECURITY_PLAN.md` v0.3, POA&M v0.1 +**Stack:** Python 3.12 · FastAPI · SQLAlchemy 2.x · Alembic · Postgres 16 (SQLite in tests) · Docker Compose · pytest — matches OWC +**No frontend.** Phase 0 is API + minimal admin shell. Public portal is Phase 1+. + +--- + +## 1. Phase 0 scope + +Phase 0 delivers a runnable local repo that every future phase bolts onto. It does **not** implement domain logic (eligibility rules, matching, timekeeping, payroll, integrations) — that's Phase 1+. + +### In scope + +| Area | What ships | +|---|---| +| **Repo scaffold** | Monorepo layout matching [`ARCHITECTURE.md`](ARCHITECTURE.md) §5.1: `src/ypms/`, `tests/`, `migrations/`, `docs/`. `pyproject.toml`, `Dockerfile`, `docker-compose.yml`, `alembic.ini`, `.env.example`. `docker compose up` boots app + Postgres. | +| **Framework vendor-in** | Copy OWC `framework/` and `security/` modules into `src/ypms/framework/` and `src/ypms/security/`. Header comment names the OWC commit; if a YPMS-specific tweak is needed it stays in YPMS's copy and does not flow back. | +| **Config, logging, health** | `pydantic-settings`-based config, structured JSON logging (sensitive-field sanitizer per ARCH §10.1), `/healthz` and `/readyz`. | +| **Auth** | Local username + password (pbkdf2_sha256) + JWT. `iam.assurance_level` claim issued at authentication time (§4 of ARCH). No external IdPs in Phase 0. | +| **RBAC seed** | Data-driven permissions matrix seeded from `src/ypms/seed/permissions_matrix.json`. Roles seeded: `DOES_SYSTEM_ADMIN` (super-role, bypasses checks), `OYP_STAFF`, `ELIGIBILITY_EXAMINER`, `PAYROLL_ADMIN`, `REPORTING_ANALYST`, `HOST_USER`, `PARENT_USER`, `YOUTH_USER`. | +| **Generic Entity base** | CRUD + soft delete + optimistic locking + audit + version history + cursor pagination + bulk create/update/delete. Vendored from OWC. | +| **Audit logging** | Framework-emitted for every state change (create / update / delete / restore). Structured JSON, append-only table. Ties to NIST AU-2 / AU-3 / AU-12 and source RFP `C.5.7.39`, `C.5.7.48`, `C.5.7.49`. | +| **PII-read audit decorator** | YPMS addition: `@audit_read("pii_access")` on sensitive-record read endpoints. Ties to source RFP `C.5.6.9` #5. Exercised on the Phase 0 Registrant vertical slice. | +| **Registrant vertical slice** | The `Registrant` entity is real, end-to-end: model, schemas, router, migration, permissions, tests, coverage doc. Proves the framework works with a domain entity that has masked SSN, encrypted-at-rest banking placeholder, and PII-read audit. | +| **501 stubs for other entities** | Every entity enumerated in ARCH §6.1 (Guardian, Host, Worksite, Position, Program, Application, Enrollment, TimeEntry, Timesheet, PayrollBatch, TransportationVoucher, Attachment, Note, IntegrationEvent, Notification, EducationRecord, FosterIndicator, ConsentRecord, Cohort, EligibilityRule, JobPosting, HostContact, Certification, Orientation, TaxDocument) shipped as a 501-returning router that **still fires RBAC + audit**. Permission gaps surface at Phase 0, not Phase N. | +| **Retention scaffold** | `retention_policy` attribute declared on entity models (per ARCH §6.4). Nightly job wired but no-op in Phase 0 — enforcement lands with the entity-specific implementations in later phases. | +| **Alembic baseline** | One initial migration containing all model tables. Phase 0 baseline is `0001_baseline.py`; immutable once merged. | +| **CI-ready layout** | GitHub Actions workflow (matches OWC): lint (ruff), type check (mypy or pyright — match OWC), tests (pytest), SAST (bandit), SCA (pip-audit), secret scan (gitleaks), SBOM (CycloneDX). Blocks merge on failure. | +| **Test discipline** | ≥ 80% coverage on `framework/` and `security/`. Every other module needs at least one happy-path test. | +| **Docs** | `README.md` (runnable quickstart, entity-adding template), `CONTRIBUTING.md` (hard rules, mirrored from OWC), `PHASE0_PLAN.md` (this file), `docs/nist-mapping.md` (stub). | + +### Out of scope (Phase 1+) + +- **Any frontend.** Public portal, host portal, staff portal — all Phase 1+. The Phase 0 admin surface is FastAPI's built-in `/docs` (OpenAPI UI). +- **External IdP integration.** Entra ID (staff), Login.gov (youth/host), social-media OAuth (browsing) — all Phase 1. +- **Parental co-consent lifecycle.** Data model has a `Guardian` stub and a `ConsentRecord` stub; the workflow that binds them to an `Application` is Phase 1 alongside intake. +- **Integrations.** SSA, OSSE, CFSA, DC MAR, payroll vendor, LMS — Phase 2 or later depending on dependency. +- **Eligibility engine.** Rules seed, engine, decision workflow — Phase 2. +- **Timekeeping and payroll.** Phase 7. +- **Reporting.** MicroStrategy replacement is Phase 8. +- **Retention automation execution.** Scaffold only; enforcement per entity as entities gain real fields. +- **Row-level RBAC.** Phase 0 is "can role X do action Y on entity type Z?" Row-level ("only your caseload") is Phase 2+. +- **Real PII.** Dev and test are synthetic only. Sanitization pipelines for prod-refresh come with Phase 5 CSV-ingest work. + +--- + +## 2. Traceability + +Every Phase 0 component maps to a source-RFP requirement or a NIST control. Table is the audit trail — mirrors OWC's `PROJECT_PLAN.md` §2 pattern. + +| Component | Source | Notes | +|---|---|---| +| User model + role seed | Source RFP `C.5.7.29`–`C.5.7.34`; NIST AC-2 | 8 initial roles; seeded at migration time | +| RBAC permission check | Source RFP `C.5.7.27`, `C.5.7.32`; NIST AC-3, AC-6 | Data-driven; matrix loaded from seed JSON | +| Generic CRUD framework | Source RFP `C.5.21.31`–`C.5.21.34` (define, view, comment on, view history of cases and tasks); vendored from OWC | Build once, reuse | +| Audit log | Source RFP `C.5.7.39`, `C.5.7.48`, `C.5.7.49`, `C.5.6.9` #4, #8, #11, #12, #13, #17, #18; NIST AU-2, AU-3, AU-12 | Structured JSON, append-only table | +| PII-read audit decorator | Source RFP `C.5.6.9` #5; NIST AU-14 | YPMS-specific addition above OWC's framework | +| Soft delete + version history | Source RFP implicit (case/task history retention `C.5.21.34`) | Common base mixin | +| Auth + session mgmt | Source RFP `C.5.7.1`, `C.5.7.3`–`C.5.7.14`, `C.5.7.38`; NIST IA-2, IA-4, IA-5 | Local + JWT; `iam.assurance_level` claim for future assurance gates | +| Password hashing | Source RFP `C.5.7.9`; NIST IA-5(1) | pbkdf2_sha256; FIPS 140-3 by container of the library where available | +| Config / secrets handling | NIST SC-12, SC-28, CM-6 | Env-based; `.env.example` committed, `.env` not; Key Vault comes Phase 1 | +| Registrant vertical slice | Source RFP `C.5.3.1`, `C.5.3.4` (youth application, account management); ARCH §6.1 | Proves the framework end-to-end | +| 501-stubs on remaining entities | Source RFP `C.5.7.27` (enforcement even on unimplemented routes) | RBAC + audit fire regardless | +| Alembic migration discipline | NIST CM-3, CM-4; source RFP `C.5.8.12` (impact analysis before DB change) | Migrations immutable once merged (OWC hard rule) | + +--- + +## 3. Milestones + +| # | Milestone | Exit criteria | +|---|---|---| +| **0.1** | Repo scaffold + Docker Compose boots | `git init` in `ypms/`, tree matches ARCH §5.1, `docker compose up` starts app + Postgres, `curl :8000/healthz` returns 200. | +| **0.2** | Framework vendor-in | `src/ypms/framework/` and `src/ypms/security/` contain vendored OWC modules; header comment names OWC commit; base tests from OWC pass in YPMS repo (adjusted for module path). | +| **0.3** | Auth + JWT + assurance_level | `POST /auth/login` returns a JWT with `sub`, `iat`, `exp`, `iam.assurance_level`, `roles` claims. `get_current_user` dep verifies. Local password auth uses pbkdf2_sha256. | +| **0.4** | RBAC seed loaded | `src/ypms/seed/permissions_matrix.json` loaded at startup; `can(user, action, entity)` returns correct decisions per matrix; `DOES_SYSTEM_ADMIN` bypasses. Seed round-trip test passes. | +| **0.5** | Registrant vertical slice | `Registrant` model + schemas + router + migration + permissions + tests. CRUD works end-to-end; SSN masked in serializer output; `@audit_read("pii_access")` fires on GET; every state change emits audit row. Coverage doc at `docs/coverage/registrant.md`. | +| **0.6** | 501-stub routers for remaining entities | Every entity in ARCH §6.1 (except Registrant, User, Role, Permission, AuditRow) has a router registered in `main.py` that returns 501 while still firing RBAC + audit. Test asserts RBAC decision and audit emission for each. | +| **0.7** | Retention scaffold | `retention_policy` attribute on every entity model (even 501-stub entities have a model). Nightly job in `src/ypms/framework/retention.py` runs, logs "0 records to purge" — no-op but wired. | +| **0.8** | CI pipeline | GitHub Actions workflow with lint (ruff), types (mypy/pyright — match OWC's pick), tests, bandit, pip-audit, gitleaks, SBOM. Green build on `main`. | +| **0.9** | Docs + acceptance | `README.md` with runnable quickstart; `CONTRIBUTING.md` with hard rules; `docs/nist-mapping.md` skeleton; this file marked complete. | + +Each milestone independently mergeable. + +--- + +## 4. Data-model sketch (Phase 0) + +Minimal. Real fields on `Registrant` because it's the vertical slice; everything else is a stub with `id`, `created_at`, `updated_at`, `deleted_at`, `version` — enough to demonstrate framework mixins. + +``` +Registrant (real — vertical slice) + ├── id + ├── first_name, middle_name, last_name + ├── dob + ├── ssn_encrypted (app-layer encrypted; masked in serializer to XXX-XX-1234) + ├── ssn_last4 (denormalized for search / display) + ├── email, phone + ├── address_line1, line2, city, state, zip + ├── minor_flag (derived from dob at read time) + ├── created_at, updated_at, deleted_at, version (from framework mixins) + +User (real — needed for auth) + ├── id, username, password_hash, is_active + ├── roles (M2M → Role via RoleAssignment) + ├── mfa_verified (Phase 0: always false; Phase 1 flips to real) + ├── assurance_level ('standard' by default; upgraded by Phase 1 flows) + +Role (real — seed-loaded) + ├── id, name, description, is_superuser + +Permission (real — seed-loaded) + ├── id, entity, action + +RoleAssignment (real — junction) + ├── role_id, permission_id + +AuditRow (real — framework) + ├── id, actor_id, action, entity, entity_id + ├── request_id, before (JSONB), after (JSONB), timestamp + +All other entities from ARCH §6.1 (stubs — id + mixins only) + Guardian · ConsentRecord · Host · HostContact · Worksite · Position · + JobPosting · Program · Cohort · EligibilityRule · Application · + EligibilityDecision · Certification · Orientation · Enrollment · TimeEntry · + Timesheet · PayrollBatch · TaxDocument · TransportationVoucher · Attachment · + Note · IntegrationEvent · Notification · EducationRecord · FosterIndicator +``` + +--- + +## 5. Repository layout at Phase 0 end + +Matches ARCH §5.1 with only the Phase 0 subset populated: + +``` +ypms/ +├── README.md (runnable quickstart) +├── CONTRIBUTING.md (hard rules mirrored from OWC) +├── PHASE0_PLAN.md (this file) +├── ARCHITECTURE.md (design blueprint) +├── ... (SSP, control mapping, POA&M, PIA, TODO, CLAUDE.md, OVERVIEW.md) +├── Dockerfile +├── docker-compose.yml +├── pyproject.toml +├── alembic.ini +├── .env.example +├── .github/workflows/ci.yml +├── migrations/versions/0001_baseline.py +├── src/ypms/ +│ ├── __init__.py +│ ├── main.py (FastAPI factory + router registration) +│ ├── settings.py (pydantic-settings) +│ ├── logging.py (structured JSON + sensitive-field sanitizer) +│ ├── db.py (engine, session, base) +│ ├── deps.py (FastAPI deps) +│ ├── framework/ (vendored from OWC) +│ │ ├── __init__.py +│ │ ├── entity.py (base + mixins) +│ │ ├── crud.py (CRUDService with audit emission) +│ │ ├── router.py (make_router factory) +│ │ ├── audit.py (framework audit emitter) +│ │ ├── pii_audit.py (YPMS addition — @audit_read decorator) +│ │ ├── pagination.py +│ │ ├── retention.py (scaffold; no-op in Phase 0) +│ │ └── seed_loader.py +│ ├── security/ (vendored + YPMS additions) +│ │ ├── __init__.py +│ │ ├── auth.py (JWT create/verify with iam.assurance_level) +│ │ ├── passwords.py (pbkdf2_sha256) +│ │ ├── rbac.py (can/require_permission decorators) +│ │ └── encryption.py (app-layer column encryption helpers) +│ ├── seed/ +│ │ └── permissions_matrix.json +│ ├── youth/ (Registrant — real) +│ │ ├── __init__.py +│ │ ├── models.py +│ │ ├── schemas.py +│ │ ├── router.py +│ │ └── service.py (thin service using CRUDService) +│ ├── parent/ (Guardian — stub) +│ ├── host/ (Host, HostContact, Worksite, Position, JobPosting — all stubs) +│ ├── program/ (Program, Cohort, EligibilityRule — stubs) +│ ├── application/ (Application, EligibilityDecision, Certification, ConsentRecord — stubs) +│ ├── enrollment/ (Enrollment — stub) +│ ├── orientation/ (Orientation — stub) +│ ├── timekeeping/ (TimeEntry, Timesheet — stubs) +│ ├── payroll/ (PayrollBatch, TaxDocument, TransportationVoucher — stubs) +│ ├── notifications/ (Notification — stub) +│ ├── integrations/ (IntegrationEvent — stub; no adapter modules yet) +│ ├── attachments/ (Attachment, Note — stubs) +│ ├── education_records/ (EducationRecord — stub; FERPA-scoped) +│ ├── foster_indicators/ (FosterIndicator — stub; Title 4-scoped) +│ └── admin/ (User, Role, Permission — real; system-admin endpoints) +├── tests/ +│ ├── framework/ (vendored tests + YPMS additions for pii_audit) +│ ├── security/ (auth, rbac, encryption) +│ ├── youth/ (Registrant e2e) +│ ├── stubs/ (one test per stub entity: RBAC + audit fire on 501) +│ └── conftest.py +└── docs/ + ├── nist-mapping.md (skeleton — populated per phase) + ├── coverage/ + │ └── registrant.md + └── compliance/ (mirrors OWC docs/compliance/ once real controls have code) +``` + +--- + +## 6. NIST controls that get real (non-stub) code in Phase 0 + +Following OWC's pattern of only wiring controls that code actually implements. Others stay as 📝 in the control mapping until later phases. + +| Control | Implementation | +|---|---| +| **AC-2** | User model, role-based accounts, admin can enable/disable | +| **AC-3** | `require_permission` decorator on every mutating route; 501 stubs still enforce | +| **AC-6** | RBAC via permissions matrix; `DOES_SYSTEM_ADMIN` super-role explicit | +| **AC-7** | 5-failure lockout — Phase 0 targets the check; actual lockout with `locked_until` field lands here | +| **AC-11 / AC-12** | JWT expiry (short-lived access); refresh token flow lands Phase 1 | +| **AU-2 / AU-3 / AU-12** | Framework audit emission on every state change; `AuditRow` model + emission tests | +| **AU-8** | UTC-normalized timestamps everywhere; Postgres timezone set to UTC in Docker Compose | +| **AU-14** | PII-read audit decorator on Registrant read endpoints | +| **CM-3** | Alembic migrations immutable once merged (repo policy + CI check) | +| **IA-2** | Authentication required for every non-public route | +| **IA-4** | Unique usernames; no re-issue on delete (deleted users tombstoned, username reserved) | +| **IA-5** | Password change endpoint; pbkdf2_sha256 | +| **IA-5(1)** | FIPS-approved password hashing | +| **SC-8** | Dev/test uses TLS via reverse-proxy in compose (self-signed OK for local); production TLS is deploy-phase | +| **SC-12 / SC-13 / SC-28** | App-layer column encryption for `ssn_encrypted` and banking placeholder using cryptography-library primitives; Key Vault swap-in is Phase 1 | +| **SI-10** | Pydantic schema validation on all inbound requests | +| **SI-11** | Non-exploitable error responses (custom exception handler) | + +Everything else in the control mapping stays 📝 until later phases wire it. + +--- + +## 7. Risks + +| Risk | Mitigation | +|---|---| +| Vendoring OWC's framework introduces divergence over time | Header-comment naming the OWC commit; document the vendored-code policy in CONTRIBUTING. Pulling upstream OWC changes is a deliberate act, not an ambient sync. | +| Data-driven RBAC seed drifts from code expectations | Seed loaded at startup with schema validation; missing entity or action fails startup rather than silently ignoring. | +| 501 stubs mask real permission gaps | Every stub is tested to fire RBAC + audit; gap surfaces in tests, not later. | +| App-layer encryption in Phase 0 uses local key material | `.env` value in dev/test only; documented; Phase 1 swap to Key Vault is a single-file change with the encryption helper interface preserved. Local keys never used in staging or prod. | +| Vertical slice on Registrant hides framework issues for other entity shapes | 501 stubs still exercise the framework at the RBAC + audit level for every entity, catching factory-parameter mistakes. | +| Alembic baseline captures wrong shape and every future migration inherits the mistake | Baseline reviewed against ARCH §6 by CIO before first merge; every downstream migration is additive, so wrong shapes are correctable via new migration (never edit baseline). | +| CI pipeline slow enough to block iteration | Test suite must stay under 60s (SQLite fixtures). Framework tests get priority; slow integration-style tests deferred to a nightly workflow. | +| Retention scaffold gets forgotten and never enforces | Every entity model asserts a `retention_policy` in a startup check; entity without one fails startup. Enforcement per class lands later, but the scaffold is unforgettable. | + +--- + +## 8. Definition of done for Phase 0 + +Phase 0 is complete when: + +- [ ] `docker compose up` boots app + Postgres cleanly; `/healthz` returns 200. +- [ ] `alembic upgrade head` applies the baseline migration. +- [ ] `POST /auth/login` issues a JWT with `iam.assurance_level` claim. +- [ ] `POST /registrants` creates a Registrant with masked SSN in the response, emits an audit row, requires `OYP_STAFF` or higher. +- [ ] `GET /registrants/{id}` reads the record, fires the PII-read audit decorator, masks SSN, requires appropriate role. +- [ ] `PATCH /registrants/{id}` updates fields, emits before/after in audit row, requires appropriate role. +- [ ] `DELETE /registrants/{id}` soft-deletes, emits audit, requires appropriate role. +- [ ] Every stub entity's endpoints return 501 but still emit an audit row and enforce RBAC. +- [ ] Tests green in CI: lint, types, pytest, SAST, SCA, secret scan, SBOM. +- [ ] Coverage ≥ 80% on `framework/` and `security/`; every stub has one test. +- [ ] `README.md` quickstart works on a clean checkout. +- [ ] `CONTRIBUTING.md` published with hard rules mirrored from OWC. +- [ ] `docs/nist-mapping.md` lists the controls wired above, with file:line evidence. +- [ ] Control mapping `NIST_800_53_CONTROL_MAPPING.md` updated: the Phase-0-wired controls flip from 📝 to ✅ (or 🟡 for partials); file:line evidence populated. + +--- + +## 9. What I need from you + +1. **Match OWC's Azure Gov deployment target?** OWC currently runs Docker locally; its Azure Gov deployment is Phase 19/20. YPMS Phase 0 is local-only too. Confirm we're **not** provisioning Azure Gov in Phase 0 — Azure comes with Phase 1 (Key Vault swap-in) or later. +2. **Match OWC's CI provider?** OWC uses `[TBD — confirm]`. I'll default to GitHub Actions unless OWC is on Azure DevOps; then I match. Say which. +3. **8 initial roles OK, or want a different seed set?** Current default: `DOES_SYSTEM_ADMIN`, `OYP_STAFF`, `ELIGIBILITY_EXAMINER`, `PAYROLL_ADMIN`, `REPORTING_ANALYST`, `HOST_USER`, `PARENT_USER`, `YOUTH_USER`. Missing roles surface fast at Phase 1; adding one later is a seed update. +4. **First entity as Registrant, or something smaller?** Registrant is the natural vertical slice because everything else hangs off it. Smaller options: `Program` (mostly reference data) or `HostContact` (simple). I lean Registrant because the encryption + masking + PII-read audit path is what Phase 0 needs to prove. +5. **Test-runner + type-checker to match OWC?** Confirm: pytest for tests, and pick mypy or pyright to match OWC. + +If you just say "proceed" I'll: + +- Start with milestone 0.1 (repo scaffold + Docker Compose), +- Default GitHub Actions, mypy, the 8 roles above, Registrant as the slice, and no Azure Gov in Phase 0, +- Merge each milestone independently as it lands. + +--- + +**End of draft v0.1.** diff --git a/POAM.md b/POAM.md new file mode 100644 index 0000000..051a11b --- /dev/null +++ b/POAM.md @@ -0,0 +1,201 @@ +# Plan of Action and Milestones (POA&M) +## Youth Program Management System (YPMS) + +**Document Version:** 0.1 (initial seed) +**Date:** 2026-09-30 +**NIST Reference:** SP 800-53 Rev. 5 control CA-5 +**Status:** Pre-Development / Pre-Authorization +**Companion docs:** [`SYSTEM_SECURITY_PLAN.md`](SYSTEM_SECURITY_PLAN.md), [`NIST_800_53_CONTROL_MAPPING.md`](NIST_800_53_CONTROL_MAPPING.md) + +> **Drafting note.** This POA&M is seeded from three sources: (1) the four SSP tailorings above the RFP-derived requirement floor, (2) the six open policy decisions awaiting AO / OYP / Privacy Officer disposition, and (3) the standard pre-ATO deliverables not yet authored or executed (companion docs, data-sharing agreements, foundational build activities, independent assessments). Because YPMS is **pre-development** — this is an in-house build following the DCYWP / OWC / Employer 360 pattern, and no code exists yet — there are no vulnerability findings to import. Once initial code lands, findings from SAST/DAST/pentest will be added by ID. Items marked **`[TBD]`** for owner or target date are pending assignment by DOES leadership. + +--- + +## Table of Contents + +1. [Status Legend](#1-status-legend) +2. [Severity Definitions](#2-severity-definitions) +3. [Open Items](#3-open-items) +4. [Closed Items](#4-closed-items) +5. [Maintenance and Reporting Cadence](#5-maintenance-and-reporting-cadence) + +--- + +## 1. Status Legend + +| Symbol | Meaning | +|---|---| +| 🔴 | Open — work not yet started | +| 🟡 | In progress — work underway | +| 🟢 | Closed — completed and verified | +| 🔵 | Risk accepted — formally accepted by AO with documented rationale | +| ⚪ | Deferred — known and tracked, scheduled for a later cycle | +| ❓ | Awaiting decision — blocked on AO / OYP / Privacy Officer determination | + +## 2. Severity Definitions + +Severity ratings align with FedRAMP Continuous Monitoring guidance and the DCYWP POA&M scale for consistency across DOES ATO packages. + +| Severity | Definition | Default Remediation Window | +|---|---|---| +| **Critical** | Vulnerability allows direct unauthorized access to PII or system control, or blocks ATO decision entirely | 30 days | +| **High** | Significant risk to confidentiality, integrity, or availability with credible exploit path; or an ATO artifact that must exist before AO can sign | 90 days | +| **Moderate** | Material weakness without immediate exploit; defense-in-depth gap; or a companion doc/process needed for continuous monitoring | 180 days | +| **Low** | Hygiene; best practice; no immediate exploit | 365 days or next major release | + +--- + +## 3. Open Items + +### 3.1 Critical + +| ID | Severity | Title | Source | Owner | Milestones | Target Date | Status | +|---|---|---|---|---|---|---|---| +| **YPMS-POAM-001** | Critical | FIPS 199 categorization memo signed by AO | NIST RA-2 / SSP §2 | Chris Tonjes (System Owner / AO) | M1: draft memo — 14 days. M2: Privacy Officer review — 30 days. M3: AO signature — 45 days. | 2026-11-15 | 🔴 Open | +| **YPMS-POAM-002** | Critical | AO designated in writing for YPMS | NIST CA-6 | DOES CIO | ✅ **Closed 2026-09-30**: Chris Tonjes designated as AO alongside System Owner and ISSO roles; role concentration accepted and recorded in SSP §5. | 2026-09-30 | 🟢 Closed | + +### 3.2 High (open) + +#### Missing ATO artifacts (all must exist before AO signature) + +| ID | Severity | Title | Source | Owner | Milestones | Target Date | Status | +|---|---|---|---|---|---|---|---| +| **YPMS-POAM-010** | High | System Security Plan finalized and approved | NIST PL-2 | DOES CIO + ISSO | v0.3 exists (`ypms/SYSTEM_SECURITY_PLAN.md`) in in-house build framing. M1: ISSO review — 60 days. M2: AO signature — 90 days. | 2026-12-31 | 🟡 In Progress | +| **YPMS-POAM-011** | High | Privacy Impact Assessment authored, reviewed, approved | NIST PT-2 | Privacy Officer + DOES CIO | v0.1 draft complete 2026-09-30 (`ypms/PRIVACY_IMPACT_ASSESSMENT.md`). M1: Privacy Officer + OGC review — 30 days. M2: AO signature — 60 days. | 2026-11-30 | 🟡 In Progress | +| **YPMS-POAM-012** | High | Incident Response Plan finalized; tabletop run | NIST IR-3 / IR-8 | DOES CIO + DC OCTO CISO liaison | M1: draft — 30 days. M2: tabletop with OCTO SOC — 60 days. M3: signatures — 90 days. | 2027-01-15 | 🔴 Open | +| **YPMS-POAM-013** | High | Contingency Plan finalized; functional restore drill | NIST CP-2 / CP-4 | DOES CIO + OIT Ops | M1: draft — 30 days. M2: signatures — 60 days. M3: functional restore drill — 120 days. Recovery envelope: 99.5% SLA / peak-season hard deadlines. | 2027-02-15 | 🔴 Open | +| **YPMS-POAM-014** | High | Rules of Behavior authored (staff / host / youth+parent variants) | NIST PL-4 | DOES HR + Privacy Officer | M1: staff variant — 30 days. M2: host variant — 60 days. M3: youth/parent variant with parental-consent flow — 90 days. M4: incorporated into onboarding + account-creation workflow — 120 days. | 2027-02-01 | 🔴 Open | +| **YPMS-POAM-015** | High | NIST 800-53 control mapping finalized | NIST PL-2 / CA-2 | DOES CIO + ISSO | v0.2 exists (`ypms/NIST_800_53_CONTROL_MAPPING.md`) in in-house build framing (DOES OIT tags, repo/pipeline evidence). M1: ISSO review — 60 days. M2: refresh to v0.3 once architecture and initial code land. | 2027-02-28 | 🟡 In Progress | + +#### Data-sharing agreements (blocking on integration builds) + +| ID | Severity | Title | Source | Owner | Milestones | Target Date | Status | +|---|---|---|---|---|---|---|---| +| **YPMS-POAM-020** | High | DOES–OSSE data-sharing agreement (FERPA) — **renewal / scope amendment** | NIST CA-3 / SA-9; FERPA | DOES OGC + Privacy Officer + OSSE liaison | M1: pull existing agreement + confirm expiration — 14 days. M2: draft renewal or YPMS-scope amendment — 45 days. M3: OSSE review — 75 days. M4: signature — 105 days. **Blocks OSSE school-enrollment ingest build.** | 2027-01-15 | 🔴 Open | +| **YPMS-POAM-021** | High | DOES–CFSA MOU (foster/ward indicator) — **renewal / scope amendment** | NIST CA-3 / SA-9; DC Code Title 4 | DOES OGC + CFSA liaison | M1: pull existing MOU + confirm expiration — 14 days. M2: draft renewal or YPMS-scope amendment — 45 days. M3: CFSA review — 75 days. M4: signature — 105 days. **Blocks CFSA ingest build.** | 2027-01-15 | 🔴 Open | +| **YPMS-POAM-022** | High | SSA Electronic Information Exchange agreement (SSN cross-match) — **renewal / scope amendment** | NIST CA-3; SSA EIES requirements | DOES OGC + SSA regional liaison | M1: pull existing agreement + confirm YPMS scope coverage — 30 days. M2: amendment drafted if scope is new — 60 days. M3: SSA signature — 150 days (SSA cycle is slow). **Blocks SSN verification build.** | 2027-03-01 | 🔴 Open | +| **YPMS-POAM-023** | High | Payroll-vendor selection and security review | NIST SA-9 / CA-3 | DOES CIO + OYP + Procurement | M1: vendor requirements — 30 days. M2: SIG-Lite / SOC 2 collection from candidates — 60 days. M3: selection — 90 days. M4: ISA / DPA signature — 120 days. **Blocks payroll integration build.** | 2027-01-31 | 🔴 Open | + +#### SSP tailorings above the RFP-derived requirement floor + +These four items are the tailorings recorded in the SSP Appendix D and control-mapping §5. Building to the RFP wording alone would fail the Moderate baseline. + +| ID | Severity | Title | Source | Owner | Milestones | Target Date | Status | +|---|---|---|---|---|---|---|---| +| **YPMS-POAM-030** | High | MFA required for all privileged and staff accounts | NIST IA-2(1)/(2) — SSP tailoring above `C.5.7.6` | DOES CIO | M1: MFA modality decision (Entra ID conditional access preferred, aligned with OWC/Employer 360) — 30 days. M2: implementation in non-prod — 90 days. M3: production enforcement — 120 days. | 2027-02-15 | 🔴 Open | +| **YPMS-POAM-031** | High | TLS 1.2+ (target 1.3), FIPS-approved cipher suites; SSL retired | NIST SC-8 / AC-17(2) — SSP tailoring above `C.5.6.15` | DOES CIO | M1: TLS baseline in architecture doc — 30 days. M2: enforced in all environments — 60 days. M3: SSL Labs A+ or equivalent on public endpoints — 90 days. | 2027-01-31 | 🔴 Open | +| **YPMS-POAM-032** | High | FIPS 140-3 cryptography (140-2 acceptable during deprecation window) | NIST IA-7 / SC-12 / SC-13 — SSP tailoring above `C.5.7.9` | DOES CIO | M1: crypto library inventory + FIPS mode confirmed for each — 30 days. M2: Key Vault (Azure Gov HSM) provisioned — 60 days. M3: all keys managed via Key Vault — 120 days. | 2027-02-28 | 🔴 Open | +| **YPMS-POAM-033** | High | IAL2-equivalent identity proofing before youth banking/payroll actions | NIST IA-12 — SSP tailoring (RFP silent); links to open decision YPMS-POAM-050 | DOES CIO + Privacy Officer + OYP | M1: identity-model decision (see YPMS-POAM-050) — 45 days. M2: proofing vendor selection (Login.gov / SSA / DMV records) — 90 days. M3: proofing flow implemented — 180 days. **Blocks payroll enrollment for minors.** | 2027-04-01 | ❓ Blocked on YPMS-POAM-050 | + +#### Foundational build activities + +| ID | Severity | Title | Source | Owner | Milestones | Target Date | Status | +|---|---|---|---|---|---|---|---| +| **YPMS-POAM-040** | High | Architecture & tech-stack decision recorded | NIST PL-8 / SA-3 | DOES CIO | ✅ Stack decision closed 2026-09-30: Python 3.12 / FastAPI / SQLAlchemy / Postgres on Azure Government (OWC alignment). ✅ Architecture document v0.1 drafted 2026-09-30 (`ypms/ARCHITECTURE.md`). ✅ Phase 0 plan drafted 2026-09-30 (`ypms/PHASE0_PLAN.md`). M1: DC OCTO security architecture review — 45 days. | 2026-11-15 | 🟡 In Progress | +| **YPMS-POAM-041** | High | Azure Government tenant + non-prod environments provisioned | NIST CM-2 / CM-6 | DOES CIO + DC OCTO | M1: subscription request — 30 days. M2: dev + test environments — 60 days. M3: CIS Azure Foundations baseline applied — 90 days. | 2027-01-15 | 🔴 Open | +| **YPMS-POAM-042** | High | CI/CD pipeline with SAST, SCA, secret scanning, SBOM | NIST SA-11 / SR-3 / SR-11 / CM-8 | DOES CIO | M1: pipeline scaffold — 30 days. M2: SAST + SCA gates — 60 days. M3: SBOM generation per release (CycloneDX) — 90 days. | 2027-01-31 | 🔴 Open | +| **YPMS-POAM-043** | High | Sentinel integration (DOES OIT ships application + Azure resource logs to DC OCTO Sentinel) | NIST AU-6 / SI-4 | DOES CIO + DC OCTO CISO | M1: log-schema agreement with OCTO SOC — 30 days. M2: Sentinel workspace and ingestion — 60 days. M3: correlation rules and alert playbooks — 120 days. | 2027-02-28 | 🔴 Open | +| **YPMS-POAM-044** | High | Backup + restore procedure documented and tested | NIST CP-9 / CP-9(1) | DOES CIO + OIT Ops | M1: procedure documented — 30 days. M2: initial restore drill — 60 days. M3: annual drill cadence established — 90 days. | 2027-02-15 | 🔴 Open | + +### 3.3 Moderate (open) + +#### Open policy decisions (mirrored to SSP Appendix D) + +| ID | Severity | Title | Source | Owner | Milestones | Target Date | Status | +|---|---|---|---|---|---|---|---| +| **YPMS-POAM-050** | Moderate | Identity model for minors (social-media login vs. IAL2 proofing gates) | SSP §17.D | DOES CIO + Privacy Officer + OYP + AO | M1: options memo (browse-only social, IAL2 for payroll, parental co-auth for under-18) — 30 days. M2: AO decision — 60 days. **Feeds YPMS-POAM-033.** | 2026-11-30 | ❓ Awaiting decision | +| **YPMS-POAM-051** | Moderate | Clarify "Level 3 security" wording from source RFP `C.5.7.24` | SSP §17.A | DOES CIO + ISSO | M1: options memo — 30 days. M2: AO clarification memo — 45 days. Treat as NIST 800-63 IAL3/AAL3 pending decision (higher of plausible readings). | 2026-11-15 | ❓ Awaiting decision | +| **YPMS-POAM-052** | Moderate | PCI DSS applicability determination | SSP §17.E | DOES CIO + OYP + OGC | M1: transaction-flow review confirming ACH-only via payroll vendor (no card processing in YPMS) — 30 days. M2: PCI scope memo (expected: out of scope) — 45 days. | 2026-11-15 | ❓ Awaiting decision | +| **YPMS-POAM-053** | Moderate | Dormant emergency health-record CSV path — in-boundary vs. emergency extension | SSP §17.H | Privacy Officer + DOES CIO + AO | M1: options memo — 30 days. M2: AO decision — 60 days. Recommended: separate emergency-scoped extension with its own PIA addendum. | 2026-11-30 | ❓ Awaiting decision | +| **YPMS-POAM-054** | Moderate | Retention policy for audit logs, case records, backups | SSP §17.G | DOES Records Officer + Privacy Officer + DOES CIO | M1: records-schedule review — 30 days. M2: retention policy signed — 60 days. Feeds AU-11 and SI-12 implementation. | 2026-12-15 | ❓ Awaiting decision | + +#### Assessment and pre-launch validation + +| ID | Severity | Title | Source | Owner | Milestones | Target Date | Status | +|---|---|---|---|---|---|---|---| +| **YPMS-POAM-060** | Moderate | Independent Control Assessment (SCA) commissioned | NIST CA-2 / CA-2(1) | DOES CIO | M1: assessor selection — 60 days. M2: engagement — 120 days. M3: report — pre-Go-Live. | 2027-06-30 | 🔴 Open | +| **YPMS-POAM-061** | Moderate | Penetration test (external + authenticated) | NIST CA-8 | DOES CIO | M1: scope of work — 60 days. M2: engagement — 120 days. M3: report + remediation POA&M items — pre-Go-Live. | 2027-06-30 | 🔴 Open | +| **YPMS-POAM-062** | Moderate | Vulnerability scanning cadence in production | NIST RA-5 | DOES CIO | M1: scanner selection — 45 days. M2: monthly authenticated + unauthenticated scans — 90 days. | 2027-03-15 | 🔴 Open | + +#### Access control and hygiene + +| ID | Severity | Title | Source | Owner | Milestones | Target Date | Status | +|---|---|---|---|---|---|---|---| +| **YPMS-POAM-070** | Moderate | System-use notification banner on all authenticated entry points | NIST AC-8 | DOES CIO + Legal | M1: banner text approved — 30 days. M2: implementation — 60 days. | 2027-01-31 | 🔴 Open | +| **YPMS-POAM-071** | Moderate | Auto-disable inactive accounts (staff 90d, youth 180d — pending records policy) | NIST AC-2(3) | DOES CIO | M1: policy — 45 days (depends on YPMS-POAM-054). M2: implementation — 90 days. | 2027-03-15 | 🔴 Open | +| **YPMS-POAM-072** | Moderate | Quarterly privileged-access recertification process | NIST AC-2 / AC-6(7) | DOES ISSO | M1: process document — 30 days. M2: first recertification cycle — 90 days. | 2027-02-15 | 🔴 Open | +| **YPMS-POAM-073** | Moderate | Annual all-user access recertification process | NIST AC-2 | DOES ISSO | M1: process document — 60 days. M2: tooling — 120 days. | 2027-03-31 | 🔴 Open | +| **YPMS-POAM-074** | Moderate | Continuous Monitoring Strategy document | NIST CA-7 / SP 800-137 | DOES ISSO | M1: draft — 60 days. M2: signatures — 90 days. Codifies cadence table from SSP §15. | 2027-02-28 | 🔴 Open | + +#### Data-handling and privacy + +| ID | Severity | Title | Source | Owner | Milestones | Target Date | Status | +|---|---|---|---|---|---|---|---| +| **YPMS-POAM-080** | Moderate | SSN masking/anonymization design and enforcement | NIST SC-28 / SI-10; `C.5.7.50` | DOES CIO | M1: display-layer masking design — 30 days. M2: at-rest encryption confirmed — 60 days. M3: audit — pre-Go-Live. | 2027-04-30 | 🔴 Open | +| **YPMS-POAM-081** | Moderate | Language Access Act compliance (notices, portal content) | DC Language Access Act 2004 | DOES CIO + OYP | M1: language matrix — 30 days. M2: translated content pipeline — 120 days. | 2027-03-31 | 🔴 Open | +| **YPMS-POAM-082** | Moderate | Section 508 / WCAG 2.1 AA compliance audit | Section 508 | DOES CIO | M1: automated audit in CI — 60 days. M2: manual audit — 120 days. M3: remediation — pre-Go-Live. | 2027-05-31 | 🔴 Open | +| **YPMS-POAM-083** | Moderate | Parental consent workflow for under-18 registrants | NIST PT-4 | Privacy Officer + DOES CIO + OGC | M1: consent-flow design — 45 days. M2: implementation — 120 days. | 2027-04-15 | 🔴 Open | +| **YPMS-POAM-084** | Moderate | Data flow inventory + diagrams (all integrations) | NIST CA-3 / CA-9 | DOES CIO | M1: inventory — 45 days. M2: diagrams — 90 days. Continuously updated. | 2027-02-28 | 🔴 Open | + +#### DOES organizational / process + +| ID | Severity | Title | Source | Owner | Milestones | Target Date | Status | +|---|---|---|---|---|---|---|---| +| **YPMS-POAM-090** | Moderate | ISSO assigned in writing for YPMS | NIST PM-2 | DOES CIO | ✅ **Closed 2026-09-30**: Chris Tonjes designated as ISSO alongside System Owner and AO roles; role concentration accepted and recorded in SSP §5. | 2026-09-30 | 🟢 Closed | +| **YPMS-POAM-091** | Moderate | Role-based training curriculum (OYP staff, eligibility examiners, payroll admins) | NIST AT-3 | DOES ISSO + OYP | M1: curriculum outline — 60 days. M2: content — 120 days. M3: first delivery — pre-Go-Live. | 2027-05-31 | 🔴 Open | +| **YPMS-POAM-092** | Moderate | Personnel background-check confirmation for all YPMS-access personnel | NIST PS-3 | DOES HR + DC OCTO | M1: current DOES/OIT team background-check status verified — 30 days. M2: gaps closed — 90 days. | 2027-01-31 | 🔴 Open | +| **YPMS-POAM-093** | Moderate | Change Management Plan | NIST CM-3 / CM-9 | DOES CIO + OIT Ops | M1: draft — 45 days. M2: DOES + OCTO NOC review — 90 days. | 2027-02-15 | 🔴 Open | +| **YPMS-POAM-094** | Moderate | SORN applicability determination | NIST PT-6 | Privacy Officer + OGC | M1: applicability memo — 60 days. | 2026-12-31 | ❓ Awaiting decision | + +### 3.4 Low (open) + +| ID | Severity | Title | Source | Owner | Milestones | Target Date | Status | +|---|---|---|---|---|---|---|---| +| **YPMS-POAM-100** | Low | Approved-software list maintained and reviewed | NIST CM-10 | DOES CIO | Quarterly review starting after first release. | Ongoing | 🔴 Open | +| **YPMS-POAM-101** | Low | Anti-bot / rate-limit measures on public MBSYEP peak windows | NIST SC-5 | DOES CIO | M1: threat model — 60 days. M2: WAF rules — 90 days. Tuned for summer peak. | 2027-04-30 | 🔴 Open | +| **YPMS-POAM-102** | Low | FOIA response workflow with PII redaction guidance | DC FOIA | DOES OGC + Records Officer | M1: workflow document — 90 days. | 2027-03-31 | 🔴 Open | +| **YPMS-POAM-103** | Low | Emerging-tech (GenAI/ML) governance if enabled | NIST SA-9 / SR-3 | DOES CIO + Privacy Officer | Only triggers if GenAI features added. Deferred pending scope decision. | Deferred | ⚪ Deferred | +| **YPMS-POAM-104** | Low | Vendor lock-in and data-portability provisions in payroll/LMS contracts | NIST SA-4 | DOES OGC + Procurement | Included as clauses during vendor selection. | 2027-01-31 | 🔴 Open | +| **YPMS-POAM-105** | Low | Legacy data-migration plan (7 tools: PF3, TMS, MicroStrategy, Host/Participant App, Scanning, Transfer, manual payroll) | NIST SI-12 | DOES CIO + OYP + OIT | M1: source inventories — 90 days. M2: mapping and transform design — 180 days. M3: cutover strategy — pre-Go-Live. | 2027-05-31 | 🔴 Open | +| **YPMS-POAM-106** | Low | Legacy system decommission schedule and destruction evidence | NIST MP-6 / SR-3 | DOES CIO + OIT | Follows successful cutover. | Post-Go-Live | ⚪ Deferred | + +--- + +## 4. Closed Items + +Closures retained for traceability. + +| ID | Title | Closure Date | Verification / Evidence | +|---|---|---|---| +| **YPMS-POAM-002** | AO designated in writing for YPMS | 2026-09-30 | Chris Tonjes (DOES CIO) designated as AO. Role-concentration risk accepted per SSP §5. Update SSP §3.2 reflects the designation. | +| **YPMS-POAM-090** | ISSO assigned in writing for YPMS | 2026-09-30 | Chris Tonjes designated as ISSO. Role-concentration risk accepted per SSP §5. Update SSP §4 reflects the designation. | +| — | Stack decision (partial closure of YPMS-POAM-040) | 2026-09-30 | Python 3.12 / FastAPI / SQLAlchemy / Postgres selected (OWC alignment). | +| — | Architecture document v0.1 (partial closure of YPMS-POAM-040) | 2026-09-30 | `ypms/ARCHITECTURE.md` drafted; forward-looking design following the OWC pattern. | +| — | Phase 0 plan v0.1 (partial closure of YPMS-POAM-040) | 2026-09-30 | `ypms/PHASE0_PLAN.md` drafted: framework vendor-in, auth, RBAC, audit, Registrant vertical slice, 501 stubs on remaining ARCH §6.1 entities. Ready to start build on your say-so. | + +--- + +## 5. Maintenance and Reporting Cadence + +| Activity | Frequency | Owner | +|---|---|---| +| POA&M review — status update on every open item | Monthly | DOES ISSO | +| POA&M report to AO | Quarterly | DOES CIO | +| New-finding intake (from scans, assessments, incidents) | Continuous | DOES ISSO | +| Milestone-slip escalation to CIO | On any 30-day slip past target date | DOES ISSO | +| Closure verification (independent from remediator) | Per closure | DOES ISSO | +| POA&M archive at ATO decision | At initial ATO and each reauthorization | DOES CIO | + +### Reporting format for status update + +Each open item gets a one-line status update per monthly cycle, retained in an append-only status log (`ypms/POAM_STATUS_LOG.md` — to be created on first cycle): + +``` +YYYY-MM-DD YPMS-POAM-NNN [🔴|🟡|🟢|🔵|⚪|❓] {status text ≤ 200 chars} +``` + +Status text records: what moved, blockers, next milestone due. + +--- + +**End of draft v0.1.** diff --git a/PRIVACY_IMPACT_ASSESSMENT.md b/PRIVACY_IMPACT_ASSESSMENT.md new file mode 100644 index 0000000..e204bc0 --- /dev/null +++ b/PRIVACY_IMPACT_ASSESSMENT.md @@ -0,0 +1,405 @@ +# Privacy Impact Assessment (PIA) +## Youth Program Management System (YPMS) + +**Document Version:** 0.1 (Draft) +**Date:** 2026-09-30 +**Status:** Pre-Development / Pre-Authorization +**Companion to:** [`SYSTEM_SECURITY_PLAN.md`](SYSTEM_SECURITY_PLAN.md), [`NIST_800_53_CONTROL_MAPPING.md`](NIST_800_53_CONTROL_MAPPING.md), [`POAM.md`](POAM.md) + +> **Drafting note.** This PIA is required because YPMS processes Personally Identifiable Information (PII), including PII of **minors**, and because it ingests **FERPA-covered educational records** and **CFSA foster/ward-of-state records** — both of which carry statutory confidentiality above generic PII. It supports DC Personal Information Protection Act (DC Code §28-3851 et seq.) compliance and accompanies the System Security Plan. Items marked **`[TBD]`** require completion by DOES leadership before ATO submission. Where a source-RFP requirement is load-bearing (e.g., `C.5.7.50` for SSN masking), the identifier is cited inline. + +--- + +## Table of Contents + +1. [System Identification](#1-system-identification) +2. [Authority and Purpose](#2-authority-and-purpose) +3. [Information Collection](#3-information-collection) +4. [Use of Information](#4-use-of-information) +5. [Sharing and Disclosure](#5-sharing-and-disclosure) +6. [Notice and Consent](#6-notice-and-consent) +7. [Individual Rights](#7-individual-rights) +8. [Data Quality and Integrity](#8-data-quality-and-integrity) +9. [Retention and Disposal](#9-retention-and-disposal) +10. [Security Safeguards](#10-security-safeguards) +11. [Auditing and Accountability](#11-auditing-and-accountability) +12. [Privacy Risks and Mitigation](#12-privacy-risks-and-mitigation) +13. [PIA Review and Approval](#13-pia-review-and-approval) + +--- + +## 1. System Identification + +| Field | Value | +|---|---| +| **System Name** | Youth Program Management System (YPMS) | +| **Operating Agency** | DC Department of Employment Services (DOES), Office of Youth Programs (OYP) | +| **System Owner** | Chris Tonjes, DOES CIO | +| **Delivery Model** | In-house build by DOES OIT on Azure Government (Python 3.12 / FastAPI / SQLAlchemy / Postgres) | +| **PII Populations** | (a) **Minors** aged 14–24 registering or participating in OYP programs, with distinct treatment for under-18 registrants; (b) parents / guardians of under-18 registrants; (c) host employer contacts and worksite supervisors; (d) DOES OIT and OYP staff and any contracted individual developers. | +| **Estimated Volume** | ~36,000 total distinct persons at steady state (per RFP `C.5.6.21`): 27,000 youth, 7,400 parents/guardians, 1,500 host employers, 90 DOES users, 100 other-agency users. **Peak surge:** MBSYEP application window (typically January–March) may see the youth-registration volume enter within a compressed period. | +| **Privacy Impact Threshold** | **Yes — full PIA required.** System collects (a) PII of minors — a special population — (b) SSN, (c) banking / financial-account information, (d) FERPA-covered educational records, (e) CFSA foster/ward-of-state indicators (confidential under DC Code Title 4), and (f) a dormant path for health records under emergency declaration. | +| **FIPS 199 Provisional Categorization** | Moderate / Moderate / Moderate with High-sensitivity subsets (see SSP §2). | + +--- + +## 2. Authority and Purpose + +### 2.1 Legal Authority for Collection + +- **DC Code Title 32, Chapter 2, Subchapter II** — governs youth employment in the District. +- **DC Code Title 32, Chapter 2, Subchapter V** — establishes the Mayor's Youth Leadership Institute (MBYLI). +- **DC Municipal Regulations Title 7** — Employment Benefits. +- **Social Security Act, Title III / Title IX** — federally funded workforce programs subject to the confidentiality requirements of §1106 (RFP §C.2 Item 7). +- **Federal Unemployment Tax Act (FUTA)** — where wage records feed cross-agency reporting. +- **Family Educational Rights and Privacy Act (FERPA), 20 USC §1232g** — governs the ingest of OSSE-sourced school enrollment records. +- **DC Code Title 4** — governs the confidentiality of CFSA foster/ward-of-state indicators. +- **Privacy Act of 1974, 5 USC §552a** — applies where DOES acts under federal delegation for USDOL-reported program data. +- **DC Personal Information Protection Act (DC Code §28-3851 et seq.)** — governs breach notification for PII collected. +- **DC Language Access Act of 2004** — governs delivery of notices and portal content in required languages. + +### 2.2 Purpose of the System + +To centralize OYP program administration end-to-end, replacing seven legacy tools: + +- Take applications from youth and hosts across MBSYEP, HSIP, MBYLI (SIT/SYP/Global), CRESP, and future OYP programs. +- Determine eligibility using data checks (age, residency, SSN validation, foster/ward status, school enrollment) and business rules. +- Certify applications, capture orientation completion, match youth to worksites, and manage enrollment. +- Track hours worked and issue payment via a third-party payroll vendor with annual tax-form generation. +- Provide reports and analytics replacing MicroStrategy. +- Support DOES staff workflows replacing PF3 admin-backdoor logins and manual payroll approvals. + +### 2.3 Mission Connection + +YPMS directly supports DOES's statutory obligation to administer District youth employment and workforce-development programs and to protect the minors served by those programs. + +--- + +## 3. Information Collection + +### 3.1 PII Elements — Youth Registrant + +| Element | Source | Purpose | Mandatory? | Sensitivity | +|---|---|---|---|---| +| First, middle, last name | Registrant | Identity, permit / payroll issuance | Yes | Standard PII | +| Date of birth | Registrant | Age eligibility per program | Yes | Standard PII | +| SSN | Registrant | SSA cross-match; payroll tax reporting | Yes for enrolled participants; not required for pre-application browsing | **Sensitive PII** | +| Residential and mailing address | Registrant; validated via DC MAR | DC residency verification, correspondence | Yes | Standard PII | +| Phone, email | Registrant | Notifications, secure home-page URL delivery per source RFP `C.5.21.5` | Yes | Standard PII | +| Race, ethnicity, gender (demographics) | Registrant (self-report) | USDOL federal reporting; equity analysis | Optional per federal reporting rules | Standard PII | +| School name, grade level (self-report) | Registrant | Program-fit determination | Yes for school-year programs | Standard PII | +| Educational-record excerpts (enrollment status, grade) | **OSSE** via CSV ingest | Eligibility verification | Yes when OSSE match applies | **FERPA-covered — heightened** | +| Foster / ward-of-state status | **CFSA** via CSV ingest | Categorical-eligibility rules; support-service triage | Yes when CFSA match applies | **DC Code Title 4 — heightened** | +| Immigration / work-authorization documents | Registrant upload | Employment eligibility | Yes | **Sensitive PII** | +| Resume content | Registrant upload or Resume Builder | Job matching | Optional | Standard PII | +| Job preferences, career interests | Registrant | Job matching | Optional | Standard PII | +| Banking (routing + account) | Registrant | Direct-deposit payroll | Yes for paid participants | **Sensitive PII** | +| Tax withholding elections | Registrant | Payroll | Yes for paid participants | Standard PII | +| Application answers, financial-literacy responses | Registrant | Program placement | Yes per program | Standard PII | +| Hours worked | Timekeeping | Payroll computation | Yes | Standard PII | +| Support-service enrollment (e.g., transportation) | Registrant / staff | Program services | Optional | Standard PII | +| Program participation history | System-generated | Retention, reporting, categorical eligibility | Yes | Standard PII | +| **Health records (contingent)** | **CSV under declared emergency only** (source RFP `C.5.6.3.a.2`) | Emergency operations only | No (dormant path) | **Heightened; HIPAA-adjacent** | + +### 3.2 PII Elements — Parent / Guardian (of under-18 registrants) + +| Element | Source | Purpose | Mandatory? | Sensitivity | +|---|---|---|---|---| +| First, last name | Parent | Consent record | Yes | Standard PII | +| Relationship to registrant | Parent | Consent authority | Yes | Standard PII | +| Address, phone, email | Parent | Notification, consent workflow | Yes | Standard PII | +| Consent signature and timestamp | Parent | Lawful basis for minor's data processing | Yes | Standard PII | +| Parent user credentials (if a separate portal account is created) | Parent | Authenticated access to their under-18 registrant's record | Optional | Standard PII | + +### 3.3 PII Elements — Host Employer Contact + +| Element | Source | Purpose | Mandatory? | Sensitivity | +|---|---|---|---|---| +| Contact name, title | Host | Employer relationship | Yes | Standard PII | +| Business address, phone, email | Host | Correspondence | Yes | Standard PII | +| Worksite supervisor names | Host | Worksite assignment | Yes | Standard PII | +| Signed employer attestations | Host | Compliance with youth-employment rules | Yes | Standard PII | + +### 3.4 PII Elements — DOES / Contracted Staff + +| Element | Source | Purpose | Mandatory? | Sensitivity | +|---|---|---|---|---| +| Name, DOES email | HR feed | Account identity | Yes | Standard PII | +| Role, work unit | HR feed | RBAC assignment | Yes | Standard PII | +| Skill set, geographic area, language skills, availability calendar | HR / staff self-service (source RFP `C.5.21.30`) | Workforce scheduling | Optional | Standard PII | +| Authentication credentials + MFA factors | Entra ID | Authentication | Yes | **Sensitive** | + +### 3.5 Explicitly Not Collected + +- Biometric data (fingerprint, face, voice) — not collected. +- Location tracking (device GPS) — not collected. +- Content of private communications — not collected. +- Health data — **not collected** in steady-state operations. The dormant emergency CSV path is deferred to an emergency-scoped extension with its own PIA addendum before activation (see `YPMS-POAM-053`). + +### 3.6 Collection Method + +- Web/mobile portal (primary channel). +- Server-to-server ingest (CSV via secure file transfer) from OSSE and CFSA. +- API queries to SSA, DC MAR. +- Bidirectional integration with third-party payroll vendor. +- Bidirectional integration with third-party LMS (orientation completion status only; no LMS-owned PII returned). +- Staff-mediated correction and augmentation via the internal portal. + +--- + +## 4. Use of Information + +### 4.1 Primary Uses + +| Use | PII involved | Legal basis | +|---|---|---| +| Determine program eligibility | Age, residency, SSN, foster/ward status, school enrollment, demographics | DC Code Title 32; program-specific rules in RFP Appendix D | +| Verify identity | SSN (via SSA), address (via DC MAR), immigration docs | Employment eligibility; SSA data-exchange agreement | +| Match youth to worksites | Job preferences, resume, availability, geography | DC Code Title 32 | +| Track hours worked and issue payment | Timekeeping, banking, tax data | Employment law; payroll obligations | +| Generate annual tax forms | SSN, wages, withholdings | IRS reporting; via payroll vendor | +| Notify participants | Email, SMS, phone | Programmatic communications per source RFP `C.5.21.4`, `C.5.21.5` | +| Support-service enrollment | Registrant preferences, CFSA foster/ward status where applicable | Program-service delivery | +| Report to USDOL | De-identified or aggregated program participation | Federal grant reporting | +| Statistical / equity analysis | De-identified demographics | Federal grant reporting; internal program improvement | +| Fraud detection | Cross-reference of application data with SSA, wage, and NDNH data | 42 USC §653; SSA data exchange | + +### 4.2 Prohibited Uses (Purpose Limitation) + +- **No use for immigration enforcement.** Immigration-document uploads are collected solely to establish work authorization per federal employment law; they are not shared with immigration enforcement absent a lawful process (subpoena, court order) reviewed by DOES OGC. +- **No use for law enforcement of the child or their family** beyond what is expressly required by DC or federal law. +- **No use for advertising, marketing, or commercial resale.** Data is not sold to third parties. +- **No use of foster/ward status for anything outside categorical eligibility and support-service triage.** Foster/ward flags are not surfaced to host employers or worksite supervisors. +- **No use of school-enrollment records outside eligibility determination.** OSSE-sourced FERPA-covered records are not surfaced to hosts, other agencies, or the public. +- **No use of health records** in steady-state operations; the dormant emergency path is scope-restricted. + +--- + +## 5. Sharing and Disclosure + +### 5.1 Routine Sharing (with executed agreements) + +| Recipient | Data Shared | Direction | Legal / Agreement Basis | +|---|---|---|---| +| **SSA** (Business Services Online) | SSN + selected identity elements | Outbound (query) | SSA Electronic Information Exchange Security Requirements; `YPMS-POAM-022` | +| **OSSE** | Registrant identifiers for enrollment cross-match | Inbound (CSV) | DOES–OSSE data-sharing agreement (FERPA); `YPMS-POAM-020` | +| **CFSA** | Registrant identifiers for foster/ward cross-match | Inbound (CSV) | DOES–CFSA MOU (DC Code Title 4); `YPMS-POAM-021` | +| **DC MAR** | Address strings | Outbound (query) | DC OCTO service agreement | +| **Third-party payroll vendor** | Hours, banking, tax IDs, tax forms | Bidirectional | Vendor contract with DPA/ISA; `YPMS-POAM-023` | +| **Third-party orientation LMS** | Registrant identifier + orientation status flag only | Bidirectional | Vendor contract with DPA | +| **DC OCTO Sentinel / SOC** | Security telemetry (log stream) | Outbound | DC OCTO CISO agreement; `YPMS-POAM-043` | +| **DC NOC** | Availability and change coordination signals | Bidirectional | Internal DOES/OCTO operational | +| **USDOL ETA** | Aggregated / de-identified program reporting | Outbound | Federal grant reporting; ET Handbook 336 | +| **IRS** (indirect, via payroll vendor) | W-2 / 1099 issuance data | Outbound (vendor-mediated) | Payroll vendor handles per IRS specs | +| **National Directory of New Hires (NDNH)** (if scoped in) | Wage/new-hire cross-match | Bidirectional | 42 USC §653 | + +### 5.2 Non-Routine Sharing + +- **Subpoenas, court orders, and lawful investigative demands** are handled by DOES OGC. YPMS provides an audit trail so a specific record's disclosure history is reconstructable. +- **FOIA requests** are handled by DOES OGC with PII redaction; individual PII is never disclosed under FOIA. +- **Breach notification** to individuals and to the DC Attorney General is governed by DC Code §28-3852 and executed under the Incident Response Plan. + +### 5.3 Public-Facing Data + +Public content is limited to: +- Program information (names, descriptions, dates). +- Host-employer job postings (position title, worksite, description, apply link). +- Application forms and static help/training content. +- Aggregated, de-identified counts for press / public reporting. + +**No individual PII is exposed publicly.** No profile pages, no unauthenticated lookup of persons. + +--- + +## 6. Notice and Consent + +### 6.1 Privacy Notice + +- Presented at first youth or host contact with the system (registration flow), before any PII is collected beyond an email address. +- Available in DC Language Access Act–required languages (`YPMS-POAM-081`). +- Discloses: identity of DOES as data controller, categories of PII collected, purposes of collection, categories of recipients (SSA, OSSE, CFSA, payroll vendor), individual rights, retention periods (once set), how to contact the DOES Privacy Officer. +- Version-stamped; changes tracked in system so a record can be tied to the notice version in force at the time of collection. + +### 6.2 Consent — Adult Registrants (18+) + +- Consent obtained at registration by explicit checkbox acknowledgment of the privacy notice. +- Optional-field consents (demographics, resume upload) are separate from mandatory-field consents. +- Consent to share data with the payroll vendor for direct-deposit purposes is a separate opt-in during payroll enrollment. + +### 6.3 Consent — Under-18 Registrants (Parental Co-Consent) + +**Under-18 registrants require parental / guardian consent** for the collection and processing of their PII beyond initial pre-application browsing (`YPMS-POAM-083`). Design constraints: + +- The minor may browse program content and complete a pre-application draft without parental involvement. +- Before eligibility is determined, before SSN is collected, and before any payroll-related activity, a parental consent flow is triggered: + - The minor identifies the parent/guardian and provides their contact information. + - The system sends a verification email/SMS to the parent/guardian with a secure link. + - The parent/guardian creates an account (or authenticates against an existing one) and provides explicit, granular consent. + - The consent record is retained with the minor's application and includes the parent's identity, timestamp, IP, and the version of the notice in force. +- The parent/guardian can view and export their under-18 registrant's data at any time via their portal account. +- Consent can be revoked by the parent/guardian; revocation triggers the individual-rights workflow (§7). + +### 6.4 Consent — Sensitive Data Elements + +- **SSN collection:** disclosed at the point of collection with the specific purpose (SSA cross-match, payroll reporting). Alternate documentation paths accepted where legally permissible. +- **Immigration/work-authorization documents:** disclosed as required by federal employment law; document image encrypted at rest and access-audited. +- **Banking data:** disclosed as required for direct-deposit payroll; not shared with hosts or worksite supervisors. +- **Foster/ward status:** ingested from CFSA; the minor and parent are informed that categorical-eligibility rules use this data for support-service triage; the flag is never displayed to hosts or supervisors. +- **OSSE educational records:** ingested under the DOES–OSSE data-sharing agreement; the minor and parent are informed at registration that DOES verifies school enrollment with OSSE. + +--- + +## 7. Individual Rights + +Youth (or parent/guardian for under-18) and host contacts have the following rights, accessible through the portal. + +| Right | Implementation | +|---|---| +| **Access** — view what YPMS holds | Portal profile view + full record export (source RFP `C.5.7.19`, `C.5.7.21`). | +| **Correction** | Portal profile update (source RFP `C.5.7.19`); staff-assisted correction with audit trail. | +| **Deletion / erasure** | Case-by-case; program-participation records generally retained per records schedule (see §9), but user-generated content (resume, uploaded documents) may be deleted subject to retention rules. Deletion requests routed through DOES Privacy Officer. | +| **Portability** | Export of the individual's record in machine-readable format on request. | +| **Consent withdrawal** | Parent/guardian may revoke consent for under-18 registrants; adult registrants may revoke consent for optional processing. Withdrawal does not affect participation records already generated (which are retained for statutory reasons) but stops further processing where possible. | +| **Complaint** | DOES Privacy Officer contact info in the privacy notice; complaints logged and tracked. | + +**Language access:** all rights are exercisable in DC Language Access Act–required languages. + +--- + +## 8. Data Quality and Integrity + +- **Input validation** at collection: character set, length, numerical range, format (source RFP `C.5.7.44`). +- **Address validation** via DC MAR with user override option (source RFP `C.5.21.47`). +- **SSN validation** via SSA cross-match (source RFP `C.5.6.3.b`). +- **Age eligibility validation** at eligibility determination. +- **User self-service correction** via portal (source RFP `C.5.7.19`). +- **Staff correction** with audit trail (source RFP `C.5.7.15`). +- **Backdated transactions** allowed for authorized users with reprocessing (source RFP `C.5.7.17`); every backdated change is audit-logged with actor identity. +- **Duplicate detection** across programs so a single registrant is not represented as multiple persons; categorical-eligibility reuse (source RFP `C.5.3.3`). +- **Reconciliation** with source-of-record systems on inbound cross-matches (SSA, OSSE, CFSA); mismatches routed to staff review, not silently overwritten. + +--- + +## 9. Retention and Disposal + +`[TBD: aligned with DOES records schedule and OYP program-specific retention; tracked as YPMS-POAM-054.]` Recommended interim posture pending records-officer sign-off: + +| Data class | Interim retention | Rationale | +|---|---|---| +| Program participation records (application, eligibility decision, enrollment, hours worked, payment record) | 7 years after last activity | Aligned with federal wage-and-hour and tax-record retention; supports USDOL audits | +| Uploaded documents (immigration proof, resume, orientation certificates) | 7 years after last activity or 1 year post-program completion, whichever is greater | Retention for compliance disputes | +| Banking data | Retain only through active-payroll relationship; purge at end of participation | Minimize sensitive-PII exposure | +| Consent records (parental and adult) | Match the retention of the record they relate to | Traceability of lawful-basis for any historical processing | +| Audit logs | 1 year online + 3 years archived | Aligned with source RFP `C.5.7.42` and SP 800-53 AU-11 | +| Foster / ward-of-state indicators (CFSA-ingested) | Retain only current-year and one-prior-year; older values purged on annual cadence | Minimize exposure of DC Code Title 4 confidential data | +| OSSE-ingested enrollment records | Retain only current-year and one-prior-year | Minimize FERPA-covered data exposure | +| **Health records (contingent path)** | Not retained in steady state (path is dormant); when activated, retention set in emergency-specific PIA addendum with hard destruction date | Minimize HIPAA-adjacent data exposure | +| Contact channels (email, phone, address) | Retain per participation-record retention; suppressed after opt-out | Deliverability and notification | + +Destruction: encrypted delete plus DB tombstoning; media sanitization inherited from Azure Government. + +--- + +## 10. Security Safeguards + +Full detail is in the SSP (`ypms/SYSTEM_SECURITY_PLAN.md`) and the NIST 800-53 control mapping (`ypms/NIST_800_53_CONTROL_MAPPING.md`). Highlights specifically relevant to privacy: + +- **Encryption in transit:** TLS 1.2+ (target 1.3), FIPS-approved cipher suites (SC-8; `YPMS-POAM-031`). +- **Encryption at rest:** Postgres TDE plus envelope encryption for blob storage; keys in Azure Key Vault (Gov / HSM) (SC-28, SC-12/13; `YPMS-POAM-032`). +- **SSN masking / anonymization** in all display contexts (source RFP `C.5.7.50`; `YPMS-POAM-080`). +- **MFA** for staff and admin (Entra ID conditional access) — above the source-RFP floor (`YPMS-POAM-030`). +- **IAL2-equivalent identity proofing** required before youth registrants can enroll for payroll actions (`YPMS-POAM-033`). +- **Role-based access control** with least privilege; CFSA foster/ward data and OSSE FERPA records reachable only by role-flagged users (AC-6). +- **Audit logging** of all PII interactions (source RFP `C.5.7.39`, `C.5.7.48`). +- **Immediate breach notification** through DOES OIT → DC OCTO CISO chain, followed by a 24-hour internal disclosure report and a 2-business-day remediation report (source RFP `C.5.8.18`–`C.5.8.20` adopted as internal DOES policy). +- **Malicious-code scanning** on all uploaded documents (SI-3). +- **Input validation** and canonicalization (SI-10). +- **Network segmentation** with trusted / transition / untrusted zones (source RFP `C.5.7.23`). +- **Sentinel** SIEM integration for continuous monitoring (`YPMS-POAM-043`). +- **Quarterly personnel-with-data-access roster review** (source RFP `C.5.8.17`). + +--- + +## 11. Auditing and Accountability + +- **Every PII interaction is audit-logged** (source RFP `C.5.7.39`). +- **What/when/where/source/outcome/identity** is captured for every record modification (source RFP `C.5.7.48`). +- **Before-and-after snapshots** are retained for material changes to enable reconstruction (source RFP `C.5.6.9` #8, `C.5.7.49`). +- **Screen-access logs** allow searching who viewed sensitive-data screens (source RFP `C.5.6.9` #5, #7). +- **Backdated transactions** are logged with actor identity and rationale (source RFP `C.5.7.17`). +- **Bulk operations** (bulk group updates, splits, merges — source RFP `C.5.21.40`, `C.5.21.41`) are logged with the actor, the scope, and the change diff. +- **Audit-log tampering protection**: append-only storage design; Sentinel ingestion moves logs to a separate trust boundary. +- **Chris Tonjes (System Owner / ISSO / AO)** reviews privileged-access audit output monthly and posts findings to the POA&M cycle. +- **Independent Control Assessment** annually and before initial ATO (CA-2; `YPMS-POAM-060`). +- **Penetration testing** annually and after major releases (CA-8; `YPMS-POAM-061`). + +--- + +## 12. Privacy Risks and Mitigation + +Load-bearing section. Each risk carries a specific mitigation and a POA&M reference where applicable. + +### 12.1 Population-specific risks + +| Risk | Impact | Mitigation | POA&M | +|---|---|---|---| +| **Minors' data exposed to unauthorized parties** — most registrants are minors, whose PII carries lifelong identity-theft risk if exposed | High | Parental co-consent for under-18 (§6.3); minimization at collection; encryption at rest and in transit; RBAC; audit logging | `YPMS-POAM-083`, `YPMS-POAM-080` | +| **Foster/ward status disclosed to hosts, worksite supervisors, or peers** — DC Code Title 4 confidentiality violation with severe personal impact | High | CFSA flag never displayed to hosts or supervisors; role-scoped access restricted to eligibility/support-service staff; annual purge of older values; audit review of who has viewed CFSA flags | Enforced in RBAC (§5.4 of control mapping); logged per AU-2 | +| **FERPA violation via OSSE-ingested records** — federal law violation with USDOL/USDE consequences | High | OSSE data flows only through eligibility engine, not exposed to hosts or general staff; annual purge of older values; DOES–OSSE agreement scopes permitted uses; audit review | `YPMS-POAM-020` | +| **Immigration-document exposure** — chilling effect on lawful participation, potential harm to the individual | High | Access strictly limited to staff conducting work-authorization review; document image encrypted; access audited; never shared with immigration enforcement absent lawful process reviewed by OGC | Enforced in RBAC and via §4.2 purpose limitation | + +### 12.2 Sensitive-data-element risks + +| Risk | Impact | Mitigation | POA&M | +|---|---|---|---| +| **SSN theft or exposure** — enables identity theft affecting the minor for life | High | SSN masked/anonymized in all display contexts; encrypted at rest and in transit; access strictly limited; audit-logged (source RFP `C.5.7.50`); alternate documentation paths where legally permitted | `YPMS-POAM-080` | +| **Banking data theft** — direct financial harm | High | Encrypted at rest and in transit; passed to payroll vendor via secured integration; retained only through active-payroll relationship; access strictly limited; audit-logged | §9 retention + §10 safeguards | +| **Tax-form data exposure (W-2/1099)** | Moderate | Generated by payroll vendor, not YPMS; YPMS retains only summary references | §5.1 payroll integration | +| **Health-record ingest activated under emergency without proper safeguards** | High if activated poorly | Path is dormant by default; activation requires emergency-scoped PIA addendum, retention schedule, and destruction plan; not in steady-state boundary | `YPMS-POAM-053` | + +### 12.3 Access and authentication risks + +| Risk | Impact | Mitigation | POA&M | +|---|---|---|---| +| **Weak authentication for staff enables unauthorized access to youth data** | High | MFA required for all staff (above source-RFP floor); Entra ID conditional access; lockout after 5 failed attempts | `YPMS-POAM-030` | +| **Social-media identity assertion insufficient for high-impact actions on minors' records** | High | Social-media login limited to browsing / pre-application; IAL2-equivalent proofing required before banking/payroll actions; parental co-authentication considered for under-18 | `YPMS-POAM-033`, `YPMS-POAM-050` | +| **Stale accounts retain access after termination** | Moderate | Auto-disable on inactivity (source RFP `C.5.7.4`); quarterly personnel roster review; termination workflow with same-day access revocation | `YPMS-POAM-071`, `YPMS-POAM-072` | +| **Insider-threat scenarios** — staff or contracted developer with access views records for unauthorized purposes | Moderate | Sensitive-data screen access logged and monitored (source RFP `C.5.6.9` #5); monthly review of privileged-user activity; least-privilege RBAC; DOES personnel-security controls | AU-14, AC-6 | + +### 12.4 Integration and vendor risks + +| Risk | Impact | Mitigation | POA&M | +|---|---|---|---| +| **Payroll vendor breach exposes YPMS-shared PII (banking, SSN, wages)** | High | Vendor SOC 2 / SIG-Lite review before selection; DPA with breach-notification clause; incident-response coordination in contract | `YPMS-POAM-023` | +| **LMS vendor breach exposes orientation-completion linkage** | Low (limited PII shared) | Only registrant identifier + status flag shared; vendor DPA | `YPMS-POAM-023` follow-on for LMS | +| **Social-media IdP receives more info than needed** | Moderate | Minimal-scope OAuth requests (email + basic profile only); no data returned to IdP; not sufficient for payroll actions | `YPMS-POAM-050` | +| **CSV file transfers (OSSE, CFSA) intercepted** | High | Encrypted secure file transfer; source-authenticated; retention minimization on ingested data | §11 SSP interconnections | +| **DC MAR query leaks address by log correlation** | Low | Query is address-only, no other PII; DC OCTO service; TLS-encrypted | §11 SSP | + +### 12.5 Governance and process risks + +| Risk | Impact | Mitigation | POA&M | +|---|---|---|---| +| **Role concentration** — Chris Tonjes as System Owner + ISSO + AO reduces independent risk-acceptance | Moderate | Independent Control Assessment (annually) and pentest provide external technical validation; DC OCTO CISO and USDOL/OIG oversight provide external accountability; SSP §5 records the acceptance | SSP §5 risk-acceptance note | +| **PIA not updated as system evolves** | Moderate | PIA refreshed on every material change; at minimum annually; incorporated into POA&M review | §13 approval cadence | +| **FOIA response inadvertently discloses PII** | Moderate | DOES OGC review before every FOIA release; PII-redaction guidance in FOIA workflow | `YPMS-POAM-102` | +| **Records-schedule not aligned; retention drifts** | Low | Formalize retention with DOES records officer before Go-Live; automated retention purges | `YPMS-POAM-054` | + +--- + +## 13. PIA Review and Approval + +| Role | Name | Signature | Date | +|---|---|---|---| +| System Owner (DOES CIO) | Chris Tonjes | | | +| Information System Security Officer | Chris Tonjes | | | +| DOES Privacy Officer | `[TBD]` | | | +| DOES OGC representative | `[TBD]` | | | +| Business Owner (OYP) | `[TBD]` | | | +| Authorizing Official | Chris Tonjes (per SSP §5 role-concentration note) | | | + +**Review cadence:** PIA is refreshed on every material change to PII collected, purposes of processing, sharing, retention, or safeguards. At minimum, PIA is reviewed annually against SSP and control mapping revisions. + +--- + +**End of draft v0.1.** diff --git a/SYSTEM_SECURITY_PLAN.md b/SYSTEM_SECURITY_PLAN.md new file mode 100644 index 0000000..b2eb761 --- /dev/null +++ b/SYSTEM_SECURITY_PLAN.md @@ -0,0 +1,742 @@ +# System Security Plan (SSP) +## Youth Program Management System (YPMS) + +**Document Version:** 0.3 (Draft — in-house build reframe) +**Date:** 2026-09-30 +**Classification:** Controlled Unclassified Information (CUI) — internal DOES use only +**Status:** Pre-Development / Pre-Authorization (drafting alongside team formation and architecture) + +> **Drafting note.** YPMS is an **in-house build** by DOES OIT, matching the DCYWP / OWC / Employer 360 delivery pattern. This SSP derives functional and security requirements from the prior YPMS RFP (Solicitation `Docxxxxx`, April 2025) — its C.5.7 Security Requirements catalogue (54 requirements), C.5.6 Infrastructure Requirements, C.5.8 Database Requirements, and Attachment E Additional Non-Functional Requirements — as **source specifications**, not as Contractor obligations. Ownership of controls sits with DOES OIT (implementation), DC OCTO enterprise services (some Hybrid), and Azure Government FedRAMP High (Inherited for physical, environmental, and low-level infrastructure). Items marked **`[TBD]`** require completion by DOES leadership before ATO submission. Where a source-RFP requirement is load-bearing for a control statement, its identifier (e.g., `C.5.7.9`) is cited inline so a reviewer can trace SSP text back to the source spec. Companion documents referenced below live as siblings in `ypms/`. + +--- + +## Table of Contents + +1. [System Identification](#1-system-identification) +2. [System Categorization (FIPS 199)](#2-system-categorization-fips-199) +3. [System Owner and Authorizing Official](#3-system-owner-and-authorizing-official) +4. [Other Designated Contacts](#4-other-designated-contacts) +5. [Assignment of Security Responsibility](#5-assignment-of-security-responsibility) +6. [System Operational Status](#6-system-operational-status) +7. [Information System Type](#7-information-system-type) +8. [General System Description](#8-general-system-description) +9. [System Environment and Boundary](#9-system-environment-and-boundary) +10. [Information Types](#10-information-types) +11. [System Interconnections](#11-system-interconnections) +12. [Related Laws, Regulations, and Policies](#12-related-laws-regulations-and-policies) +13. [Privacy Considerations](#13-privacy-considerations) +14. [Minimum Security Controls](#14-minimum-security-controls) +15. [Continuous Monitoring](#15-continuous-monitoring) +16. [Plan Approval](#16-plan-approval) +17. [Appendices](#17-appendices) + +--- + +## 1. System Identification + +| Field | Value | +|---|---| +| **System Name** | Youth Program Management System | +| **System Acronym** | YPMS | +| **System Identifier** | `[TBD: DOES-issued system ID per DC OCTO inventory]` | +| **Operating Organization** | District of Columbia, Department of Employment Services (DOES) | +| **Operating Component** | Office of Youth Programs (OYP) — business owner / Office of Information Technology — technical owner and implementer | +| **Delivery Model** | **In-house build by DOES OIT** on Azure Government, matching the OWC pattern. Stack: **Python 3.12 / FastAPI / SQLAlchemy / Postgres**, decision recorded 2026-09-30. | +| **Information System Abstract** | Centralized DOES-owned system replacing a fragmented set of legacy tools (Host/Participant Application, Scanning Application, Transfer Application, TMS, MicroStrategy, People First PF3 "backdoor" admin tool, and manual payroll scripts). Automates OYP business processes end-to-end: Online Youth Applications, Eligibility, Certification, Orientation (via LMS integration), Job Matching, Program Enrollments, Host Registration, third-party Payroll distribution, Worksites/Positions Management, Job Postings, Online Time Management, Reports, and Admin Functions. Serves programs MBSYEP, HSIP, MBYLI (SIT/SYP/Global Education), CRESP, and future OYP programs. Target Go-Live: **beginning of FY2027** per source RFP `C.5.2.11`; effective slip acknowledged pending team formation, stack decision, and iterative build. | + +--- + +## 2. System Categorization (FIPS 199) + +Determined per FIPS 199 *Standards for Security Categorization of Federal Information and Information Systems* and FIPS 200 *Minimum Security Requirements for Federal Information and Information Systems*. YPMS processes information subject to categorization guidance in NIST SP 800-60 Vol. II for youth workforce, benefits, and PII information types. + +### 2.1 Security Objectives + +| Security Objective | Categorization | Rationale | +|---|---|---| +| **Confidentiality** | **Moderate** (with High-sensitivity subsets — see note) | YPMS collects PII on **minors** (registrants ages 14–24, including under-18 participants), SSN (masked/anonymized per `C.5.7.50` but stored for SSA cross-match per `C.5.6.4`), DOB, residential address, parent/guardian contact, banking information for payroll (`C.5.3.8`), tax information, school enrollment records ingested from OSSE (subject to **FERPA**), CFSA records identifying wards of the state and foster youth (`C.5.6.3.a.3`), and — under contingency scenarios — health records ingested by CSV (`C.5.6.3.a.2`). Loss of confidentiality would cause significant harm to minors including identity-theft risk, unauthorized disclosure of foster/ward status, and FERPA-covered educational record exposure. | +| **Integrity** | **Moderate** | Eligibility determinations control access to paid summer employment for DC minors; wage payments are computed by YPMS-adjacent payroll integration (`C.5.3.8`) with tax-form generation. Unauthorized modification of eligibility flags, hours-worked records, employer registrations, or payroll transmissions could enable wage fraud, wrongful denial of eligibility, or IRS reporting errors. Backdated transactions and reprocessing are allowed (`C.5.7.17`) — heightened integrity controls needed on that path. | +| **Availability** | **Moderate** | Target SLA (adopted from source RFP `C.5.6.17`) is **99.5% in any rolling 30 days** — ≤ 43.2 minutes/month of unplanned downtime. Program impact is seasonally peaked: MBSYEP application windows and payroll cycles are hard deadlines for youth compensation. 24×7 operability required (`C.5.6.10`). | + +### 2.2 Overall System Categorization + +**Moderate Impact** (highest of the three security objective categorizations, per FIPS 199 §3). + +> **Note on High-sensitivity data subsets.** Three data classes elevate risk above a typical Moderate profile and require compensating controls even where the aggregate rating remains Moderate: +> 1. **FERPA educational records** ingested from OSSE (`C.5.6.3.a.1`) — treated per FERPA and the DOES–OSSE data-sharing agreement. +> 2. **CFSA foster-care / ward-of-state records** (`C.5.6.3.a.3`) — DC Code Title 4 confidentiality applies; access strictly limited on need-to-know. +> 3. **Contingent health records** (COVID-era CSV pathway per `C.5.6.3.a.2`) — HIPAA-adjacent; DOES is not a covered entity for these, but reasonable safeguards apply and the ingest path is dormant except during declared emergencies. +> +> The initial FIPS 199 categorization memo (`ypms/FIPS_199_MEMO.md` — to be authored) records the AO's disposition on whether any of these subsets warrant a High-water-mark categorization for the whole system. + +### 2.3 Applicable Control Baseline + +**NIST SP 800-53 Rev. 5 Moderate baseline**, tailored as documented in §14. Explicitly cited by the RFP: +- **NIST SP 800-53** (`C.5.7.51`, RFP §C.2 Item 10). +- **NIST SP 800-171 Rev. 2** for CUI protection (RFP §C.2 Item 4). +- **FIPS 140-2** for cryptographic modules protecting authenticators and data (RFP §C.2 Item 9; `C.5.7.9`) — implementers should validate to **FIPS 140-3** where available (FIPS 140-2 is sunset, though existing validations remain accepted for a defined window). + +Overlays under consideration: +- **PII overlay** (SP 800-53 privacy family — PT/PM). +- **FERPA overlay** for OSSE-sourced educational records. +- **PCI DSS** (`C.5.6.19`) — only if YPMS processes card-present or card-not-present transactions; scope reduction preferred (payroll is ACH via vendor; expected out of scope). See open question §17.E. +- **SSA Electronic Information Exchange requirements** (`C.5.6.4`). +- **DC OCTO IT Security Policy** (`C.5.7.53`, source RFP §C.2 Item 3). + +--- + +## 3. System Owner and Authorizing Official + +### 3.1 System Owner + +| Field | Value | +|---|---| +| **Name** | Chris Tonjes | +| **Title** | DOES Chief Information Officer | +| **Organization** | DC Department of Employment Services | +| **Address** | 4058 Minnesota Avenue NE, Washington, DC 20019 | +| **Phone** | (202) 724-7000 | +| **Email** | ctonjes@gmail.com | + +### 3.2 Authorizing Official (AO) + +| Field | Value | +|---|---| +| **Name** | Chris Tonjes | +| **Title** | DOES Chief Information Officer, acting as Authorizing Official (see §5 role-concentration note) | +| **Organization** | DC Department of Employment Services | +| **Address** | 4058 Minnesota Avenue NE, Washington, DC 20019 | +| **Phone** | (202) 724-7000 | +| **Email** | ctonjes@gmail.com | + +--- + +## 4. Other Designated Contacts + +| Role | Name | Phone | Email | +|---|---|---|---| +| Information System Security Officer (ISSO) | Chris Tonjes (see §5 role-concentration note) | (202) 724-7000 | ctonjes@gmail.com | +| Privacy Officer | `[TBD]` | `[TBD]` | `[TBD]` | +| Business Owner — Office of Youth Programs | `[TBD]` | `[TBD]` | `[TBD]` | +| DOES OIT Delivery Lead | `[TBD]` | `[TBD]` | `[TBD]` | +| DOES OIT Backend Engineer(s) | `[TBD]` | `[TBD]` | `[TBD]` | +| DOES OIT Frontend Engineer(s) | `[TBD]` | `[TBD]` | `[TBD]` | +| DOES OIT Data/Integration Engineer (owns OSSE, CFSA, SSA, DC MAR, payroll integrations) | `[TBD]` | `[TBD]` | `[TBD]` | +| DOES OIT Test/QA Lead | `[TBD]` | `[TBD]` | `[TBD]` | +| DOES OIT Database Team Lead | `[TBD]` | `[TBD]` | `[TBD]` | +| DC OCTO Cloud Coordination POC | `[TBD]` | `[TBD]` | `[TBD]` | +| DC NOC POC | `[TBD]` | `[TBD]` | `[TBD]` | +| DC OCTO SOC POC (Sentinel) | `[TBD]` | `[TBD]` | `[TBD]` | +| Payroll Vendor Security POC | `[TBD]` — on vendor selection | `[TBD]` | `[TBD]` | + +--- + +## 5. Assignment of Security Responsibility + +> **Role-concentration note (accepted risk).** Chris Tonjes (DOES CIO) currently holds three roles for YPMS: System Owner, ISSO, and Authorizing Official. FISMA practice usually separates the AO from the system owner and ISSO to preserve independent risk acceptance. DOES is a District agency and the DC CIO / OCTO structure does not require an external AO for agency-scoped systems; the DOES CIO has authority to accept residual risk on behalf of the agency. This concentration is accepted for the initial ATO on the basis that (a) DOES's parent oversight — DC OCTO CISO, USDOL ETA, and OIG when applicable — provides external accountability outside the SSP process, and (b) the initial and annual independent Control Assessments (see §14.4 CA-2) are commissioned from an independent party, giving external technical validation independent of the AO. Future revisions may designate the DOES Director or a peer CIO as AO if a federal partner or OIG review requires strict role separation. + +| Function | Responsible Party | +|---|---| +| Overall security responsibility | Chris Tonjes, DOES CIO (System Owner) | +| Day-to-day security operations | Chris Tonjes, ISSO | +| Application security | DOES OIT delivery team, under DOES CIO direction | +| Infrastructure and Azure Government tenant security | DOES OIT, coordinated with DC OCTO per source RFP `C.5.6.14` | +| Incident response | DC OCTO CISO Office + DOES OIT (per DC government IRP); breach-notification SLAs derived from source RFP `C.5.8.18`–`C.5.8.20` and adopted as internal DOES policy | +| SIEM operations | DOES OIT ships logs to DC OCTO Sentinel per `YPMS-POAM-043` | +| Personnel security / background checks | DOES HR for DOES staff and any contracted individual developers; DC OCTO clearance requirements apply | +| Physical / environmental security | Inherited from Azure Government FedRAMP High authorization | +| Data-access reporting | DOES OIT maintains and reviews a full list of personnel with production data access, updated at least quarterly with additions and deletions tracked | +| Unauthorized-disclosure notification | DOES OIT to DC OCTO CISO **immediately** on awareness; full disclosure report within **24 hours**; remediation report within **2 business days**. Federal-agency notifications on top per Privacy Act and SSA/OSSE/CFSA agreement terms. | + +--- + +## 6. System Operational Status + +**Pre-Development** as of 2026-09-30. No code exists yet. This SSP reflects the target-state YPMS post-build. Interim state during migration: + +- Legacy components (Host/Participant Application, Scanning Application, Transfer Application, TMS, MicroStrategy, PF3, Manual Payroll scripts) remain in operation until superseded by phased YPMS releases. +- Delivery is Agile, matching OWC's phased approach (see `owc-system/PHASE*_PLAN.md` for the reference pattern). +- **Go-live milestone per source RFP**: major features required for FY 2026 MBSYEP in production by FY 2027 MBYLI school-year registration kick-off; Go-Live at beginning of FY 2027. Effective slip acknowledged pending team formation and architecture kickoff. + +Each phase gate triggers an SSP refresh; this document uses semantic versioning (v0.x pre-ATO, v1.0 at initial ATO). + +--- + +## 7. Information System Type + +- **Major Application** (per NIST SP 800-18 Rev. 1 §2.5). YPMS is a distinct, funded, mission-critical application supporting DOES's statutory obligation to administer District youth employment and workforce-development programs under DC Code Title 32, Chapter 2, Subchapters II and V. +- YPMS is a **DOES-built, DOES-operated application** on Azure Government. Underlying compute, network, storage, identity, and physical/environmental controls are inherited from Azure Gov's FedRAMP High authorization. Application code is written and maintained by DOES OIT. + +--- + +## 8. General System Description + +### 8.1 Purpose and Scope + +YPMS is the centralized platform for all Office of Youth Programs (OYP) programs, replacing seven legacy tools and a manual payroll process. It supports application intake, eligibility determination, certification events, orientation tracking, job matching and postings, host/employer registration, worksite and position management, online time management, third-party payroll issuance, and reporting. + +### 8.2 Programs Supported + +| Program | Description | +|---|---| +| **MBSYEP** — Marion S. Barry Summer Youth Employment Program | Locally-funded subsidized summer placements for DC youth ages 14–24. Highest peak-load driver. | +| **HSIP** — High School Internship Program | School-year academic enrichment, work-readiness, project-based learning for grades 9–12 (ages 14–18). | +| **MBYLI** — Marion Barry Youth Leadership Institute | Year-round leadership program including Summer Intensive Training (SIT), School Year Program (SYP), and Global Education Program. | +| **CRESP** — Career Ready Early Scholars Program | Middle-school career exploration across 11 tracks (athletics, business, law/global affairs, culinary, agricultural sciences, engineering/design, language arts, STEM, social science/humanities, visual/performance arts, public speaking). | +| **Future OYP programs** | System must accept new program definitions from application through completion (`C.5.3.1`). | + +> **Definitional note.** The RFP glossary defines "Youth" as "DC resident participants between 99 – 24 years old" (RFP §C.3.1). This is a typographical error; the operative program-eligibility ranges are 14–24 (MBSYEP) and 14–18 (HSIP) with middle-school participants in CRESP. Age band should be corrected in the awarded specification. + +### 8.3 User Populations (per `C.5.6.21`) + +| Population | Est. Volume | Access Channel | +|---|---|---| +| DOES Users (internal staff and contracted individual developers, plus DOES-approved vendor users) | 90 | Authenticated internal portal; SSO / DOES global directory (`C.5.3.2`) | +| Host Employers (active, inactive, registering) | 1,500 | Web portal with self-registration | +| Youth (registering and participating) | 27,000 | Web portal; social-media login supported (`C.5.3.2`); minors, some under 18 | +| Parents / Guardians | 7,400 | Web portal | +| Other agencies | 100 | Web portal or interconnection | +| **Total** | **36,000** | — | + +Scaling target: **50% growth per year** (`C.5.6.20`). + +### 8.4 Functional Capabilities (summary from C.5.3–C.5.6) + +- Online youth applications, saved-and-resumed, with demographic, job-preference, education, financial literacy, banking, tax, and supporting documents. +- Auto-eligibility with rules-driven categorical eligibility (`C.5.3.3`, Appendix D). +- Certification event management with document upload. +- Youth account dashboards, resume builder, job search, program/support-service recommendation. +- LMS integration for orientation tracking (`C.5.3.4`). +- Host/employer application, worksite management, job posting. +- Online time management with third-party payroll integration (`C.5.3.8`). +- Tax-form generation (annual) via payroll integration. +- Transportation-voucher tracking. +- Reports and MicroStrategy replacement. +- Admin functions with role-based access. +- 24×7 operability (`C.5.6.10`). +- <1 second response time (`C.5.6.27`). +- Modern browser support: latest Chrome, Edge, Safari, Opera (`C.5.6.11`). +- Multi-environment: minimum two lower + production (`C.5.5.1`). + +--- + +## 9. System Environment and Boundary + +### 9.1 Authorization Boundary + +The YPMS authorization boundary includes: + +1. DOES-authored YPMS application source code and container images (hosted in the DOES git repository under `ypms/`). +2. Azure Government tenant (compute, network, storage) housing YPMS. +3. Development, test, and production environments (minimum two lower + production per source RFP `C.5.5.1`); dev and test sanitized of production PII. +4. YPMS application databases (Postgres flexible server on Azure Gov). +5. YPMS-issued APIs and web services (per source RFP `C.5.8.15`). +6. YPMS-generated audit logs shipped to DC OCTO Sentinel. +7. Encrypted backups (Azure-managed, tested restore). +8. Emerging-technology components (Generative AI / ML / NLP) if enabled, constrained to the DOES domain (source RFP `C.5.6.31`, `C.5.6.32`, `C.5.7.54`) — deferred; tracked as `YPMS-POAM-103`. + +**Explicitly out of boundary (but interconnected — see §11):** + +- Third-party payroll management system. +- DC MAR (address verification). +- SSA Business Services Online (SSN verification, wage data). +- OSSE (school enrollment records). +- CFSA (foster / ward-of-state indicators). +- Third-party orientation LMS. +- Social-media identity providers used for youth login (`C.5.3.2`). +- DOES global directory / SSO for staff. +- DC OCTO SOC / NOC. +- Emergency health-record CSV source (dormant path per `C.5.6.3.a.2`). + +### 9.2 Hosting Environment + +**Azure Government Cloud** (aligned with OWC and Employer 360). DOES coordinates cloud infrastructure with DC OCTO per source RFP `C.5.6.14`. DOES OIT delivers architecture diagrams and technical requirements to OCTO before each significant deployment. + +Physical, environmental, media protection, and low-level infrastructure controls are inherited from Microsoft's **FedRAMP High** authorization for Azure Government. DOES OIT hardens tenant-level configuration to at least the CIS Microsoft Azure Foundations Benchmark plus DOES-specific overlays. + +### 9.3 Network Architecture (target) + +`[TBD: DOES OIT to deliver as part of the architecture document — tracked as `YPMS-POAM-040`.]` Source RFP mandates that carry over: + +- Trusted-zone / transition-zone / untrusted-zone segmentation (`C.5.7.23`). +- Redundant systems at each tier to eliminate single points of failure (`C.5.6.18`). +- Load distribution across multiple hosting platforms for failover (`C.5.6.29`). +- Failover to a remote site for patching without service interruption (`C.5.6.13`). +- 99.5% availability SLA (`C.5.6.17`). +- IDS/IPS with alerting (`C.5.7.26`). +- SIEM with configurable aggregation and alerting (`C.5.6.9` #19–23). + +### 9.4 Software Baseline (target) + +| Layer | Component | Notes | +|---|---|---| +| Application platform | **Python 3.12 / FastAPI** (matching OWC). | Confirmed 2026-09-30. | +| ORM / DB access | **SQLAlchemy 2.x** with Alembic migrations. | Matches OWC. | +| Frontend | Server-rendered Jinja2 templates plus HTMX (matching OWC), with progressive-enhancement JS where needed. | Public youth/host portal may require richer client — decision at architecture phase. | +| Database | **PostgreSQL flexible server on Azure Gov** (private endpoint). | Data dictionary and physical model per source RFP `C.5.8.4`, `C.5.8.5`, `C.5.8.7`. | +| Cryptographic module | FIPS 140-3 validated (140-2 acceptable during deprecation window). | Managed via Azure Key Vault (Gov / HSM). | +| Directory / identity — internal (staff) | **Entra ID** (DOES tenant); conditional access with MFA. | LDAP-compliant per source RFP `C.5.7.30`. | +| Identity — external (host / youth) | Entra External ID or equivalent; social-media login optional for browsing. | See open question §17.D. | +| Payroll integration | Third-party payroll vendor. | Vendor selection tracked as `YPMS-POAM-023`. | +| LMS integration | Third-party orientation LMS. | Vendor `[TBD]`. | +| Endpoint (internal user) | DOES-issued device with DC OCTO baseline. | Compliant with DC OCTO IT policy (source RFP `C.5.6.30`, `C.5.7.53`). | +| Emerging-tech (optional) | GenAI/ML/NLP components, constrained to DOES domain. | Deferred; tracked as `YPMS-POAM-103`. | + +--- + +## 10. Information Types + +Per NIST SP 800-60 Vol. II mission-based information type mapping, tailored for YPMS: + +| Information Type | 800-60 Ref | C | I | A | Notes | +|---|---|---|---|---|---| +| Personal Identity and Authentication | C.2.8.1 | M | M | L | Youth PII: name, SSN, DOB, address, parent/guardian contact. | +| Youth Development / Workforce Investment | C.3.4.5 | M | M | M | Program participation, eligibility, hours worked. | +| Benefits Administration | C.3.4.2 | M | M | M | Wage subsidy issuance via payroll integration. | +| Revenue Collection (tax reporting) | C.3.4.3 | M | M | L | Annual W-2 / tax forms generated. | +| Educational Records (FERPA) | C.3.1.2 | **M–H** | M | L | OSSE school enrollment; access strictly limited. | +| Social Services (foster / ward status) | C.3.4.7 | **H** | M | L | CFSA data — DC Code Title 4 confidentiality. | +| Health Information (contingent) | C.3.3.2 | **H** | M | L | Dormant unless emergency-declared per `C.5.6.3.a.2`. | +| Information Management | C.3.1.3 | M | M | M | Case, workflow, notification, audit logs. | + +**Provisional aggregate categorization: Moderate**, with High-sensitivity data class handling documented in §13 and enforced by role-based least-privilege access under §14.1. + +--- + +## 11. System Interconnections + +Interconnection Security Agreements (ISAs) or equivalent MOUs to be drafted per NIST SP 800-47 Rev. 1 for each of the following. + +| Interconnected System | Direction | Data | Boundary Protection | Authority | +|---|---|---|---|---| +| Third-party Payroll Management System | Bidirectional | Hours worked, banking, tax IDs, payroll runs, tax forms | HTTPS + certificate-pinning per source RFP `C.5.6.5`; FIPS-approved crypto | Vendor agreement + ISA `YPMS-POAM-023` | +| SSA (Business Services Online) | Outbound | SSN and identity elements for verification | Per SSA Electronic Information Exchange Security Requirements (`C.5.6.4`) | SSA data-exchange agreement | +| OSSE — School Enrollment | Inbound CSV (`C.5.6.3.a.1`) | Student unique identifiers, enrollment status | Secure file transfer `[TBD]` | DOES-OSSE data-sharing agreement — must reference FERPA | +| CFSA — Foster / Ward Indicators | Inbound CSV (`C.5.6.3.a.3`) | Ward-of-state, foster status | Secure file transfer `[TBD]` | DOES-CFSA MOU — DC Code Title 4 | +| Third-party Orientation LMS | Bidirectional | Youth orientation completion status | HTTPS API | Vendor agreement `[TBD]` | +| DC MAR (Address Verification) | Outbound query | Address strings for validation | HTTPS | DC OCTO service agreement | +| DOES SSO / Global Directory | Outbound authn | Staff identity assertions | LDAP over TLS (`C.5.7.30`) | Internal DOES/OCTO | +| Social-media Identity Providers (youth login) | Inbound authn | OAuth-style identity assertions | HTTPS, provider-hosted | See §17.D open question — risk documented | +| Emergency Health-Record CSV Source (dormant) | Inbound CSV (`C.5.6.3.a.2`) | Health records under emergency declaration only | Secure file transfer `[TBD]` — activated only under declared emergency | Emergency-specific MOU `[TBD]` | +| DC OCTO SIEM / SOC | Outbound telemetry | Security event log stream (`C.5.6.9` #19–20) | Encrypted syslog / API | DC OCTO CISO agreement | +| DC NOC | Bidirectional operational | Availability and change coordination (`C.5.6.17`) | Ticketing/paging | Internal DC OCTO | +| IRS (indirect, via payroll vendor) | Outbound | W-2 / 1099 issuance | Payroll vendor handles per IRS specs | Vendor-mediated | +| DOES-authored `ypms/` doc set | Internal | Requirements, SSP, control mapping, POA&M, PIA, IRP, CP, RoB | DOES-managed git repo | Internal | + +--- + +## 12. Related Laws, Regulations, and Policies + +### 12.1 Federal +- Federal Information Security Modernization Act (FISMA), 44 USC §3551 et seq. +- NIST SP 800-53 Rev. 5 — cited by `C.5.7.51` and RFP §C.2 Item 10. +- NIST SP 800-171 Rev. 2 — RFP §C.2 Item 4. +- NIST SP 800-37 Rev. 2 (RMF). +- FIPS 199 / FIPS 200 categorization. +- FIPS 140-2 (with FIPS 140-3 forward alignment) — RFP §C.2 Item 9 and `C.5.7.9`. +- Family Educational Rights and Privacy Act (FERPA), 20 USC §1232g — for OSSE-sourced records. +- Privacy Act, 5 USC §552a — RFP §C.2 Item 7. +- Section 1106 of the Social Security Act — RFP §C.2 Item 7. +- Health Insurance Portability and Accountability Act (HIPAA) — reasonable-safeguards alignment for the dormant health-record path (DOES not a covered entity for these records). +- Fair Labor Standards Act (FLSA) — youth employment provisions inform hours/eligibility rules. +- Section 508 of the Rehabilitation Act (§C.2 Item 6) and WCAG 2.1 AA. +- IEEE Standard 828-2012 — Configuration Management (RFP §C.2 Item 8). +- PCI DSS (`C.5.6.19`) — if card payments are in scope. + +### 12.2 District +- DC Code Title 32, Chapter 2, Subchapters II and V (Mayor's Youth Leadership Institute) — RFP §C.2 Items 1–2. +- DC Code Title 4 — CFSA confidentiality. +- DC OCTO Technical Policy, Requirements, and Standards — RFP §C.2 Item 3, `C.5.7.53`, `C.5.6.8`. +- DC Language Access Act of 2004 — RFP §C.2 Item 5. +- DC OCTO IT Security Policy (current version). +- DC Public Records / FOIA (DC Code §2-531 et seq.). + +### 12.3 Standards and Guidance +- OWASP ASVS Level 2 (target for DOES OIT delivery). +- OWASP API Security Top 10 — `C.5.8.15` APIs. +- SANS Information Logging Standard — `C.5.6.9` #18. +- SSA Electronic Information Exchange Security Requirements — `C.5.6.4`. + +--- + +## 13. Privacy Considerations + +A Privacy Impact Assessment (PIA) will be authored in parallel to this SSP as `ypms/PRIVACY_IMPACT_ASSESSMENT.md`; findings that alter the boundary or control set are reflected here at each revision. + +- **PII collected**: name, SSN, DOB, address(es), phone(s), email, parent/guardian contact, employment history, banking (for payroll direct deposit), tax information, education records (from OSSE), foster/ward status (from CFSA), resume content, application answers, hours worked, orientation completion. +- **Sensitive PII**: SSN, banking, foster/ward status, contingent health records. +- **Minors**: A majority of registrants are minors. All PII-handling defaults must reflect this (data minimization, parental consent workflows where required, no dark-pattern retention). +- **Legal basis**: DC Code Title 32; DOES statutory responsibility for youth workforce programs. +- **Minimization**: Category-eligible determinations should reuse data across programs (`C.5.3.3`) rather than re-collecting; the RFP anticipates this. +- **SSN handling**: SSN must be masked/anonymized in display contexts (`C.5.7.50`) and encrypted at rest and in transit (`C.5.7.25`). +- **Retention**: `[TBD]` — align with DOES records schedule and OYP program-specific retention. Backups delivered to DOES daily per `C.5.8.21` — retention of those backups is DOES's responsibility once received. +- **Notice**: Privacy notice presented at first youth/host contact; parental notice where the registrant is a minor. +- **Individual participation**: Users can view and update profile records (`C.5.7.19`, `C.5.7.21`, `C.5.7.22`). +- **Language access**: DC Language Access Act obligations (§12.2) — notices and portal content in required languages. +- **Emergency health-record path**: dormant by default. Activation requires a separate emergency-scoped PIA addendum, retention schedule, and destruction plan. + +--- + +## 14. Minimum Security Controls + +This section documents the NIST SP 800-53 Rev. 5 Moderate baseline as tailored for YPMS. Full control statements are maintained in `ypms/NIST_800_53_CONTROL_MAPPING.md`, analogous to the DCYWP `NIST_800_53_CONTROL_MAPPING.md`. The summary below records the tailoring rationale for each family and identifies which side of the line (DOES OIT / Hybrid / Inherited from Azure Gov or DC OCTO / Organizational) each control lives on. Cross-references to specific source-RFP requirements (`C.5.x.y`) are load-bearing: every control listed here has at least one source-RFP requirement it responds to; the full inverse index is in **Appendix C**. + +Legend: `DOES OIT` (DOES OIT implements and operates in the YPMS codebase and Azure tenant), `Hybrid` (DOES OIT + DC OCTO enterprise services), `Inherited` (from Azure Government FedRAMP High or DC OCTO enterprise), `Organizational` (DOES policy/process/training). + +### 14.1 Access Control (AC) + +- **AC-2 Account Management** — *DOES OIT.* Admin capability to enable/disable users (`C.5.7.5`), auto-disable after inactivity (`C.5.7.4`), unique user IDs no shorter than 12 alphanumeric characters (`C.5.7.7`), no re-issue of deleted or previously-assigned user IDs (`C.5.7.47`). +- **AC-3 Access Enforcement** — *DOES OIT.* Server-side authorization on every action (`C.5.7.27`); admin-only view/change of access rights (`C.5.7.28`); group- and user-level assignment (`C.5.7.29`); real-time and scheduled access-change effectivity (`C.5.7.31`). +- **AC-4 Information Flow Enforcement** — *DOES OIT.* Trusted/transition/untrusted zone segmentation (`C.5.7.23`); untrusted systems cannot reach trusted-zone systems directly. +- **AC-6 Least Privilege** — *DOES OIT.* Role-based access control (`C.5.7.32`, `C.5.7.34`); one login per staff user with role-mediated function access (`C.5.7.33`). Separation of duties: youth-facing self-service (`C.5.7.20`) separated from admin bulk-update paths; CFSA/OSSE data reachable only by role-flagged users. +- **AC-7 Unsuccessful Logon Attempts** — *DOES OIT.* Lockout after 5 attempts (`C.5.7.10`); revoked-access notification (`C.5.7.11`). +- **AC-8 System Use Notification** — *DOES OIT.* Notification before granting access (`C.5.7.37`). +- **AC-11 Session Lock / AC-12 Session Termination** — *DOES OIT.* Idle-timeout session expiry with re-authentication (`C.5.7.3`). +- **AC-17 Remote Access** — *DOES OIT.* All access is remote by architecture; MFA required for staff and admin (see IA-2). +- **AC-19 Access Control for Mobile Devices** — *DOES OIT.* Mobile-platform design conforms to encryption, access control, and application security principles (`C.5.7.35`); endpoints comply with DC OCTO policy (`C.5.6.30`). +- **AC-20 Use of External Systems** — *Hybrid.* Governs employer/host access and third-party integrations (payroll, LMS, social-media login). +- **AC-22 Publicly Accessible Content** — *DOES OIT.* Public content reviewed before publication. + +### 14.2 Awareness and Training (AT) + +- **AT-2 / AT-3 / AT-4** — *Hybrid.* DOES annual security awareness; role-based training for OYP staff (adjudication, eligibility, payroll admin) and any contracted individual developers. Training program derived from source RFP `C.5.9`. + +### 14.3 Audit and Accountability (AU) + +- **AU-2 Event Logging** — *DOES OIT.* Comprehensive event list from `C.5.7.39`: all root/admin actions, audit-log access/modification, successful and unsuccessful logon attempts, password changes, system-level object create/delete, all interactions with PII or other sensitive data, plus organization-defined additional events. Role changes, system shutdown/restart, file access authorized and unauthorized, and user logon events per `C.5.6.9` #4. +- **AU-3 Content of Audit Records** — *DOES OIT.* What/when/where/source/outcome/identity per `C.5.7.48`; sufficient detail to reconstruct events (`C.5.7.49`); user identification and timestamp captured on any create/modify/delete (`C.5.7.15`); unique transaction number per transaction (`C.5.6.9` #11); before-and-after transaction history (`C.5.6.9` #8); communication send/access logging (`C.5.6.9` #12, #13). +- **AU-4 Storage Capacity** / **AU-5 Response to Audit Logging Process Failures** — *DOES OIT.* Alerts to admins and additional roles on security compromise (`C.5.7.26`); user-account lockout alerts (`C.5.6.9` #23). +- **AU-6 Audit Review, Analysis, and Reporting** — *Hybrid.* SIEM with configurable aggregation into meaningful security intelligence (`C.5.6.9` #19–20); alerts/notifications on business-rule and workflow thresholds (`C.5.6.9` #21–22). +- **AU-8 Time Stamps** — *DOES OIT.* All critical system times synchronized (`C.5.7.40`). +- **AU-9 Protection of Audit Information** — *DOES OIT.* Audit information and audit tools protected from unauthorized access, modification, and deletion (`C.5.7.41`); role-based access to audit logs (`C.5.6.9` #6). +- **AU-11 Audit Record Retention** — *Hybrid.* Organization-defined retention (`C.5.7.42`); `[TBD]` — minimum recommendation one year online, three years archive. +- **AU-12 Audit Record Generation** — *DOES OIT.* Automated audit trails for all system components (`C.5.7.39`); system-generated security audit trail (`C.5.6.9` #17); SANS Information Logging Standard compliance (`C.5.6.9` #18). +- **AU-14 Session Audit** — *DOES OIT.* Searchable log of all screens accessed by user (`C.5.6.9` #7); sensitive-data screen access monitored and recorded (`C.5.6.9` #5). + +### 14.4 Assessment, Authorization, and Monitoring (CA) + +- **CA-2 Control Assessments** — *DOES.* Independent assessment prior to ATO; annual reassessment. +- **CA-3 Information Exchange** — *DOES.* ISAs/MOUs per §11. +- **CA-5 POA&M** — *DOES.* Maintained as `ypms/POAM.md`. +- **CA-6 Authorization** — *DOES.* AO ATO decision. +- **CA-7 Continuous Monitoring** — *Hybrid.* See §15. +- **CA-8 Penetration Testing** — *DOES commissions; OIT supports.* At least annually and after major releases. +- **CA-9 Internal System Connections** — *DOES OIT.* + +### 14.5 Configuration Management (CM) + +- **CM-2 Baseline Configuration** — *DOES OIT.* Application baseline in the repo (Dockerfile / compose / IaC); DOES-approved tool/software list (source RFP `C.5.6.13`); IEEE 828-2012 alignment (source RFP §C.2 Item 8). +- **CM-3 Configuration Change Control** — *Hybrid.* DOES approves changes (`C.5.6.13`, `C.5.6.17`); 30-day advance notice for maintenance-window changes; NOC coordination. +- **CM-4 Impact Analysis** — *DOES OIT.* Required per `C.5.8.12` before database design changes. +- **CM-5 Access Restrictions for Change** — *DOES OIT.* +- **CM-6 Configuration Settings** — *DOES OIT.* Admin-configurable security controls (`C.5.6.7`); certificate authority configuration (`C.5.6.5`); infrastructure configuration (`C.5.6.6`). +- **CM-7 Least Functionality** — *DOES OIT.* +- **CM-8 System Component Inventory** — *DOES OIT.* Comprehensive tool/software list (`C.5.6.13`). +- **CM-9 Configuration Management Plan** — *DOES OIT.* Delivered as `ypms/CONFIGURATION_MANAGEMENT_PLAN.md` (to be authored). +- **CM-11 User-Installed Software** — *Hybrid.* End-user installation prohibited on managed endpoints. + +### 14.6 Contingency Planning (CP) + +- **CP-2 Contingency Plan** — *DOES OIT.* Companion `ypms/CONTINGENCY_PLAN.md`. The 99.5% SLA (`C.5.6.17`) sets the recovery envelope; failover to remote site required (`C.5.6.13`). +- **CP-3 Contingency Training** — *Hybrid.* +- **CP-4 Contingency Plan Testing** — *Hybrid.* Annual tabletop plus functional test of failover. +- **CP-6 Alternate Storage Site** / **CP-7 Alternate Processing Site** — *DOES OIT.* Redundant tiers, multi-platform load distribution (`C.5.6.18`, `C.5.6.29`). +- **CP-9 System Backup** — *DOES OIT.* Azure Backup with encrypted geo-redundant storage; documented backup and restore procedures (source RFP `C.5.8.14`); daily-backup discipline retained (source RFP `C.5.8.21`) with tested restore drill. +- **CP-10 System Recovery and Reconstitution** — *DOES OIT.* + +### 14.7 Identification and Authentication (IA) + +- **IA-2 Identification and Authentication (Organizational Users)** — *DOES OIT.* Unique user ID (`C.5.7.38`); admin actions tied to individual identity (`C.5.7.36`). +- **IA-2(1)/(2) MFA** — *DOES OIT.* MFA required for staff and admin; RFP text (`C.5.7.6`) permits "unique identifier + shared secret answer" — this is insufficient by NIST SP 800-63B AAL2; SSP requires MFA above the RFP floor for privileged and staff users. See open question §17.G. +- **IA-3 Device Identification and Authentication** — *Hybrid.* +- **IA-4 Identifier Management** — *DOES OIT.* No re-issue of deleted IDs (`C.5.7.47`). +- **IA-5 Authenticator Management** — *DOES OIT.* Password establish/change (`C.5.7.8`); administrator reset with forced change on next login (`C.5.7.12`); expiry policy (`C.5.7.13`); password-change notification via email or SMS (`C.5.7.14`); policy for complexity/reuse/length/expiration (`C.5.7.45`); masked entry (`C.5.7.46`); FIPS 140-2 crypto for passwords in storage and transit (`C.5.7.9`); minimum 12-character alphanumeric ID (`C.5.7.7`). +- **IA-6 Authenticator Feedback** — *DOES OIT.* +- **IA-7 Cryptographic Module Authentication** — *DOES OIT.* FIPS 140-2 (`C.5.7.9`, RFP §C.2 Item 9). +- **IA-8 Identification and Authentication (Non-Organizational Users)** — *DOES OIT.* Youth and host authentication, including social-media login option (`C.5.3.2`) — see risk discussion in §17.D. +- **IA-11 Re-authentication** — *DOES OIT.* On session timeout (`C.5.7.3`); should be required on privilege elevation and sensitive-action (banking change, eligibility change, payroll approval) — SSP tailoring. +- **IA-12 Identity Proofing** — *DOES OIT.* `[TBD]` — IAL model for youth registrants (many are minors) requires deliberate design; social-media identity alone is insufficient for payroll enrollment. + +### 14.8 Incident Response (IR) + +- **IR-1 Policy** — *DOES.* +- **IR-4 Incident Handling** — *Hybrid.* Companion `ypms/INCIDENT_RESPONSE_PLAN.md`. DOES OIT IDS/IPS and application logs feed DC OCTO Sentinel (source RFP `C.5.7.26`, `C.5.6.9` #19). +- **IR-6 Incident Reporting** — *Hybrid.* **Immediate** notification of unauthorized disclosure through DOES OIT → DC OCTO CISO; 24-hour internal disclosure report; 2-business-day remediation report. SLAs adopted from source RFP `C.5.8.18`–`C.5.8.20` as internal DOES policy. Federal breach reporting on top per Privacy Act and any SSA/OSSE/CFSA agreement requirements. +- **IR-8 Incident Response Plan** — *DOES.* + +### 14.9 Maintenance (MA) + +- **MA-2 through MA-6** — *Hybrid / Inherited.* Physical maintenance inherited from Azure Government. Application maintenance windows require 30-day advance notice to DC NOC (source RFP `C.5.6.17` adopted as internal SLA). + +### 14.10 Media Protection (MP) + +- **MP-2 through MP-7** — *Inherited / Hybrid.* No physical media in target architecture. Endpoint media controls inherited from DC OCTO endpoint program for DOES-managed devices. + +### 14.11 Physical and Environmental Protection (PE) + +- **PE-1 through PE-20** — *Inherited* from Azure Government FedRAMP High authorization; **Hybrid** for DOES-managed endpoints. + +### 14.12 Planning (PL) + +- **PL-2 System Security and Privacy Plan** — *This document.* +- **PL-4 Rules of Behavior** — *DOES.* Companion `ypms/RULES_OF_BEHAVIOR.md`, with separate variants for staff, host employers, and youth/parent users. +- **PL-8 Security and Privacy Architecture** — *DOES OIT.* Architecture document per source RFP `C.5.5.5` — tracked as `YPMS-POAM-040`. +- **PL-10 Baseline Selection** / **PL-11 Baseline Tailoring** — Documented in §2.3. + +### 14.13 Program Management (PM) + +- **PM-1 through PM-32** — *DOES / DC OCTO CISO Office.* Inheritance documented in the DOES organization-wide security program plan `[TBD]`. + +### 14.14 Personnel Security (PS) + +- **PS-1 through PS-9** — *Hybrid.* DOES HR handles background checks and access agreements for DOES OIT staff and any contracted individual developers. DOES OIT maintains and reviews the roster of personnel with production data access at least quarterly, with additions and deletions tracked (source RFP `C.5.8.16`, `C.5.8.17` adopted as internal policy). + +### 14.15 PII Processing and Transparency (PT) + +- **PT-2 Authority to Process PII** / **PT-3 Purpose Specification** — Documented via PIA. +- **PT-4 Consent** / **PT-5 Privacy Notice** — *DOES.* Notice designed for minors and parents where applicable. +- **PT-6 System of Records Notice (SORN)** — *TBD* — applicability review by DOES Privacy Officer. +- **PT-7 Specific Categories of PII** — Sensitive PII enumerated in §13. + +### 14.16 Risk Assessment (RA) + +- **RA-2 Security Categorization** — Documented in §2. +- **RA-3 Risk Assessment** — *DOES.* +- **RA-5 Vulnerability Monitoring and Scanning** — *DOES OIT.* Cyber-threat detection and remediation (`C.5.7.52`). Authenticated and unauthenticated scans at minimum monthly; container/image scans on push where applicable. +- **RA-7 Risk Response** — *DOES.* POA&M-driven. +- **RA-10 Threat Hunting** — *Hybrid.* + +### 14.17 System and Services Acquisition (SA) + +- **SA-3 SDLC** — *DOES OIT.* Agile SDLC matching OWC / DCYWP patterns; discipline adopted from source RFP `C.5.2`. +- **SA-4 Acquisition Process** — *DOES.* Applies to third-party components DOES procures (payroll vendor, LMS vendor, SaaS subcomponents). +- **SA-8 Security and Privacy Engineering Principles** — *DOES OIT.* +- **SA-9 External System Services** — *DOES OIT.* Governs payroll vendor, LMS vendor, DC MAR, social-media IdPs, and any SaaS subcomponents. +- **SA-10 Developer Configuration Management** / **SA-11 Developer Testing and Evaluation** — *DOES OIT.* Data-model deliverables per source RFP `C.5.8.4`–`C.5.8.11`; testing and UAT per source RFP §C.5.10. +- **SA-15 Development Process, Standards, and Tools** — *DOES OIT.* +- **SA-22 Unsupported System Components** — *DOES OIT.* Third-party dependencies tracked in SBOM with maintained upgrade path (source RFP `C.5.6.13`). + +### 14.18 System and Communications Protection (SC) + +- **SC-5 Denial-of-Service Protection** — *DOES OIT.* +- **SC-7 Boundary Protection** — *DOES OIT.* Trusted/transition/untrusted zones (`C.5.7.23`). +- **SC-8 Transmission Confidentiality and Integrity** — *DOES OIT.* Encryption in transit (source RFP `C.5.7.25`); source RFP `C.5.6.15` says SSL, which is deprecated; **SSP tailors this to TLS 1.2 minimum, TLS 1.3 preferred, FIPS-approved cipher suites**. +- **SC-10 Network Disconnect** — *DOES OIT.* +- **SC-12 / SC-13 Cryptographic Key Establishment and Use** — *DOES OIT.* FIPS 140-3 cryptography (140-2 acceptable during deprecation window) via Azure Key Vault (Gov / HSM). +- **SC-17 Public Key Infrastructure Certificates** — *DOES OIT.* Certificate Authority configuration (`C.5.6.5`). +- **SC-23 Session Authenticity** — *DOES OIT.* +- **SC-28 Protection of Information at Rest** — *DOES OIT.* Encryption of all PII at rest (`C.5.7.25`); SSN masked/anonymized in display (`C.5.7.50`). +- **SC-39 Process Isolation** — *Inherited.* + +### 14.19 System and Information Integrity (SI) + +- **SI-2 Flaw Remediation** — *DOES OIT.* Cyber-threat remediation (source RFP `C.5.7.52`); DOES OIT patch cadence with failover-during-patching capability (source RFP `C.5.6.13`). +- **SI-3 Malicious Code Protection** — *DOES OIT.* Upload scanning for document uploads. +- **SI-4 System Monitoring** — *DOES OIT.* IDS/IPS with alerting (`C.5.7.26`); SIEM (`C.5.6.9` #19–23); performance monitoring (`C.5.6.22`). +- **SI-5 Security Alerts, Advisories, and Directives** — *DOES OIT.* +- **SI-7 Software, Firmware, and Information Integrity** — *DOES OIT.* +- **SI-10 Information Input Validation** — *DOES OIT.* Character set, length, numerical range, format and content, trusted-source restriction (`C.5.7.44`); address verification (`C.5.6.2`); SSA-verified SSN (`C.5.6.3.b`); DC MAR address validation (`C.5.6.3.d`). +- **SI-11 Error Handling** — *DOES OIT.* Corrective information without adversary-exploitable disclosure (`C.5.7.43`); consistent error handling with clear messages, all errors logged (`C.5.6.9` #2, #3). +- **SI-12 Information Management and Retention** — *DOES.* +- **SI-16 Memory Protection** — *Inherited.* + +### 14.20 Supply Chain Risk Management (SR) + +- **SR-1 through SR-12** — *Hybrid.* CycloneDX SBOM generated per release in CI (`YPMS-POAM-042`); third-party dependencies reviewed and pinned; provenance for payroll and LMS vendors; comprehensive tool/software list (source RFP `C.5.6.13`). + +--- + +## 15. Continuous Monitoring + +The YPMS Continuous Monitoring Strategy will follow DOES CIO / DC OCTO CISO guidance and NIST SP 800-137. Anticipated cadence: + +| Activity | Frequency | Owner | +|---|---|---| +| Log stream to DC OCTO Sentinel | Continuous | DOES OIT → DC OCTO | +| Vulnerability scanning (authenticated + unauthenticated) | Monthly | DOES OIT | +| Personnel-with-data-access roster review | Quarterly | DOES ISSO | +| Configuration drift check (CIS Azure Foundations) | Weekly | DOES OIT | +| POA&M review | Monthly | DOES ISSO | +| Access recertification (privileged) | Quarterly | DOES OIT + ISSO | +| Access recertification (all users) | Annually | DOES OIT + ISSO | +| Backup + restore drill (daily backup, periodic restore) | Daily backup, annual full restore drill | DOES OIT | +| Contingency plan test | Annually (tabletop + functional element) | DOES OIT + ISSO | +| Independent control assessment | Annually | DOES-commissioned | +| Penetration test | Annually and after major release | DOES-commissioned | +| Availability performance report (99.5% SLA envelope) | Monthly | DOES OIT | +| SSP update | On material change; at least annually | DOES ISSO | + +Ongoing metrics reported to the AO: SLA achievement (99.5%), patch SLA adherence, MTTR for high/critical vulns, open POA&M aging, and count of unauthorized-disclosure notifications. + +--- + +## 16. Plan Approval + +| Role | Name | Signature | Date | +|---|---|---|---| +| System Owner (DOES CIO) | Chris Tonjes | | | +| Information System Security Officer | Chris Tonjes | | | +| Business Owner (OYP) | `[TBD]` | | | +| DOES OIT Delivery Lead | `[TBD]` | | | +| Authorizing Official | Chris Tonjes (per §5 role-concentration note) | | | + +--- + +## 17. Appendices + +### Appendix A — Acronyms + +AAL Authentication Assurance Level · AO Authorizing Official · APM Application Performance Monitoring · ATO Authorization to Operate · CFSA Child and Family Services Agency · CIS Center for Internet Security · CISO Chief Information Security Officer · COTS Commercial Off-the-Shelf · CP Contingency Plan · CRESP Career Ready Early Scholars Program · DC MAR DC Master Address Repository · DC OCTO DC Office of the Chief Technology Officer · DOES DC Department of Employment Services · FERPA Family Educational Rights and Privacy Act · FIPS Federal Information Processing Standards · FISMA Federal Information Security Modernization Act · FedRAMP Federal Risk and Authorization Management Program · HIPAA Health Insurance Portability and Accountability Act · HSIP High School Internship Program · IaaS Infrastructure-as-a-Service · IAL Identity Assurance Level · IAM Identity and Access Management · IDS/IPS Intrusion Detection/Prevention System · ISA Interconnection Security Agreement · ISSO Information System Security Officer · LDAP Lightweight Directory Access Protocol · LMS Learning Management System · MBSYEP Marion S. Barry Summer Youth Employment Program · MBYLI Marion Barry Youth Leadership Institute · MFA Multi-Factor Authentication · MTTR Mean Time to Remediate · NIST National Institute of Standards and Technology · NOC Network Operations Center · OCTO Office of the Chief Technology Officer · OIT Office of Information Technology · OSSE Office of the State Superintendent of Education · OYP Office of Youth Programs · PCI DSS Payment Card Industry Data Security Standard · PIA Privacy Impact Assessment · PII Personally Identifiable Information · POA&M Plan of Action and Milestones · SaaS Software-as-a-Service · SANS SysAdmin Audit Network Security · SDLC System Development Life Cycle · SIEM Security Information and Event Management · SIT Summer Intensive Training · SOC Security Operations Center · SORN System of Records Notice · SSA Social Security Administration · SSP System Security Plan · SYP School Year Program · UAT User Acceptance Test · WCAG Web Content Accessibility Guidelines · YPMS Youth Program Management System + +### Appendix B — References + +- NIST SP 800-18 Rev. 1 — Guide for Developing Security Plans. +- NIST SP 800-37 Rev. 2 — Risk Management Framework. +- NIST SP 800-47 Rev. 1 — Managing the Security of Information Exchanges. +- NIST SP 800-53 Rev. 5 — Security and Privacy Controls. +- NIST SP 800-60 Vol. II — Guide for Mapping Types of Information. +- NIST SP 800-63-3 — Digital Identity Guidelines. +- NIST SP 800-137 — ISCM. +- NIST SP 800-171 Rev. 2 — CUI Protection. +- FIPS 199 / FIPS 200 / FIPS 140-2 (with FIPS 140-3 forward alignment). +- FERPA (20 USC §1232g). +- Privacy Act (5 USC §552a). +- SSA Electronic Information Exchange Security Requirements. +- DC OCTO IT Security Policy. +- DC Code Title 32 Chapter 2 Subchapters II and V. +- DC Code Title 4. +- IEEE 828-2012. +- PCI DSS. +- WCAG 2.1 AA / Section 508. +- SANS Information Logging Standard. + +### Appendix C — RFP Security Requirement → SSP / Control Traceability + +Traceability for the 54 C.5.7 Security Requirements and the load-bearing items from C.5.6 and C.5.8. + +| RFP Ref | Requirement (abbreviated) | SSP Section / Control | +|---|---|---| +| C.5.7.1 | External + internal role-based authN/authZ | §14.1 AC-2, AC-3; §14.7 IA-2, IA-8 | +| C.5.7.2 | Authorized users export data with designated file format, name, schedule, protocol, destination | §14.1 AC-6; §14.18 SC-8 | +| C.5.7.3 | Session timeout on inactivity, re-authentication required | §14.1 AC-11/AC-12; §14.7 IA-11 | +| C.5.7.4 | Auto-disable accounts after inactivity | §14.1 AC-2 | +| C.5.7.5 | Admin can enable/disable user access | §14.1 AC-2 | +| C.5.7.6 | Login = unique identifier + shared secret | §14.7 IA-2 (SSP tailors above this floor to require MFA for staff/admin) | +| C.5.7.7 | 12–64 alphanumeric user IDs | §14.1 AC-2; §14.7 IA-4 | +| C.5.7.8 | User-established and changeable passwords | §14.7 IA-5 | +| C.5.7.9 | FIPS 140-2 crypto for passwords in storage and transit | §14.7 IA-7; §14.18 SC-12/SC-13 | +| C.5.7.10 | Lockout after 5 failed attempts | §14.1 AC-7 | +| C.5.7.11 | Notification on access revocation | §14.1 AC-7 | +| C.5.7.12 | Admin password reset with forced change on login | §14.7 IA-5 | +| C.5.7.13 | Password expiration policy | §14.7 IA-5 | +| C.5.7.14 | Password-change notification by email or SMS | §14.7 IA-5 | +| C.5.7.15 | Capture user ID and timestamp on create/modify/delete | §14.3 AU-3 | +| C.5.7.16 | Authorized user view of record at specified point in time | §14.3 AU-14 | +| C.5.7.17 | Authorized user backdated transactions with reprocessing | §14.1 AC-6; §14.3 AU-3 | +| C.5.7.18 | Authorized user acts on behalf of customer | §14.1 AC-6; §14.3 AU-3 | +| C.5.7.19 | Customer profile view/update | §14.15 PT-2 | +| C.5.7.20 | Customer secure transactions from home page | §14.18 SC-8, SC-23 | +| C.5.7.21 | Authorized users view/add/modify records | §14.1 AC-3 | +| C.5.7.22 | Customer-profile relationships | §14.15 PT-2 | +| C.5.7.23 | Untrusted systems cannot reach trusted zones | §14.1 AC-4; §14.18 SC-7 | +| C.5.7.24 | Minimum Level 3 security across data lifecycle | §14 (see open question §17.A) | +| C.5.7.25 | Encrypt all PII collected/processed/stored/transmitted | §14.18 SC-8, SC-28 | +| C.5.7.26 | IDS/IPS with alerts on compromise | §14.19 SI-4; §14.8 IR-4 | +| C.5.7.27 | Enforce authorizations per access control policies | §14.1 AC-3 | +| C.5.7.28 | Only admins view/change access rights | §14.1 AC-3, AC-6 | +| C.5.7.29 | Group + individual assignment via OCTO/DOES LDAP | §14.1 AC-2 | +| C.5.7.30 | LDAP compliance | §14.7 IA-2; §11 | +| C.5.7.31 | Real-time and scheduled access-right changes | §14.1 AC-3 | +| C.5.7.32 | RBAC over defined objects | §14.1 AC-6 | +| C.5.7.33 | One login per staff, role-mediated access | §14.1 AC-6 | +| C.5.7.34 | Admin maintains role-based security | §14.1 AC-6 | +| C.5.7.35 | Mobile-platform encryption/access/app-security | §14.1 AC-19 | +| C.5.7.36 | Auto-log all admin actions incl. account changes | §14.3 AU-2, AU-3 | +| C.5.7.37 | User notification before access granted | §14.1 AC-8 | +| C.5.7.38 | Unique user ID per user for traceability | §14.7 IA-4 | +| C.5.7.39 | Automated audit trails on root/admin, audit-log access, logon events, PII interactions, org-defined events | §14.3 AU-2, AU-12 | +| C.5.7.40 | Time synchronization | §14.3 AU-8 | +| C.5.7.41 | Protect audit info and audit tools | §14.3 AU-9 | +| C.5.7.42 | Retain audit trail per org-defined period | §14.3 AU-11 | +| C.5.7.43 | Error messages informative but not exploitable | §14.19 SI-11 | +| C.5.7.44 | Input validation and trusted-source restriction | §14.19 SI-10 | +| C.5.7.45 | Org-defined password policy (complexity/reuse/length/expiration) | §14.7 IA-5 | +| C.5.7.46 | Mask passwords on entry | §14.7 IA-6 | +| C.5.7.47 | No re-issue of deleted/previous user IDs | §14.1 AC-2; §14.7 IA-4 | +| C.5.7.48 | Audit records: what/when/where/source/outcome/identity | §14.3 AU-3 | +| C.5.7.49 | Audit records sufficient to reconstruct events | §14.3 AU-3 | +| C.5.7.50 | Mask/anonymize SSN | §14.18 SC-28; §13 | +| C.5.7.51 | NIST 800-53 compliance | §2.3; §14 (all) | +| C.5.7.52 | Cyber-threat detection and remediation | §14.16 RA-5; §14.19 SI-2 | +| C.5.7.53 | DC OCTO IT policies compliance | §12.2; §14 (all) | +| C.5.7.54 | Ethical security for emerging technologies (GenAI/ML/etc.) | §9.4; §14.17 SA-9 | +| C.5.6.2 | Data checks (address, age, residency) | §14.19 SI-10 | +| C.5.6.3 | External-application integrations (OSSE, CFSA, SSA, DC MAR, LMS, payroll) | §11 | +| C.5.6.4 | SSA Electronic Information Exchange compliance | §11; §12.1 | +| C.5.6.5 | Configure Certificate Authority | §14.18 SC-17 | +| C.5.6.6 | Configure infrastructure (DB, space, performance) | §14.5 CM-6 | +| C.5.6.7 | Configure security controls | §14.5 CM-6 | +| C.5.6.8 | Security approach per DC OCTO policies | §12.2; §14 (all) | +| C.5.6.9 | Audit requirements (23-item list) | §14.3 AU-2 through AU-14 | +| C.5.6.10 | 24-hour operability | §2.1 Availability | +| C.5.6.11 | Modern browser support | §8.4 | +| C.5.6.13 | Failover to remote site during patching | §14.6 CP-6/CP-7; §14.5 CM-3 | +| C.5.6.14 | OCTO cloud coordination | §5; §9.2 | +| C.5.6.15 | SSL for confidential transmissions (SSP tailors to TLS 1.2+) | §14.18 SC-8 | +| C.5.6.16 | Hosted IaaS with DOES-approved security | §9.2 | +| C.5.6.17 | 99.5% availability SLA, 30-day maintenance notice | §2.1 Availability; §14.9 MA | +| C.5.6.18 | Redundant multi-tier architecture | §14.6 CP-6/CP-7 | +| C.5.6.19 | PCI DSS compliance | §2.3; §12.1 | +| C.5.6.20 | 50%-per-year growth scaling | §8.3 | +| C.5.6.29 | Load distribution across hosting platforms | §14.6 CP-6/CP-7 | +| C.5.6.30 | Endpoints comply with DC OCTO policy | §14.1 AC-19 | +| C.5.6.31 | Scalable emerging-tech infrastructure | §9.4 | +| C.5.6.32 | Emerging-tech data remains in DOES domain | §9.4; §14.17 SA-9 | +| C.5.8.14 | Backup and restore procedures | §14.6 CP-9 | +| C.5.8.15 | APIs and web services secured | §14.18 SC-8; §14.19 SI-10 | +| C.5.8.16 | Personnel-with-data-access roster at project start | §14.14 PS | +| C.5.8.17 | Quarterly personnel-with-data-access roster updates | §14.14 PS | +| C.5.8.18 | Immediate unauthorized-disclosure notification | §14.8 IR-6 | +| C.5.8.19 | 24-hour disclosure report | §14.8 IR-6 | +| C.5.8.20 | 2-business-day remediation report | §14.8 IR-6 | +| C.5.8.21 | Daily backup delivered to DOES | §14.6 CP-9 | + +### Appendix D — Open Questions + +Each item cross-references its POA&M ID in `ypms/POAM.md`. + +**A. What is "Level 3 security" in source RFP `C.5.7.24` (`YPMS-POAM-051`)?** Source RFP requires "a minimum of Level 3 security to all data" without defining Level 3. Two plausible readings: (1) internal maturity level, or (2) NIST SP 800-63 AAL/IAL Level 3. SSP treats it as the higher until DOES clarifies with the AO. + +**B. Youth age band typo (source RFP §C.3.1 "99 – 24 years old").** Correct in derived requirements. SSP uses program-appropriate ranges. + +**C. Social-media login for youth (`YPMS-POAM-050`) — risk acceptance required.** Accepting social-media identity assertions for payroll-eligible minors is a live IAL question. Options: (1) social-media login accepted only for browsing / pre-application; (2) full identity proofing (Login.gov, SSA verification) before banking/payroll actions; (3) require parental co-authentication for under-18 registrants. SSP recommends option 2, with option 3 as a compensating control. + +**D. PCI DSS scope (`YPMS-POAM-052`).** If no card processing occurs (payroll is ACH via third-party vendor), PCI scope is zero and this control set drops. Expected out of scope; confirm with OYP. + +**E. MFA above the source-RFP floor.** Source RFP `C.5.7.6` — "unique identifier + shared secret answer" — is not MFA. SSP tailors to require MFA for staff and admin (`YPMS-POAM-030`); question whether youth/host MFA is also required at first sensitive action. + +**F. Retention (`YPMS-POAM-054`).** Align with DOES records schedule for OYP program records and audit logs (source RFP `C.5.7.42`). + +**G. Emergency health-record CSV path (`YPMS-POAM-053`).** In-boundary steady state, or separate emergency-scoped extension with its own PIA? SSP recommends the latter to keep steady-state categorization from being dragged up by a dormant path. + +**H. FIPS 140-2 vs. FIPS 140-3 (`YPMS-POAM-032`).** Source RFP cites 140-2 (which is sunset). SSP requires 140-3 where available and treats existing 140-2 validations as acceptable during the deprecation window. + +**I. IAL2-equivalent identity proofing before payroll (`YPMS-POAM-033`).** Source RFP silent; SSP tailors to require proofing above social-media assertion for payroll-eligible actions. Feeds open question D. + +### Appendix E — Related Documents (companion, to be authored in `ypms/`) + +- `ypms/FIPS_199_MEMO.md` +- `ypms/NIST_800_53_CONTROL_MAPPING.md` +- `ypms/PRIVACY_IMPACT_ASSESSMENT.md` +- `ypms/INCIDENT_RESPONSE_PLAN.md` +- `ypms/CONTINGENCY_PLAN.md` +- `ypms/RULES_OF_BEHAVIOR.md` (staff, host, youth/parent editions) +- `ypms/POAM.md` +- Architecture and Design document (DOES OIT deliverable; source RFP `C.5.5.5`) +- Configuration / Change Management Plan (DOES OIT deliverable; source RFP §C.5.12) +- DOES–OSSE Data Sharing Agreement (FERPA) `[TBD]` +- DOES–CFSA MOU `[TBD]` + +--- + +**End of draft v0.3 (in-house build reframe).** diff --git a/TODO.md b/TODO.md new file mode 100644 index 0000000..d4dab24 --- /dev/null +++ b/TODO.md @@ -0,0 +1,190 @@ +# YPMS — TODO Checklist + +**Owner:** DOES CIO +**Last touched:** 2026-09-30 +**Scope:** everything from team formation through Go-Live and steady-state operations. Companion tracker: [`POAM.md`](POAM.md) holds the numbered, dated, milestone-tracked version of the ATO items below. + +Legend: `[ ]` open · `[~]` in progress · `[x]` done · `[!]` blocked · `[?]` needs decision + +--- + +## 0. Team formation and governance + +- [x] ISSO assigned in writing for YPMS (Chris Tonjes; `YPMS-POAM-090` closed 2026-09-30) +- [x] AO designated in writing (Chris Tonjes; `YPMS-POAM-002` closed 2026-09-30; role-concentration acceptance in SSP §5) +- [ ] Business Owner named (OYP) +- [ ] DOES OIT delivery lead named +- [ ] Backend engineer(s) assigned +- [ ] Frontend engineer(s) assigned +- [ ] Data/integration engineer assigned (owns OSSE, CFSA, SSA, DC MAR, payroll) +- [ ] Test/QA lead assigned +- [ ] DC OCTO cloud coordination POC identified + +## 1. Stack and architecture decisions + +- [x] **Stack decision** — Python 3.12 / FastAPI / SQLAlchemy / Postgres (OWC alignment; recorded 2026-09-30) +- [x] Azure Government confirmed as hosting (aligned with OWC and Employer 360) +- [?] **Level 3 security clarification** — source RFP `C.5.7.24` (`YPMS-POAM-051`) +- [?] **Youth identity model** — social-media login scope, IAL2-equivalent proofing before payroll actions, parental co-auth for under-18 (`YPMS-POAM-050`) +- [?] **PCI DSS applicability** — expected out of scope since payroll is ACH via vendor (`YPMS-POAM-052`) +- [?] **Health-record CSV path disposition** — in-boundary vs. emergency extension (`YPMS-POAM-053`) +- [?] **Retention policy** — audit logs, case records, backups (`YPMS-POAM-054`) +- [ ] SORN applicability determination (`YPMS-POAM-094`) +- [ ] Correct the youth-age typo from the source RFP (glossary says "99–24"; should be 14–24) in derived requirements +- [x] High-level architecture document v0.1 drafted (`ypms/ARCHITECTURE.md`, 2026-09-30) +- [x] Conceptual data model in `ARCHITECTURE.md` §6 (25 core entities enumerated); logical + physical ERDs remain +- [ ] Logical and physical ERDs, full data dictionary, CRUD matrix (extends `ARCHITECTURE.md` §6) +- [ ] Security architecture review with DC OCTO (referenced in `ARCHITECTURE.md` §8) + +## 2. Environments and pipeline + +- [ ] Azure Government subscription requested and provisioned (`YPMS-POAM-041`) +- [ ] Dev environment +- [ ] Test environment +- [ ] Production environment (later) +- [ ] CIS Azure Foundations baseline applied to all environments +- [ ] Azure Key Vault (FIPS 140-3 HSM) provisioned (`YPMS-POAM-032`) +- [ ] Managed Identity model for service-to-service auth +- [ ] Postgres flexible server provisioned (private endpoint) +- [ ] Git repo initialized under `ypms/` (this directory) with branch protection +- [ ] CI/CD pipeline scaffold (`YPMS-POAM-042`) + - [ ] Build + unit-test gate + - [ ] SAST gate + - [ ] SCA (dependency vulnerability) gate + - [ ] Secret scanning gate + - [ ] SBOM generation per release (CycloneDX) + - [ ] Container image scanning +- [ ] Sentinel integration for log streaming (`YPMS-POAM-043`) +- [ ] Backup + restore procedure documented and tested (`YPMS-POAM-044`) + +## 3. Data-sharing agreements & interconnections + +Existing DOES agreements cover the current OYP workflows; YPMS-scope amendments or renewals are the path, not new drafts. + +- [ ] **DOES–OSSE data-sharing agreement (FERPA)** — renewal / YPMS-scope amendment (`YPMS-POAM-020`) — **blocks OSSE ingest build** +- [ ] **DOES–CFSA MOU (DC Code Title 4)** — renewal / YPMS-scope amendment (`YPMS-POAM-021`) — **blocks CFSA ingest build** +- [ ] **SSA Electronic Information Exchange agreement** — renewal / YPMS-scope confirmation (`YPMS-POAM-022`) — **blocks SSN cross-match build** +- [ ] **DC MAR service agreement** — confirm coverage under existing OCTO umbrella +- [ ] **Payroll vendor selection + security review + ISA/DPA** (`YPMS-POAM-023`) — **blocks payroll integration build** +- [ ] **LMS vendor selection + security review** — blocks orientation-tracking build +- [ ] **DC OCTO Sentinel MOU / ingestion agreement** +- [ ] **NOC coordination arrangement** — 30-day maintenance-window notice cadence +- [ ] **Emergency health-record CSV path** — either MOU with source or scoping decision to defer (`YPMS-POAM-053`) +- [ ] ISAs / NIST 800-47 Rev. 1 documents for each of the above (`YPMS-POAM-084`) + +## 4. ATO artifacts + +- [x] Draft SSP v0.3 (`ypms/SYSTEM_SECURITY_PLAN.md`) — in-house build reframe complete (`YPMS-POAM-010`) +- [x] Draft NIST 800-53 control mapping v0.2 (`ypms/NIST_800_53_CONTROL_MAPPING.md`) — in-house build reframe complete (`YPMS-POAM-015`) +- [x] Draft POA&M v0.1 (`ypms/POAM.md`) — reflects in-house build model +- [ ] **FIPS 199 categorization memo** signed by AO (`YPMS-POAM-001`) +- [x] **Privacy Impact Assessment v0.1 drafted** (`YPMS-POAM-011`; `ypms/PRIVACY_IMPACT_ASSESSMENT.md`; 2026-09-30) — awaiting Privacy Officer + OGC review, then AO signature +- [ ] **Incident Response Plan** — tabletop with DC OCTO SOC (`YPMS-POAM-012`) +- [ ] **Contingency Plan** — functional restore drill (`YPMS-POAM-013`) +- [ ] **Rules of Behavior** — staff / host / youth+parent variants with parental-consent flow (`YPMS-POAM-014`) +- [ ] **Continuous Monitoring Strategy** document (`YPMS-POAM-074`) +- [ ] **Independent Control Assessment (SCA)** commissioned and executed (`YPMS-POAM-060`) +- [ ] **Penetration test** commissioned and executed (`YPMS-POAM-061`) +- [ ] **ATO decision package** compiled and submitted to AO +- [ ] **ATO signed** before production data flows in + +## 5. Build + +Iterative Agile delivery (Scrum/Kanban/SAFe — match OWC's phased approach). Illustrative phase breakdown; refine at architecture kickoff. + +- [ ] **Phase 1 — Foundation.** Auth, user model, RBAC, base UI shell, admin skeleton, audit-logging framework. +- [ ] **Phase 2 — Application intake.** Youth registration, application form, save/resume, document upload with malware scanning. +- [ ] **Phase 3 — Eligibility engine.** Rules-driven auto-eligibility from Appendix D of source RFP; categorical eligibility across programs. +- [ ] **Phase 4 — External integrations.** DC MAR address verification, SSA SSN verify (blocked on `YPMS-POAM-022`), OSSE ingest (blocked on `YPMS-POAM-020`), CFSA ingest (blocked on `YPMS-POAM-021`). +- [ ] **Phase 5 — Certification and orientation.** Certification event workflow, LMS integration. +- [ ] **Phase 6 — Host/employer.** Host registration, worksite management, job posting. +- [ ] **Phase 7 — Matching and enrollment.** Job matching engine, program enrollment. +- [ ] **Phase 8 — Time and payroll.** Online timekeeping, payroll vendor integration (blocked on `YPMS-POAM-023`), transportation vouchers, tax forms. +- [ ] **Phase 9 — Reporting.** Native reports replacing MicroStrategy; audit-log search. +- [ ] **Phase 10 — Admin functions.** Broadcast notifications, workflow rule maintenance, user profile management. + +## 6. Security implementation (crosscuts all phases) + +- [ ] MFA for staff and admin (Entra ID conditional access) (`YPMS-POAM-030`) +- [ ] TLS 1.2+ enforced everywhere; SSL Labs A+ on public endpoints (`YPMS-POAM-031`) +- [ ] FIPS 140-3 cryptography (`YPMS-POAM-032`) +- [ ] IAL2-equivalent identity proofing before payroll actions (`YPMS-POAM-033`) +- [ ] SSN masking + at-rest encryption (`YPMS-POAM-080`) +- [ ] System-use notification banner (`YPMS-POAM-070`) +- [ ] Auto-disable inactive accounts (`YPMS-POAM-071`) +- [ ] Quarterly privileged-access recert process (`YPMS-POAM-072`) +- [ ] Annual all-user access recert process (`YPMS-POAM-073`) +- [ ] Language Access Act compliance (`YPMS-POAM-081`) +- [ ] Section 508 / WCAG 2.1 AA compliance audit (`YPMS-POAM-082`) +- [ ] Parental consent workflow for under-18 (`YPMS-POAM-083`) +- [ ] Anti-bot / rate-limit for MBSYEP peak windows (`YPMS-POAM-101`) + +## 7. Testing + +- [ ] Unit-test coverage target set and enforced in CI +- [ ] Functional tests per feature +- [ ] Non-functional tests: performance (99.5% SLA envelope, <1s response), load (50%/year growth headroom) +- [ ] Accessibility tests (Section 508) +- [ ] Language-access tests +- [ ] UAT plan and test scripts approved +- [ ] Vulnerability scanning cadence in production (`YPMS-POAM-062`) + +## 8. Legacy retirement & data migration + +- [ ] Data-migration plan from each of the seven legacy tools (`YPMS-POAM-105`) +- [ ] Data-quality baselines documented per source +- [ ] PII handling during migration +- [ ] Cutover strategy — big-bang vs. phased-by-program +- [ ] Read-only archive of legacy data for audit / statute-of-limitations retention +- [ ] Legacy system decommission schedule and destruction evidence (`YPMS-POAM-106`) + +## 9. Training & change management + +- [ ] Training plan for OYP staff, host/employer, youth self-service (`YPMS-POAM-091`) +- [ ] System overview intro video (MP4, closed captioned) +- [ ] Role-based training materials +- [ ] Help / KB content with an updateable help system + +## 10. Go-Live & steady-state + +- [ ] Go/No-Go decision meeting with AO +- [ ] Cutover runbook rehearsed +- [ ] Go-Live +- [ ] Post-Go-Live retrospective + +## 11. Continuous monitoring (steady-state cadence) + +- [ ] Monthly vulnerability scans +- [ ] Monthly POA&M review by DOES ISSO +- [ ] Quarterly privileged access recertification +- [ ] Annual full access recertification +- [ ] Annual Contingency Plan test (tabletop + functional element) +- [ ] Annual Independent Control Assessment +- [ ] Annual penetration test +- [ ] Annual SSP refresh +- [ ] Monthly availability performance report against 99.5% SLA + +--- + +## Immediate next actions (this week) + +1. ~~SSP v0.3 in in-house build framing~~ ✓ +2. ~~Control mapping v0.2 in in-house build framing~~ ✓ +3. ~~POA&M v0.1 seeded~~ ✓ +4. ~~ISSO / AO / System Owner: Chris Tonjes (with role-concentration risk acceptance)~~ ✓ +5. ~~Stack: Python 3.12 / FastAPI / SQLAlchemy / Postgres (OWC alignment)~~ ✓ +6. ~~Draft the PIA — minors + FERPA + CFSA is the substantive part~~ ✓ (v0.1 drafted 2026-09-30) +7. Get **existing OSSE, CFSA, and SSA agreements pulled from OGC files** to scope renewals (`YPMS-POAM-020`, `YPMS-POAM-021`, `YPMS-POAM-022`) +8. Draft the **FIPS 199 categorization memo** for AO signature (`YPMS-POAM-001`) +9. ~~Start the architecture document~~ ✓ (`ypms/ARCHITECTURE.md` v0.1 drafted 2026-09-30) +10. Route PIA v0.1 to Privacy Officer + OGC review +11. ~~Author PHASE0_PLAN.md~~ ✓ (`ypms/PHASE0_PLAN.md` v0.1 drafted 2026-09-30) +12. DC OCTO security architecture review meeting scheduled + +## Parking lot (not yet triaged) + +- Emerging-tech (GenAI/ML) posture — ethical measures required; data must stay in DOES domain (`YPMS-POAM-103`) +- FOIA response workflow with PII redaction (`YPMS-POAM-102`) +- Records schedule alignment with DOES records officer +- Approved-software list governance (`YPMS-POAM-100`) +- Employer 360 dependency: once E360 lands, YPMS host/employer records should consume it rather than re-implementing employer matching