June 28, 2023

What's new in NIST 800-171r3?

Obviously the big additions are the three new families of controls (which will be called "domains" in the new version of the CMMC model): Planning, System and Services Acquisition, and Supply Chain Risk Management.

Planning The SSP requirement (3.12.4 in r2) was moved to this family, along with two new controls:

3.15.1 Policy and Procedures
a. Develop, document, and disseminate to organizational personnel or roles, policies and procedures needed to implement security requirements.
b. Review and update policies and procedures [Assignment: organization-defined frequency].

3.15.3 Rules of Behavior
a. Establish and provide to individuals requiring access to the system, the rules that describe their responsibilities and expected behavior for handling CUI and system usage.
b. Review and update the rules of behavior [Assignment: organization-defined frequency].

So, those pesky documentation requirements in CMMC v. 1.0, that were taken out of v2.0, are back. Of course, they were always in 800-171r as NFO Controls in Appendix E, so this isn't really new, except most people didn't pay attention to Appendix E.

Remember, a policy is a high-level statement of intent, signed by someone in authority, that describes generally what you are trying to accomplish. A procedure, by contrast, is basically the instructions for accomplishing the goals stated in a policy.

System and Services Acquisition The first control, 3.16.1 Security Engineering Principles, is basically a revision of 3.13.2 from r2, while 3.16.2 Unsupported System Components is an explicit statement of requirements that were inferred in r2:

a. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or
b. Provide options for alternative sources for continued support for unsupported components.

I find 3.16.3.External System Services to be very interesting:

a. Require the providers of external system services to comply with organizational security requirements, and implement the following controls: [Assignment: organization-defined controls].
b. Define and document organizational oversight and user roles and responsibilities with regard to external system services.
c. Implement the following processes, methods, and techniques to monitor control compliance by external service providers on an ongoing basis: [Assignment: organization-defined processes, methods, and techniques].

This is not talking about storing or processing CUI in the cloud, rather it is addressing the risk to your CUI information system from external service providers. For example, the MSP who has remote access to your information system, or cloud-based security protection tools.

Supply Chain Risk Management Here we have four brand-new controls, which I believe are pretty self-explantory:

3.17.1.Supply Chain Risk Management Plan
a.Develop a plan for managing supply chain risks associated with the development, manufacturing, acquisition, delivery, operations, maintenance, and disposal of the system, system components, or system services.
b.Review and update the plan [Assignment: organization-defined frequency].

3.17.2.Acquisition Strategies, Tools, and Methods
Develop and implement acquisition strategies, contract tools, and procurement methods to protect against, identify, and mitigate supply chain risks.

3.17.3.Supply Chain Controls and Processes
a. Establish a process or processes for identifying and addressing weaknesses or deficiencies in the supply chain elements and processes.
b. Employ the following controls to protect against supply chain risks to the system, system component, or system service and to limit the harm or consequences from supply chain- related events: [Assignment: organization-defined supply chain controls].

3.17.4.Component Disposal Dispose of system components, documentation, or tools containing CUI using the following techniques and methods: [Assignment: organization-defined techniques and methods].

I figure about now, you are wondering what's up with all these things that are "organization-defined"? What does that mean? It's a bit confusing because it's a carryover from 800-53 language, where the organization is the federal agency implementing the requirements. In 800-171r3, the organization is the federal agency requiring a contractor to implement the standards. So, for example, in R2 you could decide on your own how often you need to run vulnerability scans. In R3, you no longer have the authority to determine the frequency. Exactly who will determine these things? That's something we don't know yet.

What place should R3 have in your current security program? I would say that (1) you need to be aware of the changes in requirements, and (2) take them into consideration when making any changes to your system. This document is still a draft, so I wouldn't worry about implementing anything new at this point. BUT, if you are about to buy a new tool or sign up for a new service, anything like that, I would look to R3 to be sure that the new tool/service will be compliant when the time comes.

Need more help? You know where to find me!

Remember, you can read past editions of this newsletter on our website, along with tons more information under the CMMC and Resources tabs. Feel free to share this update!

Sincerely,

Glenda R. Snodgrass, CCP
grs@theneteffect.com
The Net Effect, LLC
www.theneteffect.com
251-433-0196 x107

If you enjoy these updates, you might also enjoy my weekly newsletter "Cyber Security News & Tips" -- sign up now!