The current cybersecurity landscape has become more fraught than ever, with threat vectors continuing to intensify in the healthcare industry, even as the leaders of patient care organizations struggle with a range of challenges during the COVID-19 pandemic, including clinician burnout, staff shortages, and imperiled finances. Indeed, if ever there were a time when cyber attacks could prove devastating, it would be now.
Unfortunately, a significant number of U.S. hospitals and health systems were impacted in mid-December, when Ultimate Kronos Group, the workforce and human resources management company with dual headquarters in Lowell, Mass., and Weston, Fla., disclosed on Dec. 13 that it had been hit with a ransomware attack. As CNN’s Jennifer Korn wrote on Dec. 17, “Ultimate Kronos Group, one of the largest human resources companies, disclosed a crippling ransomware attack on Monday, impacting payroll systems for a number of workers. After noticing "unusual activity" on Saturday, Kronos noted that its systems were down and could remain that way for several weeks. Kronos has a long list of notable customers across the public and private sector, including the city of Cleveland, New York's Metropolitan Transportation Authority (MTA), Tesla and MGM Resorts International. It also works with many hospitals across the country. Some employers find themselves having to make contingency plans in order to pay workers, such as shifting to paper checks. And some impacted employees have been unable to access payroll systems. The ransomware attack impacts Kronos Private Cloud solutions, a data storing entity for several of the company's services, including UKG Workforce Central, which is used by employees to track hours and schedule shifts.”
The company was compelled to create an entire section on its corporate website to answer questions from customer organizations, the public, and the press, entitled “Kronos Private Cloud FAQs.” In December, one of the statements in that section of the website read thus: “UKG is currently mitigating the impact of a ransomware incident affecting a small subset of UKG solutions. The incident is limited to those instances that are hosted in the Kronos Private Cloud (KPC), specifically, Workforce Central, Telestaff, Healthcare Extensions, and UKG Scheduling/Workforce Management for Banks (formerly called FMSI/Kronos for Banking Solutions). UKG has engaged leading cybersecurity experts, notified the authorities, is proactively communicating with impacted customers, and is beginning the recovery stage. We recognize the seriousness of this issue and are committed to supporting our customers as we work to a resolution.”
One of the questions about the UKG situation was whether what happened to Kronos was in some way connected to the Log4j vulnerability. As a report published on Dec. 29 in the “Business Line” section of The Hindu newspaper of Chennai, India, stated, under the headline, “Cyber security: Log4j vulnerability issue explained," “What is Log4j : Log4j, an open source software, a logging library for Java, is widely used by businesses and web portals. Earlier this month, this open source software was in the news for its vulnerabilities. According to the Indian Computer Emergency Response Team (CERT), multiple vulnerabilities have been reported in Apache Log4j, which could be exploited by a remote attacker to execute arbitrary code or perform denial of service attack on the targeted servers. Log4j is a Java-based logging library included in Apache open source project.” The unbylined article noted that , “Being used by many businesses and websites around the globe as a Java language, this software is public accessible and used to collect and store records of activity on a server. In this case, the vulnerability discovered allows malicious attackers to execute code remotely on any targeted computer. In simple terms, hackers can easily steal data or take control over the system. This vulnerability has the potential to expose organisations to new waves of cybersecurity risks, where the attackers can exploit using Remote Code Execution (RCE).”
UKG executives have not disclosed whether they believe that the attack on their Kronos solutions was in any way connected to Log4j, but the UKG hack emerged at the same time as awareness of Log4j was emerging. But Linn Freedman, chair of the privacy and cybersecurity team at the Boston-based Robinson + Cole law firm and an adjunct professor at Brown University and the Roger Williams Law School in Providence, R.I., wrote in a Dec. 17 blog entitled “update on Apache log4j and Kronos Security Incidents, “Here’s an update on the Apache and Kronos situations, which have not yet been confirmed as related, but frankly, the timing does seem more than coincidental. Whether related or not, both are worthy of mention in this week’s Insider. The log4Shell vulnerability, discovered by the Alibaba Cloud Security Team and disclosed by Kronos on December 9, 2021, has affected multiple versions of the Apache log4j 2 utility. The vulnerability (CVE-2021-44228, CVSS v. 10.0) affects Apache log4j 2 versions 2.0 and 2.14.1. According to Randori, “the vulnerability allows threat actors to execute unauthenticated remote code execution,” which means that “any scenario that allows a remote connection to supply arbitrary data that is written to log files by an application utilizing the Log4j library is susceptible to exploitation. This vulnerability is being exploited in the wild and thousands of organizations are impacted. This vulnerability poses a significant and active real world risk to affected systems—PLEASE TAKE IMMEDIATE ACTION.”
And Mac McMillan, CEO of the Austin, Tex.-based CynergisTek consulting firm, wrote in a Dec. 17 web article for Healthcare Innovation entitled “Just in Time for Christmas—Log4j—oh joy!” that, “By now you have no doubt heard your CIO or CISO talking about a vulnerability that has widespread implications for your health system, which is a security flaw involving the Apache Log4j popular open-source library, a commonly embedded and ubiquitous piece of software found in millions of systems that are web-enabled. It is so prevalent because it provides functionality that every web application needs. This is serious because this vulnerability, which does have well known exploits, allows an attacker to remotely execute code and totally compromise the system affected. As a result, it has been assigned a severity level of 10.0 out 10.0, meaning it doesn’t get any worse. But the real reason this vulnerability is so dangerous is because of its potential widespread attack surface which includes your enterprise systems, vender systems, affiliates, ancillary groups and remote users. The bottom line is it has the potential to affect virtually every aspect of your computing environment, and if left unmitigated is extremely easy to exploit. So, we have a real threat, with real exploits, that affects millions of systems, that is easy to exploit and can have devastating results both operationally and to patient care.”
Meanwhile, Liam Tung wrote in a Jan. 12 article in ZDNet that “Iran-backed hacking group Phosphorous or APT35 is using the Log4j vulnerability to distribute a new modular PowerShell toolkit, according to security firm Check Point. APT35 is one of several state-backed hacking groups known to have been developing tools to exploit public-facing Java applications that use vulnerable versions of the Log4j error-logging component. Microsoft, which tracks the group as Phosphorous and has called it out for increasingly using ransomware in attacks, found it had operationalized a Log4j exploit for future campaigns less than a week after Log4Shell's December 9 disclosure,” Tung wrote.
And, whether it ultimately turns out that the Kronos hack and Log4j were directly connected or not, The Wall Street Journal’s James Rundle wrote on Dec. 17 that “Kronos users span a range of industries, covering retail, government services, manufacturers, and numerous healthcare systems. The American Hospital Association said in a Dec. 14 statement that it had seen several reports from hospitals that had been affected by the outage, and warned that the lack of system availability could be “quite disruptive” given a continuing rise in seasonal flu and Covid-19 cases.” What’s more, he wrote last month that “The payroll issues stemming from the Kronos outage come as technology staff around the world are grappling with a newly discovered vulnerability in a software tool known as Log4j that logs user activity. UKG said in a notice on its website that it is aware of the Log4j flaw, and has measures in place to prevent hackers from exploiting it. The ransomware attack at UKG is the latest in a number of cyber incidents during 2021 targeting technology service providers and supply chains. In July, Kaseya Ltd., which offers technology management tools, was the victim of a ransomware strike that subsequently infected hundreds of customers. A February attack on software company Accellion USA LLC exposed data from law firms, universities and other users of its File Transfer Appliance platform,” Rundle added.
All of these developments, whether directly related to one another or not, signal an intensifying threat landscape for the leaders of U.S. patient care organizations. And, says CybergisTek’s Mac McMillan, patient care organization leaders, including CIOs, CISOs, all c-suite members, and boards, need to accept that they all retain responsibility for core cybersecurity in their institutions, regardless as to whether third-party vendors also have some responsibility for safeguarding their data and information systems. In that context, McMillan spoke recently with Healthcare Innovation Editor-in-Chief Mark Hagland regarding the current moment in U.S. healthcare cybersecurity. Below are excerpts from that interview.
So much has been happening, even in the past two months, in healthcare cybersecurity. Let’s start way up at a 40,000-feet-up level. What are you seeing, and how would you describe the landscape in this moment?
I think the thing that concerns me the most, in particular around HC, is the disruptive nature of a lot of the attacks that are occurring, and what that means to HC. Those disruptive attacks, particularly ones that last for more than a week or so, have a really debilitating effect on organizations, on quality of care, on the impact of operations. And we’re at a moment in this industry, where the industry is as stressed as much as it can be stressed, in terms of the pandemic that has not gone away yet, in terms of loss of clinicians, clinicians who are tired. It’s just putting a tremendous strain on a system that is so critical to our society.
What do the c-suite, board, CIO, CISO, and everyone else in charge at patient care organizations, really need to focus on, given this moment in healthcare, in the midst of this terrible pandemic?
I would focus on two areas. From a technical perspective, I think we really need to embrace being more proactive: greater testing, controls validation and analysis of our environment, and less focus on compliance, and more focus on the controls we have deployed, are they actually functioning and providing the levels of functionality we need? So we need to be more proactive in how we approach security from a technical perspective.
And second, we need to focus more on business continuity. We need to absolutely understand what our critical systems and processes are, and go through a complete analysis of our worst-case scenario—an extended complete outage—recognizing that it does happen. Are we adequately prepared to continue to operate, and care for people, and take care of our employees, our caregivers, if we have lost our systems and our data?
And in terms of being more diligent and proactive in terms of more continuous monitoring, controls validation, etc., gives us a better shot at anticipating trouble when it hits us, so it doesn’t have quite as broad an impact; and second, we need to be ready for it when it happens.
Three specific areas keep coming up in nearly all the interviews that I and my team have been doing with healthcare IT leaders: robust backup governance; behavioral monitoring; and real network segmentation. Can you speak to the importance of those areas?
Yes, we still are behind in those areas, including in terms of organizations developing an effective backup strategy. It makes all the sense in the world to take advantage of redundant data centers and asynchronous backup; the problem is that that doesn’t really prepare you for the catastrophic situation in which somebody attacks your backups first or attacks both your backups and your live system. And things like this Kronos situation that just occurred recently, is a classic example of where your backup strategy not only has to encompass redundancy in terms of data centers, but a backup that is completely offline, that the bad guys can’t get to if you lose your entire network, so that you have the ability to reconstitute.
Now, keep in mind, their situation at Kronos was complicated. I think it was more the infrastructure between the data centers that caused the issue. And it was more complicated in the sense of the enormous number of people they support, in terms of bringing things back online in a safe manner. But generally speaking, there’s an old 3-2-1 rule; 3 sources of data, 2 data centers, and 1 copy offline. You need redundancy in your systems, so that if one goes down, you can trip over quickly, but you also have a copy that’s not on your network.
What percentage of hospital-based organizations are at that level?
When it comes to data on prem [on premises], a lot of hospital-based organizations do have that today. Where this begins to fall apart is that when people put data or a service in the cloud, they then begin to rely on the cloud vendor, meaning, who’s going to rely on that service. When you put data, or a critical process, in the cloud, that doesn’t relieve you of responsibility for that information, because you can’t say to your customer—your patient or employee or whatever, it’s my vendor’s fault.
Is one of the problems the naivete of relying on cloud vendors without backing up internally?
Yes, that’s absolutely. Right. I’ve always said, take advantage of the many benefits of cloud computing; but, do it responsibly. Think about security, think about their requirements for securing your data. Think about the connectivity between you and your cloud vendor, and the risks involved. What is their backup strategy? What is their redundancy strategy? So you don’t end up in a situation where they get attacked and taken down, and you lose your ability to respond. That happened with Nuance; it happened with athenahealth. There have been several examples of this. And these are all good companies; they’re all trying to do the right thing. But the problem is that even the best companies—even the people who do everything right—can still find themselves victim to an attack. And look at these most recent ransomware attacks—Log4J was a zero-day attack in December; nobody knew it existed. There was no patch for it. So anybody who got hit by Log4J was going to be susceptible. Zero-day attacks are a perfect example of the residual amount of risk that will always be out there that you can’t plan for; but you should always anticipate that something will happen. So your business continuity planning should always take into consideration not just the short-term outage, but the long-term outage as well. Outages don’t all get cleaned up in four hours. And where we fall apart is when these things stretch out to a week or more, and we haven’t adequately planned for that.
I vividly remember in May 2017, when the information systems of the National Health Service of the United Kingdom crashed. The leaders of the NHS had repeatedly been warned of the danger of, even then, relying on a core information system that was Microsoft XP-based, and was no longer being supported. Imagine if a crash like that had happened here in the U.S., now, during the midst of the COVID-19 pandemic, as our country’s ICUs are nearly full.
The impact would be devastating. I was talking to an individual at one hospital very recently; they had hundreds of COVID patients, and all their ICU beds were filled, and nearly all were people who were not vaccinated. But to your point, this is the worst time for hospitals to lose all their systems. Imaging transferring patients on ventilators; that’s not a trivial thing. And the threat actually likes the situation that hospitals are in, because when hospitals are under stress and are facing a ransom, the greater likelihood is that they’ll pay a ransom. It’s the perfect scenario for the bad guys.
It seems that there’s been something of a misunderstanding around the attack on Kronos; healthcare organization leaders needed to understand that they still retained responsibility for their data and their systems, even if they were Kronos customer organizations, correct?
Yes, that’s exactly right. Kronos was the first victim here; they got attacked. But the fact that they were a victim has been completely dismissed, because everyone was angry. But in my opinion, a lot of patient care organizations had embraced Kronos as a cloud vendor, but they didn’t do it responsibly. Kronos had all sorts of redundant data centers, and promised everyone they would do their best to never go down; but at the end of the day, nobody can make that assertion, because you just don’t know what you don’t know. So I have to assume that, even if they’re doing the best they can, something could happen, and they could go down. And if they go down, what am I going to do?
And that’s the customer responsibility that hasn’t been recognized; a lot of people got flat-footed, because they never planned effectively for a major outage. And it happened at the worst possible time, just prior to a payroll, just prior to the biggest holiday of the year, in the middle of a pandemic. You couldn’t have planned a better “perfect storm” in terms of impact. So organizations already stressed in terms of staff—people not wanting to come to work because of the COVID situation, people infected with COVID—and all of a sudden, their pay is impacted, which puts even more stress on the institution and on those individuals, and it was just the worst situation at the worst time. But I believe that a lot of that could have been alleviated if customer organization leaders had had a plan. I don’t think they made a plan.
Do you see the Kronos attack as perhaps a potential wake-up call? That patient care organization leaders need to not assume their vendors will “take care of everything”?
Yes. You own your data and your operations, regardless as to who’s doing it. And it’s your job to make sure that you can continue to operate in the face of some adverse situation. And yes, the vendors that you hire share part of that responsibility in terms of responding, but ultimately, it’s your responsibility. Kronos is a great company. They’ve been around for a very long time, and have been doing a great job. They have been solid as a rock; I’ve been in HC for over 25 years, and I’ve seen them in hospitals and everywhere; they’re a great company. Unfortunately, they got it with something—we still don’t know exactly what it is—and it impacted them, and impacted their customers, and that impacted their employees.
To me, the lesson learned from all of this is just as you’ve said, we all have to plan for contingencies. And organizations that do so, fare far better. We have hospital client organizations that were hit by it, but had contingency plans, and were able to respond; others didn’t do such a great job. Ultimately, it’s the business owner that owns responsibility for the continuity of his or her enterprise, regardless as to whom they outsource it to. I used to say all the time when I was a director of security that you can outsource systems, processes, or people, but you can’t outsource responsibility; the buck still stops at your desk. And I think all too often, we try to place blame, instead of trying to solve how we got here in the first place. And in some instances, with cyber, there really isn’t a clear blame path, right? Especially if you’re dealing with something like a zero-day attack. If you can catch the hacker, that’s the guy who’s responsible.
