There’s a Star Trek: The Next Generation episode that could never hold my attention until NIST SP 800-53 Rev 5 came along (yes, this is what content nerds do; we find symmetry between regulations and Star Trek). In the episode titled Darmok, the United Federation of Planets’ universal translator (which translates any language to Federation Standard language) fails to interpret the language of a race known as the Tamarians. The translation catastrophe is rooted in how meaning is established in the Tamarian language: their vocabulary is comprised of metaphors. All these metaphors are based entirely on Tamarian mythology and history; therefore, to understand the language and establish a translation, one has to know every myth, every historical connection, and every experience the Tamarians associated with these stories. “Shaka when the walls fell” means failure to the Tamarians, but as we read it, without context, it makes no sense.
How does translation figure in security content? Like language, regulations are not static; regulatory bodies release periodic updates, and Xacta® content moves to match these changes. Imagine a fully populated project, laden with artifacts and process steps filled to the brim with collected data. It’s on Rev 4, and Rev 5 comes along. You wouldn’t want to have to start with a clean slate. It would be great if you could reuse as much data as you can where it’s relevant. This is where Xacta is an enormous time-saver for our customers. The analysis that goes into the translation files and supporting documents that guide our customers through regulation upgrades does the heavy lifting in their transition from Rev 4 to Rev 5, leaving them to allocate valuable resources to the heaviest changes in compliance.
Translating NIST Rev 4 to NIST Rev 5
To enable this in Xacta, we write translation files. Think of it as getting your Rev 4 project to start talking Rev 5. In this translation file, we line up the old regulation elements with the new one. In a regulation upgrade, the file is loaded into Xacta, the Rev 5 regulation is then selected, and after a few clicks, your assessment project’s old regulation is overwritten with Rev 5 content, including its compliance data, workflow status, and associated artifacts intact and mapped to the relevant controls.
While the differences between Rev 4 and Rev 5 are not as problematic as translating Tamarian to Federation Standard, we’ve found that upgrades between versions are not as simple as matching control IDs. In this post, we look back at the regulations we’ve built translations from one version to the next and share with you what we’ve learned.
NIST SP 800-53 Rev 4 to Rev 5 to Rev 5.1.1
This has been the most challenging regulation change the Xacta team has had to face in recent years. Not only did we see a significant increase in the number of controls (from 965 non-granular controls in Rev 4, Rev 5 now stands at 1193), but there were extensive changes in control structures as well. These changes warranted that we go beyond simply comparing control IDs (i.e., line up AC-1.a.1 from Rev 4 with AC-01.a.1 in Rev 5). Instead, the team had to analyze what the Rev 4 control requires, determine how it was broken down, and identify how the breakdown was handled in Rev 5. For example, was the control distributed to multiple Rev 5 controls? Was it merged with another control, or was it removed from the control set, but were some parts of it incorporated into another control? This is further exacerbated by the fact that NIST SP 800-53 is made up of more than just security and privacy controls; it also covers baselines for security classifications (800-53B) and assessment procedures (800-53A). All of these were updated and moved into Rev 5. Here are some details on the important elements that changed:
Privacy controls. Incorporation of privacy controls into the main body of controls. Privacy controls in Rev 4 were relegated to Appendix J, almost like an afterthought, and treated mostly as optional for the time it was developed. Privacy has figured more strongly in risk assessment since then. Rev 5 introduces a new control family, PT (Personally Identifiable Information Processing and Transparency), and adds a privacy component to several controls.
Organization-defined values: Organization-defined values have figured in 800-53 since Rev 1. In Rev 5, we saw these values used in tests as well. This presented a challenge because parameters must be defined by the assessment team and displayed wherever control statements and tests are referenced. Our Xacta content templates for NIST 800-53 Rev 4 had 870 unique parameters, with Rev 5 this has gone up to 1519.
Revoked and reconstituted controls. The incorporation of privacy controls into security controls demonstrates this best. We saw all of the privacy controls rescinded and reconstructed into other controls (not unlike how a Federation-issue replicator recycles matter into other forms). There are also some Rev 4 security controls that have been revoked coming into Rev 5 and reconstituted as part of updated and new controls. For example, SI-3(9) Authenticate Remote Commands from Rev 4 has been taken out from the System and Information Integrity family and incorporated into AC-17(10) under the Access Control family.
Shifting control statements and sub-elements: Returning to our language translation metaphor, if we want to accurately “speak” Rev 5, it’s helpful to understand how control statements were organized in Rev 4. Each control comes with a “Stated Requirement” or control statement, which defines what needs to be present in a system to satisfy a particular security or privacy category. These can be short, simple statements that don’t need to be broken down into smaller elements to effectively meet the requirement. Some can be especially lengthy and complex – these are better handled if broken down into their sub-elements. This is why we have two control sets for NIST 800-53 and CNSS 1253: standard (nongranular) and extended (granular). At a granular level, some NIST 800-53 Rev 4 control statements changed in order in Rev 5. The example below shows three sub-elements of AC-5 (a,b,c) in Rev 4. However, in Rev 5, there are only two, and AC-5 sub-element ‘b’ content doesn’t line up with the Rev 4 AC-5.b. This transposition occurs across multiple controls and families.
Revision 4 | Revision 5 | ||
AC-5.a | Separation of Duties | AC-05.a | Separation of Duties |
AC-5.b | Separation of Duties | ||
AC-5.c | Separation of Duties | AC-05.b | Separation of Duties |
ISO 27002:2013 and 27002:2022
Even with fewer controls than NIST 800-53 Rev 4 or Rev 5, the ISO 27002 update from 2013 to 2022 can get just as complicated. The 27002 sees the merging of multiple 2013 controls into a single 2022 control. For example, the 2013 controls for storage media (08.3.1, 08.3.2, 08.3.3, 11.2.5) all merge into the 2022 control 7.10 – on top of requirements unique to this new control. This presents challenges in consolidating data associated with these multiple controls. Furthermore, compliance with these old controls doesn’t automatically translate into compliance with the new control, which has components that were not present in 2013.
NIST SP 800-171 with 800-171A
This NIST Special Publication provides recommended requirements for protecting the confidentiality of controlled unclassified information (CUI). Revision 1 of this publication did not carry assessment procedures. Revision 2 now carries 800-171A, which covers how one should test for compliance with 800-171. The third revision of this publication is in its final public draft and now mimics the control structure of 800-53 in that it now has organization-defined parameters as well.
The transition between Rev 1 and 2 is straightforward: there is no complex merging or splitting of controls from one version to the other. Complexity is introduced in Rev 3, with the use of organization-defined parameters in both controls and tests.
Australia ISM
The frequency of upgrades is a challenge when dealing with the ISM. While it doesn’t use parameters like NIST, the ISM has upgrade cases involving rescinded (withdrawn) controls that are incorporated into new and/or old controls – done quarterly. The ISM also moves controls around from one guideline to another. This may appear inconsequential, but if your assessment workflow relies on the presentation order of controls (dependencies), transfers such as these may wreak havoc on that flow. The process of moving data from one revision to another is difficult enough for NIST 800-53, which upgrades roughly every five years. This is an exponentially heavier lift with a regulation that upgrades every three months and 904 controls as of the last count.
Xacta is Designed to Change Along with Continually Evolving Regulations
What we’ve learned from these regulation changes adds depth to how the development team behind Xacta continually modifies and improves the platform. We’ve had to put in enhancements to accommodate the NIST 800-53 Rev 5.1.1 structural control and assessment procedure modifications, making Xacta Rev 5-ready – this means more than just having Rev 5 content available, our Xacta tool has gone through some major retooling to adapt to the structural changes in assessing for NIST 800-53 Rev 5. We’re seeing control movements that are common across different regulations and are working on enhancements that will make Xacta suited to these upgrade cases. Translation, as with the Star Trek episode, works best if the body of controls is understood not just for its individual parts but as interdependent components.
The universe of regulations and standards will only keep growing, and we’re steering Xacta into new territory each time, boldly where no one has gone before.