Security Operations

On this page

This page documents CRAIG’s operational security processes: how vulnerabilities are classified, how quickly they must be remediated, how penetration tests are conducted, and how security incidents are handled.

Severity Classification

CRAIG classifies vulnerabilities using the Common Vulnerability Scoring System (CVSS v3.1) base score as the primary input, adjusted by deployment context.

Severity CVSS Range Criteria

Critical

9.0 – 10.0

Remote code execution, authentication bypass, SQL injection enabling full data exfiltration, or any vulnerability actively exploited in the wild. Affects confidentiality of child welfare records (PII/PHI).

High

7.0 – 8.9

Privilege escalation, significant data exposure (e.g., cross-tenant data leak), denial of service against core services, or vulnerabilities in authentication/authorization flows.

Medium

4.0 – 6.9

Information disclosure of non-sensitive data, cross-site scripting (XSS) requiring user interaction, missing security headers, or denial of service against non-critical endpoints.

Low

0.1 – 3.9

Minor information leaks (version banners, stack traces in non-production), cosmetic security issues, or vulnerabilities requiring local access and authenticated sessions.

Contextual Adjustments

  • If a vulnerability affects PII or PHI (child records, case narratives, health data), increase severity by one level.

  • If a vulnerability is only exploitable in devstack (not production configurations), decrease severity by one level.

  • If a CVE has a known public exploit, treat as Critical regardless of CVSS score.

Remediation SLAs

Remediation timelines are measured from the date a vulnerability is confirmed (triaged and classified).

Severity Time to Patch Time to Deploy Notes

Critical

24 hours

48 hours

Emergency release. All other work stops. Notify deploying agencies immediately.

High

7 days

14 days

Expedited release. May be bundled with other high-severity fixes.

Medium

30 days

60 days

Included in the next scheduled release.

Low

90 days

Next release

Addressed in normal development cycle.

"Time to Patch" is the deadline for merging a fix to the main branch. "Time to Deploy" is the deadline for deploying the fix to production environments. Deploying agencies are responsible for meeting the deployment deadline once a patched release is published.

Escalation Procedures

Severity-Based Escalation

Severity Escalation Path

Critical

Project maintainer notified immediately. Deploying agency CISOs notified within 4 hours. Fix branch created within 2 hours. Post-incident review required within 5 business days.

High

Project maintainer notified within 4 hours. Deploying agencies notified within 24 hours via security advisory. Fix prioritized above all non-critical work.

Medium

Logged as a confidential GitLab issue. Assigned to the next sprint. Deploying agencies notified in the release notes.

Low

Logged as a confidential GitLab issue. Addressed during normal development.

Notification Channels

  • Confidential GitLab issues — primary tracking for all severity levels

  • Email to deploying agency security contacts — Critical and High

  • Release notes — Medium and Low

  • CRAIG security advisory page — all confirmed vulnerabilities after patch is available

Security Update Release Process

  1. Triage: Confirm the vulnerability, classify severity, assign a CVE identifier if applicable.

  2. Fix: Develop the patch on a private branch. The branch name must NOT reveal the vulnerability.

  3. Test: Run the full CI pipeline (unit, integration, E2E). Add a regression test for the vulnerability.

  4. Review: Security-sensitive MRs require review from a maintainer who did not author the fix.

  5. Release: Tag a new patch version. Publish container images. Update CHANGELOG.adoc.

  6. Notify: Send security advisory to deploying agencies per the escalation procedures above.

  7. Verify: Confirm deploying agencies acknowledge receipt and have a deployment plan.

Penetration Test Process

Recommended Frequency

  • Annual: Full-scope penetration test covering all services and authentication flows.

  • After major changes: Any new service, new authentication mechanism, or significant API surface change.

  • After critical vulnerability remediation: Re-test to verify the fix is effective and no regressions were introduced.

Scope Definition Template

Before engaging a penetration testing vendor, define the scope using this template:

Item Description

Target Services

List specific CRAIG services (e.g., craig-web, craig-intake, craig-cases) and their endpoints.

Authentication Flows

