Utilizing Key Orchestration During a Hospital Ransomware Event
In Part 2 of this series, we examined the ongoing transition from Cyber Security to Cyber Defense, discussing Cyber Defense effects and utilizing Key Orchestration to realize those effects. In this post, we continue the discussion as we demonstrate how Key Orchestration enables the effects in a real-world scenario.
For practical consideration, let’s examine the following environment: A healthcare enterprise with 15 hospitals, two data centers, and multiple third-parties who use hospital technology resources. The IT infrastructure represents a number networks, applications, storage solutions, and network-connected diagnostic equipment.
This healthcare system has implemented a Network Operations Center (NOC) and has integrated security operations with the NOC. Part of the services portfolio for the NOC is threat detection and response. They have implemented technologies from Splunk, Ruckus Networks, VMware, Dell, NetApp, Racktop Systems, Penteon, and Fornetix.
A user at one of the 15 hospitals clicks where they should not have (email, website, etc) and unknowingly downloads ransomware with ENTERNALBLUE-type capabilities that allow it to start spreading on the local network.
Threat Detection and Response is Triggered – Orchestration Begins
Log aggregation from Splunk detects an abnormal amount of failures associated with file access on hospital systems (all happening before the panicked phone calls begin). The NOC has created a ransomware alert for this type of detection behavior that triggers a multi-faceted response across technologies to deny access, disrupt ransomware communications, and gather forensic data to help discover the source of the attack.
Part of the alert is a call to Key Orchestration to execute a composition called CyberPlanA which uses an Orchestrator integrated with Ruckus infrastructure to change MACsec pre-shared keys on Ruckus switches, swapping the keys on safe network segments to isolate the effected ones. This makes recovery a simple exercise of putting the original keys back.
While CyberPlanA is executing, logging continues in the environment to watch for a combination of alerts that denote the presence of ransomware and the success of CyberPlanA execution. If CyberPlanA has failures noted by Key Orchestration, Orchestrator commands, and the ransomware alert being triggered (CyberPlanA_Alert), then the CyberPlanB1 and CyberPlanB2 compositions are triggered which is used to limit access to storage and virtualization resources in order to protect things like patient electronic health records.
With CyberPlanB triggered, Key Orchestration starts moving the position of keys in Key Orchestration’s hierarchy (effectively suspending them) for VMware, Dell, and NetApp unlock keys and SSH public keys for associated network infrastructure. A combination of calls within the CyberPlanB and Orchestrators trigger service restarts that isolate the storage and virtualization resources from the threat.
CyberPlanB2 interacts with the Penteon IoT systems and their integrated LoRaWAN reporting networking, preventing sensor and communications data from being corrupted by any affected workstations interacting with the Penteon IoT sensor platform. This allows for clean infrastructure to operate on new encrypted channels and prevent any local infected systems from accessing Penteon resources.
Identifying the Attacker, Recovery and Restoration
In many cases, cyber-attacks use things like ransomware as a distraction from the main effort of the attack — an attempt to steal data. That’s where Racktop's Brickstor combined with the Key Orchestration appliance comes into play; integrated together as the “Secure Data Protection Platform.” In the case of the CyberPlanA_Alert for CyberPlanB1 and CyberPlanB2 being triggered, CyberPlanA_Alert also calls the CyberPlanC composition. CyberPlanC takes advantage of unique capabilities of the Secure Data Protection Platform by presenting information to the attacker as a honeypot that provides the capability to discover the source of the attack — something as simple as a document with a DNS entry embedded in it. (Note: DNS is UDP and as a result can reveal real network addresses vs TOR obfuscated addresses.)
Finally, there is recovery. Just like when soldiers defend things outside cyberspace, there are actions required to bring systems back into working order. Back to normal. The goal here is bringing systems back online as painlessly as possible. Scorched earth defenses are rarely applicable in Cyber Defense so what you want is to rapidly undo the effects once things return to normal.
In the case for CyberPlanA it is as simple as restoring the original keys back. For CyberPlanB1 and CyberPlanB2 it is an exercise of moving keys back and starting services for CyberPlanB1 and updating the isolated systems in CyberPlanB2. For CyberPlanC1 it is a variant of CyberPlanB1 while watching what outside IPs are pinging your DNS servers.
When looking at practical application of Key Orchestration, it shows that Cyber Defense is one-part preparation, one-part vigilance, and one-part execution. What is described above is how the Key Orchestration appliance, Orchestrators, and standards-based solutions built on interoperability, provide a path to make management of encryption and encryption keys a powerful part of how you protect yourself.
To see these concepts in action and learn more about how Fornetix can help your organization, request a demo today.Share this entry