How to Use the NIST SP 800–171 Cybersecurity Framework
Tags: Information Security, Cybersecurity, Cloud Computing, Risk Management, Nist

While many InfoSec teams are well-prepared for almost anything that comes their way, cybersecurity is a constantly growing and changing industry. There are always going to be new threats on the horizon, which means security measures must continuously evolve to meet these new needs. In July 2019, NIST released two new edits to its SP 800–171 Framework: SP 800–171 Rev. 2 and SP 800 171B. This post will explore why the NIST SP 800–171 Framework is so important, the differences in these new updates, and how organizations can maintain NIST compliance.

Understanding the NIST SP 800–171 Framework

The National Institute of Standards and Technology (NIST) owns the handling of cybersecurity and data privacy efforts for the Department of Defense (DoD) and other government agencies. Any organization doing business with the DoD must be aware of and compliant with NIST standards, including its SP 800–171 Framework. This security framework is one of the top five security frameworks vendors must adhere to in the country. So, if your team is already doing business with or is acting as a third party to any federal government agency (especially the DoD), then you’re most likely already leveraging the SP 800–171 Framework in some capacity.

On the ground level, the SP 800–171 Framework manages the sharing and access of Controlled Unclassified Information (CUI), which is data that is critical and potentially sensitive, but that isn’t directly regulated by the government. So, the NIST security framework assesses and judges vendors and contractor agencies that are outside of the regulated federal security ‘bubble’ to ensure these organizations are able and prepared to handle CUI.

Comparing SP 800–171 Rev. 2 and SP 800 171B

The first iteration of SP 800–171 was published in 2017. In mid-2019, NIST published two proposed edits to this framework, each with unique changes and updates to the original publication:

SP 800–171 Rev. 2: This particular update provides minimal changes to the content in the original SP 800–171 documentation. Updates were made only in introductory chapters and appendices including the Glossary, Acronyms, and References section.

SP 800–171B: This Framework is intended not as a replacement of SP 800–171 but as a supplemental tool alongside the original Framework. This update takes into account the trends in cybersecurity from recent years to advise and recommend new ways to protect CUI that is at higher-risk than normal. As certain areas of security become more vulnerable and more at-risk (i.e. healthcare, finance, etc.) these areas need additional security measures in place.

How to achieve SP 800–171 compliance

Maintaining compliance with SP 800–171 regulations can be difficult for two reasons. First, dealing with CUI is tricky and the compliance reporting process is not easy. And second, since the framework is constantly being updated and added to, processes in place for achieving compliance must also be able to grow and change.

Working as a third-party vendor of the federal government, especially the DoD, is a prestigious position that only the most secure organizations can secure. That being said, there are around 110 security requirements that make up the SP 800–171 Framework, and InfoSec teams that are currently working with or trying to work with government agencies spend most of their time ensure nothing slips through the gaps.

This is why working with a security vendor management platform like Whistic is so critical for organizations using NIST Frameworks. With a Whistic vendor security profile, InfoSec teams can easily analyze and respond to NIST requirements, identify gaps, allocate new resources, and facilitate conversations along the way. Plus, because Whistic automatically updates with new Framework releases or content, InfoSec teams can be sure they’re working off the most updated version.

Related Reading:

NIST 800–171: Why The DoD’s New Guidance Matters to Cybersecurity

Automating Vendor Risk Management

Residual Risk: What Constitutes an Acceptable Level of Risk?