Sasser and Yet More IT Incompetence

I agree in general but don't forget that many places are infected despite proper firewall setup because of things like laptops and VPNed home computers. It's amazing how often politics interferes with internal security measures - I've heard more than a few accounts of places where it took a major outbreak for the security folks to get permission to install patches even if some users whined about having to reboot.

Well… there is an argument that laptops that are connected to an insecure network should (at the very least) have their own independent software firewall, as should home machines with access to a corporate VPN. In just the same way, in fact, that better IT organisations usually insist that Windows systems that connect to the corporate network must run antivirus software, even if they are employees' own home machines.

Obviously there's a policing issue there, so this kind of thing isn't necessarily failsafe, but it's always possible to fall back on the threat to sack employees whose negligence affects the company network. Keeping your job is a good incentive, I find :-)

I do realise that in many cases just a firewall isn't enough—and, in fact, neither is antivirus software, since AV software is reactive rather than proactive—but I'd bet good money that it would have prevented the problem in nearly all the cases that have been highlighted by the press.

Sasser doesn't spread on 139, and it uses 9995 and 5554 as a backchannel as well. I guess it's a good thing you don't run the firewall - or you'd be fired!

Note that the MS and most of the AV providers data on the sasser worm have been incorrect or incomplete at times, and it's important to use all available information and some discernement and testing if possible.

Large institutions are not dealing with this as a simplistic issue. The time it takes to deploy a patch to a globally distributed workforce, some of which connect only every three weeks, is longer than in a mom&pop shop or home situation. A patch like the one that addressed sasser - 14 days before sasser arrived - also made some major revisions to the operating system. In a large enough user population, with enough applications running - applying a patch like this will cause some business disruption. In some cases that disruption is worse than the disruption of the threat itself.

There are lots of avenues into a large corporate network. Vendors working on site, RAS/VPN, extranet business partners, field offices with their own internet presences. Generally the IT folks are identifying risks and proposing techincal solutions to the business constantly, but only some of their suggestions actually get funded. Most organizations weigh risk against cost, and find it impossible to impliment every control that would mitigate every threat. Granted some organizations fund less than others, and some miss the boat on obvious controls at their disposal. But I would not be so quick to assign fault to IT folks using such a simplistic view of mitigation as a single firewall, when in reality the large institution is a much more complex animal.

Sasser doesn't spread on 139, and it uses 9995 and 5554 as a backchannel as well. I guess it's a good thing you don't run the firewall - or you'd be fired!

No, I'd still have my job, because all of those ports would be blocked unless someone had a need for them to be open. Just like the firewall I'm using, in fact. The report of Sasser possibly using Netbios came from one of the AV company reports, which I acknowledge may have been inaccurate. It's also important to point-out that there is more than one version of Sasser, and that different versions use different port numbers.

I realise that corporate networks are complex beasts, but that is no excuse for incompetence. They should already be locked down against this sort of thing, and shouldn't even require patches to fix this vulnerability because it should never have been able to get inside their networks' defences. This isn't a virus that spreads via document files, e-mail attachments or infected executables; it only spreads through the network.

I also understand that some IT organisations take a cautious line as regards application of patches, but protecting your network from Sasser doesn't require patches—although it's certainly good practice to apply them as soon as possible, taking into consideration any potential disruption that may cause. Sasser spreads in the background through a few specific ports; the only corporates who have a good excuse for being infected are those who had to have those ports open for some reason. Otherwise they should have been closed.

But I would not be so quick to assign fault to IT folks using such a simplistic view of mitigation as a single firewall, when in reality the large institution is a much more complex animal.

I don't see where I said that a “single firewall” was the solution to this problem, nor do I hold that view. In fact, I believe I used the word in the plural. I'm well aware that firewalls aren't the be-all and end-all of network or computer security. But the fact is that with a worm such as Sasser, a best-practice closed-by-default firewall implementation around the exposed borders of the network would have prevented any problem.

Here's a fictional scenario for you -
A traveling executive power user has one of the organizations laptops with him at a hotel. It's virus definitions are three days old - since he has not connected in that time. The hotel only supports wireless internet access, and the executive must VPN into the corporate network for a sales meeting with a major customer.
The laptop has a firewall/IDP system installed on it. However, the wireless NIC that is given to the executive binds to the network stack - which has a shim for the VPN clients virtual adapter - in such a way that the FW/IDP is bypassed.
The exec logs onto the hotel network, and in the course of picking up a lease and DNS server, is compromised by the Sasser worm.
The exec then logs onto the corporate VPN, which does not (and cannot) have 445 blocked - since this would prevent our exec from joining the domain and doing any work.
The exec's laptop now starts propogating the virus, as the high ports are also not blocked on the VPN filters - since they are used as return channels for RPC email transmissions.
Other systems in the corporate network have valid virus definitions, and are able to clean the offensive files. The problem though, is that since they are not patched, the attempt against the service crashes those boxes, and the virus product becomes essentially ineffective.

If this seems like a hypothetical "what-if" kind of scenario, please consider that it only takes one odd situation like this in a user population of thousands to create an internal problem.

Respectfully, I propose that "default deny perimiter firewall" approach cannot protect against possibilites such as this. This is why layered security is the new mantra.

/rgds

The laptop has a firewall/IDP system installed on it. However, the wireless NIC that is given to the executive binds to the network stack - which has a shim for the VPN clients virtual adapter - in such a way that the FW/IDP is bypassed.

So, what you're saying is, suppose someone has a faulty firewall, or a poorly written or badly configured NIC driver that binds to the network stack in the wrong place? What then? Well, yes, you could get infected.

But if you're in charge of IT and that happens, it's still your fault, because you supplied the wireless NIC and firewall software and should have tested that the firewall worked properly with the NIC.

Respectfully, I propose that "default deny perimiter firewall" approach cannot protect against possibilites such as this. This is why layered security is the new mantra.

Agreed, a perimeter firewall doesn't protect you from incompetence, in this case the fact that the laptop configuration wasn't tested properly. And I also agree that it makes sense to install firewalling, antivirus and intrusion detection systems within the network as well as at its borders, which improves your chances of not being affected and provides a level of mitigation if you are.

There are certainly situations where it isn't the IT department's fault that their organisation has contracted Sasser, for instance if an employee connects his own machine to their network without authorisation, disables the network security measures for some reason, or actually wrote the virus in the first place. That doesn't really change my position on those companies/organisations that were badly affected, because I doubt that that's actually what happened in the vast majority of cases, but it is a good argument for the layered security approach in that you at least stand a chance of minimising the scale of the any infection.

Well actually - the hotel supplied the NIC in my example - but, anyway - this has been a very interesting exchange!

I think I've learned that one's idea of how much control they actually have from a security perspective is directly related to the size of the enterprise they are involved with.

Thanks

I'm sorry, the travelling executive is installing unauthorised hardware and software into their laptop. Hmm, isn't that against company policy. It should be. Sack the exec!