Information Security Management Handbook, Sixth Edition (2012)

DOMAIN 4: APPLICATION DEVELOPMENT SECURITY

System Development Controls

Chapter 15. Application Whitelisting

Georges J. Jahchan

Last year (2010) has seen the proliferation of some high-profile pieces of malware that targeted attacks aimed at specific organizations and were initiated for a specific purpose that varies from sabotaging industrial machinery (reportedly, uranium enrichment centrifuges in Iran) to wide-scale industrial espionage.

By several security experts’ accounts, StuxNet is by far the most sophisticated piece of malware ever launched, targeting what was at the time four as yet undisclosed vulnerabilities in the Windows operating system and relying on stolen digital certificates. Experts believe it was purpose-built to cause physical damage to machinery controlled by Siemens’ SCADA industrial control software. StuxNet is also able to mutate and propagate from one system to another across a network. For example, in an industrial system in which SCADA controls the flow of oil to the parts of a machine that need it to function, StuxNet could be programmed to instruct SCADA to stop the flow of oil while a machine is running and simultaneously feeding sensor signals that all is OK with the flow of oil, potentially leading to physical damage or outright destruction of the machine. While typical malware size is quite small (tens of kilobytes), StuxNet is hundreds of kilobytes in size and is widely believed to be the work of a government sponsored team of programmers, with significant time and resources at their disposal.

Another big story of 2010 was Operation Aurora, which by the accounts of the targeted software publishers (Google and Adobe among others) went on for months. It is widely believed to be the work of Chinese hackers. Operation Aurora exploited an undisclosed vulnerability in the Internet Explorer browser.

Theoretically, the targeted sites or systems were protected using conventional (blacklist-based) antimalware technology. Application whitelisting vendors claim that such attacks would not have been successful had the victim systems been protected by a properly configured application whitelisting solution.

Antimalware technology has relied on identifying known bad or suspicious bit patterns in files to prevent malware from exploiting vulnerable systems. Herein lies the problem. Tweak a known piece of malware and the malware is likely to evade blacklist detection. In this cat-and-mouse game, antimalware vendors released an estimated 6 million new malware signatures in 2010. Come to think of it, on average, a new signature was released every 4.5 seconds, round the clock. There is little in terms of assurance that signatures will be deployed onto systems before malware targets them. New malware is being created and spreads faster than antimalware vendors can put their hands on the code and create its signatures, and end users download these signatures and distribute them where they are needed—on the endpoints they are supposed to protect.

To address the variations in malware code, heuristics have been introduced. However, with strong heuristics enabled, it takes more CPU cycles to inspect content, and the technology is prone to false-positives.

Behavior rules were added to improve detection capabilities, again these cause additional processing overhead and are prone to false-positives.

In a bid to improve the time to detect, Trend Micro is now proposing their Titanium Suite, a cloud-based antimalware solution with client components installed on end-users systems. However, blacklist-based technology still falls short of achieving the levels of protection required by businesses and individuals.

In a Q2 2010 evaluation of 10 corporate endpoint security suites from various vendors (AVG, ESET, F-Secure, Kaspersky, McAfee, Norman, Panda, Sophos, Symantec, and Trend Micro), NSS Labs found their effectiveness at stopping malware at download time varied between 35 percent for the worst performer and 88 percent for the best performer. In other words, in the best of cases, 12 pieces of malware out of every 100 that knock on a system’s doors are likely to evade blacklist-based antimalware defenses. The consequences of such evasion can range from a mere inconvenience to catastrophic.

Furthermore, according to the same NSS Labs tests, it took on average between 4.6 hours and over 92 hours for the vendors to block malicious Web sites. Ample time for such sites to spread malware.

In this context, a new endpoint security line of thought has emerged: instead of blocking the known or suspected bad (blacklist), why not allow only authorized code to run and block everything else, regardless of its nature. Enter application whitelisting technology.

The theory goes that by only allowing known good applications and blocking everything else, application whitelisting technology can effectively protect organizations against unknown (zero-day), or new variations of known malware, in addition to preventing execution of unauthorized applications, and a host of other collateral benefits.

In other words, among its benefits, a properly configured application whitelist acts as a strong first line of defense against unauthorized applications, which includes malware—known and unknown as well as applications not explicitly allowed by policy. As of the writing of this chapter, technology solutions were available from a handful of vendors: Bit9 (Parity Suite), CoreTrace (Bouncer), Lumension (Application Control), McAfee (Application Control), Microsoft (AppLocker—on Windows 7 and Server 2008 only), and Sophos (Endpoint Security and Data Protection).

