Federal contractors required to implement the cybersecurity controls in NIST SP 800-171 may be confused when addressing safeguards involving the protection of “sessions”, particularly user sessions and network communications sessions. In our latest “What the heck?” post, we explore what NIST really means by these two types of sessions. This post is relevant for any federal contractor required to implement NIST 800-171, especially Department of Defense (DoD) contractors pursuing a Cybersecurity Maturity Model Certification (CMMC).
A glance at the controls
The two NIST 800-171 Revision 2 controls in question include:
Terminate (automatically) user sessions after a defined condition.
Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
NIST indicates that there are two types of “sessions” to account for when protecting CUI: user and network communications. So, what the heck do each of these mean, and are they mutually exclusive from one another? We unpack this in the next section.
Exploring types of sessions
NIST defines a session to be “a persistent interaction between a subscriber and an endpoint”. This implies that a session is not merely limited to a user-initiated interaction with a system, and may include interactions across systems without any user involvement. This is an important consideration when interpreting the 800-171 controls above.
Logging out = ending all processes associated with the user session
Network disconnect = ending network connections, not necessarily logged out
User sessions
User sessions, in the context of 800-171, include interactions between a user and any organizational “system” where CUI may be handled. This could be a user accessing internal IT resources, such as a file server, or it may be a user accessing external resources, such as cloud applications. The user initiates the session by connecting to the file server, or signing into the cloud application, and the session ends when the user disconnects or signs out. In the case of Control 3.1.11, the expectation is that these sessions have some form of an automatic logout (whether due to a period of inactivity or certain length of time), defined and enforced by the organization. Logging out ensures that all processes associated with the user’s session is completely terminated, and the user is forced to re-authenticate to establish a new session.
Note that this requirement is not merely describing the use of screen locks on workstations resulting from a certain period of inactivity, as these are also covered by the prior control, 3.1.10. Rather, any instances of users connecting to organizational CUI resources, whether they be workstations, servers, databases, cloud applications, or anything else, must completely sever user access to that resource after given conditions are met, which the organization is free to define. The key for this control is that any user processes are no longer running. Examples include:
- Automatically “sleeping” (different from locking) workstations after one hour of inactivity
- Automatically logging users out of SSH sessions to servers or other network appliances after one hour of inactivity
- Automatically logging users out of cloud services (e.g., secure file share applications or enclaves) after eight hours, whether sessions are inactive or not
Most contractors will use inactivity as their “defined condition” for session termination. This is recommended, but there are other conditions you may want to include. Since the spirit of this control is to protect the confidentiality (no unauthorized access) of user sessions and the information handled thereupon, you may also consider incorporating conditions such as temporal; for instance, automatic termination should a user try to SSH into a server during the middle of the night. Or, you may use geographic conditions to terminate the session if the user signs in from an unexpected location. The bottom line is that you can define the conditions; just make sure you are enforcing them and are ready to provide evidence to a CMMC assessor of doing so.
Network communications sessions
In the 800-171 Discussion text for 3.13.9, it states that this control applies to both “internal and external networks”. For external (remote) access to a contractor’s covered system, e.g., connections made across the Internet, this could include Virtual Private Network (VPN), Remote Desktop Protocol (RDP), or Virtual Desktop Infrastructure (VDI). Similar to user sessions, the expectation is that these remote network connections are terminated “at the end of the session” or whenever the organization defines. Aside from traditional remote access such as VPN/RDP/VDI, this would also include internal system connections to servers or communications among servers.
As far as terminating these network communications sessions, examples would include:
- Disconnecting corporate VPN (excluding always-on site-to-site VPN) connections after 30 minutes of inactivity
- Disconnecting RDP connections among workstations, servers and virtual machines after 30 minutes of inactivity
- Disconnecting VDI connections (such as Totem’s ZCaaS™, Azure Virtual Desktops, or connections to other hypervisors) after 30 minutes of inactivity
- Setting connections between internal servers to automatically timeout and disconnect
The CMMC Level 2 Assessment Guide provides the following example for 3.13.9:
You are an administrator of a server that provides remote access. Your company’s policies state that network connections must be terminated after being idle for 60 minutes [a]. You edit the server configuration file and set the timeout to 60 minutes and restart the remote access software [c]. You test the software and verify that the connection is terminated appropriately.
The key difference between 3.1.11 and 3.13.9 is that 3.1.11 requires user sessions to terminate, meaning users need to be automatically logged out whenever the “defined conditions” are met. 3.11.9 requires any network connections to disconnect either due to inactivity or at the end of the session. If a user, for instance, logs into a VDI CUI enclave or connects to a server using SSH, and that connection disconnects after 15 minutes of inactivity but does not sign the user out, 3.11.9 has been fulfilled but not 3.1.11.
Another helpful example to differentiate between these two requirements is Wi-Fi. Wi-Fi is itself a network connection and therefore must be terminated according to 3.13.9. However, a user connecting to, say, a cloud service over Wi-Fi would be a user session and must also fulfill 3.1.11. The TCP/IP four-layer model can help to elucidate the difference, with network communications sessions occurring in the bottom three layers (e.g., connecting to Wi-Fi), and the user sessions occurring at the top layer (e.g., connecting over Wi-Fi to a cloud service):
Given this, we can infer that the “user” in user sessions refers to either a human or a process acting on behalf of an authorized user, such as a piece of software performing tasks with user credentials. “Network” refers to the devices that comprise your IT infrastructure and that are addressable (e.g., have a MAC address, IP address, hostname, etc.). For the typical small business that permits the flow of CUI both internally (across their internal network) and externally (such as through CUI cloud backups), both 3.13.9 and 3.1.11 come into scope. Additionally, you may find it easier to address 3.13.9 before 3.1.11, given that network communications sessions are “lower-level” connections on the TCP/IP four-layer model compared to user sessions.
Wrapping up
There you have it: a brief overview of “sessions” and two NIST 800-171 controls you may be struggling to wrap your mind around. Be sure to follow along on our KnowledgeBase as we address other challenging controls such as these. Or, better yet, grab a seat in our next CMMC Readiness Online Workshop, where we discuss these controls in depth!
Thanks for reading!
Nathan
