Module 9: Designing Technical and Procedural Controls for CMMC Level 2

Step 1 – From NIST 800-171 Requirements to Concrete Controls

In CMMC 2.0 Level 2, you are essentially asked to operationalize NIST SP 800-171 Rev. 2 (110 security requirements) in a way that can be tested by a C3PAO or DIBCAC team.

Think of each requirement as needing three layers:

1. Technical controls – what the system actually does
2. Procedural controls – how people operate and maintain the system
3. Governance artifacts – policies, standards, and records that prove consistent implementation

A good mental model for design is to map NIST 800-171 / CMMC practices to the NIST Cybersecurity Framework (CSF) functions:

• Identify – Know where CUI is, who owns it, and what systems process it
• Protect – Limit access, harden configurations, encrypt, and train users
• Detect – Log, monitor, and identify anomalous behavior
• Respond – Contain and eradicate incidents affecting CUI
• Recover – Restore CUI systems and validate integrity

For this module, we focus on four major design domains:

1. Identity & Access Management (IAM) for CUI environments
2. Baseline technical controls (MFA, logging, hardening, backups)
3. Procedural layer (policies, procedures, and training)
4. Shared responsibility with cloud providers (especially FedRAMP / GCC High contexts)

As you go, continuously ask:

> If an assessor walked in today, could they see evidence that this control is designed, implemented, and maintained over time?

We will move step-by-step from requirement language → concrete designs you could actually implement in a small-to-mid-size defense contractor.

Step 2 – Designing Identity & Access Management for CUI

CMMC Level 2 heavily emphasizes Access Control (AC) and Identification and Authentication (IA) families from NIST 800-171.

2.1 Core IAM design principles

For a CUI enclave, design IAM around:

1. Single authoritative identity source

• Typically: Active Directory (AD) or Entra ID (Azure AD) for Windows-centric shops.
• Avoid local accounts on endpoints/servers handling CUI except for tightly controlled break-glass accounts.

1. Strong identity proofing & joiner/mover/leaver process

• Onboarding: HR → IT workflow; no account without HR authorization.
• Role changes: access is updated when job role changes, not just when requested.
• Offboarding: disable accounts immediately upon separation; remove from all groups; revoke tokens/sessions.

1. Role-Based Access Control (RBAC)

• Map NIST 800-171 AC.2.007, AC.3.012, etc.
• Define CUI roles (e.g., `CUIEngineer`, `CUIContracts`, `CUI_Admin`).
• Access to CUI file shares, projects, and applications is granted to roles, not individuals.

1. Least privilege and separation of duties

• Admins use separate admin accounts (no email/browsing).
• No one should be able to both develop code and unilaterally approve its deployment into CUI production without oversight.

2.2 MFA and strong authentication

For CMMC Level 2, MFA is effectively expected for:

• All remote access to the CUI environment (VPN, remote desktop, cloud portals)
• All privileged accounts (domain admins, cloud admins)
• Ideally, all user access to CUI systems, even on-prem

Design pattern example (Microsoft 365 GCC / GCC High):

• Identities in Entra ID (cloud) synchronized from on-prem AD.
• Conditional Access policies:
• Require MFA for all users accessing CUI-related apps (SharePoint CUI sites, Teams CUI channels, line-of-business apps).
• Block legacy authentication (POP/IMAP/older Office clients).
• Require compliant or hybrid-joined devices for CUI access.

2.3 Practical IAM design checklist

When designing IAM for CUI, ensure you can answer yes to these:

• Do we have a documented list of CUI systems and which identity store they use?
• Is there exactly one authoritative identity per person (no unmanaged duplicates)?
• Are group memberships and role assignments reviewed at least quarterly?
• Are service accounts inventoried, justified, and using strong credentials or managed identities?
• Are shared accounts for CUI strictly prohibited (or extremely limited and formally approved)?

Step 3 – IAM Design Thought Exercise

Imagine you are designing IAM for a 200-person defense contractor with a dedicated CUI enclave.

They currently:

• Use on-prem Active Directory with no MFA
• Allow local admin rights for many engineers
• Use shared generic accounts for a CUI file share (e.g., `CUI_DesignTeam`)

Task: In bullet points, sketch a minimum viable IAM redesign that would move them toward CMMC Level 2 alignment. Address:

1. Identity source and account lifecycle
2. MFA deployment scope and method
3. How you would eliminate or tightly control shared accounts
4. How you would handle local admin rights on endpoints

(Write your answer separately; then compare against the example solution in the next step.)

Step 4 – Example Solution: IAM Redesign for a CUI Environment

One possible minimum viable IAM redesign:

1. Identity source & lifecycle

• Declare on-prem AD the authoritative identity store for all CUI users.
• Implement a joiner/mover/leaver workflow: HR must submit a ticket before any account is created or modified.
• Create role-based AD groups: `CUIEngRead`, `CUIEngWrite`, `CUIContracts`, `CUIAdmin`.
• Map each employee to exactly one primary role group plus any additional justified groups.