In this chapter, the author will get into the details of managing application whitelists and solution deployment in a corporate environment, taking one such application with which the author is thoroughly familiar—Parity Suite from Bit9—as an example.

Architecture

The solution architecture consists of the following components:

Server software provides central file security management, event monitoring, and a live inventory of files of interest on all agent systems.

Agent software, which runs on servers, desktops, and laptops, monitors files and either blocks or permits their execution based on security policy settings. It also reports new files to the Parity server.

Knowledge service compares new files introduced on computers running the agent to a database of known files, providing information on threat level, trust factor, and software categorization.

Solution Architecture

Server

Server software runs on standard Windows computers. It can be run on a dedicated system or as a virtual machine. The server is used to manage policies, including software and device approvals and software bans, and to provide visibility into events and file activity on computers running agents. The console, a convenient Web-based user interface, provides access to the server from any connected computer.

The server database uses Microsoft SQL server, either on the same machine or on separate hardware. Key data is accessible outside of the solution through a series of published views in the database that are part of the Live Inventory SDK.

Integration with active directory: Named users, computers, and groups may have already been defined using Microsoft Active Directory. The Server can take advantage of the existing Active Directory environment to set access privileges for users of the console, assign security policies to computers, provide user and computer metadata, and designate certain groups or users to be able to install software (and have it automatically approved) on managed computers.

Agent

Agent software running on Windows client computers monitors file, device, and registry activity and communicates with the server when necessary. Even when disconnected from the server, the agent continues to enforce the last specified bans and security policies it received. When a disconnected computer running the agent reconnects, the agent receives updates from the server and communicates relevant file activity during the time it was off the network. Parity agent runs silently in the background until it blocks a file, at which point it displays a message to the computer user that explains why the file was not permitted to execute. Depending on the file state and the agent’s security level, the agent may also let the user on the client computer choose to run an otherwise blocked file.

Parity Knowledge Service and Trust Rating

Parity Knowledge is a Web service, hosted by Bit9, that helps identify and classify software discovered in your network by comparing it to an extensive database of known files. Based on weighted analysis, Parity Knowledge service further assigns a threat level (malicious, potentially malicious, unknown, or clean) and a trust rating (0–10 or unknown) to each file. Parity server can include this information in its live file inventory so that you immediately know the threat status and other key information about the files on your systems. With Parity Knowledge enabled, any file in the Server inventory can be analyzed to get whatever information is available.

A file’s trust rating goes beyond the information available from an antivirus scan. It is based on a series of factors, including how long and on how many computers the file has been seen, whether it has a trusted digital certificate, and the results of scanning by multiple antivirus programs.

For example, a file that scans as clean on antivirus programs has a trusted digital certificate from a known publisher and appears on many computers for a long period of time might have a Parity trust rating of 10, highly trusted. Another file that also produces clean antivirus scans but has only recently been seen is on very few computers and does not have a digital certificate might only get a trust rating of 2, low trust.

Because the operational model of Parity is policy-based, we shall start by delving into the important aspects of policies.

Security Policies and Levels

Parity policies are named groups of protection rules shared by targeted groups of computers running the Parity agent—every computer running the agent must belong to a policy. You create policies based on your security and organizational requirements. For example, you might base policy membership on functional group (marketing, customer service), location, or type of computer (laptop, desktop, server).

Each policy has its own Parity agent installer, which is automatically generated on the server when the policy is created. Each installer automatically assigns a policy to each agent it installs. However, if so desired, the Parity server can assign a policy based on Active Directory data for the user and/or computer running the agent, each time the computer with the agent connects to the server.

Policy Settings

Policy settings define the way you want Parity to manage a particular group of computers. There are three categories of settings:

Basic policy definitions: These include the policy name and other descriptive information, whether computers in this policy allow agent upgrades, whether live file inventory is activated for these computers, and the basic security level (the Mode and SecCon) for the policy. Modes and SecCons are described in more detail below.

Device settings: Device settings control the way a Parity policy treats removable devices. Different rules control read, write, and execute operations on devices, and devices can be designated as approved, to be treated differently than nonapproved devices.

Advanced settings: Advanced policy settings control whether computers in a policy have certain file types blocked, whether files installed by specially designated “trusted” users are allowed to execute, and whether special treatment of certain directories is enabled. The possible values are Active, Off, and Report Only.

Modes and SecCon Levels

The SecCon (security condition) level in a security policy controls whether pending files (applications that may be unidentified and that have not been approved or banned) are allowed to execute. The availability of different SecCon levels enables you to choose a setting for each policy that suits the security and user requirements for the group of computers associated with that policy.

