Happy April Fools!

If you believe what you read in the press, then you may be surprised to learn that even after all the hype surrounding the Conficker worm, the UK Houses of Parliament are today reported to have been infected.

Allegedly computers used by MP’s have been affected, and according to Chanel 4 News, staff have since been told not to use unauthorised computers on the network, implying that previously this was deemed acceptable.

The Houses of Parliament have opted not to comment on this incident, but C4 claim to have seen an email sent to MP’s outlining the above.

It’s almost beyond belief that three months after Microsoft patched the exploit, and after all of the column inches devoted to Conficker, such a high profile institution could be caught out in such a way. Assuming all is as reported, it’s shocking that unknown computers are allowed to access the network, especially given that the managed computers seem to have been unpatched and quite possibly not running up-to-date AV. I’m not convinced that this one can be pinned on the credit crunch!

The bad news for those still infected is that Conficker is due to attempt a “call home” on 1st April, although many within the industry are speculating as to what the outcome will actually be. The payload may not necessarily be downloaded on April 1st; the infected computers will simply attempt to contact one of the thousands of call home domains. If the domains aren’t registered for a few days or weeks, nothing will happen. Even then, the payload may not necessarily execute immediately.

If you’re still in the unfortunate position of trying to clean-up after Conficker, then next week may be a little nerve-racking. One way of minimising the impact of any potential payload is to make sure your computers can’t contact those call home servers to download it in the first place.

Microsoft ISA users are fortunately able to download and run a VB script that will configure ISA to block outbound requests for Conficker, although a quick Google search for a few other firewall vendors didn’t reveal any similar tools. If your AV vendor bundles a client firewall, then now could be a good time to make the most of it. At the very least, it could help prevent re-infection while your administrators chase Conficker around the network.

And of course, you can always call our support department if you need some friendly advice.

ISA Conficker Script:
http://blogs.technet.com/yuridiogenes/archive/2009/01/01/blocking-conficker-through-isa-server-tmg.aspx

Conficker Removal Tool (from Sophos, free but requires registration):
http://www.sophos.com/products/free-tools/conficker-removal-tool.html

Lessons Learned

It’s not especially controversial to say that if you don’t implement an effective patch management strategy, and ensure your endpoints run up-to-date and enabled Antivirus, you’re sitting on a network security incident time bomb.

We all know and understand this, yet the IT press reports high profile incidents on an almost daily basis. A review of an outbreak that affected three major London hospitals in 2008 concluded that the infection by the “Mytob” worm was “entirely avoidable”.

The infection, which affected Barts and the London NHS trust, “rapidly infiltrated” the trust’s 4,700 PC network resulting in a “very small number” of non-urgent operations being rescheduled. It seems that the Trust reacted well to the outbreak, and that “patient safety was not compromised at any time”, and at no point was confidential patient information put at risk.

The root of the issue, it would seem, was that although the Antivirus software was regularly updated, the updates did not reach all PCs. Additionally the software was found to be incorrectly configured on some PCs, leaving a “back door for the virus to infiltrate the network”. The source of the virus was not made entirely clear, but it was said to have been “introduced accidentally” and without malicious intent.

The fact the incident was well handled by the Trust, and that at no point was the well-being or confidentiality of patients put at risk, reflects positively on the IT personnel involved in responding to the incident. The report highlighted the fact that the trust had “well-rehearsed emergency procedures” in place, and ensured that key clinical systems continued to function.

What can we learn from this? Firstly, don’t rely on a reactive approach to systems such as Antivirus and patching. A daily manual check of the Antivirus server’s console isn’t good enough anymore, instead we need to restrict a devices network access the moment it has an issue.

Secondly, as highlighted by the above report, having a procedure in place for responding to incidents is critical. Instead of wasting crucial time planning how to react, the London NHS was able to respond immediately and ensure the continued smooth running of their organisation.

The report is available via the Barts and the London NHS Trust website (bartsandthelondon.nhs.uk)