®

1

White Paper:

Application Whitelisting and Control Systems — A Good Match?

A new security technology has emerged that can provide a heightened degree of security for SCADA / control systems. Application whitelisting takes the traditional approach of the antivirus vendors and turns it 180 degrees. Rather than constantly maintaining a blacklist of malicious software that can get loaded onto a computer system, why not just maintain a whitelist of the authorized applications that are installed and make sure it doesn’t change?

This white paper is broken into three basic sections. With any given security technology, the strength of the solution is always in the implementation. The first section describes the short history of application white-listing and provides detailed perspective on how the technology works. The second section discusses the use of whitelist technologies in a SCADA / control system environment and how it can help solve some unique security challenges. The third and final section provides some perspective on how this technology is adapting to function in a constantly changing environment where software changes are always needed.

The Technology

In the late 1990’s, the concept of application whitelisting began to emerge. It became evident that the antivirus and anti-malware companies were having an increasingly difficult time keeping up with all the rogue software appearing on the Internet. Their products began to bloat with larger and larger databases of bad programs and the impact on the protected system became more intrusive consuming time and resources. What if the IT staff could install known software on a system and somehow keep it in that tested, functional configuration without allowing viruses and malware to run? The term applied to this security approach is application whitelisting. Rather than look for bad software off of a list of ‘blacklisted’ applications and stop it from running, this new technology looks at a list of good or ‘whitelisted’ software and allows only it to run.

The concept of tracking which software is installed on a given computer is fundamental to configuration management. There have been many configuration management systems over the years that simply used the file pathname and date to ensure the proper file was in the proper place on any given computer. Over time, additional technologies surfaced to aide in identifying the files and ensuring they have not been unintentionally corrupted. These began as simple checksums and have evolved into ever more complex cryptographic algorithms to include MD5, SHA-1, and SHA-2 families. The first step toward application whitelisting had begun, years before the concept was even introduced.

The Fundamentals

While there are many challenges to designing an application whitelisting solution, all solutions need to enforce a list of approved applications and then enable an efficient, IT-friendly change process for the addition of new and updated applications. Not including the management of the solution, which will be

TM

®

2

discussed later, each whitelisting solution must have three fundamental capabilities. First and foremost, it requires a way to securely and efficiently enforce the whitelist on the computer. Second, it must have a way of building or acquiring the whitelist of applications for any given computer. And third, it must have the ability to report any attempts to violate the security policy it is enforcing. These three capabilities together provide the security required to protect the computer, while at the same time reporting on system status.

In leading products, the whitelist enforcement mechanism is in the form of a tamper-proof client installed on each computer. It is very important that the enforcement provided by this engine cannot be circum-vented by either the local user or a malicious user or program with network access. To this end, the client installed on the computer must function in the operating system kernel. Through tight integration with the operating system, the solution is able to protect the system and have greatest efficiency — it essentially functions as part of the operating system rather than an add-on security feature. From within the operating system kernel, the client reads in the whitelist or policy, and ensures that only those applications on the whitelist are allowed to run. This process begins during boot time when the operating system is starting. The client is loaded as early as possible and then reads in the whitelist; it can then check all the execut-ables that loaded before and after itself to ensure they are all authorized. Once the computer is up and running, the client only performs checks when a new application or process attempts to start. From within the operating system, this is very quick with no delay perceived by the user. And because the whitelist is small compared to the massive blacklists in today’s antivirus products, the amount of memory, disk space, and CPU consumed by the client is also small.

The application whitelist is what makes this security solution unique. There are many different approaches to producing the list and also many different technologies that may be involved. Experience using this tech-nology has shown that no two computers are exactly alike, so there is rarely a match of whitelists across platforms. For example, orders placed with any major computer manufacturer for computers with identical specifications will have slightly different executables due to variations in chipsets on motherboards, network cards, video cards, memory, and so forth. Thus, the whitelist must be assembled for each computer indi-vidually. Leading solutions perform this automatically, scanning the computer and building the whitelist. As part of building the whitelist, the client collects a series of parameters to uniquely identify each executable file. These can include the pathname, digital digest, size, digital certificate if it is signed by the vendor, or other identifiers. As mentioned previously, it is the checking of some combination of these parameters by the client during application startup that determines the file has not been modified and is allowed to run. And finally, it is important the security of the whitelist itself is maintained. The whitelist is generally stored in an encrypted and digitally signed file that only the client can decrypt and verify.

Although a good whitelisting solution will prevent unauthorized applications from running, it is important to monitor and capture related activity from the computer. This activity can take a number of forms. The whitelisting solution can log attempts to overwrite, possibly trojanizing, protected applications on the com-puter. Likewise, it can log attempts to run unauthorized applications that may have been copied onto the protected system. The whitelisting solution can provide insight into whether this is a local attack initiated on the computer itself or if this is activity from across the network. In addition to basic policy or whitelist violation attempts, the solution logs administrative activity related to the managing the whitelist itself. Events here include administrative actions like modification to the whitelist, complete changing of the whitelist, and even major events like uninstalling and reinstalling the client on the computer. All these events can be used for compliance verification and reporting.

TM

®

3

