Whitepaper Abstract This white paper explains why application whitelisting is being rapidly adopted as a security and control solution for SCADA systems. In three major sections, the paper: Provides a detailed perspective on how application whitelisting technology works. Discusses the use and benefits of whitelisting technologies in SCADA and Energy environments. Explains how the technology is adapting to function in environments where controlled software changes are needed.

1. ®
TM
White Paper:
Application Whitelisting and Energy Systems — A Good Match?
A new security technology has emerged that can provide a heightened degree of security for energy industry
information and 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 and Energy 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 soft-
ware 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
discussed later, each whitelisting solution must have three fundamental capabilities. First and foremost,
1

2. ®
TM
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, net-
work cards, video cards, memory, and so forth. Thus, the whitelist must be assembled for each computer
individually. 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 execut-
able 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.
2

3. ®
TM
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 configuration
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
management 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 con-
figuration 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
3

4. ®
TM
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 system.
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 computer.
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
authorized changes within the context of the allowed action.
4

5. ®
TM
Security Perspective
Now that a detailed understanding of how application whitelisting solutions are implemented, it is important
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
parameters 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
execution 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 and Other Energy Industry Systems
SCADA and other energy industry computer systems provide some unique security challenges. Many are iso-
lated 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
5

6. ®
TM
systems, it is important 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 controlled energy 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
executables 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 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
6
© 2009 CoreTrace Corporation. Trademarks are the property of their respective owners. Rev. 20090505