20 Critical Security Controls – Control 2: Inventory of Authorized and Unauthorized Software

Today’s post is all about Control 2 of the CSIS 20 Critical Security Controls – Inventory of Authorized and Unauthorized Software (last week was Control 1).  Here I’ll explore the requirements I’ve parsed out of the control (I used the PDF version, but the online version is here) and offer my thoughts on what I’ve found.*

Key Take Aways

1. Don’t do it all at once. Asset inventory is hard, and the software piece of that is no exception.
2. Start Small and Basic. Another repeat from Control 1. There’s too much that can go wrong if you try to go big too soon. Start with the understanding that there are some pretty obvious edge cases that you’ll need to eventually cover.
3. Take Control 1 and Control 2 together.  There are too many similarities between Control 1 and Control 2 to not treat them as one control. The reality is that computing devices and software are, from a business perspective, assets. Tracking them both with a reasonable degree of  accuracy is important, so why make the distinction from a process perspective?
4. Take these requirements to your vendors. This is another one that is likely to turn into a trend. This Control is littered with requirements you can take to your security tool vendors. The requirements that are especially important are related to interoperability feature/functionality.

Potential Areas Of Improvement

• Combine Control 1 and Control 2. If we look at the world from the perspective of what an “asset” is, then it’s pretty easy to see that computing devices are the same as software – they all have some value to an organization. When you read the tenth requirement below, you’ll get the idea.
• Dependencies. As I suspected, there are allusions to a plethora of processes and/or procedures throughout this Control. It makes some sense, but having a distinct list of these dependencies could be helpful for those less experienced with interpreting control frameworks.
• Rethink Today’s Organizational Needs. There are always exceptions and there’s no possible way a single written control framework can address everything for all organizations. I recognize this as a fact. Still, I think some of the requirements are stuck somewhere in the last decade. What organization is going to subject a R&D organization, for example, to a change management process for installing software? Perhaps in the most rigorous of environments this is tolerated, but I would wager that the supermajority of R&D shops give developers administrative rights expressly because they need them to develop and install software on their machines. This presents an interesting dilemma from an information security perspective, but it’s reality.

Requirement Listing

1. Description: Devise a list of authorized software that is required in the enterprise for each type of system, including servers, workstations, and laptops of various kinds and uses.
   • Notes: There’s a lot of work that needs to go into this. Consider that you need to first identify the types ofassets you have (presumably, you’ve done some of this when you classified in carrying out the first control), then you need to create a list of software for each of those types. The level of granularity will likely be determined by the size of your organization.
2. Description: This list should be tied to file integrity checking software to validate that the software has not be modified.
   • Notes: Here is a point of integration that stands to be automated. If it’s not automated in some way, then whenever you update your authorized software list, you’re going to need to remember to update your FIM tool. If this could be automated in some way (and it can), then your FIM tool should be capable of understanding when it comes across a particular type of asset (so it knows what should/shouldn’t be installed). Business context is important.
3. Description: Perform regular scanning and generate alerts when unapproved software is installed on a computer.
   • Notes: This has to be automated. There’s really no two ways about it for an enterprise any larger than a few computing devices. An implication to make explicit is that “scanning” involves three steps: 1) harvesting information from your computing devices, 2) comparing the information you’ve harvested against your whitelist of authorized software, and 3) generating an alert when an unauthorized piece of software is discovered.
4. Description: A strict change control process should also be implemented to control any changes or installation of software to any systems on the network.
   • Notes: When it comes to non-OS software and computing devices (as in the first control), this is much easier to accomplish. In the case of controlling installed software in the enterprise, this is easier said than done. The problem is almost always that some set of users will simply not be subjected to this level of control. If, for example, a developer had to wait three days for the change control board to make a decision about a new compiler, then that developer will find a new employer.
5. Description: Deploy application white listing technology that allows systems to run only approved software and prevents execution of all other software on the system.
   • Notes: This requirement depends on having a list of authorized software in the first place, which is fair enough. Something that comes to mind is that it seems reasonable to start talking to OS vendors for this type of support. I know there are whitelisting companies out there, but it seems most advantageous to all of us if OS’ provided whitelisting capabilities.
