|
||||||||||||
Part I of this two-part article will discuss the technology behind application "whitelisting."
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 article 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 whitelisting and provides a 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 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.
<
In the late 1990s, 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 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 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 have surfaced to aid 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, 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 circumvented 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 as 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. The 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 executables 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 produce the list and also many different technologies that may be involved. Experience using this technology 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 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 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 computer. 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 managing the whitelist itself. Events here include administrative actions like uninstalling and reinstalling the client on the computer. All these events can be used for client verification and reporting.
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 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 certificates. 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 in and applied on the client. Once the policy is in place, the channel is mainly 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 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. 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 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.
Part II of this article will deal with whitelisting's applications in SCADA and other energy industry security systems.