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.
That’s why the Health Insurance Portability and Accountability Act of 1996 set up a framework to help protect Electronic Protected Health Information (ePHI). Today, 23 years later, HIPAA compliance is critical.
Also, a complete nightmare.
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.
Worst of all, HIPAA is at once, terribly stringent yet purposefully vague.
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.
HIPAA Technical Safeguards
One of the most important parts of HIPAA Compliance is that ePHI, whether in transit or at rest, needs to be secure once it leaves the organization’s internal firewalled servers. Encryption is the best option for this, but it needs to meet National Institute of Standards and Technology (NIST) standards, too.
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)
164.312 (a)(2)(IV): Encryption and decryption(Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.
164.312 (c)(1): Standard: Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.
164.312 (e)(1): Standard: Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.
164.312 (e)(2)(ii): Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.
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.
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.
You need to implement SSL/TLS correctly. What does that mean?
HIPAA SSL Checklist
An optimized, HIPAA compliant SSL/TLS implementation:
- Only supports TLS 1.2 & TLS 1.3 (no support or fallback options for SSL 2.0, SSL 3.0, TLS 1.0 or TLS 1.1)
- Uses an ephemeral key exchange scheme for Perfect Forward Secrecy
- Supports only the most secure cipher suites
- Rotates keys and certificates on a regular basis (at least once annually)
- Has strict CAA records set for all relevant domains and servers
- Leverages HTTP Strict Transport Security (HSTS)
- Monitors Certificate Transparency logs, OCSP logs and CRLs
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?
Cipher suites are groups of algorithms that govern the cryptographic functions in an HTTPS connection. Picking the wrong ones can leave your website at risk. Learn more.
We’ll take out the guess work and just tell you:
Suggested TLS 1.2 Ciphers
|Key Exchange||DHE, ECDHE|
|Digital Signature||RSA, ECDSA|
|Bulk Encryption||AES_GCM or AES_CCM, CHACHA20|
Suggested TLS 1.2 Cipher Suites
Suggested TLS 1.3 Ciphers
|Bulk Cipher/AEAD||AES_GCM or AES_CCM; CHACHA20_POLY1305|
Suggested TLS 1.3 Cipher Suites
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
- 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.
That’s insane, but not entirely surprising. And one of the biggest culprits is plain old ignorance. 70% of US employees have no idea about cybersecurity best practices. Phishing simulations have found that about 1 in 7 hospital employees are liable to click on a phishing email.
Fortunately, there is hope. Education really does work.
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.
Whether or not that was wise is debatable, a recent study found that the Healthcare Industry ranked 15 out of the 18 industries surveyed in terms of cybersecurity.
HIPAA compliance is a great first step, but don’t stop there.
HIPAA Encryption Cheat Sheet
Under HIPAA, an organization is required to:
|164.306 (1)||Ensure the confidentiality, integrity and availability of all PHI (Personal Healthcare Information)|
|164.306 (2)||Protect PHI against any reasonably anticipated threats (cyber attacks, breaches, etc.)|
|164.306 (4)||(2)(e) Continue to review and upgrade security measures as needed|
Encryption/Decryption is needed for:
|164.312||(c)(1) Implement policies and procedures to prevent improper alteration/destruction of PHI|
|164.312||(e)(1) Secure PHI as it is being transmitted|
- 164.312 (c) – Data at Rest
- 164.312 (e) – Data in transit
- Partners must also demonstrate and maintain appropriate technical safeguards
Other required safeguards:
- Must have a mechanism for detecting and defending against cyber attacks
- Must conduct a proper risk assessment
- Must have employee information access management set up
- Must have unique user identification
- Must have login monitoring and a strong password policy/management
- Must train (and document training) employees on cybersecurity and data security regularly
- Must have an antivirus mechanism
- Must have:
- Data backup plan
- Data recovery plan
- Emergency mode operations plan
- Emergency access procedures
- Physical safeguards (things like locks and alarm systems, not relevant to us)
As always, leave any comments or questions below…