Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
Establish, implement, and actively manage (track, report on, correct) the security configuration of laptops, servers, and workstations using a rigorous configuration management and change control process in order to prevent attackers from exploiting vulnerable services and settings.
Why Is This Control Critical?
As delivered by manufacturers and resellers, the default configurations for operating systems and applications are normally geared to ease-of-deployment and ease-of-use - not security. Basic controls, open services and ports, default accounts or passwords, older (vulnerable) protocols, pre-installation of unneeded software; all can be exploitable in their default state.
Developing configuration settings with good security properties is a complex task beyond the ability of individual users, requiring analysis of potentially hundreds or thousands of options in order to make good choices. Even if a strong initial configuration is developed and installed, it must be continually managed to avoid security "decay" as software is updated or patched, new security vulnerabilities are reported, and configurations are "tweaked" to allow the installation of new software or support new operational requirements. If not, attackers will find opportunities to exploit both network-accessible services and client software.
How to Implement This Control
|CSC 3-1||Establish and ensure the use of standard secure configurations of your operating systems. Standardized images should represent hardened versions of the underlying operating system and the applications installed on the system. Hardening typically includes: removal of unnecessary accounts (including service accounts), disabling or removal of unnecessary services, configuring non-executable stacks and heaps, applying patches, closing open and unused network ports, implementing intrusion detection systems and/or intrusion prevention systems, and use of host-based firewalls. These images should be validated and refreshed on a regular basis to update their security configuration in light of recent vulnerabilities and attack vectors.||Quick win (One of the "First Five")|
|CSC 3-2||Implement automated patching tools and processes for both applications and for operating system software. When outdated systems can no longer be patched, update to the latest version of application software. Remove outdated, older, and unused software from the system.||Quick win (One of the "First Five")|
|CSC 3-3||Limit administrative privileges to very few users who have both the knowledge necessary to administer the operating system and a business need to modify the configuration of the underlying operating system. This will help prevent installation of unauthorized software and other abuses of administrator privileges.||Quick win (One of the "First Five")|
|CSC 3-4||Follow strict configuration management, building a secure image that is used to build all new systems that are deployed in the enterprise. Any existing system that becomes compromised should be re-imaged with the secure build. Regular updates or exceptions to this image should be integrated into the organization's change management processes. Images should be created for workstations, servers, and other system types used by the organization.||Quick win|
|CSC 3-5||Store the master images on securely configured servers, validated with integrity checking tools capable of continuous inspection, and change management to ensure that only authorized changes to the images are possible. Alternatively, these master images can be stored in offline 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.||Quick win|
|CSC 3-6||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.||Visibility/Attribution|
|CSC 3-7||Do all remote administration of servers, workstation, network devices, and similar equipment over secure channels. Protocols such as telnet, VNC, RDP, or others that do not actively support strong encryption should only be used if they are performed over a secondary encryption channel, such as SSL or IPSEC.||Configuration/Hygiene|
|CSC 3-8||Utilize file integrity checking tools 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 security personnel. The reporting system should have the ability to account for routine and expected changes, highlighting unusual or unexpected alterations. |
For investigative support, the reporting system should be able to show the history of configuration changes over time and identify who made the change (including the original logged-in account in the event of a user ID switch, such as with the su or sudo command). These integrity checks should also identify suspicious system alterations such as owner and permissions changes to files or directories; the use of alternate data streams which could be used to hide malicious activities; as well as detecting the introduction of extra files into key system areas (which could indicate malicious payloads left by attackers or additional files inappropriately added during batch distribution processes).
|CSC 3-9||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 tools compliant with Security Content Automation Protocol (SCAP), and alerts when unauthorized changes occur. This includes detecting new listening ports, new administrative users, changes to group and local policy objects, (where applicable), and new services running on a system.||Advanced|
|CSC 3-10||Deploy system configuration management tools, such as Active Directory Group Policy Objects for Microsoft Windows systems or Puppet for UNIX systems that will automatically enforce and redeploy configuration settings to systems at regularly scheduled intervals. They should be capable of triggering redeployment of configuration settings on a scheduled, manual, or event-driven basis.||Configuration/Hygiene|
CSC 3 Procedures and Tools
Rather than start from scratch developing a security baseline for each software system, organizations should start from publicly developed, vetted, and supported security benchmarks, security guides, or checklists. Excellent resources include:
* The Center for Internet Security Benchmarks Program (www.cisecurity.org)
* The NIST National Checklist Program (checklists.nist.gov)
Organizations should augment or adjust these baselines to satisfy local policies and requirements, but deviations and rationale should be documented to facilitate later reviews or audits.
For a complex enterprise, the establishment of a single security baseline configuration (for example, a single installation image for all workstations across the entire enterprise) is sometimes not practical or deemed unacceptable. It is likely that you will need to support different standardized images, based on the proper hardening to address risks and needed functionality of the intended deployment (example, a web server in the DMZ vs. an email or other application server in the internal network). The number of variations should be kept to a minimum in order to better understand and manage the security properties of each, but organizations then must be prepared to manage multiple baselines.
Commercial and/or free configuration management tools can then be employed to measure the settings of operating systems and applications of managed machines to look for deviations from the standard image configurations. Typical configuration management tools use some combination of: an agent installed on each managed system, or agentless inspection of systems by remotely logging in to each managed machine using administrator credentials. Additionally, a hybrid approach is sometimes used whereby a remote session is initiated, a temporary or dynamic agent is deployed on the target system for the scan, and then the agent is removed.
CSC 3 Effectiveness Metrics
In order to test the effectiveness of the automated implementation of this control, organizations should measure the following:
1. How long does it take to detect configuration changes to a network system (time in minutes)?
2. How long does it take the scanners to alert the organization's administrators that an unauthorized configuration change has occurred (time in minutes)?
3. How long does it take to block/quarantine unauthorized changes on network systems (time in minutes)?
4. Are the scanners able to identify the location, department, and other critical details about the systems where unauthorized changes occurred (yes or no)?
5. Are the scanners able to trigger different notifications / workflows based on the severity of the configuration variance detected?
For all of the above, consider that system priority, service level commitments, system role, and other factors may drive varying objectives for scan frequency and alert time frames on different systems. Ensure that the rationale for these classifications is clear, consistent, documented, and consistently applied. Verify that target detection and notification results are aligned with service level commitments and policies for each class of system.
CSC 3 Automation Metrics
In order to automate the collection of relevant data from these systems, the organization should gather the following information with automated technical sensors:
1. What is the percentage of business systems that are not currently configured with a security configuration that matches the organization's approved configuration standard (by business unit)?
2. What is the percentage of business systems whose security configuration is not enforced by the organization's technical configuration management applications (by business unit)?
3. What is the percentage of business systems that are not up to date with the latest available operating system software security patches (by business unit)?
4. What is the percentage of business systems that are not up to date with the latest available business software application security patches (by business unit)?
5. What is the percentage of business systems not protected by file integrity assessment software applications (by business unit)?
6. What is the percentage of unauthorized or undocumented changes with security impact (by business unit)?
CSC 3 Effectiveness 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, but that does contain additional services, ports, and configuration file changes, onto the network. This must be performed on 10 different random segments using either real or virtual systems. The evaluation team must then verify that the systems generate an alert regarding the changes to the software within the target service window, or within 24 hours - whichever is less. 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 also introduce undocumented / out-of-band configuration settings and binaries using real or virtual systems on 10 random segments. The test should include making a non-persistent change, in which a change is introduced to the primary program location (/bin, Program Files, etc.), left in place for 30-60 minutes, then reverted to the original configuration.
The evaluation team must verify that all configuration changes and binaries are detected, and that there is a record of the non-persistent changes mentioned above. The detection data should include the nature of the change made (addition, removal, alteration, owner, permissions, contents, etc.), as well as the user account that made the change.
The evaluation team must also verify that unauthorized software is blocked by attempting to execute it and verifying that it is not allowed to run. On systems where blocking is not allowed or blocking functionality is not available, the team must verify that the execution of unauthorized software is detected and results in a notification to alert the security team that unauthorized software is being used.
In addition to these tests, the following 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 detected and either blocked or trigger an alert that follows the above notification process.
2. Detection software must detect the disabling of system logging, as well as the truncation, modification or deletion of log files. Note that growth of logs should not trigger notifications, but suspicious changes associated with malicious activities should; examples include deletion or truncation of logs, modification of past log events, owner or permission changes, etc. Any inappropriate changes to logs must trigger an alert that follows the above notification process.
3. System scanning tools that check for software version, patch levels, and configuration files must be run on a daily basis. Any changes must be detected and either blocked or trigger an alert that follows the above notification process.
CSC 3 System Entity Relationship Diagram
Organizations will find that by diagramming the entities necessary to fully meet the goals defined in this control, it will be easier to identify how to implement them, test the controls, and identify where potential failures in the system might occur. As with any configurations, all changes must be approved and managed by a change control process.
A control system is a device or set of devices to manage, command, direct, or regulate the behavior of other devices or systems. In this case, we are examining the devices, software, and entities used to manage and implement consistent configuration settings to workstations, laptops, and servers on the network. The following list of the steps in the above diagram shows how the entities work together to meet the business goal defined in this control. The list also delineates each of the process steps in order to help identify potential failure points in the overall control.
Step 1: Secured system images applied to computer systems
Step 2: Secured system images stored in a secure manner
Step 3: Configuration management system validates and checks system images
Step 4: Configuration policy enforcement system actively scans production systems for misconfigurations or deviations from baselines
Step 5: File integrity assessment systems monitor critical system binaries and data sets
Step 6: Whitelisting tool monitors systems configurations and software
Step 7: SCAP configuration scanner validates configurations
Step 8: File integrity assessment system sends deviations to alerting system
Step 9: Whitelisting tool sends deviations to alerting system
Step 10: SCAP configuration scanner sends deviations to alerting system
Step 11 and 12: Management reports document configuration status.
Critical Security Controls - Version 5
- 1: Inventory of Authorized and Unauthorized Devices
- 2: Inventory of Authorized and Unauthorized Software
- 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
- 4: Continuous Vulnerability Assessment and Remediation
- 5: Malware Defenses
- 6: Application Software Security
- 7: Wireless Access Control
- 8: Data Recovery Capability
- 9: Security Skills Assessment and Appropriate Training to Fill Gaps
- 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
- 11: Limitation and Control of Network Ports, Protocols, and Services
- 12: Controlled Use of Administrative Privileges
- 13: Boundary Defense
- 14: Maintenance, Monitoring, and Analysis of Audit Logs
- 15: Controlled Access Based on the Need to Know
- 16: Account Monitoring and Control
- 17: Data Protection
- 18: Incident Response and Management
- 19: Secure Network Engineering
- 20: Penetration Tests and Red Team Exercises
This work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.
To further clarify the Creative Commons license related to the 20 Critical Controls content, (i) All persons are authorized to use the content as a framework in their organization or to sell professional services related to the content (e.g. a consulting engagement to implement the 20 Critical Controls), and (ii) sale of the contents as a framework model is not authorized. Users of the 20 Critical Controls framework are also required to refer to http://www.sans.org/critical-security-controls/ when referring to the 20 Critical Controls in order to ensure that users are employing the most up to date guidance.
You may use the following code to embed the 20 Critical Controls on your site:
<iframe src="http://www.sans.org/critical-security-controls/" width="1000" height="1200" />