This step-by-step guide explains how to establish, implement, and enforce security configuration settings for IT products to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control CM.L2-3.4.2, with practical implementation advice, real-world small-business scenarios, and specific technical controls you can apply immediately.
1) Start with an accurate inventory and risk-based baselines
Begin by inventorying all IT products (servers, endpoints, network devices, cloud resources, appliances, and SaaS configurations). For each product record vendor, OS/firmware version, function (e.g., domain controller, file share, web server), and whether it processes Controlled Unclassified Information (CUI). Use automated discovery (Nmap/Zenmap, AD discovery, Azure/ AWS inventory APIs) if you have limited staff. Next, assign a risk tier (high/medium/low) so you prioritize baselines and remediation effort. Small-business example: a 20-person defense subcontractor tags its on‑prem Windows servers and Azure VMs as "high" because they store CUI, and laptops as "medium."
2) Define and document secure configuration baselines
Choose authoritative baselines mapped to the product type: CIS Benchmarks, DISA STIGs for government-aligned systems, vendor hardening guides, or internally derived baselines where no benchmark exists. Capture the baseline as a configuration profile that lists required settings, acceptable deviations, and rationale. Record baselines in your System Security Plan (SSP) and configuration management database (CMDB). Practical settings to include: password/lockout policies (minimum length 12–14, complexity, lockout threshold 5), local admin removal, audit policy levels, SMB signing, TLS minimum versions, SSH key policies, and host-based firewall rules.
3) Implement baselines using automation and centralized management
Where possible implement baselines centrally rather than manually. Recommended tools: Group Policy (AD) or Microsoft Intune for Windows, JAMF for macOS, SCCM/BigFix/Ansible for patch and configuration management, AWS Systems Manager/Azure Policy for cloud resources. Example (small-business scenario): Use Intune to deploy a Windows 10 configuration profile that enforces BitLocker, disables SMBv1, and configures Defender ATP settings; use AWS Config rules to ensure S3 buckets are not publicly accessible and that encryption is enabled. For Linux servers, use Ansible playbooks to apply SSH hardening, disable unused services, set file permissions, and manage package updates.
Concrete automation example
Here is a minimal Ansible task snippet to enforce SSH hardening on Linux servers (example—adapt for your environment):
- name: Harden SSH configuration
hosts: all
become: yes
tasks:
- name: Ensure sshd_config has Protocol 2
lineinfile:
path: /etc/ssh/sshd_config
regexp: '^Protocol'
line: 'Protocol 2'
create: yes
- name: Disable root login over SSH
lineinfile:
path: /etc/ssh/sshd_config
regexp: '^PermitRootLogin'
line: 'PermitRootLogin no'
4) Enforce and monitor configuration compliance continuously
Enforcement is two parts: preventative enforcement (policy push) and detective monitoring (scans and alerts). Preventative: use MDM/GPO/Configuration Management to prevent users from changing enforced settings. Detective: run regular automated checks—weekly vulnerability/configuration scans (Nessus, Qualys), SCAP/OVAL content, CIS-CAT Pro for benchmarks, or OSQuery for endpoint inventory. Use a SIEM or centralized logging (Splunk/ELK/Microsoft Sentinel) to collect configuration change events and generate alerts for drift or rollback. For cloud, enable continuous assessment with AWS Config rules, Azure Policy, and Google Cloud Policy Controller.
5) Change control, drift remediation, and exceptions
Embed configuration changes in your change control process: every configuration baseline change must be tracked, risk-assessed, and approved. Automate drift detection and remediation where feasible—e.g., an Azure Policy remediation task that re-applies approved tag or encryption settings, or an Ansible runbook executed by Jenkins when changes are detected. Maintain a documented exceptions process: short-term exceptions must have compensating controls, expiration dates, and must be entered into your POA&M (Plan of Action & Milestones). Small-business example: if a legacy device requires an older TLS version, document the business justification, restrict network access, and schedule replacement on the POA&M.
6) Compliance evidence, policy, and practical tips
Capture evidence for auditors: baseline documents, configuration templates, change tickets, scan reports (with dates and remediation evidence), and SSP/POA&M entries. Best practices: map each baseline setting to the specific CM.L2-3.4.2 requirement and controls in your SSP; prioritize high-impact systems first; apply the principle of least privilege to admin accounts; automate patching for OS and third‑party software; and use multi-factor authentication for administrative access. For limited budgets, adopt managed services (MDR, cloud native security) and leverage free community CIS Benchmarks plus open-source tools (OSQuery, OpenSCAP).
Risk of non-implementation: failing to enforce secure configuration settings increases the likelihood of malicious access, lateral movement, data exfiltration of CUI, ransomware infection, and procurement penalties (contract loss or inability to bid on DoD work). From a compliance perspective, missing baselines or lack of continuous enforcement will produce findings in an assessment and require costly remediation and POA&M tracking.
Summary: To meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 CM.L2-3.4.2, inventory assets, select authoritative baselines, implement them with centralized and automated tooling, continuously monitor for drift, embed changes in formal change control, and document everything in your SSP/POA&M. For small businesses, prioritize high-risk systems, use managed/cloud enforcement features, and automate as much as possible—these practical steps both reduce security risk and create audit-ready evidence for compliance.
