Critical Control 3: Secure Configurations for Hardware and Software on Laptops, Workstations, and Servers

How do attackers exploit the lack of this control?

On both the Internet and internal networks that attackers have already compromised, automated computer attack programs constantly search target networks looking for systems that were configured with vulnerable software installed the way it was delivered from manufacturers and resellers, thereby being immediately vulnerable to exploitation. Default configurations are often geared to ease-of-deployment and ease-of-use and not security, leaving some systems exploitable in their default state. Attackers attempt to exploit both network-accessible services and browsing client software using such techniques.

Defenses against these automated exploits include procuring computer and network components with the secure configurations already implemented, deploying such pre-configured hardened systems, updating these configurations on a regular basis, and tracking them in a configuration management system.

How can this control be implemented, automated, and its effectiveness measured?

1. QW: System images must have documented security settings that are tested before deployment, approved by an agency change control board, and registered with a central image library for the agency or multiple agencies. These images should be validated and refreshed on a regular basis (such as every six months) to update their security configuration in light of recent vulnerabilities and attack vectors.
2. QW: Standardized images should represent hardened versions of the underlying operating system and the applications installed on the system, such as those released by NIST, NSA, DISA, the Center for Internet Security (CIS), and others. This hardening would typically include removal of unnecessary accounts, as well as the disabling or removal of unnecessary services. Such hardening also involves, among other measures, applying patches, closing open and unused network ports, implementing intrusion detection systems and/or intrusion prevention systems, and host-based firewalls.
3. QW: Any deviations from the standard build or updates to the standard build should be documented and approved in a change management system.
4. QW: Government agencies should negotiate contracts to buy systems configured securely out of the box using standardized images, which should be devised to avoid extraneous software that would increase their attack surface and susceptibility to vulnerabilities.
5. QW: The master images themselves must be stored on securely configured servers, with integrity checking tools and change management to ensure only authorized changes to the images are possible. Alternatively, these master images can be stored in off-line machines, air-gapped from the production network, with images copied via secure media to move them between the image storage servers and the production network.
6. Config/Hygiene: At least once per month, run assessment programs on a varying sample of systems to measure the number that are and are not configured according to the secure configuration guidelines.
7. Config/Hygiene: Utilize file integrity checking tools on at least a weekly basis to ensure that critical system files (including sensitive system and application executables, libraries, and configurations) have not been altered. All alterations to such files should be automatically reported to security personnel. The reporting system should have the ability to account for routine and expected changes, highlighting unusual or unexpected alterations.
8. Config/Hygiene: Implement and test an automated configuration monitoring system that measures all secure configuration elements that can be measured through remote testing, using features such as those included with SCAP-compliant tools to gather configuration vulnerability information. These automated tests should analyze both hardware and software changes, network configuration changes, and any other modifications affecting security of the system.
9. Config/Hygiene: Provide senior executives with charts showing the number of systems that match configuration guidelines versus those that do not match, illustrating the change of such numbers month by month for each organizational unit.

Associated NIST SP 800-53 Rev 3 Priority 1 Controls:

CM-1, CM-2 (1, 2), CM-3 (b, c, d, e, 2, 3), CM-5 (2), CM-6 (1, 2, 4), CM-7 (1), SA-1 (a), SA-4 (5), SI-7 (3), PM-6

Procedures and tools for implementing and automating this control:

Organizations can implement this control by developing a series of images and secure storage servers for hosting these standard images. Then, commercial and/or free configuration management tools can be employed to measure the settings of managed machines' operating system and applications to look for deviations from the standard image configurations used by the organization. Some configuration management tools require that an agent be installed on each managed system, while others remotely login to each managed machine using administrator credentials. Either approach or combinations of the two approaches can provide the information needed for this control.

Control 3 Metric:

The system must be capable of identifying any changes to an official hardened image that may include modifications to key files, services, ports, configuration files or any software installed on the system. Modifications include deletion, changes or additions of new software to any part of the operating systems, services or applications running on the system. The configuration of each system must be checked against the official master image database to verify any changes to secure configurations that would impact security. Any of these changes to a computer system must be detected within 24 hours and notification performed by alerting or sending email notification to a list of enterprise administrative personnel. Systems must block installation, prevent execution, or quarantine unauthorized software within one additional hour, alerting or sending e-mail when this action has occurred. Every 24 hours after that point, the system must alert or send e-mail about the status of the system until it has been removed from the network or remediated. While the 24 hour and one hour timeframes represent the current metric to help organizations improve their current state of security, in the future, organizations should strive for even more rapid alerting and isolation, with notification about unauthorized changes being sent within two minutes and installation and execution blocked within five minutes.

Control 3 Test:

To evaluate the implementation of Control 3 on a periodic basis, an evaluation team must move a benign test system that does not contain the official hardened image, containing additional services, ports and configuration files changes, onto the network. This must be performed on ten different random segments, using either real or virtual systems. The evaluation team must then verify that the systems generate an alert or e-mail notice regarding the changes to the software within 24 hours. It is important that the evaluation team verify that all unauthorized changes have been detected. The team must also verify that the alert or e-mail is received within one additional hour indicating that the software has been blocked or quarantined. The evaluation team must verify that the system provides details of the location of each machine with the unauthorized changes, including information about the asset owner.

The evaluation team must then verify that the software is blocked by attempting to execute it and verifying that it is not allowed to run. In addition to these tests, two additional tests must be performed:

1. File integrity checking tools must be run on a regular basis. Any changes to critical operating system, services and configuration files must be checked on an hourly basis. Any changes must be blocked and follow the above email notification process.
2. System scanning tools that check for open ports, services, software version, patch levels and configuration files must be run on a daily basis. Any changes must be blocked and follow the above email notification process.

List Of Controls

• Critical Control 1: Inventory of Authorized and Unauthorized Devices
• Critical Control 2: Inventory of Authorized and Unauthorized Software
• Critical Control 3: Secure Configurations for Hardware and Software on Laptops, Workstations, and Servers
• Critical Control 4: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
• Critical Control 5: Boundary Defense
• Critical Control 6: Maintenance, Monitoring, and Analysis of Audit Logs
• Critical Control 7: Application Software Security
• Critical Control 8: Controlled Use of Administrative Privileges
• Critical Control 9: Controlled Access Based on Need to Know
• Critical Control 10: Continuous Vulnerability Assessment and Remediation
• Critical Control 11: Account Monitoring and Control
• Critical Control 12: Malware Defenses
• Critical Control 13: Limitation and Control of Network Ports, Protocols, and Services
• Critical Control 14: Wireless Device Control
• Critical Control 15: Data Loss Prevention

Additional Security Controls

The following sections identify additional controls that are important but cannot be fully automatically or continuously monitored to the same degree as the controls covered earlier in this document.

• Critical Control 16: Secure Network Engineering
• Critical Control 17: Penetration Tests and Red Team Exercises
• Critical Control 18: Incident Response Capability
• Critical Control 19: Data Recovery Capability
• Critical Control 20: Security Skills Assessment and Appropriate Training to Fill Gaps