HIPAA Compliance: Technical Safeguards

HIPAA Technical Safeguards require you to protect ePHI and provide access
to data

Help with HIPAA compliance and the HIPAA technical safeguards are one of the most common requests we get from our customers. The Healthcare industry is a major target for hackers and cybercriminals given then amount of valuable data it collects.

Organizations that fail to comply with HIPAA guidelines run
the risk of a substantial fine. And, in the event of a breach, the organization
opens itself up to criminal charges and civil lawsuits. HIPAA fines are
governed by the Office for Civil Rights (OCR), which is a part of the
Department of Health and Human Services. And ignorance is not a justifiable
defense, the OCR will fine you whether the violation was the result of
ignorance or willful neglect.

Typically, when organizations are discussing HIPAA compliance with us they’re referring to the Technical Safeguards. The Technical Safeguards are concerned with the technology that protects ePHI and access to that data. Unfortunately – and to the detriment of many – HIPAA doesn’t explicitly spell out exactly what needs to be done. And the technical safeguards are only half the digital battle – you also need to have administrative safeguards in place to govern those technical safeguards.

So, today we’re going to talk about HIPAA compliance, HIPAA technical safeguards, HIPAA administrative safeguards and what role SSL/TLS and other forms of encryption need to play in a HIPAA-compliant organization. Then at the end we’ll give you a quick HIPAA Encryption Cheat Sheet.

Let’s hash it out.

Explain HIPAA Compliance to me like I’m five

HIPAA is a mess, updates are made via “guidance notices”
issued by the HHS’s Office for Civil Rights (OCR). Originally signed into
effect in 1996 by Bill Clinton, its original intention was to protect and
regulate the availability and breadth of health insurance policies for all individuals
and groups. This is why it’s administered by the OCR. However, more recent
updates to the regulation have made that relationship seem a little less
intuitive.

2003 – Privacy and Security Rules added

2006 – HIPAA Enforcement Rule added

2009 – HITECH Act Requirements incorporated

2013 – Final Omnibus Rule

HIPAA, much like much of our current legislation and our
legal framework, in general, is fairly ill-equipped to keep up with modern
technology and the new threats that evolve with it each day.

So, HIPAA takes a fairly interesting tact when it comes to how it deals with technical safeguards and things like encryption requirements…

Security Policies are Critical

HIPAA’s enforcement arm focuses largely on the underlying processes and security policies that an organization has in place – it calls them administrative safeguards. Perhaps as much as any other regulation, HIPAA seems to accept the fact that $#!% is going to happen. It’s really more concerned with the infrastructure you’ve put in place to detect it, mitigate it, course correct and harden your defensive posture to try to avoid it in the future.

That’s not to say HIPAA doesn’t care about data breaches and other cyber incidents – it absolutely does. But that’s not what’s going to kill you. It’s finding out that you didn’t have the policies and framework in place to detect and handle something like this that will put nails in your coffin. The closest thing I can think to compare it to is in college sports in the US, as administered by the NCAA, there is a penalty for “loss of institutional control” that is catastrophic for any school accused of it.

HIPAA is basically looking at the same thing. Incidents happen, what administrative policies and processes did you have in place to handle them? Do you have the correct organizational controls in place to manage something like this?

HIPAA is Vague on Purpose

While there is no specification as to what specific safeguards
must be put in place, that’s by design. When the original rule was enacted, one
of the biggest things its creators got right was the fact that technology
evolves. Today’s safeguards will be obsolete tomorrow, which renders the entire
regulation outdated and creates a bureaucratic nightmare.

So, HIPAA stops short of mandating specific types of technical safeguard. There is no HIPAA SSL rule, there’s no HIPAA encryption standard.

Instead what HIPAA lays out are a set of responsibilities. How you accomplish them is honestly up to you. As long as you document it. What’s important is that it gets the job done. Now, in reality, there’s only a select few options that will successfully perform those tasks. If you need to create a secure portal for patients to log in, there’s only a few routes you can go. So while HIPAA doesn’t explicitly spell out that you must use SSL/TLS certificates and HTTPS, it makes clear what needs to be done.

There’s also some confusion about the word “addressable” as
it connotes that this might be an optional measure. What this really means is
that encryption/decryption or a commensurate alternative must be used. Failing
that, an organization must justify (and document) why this was not necessary.
The same goes for, “whenever deemed appropriate.” That doesn’t mean the measure
isn’t necessary, it just means that if you’re transmitting information
in-network, behind a firewall, that could be seen as a reasonable alternative
to encryption in that context. Every attempt still must be made to secure the
information though. And when you decide to go an unconventional route you
better have the documentation to back it up.

Remember, while HIPAA doesn’t explicitly lay out everything you need to do to secure your organization’s ePHI data, there are some fairly standard practices that achieve this. Here are some suggestions to get you started:

Implement Encryption/Decryption – Everything that leaves your firewalled servers needs to be encrypted. Likewise, users need to be able to decrypt messages, provided they are the intended recipient. This doesn’t just mean using SSL/TLS to encrypt data in transit, it means actually encrypting the data itself before transmitting it – adding an additional layer of security. VPNs, SSH & at-rest encryption should also be leveraged to secure any connection or data the leaves or resides in your network.

Implement a means of access control – Every employee with access to ePHI needs to be assigned a centrally-controlled unique username and PIN code. Organizations also need to establish procedures that govern the release and disclosure of ePHI in an emergency.

Introduce a way to authenticate ePHI – Much like you would see with document or email signing, it’s important that you can verify the integrity of the data—specifically whether or not it has been altered or destroyed.

Introduce activity audit controls – This should already be a part of any company’s security playbook, but it’s important to record attempted access to ePHI, as well as what’s done with it after it’s accessed.

Facilitate Automatic Logout – This is another one that should be obvious, but it’s crucial that you automatically log users out after a set period of inactivity, lest someone unauthorized access a computer using credentials from its previous user.

Relevant HIPAA Encryption Regulations

Now that we’ve given a cursory look at what major steps need
to be taken for HIPAA compliance, let’s bore down a little deeper. Starting with
a look at the actual HIPAA technical safeguard regulations as they relate to
encryption.

164.306 (1): Ensure
the confidentiality, integrity, and availability of all electronic protected
health information the covered entity or business associate creates, receives,
maintains, or transmits.

164.306 (2): Protect
against any reasonably anticipated threats or hazards to the security or
integrity of such information.

164.306 (4)(2)(e):Maintenance. A covered entity or
business associate must review and modify the security measures implemented
under this subpart as needed to continue provision of reasonable and
appropriate protection of electronic protected health information, and update
documentation of such security measures in accordance with § 164.316(b)(2)(iii)

HIPAA Compliance: Implementing Strong Encryption

Ideally, you should already be securing your data at rest. That means leveraging network security mechanisms like firewalls and monitoring software. You may also want to consider encrypting it. While HIPAA certainly doesn’t insist on encrypting your data at rest it’s advisable, and not just for healthcare organizations either. If your organization has the means, it should be encrypting as much of its network as it possibly can.

Our expertise lies more in the realm of encrypting data in
transit though. HIPAA states that organizations need to “secure PHI as it is
being transmitted.” There are a few ways to accomplish this and multiple
contexts it needs to be accomplished in – email, messenger apps, internet
connections – so let’s cover some of them right now.

HIPAA Compliance: Securing Email

There’s really two different levels you can secure email at.
You can secure the email itself by encrypting it, or you can encrypt the
channel it’s being transmitted over. So, you can use SSL/TLS to securely
transmit an email, but once it gets to the destination network the email would
be readable by anyone because the actual contents of the email were never
encrypted.

Conversely, you can encrypt the email itself, which would
mean that even if it WERE transmitted over an unsecured channel it would still
be secure. HIPAA is “technology neutral” so you could go with either route and
be fine as long as you justified the decision and document it.

It’s probably advisable to do both though. Slapping an SSL/TLS certificate on your email server isn’t a very difficult thing to do, and frankly email signing or S/MIME certificates have come a long way recently and are finally beginning to offer a viable solution to both email encryption and authentication – which is another key tenant of HIPAA compliance.

Don’t Get Breached

91% of cyber attacks start with an email. 60% of SMBs are out of business within six months of a data breach. Not securing your email is like leaving the front door open for hackers.

HIPAA Compliance: SSL/TLS

Whether it’s a website, an app or a payment portal, you need
to be encrypting every single connection. As we cover all the time, HTTP was fine
in the early days of the internet, but when you’re trafficking in something as
sensitive as ePHI, you can’t afford to be transmitting in plaintext. Literally,
HIPAA – or rather the OCR – will fine you. And you can’t afford that.

While there is no HIPAA SSL requirement, adding an SSL/TLS
certificate to your public facing (and even internal) servers is a no-brainer.
Again, HIPAA couldn’t be much clearer about securing data in transit. But while
just installing an SSL/TLS certificate may be enough to satisfy that
requirement, it’s not necessarily optimizing your security or the safety of
your patients/customers.

At a certain size, you may also want to consider a professional certificate/key management option. Most organizations have no idea how many certificates and keys they even have, let alone have a mechanism to manage them all efficiently. As we covered, and will discuss in more depth in a moment, a big part of HIPAA compliance is showing that you have the right administrative processes in place.

If you get audited because an expired certificate or lost
key ends up causing a breach or cyber incident and the OCR sees you’re tracking
SSL certificates on spreadsheets it’s not going to be happy.

