I’m sure I can’t have been alone in my frustration at the fallout from WannaCry – or in my annoyance at the impact it had on the NHS as one of its casualties. This is after all a service that’s available to all UK residents; an equaliser that cares for us from cradle to grave, offering virtually every type of treatment, from the relatively mundane – vaccinations, blood pressure checks, etc. – to the daily performing of life-saving procedures.
As for the many commentators who said more should have been done to prevent such an attack, they were of course, right to an extent – but that’s only half of the story. In reality, the NHS is stretched to capacity and while its clinical staff do a sterling job caring for the nation’s health, spare a thought for its IT departments, also striving to do more with less, and actually doing a great job under the circumstances.
Putting emotions to one side, the industry is awash with commentary on how easily this could have been avoided with patching. Patching is indeed, a critical part of the solution but in the highly complex environment that is the NHS, being 100% fully patched 100% of the time is impossible.
The reactions we saw in the face of WannaCry were many and various, but there were reports of affected NHS trusts being forced to disable or shut down their systems in response. Unfortunately, this self-inflicted denial of service probably caused more disruption than the malware itself.
Prevention is not the cure
Sadly, there appears to remain an insistence and focus on prevention strategies – in other words: “how do I stop this from happening again?”
This response however, completely misses the point. The fact is, you can’t stop it happening again. If history has taught us anything it’s that it is impossible to prevent these types of incident, meaning any prevention-focussed security strategy will fail at some point. What the NHS needs to do now is take stock, reflect on recent events and understand how it can be better prepared to rapidly identify, contain and remediate future cyber incidents.
There are few (if any) reports of NHS trusts having used network intelligence to support either their decision-making or response actions. Rather, the reaction once again appeared to be disabling systems to contain the threat, followed by manual patching to any places where systems hadn’t previously been patched.
Understand your IT assets
Many of our customers have already made significant investments in Cisco LAN technology, which has a range of capabilities that could have been utilised in the face of WannaCry – and can also be harnessed during other attacks. Making the right investment however is one thing, but the true value of any IT expenditure lies in understanding and exploiting its capabilities.
Visibility
We have two fundamental capabilities that can be leveraged when faced with a WannaCry-style outbreak; Visibility and Segmentation.
The WannaCry malware self-replicated across the network, but by using Cisco Netflow customers would have identified the tell-tale traffic patterns that point to a device being infected. This visibility would have enabled rapid identification of where the outbreak might take hold, enabling containment and remediation actions to more accurately pin-pointed.
Netflow could also have helped indicate the location of ‘patient zero’; that is, how the infection was first brought into the environment. Netflow is baked into virtually all Cisco core networking products, and even the most basic collation of the flow of events would have helped. Coupled with Stealthwatch, customers would have also received security alerts as WannaCry attempted to spread.
Segmentation
Once the malware took hold, it could move unchecked throughout our customers’ networks. Yet with a properly segmented network, customers could enforce access-control policies between zones that can be rapidly updated to contain threats like WannaCry.
Early on in the attack, it was clear that WannaCry was spreading via the Microsoft Server Message Block (SMB) protocol, but with appropriate segmentation and access-control, administrators could have rapidly implemented policies to block traffic between zones, containing the threat and avoiding the preventative mass shutdown of IT systems.
What next?
As I said earlier, the NHS now needs to take stock and try to understand how WannaCry was able to take hold and have such a dramatic impact. Next, review which tools you already have in place that could help contain future threats, consider what you need to do next to safeguard your system, and review your existing security and business strategies.
Finally, why not check out my recent podcast on this very subject – and feel free to contact us for further advice.
Authors
3 Comments
Thanks for that Mark. It’s interesting isn’t it, because I suppose SMB was never meant for the huge networks that are now possible. It was designed with networks of 100-ish maximum Windows PCs and a bunch of printers in mind.
The solution, as you say, is segmentation and patching where possible. Many years ago we used to segment by using vlans to lock-down public PCs and staff PCs, as well as a DMZ for internet visible services. All internal systems were entirely invisible from the Internet, and SMB was not routed at all between networks. That seemed to work quite well, even when machines weren’t up to date and patched, which as you rightly say – sometimes just isn’t an option.
@Steve. Appreciate the comment and yes, I’d agree. SMB is being used in ways that it was never designed and like all legacy, it’s a tough thing to get rid of once it’s in place.
Segmentation is a big part of the solution to my mind but it’s also about enforcing that segmentation. Most networks will have VLANs in place to segment things but it’s probably not done based on security ‘zones’ and is even less likely to have any sort of access-control policy enforcement between VLANs. It’s tricky to do this well, and can become a huge management overhead. Software defined segmentation technologies (Cisco TrustSec etc.) can really help as it’s far more dynamic and takes away a lot of manual overhead.
Great blog Mark.