1. MFA deployment

• Implement an MFA solution (e.g., Entra ID + VPN integration, or a 3rd-party MFA for VPN/RDP).
• Require MFA for:
• VPN access into the CUI enclave
• All `Domain Admin` and `CUI_Admin` accounts
• Any remote access tools (e.g., remote support tools) touching CUI systems.

1. Shared accounts

• Replace `CUIDesignTeam` shared account with **individual accounts** mapped to `CUIEng_Write`.
• If a shared account is temporarily unavoidable (e.g., legacy application):
• Document a formal exception.
• Store credentials in a password vault with check-in/out and logging.
• Limit access to the smallest feasible group and plan a sunset date.

1. Local admin rights

• Remove local admin rights from standard user accounts on CUI endpoints.
• Implement a Just-In-Time (JIT) elevation tool or IT helpdesk process for software installs.
• Maintain a small, documented set of local admin accounts used only by IT; log their usage.

This design directly supports multiple NIST 800-171 requirements (AC and IA families) and is something an assessor can test by:

• Reviewing AD group structures and membership
• Examining MFA configuration and logs
• Interviewing HR and IT about account lifecycle
• Spot-checking endpoints for local admin rights

Step 5 – Baseline Technical Controls: Hardening, Logging, and Backups

Now we translate several high-impact NIST 800-171 controls into a baseline technical stack.

5.1 Configuration hardening

Relevant families: CM (Configuration Management), SI (System and Information Integrity), SC (System and Communications Protection).

Key design elements:

1. Standard secure baselines

• Use CIS Benchmarks or DISA STIGs as starting points for:
• Windows servers and workstations in the CUI enclave
• Network devices (firewalls, switches, wireless)
• Implement baselines via Group Policy, MDM (e.g., Intune), or configuration management (e.g., Ansible).

1. Application allow-listing

• For high-value CUI systems, implement allow-listing (e.g., AppLocker, WDAC, or 3rd-party) to prevent unauthorized executables.

1. Network segmentation

• CUI enclave is logically isolated from corporate network with firewall rules and minimal, documented interconnections.
• Admin access to CUI is via jump hosts with MFA and logging.

1. Patch management

• Centralized patching (WSUS, SCCM, Intune, or equivalent).
• Documented timelines (e.g., critical patches within 14 days, others within 30 days) with exceptions tracked.

5.2 Logging and monitoring

Relevant families: AU (Audit and Accountability), IR (Incident Response), SI.

Design a logging architecture with:

1. Central log collection

• Collect from: domain controllers, key servers, firewalls, VPNs, EDR tools, cloud services (M365/Azure, AWS CloudTrail).
• Use a SIEM or log management platform (e.g., Splunk, Sentinel, Elastic, or a managed SOC service).

1. Defined log retention

• Typical target: 12 months or more for security logs affecting CUI (check with current DoD customer / contract requirements).
• Ensure storage is tamper-resistant (e.g., restricted access, immutable storage features where feasible).

1. Use cases / alerting

• At minimum, detect:
• Multiple failed logins and brute-force attempts
• Privilege escalation or new admin account creation
• New or unusual remote access
• Malware detections and quarantines

5.3 Backup and recovery design

Relevant families: CP (Contingency Planning), SC, SI.

Design backups with:

1. 3-2-1 principle

• 3 copies of data
• 2 different media types
• 1 copy offsite and logically separated (ideally immutable / offline)

1. Scope

• All CUI repositories (file shares, document management, databases).
• Configuration data (domain controllers, critical app configs, firewall rules).
• Key management data (if you run your own PKI / encryption keys).

1. Testing and documentation

• Perform regular restore tests (e.g., quarterly) and document results.
• Maintain a runbook for restoring CUI systems, including RTO/RPO targets and decision points.

Assessors will expect to see evidence: baseline documents, GPO exports, SIEM dashboards, backup job reports, and restore test records.

Step 6 – Quick Check: Baseline Technical Controls

Answer the following based on the baseline controls just discussed.

Step 7 – Procedural Layer: Policies, Procedures, and Training

CMMC assessments in practice often fail not on technology, but on missing or weak procedures and training.

7.1 Policy vs. standard vs. procedure

• Policy – High-level intent and requirements (e.g., All CUI must be accessed using MFA). Approved by leadership.
• Standard – Specific technical parameters (e.g., MFA must use FIPS 140-validated crypto; passwords must be ≥ 14 characters).
• Procedure / SOP – Step-by-step instructions (e.g., How IT creates a new CUI user account and assigns groups).

For each major technical control, you need at least:

1. A policy statement (why and what must be done)
2. A documented procedure (how it is done, by whom, and when)
3. Evidence that people are trained and records are kept

7.2 Example: MFA control full implementation

Consider the MFA requirement. A full implementation includes:

• Policy:
• All interactive logons to CUI systems (including remote access, cloud portals, and privileged access) must use multi-factor authentication.