Finally, let’s cover the suggested cipher suites for TLS 1.2 and TLS 1.3. Earlier this week we talked about cipher suites in depth, there are currently 37 “approved” TLS 1.2 cipher suites and 5 TLS 1.3 ones. So which of those 42 cipher suites should you support?

Suggested TLS 1.3 Ciphers

Suggested TLS 1.3 Cipher Suites

TLS_AES_256_GCM_SHA384

TLS_CHACHA20_POLY1305_SHA256

TLS_AES_128_GCM_SHA256

TLS_AES_128_CCM_8_SHA256

TLS_AES_128_CCM_SHA256

HIPAA SSL Checklist – What not to use

There are a few algorithms that should absolutely not be
used. Most modern implementations have already deprecated support for them, but
in older implementations they may still be present. This is a large part of why
we only advise supporting TLS 1.2 and TLS 1.3 – earlier versions face known
vulnerabilities due to some of these algorithms.

Do not use:

RSA key exchange

Static Diffie-Hellman key exchange schemes

Block ciphers running in block mode

DSA, DES, RC4, MD5, SHA1

Administrative Safeguards are an equally important part of HIPAA Compliance

As we’ve been discussing the entire article, just implementing
strong security is not going to be enough to satisfy HIPAA requirements.
Securing your networks and data needs to be a part, and a function of, a much
larger administrative process that is constantly working to assess risk, implement
the latest security measures and maintain readily-accessible records.

For that reason, you really can’t comply with HIPAA’s technical
requirements if you’re not already executing a larger administrative plan. In
fact, HIPAA Administrative safeguards represent over half of the HIPAA Security
Rule requirements because they govern so much of the organization’s security in
the first place.

That’s why we subtly suggest an actual certificate and key management platform once you get to a certain size. Just having a bunch of digital certificates deployed might check the boxes for the security/technical safeguards you need in place, but it’s not going to satisfy the administrative requirements. Having an apparatus to manage those certificates will though.

Again, the word “addressable” rears its head when it comes to
administrative safeguards. You still need to satisfy the given burden, “addressable”
just means you’ve got a little more latitude in that area.

The Administrative Safeguards break down into a set of standards:

Security Management Processes

Assigned Security Responsibilities

Workforce Security

Information Access Management

Security Awareness and Training

Security Incident Procedures

Contingency Planning

Evaluations

Business Associate Contracts and Other
Arrangements

The decisions you make with regards to these standards are
going to govern a lot of the other decisions you make on a technical or
physical level. The administrative level is where you make decisions about
employee permission levels and access management, then those policies inform
the decisions that are made at the various touch points.

Not all of these are related to HIPAA encryption requirements, and we’d like to keep this article as focused as possible, but some of these standards do bear commenting on.

HIPAA Compliance – Security Management Processes

Recently our own Casey Crane wrote about how to create a disaster recovery plan, and that article has a lot of overlap with the security management process that HIPAA imposes. Think of this as a fairly holistic strategy to security that should be tackled at the outset of your HIPAA compliance planning. You need to deal with all phases of the security cycle: Prevent, Detect, Contain & Correct.

To accomplish this you’re going to need to perform a couple
of assessments and you’re going to want to document everything as you go. You’ll
want to start by performing:

We’ve got an in-depth guide on how to do both if you just click the link. From there, you want to apply a cyber resilient approach – one that factors in how to maintain business operations in the event of a breach or attack – to securing the various end points and networks you turned up during your initial assessments.

After this has all been done, you also need to revisit your
security management processes regularly so that they are continually evolving
and improving. Now let’s tie this back to encryption and SSL/TLS. For the sake
of HIPAA compliance you’re going to need to inventory all of your certificates and
keys, as well as the end points they’re securing and where they’re being
stored.

There are some tools that can scan and do this all instantly and then there are some tools who try to do it themselves with sharpies and spreadsheets and end up making mistakes. At any rate, you’re also going to want to implement policies for how often keys are rotated and certificates are replaced. Who’s role is that? Do you have notifications set up for expiry, issuance, revocation, etc.? What’s the escalation path for those notifications?

These are all the policies that you’re going to want to
define and document, because they show that you’re not only secure technically,
but that you have the administrative apparatus built out to continue to be
secure technically. That’s what HIPAA means by compliance.

One last word, you also need to develop and document a policy that sanctions employees for failing to abide the security guidelines that you have so clearly defined and set forth for them.

HIPAA Compliance – Employee Training

Your employees are your greatest asset and your greatest threat. A recent study found that organizations attribute up to 34% of all cyber incidents to their own employees.

A recent academic study carried out by a group of US doctors representing top US universities found that over time, and following repeated training campaigns, employee training really does produce results.

