Unless this week you never read the news, either in print or on the Internet, and you don't watch TV then you must have heard of sasser, the terrible Internet worm which is going to end civilisation as we know it.
It has been a phenomenal start of the week for the various news agencies, all falling over each other to try and find quotable quotes and disaster-struck companies to cite in their "end of the world" articles.
The lack of understanding of what sasser is and why it spreads has meant that nobody actually focused on the fact that this alleged disaster could have been avoided by pretty much every large company admitting to being hit with a modicum of effort and planning.
The reader could be forgiven for assuming that this will turn into yet another "timely patching is essential" article but would be mistaken. It is not patching that solves the sasser problem but appropriate network design.
Let us assume that all the companies cited in the BBC's article were real victims of sasser (I have no independent means of verification), if they weren't then they can serve as useful examples nonetheless.
Let us begin with a Finnish financial institution, Sampo, which allegedly closed 130 branches due to the sasser outbreak. The very first question you should ask yourselves is "how on Earth did the worm get to the branches?" followed closely by "surely they are not connected to the Internet?" followed by inevitable dispair. How can a financial instution possibly allow a cash-handling system to be connected to the Internet even via firewalls?
Alternatively, if the systems are not connected to the Internet, how did the worm spread? Well, the only possibility is that an infected system was placed on the same LAN because, suprisingly enough to some people, Internet worms can't jump out of one machine and magically appear onto another without them being connected. At which point the next question is "surely you can't just plug in any old system on the branch network?" and the answer to that can only be a resounding "yes" to explain the spread on their internal network.
The above example has nothing to do with Microsoft, patching or worms and everything to do with atrocious security policies. If you are a financial institution then your primary concern should be the preservation of the integrity of the network handling financial transactions not making sure that your employees at branches can read their Yahoo! mail or surf the web.
Are they alone? No, according to an article on the italian newspaper "La Repubblica", the italian Home Office ("Ministero dell' Interno") was affected. Of course we don't know the details: it could have been external hosts only (although their website is running Apache, normally a good sign) but still the fact that they were affected at all is not impressive. This is the ministry which controls the police force in Italy. Or what about Dubai International Airport? Australian Railways? Goldman Sachs? Deutsche Post and Taiwan's national post office reverting to pen and paper?
This is pure madness: how can a worm which spreads from the Internet and via the Internet possibly shut down the whole national post office network with branches reverting to pen and paper? There is only one answer: incompetence at the highest level.
Allow me to give an extreme example in the opposite direction: a friend of mine used to work for a bank in the City of London. This bank had a very simple policy: thou shalt not have physical access to anything connected to the network. If you wanted your Palm synchronisation program installed they would take your sync cable, bolt it to the machine, install the software and return it to you. If you wanted access to the corporate network from home they would install a leased line and an office-standard locked-down system. By locked down I mean: no floppy, no CD-ROM, ports at the back bolted and locked, case under lock and key. So yes, it is very expensive but they knew that there was no trivial way that someone could bring a worm into their network.
So it can be done at some expense but how much did a day of virtual shutdown cost to the affected companies, not to mention the public relations disaster?
In the midst of the ever so exciting war between Bagle and Netsky perhaps we should reflect again on the reasons for the success of Windows virii beyond the already discussed pointless existence of anti-virus software.
It is pretty clear that most virii are "successful" by subverting some part of the system they are about to infect and gain their entry mainly via social engineering. We can discuss to our heart's content whether the techniques are getting any better but the bottom line is that "oops, I clicked on the attachment" is still leading the pack.
Instead of a pointless long rant on anti-virus software let us consider how the problem could be at the very least mitigated.
Let us assume that we can't change certain software, for example Outlook. Why? Because the Microsoft group which writes Outlook, Office and everything else is separate from the underlying Windows OS group to a certain degree. So we need to work at the OS-level. Let us also borrow techniques from various places.
To begin with let us consider systrace (by Niels Provos, originally surfaced in OpenBSD) which verifies that the system calls made by an application match those defined in its "profile". Despite sounding difficult this mechanism is in production use on many OpenBSD and NetBSD systems. In practice this means that if your Outlook tries to write to the registry a systrace equivalent will terminate it and print a suitable message. Where are the profiles? Well, that's simple, when you certify your application to run on Windows you also submit a profile for inclusion with the OS release or you add it to your installation disk.
That is already a good start, what next? Well, systrace can of course be circumvented so we need multiple layers of defence. So let us consider a limited form of "real-time Tripwire". This is a system which would very simply protect a small number of files from alteration. Allegedly this is already available under Apple's Mac OS X and is a brilliant idea. Writing to these protected files can only take place if the user authorises it, not just with an "OK" button, which is often pressed without reading the warning which accompanies it, but by typing in the user's password.
Now what is really missing is some sort of "process watcher". This would simply check that any process started belongs in a whitelist of allowed processes, not just via the process name (too easy to falsify) but also via checksumming techniques, perhaps linked in with a full version of Tripwire and friends.
Of course there is a downside to all of the above: what about the so-called power-users? Well, they will complain about the "performance hit" to which the obvious answer is "buy a bigger box". It isn't like CPU power is an expensive factor in today's PCs. The only real losers from the above are developers: for them each compiler run will produce an executable which is not recognised by the system, which they will have to register and profile.
Are we there yet? Well, the tools are mostly there, the "miracle security cure" offered by Windows XP SP2 (aka: non-executable stack) is a start in the right direction but clearly not enough. It protects from buffer overflows but not much else and the current crop of fashionable virii are not going to be affected by it.
To tie it all together one could argue that the above functionality is really beyond a HIDS and closer to anti-virus system but there is a rather striking difference: all the above is based on white-listing, allowing only what is trusted, this means that you need not download new signatures on an hourly basis but on the contrary define what is acceptable and sit back.
As a final aside one should really mention the much-hated Trusted Computing Platform Alliance which got it all wrong by associating their work with so-called "Digital Rights Management". An overview is available on the Wikipedia, for discussions of how a much needed idea was turned into a nightmare see Ross Anderson's FAQ on the subject and the EFF's white-paper titled "Trusted Computing: Promise and Risk".
What is needed is a push, on the part of users, towards OS developers to implement some basic security features which would make life much easier for all of us.