OIDC Authorization Code + PKCE (web UI), ROPC (CLI/tests), API key (partner intake), unauthenticated (public intake form).

In-Scope Attacks

OWASP Top 10, authentication bypass, RBAC boundary testing, IDOR, CSRF, injection attacks, API abuse.

Out-of-Scope

Denial of service against production, social engineering, physical access, attacks against Keycloak itself (separate product).

Environment

Devstack (Docker Compose) or staging deployment. Never test against production with real data.

Test Accounts

Provide test credentials for each role: admin, supervisor, caseworker, eligibility_worker, icpc_coordinator, readonly.

Data Sensitivity

Test environment must use synthetic data only (generated by craig-seed). No real PII/PHI.

Vendor Selection Criteria

  • CREST, OSCP, or equivalent certification for lead tester

  • Experience with REST API security testing

  • Experience with OIDC/OAuth2 authentication flows

  • Familiarity with child welfare or government systems (preferred)

  • Ability to produce findings in a format compatible with GitLab confidential issues

  • Willingness to perform re-testing after remediation at no additional cost

Pre-Test Checklist

  • Devstack or staging environment deployed and accessible to the testing team

  • Synthetic seed data loaded (craig-seed --seed 42 --families 12)

  • Test accounts created in Keycloak for all 9 roles (6 operational + the 3 ADR-054 office roles)

  • Scope document signed by both parties

  • Project maintainers and deploying agency stakeholders notified of test window

  • Database snapshot taken (for restoration after destructive tests)

  • Monitoring and alerting configured to distinguish test traffic from real incidents

Post-Test Report Handling

  1. Vendor delivers findings report (PDF + structured format).

  2. Project maintainer reviews findings within 2 business days.

  3. Each finding is logged as a confidential GitLab issue with severity classification.

  4. Findings are mapped to NIST SP 800-53 controls where applicable (see NIST Architecture Mapping).

  5. Remediation is prioritized per the SLA table above.

  6. Deploying agencies receive a summary of findings and remediation timeline (details redacted until fixes are deployed).

Re-Test Verification

  • After all Critical and High findings are remediated, request a re-test from the original vendor.

  • Re-test scope is limited to the specific findings and their surrounding attack surface.

  • Re-test results are appended to the original report.

  • Final report is stored as a security review evidence artifact in craig-security object storage.

Incident Response Overview

CRAIG follows a five-phase incident response lifecycle aligned with NIST SP 800-61.

Phase 1: Detect

  • Automated detection via the wildcard RabbitMQ audit subscriber (audit_log table)

  • CI/CD security scanning (SAST, dependency scanning, secret detection, cargo audit advisory DB)

  • Breach detection rules flag anomalous patterns (six default rules on detection_rules: failed auth, bulk access, after-hours access, privilege escalation, data export, account lockout)

  • Pre-push quality gates: cargo xtask security (ZAP + ffuf, phases 1–5) and the blocking axe-core accessibility audit over the enumerated page set (counts live in the VPAT)

  • External reports via the vulnerability disclosure policy (SECURITY.md)

Phase 2: Contain

  • Isolate affected service(s) — stop the container or revoke network access

  • Revoke compromised credentials (Keycloak sessions, API keys)

  • Preserve audit logs and database state for forensic analysis

  • Notify deploying agency incident response teams

Phase 3: Eradicate

  • Identify root cause (code vulnerability, misconfiguration, compromised credential)

  • Develop and test the fix per the security update release process above

  • Scan for indicators of compromise (IOCs) across all services

Phase 4: Recover

  • Deploy the patched version to all affected environments

  • Restore data from backup if integrity was compromised

  • Re-enable services and verify normal operation

  • Monitor for recurrence (increased logging, additional alerting rules)

Phase 5: Learn

  • Conduct a post-incident review within 5 business days

  • Document the timeline, impact, root cause, and remediation actions

  • Update security controls and monitoring rules to prevent recurrence

  • File a biennial security review record via POST /v1/security/reviews if the incident reveals a systemic gap

  • Update the NIST control assessment if any control was found to be ineffective

Related Pages

Edit this page · latest