HIPAA 101: Enhancing cybersecurity to achieve compliance

This webinar was recorded live on July 31, 2024.

HIPAA was introduced in 1996. Since then, it’s had regular updates, but the overall goal of the legislation really hasn’t changed since the mid-nineties. Lawmakers at the time wanted to improve the portability and transferability of insurance, reduce waste and fraud, and strengthen the security of patient health information.

PHI, or patient health information, is essentially any medical record that can be traced back to a person through one of eighteen specific identifiers. Those identifiers can include your name, address, Social Security number, phone number, and now even biometrics like a fingerprint or a full-face photo. If a patient record has even one of those eighteen identifiers, it’s considered PHI and needs to be protected under the legislation.

If the information is fully anonymized, like what you sometimes see in drug trials, it can be shared more easily and more widely. You might also hear the acronym ePHI, which is just the electronic version of PHI. You can think of your printer as the point where ePHI becomes PHI—where the electronic version becomes physical.

Who does HIPAA apply to? 

The legislation identifies two major groups of entities that have to comply.

The first group is covered entities. A covered entity is anyone who produces, uses, or transmits PHI as part of their operations. That’s mostly healthcare providers—everyone from a single-doctor clinic up to a major hospital. Insurance companies also fall under this group, as do healthcare clearinghouses that store and transmit large amounts of patient health information.

The second group is business associates. A business associate doesn’t normally handle PHI directly as part of their day-to-day duties, but they’re a contractor or subcontractor for a covered entity. That could be a law firm, an accounting firm, and—most relevant for our crowd today—managed service providers. Companies that handle IT for covered entities are definitely considered business associates.

Who does HIPAA not apply to?

The first example is a bit hypothetical: cash-only doctors. If you ever come across a physician who refuses any kind of electronic or insurance payment, it might be because they’re trying to argue that they don’t perform the types of transactions covered under HIPAA. Would that argument hold up? Hard to say—I’ll leave that to the lawyers and HHS.

The second category is non-human patients—Rover is not covered under HIPAA. That said, many states are starting to implement laws that specifically protect pet health records. So if you’re an MSP and you support veterinary clinics, a lot of what we’re talking about today could end up applying to you in the future.

Major changes to HIPAA over the years

This is just to give you an idea of how much the technology landscape has changed since 1996, and why it was necessary for HIPAA to evolve over time. Back then, if you were using a computer, it was probably running Windows 95 with a high-end Pentium processor. If you needed to transmit PHI from one machine to another, you were likely doing it on floppy disks.

And if you were using that new thing called the internet, you were probably connecting with a lightning-fast 56k fax modem from U.S. Robotics. The cloud didn’t exist yet, of course, and if you had told someone you were storing patient health records “in the cloud,” they definitely would have looked at you a little funny.

The Privacy and Security Rule

The first big update came in 2003 with the implementation of the Privacy and Security Rule. That’s not to say the 1996 legislation didn’t address privacy and security at all—it did—but the language was much more general. In 2003, they started calling out specific safeguards they expected covered entities and business associates to follow.

The Enforcement Final Rule

In 2006, we saw the Enforcement Final Rule. This gave the Office for Civil Rights—the part of HHS responsible for enforcing HIPAA—a bigger stick. Before 2006, fines were capped at a low amount and were relatively minor. After this change, a tiered enforcement structure was introduced with much tougher penalties for non-compliance.

The High-Tech Act

In 2009, the High-Tech Act was added. The biggest change here was breach notification requirements. Prior to 2009, if a covered entity or business associate had a breach involving PHI, they weren’t required to tell anyone. Starting in 2009, they had to notify the affected individual, HHS, and in some cases the media. Today, breaches affecting 500 or more individuals must be reported to HHS almost immediately. Smaller breaches have a longer reporting window.

The Omnibus Final Rule

Then in 2013, we had the Omnibus Final Rule. This gave patients more power to request their PHI from providers, but the bigger impact was on business associates. Starting in 2013, business associates had direct liability for HIPAA breaches, just like covered entities. This was a major shift for managed service providers and other business associates, who had to significantly raise their security game.

