Hello and welcome to the NIST 800-171 learning path, my name is Dave Hatter, I'm an instructor for this class and this is course two. Understanding and implementing the 110 NIST 800-171 requirements. In this video we'll take a look at the first of the requirement families 3.1 access control as I'm sure you're well aware because access control is a concept that is applicable to most all modern systems. It's a method for identifying users and processes to ensure that only authorized users and processes have access to CUI. You need to ensure that CUI is not released or exposed to those not authorized to access it. It's important to keep in mind that this is not just digital assets it covers physical assets as well. You need to protect any sort of physical CUI for example, paper, microfilm, etc. And then you might need manual processes and procedures to do that. And this is a large requirement family there are 22 requirements, let's dive right in. The first of the requirements in access control is 3.1.1, limit system access to authorized users, processes acting on behalf of authorized users and devices. Pretty straightforward, right? Limit system access to authorized users, processes acting on behalf of authorized users and devices. So we want to make sure that we don't have any unauthorized users accessing any system that stores processes or transmit CUI. This is a basic security requirement. It's focused on account management for systems and applications. Again, account management pretty typical in most modern systems. We want to make sure that access to objects is granted only to authorized users and processes. And they point out, enforcement mechanisms can be implemented at the application and or the service level. Our next requirement is 3.1.2 limit system access to the types of transactions and functions that authorized users are permitted to execute. Again, that's limits system access to the types of transactions and functions that authorized users are permitted to execute. It's a basic security requirement and again we want to make sure that only authorized users can perform actions in our system. Organizations can choose to define privileges based on account, account type or both. Account types can include a variety of accounts including anonymous, individual, group, guest, etc. And you can use other attributes to restrict access including location, configuration, time of day, that sort of thing. Again, not prescriptive and this is giving you guidance on different things that you might want to consider to make the supply in your organization. The next control 3.1.3 control the flow of CUI in accordance with approved authorizations. Again, control the flow of CUI in accordance with approved authorizations. So you're going to authorize where CUI can go and then control the flow of that CUI information based on those authorizations. This is a derived security requirement, controls were CUI can travel within and between systems versus who can access it. You're going to use information flow control policies and mechanisms to control that flow. It's based on the characteristics of the information or the path of the information. You will use enforcement at boundary protection devices, things like routers and switches, etc. And you need to ensure that you're considering the trustworthiness of the filtering and inspection mechanisms and that they're going to be adequate and up to the task to protect that flow of CUI. 3.1.4, separate the duties of individuals to reduce the risk of malevolent activity without collusion. Again, separate the duties of individuals to reduce the risk of malevolent activity without collusion. This is really about separation of duties, a concept that has also been around for a long time in the world of IT. This is a derived security requirement, obviously by separating duties, it reduces the risk of malicious activity without collusion between one or more parties. Ideally you're going to split duties among several individuals or roles. It also can help with cross training and dealing with situations like when someone is out on vacation. But the primary purpose is ultimately to reduce the risk of exposure of CUI without collusion amongst individuals. And you need to ensure that individuals who administer access control do not also administer auditing functions. Obviously if I can control access to systems as well as have access to the logging and can manipulate that, then I can potentially take malicious actions and then it will erase any record of those malicious actions, not good. So, let's take a look at 3.1.5 employ the principle of least privilege including for specific security functions and privileged accounts. Again, employed the privilege of least privilege, I'm sorry, employ the principle of least privilege including for specific security functions and privileged accounts. Ideally everyone knows what the principle of least privilege is. We want to give people the absolute minimum amount of access required to perform their jobs. This is a derived security requirement. Again, you want to give people the absolute minimum amount of privileges required to perform a task and you want to restrict access to privileged accounts and use dedicated privileged accounts. So rather than have someone log in with the account they do their daily work with that has administrative privileges. You want to have dedicated privileged accounts which adds to the visibility and accountability of those accounts. 3.1.6, use non-privileged accounts or roles when accessing non-security function. Use non-privileged accounts roles when accessing non-security functions. A derived requirement. Again, when you're just doing your daily work, you want to make sure you're doing it with non-privileged accounts. And when you are doing anything that requires administrative level permissions, then you have dedicated accounts for that. 3.1.7, prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs. Again, prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit laws. Most modern operating systems make this pretty easy. This is a derived security requirement. Ideally if you can abuse or misuse privileged functions, then we know that can lead the compromise of CUI or worse. You want to make sure that privileged functions are logged and logs should be reviewed to detect the use of privileged functions. Pretty straightforward stuff. 3.1.8, limit unsuccessful logon attempts. Again, limit unsuccessful log on attempts. It's derive security requirement, should be implemented for local and network logons. To prevent denial of service, you can use temporary lockouts. So after x number of failed logins the account locks for say 15 minutes and then automatically unlocks itself so you don't have to wait for an administrator to unlock it. And this can be implemented at the operating system application level. Again, this is pretty common in most modern operating systems, pretty easily implemented. 3.1.9, provide privacy and security notices consistent with applicable CUI rules. Again, provide privacy and security notices consistent with applicable CUI rules. This is a derived security requirement. Also pretty easy in most modern operating systems you're going to display a warning message that CUI is contained in the system when the user logs in. This really only needs to be done for human logon processes. And in the NIST 800-171 documentation they say quote, organizations consult with the Office of General Counsel for legal review and approval of the warning banner content. So that's 3.1.9, 3.1.10 is use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity. Again, use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity. Also pretty easy with the most modern operating systems, it's a derived security requirement. Lock sessions after a period of user inactivity. They don't tell you what that should be, they leave that up to you. Again, non prescriptive, leave it up to you to decide what the right period of inactivity should be can be. Can be implemented at the operating system or the application level. Should not be used in place of logging out of the system when work is complete. And it's also important to remember that when you do have a session time out, that you have some sort of pattern-hiding display screen saver, something like that. So that any CUI that may have been visible is no longer accessible without the user unlocking the session. 3.1.11, terminate automatically a user session after a defined condition. Terminate automatically a user session after a defined condition. This is a derived security requirement, and basically they leave up to you to determine what the triggers are but you'll have some sort of triggers that will terminate user sessions. We've already talked about a prime example of some sort of user inactivity. Time of day might be another one once it hits 5 pm, you knock everyone off the system. Terminate all processes associated with the user session except processes specifically designed to continue after the session is terminated. 3.1.12, monitor and control remote access sessions. Monitor and control remote access sessions. This is a derived security requirement. Per NIST, quote, remote access is access to organizational systems by users for processes acting on behalf of users communicating through external networks eg, the Internet. Remote access methods include dial up, broadband, and wireless, unquote. You need to ensure that only authorized users can access organizational systems. You want to monitor access to ensure ongoing compliance. And they point you to various NIST Special Publications including 800-46, 800-77, and 800-113 for guidance on remote access and virtual private networks. There's some excellent guidance in those Special Publications, I would recommend that you check them out. But the bottom line here is if you're going to allow remote access to your systems and perhaps you're not going to allow remote access to certain systems that contain CUI. Then this is obviously a control that you could say doesn't apply to us. But if you are you need to make sure that you monitor and control it and then the next few get into additional steps you need to take to secure remote access. So 3.1.13, employ cryptographic mechanisms to protect the confidentiality of remote access sessions. Again that's, employ cryptographic mechanisms to protect the confidentiality of remote access sessions. It's a derive requirement, essentially use something like a VPN, a virtual private network. NIST says quote, cryptographic standards including FIPS-validated cryptography and NSA-approved cryptography unquote should be used for cryptography on remote access. Again, VPNs but reminder that if you use a VPN it may make it difficult to detect malicious code because of the encryption at play. 3.1 .14, remote, I'm sorry, route remote access via managed access control points. Again that's route remote access via managed access control points. This is a derived security requirement, pretty straightforward limit remote access to manage ingress and egress points. Know where someone could get in and out of the system using remote access and limited to those ingress and egress points and control that. 3.1.15, authorize remote execution of privileged commands and remote access to security-relevant information. Again authorized remote execution of privileged commands and remote access to security-relevant information. Another derived security requirement. You want to limit the ability to execute privileged commands remotely. NIST says quote, a privileged command is a human initiated interactively or via a process operating on behalf of a human. Command executed on a system involving the control, monitoring, or administration of the system, including security functions unquote. This one might be a little trickier now because thanks to the pandemic, many people had to be able to work from remote environments. So it may be more common that you would have administrators performing privileged tasks over remote access. Something to consider but again, one of the requirements of the access control family. 3.1.16, authorize wireless access prior to allowing such connections. Again, authorize wireless access prior to allowing such connections. This is a derived security requirement. You need to ensure wireless networks use authentication protocols and ideally you're going to whitelist wireless connections. You're not going to let someone on your network unless you have pre-authorized that device. And they point you to NIST Special Publication 800-97 for guidance to secure wireless networks. A lot of good advice in there, I would suggest that you check out NIST Special Publication 800-97 as well. 3.1.17, protect wireless access using authentication and encryption. Again, protect wireless access using authentication and encryption. It's a derived security requirement. You don't want to have unauthenticated users or devices on your network. You should use the strongest wireless encryption possible, obviously something like WPA 3 if possible or at least WPA 2. Again they point you to NIST Special Publication 800-97 for guidance on securing wireless networks. 3.1.18, control connection of mobile devices. Again, control connection of mobile devices. A derived security requirement. They describe mobile devices as tablets, phones, etc. And obviously they're typically designed to operate wirelessly. These devices may contain a variety of sensors that can capture data and obviously lead to the inadvertent or malicious exfiltration of CUI. These devices are often much less secure than traditional computing devices. They may or may not be receiving updates, they may or may not have endpoint protection, anti virus software, that sort of thing, so something to consider. And mobile device access should be carefully controlled, you don't want these devices being used to exfiltrate CUI. They point you to NIST Special Publication 800-124 for guidance and mobile device security, also work your time to check out. 3.1.19, encrypt CUI on mobile devices and mobile computing platforms. This is a derived security requirement. You can implement full device encryption which is probably your best bet but in a bring your own device type of environment that may be less possible. So you can use container based encryption to protect CUI on mobile devices and have control over those devices. And they tell you to make sure that you're using FIPS-validated cryptography or NSA-approved cryptography for the encryption of CUI on mobile devices and mobile computing platforms. 3.1.20, verify and control/limit connections to and use of external systems. Again that's, verify and control/limit connections to and use of external systems. This is a derived security requirement and they point out that you generally have little or no control over external systems which presents a risk to your CUI. This can include personal systems or cloud-based systems and it can include other systems that do not contain CUI but might have access to your systems that do. And thus you want to control or limit those connections that would potentially allow to the exfiltration and breach of CUI. 3.1.21, limit use of portable storage devices on external systems. Again that's limit use of portable storage devices on external systems. This is a derived security requirement. And obviously I think everyone probably gets that if I can walk in with a portable hard drive or a thumb drive or something like that and plug it in I can potentially exfiltrate CUI. And perhaps depending on your environment and the security maturity you've achieved no one being the wiser. They point out these devices can be used to purposefully or inadvertently expose CUI. So you're going to want to potentially block or certainly limit used to authorized personnel under carefully controlled circumstances. And then last but not least 3.1.22 control CUI posted or processed on publicly accessible systems. Again that's, control CUI posted or processed on publicly accessible systems. This is a derived security requirement. And NIST says quote, that in accordance with laws, executive orders, directives, policies, regulations or standards the public is not authorized to access nonpublic information. Eg, information protected under the privacy act, CUI, and proprietary information, unquote. So you want to make sure that you're not posting any of those things to public systems websites etc, where anyone could access it. You should have individuals who are authorized to post CUI especially designated so that they can be trained, they can understand what CUI is. And to the last point understand how to scrub any nonpublic information including CUI from anything that's going to be posted on publicly available sites, websites that sort of thing. So again, a lot of controls in this family, a lot to take in my guess is many of these are things you're already doing to some extent. And for those that aren't again, there's some basic guidance here on how you can get there. Thank you for watching this video, and I will see you in the next video.
