Credit: filo/Getty Images
Cyber resilience is a concept that most organizations are familiar with. It's defined as the ability to withstand and recover from adverse events that have the potential to impact an organization’s information systems and IT resources.
Hospitals are no stranger to this need, of course, and most have sophisticated downtime procedures to keep patient care operational in the event that EHR, PACS and other clinical systems are impacted by an incident.
But while downtime procedures and other incident-response procedures that help support cyber resilience often include information security components, it is not uncommon to find that organizations often forget to ask an important question: How much resilience does my organization have if one of my cybersecurity tools or controls were to suffer an adverse event?
If a healthcare organization were to suddenly lose EDR telemetry, have a firewall fail open or have a zero day inconveniently render a system vulnerable, is there enough cyber resilience across security controls to ensure the organization remains protected?
While issues like the recent CrowdStrike event, which disabled Microsoft systems worldwide, have brought this issue to the top of mind for many hospitals, it is important to remember that controls don’t fail in just major events.
In fact, security controls fail all the time – and that attackers are often adept at bypassing common security tooling.
Hospitals need to develop robust security strategies and architectures that account for control failures in order to ensure they have built a security program that is resilient enough to withstand adverse events and protect the patients in their care.
In order to achieve an effective level of cyber resilience for security controls, healthcare organizations should begin to consider incorporating some of the approaches detailed below:
Measuring control efficacy
Many of the standards that the security industry follows today are useful for setting minimum baselines for what security controls are needed to keep an organization secure, but one of the limitations of these standards is they tend to be focused on control existence and not control efficacy.
Being able to check off having a firewall is very different from empirically evaluating the efficacy of the firewall ruleset against attacker behavior like data exfiltration or the establishment of command and control.
The adoption of approaches such as evidence-based security can help organizations to evaluate the efficacy of their controls against attacker techniques and help them identify all of the areas where controls are not working as well as intended.
This is especially critical in that controls fail more often than many organizations realize, with one study estimating that controls such as EDR only work to stop attacks 39% of the time.
Such approaches to measuring security are vital as it’s through the identification of weaknesses that we often find the best opportunities for improvement. Ensuring the controls we have work to an acceptable level of efficacy is the first step towards control resilience as it ensures that our defenses don’t fail right out of the gate.
Eliminate bypasses
Related to the above, a common issue with many security tools and controls is even if a control can be demonstrated to have a high level of efficacy against common attacker techniques, attackers often have means of bypassing controls in their playbooks such as booting into safe mode to bypass EDR or using DNS tunneling to mask command and control and bypass egress filtering.
As security professionals we need to identify and work to eliminate all of the various ways in which controls can be bypassed. In the case of safe mode, perhaps we block the bcdedit command from execution and in the case of DNS tunneling perhaps we add controls to block the lookup of domains that are not categorized as safe or build detections for DNS requests or responses that are unusual in size.
While bypasses may differ from tool to tool, no security tool is perfect, and every tool can be bypassed in some way. The more proactive we are in identifying and eliminating a bypass the more we can ensure that attackers are forced to contend with the efficacy our controls bring, rather than taking an easy way around them.
After all, a control that can be readily bypassed is not much of a control and won’t provide much resilience against an attack.
Vulnerability management
When most healthcare organizations think of vulnerability management, they think of identifying all the places where a patch may be needed and making plans to apply the missing patch in a timely manner. While patching is a critical security best practice and something that should be done wherever possible, hospitals should not rely on patching alone as a means of keeping systems secure.
Organizations need to begin to expand the definition of vulnerability management to involve more than just patching, and begin to ask the question of what compensating controls could be applied to mitigate the successful exploitation of this vulnerability.
For example, if we consider a vulnerability like Log4J in the context of compensating controls, we can see that in order to successfully exploit this vulnerability that outbound LDAP communications are required. Thus, applying egress filtering to our system is a compensating control that could be used to mitigate Log4J.
Therefore, if we were to patch Log4J and apply egress filtering we would find that we not only had a defense in depth control set to protect against Log4J but that we have also improved our cyber resilience against any future zero day that might also require outbound communications.
Moreover, these types of benefits are far from unique to Log4J mitigation and disabling the print spooler on systems where it was not needed in response to PrintNightmare would be another example in that the compensating control also protects against the exploitation of future vulnerabilities in the Windows print spooler.
Asking the compensating control question allows us to identify and build the proper system hardening and security architectures needed to mitigate future vulnerabilities that may not have a patch.
With zero days increasingly being used to compromise organizations, we need to move beyond just solely patching and build hardened architectures that can protect organizations in the absence of a patch or the bypass of a tool.
Defense in depth
Defense in depth is a long-established best practice in the realm of security, but one that is not always analyzed deeply enough from the lens of failures of an entire class of control or from the lens of supply chain failures.
Analyzing failure modes becomes even more pertinent as vendors increasingly try to entice organizations with the promise that “my product can do all this on a single pane of glass.” For example, in light of the recent CrowdStrike event, it is not unreasonable to ask the question of what if we lose access to EDR and the detections it provides?
Does the organization have enough defense in depth that we would not be blind to a security issue on an endpoint? Perhaps the organization has a secondary source of detection via an MDR or XDR system that provides a layer of defense in depth, or perhaps sysmon logging and log collection is leveraged as a secondary detection set?
Defense in depth needs to be laid in a way that not only provides layers of security, but resilient layers of security in the event an entire class of control is lost, or, even worse, an entire security stack is lost due to a common vendor. Control sets need to be analyzed to identify single points of failure that would leave an organization blind to or unable to stop an attack and defense in depth applied in a way that would mitigate the impact.
System diversity
As we take into consideration defense in depth strategies as outlined above, we need to be wary that there is some diversity built into security control sets.
While there are definitive advantages to having one pane of glass, such as the potential for cost reductions, simplified management, better integration between different functions, etc., it is important to keep in mind that having everything from one source also has the potential to exacerbate any failures.
This could be a major failure on the supply chain side where multiple security functions may be simultaneously lost if the vendor experiences an issue, but could also cause more fundamental everyday failures.
If we buy our entire stack from vendor A, and vendor A does not yet have a way to detect a new threat, we will likely fail to detect the threat at all levels.
If we have some diversity of product sets (e.g. having EDR and XDR from different vendors, or having different brands for internal and perimeter firewalls, etc.,), there is an increased chance to detect a threat even if vendor A can’t. System consolidation makes sense in many cases. It just needs to be done in a way the resilience is still maintained where needed.
Zero trust
While zero trust and the various techniques like microsegmentation that it encompasses can be applied as compensating controls to help achieve many of the goals already discussed, it is worth highlighting it separately as well.
When zero trust principles are applied to system hardening guidelines and system architectures, it becomes a great way to build security resiliency into systems.
Zero trust, at root, assumes that everything can be compromised and works to proactively mitigate threats by ensuring that every person and every device has the least amount of access possible in order to do their job. Establishing a zero trust mindset and using zero trust principles will work to improve the security resilience of systems.
While the above list should not be considered comprehensive in terms of what can be done to improve the resilience of security controls, it should help to outline some of the major ways in which security resilience needs to be factored into the security strategies and architectures that healthcare systems use.
It’s critical to patient safety that security control sets are designed to be resilient enough to withstand ransomware and other cyberattacks that lead to adverse patient care events.
at Mount Sinai South Nassau.
The HIMSS Healthcare Cybersecurity Forum is scheduled to take place October 31-November 1 in Washington, D.C. Learn more and register.