HIPAA safeguards

HIPAA legislation breaks its safeguards into three main categories: administrative, physical, and technical. You might assume the physical and technical safeguards are the most significant, but in reality a lot of HIPAA is administration. Most of what HIPAA requires is bureaucracy.

The administrative controls focus on having the right policies and procedures in place, keeping them up to date, and maintaining business associate agreements with all your partners. Those agreements spell out roles, responsibilities, and obligations. Administrative safeguards also include performing regular risk reviews of your IT systems and the risks to any PHI stored on them.

Physical controls are more straightforward—they’re about making sure PHI isn’t left out on desks, that you have clean desk policies, and that devices have things like cable locks so they can’t “grow legs” and disappear. It also means ensuring your servers aren’t sitting out in a waiting room, but are stored in a secure data center with cameras, badge access, and other protections so only the right people can get to them.

The last category is technical controls.

Access and integrity

The first technical safeguard is access and integrity. This is all about making sure that only the people who truly need ePHI or PHI to do their jobs have access to it. Access should line up with job requirements, and most people within a covered entity shouldn’t have access by default.

It’s also important to ensure that even if someone can view PHI, they can’t modify it unless they’re authorized to do so. That’s where the integrity piece comes in. HIPAA wants to make sure patient health records remain unaltered unless there’s permission for a change.

Audit

Audit controls are about monitoring—both to detect security incidents and to verify that the access controls you’ve put in place are actually working.

Authentication

Authentication is focused on making sure no one gets access to ePHI before proving they are who they say they are. That means no shared user IDs, everyone having their own login, and multifactor authentication being used everywhere. Multifactor isn’t explicitly mentioned in the legislation, but in practice it’s absolutely the way to go.

Transmission security

Transmission security ensures that patient records aren’t sent across networks in an unencrypted format, for reasons that are pretty self-explanatory.

Backups

The last one isn’t technically a technical safeguard—it fits more under administrative—but it has a technical component: backups. The goal is to make sure patient health records aren’t destroyed. Even in the case of an adverse event, there needs to be a copy available to both the patient and the clinician.

Challenges of implementing HIPAA

So what are the challenges when it comes to implementing HIPAA?

The first challenge is the flexibility of the requirements. Even though the 2003 additions—the Privacy and Security Rule—made things less generic, the requirements are still written to apply to every type of covered entity. That means all shapes and sizes, using all kinds of different technologies.

As a result, there’s a lot of subjectivity. The legislation never tells you exactly what to do, so implementers are often left wondering:

• Am I actually meeting this safeguard?
• Am I really in compliance?

The second challenge is a lack of resources, especially for small and medium-sized covered entities. The administrative controls alone take up a lot of time, and then adding the physical and technical safeguards on top of that can be a real struggle for many organizations.

The third challenge is monitoring IT systems. Covered entities have never had larger or more complex environments, and monitoring them 24/7 to detect security events and ensure all controls are working is a significant burden.

And the last challenge is the possibility of audits. As discussed earlier, audits now have some real teeth. In the most serious cases—where the offense was intentional—there can even be jail time. Most audits aren’t that extreme, but they can still be a major headache. They come with fines, they’re expensive, and they take a lot of time to get through.

HIPAA audits

As mentioned, audits are conducted by the Office for Civil Rights, the bureau under HHS. There’s no set frequency for audits, and the reality is that most covered entities will go their entire lifespan without ever having one.

But when an audit does happen, it’s thorough. An OCR audit can take weeks to complete, and once the process begins, it moves quickly. Covered entities only have ten days to respond to the initial request for information, and then another ten days for any follow-up requests.

While audits can be random, OCR doesn’t have nearly enough auditors to perform random checks on even a small percentage of covered entities. Most audits are triggered by one of two things: complaints from patients who believe their health records were misused, mishandled, or breached; or incidents—specifically the breach notifications that covered entities are required to submit.

How Field Effect helps with HIPAA

