NIST 800-171 It’s Not Scary, It’s Just Security. Part II – Access Control

In this blog post, I am going to touch on some of the requirements of NIST 800-171 which we at C3 find our customers have partially fulfilled, or have the ability to fulfill, but have not yet implemented. I am focusing on section 3.1 Access Control, as it can be one of the more challenging control sets to decipher, yet one of the controls which can usually be achieved using existing system capabilities.

NIST 800-171 – Access Control

In my last blog post about NIST 800-171, I wrote about how meeting the requirements of 800-171 is more attainable than most would assume. Some of the controls required by 800-171 are security measures already in place courtesy of most modern systems or are already considered best practices within the Information Technology community. For example, anti-virus protection, obfuscated entry of passwords, and using unique usernames for all persons are all requirements of NIST 800-171 and are likely in place within your environment. In this blog post, I am going to touch on some of the requirements of NIST 800-171 which we at C3 find our customers have partially fulfilled, or have the ability to fulfill, but have not yet implemented. I am focusing on section 3.1 Access Control, as it can be one of the more challenging control sets to decipher, yet one of the controls which can usually be achieved using existing system capabilities.

3.1 Access Control

Section 3.1 can appear confusing at times: there are nine subsections, each of which initially seems redundant. When dissected, however, each subsection does, in fact, have a different focus. The overarching theme of this section is WHO accesses data, WHAT can they do with the data, and WHEN was data accessed. In lieu of iterating through each control one by one, I am going to summarize them into the following groups and include an explanation of each group.

Group 1

These controls ensure that all data, including Controlled Unclassified Information (CUI), can only be accessed by persons who require access. This group is the WHO of section 3.1. For example, if you are a manufacturing firm, can the accounting department view the design diagrams for your products even though they do not have a business requirement to view them? Or perhaps you are a professional services firm; do all of your project managers have access to all project data, even if they are not supporting all of the projects? This focus applies at not just at a departmental level, but also more granularly to each individual. The desire is to ensure only those who require access can gain access to data. Each person should be documented in a list to show who should have access, and to what data they should have access to. This list is important and will be used frequently throughout your journey to achieve compliance with NIST 800-171.

Group 2

These controls ensure that the type of access to data is appropriate for the level of interaction required by the individual. In other words, this group is asking WHAT an individual can do with the data they have accessed. For example, does their role within the organization require that they can read a document, or are they allowed to edit the document? From a security perspective, should they be allowed to download the document, even if they are working on a computer or device NOT issued by the company? As you can see, this second group assumes access to data and further addresses WHAT can be done with the data, and how those actions relate to what their role requires. Once these permissions are documented, they should be added to the previously mentioned list of authorized users to create a concise list of WHO can access files and WHAT they can do with each file.

Group 3

This third group of controls once again touches on the WHO and also adds WHEN to the equation. If you have completed a compliance audit such as ISO 27001, SOC 1/SOC 2, HIPAA, or any of the other near-endless acronyms of security and operational standards, then you are intimately familiar with the importance of WHEN, especially with auditors. Once you have narrowed down WHO can access data, WHAT they can do when data is accessed, the next step is to show WHEN they did it. This is where logging comes in. ISO 800-171 requires logs showing when files are accessed, as well as several other access and authentication elements. Once logs are captured and maintained, they must be reviewed by comparing the previously mentioned list of WHO and WHAT. The goal is to verify that those who accessed the files are permitted to access the files, and are performing actions they are authorized to perform.

As I stated at the beginning of this blog, the concepts behind these groups are not new and are likely already in place in your organization. What many struggle with is implementing the means to identify the WHO, WHAT, and WHEN. This is where C3 can help. We help our clients have the necessary business-level discussions to determine how they should classify data, and how to identify roles within the company which require interaction with data. We also have the technical expertise to create custom permission schemes specific to your unique requirements or to simply leverage our best practices to reach your security and compliance needs.