It seems that whenever we see an article about the NHS we see the words “crippled” and “in chaos” but last week we added “targeted” to the list due to the widely reported malware attack WannaCry. Failures in the NHS are always big news and WannaCry is no exception, however with responsibility for the breach, and how such a breach should be handled sitting so firmly in the headlines, it has been suggested that the response of the security industry has been to use the incident as an opportunity to sell services and products.
Does the infosec community understand the complexities of this kind of organisation well enough to advise effectively?
When asked for comment on attacks such as WannaCry, many security experts are quick to blame organisations for not patching their systems. In the case of WannaCry the vulnerability (MS17-010) was known and a patch existed for many months before the ransomware hit, therefore is it the responsibility of an organisation to make sure their systems are updated to protect against this style of attack?
On the other side of the argument, some blame the NSA for not disclosing the vulnerability to Microsoft before a weaponised exploit was created and the malware, being relatively rudimentary, would not have been able to spread without an advanced NSA level payload. Edward Snowden has been quoted as saying that if the NSA had “privately disclosed the flaw used to attack hospitals when they found it, not when they lost it, [the attack] may not have happened”.
Whilst most of those arguing blame do fall into one of these two camps, one group the infosec community is failing to attribute at least some level blame to is ourselves. The infosec community has traditionally been very reluctant to accept that security is not black and white or yes and no. Excluding ethical considerations, security is about allowing organisations to understand their risk and develop controls to help manage that risk.
Those blaming the organisations being attacked often fail to understand why patching may not be so simple. Once the limitations are understood, the security industry should engage with organisations to develop controls that will protect against future attacks.
Although patching is an important part of network security, patching is not the only way to protect a network and should not be the only message from the security community. In fact, even a network that is fully patched and up to date would be vulnerable to similar malware should a zero day vulnerability (a vulnerability not known to the vendor) be used. Whilst patching should be part of a complete security plan, there are many reasons why organisations may have not have been up to date before the WannaCry ransomware hit and often this is of no fault of their own.
The argument around patching seems to have been disproportionality levelled at the NHS, who have been widely criticised for the use of Windows XP. Though this criticism is found to be supported, the number of devices within the NHS that reportedly use XP has fallen to 4.7%. Where the NHS may indeed have legacy software running, much of this will be powering very specialised and expensive equipment used to save lives and therefore not something that can easily be upgraded. By accepting and understanding this limitation, the NHS were able to understand their risk to cyber attack and make choices to put patient safety first, even at the expense of a perfectly secure network.
Those shouting “patch everything” do not understand the realities of the infrastructure it is our job to protect, especially (like in the case of the NHS) certain criteria make patching impossible or prohibitively expensive.
It is our opinion that the security industry should work with organisations to understand their likely risk profile and help develop controls that work within their risk appetite. Selling security based on fear of the next attack, or based on the unattainable “gold standard” of network security will only work towards further isolating the security industry, ultimately making it more difficult to create secure systems.