NIST 800-171 has become the formal security benchmark for covered defense information (CDI), including controlled unclassified information (CUI) and controlled technical information (CTI). By December 2017, nonfederal organizations who process, store, or transmit CDI, CUI, or CTI must demonstrate compliance to this standard.
SecureState CEO Ken Stasiak and Management Consultant Matt Franko recently hosted a webinar Reviewing NIST 800-171 Requirements and what contractors need to know before the compliance deadline. Here are some of our attendee’s questions and answers:
Q: One of the requirements is that access to CUI is restricted to US citizens on US soil. We can place the proper Identity and Access Management controls to meet that requirement; however, if enterprise administrators with domain admin rights are not US citizens and/or reside outside of the US, how is that being addressed by other organizations? Is it necessary to stand up separate servers, migrate the data and strictly limit access and system maintenance?
A: CTI is governed until ITAR requirements. As we understand it, CUI is not restricted to U.S. Citizens if the appropriate controls are implemented.
Q: If a project requires NIST 800-171 compliance, and the group needs to use a data acquisition computer/machine, is the raw data produced by that data acquisition computer CUI simply because it was performed in the effort to fulfill the work described in the contract for project? Or, does that data only become CUI after it's been used in context to the contract/project work?
A: If the acquisition computer is being used to collect CUI or if its connected to a system that stores, processes, or transmits CUI, we interpret that it would be in scope for NIST 800-171 if the contract requires.
Q: Will this apply if you are already NIST 800-53 Mod Compliant?
A: While it will be applicable, if the environment that you are storing, processing, transmitting, or accessing CDI is already NIST 800-53 Mod compliant, there would be no further controls necessary for that environment.
Q: If there are no specific standard requirements, is 800-171 an easier standard to start with vs 800-53, and 171 will get you on your way to 53?
A: Yes. Based on our understanding, 800-171 is primarily focused on confidentiality, so if your initial goal is to protect against disclosure of your dataset, then this provides a great first step to the full 800-53 framework.
Q: Currently we must follow NIST 800-53, as we are doing business with the Department of Education. Do we need to move it to NIST 800-171, as we did not get any guidance from Department of Education about this?
A: Our initial instinct to this question would be no. NIST 800-171 is a requirement from the DOD. However, someone we’ve worked with in the past shared this link with us that says otherwise: https://ifap.ed.gov/dpcletters/GEN1612.html. If you’re dealing with 800-53 and FISMA requirements, and you’re at least dealing with a moderate baseline, you would already be covering the controls in that environment.
Q: What could you use for dual factor authentication on closed networks with no internet access systems?
A: If local connections are present, then use a Certificate Authority (CA). There are also a couple of Active Directory (AD) solutions out there that require additional hardware.
Q: What level of compliance is expected for the Plan of Action & Milestones (POAM)? Do all remediation efforts need to be complete by 12/2017?
A: While we cannot guarantee that the agency or prime contractor (depending on your contract) will accept POAM beyond 12/31/2017, our experience is that with a proper POAM, an extension beyond the EOY should be achievable. Keep in mind, the Federal government has already extended this once to 12/31/2017, so they may extend again or start to enforce shortly thereafter.
Q: Are there any penalties for not being NIST 800-171 compliant?
A: Since this is a DFARS requirement the penalties are breach of contract damages, liquidated damages from affected individuals, termination of the contract, liability under the False Claims Act, and other potential legal actions.
Q: For the flow-down clause, how is it possible to make the subcontractor DFARS compliant especially if some of these companies are mom/pop shops and can't implement some of these technical controls (MFA, DLP, etc.). And is OTP considered a factor for MFA?
A: Remember the NIST standards are risk based, so smaller organizations should have a smaller footprint, and thus not all controls may be applicable. Can you limit the type of data provided to smaller companies, to eliminate the CUI requirements? While NIST currently permits the use of SMS, they have advised that out-of-band authentication using SMS or voice must be deprecated and may be removed from future releases of their publications. From the DRAFT NIST Special Publication 800-63B Digital Authentication Guideline: https://pages.nist.gov/800-63-3/sp800- 63b.html (accessed: November 07, 2016)
Q: If you don’t meet the deadline but can show your roadmap with target dates are you able to go past December of 2017?
A: While we cannot guarantee that the agency or prime contractor (depending on your contract) will accept POAM beyond 12/31/2017, our experience is that with a proper POAM an extension beyond the EOY should be achievable. Keep in mind, the Federal government has already extended this once to 12/31/2017, so they may extend again or start to enforce shortly thereafter.
Q: Is a System Security Plan required by 12/31/2017?
A: Short answer, Yes. Longer answer: “Nonfederal organizations (NFO) should describe 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; and the relationships with or connections to other systems. Nonfederal organizations should develop plans of action that describe how any unimplemented security requirements will be met and how any planned mitigations will be implemented. Organizations can document the system security plan and plan of action as separate or combined documents and in any chosen format.”