Meeting the requirements of CMMC takes time, effort, and coordination from test, security, and IT teams. Success depends on understanding the CMMC requirements and how these apply to operational technology like test systems.
CMMC is based on NIST 800-171 rev. 2, which contains 110 controls organized into 14 families. There are many resources online to get lists of these controls, including the NIST site, where you can download a text document describing the requirements, or a spreadsheet listing the requirements, or NIST 800-171A which includes directions to assessors for how to evaluate each control. We'll leave an analysis of NIST 800-171 controls to other security sites.
Of interest here is how these controls apply to test systems. Test systems differ from IT systems for several reasons:
With these differences in mind, let's review some of the topics in NIST 800-171.
The first 22 controls in NIST 800-171 relate to restricting who has access to the test system. The system need to restrict access to authorized users and restrict automated processes (devices) that have access to the system. A test engineer needs to identify all of potential users of the system and their roles. In this analysis, keep in mind that some users may be remote processes like databases that move data from the test system to a central database.
For each of the users identified, the system architect needs to create a strategy for authentication. Will you use the standard Windows login to control who has access to the system? What access rights will operators have, and how is that different from administrators? How will remote processes authenticate to the system?
Test teams need to consider physical access as well, and how that changes the system. As ethernet is an important bus in today's test systems, it is possible for someone to connect to a device by moving the cable. How will you ensure that data cannot be taken from the device through a direct connection? If you can't control this, can you physically protect the cables?
NIST 800-171 focuses on providing the right level of access for each operation, so a test architect should consider how to apply this principle of least-privilege access. In systems where the operator isn't logged in individually (for example, a lab where several people are working together on the tester), the access privileges need to be locked down very tightly. When something requires higher privileges, like installing a software update, the system should require an individual admin to log in to perform the action.
Several of the access control requirements can be met with standard IT identity management tools. If the test system is Windows based, test teams can work with their IT group to leverage corporate identity tools. If the system is disconnected, or uses devices not supported by IT systems, test architects need to consider how they will meet basic requirements such as password complexity and limited logon attempts.
Requirements in this family focus on making sure that operators and administrators are properly trained in cybersecurity principles specific to their roles. Test teams may be able to relay on training provided by their IT teams. If test systems require specific actions or protocols, training may need to be developed to comply with these requirements.
A central principle in NIST 800-171 is the ability to know who performed specific actions. This is useful to detect malicious actions, and in the event of an incident this is helpful to identify damage done and perform root cause analysis. To enable this, test systems must be designed to log specific actions.
To be effective, audit logs must capture privileged actions- those actions that change access or configurations. Audit logs create a record of any actions on the system - who is logged in, what data is moved, what objects in the system are changed. To be accurate, the audit system must have a reliable clock for the timestamps. And to be reliable, audit logs must be protected from change or deletion.
As part of the test system design, test architects need to design a plan for creating, updating, and protecting these audit logs.
Deploying a secure test system often requires the test team to apply configuration settings that put the system and components into a more secure state. NIST 800-171 requires that the team capture a snapshot of this configuration as a baseline so that the system can be quickly reset to that configuration.
Secure Technology Implementation Guides (STIGs) provide a way for system administrators to ensure that system remain in the most secure configurations. Vendors work with the Defense Information Systems Agency (DISA) to create STIGs, which include instructions to check and adjust configurations for their products. Once approved, STIGs are available at the DoD STIG database. Where possible, gather STIGs for the software components of a test system.
Managing identities and accounts is another important part of NIST 800-171. This requires that systems authenticate users and other systems before providing access. Similar to access management, test teams can rely on IT tools for authentication to standard PC technologies in the system.
Test architects need to look for ways to authenticate components in the system. Ethernet components, databases, and networked computers all need to authenticate before connecting to the test data system.
When defenses fail and a system is attacked, an organization needs to respond quickly. This family of controls requires that teams plan for these failures, including tracking incidents, testing the system, and establishing a way to report incidents to the appropriate authorities.
Test systems require regular maintenance, including calibration. NIST 800-171 requires that teams plan to prevent lapses in protection during maintenance sessions.
Hardware must be cleared of any sensitive data prior to being sent for repair or calibration. Vendors should provide letters of volatility with instructions to properly clear the memory locations of these devices, and test teams should establish processes to protect data as part of maintenance processes.
When sensitive data is stored on media devices, those devices must be protected logically and physically. Data on devices must be encrypted. Devices must be protected against theft, and systems must prevent access from unknown devices like USB drives.
A test architect must consider where data will be stored, and how to protect the data in those locations. IT tools may be helpful for these locations - Windows Bitlocker can encrypt data on most server PCs. For other devices, the test program may need to encrypt data prior to data logging, or control which devices are permitted to connect.
Ensuring that only certain people have access to the test system and the data requires establishing processes that screen individuals and control access when roles change. Test teams need to consider how to implement processes within existing company policies to manage who has access to the systems.
System security is sometimes bypassed through physical actions - changing connections, removing drives, or adjusting physical parameters of the system. When planning a test system, the test team must consider ways to secure the system physically. This may require controlling access to the room, or locking down certain components of the system.
No security plan is perfect, and attackers continuously adjust their strategies. To maintain system security, test teams must periodically assess their rick profile and make adjustments as necessary. Vulnerability testing is used by security teams to expose weaknesses. Test teams must plan a security testing strategy that will expose weaknesses in the system. Larger companies may have a security team that can design a test, or test teams may hire an external consultant to design a security test.
Security assessments provide a team a way to review the effectiveness of the security controls in place, and to look for ways to improve. Security teams need to meet periodically to review and update the security system.
NIST 800-171 is most effective when the system is clearly defined and controls are applied within that system definition. Along with the system components, the definition needs to include connections to external systems. This set of requirements requires that those connections are secured and protected. This protection must ensure that data is not communicated outside of the secured system. When data is intentionally communicated, it must be encrypted to prevent eavesdropping on the data.
This family of NIST 800-171 controls includes additional requirements to identify system flaws and update those flows. This includes keeping malicious code protections up to date. Test teams need to create a plan to review and update systems, with minimal disruptions to the test system.
This article provides an overview of how NIST 800-171 control families apply to test systems. Test teams should review these requirements as part of a plan for deploying test systems.
See how NI provides resources to help your team meet these requirements.