Here’s the good news: when you have the right technology, a lot of HIPAA implementation becomes much easier. Field Effect’s MDR is really well positioned for this because we provide holistic coverage. We stop incidents very early in their lifecycle—and if you prevent incidents, you prevent breaches. Prevent breaches, and you avoid breach notifications. Avoid breach notifications, and you avoid audits. And nobody wants those.

But beyond stopping malware in its tracks, our MDR service constantly feeds back helpful insights to both covered entities and their business associates about how they can reduce risk in their environment.

We’ll also talk a bit about data sovereignty and log retention, and what Field Effect MDR can do to support HIPAA requirements around logging.

Holistic security

First, holistic security. What I mean by that is we have very sophisticated software. Our agent that runs on the endpoint can detect malware there, but we’re also doing deep packet network inspection for customers who have a Field Effect appliance at their gateway. We inspect all the traffic going out to the internet and coming in from the internet.

We also monitor cloud resources. We have integrations with Microsoft 365, Azure, Google, and a whole range of other cloud providers, so we’re able to monitor those environments. On top of that, our DNS firewall comes standard with MDR Complete. With all of these components working together seamlessly—because we own and configure our entire tech stack—we can provide truly seamless coverage, which is critical for HIPAA.

To talk a bit more about network monitoring: a lot of people think network monitoring is dead. It’s still an extremely valuable part of cybersecurity monitoring, especially in healthcare. One of the reasons is that so many devices in a healthcare setting simply can’t run endpoint security software.

Think about printers, security cameras—anything with an IP address that’s on your network but can’t run endpoint tools. Patient health monitors are highly specialized devices and can’t run endpoint agents either. Even some Windows servers that control diagnostic equipment like X-ray or MRI machines often come from the manufacturer with strict instructions: they can’t be modified, upgraded to the latest operating system, or have software added or removed.

So what do you do? This is where network monitoring becomes so important. We can still alert you if we see a device on your network talking to an IP address associated with cybercrime. That tells you to take immediate action—remove the device from the network or investigate further.

Our network monitoring is constantly updated with the latest threat intelligence, so you don’t have to manage that. We take care of the analysis and reporting behind the scenes, fully automated.

Incident prevention

Next up: incident prevention, and what that largely means is stopping malware in its tracks, and there are a few ways we do that.

The first is on-host blocking. Our sophisticated endpoint agent uses a large set of heuristic signatures to detect the latest threats. A good example is malicious documents. If the agent detects that someone has opened a malicious Office document and it’s trying to spawn malware, we’ll block it immediately. The user gets an on-screen notification, followed by a report.

Next, host isolation. If the compromise has progressed further—maybe malware is already installed, or we detect lateral movement—we can shut the device down right away. That keeps the compromise small and contained before it escalates into a breach or causes major impact on the clinic.

Our DNS firewall is another layer. It’s loaded with the latest threat intelligence, and you don’t need to manage any of that. It prevents end users from reaching known malicious websites or malware command-and-control channels. Customers can also enable content blocks to prevent access to sites that aren’t appropriate for a clinical environment, which helps covered entities enforce acceptable use policies.

We can lock cloud accounts too. Just like we can isolate a compromised endpoint, if we detect suspicious activity in a cloud account, we can lock it immediately to stop any damage before it affects the clinic.

And the last one is email rule deletion. Threat actors who get into a cloud account often create malicious mailbox rules—for example, forwarding any incoming email with payment or billing information to an external address. That’s typically used to set up business email compromise. We can detect and delete those rules so that activity stops immediately.

Risk reduction

Now, let's look at risk reduction, and why this is so important for HIPAA. One of the biggest concerns people have with this compliance framework is the fear of being audited, and the fear that auditors will find something they didn’t even know about. Field Effect MDR not only prevents security incidents, but also continually shows you how to improve your environment, 24/7/365. You can think of Field Effect MDR as doing a light audit on the environment at all times.

Data sovereignty

When talking about data sovereignty, we're referring to the network appliance—the device that sits at the gateway and performs network inspection. But more importantly, it keeps the vast majority of the data collected by Field Effect MDR on the network on premises.