Secure Management

Application whitelisting is designed and architected to be an enterprise solution. The fundamental capabilities previously described for an individual computer must be centrally managed to make it cost effective for deployment and long-term management. Fundamental to any enterprise management system today and with limited IT resources to run it, the system must be secure, intuitive, and require minimal training. More importantly, the system must be able to automatically — without requiring IT involvement — update the whitelist whenever new applications are added or existing ones are upgraded. Application whitelisting without the ability to handle change is simply lockdown.

Most application whitelisting systems use a dedicated central server or management appliance to maintain information about and communications with the endpoint clients. Command and control of the protected computers must be over a secure channel. This can be accomplished via SSL or a more secure and robust IPSec connection. The communications between the client software and the management appliance must provide some form of authentication, to ensure the client is not spoofed into communicating with a rogue management system. This authentication is typically performed using some form of digitally signed certifi-cates. In addition to management system-to-client authentication, the communications channel itself must be encrypted for confidentiality of information. This prevents easy interception and analysis of configura-tion changes, security events, and so forth, carried by the communications channel.

During the initial setup of the client, the vast majority of information exchanged will be whitelist related, where the list is assembled and the overall protection policy built and applied on the client. Once the policy is in place, the channel is mainly handling event information sent from the client and collected on the man-agement system. At the central point of the management system, events from all protected endpoints are collected and compiled. Because configuration of all clients is conducted from the central system, these events are easily logged as well. The management system can assemble both the security and configuration related event information into reports for additional analysis or to meet compliance requirements. Event or configuration information may also be distributed off of the management system in the form of syslog messages for compilation and analysis on other third-party systems.

The management system provides checks and balances on the protected endpoint systems. It contains a copy of the whitelist that is enforced by the client on the endpoint. It is constantly checking that the whitelist has not been either accidentally corrupted or illegally modified. When a laptop or desktop computer leaves the network for some length of time and then reconnects, the management system can verify the policy has not been modified while offline. Changes to the policy are made from the management system and pushed down to the client for enforcement on the endpoint. Good management systems allow policies to be built and queued for systems that may be offline. Once they reconnect, the policies are immediately updated. Policy changes are securely transmitted to the newly connected client, the whitelist is unencrypted, and the policy is immediately loaded and enforced by the client without rebooting the system.

The user interface on application whitelisting management systems can take several forms. Some use a web-based browser back to the system which can introduce security issues by itself. Dedicated console appliances are available to interact with the management appliance or central server. And some solutions offer remote desktop protocol (RDP), opening a secure channel between the management system and a remote computer or laptop. This final option provides the greatest flexibility while maintaining security for

TM

®

4

the overall system. The interfaces themselves vary greatly in terms of look and feel, but all strive for ease of use with an intuitive workflow.

Trusted Change

Application whitelisting solutions have been around for several years, but have had several hurdles to overcome. The first was the generation and management of the whitelist itself, which has been effectively solved. The second has been dealing with change. The descriptions provided this far in the paper have focused on scanning a system and then locking it down to prevent any changes from occurring. With the exception of some point-of-sale and other fixed purpose machines, computers are in constant need of updating. Even in a controlled environment like SCADA and energy systems, the systems must eventually be updated with newer applications or patches. Some of these requirements are driven by compliance and company policies, while others are required just for employees to perform their job. Historically, application whitelisting solutions have done an excellent job of locking down a system, but they were cumbersome when regular changes to the systems were required.

Whitelisting solutions are evolving to allow for authorized change while still maintaining security on the sys-tem. The term being applied to this process is “Trusted Change”. All Trusted Change is built on this simple concept: IT establishes multiple “sources of trust” from which users and systems can install applications or upgrades. As long as the users and systems receive the applications or upgrades from these trusted sources, the applications or upgrades can be automatically added to the whitelisting without any additional IT involvement. The additions are transparent and friction-free.

Trusted Change can take several forms. For example, the most common method to update systems in any Windows-based enterprise is from an update or configuration manager server. These can be operating system or application orientated, on periodic or infrequent basis. The application whitelisting client must be able to recognize the trusted updater and allow it to make dynamic changes on the protected com-puter. The whitelisting client must be able to update the application whitelist while monitoring the updates the trusted application is making. This process is very complex as there are many ways the updates are installed on the computer.

In a large enterprise, the IT staff may have approved applications on an internal server for installation on the endpoint systems as required. The applications have been tested for compatibility and are from a trusted source. In this configuration, the application whitelisting client must recognize the internal server share as a trusted location. Again, the client must monitor the applications being installed and update the internal whitelist accordingly so they may run.

A third example is that of a trusted user. For example, domain administrators or even local system admin-istrators may need to make changes to a protected system from time to time. The client must be able to recognize the domain administrator and track changes made to the system as per the trusted updater and trusted share examples described. Although the changes can be made, they will be logged both in the whitelist itself and in the event logging system to show what has been modified.

The application whitelisting solution must provide for all these options, while tracking and logging the auth-orized changes within the context of the allowed action.

TM

®

5

Security Perspective

