FullScope IT

NIST 800-171 compliance typically means that an organization has made an effort to comply with the NIST SP 800-171 controls, which focus on the protection of controlled unclassified information in non-federal systems. Meaning, protecting government sensitive data out in the commercial space, beyond the reach of federal information system protections. There are 110 controls in the current version of NIST SP 800-171, in 14 different areas, such as access control, incident response, or personnel security. Each area has a number of basic and derived security requirements. If someone says that their organization is NIST 800-171 compliant they could mean several things: Their organization currently has a system security plan (SSP) in place and at a bare minimum a plan of action and milestones (POAM) to comply with the remaining 109 controls at some point in the future Their organization currently complies with a number of the 110 controls and has a POAM for the remaining controls they have not implemented yet, which may be proving especially time or resource consuming Their organization has completed all 110 requirements from within the NIST SP 800-171, and considers themselves “fully compliant” Up until the end of 2018, we saw a number of federal contractors who considered the first option to be their most cost-effective route. However, as government agencies begin to consider SSPs and POAMs in their pre and post-award processes, this has been rapidly changing in the small business world of federal contracting. Primes have also stepped up their enforcement and supply chain investigations – we are no longer seeing a single page checkbox form confirming NIST 800-171 compliance, but instead detailed questionnaires, requests for full SSPs, and in-depth review of POAMs. One other important note about NIST 800-171 – you don’t see some of the traditional compliance exceptions like you do in other frameworks for things like excessive costs, or difficulty of implementation. You must comply - unless you have a written exception from the CIO of the agency that would be contracting with your firm. If you don’t, it needs to be in a POAM, and the agency can (and most likely will) consider the holes in your protection of their controlled information during contract award.

You don’t if you are talking about NIST 800-171. There is no NIST 800-171 certification currently. Anyone who is trying to sell it to you should be given a wide berth. Some other NIST standards may have related certifications or validations, such as NIST 800-53 and FedRAMP authorization, but as a federal contractor, you should not be worrying about being certified for NIST. NIST 800-171 is at the moment self-assessed for compliance. Although there is a definite possibility that a government customer or prime on a government contract may want to somehow verify you are complying with requirements around the security of controlled unclassified information they may need to send to you, such as asking to view your system security plan (SSP) and plan of action and milestones (POAM).

NIST stands for the National Institute of Standards and Technology. NIST is a part of the US Department of Commerce and is responsible for creating many of the federal information technology standards. NIST releases excellent reference materials for almost anything related to information technology, among many other things.

A few Android phones are FIPS validated, and iPhones typically are validated within a time period, but often iOS is a version behind on its FIPS validation. If you have a BYOD (bring your own device) setup for mobiles that might contain CUI you should be especially concerned, as you may have no idea what devices your users are utilizing or if they are FIPS validated. Neither Outlook Mobile or Intune are FIPS validated as of the date of this post. On laptops, if you are using BitLocker encryption, are your systems in FIPS mode? BitLocker is FIPS validated, but it must be in FIPS mode.

FIPS validated means that a product has submitted its cryptographic modules to the government, typically via an approved certifying authority, like a lab, to make sure the product is properly engineered and working as expected. From the perspective of federal government compliance, if encryption isn’t FIPS validated, it may as well be plaintext. In practical application, this is not correct, but from a government compliance perspective, it is. The entire process of getting a cryptographic module is time-consuming and involved, and most vendors don’t want to go through it unless they are targeting a federal demographic. There is only one way to check if a vendor’s product is FIPS validated – through the validation system the government has set up. The sales team of your favorite vendor will love to tell you they are FIPS compliant, which normally means they are using approved cryptographic modules, like AES, but in most cases, they aren’t actually FIPS validated. After you grab the certificate for your chosen product you can add it to your evidence documentation for your System Security Plan (SSP). But that’s a whole different blog post. To tie all of this back together, one super common thing that we’ve seen contractors overlook is FIPS validation for encryption on their mobile devices.

This question is often the most pressing – The government doesn’t support or endorse any one vendor and leaves the choice up to the contractor to decide – with one restriction. Data encryption that is used to protect CUI needs to be FIPS validated.

Within the boundaries of your 800-171 compliant information system you don’t have to encrypt data as it moves, but as soon as it is moving across untrusted and insecure networks, like the internet, you need to encrypt the data. Most secure websites, government websites, banking websites, and gradually even the regular internet are now enforcing this type of encryption so that your sensitive data can’t be sniffed across the internet. The relevant control for DIT encryption would primarily be 3.13.8, “Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.”

Data in transit encryption is encryption for data on the move. This prevents unauthorized access of sensitive information while it moves across a network or the internet. This prevents “snooping” of your sensitive material. When you sign on to a website, like your bank, it uses DIT encryption to make sure your transaction stays secure off the untrusted public internet.

In terms of if data at rest encryption is needed under NIST SP 800-171, the answer is, in certain cases. DAR encryption is required for all mobile devices (laptops, tablets, mobile phones) that store CUI. NIST SP 800-171 compliance does not require DAR encryption for desktops or servers. From the perspective of 800-171, desktops and servers are within the secure boundary of your facility, which will have other controls and protections in place. The primary control that is relevant for this is 3.1.19, “Encrypt CUI on mobile devices.” Be advised, you may be required to utilize DAR encryption for your servers or desktops under other requirements, like a specific federal contract requirement, or another compliance requirement. DAR encryption is cheap and easy insurance to prevent data loss if a device is lost or stolen.

Data at rest encryption is encryption for data while it is sitting on the device that stores it. When you unlock your mobile phone after a power off and have to type a PIN in, you are probably using DAR encryption on that device. If someone didn’t have the PIN, and the phone was off and not logged in, the data would not be accessible.

Encryption, for the purpose of NIST SP 800-171, means using hardware or software to cryptographically protect information, so that only the intended recipients can access it. When a file or data or a hard drive is encrypted, if an unauthorized person had that information, and didn’t also have the key, or password, they could not read the information. There are two main types of encryption that are of concern under 800-171, data at rest, and data in transit encryption.