From 10ab62bc19f8a3f869bebf54ffb93b9adada9345 Mon Sep 17 00:00:00 2001 From: Cameron Hopkin <35571853+cameronhopkin@users.noreply.github.com> Date: Tue, 26 May 2026 18:08:18 -0400 Subject: [PATCH 1/2] Add controls matrix scaffold and Access Control family first draft Includes: - controls/AC-access-control.md: First-pass draft of all 22 AC controls - controls/README.md: Matrix overview, family index, Rev 2 vs Rev 3 status note - references/README.md: Authoritative source documents - gap-patterns/, templates/: Scaffold directories for follow-on content - README.md: Reflect WaypointCA maintainership, link to matrix, note Rev 2 scope - pyproject.toml: Rename to cmmc-validator, update URLs to WaypointCA org Matrix content is a first draft for review and edit. Please verify accuracy of implementation patterns and gap observations before merge. Co-Authored-By: Claude Opus 4.7 (1M context) --- README.md | 39 ++- controls/AC-access-control.md | 511 ++++++++++++++++++++++++++++++++++ controls/README.md | 36 +++ gap-patterns/.gitkeep | 0 pyproject.toml | 10 +- references/README.md | 28 ++ templates/.gitkeep | 0 7 files changed, 607 insertions(+), 17 deletions(-) create mode 100644 controls/AC-access-control.md create mode 100644 controls/README.md create mode 100644 gap-patterns/.gitkeep create mode 100644 references/README.md create mode 100644 templates/.gitkeep diff --git a/README.md b/README.md index e6d305d..103021e 100644 --- a/README.md +++ b/README.md @@ -1,14 +1,27 @@ -# CMMC Control Validator +# CMMC Validator [![Python 3.9+](https://img.shields.io/badge/python-3.9+-blue.svg)](https://www.python.org/downloads/) [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT) [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black) -A Python-based tool for validating Infrastructure as Code (IaC) configurations against CMMC Level 2 and NIST SP 800-171 security controls. Designed for organizations preparing for CMMC certification or maintaining continuous compliance. +Validator and reference matrix for CMMC 2.0 Level 2 / NIST SP 800-171 Rev 2 controls. Includes a Python-based Terraform Infrastructure as Code (IaC) compliance scanner and a practitioner reference matrix oriented toward Defense Industrial Base (DIB) contractors. + +Maintained by [Waypoint Compliance Advisory](https://waypointca.com) (SDVOSB, CAGE 14Z63). + +## Standards revision + +This repository tracks **NIST SP 800-171 Rev 2**, the version cited by the CMMC 2.0 final rule (32 CFR Part 170) for Level 2 assessments. NIST SP 800-171 Rev 3 (published May 2024) restructures the controls; migration is on the roadmap and will track DoD's eventual adoption of Rev 3 for CMMC assessments. + +## Documentation + +- [`controls/`](./controls/) — Reference control matrix with implementation patterns and frequently observed gaps. First family (Access Control) published; remaining families in progress. +- [`gap-patterns/`](./gap-patterns/) — Common assessment gaps with remediation patterns (in progress) +- [`references/`](./references/) — Authoritative source documents +- [`templates/`](./templates/) — Worksheet templates: POA&M, SSP outline, etc. (in progress) ## Overview -CMMC Control Validator parses Terraform configurations and evaluates them against the 110 practices required for CMMC Level 2 certification. It provides: +CMMC Validator parses Terraform configurations and evaluates them against the 110 practices required for CMMC Level 2 certification. It provides: - **Automated Compliance Checking**: Scan Terraform files for security misconfigurations - **Gap Analysis Reports**: Identify which controls are met, partially met, or missing @@ -57,14 +70,14 @@ CMMC Control Validator parses Terraform configurations and evaluates them agains ### From PyPI ```bash -pip install cmmc-control-validator +pip install cmmc-validator ``` ### From Source ```bash -git clone https://github.com/cameronhopkin/cmmc-control-validator.git -cd cmmc-control-validator +git clone https://github.com/WaypointCA/cmmc-validator.git +cd cmmc-validator pip install -e . ``` @@ -165,7 +178,7 @@ jobs: python-version: '3.11' - name: Install CMMC Validator - run: pip install cmmc-control-validator + run: pip install cmmc-validator - name: Run Compliance Check run: | @@ -290,8 +303,8 @@ Contributions are welcome! Please see [CONTRIBUTING.md](CONTRIBUTING.md) for gui ### Development Setup ```bash -git clone https://github.com/cameronhopkin/cmmc-control-validator.git -cd cmmc-control-validator +git clone https://github.com/WaypointCA/cmmc-validator.git +cd cmmc-validator python -m venv venv source venv/bin/activate pip install -e ".[dev]" @@ -300,14 +313,16 @@ pytest ## References +Full reference list in [`references/`](./references/). Key sources: + - [CMMC Model Overview](https://dodcio.defense.gov/CMMC/) - [NIST SP 800-171 Rev 2](https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final) - [AWS CMMC Resources](https://aws.amazon.com/compliance/cmmc/) ## License -MIT License - see [LICENSE](LICENSE) for details. +MIT License (code) and CC BY 4.0 (matrix content). See [LICENSE](LICENSE) for code license details. Cite Waypoint Compliance Advisory when reusing matrix content. -## Author +## Maintainer -Cameron Hopkin - [GitHub](https://github.com/cameronhopkin) +Maintained by Cameron T. Hopkin on behalf of [Waypoint Compliance Advisory LLC](https://waypointca.com) (SDVOSB, CAGE 14Z63). diff --git a/controls/AC-access-control.md b/controls/AC-access-control.md new file mode 100644 index 0000000..afb38e2 --- /dev/null +++ b/controls/AC-access-control.md @@ -0,0 +1,511 @@ +# Access Control (AC) + +NIST SP 800-171 Rev 2, Section 3.1. 22 controls total. + +The Access Control family covers who can access systems holding Controlled Unclassified Information (CUI), what they can do once authenticated, and how those access decisions are enforced. Two basic security requirements (3.1.1, 3.1.2) and 20 derived security requirements (3.1.3 through 3.1.22). + +--- + +## 3.1.1 Authorized users (Basic) + +**Requirement:** Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). + +**Common implementation patterns:** +- Centralized identity provider (Entra ID, Okta, Google Workspace) federated to all systems holding CUI +- Service accounts and machine identities provisioned through the same governance as human accounts +- Quarterly access recertification with manager attestation +- Inventory of all systems-of-record for users, with documented joiner/mover/leaver flows + +**Frequently observed gaps:** +- Local accounts on individual servers that bypass the IdP +- Service accounts created ad-hoc without ownership or expiration +- "Emergency access" accounts that bypass MFA without compensating monitoring +- Contractors retain access after engagement end + +**Related controls:** 3.1.2, 3.5.1, 3.5.2 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.1 +- NIST SP 800-53 Rev 5 AC-2, AC-3 + +--- + +## 3.1.2 Transaction and function authorization (Basic) + +**Requirement:** Limit system access to the types of transactions and functions that authorized users are permitted to execute. + +**Common implementation patterns:** +- Role-based access control (RBAC) tied to job function, not individual identity +- Attribute-based access control (ABAC) for finer-grained authorization in CUI repositories +- Just-in-time elevation for sensitive transactions +- Documented authorization matrix (RACI per data type and system function) + +**Frequently observed gaps:** +- All users get "developer" or "admin" by default +- Authorization logic in application code, not tied to IdP groups +- No documented mapping from job role to system functions +- Admins can perform any action; no separation between admin types + +**Related controls:** 3.1.1, 3.1.4, 3.1.5 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.2 +- NIST SP 800-53 Rev 5 AC-3 + +--- + +## 3.1.3 Information flow enforcement + +**Requirement:** Control the flow of CUI in accordance with approved authorizations. + +**Common implementation patterns:** +- Data classification labels enforced at storage (S3 bucket tags, file share permissions) +- DLP scanning at egress points (email gateway, USB block, cloud upload) +- Network egress controls separating CUI-handling networks +- Documented information flow diagrams reviewed annually + +**Frequently observed gaps:** +- CUI moves into developer test environments without authorization +- Email forwarding rules silently exfiltrate to personal accounts +- Cloud sync clients (Dropbox, OneDrive) sidestep network egress controls +- Print jobs to home printers without CUI authorization + +**Related controls:** 3.1.20, 3.1.22, 3.13.1 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.3 +- NIST SP 800-53 Rev 5 AC-4 + +--- + +## 3.1.4 Separation of duties + +**Requirement:** Separate the duties of individuals to reduce the risk of malevolent activity without collusion. + +**Common implementation patterns:** +- Privileged action requests reviewed by a different individual (four-eyes principle) +- Source code commit and approver split; merge requires reviewer +- Production deploy and production approval split between roles +- Separate accounts for development versus administrative work + +**Frequently observed gaps:** +- Developer is also the deploy reviewer for their own code +- Same admin can both create users and audit access logs +- Small team excuses ("we only have two engineers") without compensating controls + +**Related controls:** 3.1.5, 3.3.5 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.4 +- NIST SP 800-53 Rev 5 AC-5 + +--- + +## 3.1.5 Least privilege + +**Requirement:** Employ the principle of least privilege, including for specific security functions and privileged accounts. + +**Common implementation patterns:** +- Default-deny IAM policies; permissions added explicitly +- Time-bounded privileged access via PAM (CyberArk, BeyondTrust, or cloud-native equivalent) +- Separate account for elevated actions (`admin.cameron@`, not the daily-driver account) +- IAM access analyzer findings (or equivalent) reviewed monthly + +**Frequently observed gaps:** +- IAM policies with `*:*` (full admin) granted to operations teams +- Long-lived AWS access keys for human users instead of SSO +- Cross-account roles trust principal `*` for the source account +- Power users have permanent admin without elevation workflow + +**Related controls:** 3.1.6, 3.1.7, 3.1.15 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.5 +- NIST SP 800-53 Rev 5 AC-6 + +--- + +## 3.1.6 Non-privileged accounts for non-security functions + +**Requirement:** Use non-privileged accounts or roles when accessing nonsecurity functions. + +**Common implementation patterns:** +- Daily-driver account has standard user privileges +- Privileged account used only for administrative tasks, never email or web browsing +- Separate browser profile or virtual machine for privileged work +- Monitoring/SIEM alerts when privileged accounts perform routine activity + +**Frequently observed gaps:** +- One account for all activities, including email and admin +- Privileged account used to browse the internet +- No separation between daily work and admin tasks + +**Related controls:** 3.1.5, 3.1.7 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.6 +- NIST SP 800-53 Rev 5 AC-6(2) + +--- + +## 3.1.7 Privileged function execution and auditing + +**Requirement:** Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs. + +**Common implementation patterns:** +- `sudo` and Windows "Run As" limited to specific commands, all logged centrally +- AWS IAM permission boundaries prevent users from escalating +- Application-layer authorization checks logged with user ID and function +- Tamper-evident logs (object lock, append-only) for privileged actions + +**Frequently observed gaps:** +- `sudoers` wildcard allows arbitrary command execution +- Audit logs writable by the same admin whose actions they record +- Application authorization checks present only in client-side code + +**Related controls:** 3.1.5, 3.3.1, 3.3.8 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.7 +- NIST SP 800-53 Rev 5 AC-6(9), AC-6(10) + +--- + +## 3.1.8 Unsuccessful logon attempts + +**Requirement:** Limit unsuccessful logon attempts. + +**Common implementation patterns:** +- Account lockout after 5 to 10 failed attempts (configurable per system) +- Progressive backoff before lockout for low-confidence brute force +- Lockout alerts to security monitoring +- IP-based rate limiting at edge, separate from per-user lockout + +**Frequently observed gaps:** +- No lockout on internal admin consoles ("internal-only" assumption) +- Lockout duration too short (30 seconds), enabling credential stuffing +- Lockout disabled for "operational convenience" + +**Related controls:** 3.1.11, 3.3.1 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.8 +- NIST SP 800-53 Rev 5 AC-7 + +--- + +## 3.1.9 Privacy and security notices + +**Requirement:** Provide privacy and security notices consistent with applicable CUI rules. + +**Common implementation patterns:** +- Banner on login screens citing CUI handling requirements +- Click-through acknowledgment recorded with user ID and timestamp +- Annual re-acknowledgment as part of access recertification +- Banner text reviewed by legal or compliance + +**Frequently observed gaps:** +- Default OS banner with no CUI-specific language +- Banner not present on all CUI-accessible systems +- No record of user acknowledgment + +**Related controls:** 3.2.1, 3.2.2 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.9 +- NIST SP 800-53 Rev 5 AC-8 + +--- + +## 3.1.10 Session lock + +**Requirement:** Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity. + +**Common implementation patterns:** +- 15-minute idle lock enforced via group policy or MDM +- Lock screen does not display sensitive content (privacy curtain on dashboards) +- Physical workstation policy requires manual lock when leaving + +**Frequently observed gaps:** +- Idle lock disabled for "dashboard" or "kiosk" workstations holding CUI +- Lock screen previews leak email subjects or notification content +- Personal devices accessing CUI without enforced lock + +**Related controls:** 3.1.11, 3.13.1 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.10 +- NIST SP 800-53 Rev 5 AC-11 + +--- + +## 3.1.11 Session termination + +**Requirement:** Terminate (automatically) a user session after a defined condition. + +**Common implementation patterns:** +- Session timeout of 8 to 12 hours; reauthentication required after +- Sliding window versus absolute timeout documented per system +- Conditional access (Entra ID, Okta) terminates sessions on risk signals +- Idle SSH session timeout enforced via PAM module + +**Frequently observed gaps:** +- "Remember me" tokens never expire +- Application sessions outlive IdP sessions +- VPN sessions persist after user disconnects from corporate network + +**Related controls:** 3.1.8, 3.1.10 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.11 +- NIST SP 800-53 Rev 5 AC-12 + +--- + +## 3.1.12 Remote access monitoring and control + +**Requirement:** Monitor and control remote access sessions. + +**Common implementation patterns:** +- All remote access via VPN or zero-trust proxy, logged centrally +- Session recording for privileged remote sessions (RDP, SSH jumphost) +- Geo-fencing alerts on remote access from unusual locations +- Connection metadata retained for the incident response window + +**Frequently observed gaps:** +- Direct RDP exposure (no VPN) to "internal" infrastructure +- Personal devices used for remote access without compliance posture check +- Remote access logs collected but never reviewed + +**Related controls:** 3.1.13, 3.1.14, 3.13.7 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.12 +- NIST SP 800-53 Rev 5 AC-17 + +--- + +## 3.1.13 Cryptographic protection of remote access + +**Requirement:** Employ cryptographic mechanisms to protect the confidentiality of remote access sessions. + +**Common implementation patterns:** +- TLS 1.2 or higher enforced; older versions disabled at the protocol level +- VPN uses FIPS-validated ciphers +- SSH host key pinning, strict cipher list +- Mutual TLS for service-to-service connections over the public internet + +**Frequently observed gaps:** +- Self-signed certificates accepted; users trained to click through warnings +- VPN allows fallback to weak ciphers for legacy clients +- TLS termination at a non-FIPS-validated load balancer + +**Related controls:** 3.13.8, 3.13.11 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.13 +- NIST SP 800-53 Rev 5 AC-17(2) + +--- + +## 3.1.14 Managed access control points + +**Requirement:** Route remote access via managed access control points. + +**Common implementation patterns:** +- Single VPN concentrator or zero-trust gateway per region +- Split-tunneling disabled or restricted to specific subnets +- No direct internet-facing SSH or RDP on CUI systems +- Internal DNS resolution available only via VPN + +**Frequently observed gaps:** +- Engineers configure personal VPN access to bypass managed gateway +- Cloud services (S3, RDS) accessible from internet via public endpoint +- Split-tunneling allows direct internet egress from CUI workstation + +**Related controls:** 3.1.12, 3.13.1 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.14 +- NIST SP 800-53 Rev 5 AC-17(3) + +--- + +## 3.1.15 Privileged remote commands and security-relevant information + +**Requirement:** Authorize remote execution of privileged commands and remote access to security-relevant information. + +**Common implementation patterns:** +- Privileged remote sessions require pre-approval workflow +- Step-up authentication (hardware token, push approval) for privileged remote actions +- Just-in-time elevation logged with business justification +- Privileged session recording reviewed quarterly + +**Frequently observed gaps:** +- "Production access" granted permanently to anyone in operations +- No documented approval for one-off privileged remote actions +- Approval system exists but bypassed during outages with no follow-up review + +**Related controls:** 3.1.5, 3.1.12 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.15 +- NIST SP 800-53 Rev 5 AC-17(4) + +--- + +## 3.1.16 Wireless access authorization + +**Requirement:** Authorize wireless access prior to allowing such connections. + +**Common implementation patterns:** +- Corporate WiFi requires certificate-based authentication (EAP-TLS) +- Guest WiFi segregated from CUI networks at L3 +- Inventory of authorized wireless networks; rogue AP detection +- BYOD wireless on a separate SSID with conditional access + +**Frequently observed gaps:** +- Pre-shared key (PSK) WiFi shared with all employees +- No detection of rogue access points +- Guest network bridges to corporate via misconfigured switch + +**Related controls:** 3.1.17, 3.1.18 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.16 +- NIST SP 800-53 Rev 5 AC-18 + +--- + +## 3.1.17 Wireless authentication and encryption + +**Requirement:** Protect wireless access using authentication and encryption. + +**Common implementation patterns:** +- WPA3-Enterprise or WPA2-Enterprise (PEAP or EAP-TLS minimum) +- Certificate-based device authentication paired with user credentials +- Wireless intrusion detection (WIDS) + +**Frequently observed gaps:** +- Open or WPA2-Personal networks still in use +- WiFi password unchanged after employee turnover +- Hidden SSID treated as a security control (it isn't) + +**Related controls:** 3.1.16 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.17 +- NIST SP 800-53 Rev 5 AC-18(1) + +--- + +## 3.1.18 Mobile device connections + +**Requirement:** Control connection of mobile devices. + +**Common implementation patterns:** +- MDM (Intune, Jamf) enforces compliance posture before access +- Conditional access blocks non-managed devices from CUI applications +- Device attestation logs reviewed for compliance drift + +**Frequently observed gaps:** +- Personal phone with corporate email but no MDM enrollment +- "Bring your own laptop" without compliance baseline +- Lost-device process slow or undocumented + +**Related controls:** 3.1.19, 3.1.21 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.18 +- NIST SP 800-53 Rev 5 AC-19 + +--- + +## 3.1.19 Mobile device encryption + +**Requirement:** Encrypt CUI on mobile devices and mobile computing platforms. + +**Common implementation patterns:** +- Full-disk encryption (FileVault, BitLocker, LUKS) enforced via MDM +- Container-based encryption for BYOD scenarios +- Removable storage encryption (BitLocker To Go) or block by policy +- Encryption status reported to a compliance dashboard + +**Frequently observed gaps:** +- Encryption keys escrowed in a service whose audit logs are rarely reviewed +- USB-based external drives accepted without encryption +- Older mobile devices that cannot enforce encryption still permitted + +**Related controls:** 3.1.18, 3.13.11 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.19 +- NIST SP 800-53 Rev 5 AC-19(5) + +--- + +## 3.1.20 External system connections + +**Requirement:** Verify and control or limit connections to and use of external systems. + +**Common implementation patterns:** +- Vendor risk reviews before integrating external services +- Documented data flow for each external system handling CUI +- API gateway with allow-list of approved external endpoints +- Outbound proxy logging all external connections + +**Frequently observed gaps:** +- SaaS tools adopted by individual teams without security review +- Browser extensions sending data to unknown third parties +- "Approved vendor list" not enforced at the network layer + +**Related controls:** 3.1.3, 3.1.22, 3.13.6 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.20 +- NIST SP 800-53 Rev 5 AC-20 + +--- + +## 3.1.21 Portable storage on external systems + +**Requirement:** Limit use of organizational portable storage devices on external systems. + +**Common implementation patterns:** +- Encrypted USB drives with serial number registration +- Endpoint controls prevent unregistered USB devices from mounting +- Loaned devices tracked with chain-of-custody documentation + +**Frequently observed gaps:** +- Generic USB drives permitted with no inventory +- No restriction on use of corporate-owned drives at home networks +- Lost-drive incidents not reported + +**Related controls:** 3.1.18, 3.8.7 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.21 +- NIST SP 800-53 Rev 5 AC-20(2) + +--- + +## 3.1.22 CUI on publicly accessible systems + +**Requirement:** Control CUI posted or processed on publicly accessible systems. + +**Common implementation patterns:** +- Pre-publication review for marketing materials, public documentation, code repositories +- Static analysis on public repos for CUI markers (regex match on classified data tags) +- Public GitHub org tied to approval workflow before repos go public +- Periodic crawl of company-affiliated public surfaces (websites, public storage) + +**Frequently observed gaps:** +- Public S3 bucket holding CUI uploaded by mistake +- GitHub repo accidentally made public by individual contributor +- Customer success teams post screenshots with CUI to a public help portal + +**Related controls:** 3.1.3, 3.1.20 + +**References:** +- NIST SP 800-171 Rev 2 § 3.1.22 +- NIST SP 800-53 Rev 5 AC-22 diff --git a/controls/README.md b/controls/README.md new file mode 100644 index 0000000..92b1756 --- /dev/null +++ b/controls/README.md @@ -0,0 +1,36 @@ +# Control Matrix + +A practitioner reference for NIST SP 800-171 controls as scoped by CMMC 2.0 Level 2 assessment. Each control family is a single markdown file with consistent structure: + +- **Requirement** — Plain-language summary of the NIST control text +- **Common implementation patterns** — How DIB contractors typically satisfy the control +- **Frequently observed gaps** — Where assessors most often find deficiencies +- **Related controls** — Cross-references to other 800-171 controls +- **References** — Authoritative source documents + +## Scope and revision + +This matrix tracks **NIST SP 800-171 Rev 2** controls, the version cited by the CMMC 2.0 final rule (32 CFR Part 170) for Level 2 assessments. NIST SP 800-171 Rev 3 (published May 2024) introduces a different control structure and numbering. Migration to Rev 3 is on the roadmap and will track the DoD's eventual adoption of Rev 3 for CMMC assessments. + +## Families + +| ID | Family | Controls | Status | +|---|---|---|---| +| AC | [Access Control](./AC-access-control.md) | 22 | First draft published | +| AU | Audit and Accountability | 9 | To be drafted | +| AT | Awareness and Training | 3 | To be drafted | +| CM | Configuration Management | 9 | To be drafted | +| IA | Identification and Authentication | 11 | To be drafted | +| IR | Incident Response | 3 | To be drafted | +| MA | Maintenance | 6 | To be drafted | +| MP | Media Protection | 8 | To be drafted | +| PE | Physical Protection | 6 | To be drafted | +| PS | Personnel Security | 2 | To be drafted | +| RA | Risk Assessment | 3 | To be drafted | +| CA | Security Assessment | 4 | To be drafted | +| SC | System and Communications Protection | 16 | To be drafted | +| SI | System and Information Integrity | 7 | To be drafted | + +## Disclaimer + +This matrix is reference material, not legal advice. It is not a substitute for engaging a Certified Third-Party Assessment Organization (C3PAO) for CMMC Level 2 assessment. diff --git a/gap-patterns/.gitkeep b/gap-patterns/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/pyproject.toml b/pyproject.toml index 8346674..f90ae31 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -3,7 +3,7 @@ requires = ["setuptools>=61.0", "wheel"] build-backend = "setuptools.build_meta" [project] -name = "cmmc-control-validator" +name = "cmmc-validator" version = "1.0.0" description = "Validate Infrastructure as Code against CMMC Level 2 and NIST 800-171 controls" readme = "README.md" @@ -69,10 +69,10 @@ docs = [ cmmc-validator = "cmmc_validator.cli:cli" [project.urls] -Homepage = "https://github.com/cameronhopkin/cmmc-control-validator" -Documentation = "https://github.com/cameronhopkin/cmmc-control-validator#readme" -Repository = "https://github.com/cameronhopkin/cmmc-control-validator.git" -Issues = "https://github.com/cameronhopkin/cmmc-control-validator/issues" +Homepage = "https://github.com/WaypointCA/cmmc-validator" +Documentation = "https://github.com/WaypointCA/cmmc-validator#readme" +Repository = "https://github.com/WaypointCA/cmmc-validator.git" +Issues = "https://github.com/WaypointCA/cmmc-validator/issues" [tool.setuptools.packages.find] where = ["src"] diff --git a/references/README.md b/references/README.md new file mode 100644 index 0000000..c920cf3 --- /dev/null +++ b/references/README.md @@ -0,0 +1,28 @@ +# References + +Authoritative source documents for the control matrix and validator. + +## NIST publications + +- **NIST SP 800-171 Rev 2** (Feb 2020): Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final +- **NIST SP 800-171 Rev 3** (May 2024): Successor to Rev 2 with restructured controls. Tracked here as a forward-looking reference; CMMC 2.0 assessments still cite Rev 2 as of this writing. https://csrc.nist.gov/publications/detail/sp/800-171/rev-3/final +- **NIST SP 800-171A**: Assessment procedures for 800-171 controls. https://csrc.nist.gov/publications/detail/sp/800-171a/final +- **NIST SP 800-53 Rev 5**: Security and Privacy Controls for Information Systems and Organizations. The catalog from which 800-171 is derived. https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final + +## CMMC + +- **CMMC Model Overview** (DoD CIO): https://dodcio.defense.gov/CMMC/ +- **CMMC 2.0 Final Rule (32 CFR Part 170)**: https://www.federalregister.gov/documents/2024/10/15/2024-22905/cybersecurity-maturity-model-certification-cmmc-program +- **CMMC Assessment Guide, Level 2**: https://dodcio.defense.gov/Portals/0/Documents/CMMC/AssessmentGuideL2.pdf + +## DFARS clauses + +- **DFARS 252.204-7012**: Safeguarding Covered Defense Information and Cyber Incident Reporting +- **DFARS 252.204-7019**: Notice of NIST SP 800-171 DoD Assessment Requirements +- **DFARS 252.204-7020**: NIST SP 800-171 DoD Assessment Requirements +- **DFARS 252.204-7021**: Cybersecurity Maturity Model Certification Requirements + +## AWS-specific references + +- **AWS Compliance: CMMC**: https://aws.amazon.com/compliance/cmmc/ +- **AWS CMMC Customer Responsibility Matrix (CRM)**: Available from AWS Artifact for accounts with appropriate agreements diff --git a/templates/.gitkeep b/templates/.gitkeep new file mode 100644 index 0000000..e69de29 From dab814fbb9b31354b4e75e8fdfa7561b3e9e459a Mon Sep 17 00:00:00 2001 From: Cameron Hopkin <35571853+cameronhopkin@users.noreply.github.com> Date: Fri, 29 May 2026 14:33:49 -0400 Subject: [PATCH 2/2] Remove phantom pyhcl2 dependency that breaks pip install CI was failing across all four Python versions with: ERROR: Could not find a version that satisfies the requirement pyhcl2>=4.0.0 ERROR: No matching distribution found for pyhcl2>=4.0.0 Root cause: requirements.txt and pyproject.toml both pinned pyhcl2>=4.0.0, but PyPI's pyhcl2 package max version is 2.0.1. Worse, the code never imports hcl2 anywhere - the Terraform parser uses stdlib re/json for its own regex-based block parsing. Phantom dependency. Removed from both files. Pip install will now succeed. Co-Authored-By: Claude Opus 4.7 (1M context) --- pyproject.toml | 1 - requirements.txt | 1 - 2 files changed, 2 deletions(-) diff --git a/pyproject.toml b/pyproject.toml index f90ae31..5eb5a3f 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -42,7 +42,6 @@ classifiers = [ requires-python = ">=3.9" dependencies = [ "click>=8.0.0", - "pyhcl2>=4.0.0", "jinja2>=3.0.0", "pyyaml>=6.0", "rich>=13.0.0", diff --git a/requirements.txt b/requirements.txt index 3c6c9ff..5b4b116 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,6 +1,5 @@ # Core dependencies click>=8.0.0 -pyhcl2>=4.0.0 jinja2>=3.0.0 pyyaml>=6.0 rich>=13.0.0