Application control, sometimes called application white listing, gives you granular control of which applications are permitted to run on each of your systems. Not only can this replace your A/V solution, it can keep rogue users and license issues in check as well.

How does application control work?

The concept is relatively straightforward. You identify which application you want each of your users to be able to run and the software takes care of enforcing that policy. One of the nice things about application control software is that you usually get far more customization capability than A/V. For example with many A/V solutions I may be forced to completely disable A/V in order to run an application listed as malicious in the signature database (say I’m an Auditor that needs to do port scanning or password cracking). With application control, I can usually get as granular as writing policies on a per user, per system, per location level (for example the Auditor can only run the port scanner from a specific system when its attached to one specific network segment). This is cool because unlike A/V I don’t have to disable the software, thus exposing myself to risk, just to simply do my job.

What to look for in application control software

There’s a couple of things you need to look at when evaluating an application control product. First, you need to look at how files are identified. Are they simply looking at file names stored in a specific location, or are they running multiple hash algorithms to authenticate the file is in fact properly identified? You also want to look at what’s involved with approving files for use and how the system deals with patches.

For example, one of my favorite products is Parity from Bit9 Software. They start by referencing a file database with over 6 billion entries and counting. While that might seem like overkill, think of how many file are involved if you just want to approve Microsoft Office for use and include all versions and all patch levels. All of a sudden 6 billion entries does not seem that far-fetched.

Unfortunately a file database is not going to be enough. You need some way to approve custom scripts and executables, as well as deal with real time patch files. For example Adobe checks for patches whenever a user launches the application. If they happen to do this right at the exact minute a patch is released, the patch file info will not yet be propagated into the file database. What Parity does is permit you to approve software based on it being digitally signed. For example we can create an exception that says, “If the file is not in the database but has been digitally signed by us or Adobe, it’s OK for use”.

Protecting Supervisory Control And Data Acquisition (SCADA) Networks

This is a very cool solution for control networks. For example those networks running the grid, municipal services, military stuff, etc., which are not suppose to be connected to the Internet. The lack of connectivity creates a catch-22. You’ve disconnected from the Internet to help protect the network but how do you update your A/V signatures with no Internet access? With Parity this is a non-issue. You simply digitally sign all software required on the control network, write a rules saying only digitally signed software can be executed, and you are done. No signatures or updates to worry about, just re-sign new software as you wish to deploy it on the network.

Parity has some other cool features as well like the ability to track file execution or the ability to control which removable drives can be used (by model, by user and by level of access). I’m starting to feel like a sales person however, so I’ll leave it to the reader if they want to learn more.

The dirty little secret

So why is it we are not seeing A/V vendors dump their signatures and jump on the application control bandwagon? I do not work for an A/V vendor so I can only speculate. I do however own stock in a few of them and will say that as soon as I see this trend occur I’m selling my stock. Think of it this way, where is the true cost in your A/V solution? Is it in the initial purchase price of the client, or is it in the monthly/annual subscription fee you pay for signatures?  Companies loooove reoccurring revenue streams because they mean predictable income with zero sales effort. Stockholders (like myself) love reoccurring revenue streams because “higher income + less up front costs = higher profit”. Note in the last example I discussed protecting a network without the need for signature updates. If users went this route it would have a serious financial impact on each A/V vendor’s bottom line.

The bad stuff

Now some caveats. You would probably want to use the file database if available, even if this means paying for a different subscription service. Digitally signing everything is fine on a network where the applications are infrequently changed (like SCADA) but in a typical corporate environment your job title would turn into “the Admin who’s always signing software”.

Also, application control simply regulates which applications are run on the system. Its not very helpful if an approved application gets whacked via a buffer overflow or the like. So patching is still a must and you will probably want to run a Host-based Intrusion Protection System (HIPS) to be completely locked down. Still, with application control you end up with a far more secure posture than sticking with that old carburetor A/V software.

