Three weeks after the crippling Qbot malware struck at the heart of Royal Melbourne Hospital’s pathology department, the IT team is just starting to get to grips with the infection.
It is now looking for particular behaviours within the network that would signal an infection, rather than relying on known signatures.
Aside from the obvious issues we’ve already looked at (use of the unsupported Windows XP operating system and heavy reliance on signature-based anti-virus software), there are aspects of risk mitigation and best practice in incident management that may have been able to reduce the overall impact of this incident.
Know your risks
For starters, if Melbourne Health knew there was significant risk of infection via its extensive fleet of Windows XP desktops, the executive team should have invested in a security team that captures and manages these risk on behalf of the business.
As a component of IT service delivery, businesses almost always employ a security operations team, but forget about the role security plays in end-to-end service management.
Security is not only about operational activities; the outcomes of the security operations team must be driven by an information security management process that targets the operational workload on both strategic and tactical risk, otherwise it will be caught off guard.
By focusing on risk, an unsupported operating system, such as Windows XP, would be assessed as extreme and the risk would be escalated to the CIO and the board.
If losing a critical business function, such as pathology, is considered serious, mitigations should have been implemented to stop such a virus from taking hold.
If this had been considered an issue beforehand, their incident management processes would have identified the possibility of infection and implemented heuristic measures much more quickly.
Even with an old and unsupported operating system, such as Windows XP, there are mitigations that can ensure the risk of infection is minimised and resolution is timely.
Security teams should look at proactive and reactive measures that reduce risks to an acceptable level until strategic mitigations, such as platform upgrades, can be applied.
Tactical mitigations
Switching on personal firewalls and application whitelisting are two countermeasures that can significantly reduce the risks of viruses running wild in your legacy environment.
Contemporary malware often relies on signalling a command and control server for instructions on how to infect its target, as well as being told how to mutate and avoid countermeasures.
If you cut off its communication channels, you can minimise its ability to function, hence minimising the risk of it spreading. Endpoint firewalls have been built into Microsoft operating systems since Windows XP, however, you also have the options of using a third party firewall, since they are often bundled with the endpoint security suite from vendors, such as Intel and Symantec.
Secondly, you can tell your operating system which executable code is permitted to run on your endpoints – this is known as application whitelisting. In basic terms, if it’s not on the list, it can’t run; there goes the virus’ means of spreading and affecting operations.
Windows XP has native support for application whitelisting (called Software Restriction Policies), so consider this before you go out and invest in any expensive third-party software.
Hone your incident management process
When a new strain of malware affects your business, your security team will be scrambling to update the anti-virus signatures, recover business data from backups, close down network ports, and inform the business of the incident.
However, if you don’t have a well-tested incident management process that handholds the operations guys through each of the steps, things will be missed in the panic. It’s these gaps that the virus authors rely on to sustain their foothold in your business, so don’t give them that opportunity.
It’s worth designating a role in your security team as your endpoint specialist, with the remit of running a test lab during the initial steps of your incident management process, that way they can study the infection and see how it works.
Firewalls rules and IPS signatures can subsequently be created to introduce an element of heurists into your tactical (less than four hours) response plan, without having to rely on the anti-virus vendors providing the answer.
There are hundreds of great resources out there that show security teams how to build an incident response capability, however, risk mitigation should never be only about the response.
It must also incorporate the proactive assessment of the security concerns, suggesting the introduction of architectural, technical and process-related countermeasures that assist in containing these issues before they occur.
Security is not just an operational consideration, you need architects that understand security, risk managers and business continuity experts that understand business recovery, and policy makers and process engineers that ensure security is addressed holistically for the business.
Only then can you ensure that it doesn’t really matter which infrastructure choices the business makes, the security team keep them safe and operational.
