20 CIS Controls – Control 2: Inventory and Control of Software Assets
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.
Notes:
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.