That matters for two reasons. First, while there are legitimate uses for the cloud, we don’t automatically pull everything up into the cloud like many other vendors do. Instead of sending all the data to the analytics, our technology brings the analytics to the data. That gives covered entities and their business associates real peace of mind, because they know exactly where their data resides.

The second benefit is faster detection of threats. Field Effect participated in a recent MITRE evaluation, and placed second in mean time to detect. That means this philosophy—keeping the data local and analyzing it locally—is helping us detect threats faster than many of the larger players in the industry.

So it’s really twofold: we give you peace of mind about your data, and we speed up the detection of threats.

Log retention

The last thing I want to mention briefly is log retention. A lot of covered entities have been led to believe that, in order to meet HIPAA’s six-year log retention requirements, they need to implement a full-scale SIEM solution.

For those who may not be familiar, SIEM solutions are very expensive. They require a lot of tuning, a lot of ongoing maintenance, and they don’t actually provide much cybersecurity value because you’re always behind. A SIEM only reports on things that have already happened, so you’re constantly trying to catch up to the threat.

With our MDR, we can help with log retention for as long as you need—up to six years. And one of the advantages of having that appliance on the network is that it can also be configured as a syslog receiver. Syslog is a very common format, and many systems can produce it. We can receive those logs on the appliance and send them to the cloud for long-term storage and retention.

We’re able to do all of this at a cost that’s far lower than a full-fledged SIEM solution. So our MDR can be a key part of the log retention strategy for a covered entity.

Q&A

Q: What if you have a thousand people who can access PHI on their own laptops while working in a patient’s home? Would they need to be monitored?

The use of personal devices brings up a whole host of issues with PHI. Once someone downloads PHI onto their own device, it’s outside your control. That device could get hacked and you might not even know—yet you’d still be required to submit a breach notification. So I’d say BYOD and HIPAA do not align very well.

Q: When it comes to incident prevention, what about malware that turns into ransomware once someone clicks or opens it? Can Field Effect handle that?

Yes—that’s a big problem, and ransomware is definitely out there. We stop ransomware on a daily basis across our customers’ networks, and we do it through the holistic approach we’ve been talking about.

Q: Where does Field Effect’s threat intelligence come from? Do your tools collect it, or do you subscribe to an open-source feed?

Great question. It’s a mix. We take in and aggregate a number of open-source threat feeds, but we also have our own. We gather intelligence through our investigations and our incident-response activities. So if we discover a new indicator of compromise on one customer’s network, and one of our analysts checks it and confirms it’s unique, we can rapidly push that indicator out to all our customers.

Q: Does Field Effect do anything beyond monitoring, incident prevention, etc. to attain sufficient information to promptly address the recent large-scale outages? 

Yes, and I think it’s important to talk about how our endpoint agent is different. One of the things we built in from day one is the ability for the agent to detect if it’s causing the system to blue-screen. If, hypothetically, something catastrophic slipped through our very rigorous testing, the machine might blue-screen a couple of times—but then the agent would automatically take itself out of the loop, and the system would boot normally again.

In the worst-case scenario, you’d temporarily lose the protection of our endpoint agent, but you’d still be able to continue business operations while we resolve the issue.

Another important point is that our company was founded by one of the world’s foremost experts in Microsoft kernel development. This is what he has spent his entire adult life working on. Many of our competitors are led by very capable business and marketing leaders; ours is led by a kernel developer. 

Q: In Canada, is it correct to say we don’t need to follow HIPAA? We’re using PIPEDA and the Canadian baseline cybersecurity controls.

That’s correct. In fact, we’re hosting a webinar this fall on PIPEDA for our customers. Canadian healthcare organizations don’t have to comply with HIPAA. There are a few scenarios where they might—like if they’re doing business with a U.S. covered entity as a business associate—but for the most part, no. If you’re a Canadian clinic, you have equally stringent compliance requirements, but they fall under the Canadian framework rather than the U.S. one.