Now that a detailed understanding of how application whitelisting solutions are implemented, it is impor-tant to ‘take a step back’ and understand where they fit into an overall security plan. The Gartner Group has a created a security framework that effectively outlines the various approaches an enterprise can to take to protect their systems. They take a two-dimensional approach, identifying the methodology of how an activity is detected and at what level the detection takes place.

The ‘how’ is based on three techniques — whitelisting, blacklisting, or behavioral. The security solution makes a decision on whether to let an activity occur based on these the techniques. Blacklisting has the drawbacks of resource consumption and inability to keep current as described earlier. Behavioral modeling takes an extended period of time to set up and is only effective on systems that perform the same set of functions day after day. These detection techniques do not work well in environments where the computer is used for projects that vary and use different applications. Whitelisting techniques are rapidly emerging as the most efficient and effective to use for maintaining both the configuration and security of the endpoint computer.

The ‘level’ at which the detection takes place is also based on three categories — network, application, or execution. Security solutions that make use of port, protocol, IP address and other network-based pa-rameters obviously fall into the network category. These solutions can make use of whitelists (e.g., only communicate with these IP addresses), blacklists (e.g., don’t communicate with these IP addresses), or even a behavioral-based list (e.g., IP addresses based on previous communications). Most application whitelisting solutions straddle the application and execution levels. Because they have the ability to build whitelists, and in some solutions remove unauthorized executables that are not on the whitelist, they exist in the application category. But for the most part, their detection or enforcement of security occurs at exe-cution time when an application attempts to run and is compared to the whitelist.

From this perspective of detection technique versus detection level, application whitelisting technology running at the execution level provides optimal real-time monitoring and security protection of the com-puter. It is by no means a complete solution, but is complementary to other technologies. Network or host-based firewalls will continue to protect systems from many kinds of attacks. Virtual private network and disk encryption technologies provide data confidentiality and protection. But application whitelisting fills a big hole in the overall security scheme, preventing unwanted system modification and unauthorized applications from running as well.

A Good Match for SCADA / Control Systems

SCADA / control systems provide some unique security challenges. Many are isolated and cannot access or download the latest antivirus / anti-spyware updates. Processing requirements often dictate they cannot be rebooted or can only be rebooted at specific times, so unplanned installation of operating system or application patches is not always feasible. Many of these systems are very old with limited memory and hardware resources available, so layering resource-hungry security applications on top is not an option. The ongoing stability of these systems is very important and they cannot be accessed via unauthorized means nor have their configuration changed without authorization. Yet as mission critical systems, it is im-

TM

®

6

portant they meet the Critical Infrastructure Protection (CIP) standards set forth by NERC for the electricity industry and similar standards in other industries.

A properly implemented application whitelisting solution can help with all these problems and more. The client and its associated whitelist have a very small footprint on the protected system. Typical size for most desktop-type systems are 10MB of memory and 20MB of disk space. Many solutions provide protection for older operating systems like Windows NT4, where patches are no longer being produced even though vulnerabilities exist. As mentioned in the technology section, the largest CPU processing impact occurs during system bootup and even then the effect is minor. Since most of these systems have all their required applications and services started on bootup, the application whitelisting solution has almost no impact on a continuously running system. Older systems with limited memory are now protected without the impact of an antivirus or anti-malware program running.

Once the initial application whitelist is built and applied to system, it will maintain that endpoint configuration until an authorized change is desired. The whitelist on the system can be changed without a reboot, and there are no continuous updates required. Protection by the application whitelist solution is enforced whether the system is connected to the network or not. Rogue applications and viruses simply won’t run because they are not on the whitelist.

The management system can be self-contained within the SCADA / control system environment if required. There is no outside connectivity needed for continuous updates as in the case of antivirus or anti-malware. The whitelist is maintained within the management system. Software updates to the management system itself can be brought in on CD and installed as needed.

The application whitelist solution can periodically scan the endpoint and remove an unauthorized application that may have been copied to the system, ensuring the pristine condition of the system is maintained. Compliance reports can show the system configuration has been maintained and any unauthorized exe-cutables that have been removed. The application whitelist solution ensures on a continuous 24/7 basis that the configuration remains constant and the system is in compliance.

Application whitelisting is an evolving and maturing technology. With the proper implementation, it can provide a heightened level of security on all systems, while not interfering with day-to-day operations. For SCADA / control systems, it is an excellent solution because of its highly efficient anti-malware capabilities, low performance impacts, and no need for system downtime or rebooting.

About CoreTrace

CoreTrace® is the pioneer of client-based application whitelisting. The company’s BOUNCER product has received accolades from customers, analysts, and leading publications such as InfoWorld, Network World, and PC Magazine for a simple reason — BOUNCER is the only solution that simultaneously stops all malicious and unauthorized applications while allowing users to easily add or upgrade approved ones via its patent-pending “Trusted Change” capability.

For more information about CoreTrace or BOUNCER, please visit www.coretrace.com.

  www.coretrace.com  •  P  512-592-4100  •  F  512-592-4101  •  6500 River Place Boulevard, Building 2, Suite 105, Austin, Texas 78730

© 2009 CoreTrace Corporation. Trademarks are the property of their respective owners. Rev. 20090505

TM