Employ the principle of least functionality
📖 What This Means
The principle of least functionality means configuring systems to provide only the essential capabilities needed for their intended purpose and nothing more. This reduces the attack surface by eliminating unnecessary services, applications, and features that could be exploited by attackers. For example, a web server should only have web hosting software installed, not email or database services. Similarly, user workstations should not have administrative privileges or unnecessary software installed. This practice ensures that systems are secure by default and reduces the complexity of managing security configurations.
🎯 Why It Matters
Unnecessary functionality increases the risk of cyberattacks by providing more potential entry points for attackers. For instance, in 2017, the Equifax breach occurred due to an unpatched vulnerability in a web application framework that wasn't essential to their operations. This led to the exposure of sensitive personal data of 147 million people. The DoD emphasizes this control because it directly reduces the attack surface of systems handling Controlled Unclassified Information (CUI). By limiting functionality, organizations can better protect their systems, reduce maintenance costs, and simplify compliance with other security controls.
✅ How to Implement
- Identify and disable unused services in cloud environments (e.g., AWS EC2, Azure VMs).
- Use cloud-native tools like AWS Security Hub or Azure Security Center to scan for unnecessary features.
- Implement role-based access control (RBAC) to limit permissions to the minimum required.
- Use containerization (e.g., Docker) to isolate applications and remove unnecessary dependencies.
- Regularly review and update cloud service configurations to ensure they align with least functionality principles.
- Enable logging and monitoring for cloud services to detect and disable unused resources.
📋 Evidence Examples
System Configuration Documentation
Security Scans
Change Control Records
Training Records
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For CM.L2-3.4.6 ("Employ the principle of least functionality"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe your configuration management process, including baseline configurations, change control procedures, vulnerability management, and how configuration compliance is monitored and enforced. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"CM.L2-3.4.6 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to employ the principle of least functionality. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"CM.L2-3.4.6 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to employ the principle of least functionality. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"CM.L2-3.4.6 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all system types within the CUI boundary requiring baselines
- • Document configuration management tools and CMDB
- • Map change control workflow from request to implementation
- • Ensure this control covers all systems within your defined CUI boundary where employ the principle of least functionality applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Configuration Management Policy
- 📄 Baseline configuration documents
- 📄 Change management records
- 📄 CMDB/asset inventory
- 📄 Evidence artifacts specific to CM.L2-3.4.6
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will compare actual system configurations against documented baselines, review change tickets for proper approval workflow, and verify vulnerability remediation within SLA.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Does your organization have a documented policy for least functionality?
Question 2: Have all unnecessary services and applications been disabled or removed?
Question 3: Are least functionality principles enforced across all systems (cloud, on-premise, hybrid)?
Question 4: Is regular monitoring and validation of least functionality configurations in place?
Question 5: Are all changes to system configurations documented and approved?
⚠️ Common Mistakes (What Auditors Flag)
1. Failing to document enabled services and applications.
2. Not regularly reviewing and updating configurations.
3. Overlooking cloud service configurations.
4. Lacking training for IT staff on least functionality.
5. Not integrating least functionality with change control processes.
📚 Parent Policy
This practice is governed by the Configuration Management Policy