This is the second in a three-part series on the new Department of Defense (DoD) audit requirement called Cybersecurity Maturity Model Certification (CMMC). Part one introduced the DoD CMMC model and what it means for the future of U.S. government cybersecurity suppliers. Part two goes into more detail about the CMMC audit itself.
CMMC did not originate out of thin air—it combines prevailing cybersecurity control standards, such as NIST SP 800-53, NIST SP 800-171, and ISO/IEC 27001. But CMMC isn’t just about repackaging older best practices. It intends to evolve and adapt to changing technological needs and new threats. Because of this and the DoD’s reach, many in the cybersecurity industry anticipate that CMMC will significantly raise the bar in securing critical infrastructure. Mårten Mickos, CEO of HackerOne, told F5 Labs, “I somehow think that CMMC can define a lot of practices in the area of cybersecurity, just like the framework by NIST has become the reference point for how to organize security in a large organization. Pretty impressive in my mind how progressive the federal government is on these topics.”
Indeed, many IT and security leaders outside of the DoD supply chain, or even outside of the United States, will be watching how CMMC progresses. Let’s look at the current security controls in CMMC and answer some basic questions.
What Are CMMC’s Security Controls and Control Domains?
The rudimentary level for CMMC is Level 1 with just 17 essential control domains, which function as goals for implementing security controls. For Level 1 CMMC organizations, the controls supporting these control domains do not need to be perfect, fully integrated, and automated processes. They provide a foundation for an organization’s security program as well as a commitment to future security program development. For some companies, this may mean breaking ground on a program in an organization that has never established a security program before.
As with any security governance process, these controls center around the specific information assets that a company must protect from exposure, tampering, or destruction. Compliance requirements in different industries focus on a variety of key assets, such as payment card data, financial transactions, or protected health information. For CMMC, the referenced protected asset is the Controlled Unclassified Information (CUI), which is the DoD data shared with the supplier. For the purposes of passing the CMMC audit, controls focus on CUI and CUI-holding systems, although your organization may have other assets and data sources worth protecting.
None of the 17 control domains mentioned in the Level 1 list should be unusual or controversial, much like our own recommended list of top controls. They include the most basic, essential security controls that appear on every best practices list. While there are 17 control domains, for simplicity we’ll break them down into four major areas.
Security Governance Control Domains
All security programs should begin with defining clear security objectives. In most organizations, these objectives are detailed in a foundational document called a security policy, which describes the security goals to employees. Woven throughout the CMMC control domains are requirements to develop various plans, policies, and requirements related to different domains of security. A security policy is an excellent singular way to fulfill that requirement at a high level.
This policy should define what CUI is and isn’t for the company, so that all personnel are aware of what to protect. The security policy is a basic declaration that risks exist and everyone needs to work together to reduce those risks. It is also the “license from management” that the IT or security team uses to enact and enforce security controls. Other policies and security documents can flow from this top security policy, such as device-hardening standards or acceptable-usage statements. When a security policy is violated, mechanisms should also be in place to report, track, and resolve these incidents.
The specific CMMC control domains covered here are: Risk Management and Awareness and Training.
Visibility Control Domains
Before establishing controls to protect an asset, an organization needs to know where it is. Therefore, companies need a system or process for identifying and tracking CUI. All contact with CUI-holding systems, both physical and electronic, must be observed, logged, and reviewed. Asset tracking should also cover removal to avoid exposing CUI data when disposing of old hardware.
Organizations also need visibility into persons accessing the CUI, which means performing background checks for employees and visitors. A mechanism should exist to look for attackers and their tools, such as malware. Visibility involves knowing where attackers are coming from, where the holes in your system lie, and how attacks could exploit them. That means processes in place include vulnerability scanning and identifying good sources for threat intelligence.
The specific CMMC control domains covered here are: Asset Management, Situational Awareness, Personnel Security, Security Assessment, and Audit and Accountability.
Access Control Domains
Access control is at the heart of security: you want to let the right people in to do only the things they’re supposed to do. F5 Labs research has consistently shown that access attacks are the number one threat to IT systems. Access control means locked doors, strong sign-in security, and role-based authorization. Regarding authentication, some forms of verification, such as multifactor authentication, are definitely superior than plain old passwords, although not without some costs. Another aspect of access control works at the network level, which means segregating the networks holding CUI from untrusted networks like the Internet.
The specific CMMC control domains covered here are: Identification and Authentication, Access Control, Media Protection, Physical Protection, System and Information Integrity, and Systems and Communications Protection.
Operational Control Domains
Good security relies on strong operational hygiene, so it makes sense that CMMC include operational controls. This means supporting and patching CUI-holding systems, locking down default configurations, and removing default passwords. The IT department should have a clear policy on employees using personal systems, which often have inadequate protection. Operational security also means having resilience and recovery systems, which includes processes to detect and manage incidents as well as backup and system rebuild procedures.
The specific CMMC control domains covered here are: Maintenance, Configuration Management, Incident Response, and Recovery.
Building Those Domains Up from Here
Since CMMC follows the Capability Maturity Model, as explained in part 1, the higher compliance levels build upon the foundations of Level 1. The lower maturity levels set up the framework for security goals, with a commitment to expanding and improving these practices over time. An organization adds more controls to support the control domains, such as adding written requirements on configuring firewalls or detailing the steps for code reviews to find security flaws in applications. As a company moves up the CMMC levels, further defining and measuring progress against these control domains, it grows in maturity. The foundational goals around security stay the same, but the depth and detail of the process expand.
Preparing for an Audit
It can take up to a year for an organization to build a security program from scratch that can successfully make it through an external audit. With CMMC looming, many DoD suppliers have CMMC preparation programs underway. F5 itself is no different—both the organization and its products are already subject to numerous compliance certifications, and we have extensive controls and documentation in place. I spoke with Mary Gardner, the Chief Information Security Officer for F5, about CMMC. She said, “Since F5, like many organizations, is already under some kind of compliance requirements, we are looking at where there might be gaps in our controls between what we’re already doing and what CMMC requires.”
Gardner noted that F5 is already on the ISO/IEC 27001 certification path, so many of those controls already apply to CMMC. Therefore, the best way for a company to start is to look at what it’s already done and see what pertains to CMMC.
Even if an organization hasn’t been through an audit yet, it can still create an inventory of the current controls, and if it has a security policy, it’s worth carefully reviewing. The policy should list the control environment and how the security processes flow. Gardner reminds us that “everything ties back to policy.”
Most organizations are already doing some kind of cybersecurity, whether it’s documented in a policy or not. Begin by interviewing the IT staff about password requirements and firewalls, the human resources department about background checks, the facilities people about door locks and cameras, and the developers about security testing. From this information, a company can build a thorough list of controls as the basis of its security program, and then map these against the specific CMMC control domains and requirements for the level it’s looking to achieve. The project list is the gap between what the company has and what it needs to do.
Next Time
Remember, if you are a DoD supplier and you’re not preparing for CMMC, you need to get started now. Those in the supply chain will need to deal with this within the next five years. Next time, we’ll cover the assessment process; even if you have a mature security program in place, there is a difference between doing it and proving it. We will also continue to examine how CMMC could become the model for all future compliance standards.
