• 52% of IT professionals surveyed are considering discontinuing anti-virus
• Anti-virus’ days are numbered
• Microsoft prepares for biggest patch Tuesday Ever – Endpoint security has never been worse

That, however, is not the topic of today’s post. Today I want to talk about application whitelisting as a compliment to, or alternative for, antivirus and the importance of managing additions and updates to legitimate applications – with the least amount of operational friction.

For the purpose of this post, I will make the assumption that most IT professionals are dissatisfied with their current endpoint security, are looking for alternatives, and that application whitelisting is on the short list of possibilities. This is certainly the case at Gartner Group if you look at their recent postings like this one.

If application whitelisting is one of the possible approaches to addressing the current sorry state of endpoint security, what is holding it back? Typically, there are two primary objections to application whitelisting that we encounter. First, IT professionals are worried about baselining a whitelist off of an existing system for the fear that malware will get whitelisted. Taking a step back and looking at this objection, it seems to be more evidence that companies should look to move to whitelisting as soon as possible. If you truly believe that your existing systems are overrun with malware, then you should move to stop the bleeding immediately and employ whitelisting to prevent any further infections that antivirus is simply incapable of preventing. Then existing infections can be identified and eliminated through the use of signature based solutions like antivirus. Eventually you will reach a steady state of clean systems.

The second objection is that managing changing applications is simply too cumbersome and that relying on an uber cloud-based white list is essentially another form of signature based security and will be too operationally disruptive to be effective. That is where we believe a “trusted change” system becomes an essential element of all application whitelisting solutions.

Managing change shouldn’t only rely upon the master whitelist, but rather should flexible enough to allow change from multiple points within the organization. For example, a good application whitelisting solution should be able to define a number of avenues from which change can take place. This could include defining your points of accepted change; for example software vendors where digitally signed applications and updates are accepted, trusting a software distribution application, a specified trusted user, or software in a specific trusted network share. Essentially, application whitelisting must encompass the way users work with their PCs today and ideally should result in minimal disruption to their productivity and routine.

Trusted change is the backbone of CoreTrace’s BOUNCER solution and we feel strongly that application whitelisting solutions must easily enable legitimate additions and changes. Those solutions that do not have this capability will languish on single purpose servers and never to see the light of day in the general enterprise where they are so sorely needed.

John, makes a reference to the Government’s Cash for Clunkers program and I think the analogy is an appropriate one. There are many desktop security companies that are heavily invested in the way things are today. Their recurring revenue model is based on subscriptions to a bloated blacklist. Their security solutions work on a find and clean model and not a preventative model. The likelihood that they will “start over” on security is slim to none and more likely they will keep trying to add a fresh coat of paint, change the tires and oil and patch things together with new additions. The problem is the engine is broken and won’t last much longer.

The problem was evident again this month when we witnessed the largest theft of credit cards in history. Over 130 million credit cards were stolen by Albert Gonzalez and his accomplices using in many cases exploits that have been around for years. One of the primary exploits was a SQL injection attack against a vulnerability that has been fixed for some time and is definitely preventable.

This attack and the ongoing proliferation of botnets has led to a number of articles indicting everything from PCI DSS standards to overall security practices. An article last week in Forbes looks to offer advice in the article “Safeguarding Against Data Breaches.” It does a good job of describing the problem, but the solution falls short, oversimplifying a very difficult problem.

Sadly, advice is not enough. There are too many attacks that penetrate organizations that take security very seriously to think that it is a common sense and education issue as suggested in the Forbes article. Desktop security is broken plain and simple. The problem lies in trying to create a known signature for every piece of malware and attack that might be out there. It’s simply not feasible anymore to identify an attack, create a signature, distribute it to customers and have the customers update their systems before the attack affects them.

This company was founded on the premise that desktop security needs to fundamentally change. It is far easier to define what is allowed to run on a computer and block everything else than it is to identify and prevent every known attack. Last month we outlined what we think needs to happen to transition organizations to a more rational approach to desktop security, application whitelisting.

