In Updates We Trust.

Remember my recent post on Application Control?

Well, after its publication I was flooded with all sorts of e-mails with comments thereon. Of particular interest were several cynical messages claiming something like, “The application control idea is sooo simple, there’s no need for any highfalutin special “Application Control” feature. It can be dealt with on-the-fly as applications are installed and updated.”

Yeah, right. The devil’s always in the details, my cynical friends! Try it on the fly – and you’ll only fail. To get application control done properly – with by far the best results – you need three things besides that “it’s easy” attitude: lots of time, lots of resources, and lots of work going into implementation of a practical solution. Let me show you why they’re needed…

On the surface, it’s true, it could seem Application Control was a cakewalk to develop. We create a domain, populate it with users, establish a policy of limited access to programs, create an MD5 database of trusted/forbidden applications, and that appears to be it. But “appears” here is exactly the right word: the first time some software updates itself (and ooohhh how software today loves to update itself often – you noticed?) the sysadmin has to write the database all over again! And only when that’s completed will the updated programs work. Can you imagine the number of angry calls and e-mails in the meantime? The number of irate bosses? And so it would continue, with every update into the future…

To the rescue here comes running a mostly unnoticeable but mega-useful feature of our Application Control – the Trusted Updater. It not only (1) automatically updates installed programs while simultaneously bringing the database of trusted software up to date, it also (2) keeps track of inheritances of “powers of attorney” attracted to the updating process. The former is fairly straightforward and clear, I think. The second… let me explain it a bit.

Let’s take an example. While performing an update, some software launches, let’s say, a browser (for example in order to show the user’s agreement), and transfers to it its access rights. But what happens when the update is completed? Are you twigging what I’m getting at here?… Yes – in some products the browser keeps the inherited rights until it’s restarted! So until then it could perform an action that is actually forbidden according to the security policy – for example, to download something from the Internet, and, more importantly – to run it. What’s more, the browser gets the ability to call on other programs and give them the enhanced rights of the updater. Oht-Oh!

Turns out a single update could bring down the whole security system through incorrect access rights’ management during the update process. Scariest of all is that this isn’t a bug, it’s a feature!

Anyway, back to our Trusted Updater. What it does is take full control over the update: as soon as the process has finished, it restores the rights back to what they were before the update – for the whole chain of affected programs. Another handy trick is its knowing beforehand which updaters can be trusted – there’s a special category for them in our Whitelist database. And should a sysadmin want to, he or she can add other updaters to this category with minimal effort but with a good addition to the level of the network’s overall protection from all sorts of sly backdoors.

Ok, let me back up a bit and try make things clearer than crystal. Let’s look at four different possible scenarios for controlling applications and keeping track of software updates.

Right, the first scenario – to control applications’ installation and updating with a home-brew, on-the-fly solution as described in the very first example above. Fail. Since an average computer has up to ten regularly updated programs installed – this isn’t an option.

The second scenario – to use an out-of-the-box product with a constantly replenished database of trusted (whitelisted) software. This is at least better than the first scenario – since the sysadmin can create rules for groups of software (as well as add new groups) and not for specific checksums (which we learned long ago have a tendency to quickly change). Ok, let’s say we permit the whole of the “accounting programs” category to be used only by the accounting department, and let all the software of this kind to update itself. But what happens if it turns out that the whitelisting database doesn’t have info on some specific program or other? And as a result the quarterly reporting doesn’t get sent to the tax authorities in time? Again – angry calls/mails/fines and plenty of impromptu sorting out needed. Well, with our product (featuring a whitelist-database of 300 million-plus files, with a million being added daily) such a likelihood is tiny. Then again, it’s not zero. Still, with competitors things are a lot worse… Anyway, let’s have a look at the next scenario.

The third scenario – to use a product providing comprehensive control over updates, like Trusted Updater. At first glance this would seem to be the ideal scenario. But there’s a nuance here too. Application Control, even with its clever updater, is not sufficient – especially if we’re talking about IT Security in the broad sense. Suppose some (long-whitelisted) software suddenly picks up a malware infection (you never know, the cyber miscreants could have broken into the site of the developer from which the updates are distributed).

And so we come to scenario No. 4: Application Control + Trusted Updater + categorized whitelist + control over the chain of updates + the rest of the anti-malware arsenal, like the antivirus scanner and proactive protection. And this whole orchestra needs to work in complete unison – so that, even if the baddies put some malware into an updater, there’s an extremely high degree of probability it will be purged at the next stage of protection. And as a matter of fact, this fourth and best way is precisely what we’ve got implemented in our Endpoint Security 8.

Actually, Trusted Updater is just one of the many useful features in our Application Control that distinguish it not only from home-brew on-the-fly solutions but also from competitors’ products. For example, we’ve perfected the concept of dynamic whitelisting – involving a regularly replenished database of trusted programs (in a recent test, it covers 94% of corporate software). We categorize all software (for example, “browsers”, “games” – in all, 96 categories). Plus sysadmins can replenish existing, and add their own new categories. There’s also automatic checking of programs for vulnerabilities, inventorization of applications, full integration with endpoint protection, and much more besides.

Overall, the product has turned out to be both delicious and powerful. I do hope this post has explained matters sufficiently – so you can protect yourself and your companies’ systems – with zero headache!