Hyperactive Imagination: Introduction
What comes to mind when you think about data at rest being protected? Do you think about three-dimensional ones and zeros with arms and legs sleeping on prison cots (i.e., resting… get it?) in a massive data center with a bunch of well-furnished security guards standing at the entrances and exits? Me neither. Only someone with an incredibly hyperactive imagination would think about something like that. Trust me, it can be crippling.
We normally think about data on hard drives, solid-state drives, and removable media like USB sticks and CDs being encrypted. Most people automatically default to “encryption”, wouldn’t they? I know I would, and, in many cases, still do. But, when it comes to implementing Data at Rest requirements in a Governance, Risk, and Compliance (GRC) program, whether mandated as part of the NIST SP 800-171 requirements and the Cybersecurity Maturity Model Certification (CMMC) program or as part of an organization’s internal efforts to ensure that their own proprietary data stays confidential, encryption may not be the best or only solution.
In today’s blog, I want to take a helpful dive into NIST SP 800-171’s 3.13.16 requirement. We’ll briefly explain what it means, the risk this requirement addresses, and the different ways it may be implemented successfully and practically in the types of business systems commonly required to implement it.
Protecting the 1’s and 0’s
First, let’s break down what this requirement means. This may seem basic, but I often think it’s helpful to go back to the basics because, sometimes, you glean some principles or concepts that you might not have considered before. So, what does 3.13.16 really mean? Let’s look at the language of the requirement first: 3.13.16’s control requirement is short, sweet, and to the point. It says, “Protect the confidentiality of CUI at rest.” Now, for those of you who are familiar with how assessments of this control are performed, you should immediately be thinking about the Assessment Objectives (AO) because that’s where we get the nuance for a seemingly simple control. You might think to yourself, “Ok, so I’m probably going to have to define or specify something like the type of protection method that will then, in another objective, be enforced.” And, for most requirements, you’d be right! However, for this one, we don’t get that. We get a single, simple restatement of the overarching requirement: “Determine if: [a] the confidentiality of CUI at rest is protected.” Very in-depth and insightful assessment guidance for sure. Ok, I’ll keep the sass for another time.
While I do wish it were a tad more explicit for the sake of guidance (which other requirements AO’s do a great job at), I can appreciate what seems to be the intent here. If I had to guess a good faith reason why we don’t have an objective for ensuring methods or mechanisms for protecting the confidentiality of CUI at rest are defined, or for enforcing defined mechanisms or methods for the protection of CUI at rest, it would be because those responsible for the development of NIST SP 800-171 and NIST SP 800-171A understood the risk to the confidentiality of CUI at rest can be mitigated in a variety of ways. A single organization may have several very different situations where CUI at rest would occur and need to be protected uniquely (i.e., encryption, especially FIPS-validated encryption, might not be the best approach).
And just in case there was any confusion or lack of clarity, “CUI at rest” refers to data stored on a system that is not actively being processed by an application (in use) and not currently being transmitted between systems (in transit).
The Risk 3.13.16 Addresses
There is a memorable quote in Marvel’s Avengers: Endgame where Thanos says, “You couldn’t live with your own failure. Where did that bring you? Back to me.” Every time I explain basic elements of CMMC, GRC, or cybersecurity, I think about a quote with the “me” being risk management. This conversation is no different. Every requirement in a security control framework exists to manage risk in one way or another. I know we wish we could eliminate risk entirely, but it is an inevitable part of the equation. That being said, what is the risk that 3.13.16 is intended to manage? Well, it’s obvious, but we should take some time to lay it out because, in my opinion, it is never proper to try to implement a requirement without understanding the risk it presents. It’s just too important a detail to be missed.
The primary risk that 3.13.16 exists to mitigate is the risk of people or groups gaining unauthorized access to and knowledge of sensitive information (CUI) residing at rest on the system. It’s straightforward but worth noting. It’s important to remember that NIST SP 800-171 exists to mitigate risks to the confidentiality of CUI, rather than to focus on the integrity and availability of such data. This is why it doesn’t include specific requirements for backing up CUI (availability/integrity); only that, if you do perform backups, you ensure the confidentiality of the backups is protected (3.8.9), which is essentially an extension of this requirement. So, if the confidentiality of CUI being compromised (i.e., someone seeing it who isn’t authorized to see it) is the risk being prioritized, then we can probably agree that the implementation of this requirement might vary quite a bit.
How to Protect CUI at Rest
Most of the Time: Encryption
Ok, so let’s talk about that! What does a good implementation of this requirement look like? Welp, that’s another big, fat “It depends.” It depends on how the organization stores CUI when it resides on its system, where it stores it, and what capabilities and desires the organization has regarding implementing this requirement. As I said before, most of the time, cryptography is the best approach for CUI at rest residing on an information system. CUI on a file server, storage array, end user workstation, or removable media are all common mediums that are used for CUI storage (i.e., at rest). And, for each of these mediums, cryptographic mechanisms are generally available to protect the data residing therein. For workstations, BitLocker Full Disk Encryption and Used Space Encryption are options you can enforce via Active Directory Group Policy and Microsoft’s MDM solution, Intune. Many storage arrays have local encryption modules that can be configured to encrypt residual data; many do so by default. Third-party security tools like Threat Locker or Manage Engine’s Device Control Plus can be installed on systems to block unauthorized or unencrypted USB drives, ensuring that only authorized and encrypted removable media can be used to store sensitive data when such a medium is necessary. There is an assortment of approaches available.
Of course, you need to be mindful of the encryption method used. 3.13.11 comes into play whenever you utilize encryption to protect the confidentiality of CUI. This requirement mandates that FIPS-validated cryptography must be utilized for all such cryptography. Therefore, it’s really important to vet your systems and ensure that, if cryptography is what the organization is intending to be the means of protecting the confidentiality of CUI, the cryptographic modules that perform the cryptographic functions and apply the cryptographic algorithms to the plaintext CUI must be independently certified through the validation process known as the NIST Cryptographic Module Validation Program (CMVP). It’s easy to get tripped up here because many security tools advertise “FIPS compliance” without actually using FIPS-validated cryptographic modules. They often utilize FIPS-Validated algorithms, but the modules themselves have not been validated to meet the current FIPS 140-3 standards via the CMVP and therefore don’t meet the requirements from NIST SP 800-171 and CMMC.
But Not Always: Alternative Methods for Protection of CUI at Rest
Though FIPS-validated encryption is a common way to protect data at rest, we also need to acknowledge that risks to the confidentiality of CUI at rest can be mitigated in ways other than encryption. Remember, nothing in this requirement and its assessment objective mention anything about encryption specifically. This is incredibly important when organizations use system components that might not support FIPS-validated cryptography, or when implementing cryptography would cause significant functional issues in the system’s operation. So, what are some ways that 3.13.16 can be implemented in an effective way without the use of FIPS-validated cryptography? I’m glad you asked! Let’s take a quick peek at the CMMC Assessment Guide for Level 2 which contains some helpful guidance on the matter. In the Further Discussion section under the SC.L2-3.13.16, the second paragraph states this:
Implementing encryption for CUI is one approach to this requirement, but it is not mandatory. Physical security is often employed to restrict access to CUI, particularly when it resides on servers within a company’s offices. Other approaches for protecting CUI include system-related protections such as configurations and rule sets for firewalls, gateways, intrusion detection/prevention systems, filtering routers, and authenticator content that eliminate attempts at exfiltration. You may also employ other security requirements, including secure off-line storage.
Now, whenever we talk about the CMMC Assessment guidance, we must keep in mind that these “Discussion” sections are neither binding nor requirements themselves. They simply exist to assist the reader in understanding the requirements but are limited in their ability to extrapolate in every nuanced way that a particular requirement and its assessment objectives could be applied in different, unique environments. At the very least, guidance exists for a reason and provides insight into the minds of those responsible for enforcing the CMMC program at the DoD. If they weren’t on board with the language in the guidance, we could assume they wouldn’t have kept it in the official guidance document for CMMC assessment performance. So then, the question we should be asking is: what principles and perspectives can we glean from this guidance? Primarily, it’s what we’ve already stated – that encryption, though the primary and often means of protecting the confidentiality of CUI at rest, is not the sole, mandatory means of doing so. One of the most common alternative methods that we see organizations utilize is physical security controls. Things like locked doors with RFID badge access restrictions, security cameras, guards, etc. that are integrated with robust Role-based Access procedures and controls are common ways that you might implement 3.13.16 without relying on encryption. Most companies that have a server room or server closet already have the capability to do this and to ensure that only authorized individuals can physically access the system media (i.e., HDDs and SSDs in data center equipment) containing CUI. For removable media/portable storage devices, you might have an accountability checklist and locked storage containers for any such media used for CUI storage. Locked file cabinets are great for this. For workstations, again, encryption is most common, but in the rare case where it’s not appropriate or feasible, you may have prohibitions for the use of such devices out of physically controlled spaces (i.e., prohibiting telework where CUI would be involved) established in your security policies and Acceptable Use Policy, and enforce such policies with training and threats of sanctions. You might also use things like DLP, network VLANs, Access Control Lists, and other technical mechanisms to restrict the ability for CUI to be transmitted to places that are not being protected by either encryption or the corporate physical security controls mentioned above. We could go on and on with the potential ways that non-cryptographic approaches could be utilized.
Final Thoughts on Implementing 3.13.16
At the end of the day, if the chosen implementation ensures that people not authorized to access and handle CUI are prevented from doing so, then the intent of 3.13.16 is satisfied. So, before you go replace your storage array or other expensive equipment because your current outfit doesn’t support FIPS-validated cryptography, take a step back and ask yourself, “Is there another way?” because there very well could be.
If you and your organization are trying to think through the dilemma related to encryption and FIPS-validation, and so forth, we’d love to help you make informed decisions or pair you up with a partner of ours that can even give you the hands-on support needed to get 3.13.16 checked off your list of compliance to-dos! We, at IntelliGRC, are constantly in the trenches advising and supporting organizations with CMMC obligations, and we get these questions a lot! Whether you’re an OSC trying to figure out where to go from here or you’re an MSP learning and growing in this industry, we’ve got something in our back pocket to support your needs. If you’d like to learn more, feel free to fill out our contact form found here or send an email to sales@intelligrc.com
I hope you enjoyed this one and that this blog was helpful on your journey towards CMMC compliance. As always, happy implementing!
Key Takeaways
- NIST SP 800-171 control 3.13.16 requires organizations to protect the confidentiality of CUI at rest.
- Encryption is the most common, and it needs to be FIPS-validated when used.
- However, encryption is not the only valid implementation method.
- Physical security, access control, and network protection can also mitigate risk.
- Organizations should implement controls that effectively prevent unauthorized access to stored CUI.