• Protect – First we must baseline our systems to prevent any new infections
• Purify – We then transition into a process that cleans our existing systems of any residual malware
• Manage Change – A new approach to desktop security requires that people can still use their computer productively and allow for new and updated software

Next week we will be publishing the results of our Anti-Malware Survey of IT Professionals and it is eye opening to say the least.

In two weeks we are also hosting a webinar on the results with Aaron Goldberg, vice president and principal analyst for Ziff Davis Enterprise, and Diane Hagglund, founder and principal of Dimensional Research.

The trojan itself is highly dangerous, targeting both online banking credentials as well as personal identity information. It is funny that this trojan is so prevalent, because it was identified by security vendors like Symantec back in early 2008. The problem with today’s malware is that they simply don’t stay static. Each trojan, virus or worm morphs into thousands of variations that avoid traditional blacklist antivirus.

The hard facts are that blacklist antivirus simply provides no protection at all. By the time you react and update your signatures, another version of the malware is on its way out the door. Identifying infection and cleaning up the mess is important, but it simply isn’t the type of protection that people need for their valuable IT assets. It is time for everyone to begin a process to move toward a system that can prevent infection in the first place. As we highlighted in our Rational Transition to Whitelisting series of posts, we think the answer to that problem is application whitelisting.

“Unlike other concerns, such as extreme weather, security-related threats can be driven by malicious actors who intentionally manipulate or disrupt normal operations as part of a premeditated design to cause damage. Cyber-related threats pose a special set of concerns in that they can arise virtually anytime, anywhere and change and emerge without warning.”

He continues:

“While the industry deals with some physical security events, like copper theft, on a regular basis, other technical threats or hazards, such as electromagnetic pulse and space weather, are a concern and will require careful consideration to develop appropriate and effective mitigations. Cyber threats to control systems are still evolving and are not yet fully understood. The potential for an intelligent attacker to exploit a common vulnerability that impacts many assets at once, and from a distance, is one of the most concerning aspects of this challenge.”

One of the reasons why cyber attacks are so concerning to those who are responsible for our energy grid, is that these types of attacks simply do not fall within the design for reliability and disaster recovery that the energy systems were built for. Reliability of our energy grid has been of paramount importance since its inception and as such it was designed to be able to respond to a system failure without interruption of power to the homes they served. Unfortunately, this disaster preparedness focused on recovering from the failure of one system and using other systems to compensate during that time, this is often referred to as N-1 preparedness. In a cyber attack, there is the potential for widespread disruption of these same systems creating an N-x problem where more than one system is down and the plan for compensation by other systems will potentially not be adequate.

Mr. Assante goes onto describe that one of his top priorities is preparing the operators of the energy grid against new and not fully understood cyber attacks. To address this to some extent he has developed a notification process where operators of the grid can be immediately notified of a pending threat. He calls out their efforts around the Conficker worm:

“NERC’s recent work to alert the industry of the Conficker worm, including lessons learned on mitigation, involved the issuance of one recommendation, two advisories, and an awareness bulletin over the span of six months. These efforts significantly contributed to overall preparedness and awareness of the underlying vulnerability and cyber threat.”

Unfortunately, it has been proven time and again, that a simple after the fact notification, while helpful, can simply not defend in the long term against serious threats that can cause widespread disruption to critical systems. After the fact technology and processes simply don’t work.

More than ever it is time for protective systems that can prevent threats without ever having to know about them. This was the focus of a recent blog entry titled “Endpoint Protection – A Case For a Rational Transition to Whitelisting: Step 1 Protect.” Protecting critical endpoint systems against unknown threats is possible today with application whitelisting and should be a top priority.

It should be no surprise that adoption of application whitelisting is being led by industries who have the most critical security needs. In the case of satisfying NERC CIP requirements, application whitelisting goes beyond meeting the letter of the regulations, it accomplishes the spirit of the regulations by dramatically enhancing the protection of those systems that are critical to the continued functioning of our energy grid.