Sometimes a technology outlives its usefulness. A good example is the automobile carburetor. While we have known the performance gains and fuel savings of multi-port direct fuel injection for decades, some (NASCAR!) still cling to the use of the outdated, yet familiar carburetor. Much the same has occurred with the technology to fight Malware. Anti-virus has become the “carburetor” of keeping malicious code off of our systems.

What is A/V software?

Anti-virus is still primarily a signature based system. In other words, we define a code pattern that we want to detect and then search memory or the hard disk for that pattern. This is referred to as “application black listing”, because we are defining the bad applications we want to keep off of the system.

Where do A/V signatures come from?

Typically an A/V customer will become infected and report the problem to their vendor. The A/V vendor can then generate a pattern, which permits their other clients to be protected from this same strain. Its also possible for the signature to get generated if the code is found in the wild prior to release, or if another vendor generates a signature.

What about heuristics?

Heuristics looks at suspect behavior and then white lists known to be good applications. For example we may check all attempts to create a user account on the system and then check to see if the application is a known administrator tool. This technology has some really cool potential, but it also has a number of flaws. The primary problem, and the reason heuristics sees little to no use, is the fact that its prone to false positives. Try to use a 3^rd party tool to manage your user accounts and the A/V heuristic engine is probably going to block it.

The business model of Malware

When anti-virus was first developed, Malware had two specific traits:

1. Malware distribution was slower than signature distribution.
2. Malware writers were mostly script kiddies attempting mass propagation.

Neither one of these items are applicable in today’s environments. Symantec states that in 2009 they are averaging a new Malware signature every eight seconds.   For F-Secure, this frequency is closer to a new signature every four seconds. Do you update youy A/V every 4-8 seconds? Does your A/V vendor even release a new signature file every 4-8 seconds? You see the problem. Even if you diligently update A/V every night, 11,000-20,000 new signatures and pieces of Malware have ticked by.

But let’s talk a bit more about item #2; script kiddies and mass propagation. Around 2001 or so I noticed a change in the Malware world. The folks who really knew what they were doing stopped doing mass release. Think about it, most Malware writers usually start when they are very young. When you are still in school and living at home, its trivial to release your code for free. At some point however you need to get a job and start earning some income. When you personally reached that place in life, what did you do? For most of us, it involves looking at what we are good at and trying to match that up to a high paying job.

So if you are good at writing Malware, where are the high paying jobs? Some possibilities:

• Extortion – Steal info and sell it back.
• Espionage – Steal info for a competing company, government, etc.
• Steal data with value in the wild – bank logon, credit card info, etc.
• Resell botnet and Malware services – Become a gun for hire. Typically spam distribution of DDoS.

While we still have some number of script kiddies doing mass propagation (think of them as Malware writers in training), the smart attackers have turned it into a profitable business model. When it’s a business model, the code of course has monetary value. This means an attacker will not risk mass propagation of high end Malware code. They are going to sit on it and only use it when there is the potential for a high rate of financial return. So we can’t count on the truly nasty stuff being mass propagated anymore. The stuff you need to worry about most is used in a targeted fashion.

Why does my A/V fail so often?

A couple of problems should be immediately apparent with the above model. To start, because we are black listing bad applications, the assumption is everything else is OK. If we do not have a signature identifying the application as malicious, we assume it is safe to run. This means that all Malware without a signature is free to infect the system. This model also assumes some level of acceptable losses. Typically there is a lag time between when systems get infected and when we get a signature to protect ourselves. This could be hours, days or in some cases even months.

Problems under the hood

One of the biggest issues with A/V software is the signatures. Most of us would not even consider purchasing a NIDS or NIPS which does not provide access to the signatures, but that’s exactly what you get with an A/V system. This leads to little to no sanity checking of signatures within the industry, as well as limited customization capability. For example I have yet to see an A/V vendor give me the ability to let my network administrator group run a password cracking tool from known to be secure machines. If I have any customization capability at all it is a tedious process to get specific applications approved for use, and even then enforcement is limited.

So where do we go from here?

With all these problems, its no wonder that application control (sometimes called application white listing) is starting to replace A/V software as the tool of choice for controlling Malware. I’ll get into application control in part 2 of this post.