Parity offers three different modes of operation: Visibility and Control, Visibility Only, and Agent Disabled. The available SecCons for each mode are described in the following table.

Following are screenshots of the relevant screens:

Computers (managed endpoints)

Events

Customizable executive dashboards

The initial deployment is either with the Agent Disabled, which essentially deploys the agent software with no policy, or in the Visibility Only mode. As soon as a Visibility policy is deployed on the endpoint or the endpoint is moved from Agent Disabled to Visibility Only, it is initialized. The initialization process involves a comprehensive scan of all files on local file systems on the endpoint, the computation of hashes for all the files found, and forwarding of that information to the server. Depending on the number of files found on the endpoint, initialization takes at least an hour and is resource-intensive on the endpoint, the network, and the server. It is recommended that the deployment be performed outside business hours and be in phases so as not to create overload conditions on the Server or on the network.

Once initialization is complete, the hashes of all files found on the system are stored in the database and are marked as in the Visibility only mode. As soon as a Visibilicontrol is enabled, these executables will be allowed to run. Any files that find their way onto the system postinitialization will be marked as be marke and depending on the applied policy, may be allowed to run (Visibility Only and Monitor), generate a prompt on the endpoint upon execution (Block and Ask), or are prevented from executing (Lockdown). In all cases, creation/execution events are reported to the console.

Contrary to blacklist-based technology that searches for known bad bit patterns and attempts to identify suspicious software behaviors, application whitelists rely on:

Hashes (MD5, SHA1, and SHA256) that uniquely identify each executable, regardless of its file path, file name, or network location. Computing a file hash takes far fewer CPU cycles and less memory than does real-time signature pattern matching, especially in the case of large executables. The hash function is run once when the program is executed. A whitelist check involves computing the file hash and looking it up among the file hashes stored in the whitelist database. If it is not approved, the type of enforcement policy being applied to the system will determine the behavior.

Screenshot of Block Message on Endpoint while in Lockdown Mode

File state, whitelisting, and blacklisting
Several key feature groups work together in Parity to secure managed computers. At the heart of this security capability is the ability to classify files according to their state. Groups of security rules, called policies, can control how different groups of computers treat files in different states. This section describes primary file states—approved (whitelisted), banned (blacklisted), and pending—and how they can be changed.

Global file state
The server maintains a central database of unique files (determined by hash) for all executable files tracked on managed computers running the agent. Each file has a global state, which indicates how it is to be treated on Parity-managed computers.

In addition to its primary global state, some files in the database have a more detailed global flag that may identify the source of its approval or other decisions made about it. For example, a file with a global state of “Approved” in the File Catalog may have a global flag of “Installer” on the File Details page.

Screenshot of File Details

Local file state
While the Parity server keeps a global state for a file, each instance of a file on a computer in the Parity network has its own local state. Files that are globally Banned or Approved have the same local and global states. Files with a global state of Pending may have different local states. In particular, it is possible to locally approve a file by a variety of methods, as long as that file was not globally banned. The local file state can be viewed on the Files on Computers tab of the Files page.

File approval methods
Software approval ensures that users of computers running Parity agent can freely install and run known-good applications regardless of the Parity settings and control level enforcement level in effect. Approving files, often called “whitelisting,” also can reduce the time devoted to tracking files that you are not concerned about. Parity supports several complementary methods for approving software on computers:

When there is a need to preapprove applications to run on all computers, trusted directories, publishers, or updaters can be designated to automatically generate approvals.

Individual files can be approved by hash, either for all computers or by policy.

When there is a need to approve software for installation on selected individual computers, either designate trusted users (or groups) to perform installations, or choose one of Parity’s local approval methods.

File ban methods
In Visibility and Control mode, Parity allows banning of specific files from executing on all computers, or on computers associated with specified policies. Files can be banned using the following methods:

File-name bans ban execution of named files on either all systems running the Parity agent or on all systems in specific policies.

Hash bans prevent files matching a unique hash from executing regardless of the file name used. They are enforced on either all systems running the agent or on systems in specific policies. More than one file can be banned in a single operation by importing a file containing the list of hashes that are to be banned.

Custom rules
In addition to the variety of ban and approval rules described previously, Parity provides other ways to protect computers, allow needed software to run, and optimize performance.
Custom rules allow the designation of one or more paths, either to the directory or the file level, at which certain activities are allowed or blocked. In some cases, this involves changing the state of files, but in others it simply allows, blocks, or disables certain behavior on a case-by-case basis without any global rule changes. Custom rules can be used for File Integrity Control, to create a Trusted Path for installation directories, to reduce tracking of files in directories known to be safe or not of interest, and for many other purposes you can configure. These are covered in detail in the Custom rules section next.