Of course this will not happen overnight. There have been significant investments made in existing blacklist antivirus technology as well as the operational processes to support this technology. These processes exist not only to update and manage blacklisting, but also support the necessary ongoing updating of operating systems and applications that are vulnerable to new malware attacks. We believe that application whitelisting is the logical next evolution of desktop security and that there are three critical steps that will take place for an organization to adopt this technology. We have addressed the first two in previous posts:

• Step 1 Protect – Organizations desperately need to implement a system that can protect their systems against zero day attacks.
• Step 2 Purify – Once their systems are protected, there will be a purification process that eventually cleans all existing systems of any infections, unauthorized software, or malware.

The third step, change management, is addressed in this post and has been the single biggest obstacle to widespread adoption of application whitelisting. The ability to completely lock down a system has been around for years. IT professionals have long been able to define and restrict applications that are allowed to run on a given system to an explicit approved list. Clearly, this would solve the problem of malware infections, since by definition malware couldn’t run since it wouldn’t be on the list. So why hasn’t it been adopted? Simply put, a security system that doesn’t allow for the inevitable change that must take place to the application environment on a PC is doomed to failure.

The answer to the question posed above, why don’t organizations just lock down their PCs, is that to date the cure has been worse than the disease. Given the significant costs of rampant malware infections and the costs of the measures being taken to protect against them, detect them and clean up after them, that is saying a lot. A simple lock down system may prevent new malware infections, but unfortunately it also causes so many problems for IT management and users who need the ability to support updated and new applications that its costs are prohibitive.

An intelligent change management process is the sine qua non for a successful application whitelisting solution. Once an organization has achieved a transition to protected systems and have purified those systems, they must have a process with the least amount of organizational friction for both IT and end users to update and add applications to their PCs.

At CoreTrace, we have invested heavily in providing a system that can deal with the changes that must occur in a way that is transparent to end users and easier than the current desktop management overhead for IT managers. We have patents pending on our “Trusted Change” process and let me outline some of the key principals:

• First, IT defines change construct.
  IT organizations have ultimate control to set policies around when an application change is allowed. These policies are driven by the needs of the users combined with risk tolerance for those systems. Examples of these trust constructs are allowing updates or additions of applications that are signed by trusted vendors. This could also include allowing changes through a trusted process or from a trusted share directory.
• Second, provide a secure infrastructure for change.
  It is critical that the infrastructure to support these changes is secure itself from being spoofed or circumvented. Online criminals have already shown their ingenuity at bypassing existing security systems. The application whitelisting solution should be highly resistant to attacks and bypass.
• Third, allow users to operate seamlessly within the construct.
  User acceptance of new security technology is essential to its success. If there is too much disruption of user productivity the application whitelisting solution will fail. Once a construct for approved change is defined by IT, users should be able to work within that construct without interacting with IT.
• Finally, the solution must accommodate a variety of applications.
  Over time a good application whitelisting solution shouldn’t limit itself to .exe or DLL files, but should encompass all applications that could pose a risk to a PC such as ActiveX and embedded applicaitons.

If you are considering application whitelisting you ought to spend a significant amount of your time addressing change management and what the operational impact of the solution will be for the systems you are protecting. Beware of solutions that simply rely upon another central list. Whether this is a centrally managed “cloudlist” where a vendor approves all the whitelist applications, or the more dangerous “crowdlist” where individuals submit applications and those applications are scanned for infections they both come with security and operational risks. Centrally maintained whitelists can compliment application whitelisting solutions for both cleanup as well as helping with change management, but they should not be the foundation for approving application changes and they must not create any additional friction or latency for the users. If a valid application is not yet on the list, it can introduce unnecessary operational friction with IT and end users. On the other hand, it is also possible for some of these lists to get malware on the list and give a false sense of security during a change approval. Most essential is the construct to define approved changes and to deal with anomalies that rarely come up individually.