What IT and Security folks can learn from the United Healthcare hack

It’s been more than a week since an attack on United Healthcare’s systems. (See the SEC 8-k disclosure here.) The details of the attack are scarce, but what we do know is that medical billing and pharmaceutical fulfillment services have been offline for many days. United Healthcare claims they took systems offline to prevent the spread of the attack.

Whatever reason the systems are offline, for either recovery efforts or as a direct impact of the attack, the outage is taking a toll on medical providers.

Personally, I have friends who own a small family medical practice that are having trouble managing the business day to day due to the outage. Online discourse of the outage also highlights organizations that are concerned about impact. The complications in billing mean organizations can’t submit for insurance payment on care rendered, which has downstream impact.

Before I get into details of what I think we as practitioners can learn so far, I want to cover what this article is not:

I don’t think it’s beneficial to start a conversation around the hypotheticals of what occurred or who’s to blame for the length of outage.

I don’t know the teams and individuals that manage the technology systems and that are the boots on the ground for response efforts, but I’m sure they are good people working tireless hours to try to bring systems back online. I’m not writing this article to critique them, their work, or what led up to this attack. There will be plenty of time for lessons learned. Hopefully there’s an open discourse in the coming month we all can learn and collectively become better from. In security we are all one mishap away from a large attack, and unless there is proven gross negligence we shouldn’t point fingers. We all live in glass houses when it comes to cybersecurity.

What I would like to do is use this to highlight the seriousness of cyber attacks, and the importance of being prepared for them.

There is an unfortunate reality that most people have both an optimism bias and survivorship bias when they have not (yet) experienced a breach. Even some who have experienced small scale breaches don’t see how close they are to becoming Icarus.

Risk management is one of the most challenging parts of business. Business is about taking risks. Most people who started a business took a risk. They sacrificed fiscal security to pursue a dream.

Our job as security practitioners is to create relationships with our colleagues that allow us to have an open dialogue and make clear decisions on which risks to accept.

That said, one risk I personally believe is never acceptable is not having a tested business continuity and practiced incident response plan.

It doesn’t require a massive spend or massive time commitment.

It requires some forethought, walking through the “what ifs,” documenting them, and developing an action plan to manage them. In some cases the negative consequences of the “what ifs” will warrant spend. (See our thoughts on the Super Bowl for example. If game streaming and ability to watch games were impacted I think the ad buyers will want their money back. They paid millions for those eyes, they want them).

But many times it’s not about spending more on technology, It’s just about the ability to have a plan and act on that plan.

The reason the military trains heavily – it’s not that the skill set is always hard to learn, it’s about being able to act under pressure. Many people could physically be in the military, but when the adrenaline rush and fear hit, it’s a different game. Your brain has to be able to act on autopilot.

It’s the same in Incident response. It’s great to have a plan but if you don’t test you don’t execute, you don’t know how to make decisions. It becomes a disaster quickly.

That said, if you have nothing to restore – no backups, no ability to move at least your data and infrastructure templates back to production – all that practice will be for naught.

I talk about security often as a game of “raising the bar.” There is likely an actor or group of attackers out there that are smarter and more determined than those playing defense. You have to assume that’s the case. If you turn to a random page in a history book there is a good chance of finding a story in which a nation fell because it underestimated the enemy.

That said, most attackers are not targeting ‘you’ specifically. They are targeting organizations which are like you, and including you. Most attacks are about financial gain. (Yes I’m ignoring those carried out in the interest of a state for this article.)

You should continually elevate your defenses beyond the level that would make you an attractive target to financially motivated attackers.

One of the ways we can elevate our security or “raise this bar” is by red teaming, purple teaming, and table top exercises (TTX) as mentioned above. We can simulate the actions of actors and our response to them to determine our readiness.

If you follow our blog, or my writing (Thank you) – you might have picked up a theme. Last article I wrote on the Clumio blog was about the changes to the NIST CSF. One of those changes highlighted the need to test recovery as part of your incident response (IR) plan testing.

In other words, as you mature your ability to execute table top exercises, it’s advised to start doing some live testing elements as well. Tactically a TTX run book can incorporate elements of purple teaming and disaster recovery (DR) testing. An example outline may be as follows:

Phishing & ransomware TTX outline

1. Phase one: Simulate a phishing attack with real tools (purple team)
   1. Have an employee open and run the simulated payload.
   2. Watch the SOC Response.
2. Phase two: Simulate ransomware
   1. Play out virtually the next steps of the attack to simulate production machines going offline. Prompt the team to discuss how they would handle this.
   2. This is a good place for an inject in which communications are cut off.
   3. Simulate response actions and trigger DR execution.
3. Phase three: DR Test
   1. Restore and bring a few “impacted” systems online as you would in a real incident.
4. Phase four: Complete response efforts
   1. Simulate the isolation, analysis, and forensics steps.
      1. Be specific. Ask what tools, what people, how they would communicate with the person. (Ask “how would you do that” over and over).
5. Phase five: After action review
   1. Review what worked and didn’t and create plans to close the gap.

Creating scenarios like this create collaboration opportunities, and really are low effort compared to many Infosec projects. Spending a little time thinking about how you and your team can practice will go a long way toward incident readiness.

United Healthcare may have done all these things well. Or they may not have. It’s too early to tell, and we may never really know.

But, if the attack and outage makes you shift uncomfortably in your seat, it’s worth revisiting if you’re ready for an attack.

Nothing I am writing is novel from a best practices perspective, but if you haven’t invested maybe this is the time to do so.

Security is a community. One that I try my best to support. My door, and my colleagues’ doors, are always open to advise. Working at a company that helps customers build resilient infrastructure also gives me a unique perspective on how some of the largest companies are building their programs and I’m happy to help with your strategy too.

Learn more about Clumio’s virtual air gap backup and how it can help you recover during an incident with our ransomware recovery solutions. You might also want to download our Best Practices Checklist for Ransomware Defense.