Trusted directories are network shares used to distribute authorized applications on endpoints. They relieve security administrators from the burden of having to allow each individual deployment package to run.

Trusted Directories Screenshot

Trusted publishers: Allows packages digitally signed by selected vendors to run without intervention and have the installers and all resulting files automatically added to the whitelists.

Trusted Publishers Screenshot

Trusted updaters: Allows updates to select applications to run without prompt, with the update packages and resulting files being automatically added to the whitelists.

Trusted Updaters Screenshot

Trusted users: Users who are allowed to bypass policy. In a high security scenario, no one should be allowed to bypass policy, but that feature can be enabled in exceptional situations.

Trusted Users Screenshot

Custom rules: Some custom rules take precedence over other (noncustom) rules and settings, including bans and approvals:

A custom rule that specifies an Execute Action takes precedence over all other rules. For example, if a custom rule specifies that a specified file is allowed to execute, that file can execute even if it is banned by hash. If a custom rule specifies that a file is blocked from execution, it will be blocked even if it is globally or locally approved.

A custom rule that blocks writing takes precedence over other rules, whether “Block” is chosen on the Write Action menu or “Prompt” is chosen and a user clicks “Block” in response to a prompt on an agent computer.

A custom rule that has a Write Action that approves (Approve, Approve as Installer, or choosing Approve on the agent computer for a Prompt rule) does not take precedence over other rules that block writing. Currently, this is limited to the case in which a Device Control rule blocks writing, regardless of any custom rule that would allow it.

Each Parity policy includes an “Enforce custom (file and path) rules” setting permanently set to “Active.” One can click on this rule to change the notifier message that appears on agent computers when a custom rule blocks an action.

For computers in Visibility Only policies, custom rules that would block a file have no effect, although they still generate events. Similarly, rules that approve a file do change the file state, but in Visibility Only, this has no effect on file execution. “Ignore” setting on the Write menu (see below) is effective in Visibility Only.

Custom rules use cases:

Prevent modification of specific folders or files.

Define folders or files for which file execution is always allowed.

Control behavior when an attempt is made to execute a file matching the rule.

Control behavior when an attempt is made to write a file matching the rule.

Specify folders or files to avoid tracking (execution will still be monitored).

Define custom behavior for controlling file execution, creation, and/or tracking.

Device Rules

In addition to the monitoring/execution controls mentioned above, removable storage devices can be controlled globally in policies and individually in Device Rules.

Device Rules in Policies

Parity policies include a series of Device Control settings. The following table shows the effects of different choices for these settings. The effect of the settings on CD/DVD drives differs from the effect on USB devices with nonremovable media. Burning a CD or DVD does not constitute a “Write” operation. If you want to block burning of CD/DVD media, ban the media-burning software application.

Screenshots—Device Rules and Device Details

Device rules use case:

Policy-based fine-grained control over removable storage devices.

Registry Rules

Parity provides the ability to create registry rules, which control what happens when there is an attempt to make any changes at specified registry paths. Rules can apply to specific users and/or processes.

Registry rules are ranked on the rules page in the order by which they are evaluated. If a path location matches two different rules, the highest ranking rule (i.e., the one with the lowest number) takes precedence and the lower-ranked (higher number) rule has no effect. You can change the ranking of rules if you decide that you want one of your rules to be considered before its current position.

Registry rules use case:

Monitor or prevent changes to critical registry keys or trees by user and by process.

Registry Rules Screenshot

Registry Rule Detail Screenshot

Software Meter

Software metering enables tracking the number of times users run specified files. When a meter is created, it specifies the file to be tracked. Each time the specified file runs on a computer, its execution is recorded. Configurable reports enable the display cumulative execution events by time of execution, user, computer, and policy. As many meters as needed can be created and centrally managed (view reports, edit, and delete) in one place. Monitoring begins almost immediately after the meter is created.

Use cases:

Gather data about how often applications are used.

Determine which computers are running an application.

Locate computers running obsolete versions of software for upgrade.

Retire older versions of an application.

Alerts

Alerts notify administrators of important Parity-monitored changes on the managed endpoints as they occur. When conditions specified in an alert are met, the server notifies in the following ways:

E-mail notification: E-mail notification about the event(s) triggering the alert goes to a list of subscribers.

Alerts page banner: All currently triggered alerts appear on the Alerts page, highlighted with a bright-colored banner.

