8 ways to reduce unauthorized software

Attackers looking to gain access to government systems and networks are constantly scanning targets for vulnerable software and initiating campaigns to trick users into downloading and executing malicious files.

Unauthorized software increases the attack surface for adversaries, because any software that is not authorized is likely unmanaged, without proper patching, updates and configurations. Moreover, IT managers with incomplete knowledge of their agency’s software cannot fully secure their assets. Unfortunately, preventing and identifying unauthorized software in large government networks is often a formidable challenge. 

To help put the appropriate focus and resources on this challenge, the Department of Homeland Security included Software Asset Management (SWAM) in phase one of its Continuous Diagnostic and Mitigation  (CDM) program. SWAM is one of four main capabilities of the CDM program, and its objective is to give IT administrators visibility into the software and operating systems installed on a network so that they can manage authorized software and remove unauthorized software.

The goal is easy to describe but much more difficult to make a reality in a large agency where other sub-organizations may be responsible for diverse assets across the enterprise and where various business units have very different requirements for software. However, not every system needs the same level of control. IT managers should start by assessing the sensitivity of their business systems and unit functions, which will make it possible to craft a policy that is appropriate to the risk.

A key component of CDM SWAM – application whitelisting – allows only what has been explicitly authorized to execute while blocking all other software by default.  It is an extremely valuable security control, but it carries significant maintenance and usability implications if not implemented effectively.

Following are eight key guidelines and recommendations that can make tackling the issue of unauthorized software much more manageable:

1. Nip it at the source.

While a robust application whitelisting capability should be the goal, a first step is to prevent unauthorized software from even entering the government environment in the first place. Agencies should have clearly defined groups or individuals who are responsible for obtaining, testing, approving, deploying and maintaining software so that end users cannot obtain software directly from external sources.

Primary sources for unauthorized software are email, web and removable media. Security teams with strong perimeter security controls can block files with extensions of known executables (.exe, .msi, .bin) along with mime types such as binary/octet-stream, application/octet-stream and application/x-msdownload via existing email and web gateway technologies (including inside compressed files). Host-based controls can similarly block known extensions and file types or block removable media entirely if not authorized in the environment.

This practice may eliminate some of the obvious targets and force attackers to give up or develop more expensive techniques. But determined individuals will  use alternative methods (i.e., encryption) to get past file inspection capabilities.

2. Don’t forget active content and browser extensions.

Application whitelisting at the client level can be very effective to prevent stand-alone malicious programs from executing on the host. However, many whitelisting tools cannot effectively prevent the execution of active content or capabilities of browser extensions or add-ons.

For example, a whitelisted browser still provides a rich environment for potential attacks and execution of malicious mobile content via ActiveX controls, java and browser extensions. Active content is also often executed when simply browsing the Internet and can be installed without knowledge of the end user. Active content and extensions can be limited by enforcing local browser/client settings or blocking associated network requests for such content at perimeter security gateways.

3. Minimize administrative privileges.

End users on government workstations should never be operating with administrative privileges by default and should not even have an option to elevate themselves to administrators unless required and properly audited. Without administrative privileges, users can be prevented from running software installation packages or executing other binary content requiring registry modifications or other privileged actions.

Access to administrative privileges allows adversaries to install malicious software, change system configurations to hide their activities and more easily exfiltrate data. Potential damage of a system compromise is directly proportional to the level of user privilege obtained on the system, and adversaries with administrative privileges have everything they need.

4. Use audit/monitor mode.

Depending on the size of an agency, it could take months or even years to get to a complete, current and manageable whitelist of approved software. However, most application whitelisting tools offer “audit” or “monitor” modes to provide logging and visibility of what software is being executed throughout the organization. The audit/monitor mode can be used to determine which applications should and should not be permitted, It also facilitates tuning of associated policies prior to actually stopping the application execution. This capability lets IT managers see the potential impact of application whitelisting and should be used to set expectations throughout an agency to minimize negative impacts.

5. Draw a line in the sand.

As noted above, achieving effective application whitelisting across a large agency is neither trivial nor quick. Compiling a list of all the applications permitted within the enterprise from day one of the production capability is often not feasible. Instead, consider drawing a line in the sand with the current footprint of executable software. Essentially serving as a “temporary whitelist,” this baseline can be used to ensure no additional software is permitted into the enterprise while the current software is being assessed.

6. Confirm senior leadership support.

Application whitelisting means that any software currently in use but not approved will be prevented from executing, and any business processes dependent on such software will also be disrupted. Therefore, full support from senior leadership is critical to make sure efforts to address unauthorized software continue while also forcing non-compliant business unit applications and processes to take appropriate remedial actions.

7. Engage stakeholders early.

Because of the potential for stopping certain business processes from functioning, it is critical to identify all stakeholders and engage them early and often. Any actions that result in the blocking of some application or other communication previously permitted will almost certainly result in complaints or escalations if stakeholders were not engaged and given advance notice. A robust communications plan will help ensure stakeholders understand and support the efforts and are not surprised by any results.

8. Prepare for emergency requests.

Good planning and communications go a long way, but there will always be exceptions where someone did not or could not plan appropriately, requiring execution of an unapproved application for a critical and time-sensitive business need. A detailed plan is needed for such situations but this can vary depending on the level of senior leadership support and risk tolerance for an organization.

Although the team responsible for maintaining an application whitelist should generally be engaged –  even for emergency requests during non-business hours – resource constraints may limit this option. As an alternative, emergency firecall accounts and processes could be established to allow help desk or other personnel to provide temporary support of emergency requests if the risk to the agency is acceptable.

Following these recommendations should help agencies gain control of unauthorized software and realize the substantial benefits of an environment where malicious or unauthorized binaries are no longer able to wreak havoc. Particularly in large government environments, it is imperative to keep in mind that the details to address this issue within each organization are unique. One size does not fit all, and appropriate approaches and timelines can vary significantly based on organizational structures, maturity, existing processes and risk tolerance.