Hello and welcome to the NIST 800-171 Learning Path. My name is Dave Heder. I'm your instructor for this class and this is Course 2, Understanding and implementing the 110 NIST 800-171 requirements. As you know, there are 14 requirements families. In this video, we'll take a look at family 3.4 configuration management. Configuration management is an IT management process for determining and maintaining the attributes of a product or system over the course of its life. It's about standardizing and managing configurations to simplify and improve security and help systems to perform in predictable and measurable ways. There are nine requirements in these requirements family. Let's take a look. The first requirement, 3.4.1 is establish and maintain baseline configurations and inventories of organizational systems, including hardware, software firmware, and documentation throughout the respective system development life cycles. This is a basic requirement. You need to create and maintain baselines, you need to modify and maintain baselines as a security risks and business needs change. I think that's a really important concept here. Obviously the bad guys never rest, the security threats constantly change. You need to understand the risks to your business, you need to understand the threat landscape, and obviously your business will change over time. You need to make sure that your configuration benchmarks and baselines are in alignment with the ever shifting field of security and business needs. You can check out in this special publication 800-128 for guidance on security focus configuration management, 3.4.2 is Establish and enforce security configuration settings for information technology products employed in organizational systems. This is another basic requirement. You need to ensure the configuration settings can be changed to alter the functionality or security of a system. You want to try to parameterize things to make it flexible and responsive to your needs, as security threats change or business needs change. You want to establish organization-wide security focused on settings that become part of the configuration baseline. You need to explore common, recognized benchmarks such as the CIS benchmarks to harden systems. We're big fans of the CIS benchmarks at [inaudible]. I would strongly encourage you to check that out and also the CIS controls. It's a great way to set a baseline of where you stand versus these well-known industry standard controls, and then use the benchmarks to improve your understanding against those controls. You can check out in this special publication 800-70 and/or special publication 800-128 for guidance on security configuration settings. Again, I strongly encourage you to check out CIS, the Center for Internet Standards, and their benchmarks as well as their controls, 3.4.3, Track, review, approve or disapprove and log changes to organizational systems. This is a derived requirement. It's also often called configuration change control. There should be a process to recommend, test, review, approve, and log changes. If approved, changes must be made to baseline configuration. Again, you want to go through a change control process. You don't want changes being made to your benchmarks, or your baselines willy-nilly. You want to make sure that they're understood and they're approved. Then when that happens, you need to update that baseline. Then you can check out NIST special publication 800-128 for guidance on configuration change control, 3.4.4, Analyze the security impact of changes prior to implementation. This is another derived requirement and you need to do a security impact analysis on proposed changes to improve baseline, to make sure that you understand what that impact might be and can plan appropriately or perhaps consider an alternative approach to implement a change because of the impact it could create. You can check out in this special publication 800-128 for guidance on configuration change control and security impact analysis, 3.4.5, Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems. Yet another derived requirement. You want to limit access to systems so that only authorized individuals can make changes. You want to access restrictions to ensure the potential security impact and configuration management is taken into account. Again, you don't want unapproved or changes that are not understood made by people that should not be making changes to your system. Again, the goal is to create a baseline and to use that baseline so that your security configuration is standardized and applied to all systems. You can see in this special publication 800-128 for guidance on configuration change control, 3.4.6, Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. Another derived requirement. This says, "Where feasible, organizations limit component functionality to a single function per component." You should disable unused or unnecessary ports and protocols, and you should use network scanning tools, intrusion detection and prevention systems, and endpoint protection to block access and lock systems down so that only authorized users have access to essential functionality, 3.4.7, Restrict, disable, or prevent the use of non-essential programs, functions, ports, protocols and services. Another derived requirement. Make a security-based determination on what software, ports, protocols and services are available to your environment. Again, sometimes business users are going to have specific requirements for they may need a software that you'd rather they not use, but you need to be aware of that software. We've discussed this before, you can't protect things that you don't know you have, and sometimes little exceptions will need to be made. You'll have to work with your business users, but ultimately, security should be brought in from the beginning, security should be part of all of these decisions. If you do have to make exceptions, then obviously you might want to use workarounds, like have that software that's needed, that's exceptional software only on a very locked down system, on its own VLAN, or something like that. But again, you want to make sure security's brought in from the beginning and that you're disabling anything that's not essential. You can follow the principle of least privilege, and you should follow the principle of least privilege frankly whenever possible and use whitelisting to determine what is allowed in your environment, 3.4.8, Apply deny-by-exception or blacklisting policy to prevent the use of unauthorized software or deny-all, permit-by-exception white-listing policy to allow the execution of authorized software. Another derived requirement. In general, whitelisting is better than blacklisting because with blacklisting, you're going to have to constantly keep that list up to date. With whitelisting, obviously, you start out at nothing and you start adding things to the whitelist to allow it. It's generally going to be easier to maintain that and keep that up-to-date, and it's going to be more flexible in most environments, or possibly some combination of both. You want to take steps to verify the integrity of whitelisted software, and you can check out NIST special publication 800-167 for guidance on application whitelisting. Then finally, 3.4.9, Control and monitor user-installed software and other derived requirement. As I said before, you can't protect something you don't know you have. You need to understand what software is installed in your environment and where possible limit or block entirely any user installed software and make them go through a process where IT and security understands what's being installed. Obviously, you can use things like GPOs or App Locker, or whitelisting, that thing to control what software can be installed by users. As they mentioned, policy enforcement can be manual, automated or both. Frankly, again, the more you can lock it down, although I know this creates friction and business users hate this, the better to ensure that rogue software or software with known vulnerabilities that perhaps you don't know needs to be patched is in there, and that might lead to a vulnerability that would allow the bad guys in and have access to your CUI. That wraps us up for 3.4 configuration management. I will see you in the next video on requirements family 3.5. Thanks.
