CM.L2-3.4.7 of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 requires organizations to restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services — a core control to reduce attack surface and protect Controlled Unclassified Information (CUI); this guide gives practical, technical, and governance-focused steps tailored for small businesses pursuing compliance with the Compliance Framework.
\n\nThe requirement expects an organization to identify what is essential for business operations and explicitly remove, disable, or block everything else. In Compliance Framework terms, this maps to configuration management and system hardening activities documented in the System Security Plan (SSP), enforced through technical controls, and tracked via a Plan of Action and Milestones (POA&M) for exceptions. Key objectives are to minimize exposed services, prevent unnecessary code execution, and reduce vectors for exploitation that could compromise CUI.
\n\nStart with a complete inventory of endpoints, servers, VMs, network devices, and IoT/OT devices. For a small business this can be performed using MDM/EDR tools (Microsoft Intune, Jamf, CrowdStrike) or open-source scanners (Nmap, GLPI + FusionInventory). Run an authenticated scan to list installed packages and listening ports: example commands — Linux: sudo systemctl list-units --type=service --state=running, ss -tuln; Windows: PowerShell Get-Service | Where-Object {$_.Status -eq 'Running'}, and netstat -ano or Get-NetTCPConnection. Store results in your CMDB and create a baseline \"approved services and programs\" list in the SSP.
Not all services labelled \"nonessential\" are safe to remove — perform a lightweight risk assessment: identify which services handle CUI, which are required for core workflows, and which are legacy/unused. For a small defense contractor, for example, the build server and tenant VPN services are essential, while Telnet, print spooler on isolated servers, or SMBv1 are likely nonessential and high risk. Document each decision, associated risk level, and mitigation in the SSP and POA&M if removal cannot be immediate.
\n\nUse centralized tools to enforce changes at scale. For Linux: disable and stop services with sudo systemctl disable --now service-name; remove packages with sudo apt purge telnetd or sudo yum remove package. For Windows: change startup types via PowerShell Set-Service -Name \"Spooler\" -StartupType Disabled and stop services Stop-Service -Name \"Spooler\", or use sc config. Use GPO, Intune configuration profiles, or SCCM to push these settings. For network services, close unused ports at the host firewall (Windows Firewall with Advanced Security, ufw/nftables) and at the edge firewall/router. Example host firewall command: sudo ufw deny 23 (blocks Telnet).
Application control prevents execution of unauthorized code and is often required to demonstrate restriction of nonessential programs. Options: Windows AppLocker or Microsoft Defender Application Control (MDAC) for Windows endpoints; signed-package and RPM/deb-only policies for Linux; and endpoint allowlists provided by EDR. For small shops, create a baseline AppLocker policy from a golden image (New-AppLockerPolicy -Xml) and deploy via GPO/Intune. Maintain a process to add approved applications through a change control ticket and audit all whitelist changes monthly.
\n\nNetwork-level controls complement host hardening. Segment networks so CUI systems are on isolated VLANs with firewall rules that only allow necessary protocols/ports between tiers. Use ACLs on switches and enforce egress filtering on the perimeter to block common exfiltration channels. Run periodic port scans (nmap -sT -p- 10.0.0.0/24) after changes to validate no unintended services are exposed. Implement continuous monitoring: forward security logs (service start/stop, application block events) to a SIEM or to a cloud log aggregator (Azure Sentinel, Elastic) and create alerts for newly opened ports or unauthorized service starts.
\n\nImplement an exception process: any service or program allowed despite not being on the approved list requires a documented exception with business justification, risk acceptance, compensating controls, and an expiration date (common TTL: 30–90 days). Record exceptions in the POA&M and update the SSP. Integrate these changes into your change control workflow (ticket, approval, test, deploy, verify). For Compliance Framework reporting, capture evidence: configuration screenshots, change tickets, deployment logs, and periodic scans showing compliance.
\n\nFailure to restrict nonessential programs/services increases attack surface, enables persistence mechanisms (e.g., weak or unnecessary services like Telnet or SMBv1), and facilitates lateral movement — all common root causes in breaches that expose CUI. Non-compliance risks include failed assessments, POA&M proliferation, possible loss of DoD contracts, and remediation costs far exceeding the price of preventative hardening. Best practices for small businesses: start with a prioritized pilot (10–20 endpoints), use MDM/EDR to automate enforcement, schedule quarterly verification scans, and treat the approved-software list as a living document tied to procurement and onboarding processes.
\n\nSummary: Implementing CM.L2-3.4.7 is a mix of inventory, risk-based decisions, technical hardening (disable/remove services, application control, firewall rules), continuous monitoring, and strong governance (SSP, POA&M, change control). For small businesses, a phased approach that leverages existing MDM/EDR tools, documents exceptions, and validates changes through scheduled scans will meet Compliance Framework expectations while dramatically reducing your exposure and protecting CUI.
", "plain_text": "CM.L2-3.4.7 of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 requires organizations to restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services — a core control to reduce attack surface and protect Controlled Unclassified Information (CUI); this guide gives practical, technical, and governance-focused steps tailored for small businesses pursuing compliance with the Compliance Framework.\n\nWhat CM.L2-3.4.7 requires and the Compliance Framework context\nThe requirement expects an organization to identify what is essential for business operations and explicitly remove, disable, or block everything else. In Compliance Framework terms, this maps to configuration management and system hardening activities documented in the System Security Plan (SSP), enforced through technical controls, and tracked via a Plan of Action and Milestones (POA&M) for exceptions. Key objectives are to minimize exposed services, prevent unnecessary code execution, and reduce vectors for exploitation that could compromise CUI.\n\nStep-by-step implementation\n\n1) Inventory and baseline every asset\nStart with a complete inventory of endpoints, servers, VMs, network devices, and IoT/OT devices. For a small business this can be performed using MDM/EDR tools (Microsoft Intune, Jamf, CrowdStrike) or open-source scanners (Nmap, GLPI + FusionInventory). Run an authenticated scan to list installed packages and listening ports: example commands — Linux: sudo systemctl list-units --type=service --state=running, ss -tuln; Windows: PowerShell Get-Service | Where-Object {$_.Status -eq 'Running'}, and netstat -ano or Get-NetTCPConnection. Store results in your CMDB and create a baseline \"approved services and programs\" list in the SSP.\n\n2) Risk-assess and categorize services and programs\nNot all services labelled \"nonessential\" are safe to remove — perform a lightweight risk assessment: identify which services handle CUI, which are required for core workflows, and which are legacy/unused. For a small defense contractor, for example, the build server and tenant VPN services are essential, while Telnet, print spooler on isolated servers, or SMBv1 are likely nonessential and high risk. Document each decision, associated risk level, and mitigation in the SSP and POA&M if removal cannot be immediate.\n\n3) Disable/remove nonessential software and services (technical controls)\nUse centralized tools to enforce changes at scale. For Linux: disable and stop services with sudo systemctl disable --now service-name; remove packages with sudo apt purge telnetd or sudo yum remove package. For Windows: change startup types via PowerShell Set-Service -Name \"Spooler\" -StartupType Disabled and stop services Stop-Service -Name \"Spooler\", or use sc config. Use GPO, Intune configuration profiles, or SCCM to push these settings. For network services, close unused ports at the host firewall (Windows Firewall with Advanced Security, ufw/nftables) and at the edge firewall/router. Example host firewall command: sudo ufw deny 23 (blocks Telnet).\n\n4) Implement application control and whitelisting\nApplication control prevents execution of unauthorized code and is often required to demonstrate restriction of nonessential programs. Options: Windows AppLocker or Microsoft Defender Application Control (MDAC) for Windows endpoints; signed-package and RPM/deb-only policies for Linux; and endpoint allowlists provided by EDR. For small shops, create a baseline AppLocker policy from a golden image (New-AppLockerPolicy -Xml) and deploy via GPO/Intune. Maintain a process to add approved applications through a change control ticket and audit all whitelist changes monthly.\n\nNetwork hardening and monitoring\nNetwork-level controls complement host hardening. Segment networks so CUI systems are on isolated VLANs with firewall rules that only allow necessary protocols/ports between tiers. Use ACLs on switches and enforce egress filtering on the perimeter to block common exfiltration channels. Run periodic port scans (nmap -sT -p- 10.0.0.0/24) after changes to validate no unintended services are exposed. Implement continuous monitoring: forward security logs (service start/stop, application block events) to a SIEM or to a cloud log aggregator (Azure Sentinel, Elastic) and create alerts for newly opened ports or unauthorized service starts.\n\nGovernance: change control, exceptions, and documentation\nImplement an exception process: any service or program allowed despite not being on the approved list requires a documented exception with business justification, risk acceptance, compensating controls, and an expiration date (common TTL: 30–90 days). Record exceptions in the POA&M and update the SSP. Integrate these changes into your change control workflow (ticket, approval, test, deploy, verify). For Compliance Framework reporting, capture evidence: configuration screenshots, change tickets, deployment logs, and periodic scans showing compliance.\n\nRisks of not implementing CM.L2-3.4.7 and compliance tips\nFailure to restrict nonessential programs/services increases attack surface, enables persistence mechanisms (e.g., weak or unnecessary services like Telnet or SMBv1), and facilitates lateral movement — all common root causes in breaches that expose CUI. Non-compliance risks include failed assessments, POA&M proliferation, possible loss of DoD contracts, and remediation costs far exceeding the price of preventative hardening. Best practices for small businesses: start with a prioritized pilot (10–20 endpoints), use MDM/EDR to automate enforcement, schedule quarterly verification scans, and treat the approved-software list as a living document tied to procurement and onboarding processes.\n\nSummary: Implementing CM.L2-3.4.7 is a mix of inventory, risk-based decisions, technical hardening (disable/remove services, application control, firewall rules), continuous monitoring, and strong governance (SSP, POA&M, change control). For small businesses, a phased approach that leverages existing MDM/EDR tools, documents exceptions, and validates changes through scheduled scans will meet Compliance Framework expectations while dramatically reducing your exposure and protecting CUI." }, "metadata": { "description": "Practical, step-by-step guidance for small businesses to meet NIST SP 800-171 / CMMC 2.0 CM.L2-3.4.7 by restricting nonessential programs, functions, ports, protocols, and services to reduce attack surface and protect CUI.", "permalink": "/how-to-implement-nist-sp-800-171-rev2-cmmc-20-level-2-control-cml2-347-step-by-step-guide-to-restricting-nonessential-programs-and-services.json", "categories": [], "tags": [] } }