NIST SP 800-171B: The Natural Evolution of NIST SP 800-171

Rick Tracy
Rick Tracy
June 25, 2019 • 4 min read

Enhanced Security Requirements for Critical Systems and High Value Assets


When NIST issued the original SP 800-171 more than a year ago, many assumed this was just the starting point and that “the bar would be raised” to add more rigorous security requirements, as needed, over time.

As expected, earlier this week NIST released DRAFT NIST SP 800-171B, which includes 33 enhanced Controlled Unclassified Information (CUI) requirements for critical systems and high value assets.  NIST indicates the focus of these new requirements is on organizations that are likely targets of advanced persistent threat (APT) attacks.

At a high level, some of the primary goals of 800-171B, as specified by NIST in chapter three of the SP 800-171b, are to:

  • Apply a threat-centric approach to security requirements specification
  • Employ alternative system and security architectures that support logical and physical isolation using system and network segmentation techniques, virtual machines, and containers
  • Implement dual authorization controls for the most critical or sensitive operations
  • Limit persistent storage to isolated enclaves or domains
  • Implement a comply-to-connect approach for systems and networks
  • Extend configuration management requirements by establishing authoritative sources for addressing changes to systems and system components
  • Periodically refresh or upgrade organizational systems and system components to a known state or developing new systems or components
  • Employ a security operations center with advanced analytics to support continuous monitoring and protection of organizational systems
  • Use deception to confuse and mislead adversaries regarding the information they use for decision-making, the value and authenticity of the information they attempt to exfiltrate, or the environment in which they are operating.

With this background, the distribution of the 33 enhanced requirements across the 14 existing CUI requirement categories seems logical:

  1. Access Control: 3 enhanced requirements
  2. Awareness and Training: 2 enhanced requirements
  3. Audit and Accountability: 0 enhanced requirements
  4. Configuration management: 3 enhanced requirements
  5. Identification and Authentication: 3 enhanced requirements
  6. Incident Response: 2 enhanced requirements
  7. Maintenance: 0 enhanced requirements
  8. Media Protection: 0 enhanced requirements
  9. Personnel Security: 2 enhanced requirements
  10. Physical Protection: 0 enhanced requirements
  11. Risk Assessment: 7 enhanced requirements
  12. Security Assessment: 1 enhanced requirement
  13. System and Communications Protection: 4 enhanced requirements
  14. System and information Integrity: 6 enhanced requirements

Viewing 800-171B in this manner shows where the emphasis is being placed for the purpose of reducing the impact of APT attacks.  It also shows where there is room for additional expansion and enhancements over time.  For instance, there are four categories that have no new or enhanced requirements.  As the threat landscape evolves, we should expect to see NIST continue to raise the bar by introducing more enhanced CUI requirements.  When looking at how 800-53 has evolved – a few hundred controls to more than 1,000 controls anticipated with 800-53 rev 5 –there is precedent for this thinking.

800-171B:  A logical progression from a security stand point

The enhanced requirements contained in 800-171B make sense from a security perspective.  Some noteworthy examples:

  • Employ technical and procedural means to confuse and mislead adversaries through a combination of misdirection, tainting, or disinformation. This requirement points to deception technology to assist with threat hunting activity. (13.3e)
  • Refresh organizational systems and system components from a known, trusted state at least twice annually. This requirement points to technology that helps to periodically rebuild systems to a known-good state in order to thwart undetected malware and reduce harmful dwell time. (14.4e)

These are just two examples of very valuable requirements that will likely necessitate additional investment in technology or a managed service that many (or most) organizations don’t currently use.

Some Cautionary Notes

Many organizations are still struggling to comply with the basic 800-171 requirements.  That said, the federal government should be careful to control who is responsible for complying with the much more rigorous requirements defined by 800-171B, once it is finalized.

The title of the document suggests that 800-171B applies to critical systems and high value assets.  However, these two terms are not defined in the document.  Also, there are no criteria questions to help determine what qualifies as a critical system or high value asset.

Additionally, the focus of 800-171B is on organizations that are likely targets of APT attacks.  How is this knowable with any degree of certainty?  You might argue that every organization is theoretically an APT target.  If so, and there are no clear definitions for critical system or high value asset, then how does one determine if 800-171B applies or not?

I think there needs to be some refinement in this area before 800-171B is finalized.  Otherwise, there will be confusion and frustration among the ecosystem of 65,000 or so organizations that are required to comply with 800-171.

Rick Tracy
Rick Tracy
Former Senior VP and Chief Security Officer
Rick Tracy is the former senior vice president and chief security officer at Telos Corporation.
Read full bio
Newest Most Voted
Inline Feedbacks
View all comments
Geeta Kumar

Nicely written article!

Incidentally, I’ve been reading up on NIST 800-171 r2 and NIST 800-171B (like everyone else) and found this NIST Newsletter that cites “Weapons Systems” as an example of a High Value Asset (HVA) —

The definition in the NIST Newsletter didn’t quite satisfy me and subsequently I began to Google the term HVA and came upon Memo M-19-03, which defines HVA as follows:

An agency may designate Federal information or a Federal information system as an HVA when it relates to one or more of the following categories:

-Informational Value – The information or information system that processes, stores, or transmits the information is of high value to the Government or its adversaries.

-Mission Essential – The agency that owns the information or information system cannot accomplish its Primary Mission Essential Functions (PMEF), as approved in accordance with Presidential Policy Directive 40 (PPD-40) National Continuity Policy, within expected timelines without the information or information system.

-Federal Civilian Enterprise Essential (FCEE) – The information or information system serves a critical function in maintaining the security and resilience of the Federal civilian enterprise.

While thinking of my previous position as a contractor at an Army organization and the terabytes of data they had on soldiers–tons of PII–I can’t help but wonder whether the data and information gathered from it constituted HVA.

I wish I could translate the definition in the Memo M-19-03 into layman terms but I’ll leave that to the experts.

FYSA: your article was among the hits that my Google search yielded (

I enjoyed your newsletter.

Rick Tracy

Thanks for the comment!

If I read correctly, the examples pertain to federal information systems, not Non-Federal systems, which is the focus of 800-171/b.

In any case, I think NIST could help themselves by making this as transparent as possible. Provide definitions in 800-171/b to make it easy for organizations who have to comply.

Thanks for letting me know about how the blog post was prioritized by Google. So far it has nearly 15,000 views on LinkedIn. Lots of interest in 800-171/b!

Thanks again for your comment!


Subscribe to Our Newsletter

Email Address
Select a Country

Although we may use your information for targeted marketing and advertising, as described in the Privacy Policy, we will never sell your information to any third party.