• Procedure:
• IT-SEC-003: MFA Enrollment and Management
• Steps for enrolling users, handling lost tokens, revoking access, and verifying identity before resetting factors.

• Technical configuration:
• Conditional Access rules, VPN integration, RDP gateway config, etc.

• Training:
• New hire security awareness includes:
• How to use MFA tokens/apps
• How to report suspicious MFA prompts (push bombing)
• Annual refresher includes MFA phishing scenarios.

• Records:
• Change tickets for MFA rollouts
• Logs showing MFA usage
• Training attendance records and materials

7.3 Training program alignment

Training must be role-based and CUI-specific:

• All users: basics of CUI handling, phishing, MFA, reporting incidents.
• IT/admins: secure administration of CUI systems, privileged access management, log review, backup/restore procedures.
• Managers: approving access, handling insider threat indicators, escalation paths.

An assessor will often pick a control and trace it across policy → procedure → implementation → records → people’s understanding.

Step 8 – Map a Technical Control to Its Procedural Artifacts

Choose one of the following technical controls and design the supporting procedural artifacts:

• Centralized logging and SIEM monitoring for CUI systems
• Quarterly access review for CUI roles and groups
• Backup and recovery for CUI file shares

For your chosen control, write out:

1. A policy statement (1–2 sentences)
2. The title of a procedure/SOP and at least 3 key steps it would include
3. At least 2 types of evidence/records an assessor could review
4. One training topic that would help staff execute the procedure correctly

(Draft your answer; then compare with peers or course materials for feedback.)

Step 9 – Shared Responsibility with Cloud Providers (FedRAMP, GCC, etc.)

By late 2025, many CMMC-focused organizations use cloud services (e.g., Microsoft 365 GCC/GCC High, Azure Government, AWS GovCloud). These often have FedRAMP Moderate/High authorizations, but that does not mean the provider “does CMMC for you.”

9.1 Shared responsibility model basics

• Cloud provider responsibilities (documented in FedRAMP System Security Plans):
• Physical security of data centers
• Hypervisor security, some network controls
• Underlying platform hardening and many SC/SI controls

• Customer responsibilities (you, the contractor):
• Identity and access (accounts, MFA, RBAC)
• Data classification and where CUI is stored
• Configuration of security features (DLP, retention, logging, encryption options)
• Incident response, user training, policies and procedures

9.2 Concrete examples

1. Example: Microsoft 365 GCC High

• Provider: ensures data centers are in the right geographic and personnel control regime, provides secure baseline.
• You: must configure:
• Which SharePoint sites/Teams are authorized for CUI
• MFA and Conditional Access
• Data Loss Prevention (DLP) rules for CUI
• Audit log retention and export to your SIEM.

1. Example: AWS GovCloud

• Provider: secures the underlying infrastructure, hypervisor, and some network controls.
• You: responsible for securing EC2 instances, S3 buckets, IAM roles, security groups, OS patching, and application-level logging.

9.3 How this plays out in CMMC assessments

Assessors will ask questions like:

• Show us how you ensure only authorized users can access CUI in M365.
• Where are your logs from your cloud services stored and how long are they retained?
• How did you determine which NIST 800-171 requirements are inherited from the cloud provider vs. implemented by you?

A best practice is to maintain a shared responsibility matrix mapping each NIST 800-171 requirement to:

• Provider responsibility (with reference to FedRAMP documentation/attestations)
• Your responsibility (with reference to your policies, procedures, and configurations)
• Any gaps or assumptions you still need to address

This matrix becomes powerful evidence during a C3PAO or DIBCAC assessment.

Step 10 – Quick Check: Shared Responsibility

Test your understanding of cloud shared responsibility in a CMMC context.

Step 11 – Flashcard Review: Key Terms and Concepts

Use these flashcards to reinforce critical concepts from this module.

Step 12 – Design a Minimal CUI Control Stack (Capstone Exercise)

Your task is to synthesize this module into a baseline CUI control stack for a hypothetical small contractor (100 employees, mix of on-prem and cloud, handling CUI for a single DoD program).

In outline form, design:

1. Identity & Access

• Identity store, MFA scope, RBAC structure, local admin strategy.

1. Protection Controls

• Hardening baselines, segmentation, endpoint protection, and where CUI is allowed to reside (on-prem vs. cloud).

1. Detection Controls

• Log sources, SIEM or managed SOC, key alert use cases.

1. Response & Recovery

• Incident response playbooks for CUI incidents, backup/restore plan and test schedule.

1. Procedural & Governance Layer

• Key policies (at least 3), associated procedures, and role-based training topics.

1. Cloud Shared Responsibility

• One example of a cloud service used for CUI, with at least 3 controls clearly assigned to the provider vs. the organization.

Aim to produce something that, if handed to a security engineer, would be a starting blueprint for CMMC Level 2 implementation.

(Draft this outside the platform; treat it as your personal design assignment.)