But you have to train at regular intervals and you have to make sure that what you’re communicating actually gets through to the people you’re training. I’m not condoning sleeping through power points presentations I’m just saying it happens more than some employees would care to admit.

This is partially why HIPAA suggests sanction programs that can penalize negligent employees when they run afoul of security best practices. Being forced to undergo extra training, financial penalties and the threat of termination are all extremely good motivators for employees to maintain good security hygiene (and just good hygiene in general – looking at you, Jared).

If all else fails, summary executions or a good old fashioned, Roman-style decimation should get the point across. Nothing reminds an employee to look for the green padlock like drawing straws to see who gets bludgeoned to death by their coworkers.

HIPAA Compliance – Record Everything

Frankly, for an industry that already documents every little sneeze and cough, this shouldn’t be too difficult to adapt to – but you need to record everything you do towards HIPAA compliance. Literally, everything. Remember when we discussed the penalties that can be levied by the OCR for HIPAA violations? Well, the heavier penalties come when you don’t appear to have the correct administrative safeguards in place to govern the technical and physical safeguards you’re using.

And the best way to prove you do have such an apparatus built out and fully functioning is documentation. Lots and lots of documentation. Document everything. Did you replace a whole bunch of digital certificates? Document it. Did you change key management platforms recently? Document it. Did you train your employees today? Document it and have them sign attestations that they did indeed train on this date. Did you correct an employee for running afoul of one of your security policies? Document it.

Are you deciding to secure your data using alternative
methods? Document it.

You should have a record of every action, decision and
policy in triplicate and ready to hand over to OCR auditors at a moment’s
notice. Seriously, having adequate documentation can save you millions of
dollars.

And not having it can demonstrate a complete lack of
institutional control.

HIPAA Violations – What are the HIPAA fines and penalties?

HIPAA enforcement is overseen by the same agency that
administers it: the Office for Civil Rights.

While there is a breach notification rule, where the OCR is
the most dangerous for healthcare organizations is in its investigation of
complaints.

Let’s start with breach notifications.

Much like with the GDPR, there is some leeway when it comes to reporting breaches. If the breach affects less than 500 people and doesn’t pose a critical threat to those affected organizations have 60 days following the end of the year to inform the OCR. Larger breaches, involving more than 500 people or representing a major risk, must be reported without delay and are always investigated by the OCR.

Breach notifications must include:

A brief description of what happened

A description of the data that was compromised

Steps those affected should take following the breach

Brief description of the steps taken to investigate and prevent repeats occurrences

Contact information for further investigation

While the OCR can fine organizations up to $1,500,000 per violation (one breach can turn up multiple violations), historically organizations that can show they made every effort to be HIPAA compliant, promptly addressed the breach and took decisive action to prevent further incidents are treated much more leniently.

This is why you need to document EVERYTHING.

As we mentioned though, the bigger threat is from the investigations by the OCR. In addition to major breaches and breaches involving more than 500 people, it also investigates complaints. The OCR doesn’t investigate every complaint it receives, it actually has fairly strict criteria for what it will look into. But when it does, it’s looking at the level of institutional control – what are the administrative safeguards does the organization have in place and how well do they inform the rest of the organization’s security posture?

Even then, the OCR seems willing to work with organizations
that are inclined to work with it. After deciding to investigate a complaint
the OCR contacts the complainant and the organization listed in the complaint.
Typically it plays the role of mediator, if the evidence indicates the
organization is not HIPAA compliant it will attempt to work out a resolution
plan that includes:

Voluntary Compliance

Corrective Action and/or

A Resolution Agreement

Typically these investigations end with a good result for
the organization – provided it does what’s asked of it. When an organization
fails to do that, it’s considered a Tier 4 violation and can carry that maximum
$1.5-million fine.

Here’s a look at the HIPAA Violation Penalties by tier:

A word (or several) about HIPAA Compliance

This is not a complete look at all of the requirements for
HIPAA compliance, rather we’re going over to portions that reside within our
area of expertise: encryption.

And encryption is extremely important for HIPAA compliance,
not just encryption of data in transit, but also encryption of data at rest.
The HIPAA rules are written to be somewhat vague so that they can be applied
more pragmatically based on the needs and scope of an organization.

1 comment

I wonder if you had a chance to look at our mobile HIPAA compliance checklist [https://safetyculture.com/checklists/hipaa-compliance/]? A digital checklist helps businesses to be compliant with HIPPA. I wonder if you can include it on your page?
We’ve put this resource together because our users found it useful and thought your readers might enjoy it too. Keep up with the awesome content!

Author

Hashed Out's Editor-in-Chief started his career as a beat reporter and columnist for the Miami Herald before moving into the cybersecurity industry a few years ago. He also designs the visuals for Hashed Out and serves as the Content Manager for The SSL Store™.