6. Description: Deploy software inventory tools throughout the organization covering each of the operating system types in use, including servers, workstations, and laptops.
   • Notes: Nothing really spectacular about this particular requirement, but if your organization has some oddball platforms, you’re probably going to be acquiring inventory tools in-house. If you’re not used to doing this and have a security program in place already (you could, right?) then you’re going to open yourself to secure SDLC requirements (treated later in the controls).
7. Description: The software inventory system should track the version of the underlying operating system as well as the applications installed on it.
   • Notes: This seems like a potentially important requirement because it requires tracking the OS, which is the tie to computing device and thus a distinct relationship to the asset inventory discussed in Control 1. This requirement lends credence to the idea of an Asset Inventory Tool being holistic – covering network and computing devices as well as software (embedded, operating system, and application alike).
8. Description: Furthermore, the tool should record not only the type of software installed on each system, but also its version number and patch level.
   • Notes: Given the previous requirement, I’m not certain this one makes a whole lot of sense, but we can get the idea nevertheless. The implication is that organizations are now on the hook for categorizing the software they use – they may not do this (in fact, I’ve never seen an outfit do this).
9. Description: The software inventory should be tied to vulnerability reporting/threat intelligence services to fix vulnerable software proactively.
   • Notes: I interpret this requirement in a way that would have a Software Inventory Tool harvesting patch levels rather than a Patch and Vulnerability Assessment tool doing the job. At the very least, the Software Inventory Tool you use (whether automated or manual) ought to inform your Patch and Vulnerability Assessment process, which is really the spirit of this requirement.
10. Description: The software inventory systems must be tied into the hardware asset inventory so all devices and associated software are tracked from a single location.
    • Notes: This requirement is making explicit the inferrence I drew three requirements ago – that the software and computing device inventories should be one in the same. But, this requirement describes two systems to cooperate so computing devices and software are “tracked from a single location,” which technically implies a third system (or at least a cooperation of the two inventory systems where one is dominant).
11. Description: The software inventory tool should also monitor for unauthorized software installed on each machine.
    • Notes: When first reading this requirement, it seems straightforward. But, it’s not. If we’re using whitelists (as in the Quick Wins already discussed), then we are, by default, detecting unauthorized software. If this requirement is not redundant, and I don’t believe it is, then it may imply that monitoring for unauthorized software should be performed in non-standard installation locations. If software can be installed without knowledge of the on-device package monitor, then monitoring for and detecting unauthorized software becomes somewhat more difficult in this context.
12. Description: This unauthorized software also includes legitimate system administration software installed on inappropriate systems where there is no business need for it.
    • Notes: This is another seemingly straightforward requirement. The idea here is that an Administrator shouldn’t install GPMC on any corporate box – only on that computer from which the Administrator means to manage group policy.
13. Description: Dangerous file types (e.g., exe, zip, msi, etc.) should be closely monitored and/or blocked.
    • Notes: I’m surprised that there is no mention of File Integrity Monitoring solutions related to this requirement. If your organization doesn’t like a particular file type, any decent FIM solution would be able to monitor for those types and alert the appropriate administrative personnel when detected. Of course, the file types listed are sometimes required during the course of legitimate business (often required?), which may make it difficult to live up to this requirement. Then, there’s also the need to have a list of dangerous file types.
14. Description: Software inventory and application white listing should also be deployed on all mobile devices that are utilized across the organization.
    • Notes: This requirement is well-intentioned, but, in today’s BYOD world, potentially obsolete. I use my own mobile device at the office. It’s my device, and even if inventory/whitelisting capabilities could be deployed to the device (they can’t today), I wouldn’t let my employer do so. For devices owned by the organization, the permission problem goes away, but the “can you deploy such capability” problem remains – some mobile platforms are not architected for this type of application.
15. Description: Virtual machines and/or air-gapped systems should also be used to isolate and run applications that are required but based on higher risk and that should not be installed within a networked environment.
    • Notes: Perhaps legacy software requiring Windows NT needs to be used for manufacturing. Maybe there’s a monolithic Perl application requiring Linux kernel 1.2. Whatever the reason, this is a reasonable – though potentially expensive – requirement. An organization needs to understand all of their applications, what their needs are, what risks they pose to business processes, and then potentially rearchitect the system to accommodate virtualization or establish manual processes to deal with migrating information over an air gap.
