CMMC Level 3 Security Configurations Explained
Preparing for Cybersecurity Maturity Model Certification (CMMC) compliance can feel like a daunting task. For any company that manages Controlled Unclassified Information (CUI), the process can feel like rolling a heavy boulder up a very steep incline. However, understanding CMMC Level 3 security configurations give you a better understanding of how to organize your approach and prioritize your activities.
Where to find the security configurations
The long and winding road to technical controls starts with the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171. Like every good regulatory guidance, NIST SP 800-171 isn’t a standalone document. It contains references to other NIST publications, including SP 800-53, SP 800-128, and SP 800-70.
NIST SP 800-128 is the “Guide for Security-Focused Configuration Management of Information Systems.” Although security configurations themselves live in the National Security Checklist Program Repository, 800-128 guides you through the steps to create a configuration management process.
3 Tips for Managing Security Configurations
Managing security configurations is hard. There’s no other way to put it. However, the following tips should help you get started.
Break systems into configuration items (CIs)
A configuration item is a group of system components treated as a single entity for the Security-focused Configuration Management (SecCM). Examples of CIs include:
- Specific system components: servers, workstations, routers, or applications
- Group of system components: grouping together servers that have the same operating system, similar network components like routers and switches, or a suite of applications
- Non-component object: firmware, documentation
By breaking systems into CIs, you can take a more granular approach to configuration management giving you more control over managing the system’s security configurations.
Set baseline configurations
Baseline configurations are the formally reviewed and agreed -upon set of specifications for a system or CI within a system that you use as the basis for future builds, releases, or changes. After setting these, changes can only be made according to your organization’s formal change control procedures.
It’s also important to keep in mind that these can evolve over time. For example, early in the system development lifecycle (SDLC), you might set the baseline around functional requirements. However, later in the build, you might want to mature those baselines to keep pace with the system. New baselines might include technical design, software load, or architecture.
When you change the configuration baseline, you agree that anything different from the previous baseline is now the new approved configuration. However, as a best practice, you should maintain older versions of the baseline configurations so that you can “rollback” or revert to those configurations. This practice protects you in case the new configurations create a problem for your systems.
Do a security impact analysis
Before you change a baseline configuration, you should analyze how it could impact your overall security. Systems tend to be in a constant state of flux. A robust security posture requires analyzing how to functionality changes can impact security controls or impact your data breach risk.
It is essential to keep your organization’s risk tolerance in mind. Prior to implementing a configuration change, you should make sure to review NIST 800-53’s Configuration Management impact analysis best practices, including:
- Ensure anyone engaging in the impact analysis has the appropriate skills and technical experience
- Review security and privacy plans, policies, and procedures to understand control requirements
- Review system design documentation and operational procedures to understand how changes might impact controls
- Review potential impact on supply chain partners
- Determine potential to create new risks to people’s privacy
- Review how to mitigate potential risks
- Create a separate test environment that is physically or logically separate from the operational environment
- Verify controls implemented correctly and operating as intended without negatively impacting security and privacy
SteelCloud: Secure, consistent baseline configuration management
SteelCloud’s Security Technical Implementation Guideline (STIG) and CIS Benchmark Control automation enable you to manage security configurations without the hassle caused by manual processes. Our patented scanning engine can scan with 5,00-10,000 systems per hour. Our ConfigOS then remediates conflicts, with the ability to manage 2,000-4,000 systems per hour. Finally, we also provide reporting capabilities that enable you to prove your compliance posture.
Leave a comment