Inventory of Authorized and Unauthorized Software
Actively manage (inventory, track, and correct) all software on the network so that only authorized software is installed and can execute, and that unauthorized and unmanaged software is found and prevented from installation or execution.
Why Is This Control Critical?
Attackers continuously scan target organizations looking for vulnerable versions of software that can be remotely exploited. Some attackers also distribute hostile web pages, document files, media files, and other content via their own web pages or otherwise trustworthy third-party sites. When unsuspecting victims access this content with a vulnerable browser or other client-side program, attackers compromise their machines, often installing backdoor programs and bots that give the attacker long-term control of the system. Some sophisticated attackers may use zero-day exploits, which take advantage of previously unknown vulnerabilities for which no patch has yet been released by the software vendor. Without proper knowledge or control of the software deployed in an organization, defenders cannot properly secure their assets.
Poorly controlled machines are more likely to be either running software that is unneeded for business purposes, introducing potential security flaws, or running malware introduced by an attacker after a system is compromised. Once a single machine has been exploited, attackers often use it as a staging point for collecting sensitive information from the compromised system and from other systems connected to it. In addition, compromised machines are used as a launching point for movement throughout the network and partnering networks. In this way, attackers may quickly turn one compromised machine into many. Organizations that do not have complete software inventories are unable to find systems running vulnerable or malicious software to mitigate problems or root out attackers.
Managed control of all software also plays a critical role in planning and executing system backup and recovery.
How to Implement This Control
|CSC 2-1||Deploy application whitelisting technology that allows systems to run software only if it is included on the whitelist and prevents execution of all other software on the system. The whitelist may be very extensive (as is available from commercial whitelist vendors), so that users are not inconvenienced when using common software. Or, for some special-purpose systems (which require only a small number of programs to achieve their needed business functionality), the whitelist may be quite narrow. When protecting systems with customized software that may be seen as difficult to whitelist, use item 8 below (isolating the custom software in a virtual operating system that does not retain infections.).||Quick win (One of the "First Five")|
|CSC 2-2||Devise a list of authorized software and version that is required in the enterprise for each type of system, including servers, workstations, and laptops of various kinds and uses. This list should be monitored by file integrity checking tools to validate that the authorized software has not been modified.||Quick win|
|CSC 2-3||Perform regular scanning for unauthorized software and generate alerts when it is discovered on a system. A strict change-control process should also be implemented to control any changes or installation of software to any systems on the network. This includes alerting when unrecognized binaries (executable files, DLL's and other libraries, etc.) are found on a system, even inside of compressed archives. This includes checking for unrecognized or altered versions of software by comparing file hash values (attackers often utilize altered versions of known software to perpetrate attacks, and file hash comparisons will reveal the compromised software components).||Quick win|
|CSC 2-4||Deploy software inventory tools throughout the organization covering each of the operating system types in use, including servers, workstations, and laptops. The software inventory system should track the version of the underlying operating system as well as the applications installed on it. Furthermore, the tool should record not only the type of software installed on each system, but also its version number and patch level.||Visibility/Attribution|
|CSC 2-5||The software inventory systems must be integrated with the hardware asset inventory so that all devices and associated software are tracked from a single location.||Visibility/Attribution|
|CSC 2-6||Dangerous file types (e.g., .exe, .zip, .msi) should be closely monitored and/or blocked.||Configuration/Hygiene|
|CSC 2-7||Virtual machines and/or air-gapped systems should be used to isolate and run applications that are required for business operations but based on higher risk should not be installed within a networked environment.||Advanced|
|CSC 2-8||Configure client workstations with non-persistent, virtualized operating environments that can be quickly and easily restored to a trusted snapshot on a periodic basis.||Advanced|
|CSC 2-9||Deploy software that only provides signed software ID tags. A software identification tag is an XML file that is installed alongside software and uniquely identifies the software, providing data for software inventory and asset management.||Advanced|
CSC 2 Procedures and Tools
Whitelisting can be implemented using commercial whitelisting tools or application execution tools that come with anti-virus suites and with Windows. Commercial software and asset inventory tools are widely available and in use in many enterprises today. The best of these tools provide an inventory check of hundreds of common applications used in enterprises, pulling information about the patch level of each installed program to ensure that it is the latest version and leveraging standardized application names, such as those found in the common platform enumeration specification.
Features that implement whitelists of programs allowed to run are included in many modern endpoint security suites. Moreover, commercial solutions are increasingly bundling together anti-virus, anti-spyware, personal firewall, and host-based intrusion detection systems (IDS) and intrusion prevention systems (IPS), along with application white and black listing. In particular, most endpoint security solutions can look at the name, file system location, and/or cryptographic hash of a given executable to determine whether the application should be allowed to run on the protected machine. The most effective of these tools offer custom whitelists based on executable path, hash, or regular expression matching. Some even include a gray list function that allows administrators to define rules for execution of specific programs only by certain users and at certain times of day.
CSC 2 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 new software installed on systems in the organization (time in minutes)?
2. How long does it take the scanners to alert the organization's administrators that an unauthorized software application is on a system (time in minutes)?
3. How long does it take to alert that a new software application has been discovered (time in minutes)?
4. Are the scanners able to identify the location, department, and other critical details about the unauthorized software that is detected (yes or no)?
CSC 2 Automation Metrics
In order to automate the collection of relevant data from these systems, organizations should gather the following information with automated technical sensors:
1. How many unauthorized software applications are presently located on business systems within the organization (by business unit)?
2. How long, on average, does it take to remove unauthorized applications from business systems within the organization (by business unit)?
3. What is the percentage of the organization's business systems that are not running software whitelisting software that blocks unauthorized software applications (by business unit)?
4. How many software applications have been recently blocked from executing by the organization's software whitelisting software (by business unit)?
CSC 2 Effectiveness Test
To evaluate the implementation of Control 2 on a periodic basis, the evaluation team must move a benign software test program that is not included in the authorized software list to 10 systems on the network. Two of the systems must be included in the asset inventory database, while the other systems do not need to be included. The evaluation team must then verify that the systems generate an alert or e-mail notice regarding the new software within 24 hours. 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 this new test software, 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 the software 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.
CSC 2 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.
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 software installed on the organization's network systems. These systems should be able to identify if new software is introduced to the environment that has not been authorized by enterprise personnel. 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: Active device scanner
Step 2: Active scanner reports to inventory database
Step 3: Inventory database compares to inventory baseline
Step 4: Inventory database initiates alerting system
Step 5: Alert system notifies security defenders
Step 6: Security defenders monitor and secure inventory database
Step 7: Security defenders update software inventory database
Step 8: Whitelisting tool continuously monitors all systems on the network
Step 9: Whitelisting checks and makes updates to the software inventory database.
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.