Part 1: Access Control
Access Control is all about ensuring that only authorized users can access specific information, systems, or resources—and only under authorized conditions. It helps prevent unauthorized disclosure or modification of CUI and supports the principle of least privilege, meaning users should have only the access they need to do their jobs.
Access control is the first family in the NIST SP 800-171 for a reason: It’s foundational. (It also starts with A, so that also probably played a role in the order…) A strong access control strategy can prevent a wide range of cyber incidents from accidental data leaks to malicious insider threats
Under NIST SP 800-171 Revision 2, the Access Control family consists of a whopping 22 requirements grouped under 4 main objectives:
- Limit System Access (3.1.1 – 3.1.7)
The first step in any access control program is to identify who and what is authorized to access the CUI. 3.1.1 requires the organization to define (and continuously maintain) a list of authorized users, processes acting on behalf of authorized users, and authorized devices that can connect to the system processing CUI.
Side Quest!
What exactly is meant by “processes acting on behalf of authorized users”? Great question because NIST doesn’t exactly explain it anywhere. The closest definition I’ve found is in the CNSSI 4009 for Non-Person Entity. Think of it like this: if a user logs in and starts an application (like Outlook or a file backup tool), that application runs as the user, meaning it can only do what the user is allowed to do—read their files, access their emails, etc. The process is “acting on behalf of the user.” In the context of NIST SP 800-171 and cybersecurity, this concept is important for controlling access. If a user isn’t authorized to access certain data, any process running on their behalf shouldn’t be allowed to access it either. One example would be a background sync tool that pulls files from a secure folder. Access would be denied if the user it’s running under doesn’t have access to that folder. A malicious script injected into a web browser can’t escalate privileges just because it’s running inside the browser… It’s still bound to the user’s permissions.
Side Quest Complete.
Back to building our access control program. Once we have identified our users, processes and devices (and documented them, because if it isn’t written down, it doesn’t exist) we need to identify (and document) what they can do, also known as transactions and functions. In 3.1.2 we define the transactions and functions that our authorized users (processes and devices) can execute and we configure the system to limit those entities to those transactions and functions. The idea here is to limit what these entities can do to only what they need to perform their job functions (3.1.5 Least Privilege).
Now where can this CUI go? Fundamentally, access control is all about ensuring only authorized entities can access, transmit, or receive CUI, and only in approved ways so naturally, a well-formed access control program will ensure that CUI only flows (3.1.3) to authorized destinations, from approved sources, to approved destinations, and only over secure channels.
We have all taken insider threat training (at least I hope we have… if not… Here you go) and one big prevention item for insider threat is separation of duties. The idea is to separate duties (3.1.4) to reduce the risk of malevolent activity without collusion. Essentially, it’s harder to accomplish sketchy stuff with more people. Examples of separation of duties would be having a manager approve user access and the IT Team granting access or having system admins schedule and install patches while the security team verifies patch installation and integrity. In addition to insider threats, separation of duties limits the occurrence of human error and whether intentional or not, humans are always the biggest weakness in any security program. Continuing with limiting the human factor, employing the concept of least privilege (3.1.5) also limits what a person can do to only essential functions to perform their job, thus decreasing the impact of damage users can inflict, whether intentional or not.
Lastly in our push to limit system access, we must look at our use of privileged accounts. 3.1.6 requires privileged users to also have a non-privileged account to use when performing non-security functions. Using a non-privileged account for user level activities limits its exposure and potential for compromise. It also prevents accidental changes and facilitates better monitoring when reviewing audit logs. Lastly we need to define (and document) privileged functions vs non privileged functions and privileged users vs non privileged users and ensure that the system is appropriately configured to ensure that non-privileges users cannot execute privileged functions.
- Control Internal System Access (3.1.8 – 3.1.11)
The next step in the development of our access control program is configuring our internal system access. Limiting unsuccessful login attempts (3.1.8) requires system administrators to configure a system to lock after an organizationally defined number of unsuccessful login attempts has occurred and define an action that must take place to unlock the account (delay algorithm or manual account reset by a system admin). Locking an account after several unsuccessful login attempts can thwart attacks such as brute force, credential stuffing, dictionary attacks, or password spraying. It is also helpful in identification as the system auditing functionality can trigger an alert that malicious activity may be afoot.
Once a successful logon has occurred, the user needs to understand that they are accessing a system with sensitive data via a Privacy & Security Notice. 3.1.9 requires systems to provide privacy and security notices consistent with applicable CUI rules. The CUI Registry can provide any CUI category specific notices that need to be displayed.
Configuring session lock (3.1.10) on any information system is imperative to retaining confidentiality of the information being processed. A manual session lock should always be required as a matter of policy and included in the rules of behavior when personnel step away from their system. Because humans are … well … humans, we can configure an automatic session lock after a predetermined period of inactivity (usually 15 minutes or less) to be initiated in cases where a user has inadvertently left the system but did not initiate a session lock.
Taking the session lock one step further, in 3.1.11 we configure session termination (logout) after organization defined conditions. While session lock is temporary, session termination ends all processes and releases the users’ resources. Determining these conditions would be based on your organizational risk assessment. With a session lock, a user simply logs back in and everything is as they left it. Consequently, a malicious user logs back in, and everything is as the authorized user left it. Does the results of the risk assessment warrant removing the convenience of a session lock for session termination? If so, when? You can also configure a session termination for policy violations like repeated unauthorized file access attempts.
Stay tuned for the thrilling sequel to this awe-inspiring family of controls.
- Control External System Access (3.1.12 – 3.1.19)
- Control Remote Access
- Remote Access Confidentiality
- Remote Access Routing
- Privileged Remote Access
- Wireless Access Authorization
- Wireless Access Protection
- Secure CUI External to the Boundary (3.1.18 – 3.1.22)
- Mobile Device Connection
- Encrypt CUI on Mobile
- External Connections [CUI Data]
- Portable Storage Use
- Control Public Information
