Preventing cybersecurity attacks isn’t easy. If it were, there wouldn’t be a continuous stream of ransomware attacks dominating news feeds, nor would the President of the United States feel compelled to issue Executive Orders on Cybersecurity or to declare that ransomware attacks be treated like terrorism.
While preventing cybersecurity attacks isn’t easy, avoiding one is a matter of luck, proper planning, or a combination of both. It is, after all, important to remember that attackers play by their own rules, and while some criminal groups have indicated they’ll avoid targeting health care providers, the collateral damage of an attack on critical infrastructure like access to fuel following the Colonial Pipeline attack can’t be ignored.
When it comes to defending against a cyberattack, I’d much prefer to be prepared and have a little bit of luck on my side than to have to pick up the pieces following a cyber incident. With that in mind, here is a blueprint to help prepare for a cyberattack whether you run a health system or are a technology provider to health systems, and ideally avoid being a victim of an attack altogether.
Have an incident response plan
Following any cyber incident, your teams are going to have to recover from the event while simultaneously dealing with patient concerns and possibly regulatory ones too. That isn’t the time to be creating a plan, or to be “winging it”. A good incident response plan will outline which teams are responsible for which tasks, and how leadership communication will occur. The plan should address everything from the mundane issues of log retention for forensic analysis through to public and regulatory communications. With the sensitivity associated with PHI, any breach will see detailed scrutiny, and eventually someone important will start asking hard questions about what went wrong. The last thing you want to tell them is that you don’t know because someone forgot to save critical data or that logs were overwritten.
Create a comprehensive threat model for your organisation
Threat models are arguably the hardest part of your preparedness plan. They force teams to think about gaps in their security processes and honestly review how those gaps might be exploited in an attack. Basic threat models tend to focus on protecting an asset, say a database, from external threats. Such models promote perimeter defences like firewalls, while ignoring the internal threats like compromised administrator credentials or the impact of social engineering. This is critical in clinical settings where clinicians might forget to logoff from a terminal or in-home settings where mobile devices or computers might have multiple users. If an attacker can access that database or patient records from behind the firewall, then that firewall is only protecting against one type of threat.
Comprehensive threat models understand that most successful attacks have multiple steps. Those steps form an attack pattern that an attacker might use to compromise your business. While it’s not always feasible to prevent every step in the attack pattern, it is possible to assign a risk metric to each step and then remediate the riskiest steps and monitor for indications of compromise with others. Without investing in the comprehensive threat model, any investment in threat mitigation isn’t all that different from a guess, and you never want to be in a situation where an attacker knows more about your weaknesses than you do.
Know all the software powering your business
All businesses have some form of patch management policy, but few can provide a comprehensive inventory of all the software powering their business and fewer still can identify the origin point for that software – particularly with the prevalence of freely downloadable software. This lack of awareness creates exploitable blind spots, but how can a business not know what software it uses?
The problem stems from procurement practices. If someone buys packaged software, they clearly know they need to manage software. But if they are buying a security camera, or diagnostic device, the evaluation criteria will be focused on functionality while the risk emanates from the software powering the hardware. As such, the procurement process should include security reviews of not only the software powering the device, but also the software used to interact with the output of the device, such as imaging software. This extends to cloud services which are themselves software engines, and where visibility into security practices is limited. Each of those pieces of software have their own update process, and the security standards used to create each piece could be quite different.
Things get much more complex when you look at open source, or freely downloadable software. With the software development trends in recent years focusing on time to market, I can all but guarantee that you have open-source software powering some part of your operation. Where a purchasing relationship at least offers the potential for the supplier to know their customers, something freely downloadable and usable from the internet doesn’t.
If your patch policy doesn’t include all software assets, independent of origin but with full knowledge of origin, then you are likely running unpatched software. And obviously, any time there is unpatched software, there is a weakness that could be exploited by an attacker.
Tying it all together
There are many more elements that form part of a successful cybersecurity blueprint, such as limiting access to data, but these three are part of the foundation. If you don’t know the software powering your organisation, you can’t possibly patch it. If you don’t know the threats your processes and software usage pose to your organisation, you can’t reliably defend against attacks on them. If you don’t have an incident response plan in place prior to an incident, you’ll be slow to react and could damage information that would be helpful to recover quickly following an attack.
Cyber security is all about preparedness. You can’t protect against all attackers, but you can defend against most. Knowing your software, why you have it and how it works is a great first step in that process.
By Tim Mackey, principal security strategist at the Synopsys CyRC