I’m working with a couple of organizations faced with NIST 800-171 compliance. The first is a small manufacturing company doing business with a prime contractor. The second is a tribal business unit with federal contracts. Both must be compliant by December 2017 or risk losing their federal business.
From what I can tell, neither organization was provided much guidance beyond the request to be compliant in the given timeframe – they’re on their own to figure it out. Tough task.
What is CUI?
If you’re not familiar, “Controlled Unclassified Information” (CUI) supports federal missions and business functions that affect the economic and national security interests of the United States. Non-federal organizations (e.g. colleges, universities, state, local and tribal governments, federal contractors) often process, store, or transmit CUI.
Executive Order 13556 (11/10/2010) designated the National Archives and Records Administration (NARA) as the Executive Agent to implement the CUI program. NIST Special Publication 800-171 defines the security requirements for protecting CUI in non-federal information systems and organizations. The final draft was made public in April 2015.
There are 14 families of security requirements associated with the standard:
- Access Control
- Audit and Accountability
- Awareness and Training
- Configuration Management
- Identification and Authentication
- Incident Response
- Media Protection
- Physical Protection
- Personnel Security
- Risk Assessment
- Security Assessment
- System and Communications Protection
- System and Information Integrity
Diving deeper… let’s look at an example for Configuration Management from Chapter 3, Requirement 4 in NIST 800-171.
Basic Security Requirements (from FIPS Publication 200):
3.4.1 Establish and maintain baseline configurations and inventories of organizational information systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
3.4.2 Establish and enforce security configuration settings for information technology products employed in organizational information systems.
Derived Security Requirements (from NIST Special Publication 800-53):
3.4.3 Track, review, approve/disapprove, and audit changes to information systems.
3.4.4 Analyze the security impact of changes prior to implementation.
3.4.5 Define, document, approve, and enforce physical and logical access restrictions associated with changes to the information system.
3.4.6 Employ the principle of least functionality by configuring the information system to provide only essential capabilities.
3.4.7 Restrict, disable, and prevent the use of nonessential programs, functions, ports, protocols, and services.
3.4.8 Apply deny-by-exception (blacklist) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
3.4.9 Control and monitor user-installed software.
With that background, consider that many of the organizations faced with this requirement are in a bit of a quandary, considering the reality of never having had to protect CUI at this level before. They don’t want to lose these important customers but at the same time, they don’t have the people or experience or technology to solve it.
They have to step up their game or lose the business to a competitor… not necessarily one with a better product or price but one that can demonstrate compliance with the standard.
I did some research and found a few helpful documents to assist with the creation of a security plan and ensuring data is protected at the right level:
- NIST SP 800-171 – This is the standard from NIST
- FIPS 199 – Security categorization standards for information (part of the required deliverables in the security plan)
- IT Security Plan Template from NIH – A template for building out your system security plan. Just read the blue portion and replace it with your plan (now offline)
- FIPS Publication 200 – For the “basic” security requirements
- NIST SP 800-53 – For the “derived” security requirements
The NIH template is very helpful, as it points out that security controls already in place for SOX or HIPAA may satisfy many of the requirements of 800-171. The template provides detailed instructions to describe the “in scope” system and components. It also provides a fillable table with the 14 families of security controls, including both the basic and derived requirements.
There are many tools available from vendors to help manage the controls required by NIST 800-171. Imprimis i2ACT-800 includes all security controls contained in NIST SP 800-53 and fully supports cyber requirements specified in the Defense Federal Acquisition Regulations Supplements and the Federal Information Processing Standards (FIPS). It also supports the Risk Management Framework (RMF) now being adopted by the Department of Defense as a replacement for the Department of Defense Information Assurance Certification and Accreditation Process (DIACAP).
NIST allows contractors to adequately protect CUI “using the systems and practices they already have in place, rather than trying to use government-specific approaches.” The burden is on the contractor to ensure that it meets its legal and contractual obligations to the government for handling CUI.
Given that many contractors will have a strong security plan, supplementing the plan with tools designed for a specific purpose may also be beneficial. Tripwire’s compliance products (Tripwire Enterprise and CCM) are good examples of tools designed to test controls for compliance and provide remediation on how to fix failed tests. These tools can provide support for the security plan.
While this is a time-consuming project and may involve an investment in enhanced security, the benefits of safeguarding CUI are many … including continuing to do business with an important customer.
Feel free to leave any questions or comments below, or you can find out more information from us here.
For more information on meeting federal NIST 800-171 requirements, click here.