I often hear feedback from clients that National Institute of Standards and Technology (NIST) frameworks are too cumbersome and frustrating to implement, with a steep learning curve to understand all the requirements. I can empathize with them, coming from a public accounting and internal audit background, adjusting to viewing risk through a NIST lens almost felt like learning a new language. Now frequently performing assessments against frameworks developed by NIST (e.g. SP 800-53, SP 800-30, Cybersecurity Framework) things are much easier to pick up and each new framework or revision feels more like a new dialect than an entirely new language. With that said one of the newer “dialects”, NIST 800-171, should provide relief to some of those previously frustrated in their compliance attempts.
Background:
What is NIST 800-171? Well it’s NIST’s guidance for “Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations”. I challenge you to say that 5 times fast…
While it is a mouthful, if we break it down the purpose is actually straightforward in the title:
- “Controlled unclassified information”,
- In non-federal systems and organizations (e.g. 3rd party contractors)
- Needs to be protected.
NIST 800-171 was originally published in June 2015 (latest rev 1 in 6/7/2018) and serves as the base set of security requirements for 3rd parties to protect CUI. Now one would assume that since there are several publications (e.g. NIST 800-53) already available that cover the confidentiality, integrity, and availability of information in federal information systems, why can’t we just leverage that? Well the answer is we largely can, however everyone knows there are costs associated with implementing or assessing any security framework, and because the information is in non-federal systems it can feel like a much bigger ask to expect 3rd parties and contractors to make the investment apply all of the same security controls, in particular when some of the risks that NIST 800-53 addresses may not be relevant to their environment.
At the end of the day controls cost money, and one of the most important things to keep in mind when applying controls is ensuring that they address the most relevant risks.
This is one of the major reasons (and differences) between the requirements under 800-171 and other federal requirements (FIPS 200, NIST SP 800-53, NIST SP 800-60, etc.). The relevant risks that the controls in the framework are not the same! In the case of 800-171, the guidance from NIST is that the most relevant risks are those to confidentiality, to a lesser extent integrity, with almost no focus on availability.
Now that we’ve covered the background, let’s take a quick look at the security requirements and controls that are considered relevant under NIST 800-53.
NIST 800-171 Security Requirements:
Types:
- Basic - based on FIPS publication 200
- Derived - based on NIST 800-53
Security Requirement Families:
3.1 Access Control
3.2 Awareness and Training
3.3 Audit and Accountability
3.4 Configuration Management
3.5 Identification and Authentication
3.6 Incident Response
3.7 Maintenance
3.8 Media Protection
3.9 Personnel Security
3.10 Physical Protection
3.11 Risk Assessment
3.12 Security Assessment
3.13 System and Communications Protection
3.14 System and Information Integrity
For anyone who has worked with NIST 800-53 controls, I’m sure these are starting to look pretty familiar? They are largely the same controls!
While NIST 800-171 includes all of the confidentiality controls found in 800-53 it also has some important FISMA related requirements. The primary being development of a System Security Plan (SSP) and Plan of actions and Milestones (POAM).
System Security Plan - Nonfederal organizations should describe the following in a system security plan:
- How the specified security requirements are met or how organizations plan to meet the requirements.
- The plan describes the system boundary.
- The operational environment.
- How the security requirements are implemented
- The relationships with or connections to other systems.
Plan of Action and Milestones (POA&M) - Nonfederal organizations should develop plans of action that describe how any unimplemented security requirements will be met and how any planned mitigation will be implemented. Organizations can document the system security plan and plan of action as separate or combined documents and in any chosen format.
For organizations that are familiar with other NIST frameworks these should be very familiar, for others they may not be. If you’re organization stores, processes, or transmits any CUI, one of your first steps should be to review NIST 800-171 and begin developing a system security plan. Although there is no required format, NIST provides a template on the special publication 800-171 page:
https://csrc.nist.gov/publications/detail/sp/800-171/rev-1/final
Not only will this also will serve as a natural first step to identify where you may not be compliant and help inform where relevant security controls may need to be implemented, after-all no can be expect to be perfect on the first try. Any gaps that surface as part of documenting the security plan can serve as an initial Plan of Actions and Milestones (POAM) and addressed over time.
Still confused? No sure where to start? Or just concerned with effectiveness of your controls/compliance? If your firm contracts with the Federal Government and processes CUI, NuHarbor can help!
