To continue our discussions of the security requirements of DFARS and CMMC, this week we’ll be looking at the fourth security family in NIST SP 800-171: Configuration Management.
Configuration management is a set of practices that ensures that your systems and devices are configured correctly from the start, and that any changes made to their configuration does not affect the security of your systems. It’s a big topic — but even small enterprises can benefit from enacting configuration management principles before things grow to be more complex.
The two basic security requirements in this requirement family are:
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
Establish and enforce security configuration settings for information technology products employed in organizational systems.
While these requirements may sound similar — and they are closely related — they emphasize two different sides to configuration management that are both important.
The first is the importance of having a configuration baseline for all devices and services on your network. This baseline should include things like minimum software version, basic configuration, and anything else that will allow for consistent configuration of devices on your network.
The second basic security requirement emphasizes the security aspect of configuration. All systems have settings that affect their security, and so special emphasis needs to be placed on that when designing your security baseline.
The derived requirements for this section highlight some important things to take into account when designing a configuration management process. The first three involve change management processes. While the basic requirements highlight the importance of having a configuration baseline, that baseline will need to change over time as your system changes. Change management is the set of processes that will allow you to design and implement those changes successfully.
Track, review, approve or disapprove, and log changes to organizational systems.
Analyze the security impact of changes prior to implementation.
Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
The first and most important requirement is simply to have a formal change management process. For smaller systems, this could be as simple as having the CIO and IT Director review all changes. For larger companies, this usually means a “change review board” or other formal committee that approves changes.
The second requirement is a reminder that security should be a main concern when reviewing changes. The requestor, technology owner, or subject matter expert should provide an in-depth explanation of the security risks and mitigations of any change, and the change review board should carefully consider this before approving a change.
Finally, changes should only be implemented by authorized individuals after they’re approved. This goes back to the principle of least privilege, mentioned in Part 1. But this principle needs to be built in to the design of your system from the beginning to ensure security and consistency.
Speaking of least privilege, a similar principle is highlighted in the next two requirements:
Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
This means that just accepting the “defaults” isn’t good enough when it comes to securing vital systems. For example, by default, Windows has dozens of services enabled that may serve a function on a client OS, but on a server system, they simply increase the attack surface. These should be identified and disabled. Other network gear may come with management interfaces or other features exposed. These should likewise be evaluated and either secured properly or disabled. Additionally, firewalls on servers should be configured so that programs cannot accept inbound connections unless specifically allowed.
The final two security requirements involve software, particularly on workstations:
Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
Control and monitor user-installed software.
Though these requirements can seem hard to manage, solutions like AppLocker can help you by whitelisting locations from which software may be run, and by checking security certificates for software in both authorized and unauthorized locations. Implementing these kinds of software restriction policies can help to reduce instances of malware and software licensing violations.
While configuration management is a broad set of topics, applying these security principles early on in your organization can help you to keep your systems secure and compliant. As always, if you’d like to consult with experts on these or any other IT security issues, please contact E-N Computers — we specialize in securing small and medium enterprises against the latest threats, and keeping them compliant with DFARS and other security regulations.