Skip to content ↓ | Skip to navigation ↓

Today, I will be going over Control 2 from version 7 of the top 20 CIS Controls – Inventory and Control of Software Assets. I will go through the 10 requirements and offer my thoughts on what I’ve found.

Key Takeaways for Control 2

  • Let Control 1 be a driver. Only attempt to scan hardware that is already in your asset database. If a system isn’t in the asset database, revisit Control 1 to figure out why.
  • Reuse existing tools. Many of the tools you are going to be using for Control 1 are going to be used for Control 2. There’s no sense to not treat these two controls as one when you are looking at how to implement them.
  • Start cheap. Along the same lines of re-using tools, many of the requirements can be accomplished with open source or built-in tools. That being said, as your organization grows, you will also outgrow the capabilities of these free tools.

Requirement Listing for Control 2

1. Maintain Inventory of Authorized Software

Description: Maintain an up-to-date list of all authorized software that is required in the enterprise for any business purpose on any business system.

Notes: Creating a list from scratch in a large enterprise can seem difficult to do. As I’ve mentioned in other controls, it may be easier to start with a baseline of what currently exists (requirement 3 below) and work on noting which software on the list is approved. While you also monitor for new software in your environment, of course.

2. Ensure Software is Supported by Vendor

Description: Ensure that only software applications or operating systems currently supported by the software’s vendor are added to the organizations authorized software inventory. Unsupported software should be tagged as unsupported in the inventory system.


3. Utilize Software Inventory Tools

Description: Utilize software inventory tools throughout the organization to automate the documentation of all software on business systems.

Notes: Using a File Integrity Monitoring tool such as Tripwire Enterprise can scan the environment for new software. Let automated tools like these be the driver for populating your inventory databases.

4. Track Software Inventory Information

Description: The software inventory system should track the name, version, publisher and install date for all software, including operating systems authorized by the organization.

Notes: If you’re using a tool mentioned in requirement three above, then you should be able to track most if not all of the items in this requirement. A snapshot of an operating system may not be able to gather install date, depending on how the data is collected. In that case, it’s best to continually scan systems and track results over time.

5. Integrate Software and Hardware Asset Inventories

Description: The software inventory system should be tied into the hardware asset inventory so all devices and associated software are tracked from a single location.

Notes: Some tools, such as vulnerability management products like Tripwire IP360, have a dual purpose to both scan the environment for new devices as well as take inventory of what is running on them. For more single purpose tools, make sure they are plumbed to integrate with asset management systems so you can keep data in a single repository.

6. Address Unapproved Software

Description: Ensure that unauthorized software is either removed or the inventory is updated in a timely manner.

Notes: Once you have a baseline, this control becomes easy to manage. Changes to installed applications on systems should be fairly rare.

7. Utilize Application Whitelisting

Description: Utilize application whitelisting technology on all assets to ensure that only authorized software executes and all unauthorized software is blocked from executing on assets.

Notes: This is the most important recommendation in the entire set of controls. Nothing will stop attackers more than implementing this properly. I would like to speak to the capabilities of AppLocker, since it is freely available to everyone running Windows (supported versions, that is) right now. First you can whitelist by folder/file name. This makes managing the whitelist very easy, and it also provides the opportunity for an attacker to just re-use existing folder/name structures. Next, you can whitelist by file hash, which is amazingly effective. However, this comes at the cost of having to constantly update the list of file hashes, which can be a nightmare across the enterprise. Finally, you have the option to whitelist based off of the files being digitally signed. This is a good balance between the two previous options; however, that can be bypassed as well by attackers. Choose a whitelisting technology which you can easily manage across the entire environment. If that’s not possible, consider AppLocker for critical systems.

8. Implement Application Whitelisting of Libraries

Description: The organization’s application whitelisting software must ensure that only authorized software libraries (such as *.dll, *.ocx, *.so, etc) are allowed to load into a system process.

Notes: When you are deciding on a whitelisting solution, just make sure that this can be accomplished. As far as I am aware, AppLocker cannot define what libraries are loaded. So you are going to have to go for a paid route if this section is going to be implemented.

9. Implement Application Whitelisting of Scripts

Description: The organization’s application whitelisting software must ensure that only authorized, digitally signed scripts (such as *.ps1, *.py, macros, etc.) are allowed to run on a system.

Notes: Along the same lines as the previous requirement, ensure that the whitelisting technology you are using can do this. From an AppLocker prospective, you can also define which users have the ability to run these as well.

10. Physically or Logically Segregate High Risk Applications

Description: Physically or logically segregated systems should be used to isolate and run software that is required for business operations but incur higher risk for the organization.

Notes: I am glad that this is part of the control, as businesses are going to have some high risk applications that are required to run in the environment. The key here is that you need compensating controls in place to both prevent as well as detect attacks. Any traffic and activity to these systems should be heavily scrutinized. These systems should be primary candidates for application whitelisting as well as whitelisted network traffic.


See how simple and effective security controls can create a framework that helps you protect your organization and data from known cyber attack vectors by downloading this guide here.

Read more about the 20 CIS Controls here:

Control 20 – Penetration Tests and Red Team Exercises

Control 19 – Incident Response and Management

Control 18 – Application Software Security

Control 17 – Implement a Security Awareness and Training Program

Control 16 – Account Monitoring and Control

Control 15 – Wireless Access Control

Control 14 – Controlled Access Based on the Need to Know

Control 13 – Data Protection

Control 12 – Boundary Defense

Control 11 – Secure Configuration for Network Devices, such as Firewalls, Routers, and Switches

Control 10 – Data Recovery Capabilities

Control 9 – Limitation and Control of Network Ports, Protocols, and Services

Control 8 – Malware Defenses

Control 7 – Email and Web Browser Protections

Control 6 – Maintenance, Monitoring, and Analysis of Audit Logs

Control 5 – Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers

Control 4 – Controlled Use of Administrative Privileges

Control 3 – Continuous Vulnerability Management

Control 2 – Inventory and Control of Software Assets

Control 1 –  Inventory and Control of Hardware Assets

You can also learn more about the CIS controls here.