16. Description: Configure client workstations with nonpersistent virtualized operating environments that can be quickly and easily restored to a trusted snapshot on a periodic basis.
    • Notes: There are probably a few correlated requirements that go along with this. If I’m operating in a nonpersistent virtual environment, then my change management process will need to accommodate that (I need to go through additional steps to update the image). Also, periodically reverting to a trusted snapshot is a smart idea when we don’t know what we don’t know – just make sure that’s happening automatically and test that you’re restoring from the right image.
17. Description: Deploy software that only provides signed software ID tags.
    • Notes: The context around this requirement is written as “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,” which is saying use the ISO 19770 Software ID tags (managed by TagVault.org). Just call it out guys.
18. Description: 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.
    • Notes: This is essentially a requirement for software inventory to handle patch checking as well. If the market has, for quite some time, included patch assessments as part of SCM, does this mean that SCM should become an authoritative source for software inventory? Or, does it mean that software inventory tools (i.e. IT ops tools) are expected to start moving into the realm of SCM? The convergence will be interesting to see.
19. Description: Features that implement white and black lists of programs allowed to run or blocked from executing are included in many modern endpoint security suites.
    • Notes: This seems to be the first place that mentions blacklists, which is interesting. The framework would do well to define “endpoint” and “security suite” and what those two terms really mean together.
20. Description: 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.
    • Notes: Here’s my first real “nit” on the framework – is it possible to bundle apart? My nit aside, this seems redundant to the previous statement and the two could simply be taken together.
21. Description: 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.
    • Notes: Again, more requirements you can use for your endpoint security suite – whatever that might end up being. If you’re just making your selections, this is good information for you.
22. Description: The most effective tools offer custom white and black lists 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, and black lists based on specific signatures.
    • Notes: More endpoint security suite requirements.
23. Description: The system must be capable of identifying unauthorized software by detecting an attempt to install it.
    • Notes: This and the next requirement provide an option, but either way your software inventory system must be able to find and identify unauthorized software. In this case it’s about detecting an attempt to install the software (remember what I noted earlier about non-standard installation locations). The saving grace here, ironically, is that a lot of installed software needs some elveated privilege to run, and many modern systems provide some level of protection around installing such software (installation is not quite as surreptitious as it seems).
24. Description: Or, the system must be capable of identifying unauthorized software by detecting an attempt to execute it.
    • Notes: This and the previous requirement provide an option, but either way your software inventory system must be able to find and identify unauthorized software. In this case it’s about detecting an attempt to execute the software, which, in theory, helps if you miss detection on install. But, this also means that some process (the OS?) is looking at the application trying to start, assessing it against a list of known good software, and then taking some action.
25. Description: The system must be capable of notifying enterprise administrative personnel within 24 hours through an alert or e-mail.
    • Notes: This requirement highlights a potential missing requirement. The alert is great, but what would it look like if the alert had more information about the device, and therefore the device owner (assuming we’re following Control 1) to share as well?
26. Description: Systems must block installation, prevent execution, or quarantine unauthorized software within one additional hour
    • Notes: This metric seems to be building in some buffer for manual process. It seems odd to list “installation” as one of the things that must be blocked “within one additional hour” of detection. This may provide some insight to what it really means to “block installation.” Simply that you need to uninstall.
27. Description: Systems must alert or send e-mail when blocking, preventing, or quarantining action has occurred.
    • Notes: A simple requirement, but make sure that your system is capable of doing the alerting. If you’re relying on manual processes, then this is something ripe for a checklist.
28. Description: Every 24 hours after that point, the system must alert or send e-mail about the status of the system until the unauthorized system has been removed from the network.
    • Notes: Again, a simple requirement, but make sure that your system is capable of doing the alerting on some automated level – or have a checklist you can audit to ensure the manual process.
29. Description: 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.
    • Notes: I would encourage you to make some subset of the 10 systems subject to non-standard installations, and even to installations with non-Administrative, but privileged users.
30. Description: The evaluation team must then verify that the systems generate an alert or e-mail notice regarding the new software within 24 hours.
    • Notes: None.
31. Description: 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.
    • Notes: None.
32. Description: 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.
    • Notes: None.
33. Description: 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.
    • Notes: None.

Footnotes

* A method and format explanation can be found at the beginning of Control 1.

Editor’s Note: This article was written by a former contributor to The State of Security who now resides with a non-profit group with an excellent reputation. We thank him for his opinions and perspective, and wish we could acknowledge him directly for his outstanding efforts on this series.