In the previous post, we introduced you to Josh, the “Help Desk guy” who was somehow expected to handle the IT needs of an entire 200+ employee organization by himself, and we talked about the alarming infrastructure and security practices of that same company. Now we go over the healthcare cybersecurity risks and the dangers of being negligent with your data.
Table of Contents
We Kept Trying to Tell Them
We had already started seeing warning signs. The healthcare cybersecurity risks were clear:
- Old infrastructure.
- Old software.
- A failed backup.
- Poor documentation.
- Weak security practices.
- A lack of centralized user management.
- A basic Microsoft 365 license without the proper tools needed for the job.
- Endpoint protection that technically existed but wasn’t being properly monitored.
- Former employee accounts and licenses that weren’t being properly cleaned up.
There were red flags everywhere.
The most frustrating part was that we knew most of these healthcare cybersecurity risks could be fixed, but leaving things as they were was incredibly dangerous. We told them what needed to be done, we insisted on it for months, and eventually they decided to act, but they did something else entirely:
They fired Josh.
Now Josh is Gone
At some point, looking for somebody to blame for the IT hiccups and increased spending, Josh was let go.
They hired someone else who didn’t work out. And then another person, who also didn’t work out. And finally, they hired Dave. Due to this constant shifting of new employees, Dave didn’t get a proper chance to learn about the infrastructure and all its issues. He only had a couple of weeks before Josh left to learn about an environment that had taken years to become this complicated, and all this with no documentation and no company training.
It was, essentially, “Here’s the keys to the zoo. The old guy is leaving soon. Good luck.”
And remember, this is an environment with multiple locations, hundreds of employees, sensitive patient information, aging infrastructure, a mountain of technical problems, and healthcare cybersecurity risks that only piled up. To make matters even more interesting, Dave was given an important instruction from the higher ups:
“Don’t send every ticket to Network Antics.”
Fair enough.
The whole point of the initial arrangement was for the internal help desk to handle the basic stuff while we handled the more advanced problems. Making us do the small stuff was contributing to the pile of invoices they were getting, and they wanted to cut the costs. A reasonable course of action.
But there was a problem with that plan: Dave was still learning.
He was a new Help Desk guy, but they had the same old problems. The same obsolete infrastructure was there. The same healthcare cybersecurity risks were there. The same lack of proper IT oversight. And probably the most alarming, the backup was still not working.
Changing the person sitting at the help desk wasn’t going to change any of that. They thought Josh, the humble Help Desk guy, just wasn’t up for the challenge, and that getting a different Help Desk guy would somehow fix all the issues.
(Spoiler alert: it didn’t)
Healthcare Cybersecurity Risks Don’t Magically Go Away
By now, we had a pretty good picture of what we were dealing with:
The organization had grown, but its IT infrastructure hadn’t grown with it. They had sensitive patient information sitting inside an environment that desperately needed modernization. They had a single help desk employee trying to carry responsibilities that belonged to an entire IT department. They had a new employee learning about the environment on the fly. They had security controls that needed significant improvement. And their backup had been broken for months.
We warned them. We had recommended fixes. We explained the risks. But they continued taking a reactive approach.
A storm was coming. The most predictable storm ever. But it was one hell of a storm, nonetheless.
The Storm Arrived
Well, it didn’t take long at all. That storm arrived.
About six months after our first engagement, we received a support ticket. A compromised e-mail account that required a standard MFA and password reset, with some additional recommendations. Standard procedure.
Except a few days later, we were notified of Screen Connect sessions occurring through the environment on several machines. We immediately relayed a plan of action to the client, but the scenario was clear: Dave was completely over his head with the size and scope of the breach and required direct guidance through the resolution.
Talking to upper management, we were given greater reign and permission to do what was best to keep things safe and working, instead of passing through Dave as a middleman. And so we deployed quickly.
Navigating the Storm with the Right Tools
Our quick response was only possible thanks to the use of the extensive stack of solutions at our fingertips and finally some liberty to act instead of reacting to their issues. We put them on trials so they could see the benefit of the tools our vendors could provide and charged only for the labor to triage and solve.
Our priority was checking the backup. The Help Desks before had never fixed the issue with the backup. Not Josh, not Dave, nor the two in-between had managed to fix it. Now we had to find something that could essentially back up everything instantly without touching the old backup.
Making sure there was endpoint protection working came next, and sure enough they had it. It was just nobody cared to monitor the alerts, telling of threats and risks around the environment. It was like an alarm system on mute.
Then we had to check on the whole company. 200+ employees meant there were a lot of devices they had no eyes on. This type of access is important to guarantee a means to proactively avoid any future calamity. Dave’s solution was to manually access each computer. We jumped into the server and created a policy for Remote Monitoring and Management (RMM) deployment. RMM is the surrogate for deploying other tools, such as Managed Detection and Response (MDR). MDR was the real hero that allowed us to save their entire environment from the otherwise catastrophic outcome.
The actions so far revealed that several standard users were set up as Domain Administrators, including the help desk. That is a lot of power for accounts and devices that were just meant to be used on day-to-day work, and a great risk.
The Domain Administrator situation gave us pause, so we had to make sure leadership understood that this was not something to brush off. We required them to confirm that everyone that mattered would be made aware of the current situation, that things were not compliant, and one wrong malicious access could compromise a lot of very sensitive information.
What Now?
We spent months working with this business. Their sequence of poor decisions in face of their healthcare cybersecurity risks made it abundantly clear that things could turn ugly at any moment. Unfortunately, the breach had been on the horizon for a long time. As we said earlier, it was just a matter of when it would hit. Now that disaster struck, we needed to make sure that it wouldn’t sink the whole company along with it.
Our work securing the environment was far from over, and recovering from the disaster wasn’t going to be easy, but thankfully we’re well-equipped even for the direst of situations (and trust us, this one was really dire). Come along with us for the final chapter of this saga as we further unravel the breach, execute our disaster recovery plan and talk about the lessons learned from this whole ordeal.
Adventures in IT Part 3: 4 Ways Medical Practices Can Maintain Compliance and Prevent Data Breaches
This blog post is the second in our new series called “Adventures in IT”, in which we relive some of the juicier and more impactful real-life stories we’ve experienced in the managed IT business that left a lasting impression on us. This is so that you, the reader, may learn not just from your own mistakes, but also from the mistakes of others.
