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.
More: The four scenarios of implementing for controlling software updates…
I’ve a real talent for photography. Beers, bulldog, and… JUICE?
