By now the effects of the WannaCry ransomware outbreak have been widely published and discussed on the internet. There is also plenty of blame and finger pointing circulating
in news articles and discussion sites, with neither Microsoft, the NSA nor IT organizations (particularly at hospitals) emerging unscathed. However, regardless of blame or the causes for this particular incident, discussion of prevention only addresses one part of the equation. What about dealing with the aftermath of the incident and minimizing its impact? In this blog post, I’ll focus on lessons learned for mitigation and recovery after an incident has occurred, from three perspectives: incident inevitability, architecting critical infrastructure, and application design for resiliency and recovery.
The reality is that no software or computerized system will ever be 100% bulletproof. Ironically, the ransomware attacked and infected Windows computers through a vulnerability that Microsoft had created a fix (MS17-010) for back in March. How is this possible? It was a vast number of computers worldwide that were unpatched and vulnerable months later. This clearly speaks to the need for automation and continuous vigilance of assets by IT security teams. But the core lesson can be found in dealing with the consequences of an attack. In terms of IT Service Level Agreements (SLAs) around data availability and system uptime, this attack resulted in what I would classify as a “disaster”. Disaster Recovery and Business Continuity procedures are a critical part of IT and security management. Ransomware only works when the data it encrypts is valuable and irreplaceable. A well planned, executed, and (importantly) routinely tested disaster recovery plan that includes timely backups and restoration would ensure that hospital systems can recover quickly from a crippling attack or system unavailability, with minimal or no data loss. All too often disaster recovery plans and procedures are put in place but not tested, at great risk to an organization. Critically, this incident also highlighted the fact that certifications and audits (such as ISO 27001 or HIPAA) might not be enough to truly ensure system security and availability without strong day-to-day diligence in applying security best practices by active security teams.
Architecting Critical Infrastructure
Healthcare falls under the definition of critical infrastructure (at least in the US), and this incident underscores the effect of disruption on patients and care providers, with patient lives literally put at risk. While most critical infrastructure such as power generation and utilities are centralized and require a breach to affect core IT services for maximum effect, this incident showed that healthcare institutions operate somewhat differently and are particularly vulnerable at the edge (such as point of care terminals), which generally takes more effort to secure, keep updated, and recover. Central IT assets supporting critical infrastructure tend to be managed well, are regularly backed up, and up to date on security patches. As we have seen, applying the same high standard of preparation and response to recover service and availability at point of care terminals is just as important – the entire system is only as strong as its weakest component.
Designing for Resilency and Recovery
The attack vector of this incident is of particular interest to those in healtchare IT. This attack targeted edge devices such as point of care terminals and connected medical devices. Because many key files were encrypted and rendered useless on these systems, the software running on them were effectively disabled, even though most patient data and medical records likely weren’t directly affected. The effect was actually a denial of service (DOS) attack for healthcare organizations. This is a case where a centralized architecture, such as SaaS software (hosted remotely or on-premises) would have been more secure and less vulnerable to disruption when delivered through a browser. Malware would not have had access to any patient data or critical patient files. Another option is for Disaster Recovery and Business Continuity plans to provide for alternate, centrally hosted and remotely accessible backup software, deployable in these situations. Most hospitals already allow secure, VPN and remote desktop based solutions for EHR access by healthcare professionals when outside the hospital network (such as from home or outpatient settings), so key infrastructure is already available and deployed. It’s only a matter of formulating the plans and being prepared to react quickly.
The healthcare industry needs to brace for and prepare for an increasing number of attacks and security incidents resulting in denial of service. Though it is vitally important to invest in protection that stops attacks before they happen, it is equally important to invest in mitigation and recovery plans. Disaster will strike, and institutions will be judged by how quickly they are able to recover and restore service when it does.