Home page and other dashboards: All currently triggered alerts appear in the Triggered Parity Alerts portlet, which is part of the default Parity Home Page and can be added to other Dashboards.

In addition, Parity keeps an Alert History for each alert, and this history is modified as alerts are triggered and reset, keeping details for events of current significance and eliminating the lowest level details of past alerts.

An alert can be reset when there is no longer a need to be notified about it. This removes the alert warning banners on the Alerts and Home pages (and any dashboard with the Triggered Alerts portlet), and if automatic resends of alert e-mail are enabled, it stops those. If the conditions that triggered the alert occur again, another alert will be triggered.

Alerts can be viewed, created, and edited through the Alerts page. In addition, several system alerts are built-in.

Alerts Screen Screenshot

Malicious Alert Detail Screenshot

One alert of particular interest is the file propagation alert. The file propagation alert is triggered when a file is first seen at a frequency that exceeds a user-defined threshold. The threshold is set as a percentage or as a number of managed endpoints per period of time set in minutes, hours, days, or weeks.

File Propagation Alert Screenshot

Reporting

Event Reports

The Events page provides access to all recorded events related to activities, including files blocked, pending files executed, system management processes, and actions by console users. Parity updates event data in near real-time for connected computers, with minor variations due to event volume and network latency.

There are predefined reports, available on the Saved Views menu, custom views can also be created and saved using existing views as templates or starting with the full events table. For any event report, the time window can be changed for the time for which results are needed, without having to create a new Saved View.

Events Screenshot

The Events page displays up to 200 events per page for a user-specified time period. The number of events displayed can be adjusted in a table by changing the rows per page parameter in the bottom right of any report.

File Reports

The server keeps track of all files on all connected computers running the agent, in near real-time. Because of this “live inventory,” files or groups of files matching a name, hash, or any other criteria available in the database can be quickly located. Even if a computer is offline, its most recent file inventory is available.

This section focuses on the Find Files page, which is preconfigured for file searches and opens by default with a filter that allows a search for a file by name. Filters can be added to fine-tune the results, and searches can be saved (Saved View). File searches can be exported to a comma separated values (csv) file suitable for importing into spreadsheets.

Saved Filtered Find Files View

Baseline Drift

Parity’s Live Inventory of files on the network gives the ability to measure baseline drift, the difference between a baseline of files and the current files on a specific target. This difference is available as a baseline drift report that can be viewed either in detail in dynamic tables or as graphic charts on a Parity dashboard. Baseline drift reports provide not only simple numbers of file differences but also risk analysis related to those changes.

Drift Values Explanation

Other key factors in determining the total drift and risk reported in a baseline drift report are:

File filtering: The security administrator can decide which files in the baseline and in the target participate in the comparison. For example, the preconfigured reports compare pending files, but ignore Banned or Approved files—this behavior can be changed. There are several other file categories that can be included or excluded from the comparison.

File comparison method: By default, if a file hash found in the baseline is also found anywhere in the target, it is considered a matching file, and no drift is reported. This is called the File Content method. The alternative is the File Location method, in which the same hash in different locations in the baseline and the target is considered a drift.

There are two preconfigured baseline drift reports: Drift of all computers, and Daily drift of all computers. These are enabled by default, the results of these reports can be viewed shortly after the Server and Agents are installed, and the initialization is completed (the inventory of files on systems). These preconfigured reports also provide a useful way to view the configuration options for baseline drift and view their results in a report. Existing reports can be copied and serve as a starting point for new reports.

Drift reports use case:

Assessment of risk resulting from changes to files on computers.

Conclusion

Sensible use of an application whitelisting solution significantly reduces the likelihood of successful exploitation of vulnerabilities in applications, mitigates the risk of malware gaining a foothold on systems, improves reliability and reduces administration costs by enforcing compliance with corporate policies, and helps pass security audits.

Parity also provides an unprecedented insight into which files are (or were) present on systems—even if they were later deleted, and their prevalence, trust, and threat factors provided by the Web-based Knowledge subscription.

The low CPU and memory footprint of the agent enables safe deployment on heavily utilized servers. The absence of signatures maintains effectiveness of protection in the face of new or zero-day malware. It allows instant selective or global banning of applications that do not meet corporate policies. The agent protects endpoints on and off the corporate network. In Lockdown mode, it supplants antimalware real-time scanning engines, rendering them redundant. It is, however, not recommended to completely remove the antivirus application except on point-of-sale systems and ATMs. On desktops and laptops, it is still needed to conduct periodic malware scans.

Device control rules provide granular control over the use of removable storage devices. Registry rules enable protection of critical registry keys, either by denying changes or providing controlled channels for changes.