CMMC Weekly Series #4
Posted on April 17, 2020 by Christopher Bukowski, Esq.
Physical Protection (PE)
Part 1: Filling the Void
From the very start, CMMC has been closely related to NIST SP 800-171 (Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations) as well as other frameworks, such as NIST SP 800-37 (Risk Management Framework), etc. Though the CMMC security framework may be closely associated and even take pieces of its own framework from these other systems, it can sometimes be hard to determine where CMMC fits into the overall puzzle of protecting sensitive information.
In order to see CMMC’s overall place in relation to the other frameworks, we need to review a brief history of the Government-wide evolution of protecting its sensitive information and then apply that summary to industry. For the last few decades the federal government has passed several laws, each aimed at protecting certain types of sensitive information. Initially it began with privacy laws and progressed from there. Eventually this led to the Federal Information Security Management Act (FISMA) of 2002 which, in a nutshell, required that all federal agencies implement a standard of security controls for their respective systems in order to protect the sensitive data on the systems. The information could be anything from individual privacy information – FOUO or CUI – or all the way up to Classified Information and beyond, each with their own set of security standards.
At the time, DOD already had its own version of standard security controls in place called DITSCAP (DOD Information Technology Security Certification and Accreditation Process). Later, after FISMA was passed, DOD replaced DITSCAP with DIACAP (DOD Information Assurance Certification and Accreditation Process) which was still specific to DOD. Eventually, in 2014, the Risk Management Framework (RMF) was introduced via NIST SP 800-37 (Risk Management Framework (RMF) for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy) with third party Assessment and Authorization (A&A) to help standardize all federal agencies under one set of policies, and standards for protecting and evaluating the security of their systems. The RMF process has mechanisms in place to allow individual systems to be evaluated in accordance to the sensitivity of the information held on their systems, and then processes in place for properly securing the system dependent on the information in the system. This helped formalize and standardize system security across the systems in the federal government.
However, there still remained an issue – a missing piece to the puzzle. Though the DOD and the Federal Government as a whole had evolved their processes and standards to a uniform practice, there was still the vulnerability of what information its supply chain partners managed on their systems. After all, a chain is only as strong as its weakest link. If the Federal Government had standards in place to protect information such as FOUO, CUI, privacy, and especially Classified information, then it logically follows that its contractors, handling the same type of information, should have similar standards in place.
To begin, we address classified information which has always had a standard of protection, whether by government agency or industry. The DOD’s – and other agencies’ – standards and manual for protecting this type of information since 2006 has been the DOD 5220.22-M, National Industrial Security Program Operating Manual (NISPOM). The NISPOM provides a set of standards for industry to protect classified systems much like NIST SP 800-37 (and its predecessors) does for government agencies.
Industry, in large part, follows a similar path as its federal agency counterparts when it comes to protecting classified information and even the chain of command. According to the NISPOM (which similarly reflects the hierarchy of its federal counterparts), at the head of information security is typically the Facility Security Officer (FSO), who is a Key Management Personnel (KMP) for the company and has overall responsibility for the security of the information for which it is custodian. The FSO can essentially be synonymous with other titles dependent on the organization, agency or company, including Chief Information Security Officer (CISO), Industry Security Director, Chief Infosec Officer, Chief Security Officer, etc. and can often times be combined with other senior / c-suite positions such as Chief Information Officer (CIO), Chief Technology Officer (CTO), etc. Regardless of the title, the FSO (for these purposes) typically reports directly to the head of the organization – the President, CEO, Director, etc. – and is also given a great deal of latitude and autonomy, so as to avoid either actual or constructive coercion against the interest of the common good or even the appearance of said coercion, whether it in fact exists or not.
Typically, as the head of information security, the FSO may have many departments reporting to him/her, including physical security (including guards, etc.), the Insider Threat Program Senior Official (ITPSO), Alternate or Assistant FSOs (A-FSOs), and the security department responsible for protecting the organizations Information Systems (IS). In the case of an industry organization’s IS containing classified information, the NISPOM points directly back to FISMA and NIST SP 800-37. Typically, the team protecting the IS counterparts is led by an Information System Security Manager (ISSM) who falls directly under the purview of the FSO, working with the FSO in IS security and reporting directly to the FSO on most occasions. The ISSM may then have other Information Systems Security Officers (ISSOs) under him/her performing IS security duties and reporting to the ISSM. Depending on how large the organization is, there can be even more subcategories of IS security professionals under the ISSO reporting up the chain of command to the FSO. This industry standard, essentially follows that of the federal agencies where things are reported straight up to the CISO (similar to the FSO) and then relayed to the system owner, agency head, program manager, etc.
However, there are still many types of information, other than classified, that are considered sensitive and they may even use different names identifying the same type of information depending on the agency that held it. For instance, in the DOD there is privacy information, FOUO (For Official Use Only), CTI (Controlled Technical Information), CDI (Controlled Defense Information), etc.
To address this concern and help protect this non-classified yet still sensitive information, the DOD and associated agencies developed FAR 52.204-21 (Basic Safeguarding of Covered Contractor Information Systems). The DOD, further solidifying its effort to protect this information, also developed DFARS 252.204-7012 (Safeguarding Covered Defense Information and Cyber Incident Reporting) to compliment the FAR clause. Both clauses required contractors possessing certain types of sensitive information to self-attest that they had complied with the proper security controls, namely those contained in NIST SP 800-171 (Protecting CUI in Nonfederal Systems and Organizations).
This was tantamount, to one degree or another, to a teacher asking students to grade their own work and attest to that grade. Sure, some students would be honest and provide their actual scores, while others might cut corners to create a better score, while others still might not even complete the homework, quizzes or tests and simply attest to receiving an A in each case. Similarly, although presumably the majority of contractors made a good faith effort to abide by and honestly attest to the security posture of their system, there was no guarantee of the veracity of the attestation – not to mention the vagueness associated with the requirements and the cloud of uncertainty that many contractors felt regarding what exactly needed to be done. This process still seemed insufficient without having more specific standards and an objective third party to confirm the validity of the otherwise self-certification.
Along comes the CMMC framework, which attempts to address both these concerns by providing better clarity, through a 5 level framework, and an objective third party confirmation of the contractor’s system security posture.
CMMC finally provides the missing piece to the puzzle. Where NIST SP 800-37 (RMF) covered both classified and unclassified but sensitive information on federal agency systems, which required a third-party authorization, industry only had the NISPOM in place to protect classified information. Now, with CMMC, all other information that is sensitive yet unclassified has a set of objective standards for protection and audit. CMMC fills in that gap. Together, the NISPOM and CMMC are the standards for industry in protecting its information parallel to the RMF framework established for federal agencies.
CMMC, in effect, is the little brother to the NISPOM, as they both complement each other. Similarly, these 2 standards for industry, taken together, reflect the standards provided in the RMF framework for both classified and unclassified information.
Although the NISPOM standards, on a whole, are more stringent since the information it is protecting is inherently more sensitive than that of CMMC, the two frameworks have several similarities. Given that, in large part, the NISPOM and CMMC framework complement each other in pursuit of the same goal, similar to that of NIST SP 800-37 and the RMF framework, it would make sense for CMMC to fall under the responsibility of the ISSO, who, under NISPOM, is responsible for all ISs (which contain the majority of the sensitive unclassified information), and ultimately under the purview of the FSO (or CISO, etc.).
Part 2: The Domain
Many of the standards protecting information in the NISPOM are also reflected in the CMMC framework. For instance, most, if not all, of the CMMC domains are covered in detail by the NISPOM (or an ancillary document to the NISPOM). One such domain is Physical Protection (PE), which applies across levels 1, 2 and 3 of the CMMC framework. There are several areas in the NISPOM that cover the same process for the classified counterparts to this CMMC domain.
The CMMC Physical Protection domain states: “Physical Protection activities ensure that physical access to CUI asset containers is strictly controlled, managed, and monitored in accordance with CUI protection requirements.” Physical Protection is one of CMMC’s 17 domains, having 4 practices at level 1, with 1 additional practice for both levels 2 and 3, totaling 6 practices at its highest level, 3. This domain pertains to the physical protection of CUI and the systems that hold CUI.
In a nutshell, the practices in each level are:
Level 1
PE.1.131 Limited Physical Access: “Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals”. This also means locking away sensitive equipment as necessary, and limiting access, even with the building to authorized personnel who have been explicitly granted to privilege to access the information that they have been given access to.
PE.1.132 Escorts visitors and monitor visitor activity: Visitors are considered those without explicit authority to access the building and/or area. This primarily entails escorting and monitoring visitors at all reasonable points while at your facility or in a sensitive area. This includes those you know well, those you may be mere acquaintances with and those whom you have just met. Furthermore, depending on the circumstances, visitor badges may be appropriate in order to give direct notice to others around that the person is not authorized to wonder unescorted or to enter restricted areas that they are not privy to. Many sets of eyes are almost certainly better than just one set of eyes escorting the visitor around.
PE.1.133 Maintain audit logs of physical access: This will allow the security team to monitor both authorized and unauthorized individuals accessing the property. This can be done through a physical sign in log, access badges, etc. or a culmination of some or all these things.
PE.1.34 Control and manage physical access devices: This provides physical barriers to accessing the property that only authorized individuals would have a “key” to. This could include physical locks and keys, keypad entry, access badges, key cards, etc. This provides reasonable limits the physical access to the premises to only those authorized to be there and then those they then allow (and escort) in.
Level 2
PE.2.135 Protect and monitor the physical facility and support infrastructure for organizational systems: This goes a step further than escorting and, used in tandem with escorting, can go a long way in protecting sensitive assets. This can include an internal security camera system, security system sensors, physical guards. All these things can enhance the security of the office beyond the basic protections provided for in level one. Furthermore, with the additional layer of security will come additional responsibilities and security concerns, such as the internal network of sensors and cameras, their cabling, etc. Those should be secured as best as possible to in order to ensure they cannot be tampered with and then compromised, giving a false sense of security of manipulated.
Level 3
PE.3.136 Enforce safeguarding measures for CUI at alternate work sites: This is extremely important, especially in this day and age of telecommuting, etc. This simply means taking the same reasonable precautions offsite that are taken onsite. Sensitive information should be locked up and protected, regardless of where it is. Computers should be VPN into the organizations internal secure network. This also includes locking your computer when not using it, encrypting sensitive information, avoiding public networks, etc.
Though these practices are somewhat self-explanatory and make for good common sense, there is a deeper level of consistency in these practices. Not only do most of them relate back to the RMF (through NIST SP 800-53, etc.) and NIST SP 800-171 as prescribed by DFARS 252.204-7012, but there is a clear consistency with the NISPOM as well. For example, several of the NISPOM sections correlate to these processes: NISPOM 5-306. Closed Areas; NISPOM 5-103. Perimeter Controls; NISPOM 5-313. Automated Access Control Systems; 5-314. Electronic, Mechanical, or Electromechanical Devices; NISPOM 5-901. CSA Approval; NISPOM 6-101. Classified Visits; NISPOM 8.2. Assessment and Authorization; NISPOM 8-302. Operational Controls; and so on.
In summary, now that CMMC has hit the scene, industry has been provided the final piece to the puzzle. Although at first this all might seem a bit confusing, especially when reading the details of the frameworks, once things are abstracted taking a macro-view of circumstances and how all the pieces work together, having many similarities and interrelated connections, one begins to see a well-orchestrated machine. First, we can see how FISMA, in requiring universal standards for securing federal information systems, manifested itself and came to full fruition in NIST SP 800-137 and its ancillary documents. On the other hand, industry, holding much of the same information on its systems, had a structure in place through the NISPOM to protect classified information, but was missing a formal system to protect other sensitive data. That need was initially met with NIST SP 800-171 followed by the CMMC framework. Now the CMMC framework, coupled with the NISPOM, reflect the same overall protection of sensitive information for industry that the RMF process does for both classified and unclassified but sensitive information for federal agencies.
Among all of these frameworks and processes there is a significant amount of similarities, including the physical protection of sensitive assets, which is reflected in CMMC for CUI held by industry, the NISPOM for classified information held by industry, and in the RMF for both CUI and classified information held by federal agencies.
One such domain is Physical Protection. All 3 frameworks speak similarly to the topic, but also from the perspective of the information they are endeavoring to protect. Physical Protection, though not the most glamorous of the domains and fairly self-explanatory, is one that ought to be considered paramount as a first line of defense, whether implementing physical protection of human resources or securing and protecting equipment at level 1 of the OSI model (Physical) and/or level 1 of the TCP/IP Model (Network Interface) as well.
