For the last couple years, as anti-virus has continued to fail us with a detection rate often in the single digits, many have suggested that a better approach would be to not focus on the bad but on the good. The objective would be to identify what normal is and alert on everything that is not normal.  While that is still a tall task, it is often an easier one than to identify every possible piece of malware or attack method in existence.  Moreover, for many of our industrial control systems in operation, it would seem to be easier still as they tend to run constantly in a very predictable fashion. For example, no one operating a piece of software that controls turbines should be using that system to post to Facebook^®.  Consequently, the concept of application whitelisting has caught on with operators of industrial control systems.  There is also the added benefit that performance-hindering technologies, such as anti-virus software, can be scaled back if application whitelisting is implemented correctly.

However, deploying application whitelisting in a manner that proves effective is easier said than done.  While monitoring for what is normal may seem to give defenders an edge when compared to anti-virus technology that necessarily has to make signatures publicly available for all to see;  however, in highly predictable environments, hackers can often learn what normal looks like through vendor manuals and other publicly available information.  However, the hacker must still figure out how to make the attack look like normal activity, a challenge more difficult than coming up with malware not already in a signature database.  Additionally, asset owners can add more value to a whitelisting solution by defining what normal is uniquely for their organization, thereby making it harder for everyone except insiders.

But defining normal is only part of the challenge. Application whitelisting can only protect what the underlying applications and operating systems will let it. For example, once loaded in memory, software is changed slightly, making it problematic to restrict what can be run in memory and when someone should be allowed to modify the code already in memory. In their presentation at ShmooCon 2012, Curt Shaffer and Chris Cuevas highlight a number of vulnerabilities with various commercial application whitelisting products, describing how the controls can be circumvented when used with software platforms such as Java^®, Windows PowerShell^®, and Adobe^®products.  However, the presenters did make clear that application whitelisting was a step in the right direction but noted the need for diligence when implementing these tools.  We all are painfully aware that there is no silver bullet for security.  Nonetheless, application whitelisting, when combined with robust change detection technology, can dramatically improve the level of security for our critical infrastructure.

Facebook is a registered trademark of Facebook, Inc. in the U.S. and/or other countries. Java is a registered trademark of Oracle America, Inc. in the the U.S. and/or other countries. Windows PowerShell is a registered trademark of Microsoft Corporation in the U.S. and/or other countries. Adobe is a registered trademark of Adobe Systems Incorporated in the U.S. and/or other countries.