Enforcing "least functionality" (NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control CM.L2-3.4.6) means configuring Windows and Linux systems so they provide only the services, ports, applications, and capabilities necessary for their approved mission — nothing more; this guide gives practical, technical steps and small‑business examples to implement that requirement within a Compliance Framework program.
Understanding the control and objectives
The key objective of CM.L2-3.4.6 is to reduce attack surface by removing or disabling capabilities that are not required for an asset's function. In practice this maps to a combination of inventory, baselines, service and package minimization, firewall rules, application allow‑listing, and runtime restrictions (sandboxing). For a Compliance Framework implementation you'll need documented baselines, change and exception processes, and evidence that systems are deployed and continuously monitored to those baselines.
Implementation notes (what to document and why)
Document an authorized services/ports matrix per system role (e.g., "workstation", "dev build server", "web server"), include a justification and approval for each enabled service, and track exceptions with expiration. Maintain a configuration change control record that links deviations to risk assessments. These artifacts are often the primary evidence auditors expect for CM.L2-3.4.6.
Hardening Windows — practical steps and commands
Start from a minimal Windows image (Server Core for servers where possible) and apply a security baseline (Microsoft Security Compliance Toolkit or CIS). Inventory running services and listening ports: use Get-Service and Get-NetTCPConnection or netstat -ano / ss. Disable or set unneeded services to Manual/Disabled using PowerShell: e.g., Get-Service -Name "XblGameSave" | Stop-Service -Force; Set-Service -Name "XblGameSave" -StartupType Disabled. Remove optional features with DISM: dism /online /Get-Features and dism /online /Disable-Feature /FeatureName:Name. Enforce application control with AppLocker or Windows Defender Application Control (WDAC) and publish explicit allow lists; a simple AppLocker policy example uses New-AppLockerPolicy to generate rules from a reference machine. Use Windows Firewall (or a host firewall profile via Intune/GPO) to restrict inbound/outbound flows: New-NetFirewallRule -DisplayName "Allow RDP from AdminNet" -Direction Inbound -Action Allow -RemoteAddress 10.0.0.0/24 -Protocol TCP -LocalPort 3389. Standardize and deploy settings via Group Policy, Microsoft Intune, or SCCM/ConfigMgr to ensure consistent baselines and to capture compliance evidence.
Hardening Linux — practical steps and commands
For Linux, build minimal OS images (install only required packages) and apply a benchmark (CIS, OpenSCAP). Identify listening services and ports: ss -tuln or netstat -tuln. Disable unnecessary services: systemctl disable --now bluetooth.service && systemctl mask cups.service. Remove unneeded packages: apt-get purge --auto-remove
Automation, baselines and continuous monitoring
Manual change is error-prone; use automation to enforce least functionality. For Windows, use Group Policy + SCCM/Intune or PowerShell DSC; for Linux, use Ansible, Puppet or Chef to apply idempotent playbooks that disable services, enforce package lists, and deploy firewall rules. Maintain golden images and use image build pipelines to bake in baselines. Scan on a schedule with CIS-CAT, OpenSCAP or third‑party vulnerability scanners and feed results into a SIEM or ticketing system. For runtime verification, enable Windows Event Forwarding or auditd on Linux and monitor for attempts to start blocked services or install unauthorized packages — these are signs an exception or compromise is occurring.
Small-business real-world example
Scenario: a 25‑person small engineering firm handling Controlled Unclassified Information (CUI). Practical implementation: (1) Classify endpoints by role (developer workstation, CAD workstation, admin server). (2) Build three golden images with minimal installs. (3) Deploy images via Intune (Windows) and Ansible (Linux). (4) Turn on AppLocker on workstations and only allow signed CAD and office apps; disallow installers in user contexts. (5) Block all inbound connections by default at host firewall and only open required ports to specific subnets (e.g., developer git and build server access). (6) Disable SMBv1, printer services on non‑print servers, remove telephony packages on servers, and enable SELinux on Linux hosts. (7) Track exceptions: a developer may need a service for testing — approve with a 30‑day expiration and monitor closely. These practical steps are achievable with modest budgets but deliver strong evidence for CM.L2-3.4.6.
Compliance tips and risks of not implementing
Key tips: start with inventory and roles, use baselines with change control, automate enforcement, and retain logs/audit trails for evidence. Maintain an exceptions register and periodically review exceptions. If you don't apply least functionality you increase attack surface—this leads to higher likelihood of lateral movement, persistent compromise (malware hiding in unused services), data exfiltration of CUI, and failing audits or losing DoD/contract opportunities. Non‑compliance can have financial and reputational consequences beyond technical risk.
Summary: To meet CM.L2-3.4.6, combine documented system roles and approved service matrices with technical hardening (disable/remove packages and services, enforce host firewall rules, use allow‑listing, apply systemd sandboxing / SELinux or AppArmor, and automate with Group Policy/Intune/Ansible). Keep records of baselines and exceptions, scan continuously, and monitor for deviations — these concrete actions make least functionality operational, auditable, and sustainable for small businesses pursuing NIST SP 800-171 / CMMC 2.0 Level 2 compliance.
