The second critical security control (and foundational) is the Inventory of Authorised and Unauthorised Software. (Council on Cyber Security, 2014) specifies it as:
Actively manage (inventory, track, and correct) all software on the network so that only authorised software is installed and can execute, and that unauthorised and unmanaged software is found and prevented from installation or execution.
The basic ideas are similar to CSC1:
- You can only protect what you know.
- You only want authorised software to be on your assets.
You need some control in relation to what software is installed to your assets. When you allow users to have full control over what is installed on computers, you have lost control of your software management. Without control, you will find different pieces of software ranging from pirated software to malicious software on your computers.
Software management also goes hand-in-hand with making sure that software are regularly updated not just when there is a new feature or capability but also if there is a security vulnerability. My blog entry back in 2010 on “What to Update?” is still relevant on what software to update. Remember, all an attacker needs is one vulnerable computer in your environment to be able to enter your network. And it’s far easier than you think as you always have the human element factoring in (e.g., accidentally clicking on a malicious link).
Implementing the Control
In implementing the control for a small business (including a home office), we will look at primarily the ‘Quick Win’ category in the CSC document.
|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 customised software that may be seen as difficult to whitelist, use CSC 2-8 in (Center for Cyber Security, 2014) (isolating the custom software in a virtual operating system that does not retain infections.).
|CSC 2-2||Devise a list of authorised 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 authorised software has not been modified.|
|CSC 2-3||Perform regular scanning for unauthorised 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 unrecognised binaries (executable files, DLL’s and other libraries, etc.) are found on a system, even inside of compressed archives.
This includes checking for unrecognised or altered versions of software by comparing file hash values (attackers often utilise altered versions of known software to perpetrate attacks, and file hash comparisons will reveal the compromised software components).
I would address CSC 2-2 first as you need to have a list of authorised software before you can implement whitelisting. On servers, this will be easier as you only have a small set of authorised software that should be on servers (e.g., your directory software, mail server software, etc.). For workstations and laptops, it becomes a bit more challenging but you should have at least a core list of allowed software (e.g., office productivity software, web browser, anti-virus client, etc.). The list is important so you know how much of a variance there is between your “ideal world” versus the reality of it.
You will need a tool to get the software inventory on your system. There are a number of free or cost-effective tools out there using your favourite search on ‘Software Inventory’. Software Inventory is often tied in with your Hardware Inventory to form an Asset Inventory (or what ITIL folks will call a Configuration Management Database or CMDB). When looking for an asset inventory tool, I would look for at least the following:
- Support for all the platforms in your environment (e.g., you may have Windows, Mac OS X, and other operating systems).
- Preference for agent-less installations so you don’t have another software to install but it may result in some inaccurate information (e.g., there is a disparity between the last time the system was scanned versus what software it has).
- Specify the list of authorised software and optionally include your licenses.
- Generate reports on what you currently have and changes in your environment. Optionally, get reports on which systems are out-of-compliance and where they’re out-of-compliance.
- (Optionally) Integration with your directory software (e.g., Active Directory) or user database to tie in users with the asset.
Once you have your authorised software inventory, you can then look at CSC 2-1 Application Whitelisting. When implemented correctly, application whitelisting does work in addressing what software is allowed in your environment. Unfortunately, I don’t know of many free application whitelisting software (except for Microsoft AppLocker available for Windows 7 and newer) but there are number of good ones available in the marketplace (just do a search on ‘Application Whitelisting’ or ‘Application Control’. Some of them are bundled as part of an Endpoint Protection application. If you have an existing anti-virus application, check if it is capable of application control. One of the biggest challenges in security right now is in relation to “Security Tool Sprawl” wherein you have too many security tools that do not communicate with one another so you need to have a separate console for each.
Depending on how the whitelisting is implemented, there is a certain level of trust you impart on the vendor providing the whitelisting service. In 2013, a leading application whitelisting vendor was compromised (it appears that they weren’t using application whitelisting on all their systems) and allowed malicious software to be treated as legitimate.
Once you had CSC 2-1 and 2-2 implemented, CSC 2-3 follows in making sure that regular scanning for unauthorised software is happening.
This foundational control is complemented with other CSCs like Continuous Vulnerability Assessment and Remediation and Malware Defence.
The human element is the biggest differentiator on whether this is a quick win or not. It depends on the environment that your users have grown accustomed to. If they were restricted (i.e., they don’t have administrative privileges on their systems) then it will be a quick win. If they had unrestricted privileges then it will be a bit more difficult as you try and win them to your side.
The biggest challenge comes from those who either develops software (if your company is a software development firm), does Research & Development (R&D) where scripting or similar software tools are used, or administers the information systems (e.g., system administrators). You will need to convince these groups of people that the control is for their best interest. We won’t tackle this right now but it’s something to keep in mind when implementing this control.
Otherwise, the technology element is easier to implement whether you go through the route of limiting privileged access (i.e., don’t make everyone an administrator) or through application whitelisting.
What do you think?
The blog entries on CSC may be edited as I have more current information on the control. It is easier for me to update an existing entry rather than recreating the whole thing.