Secure Email (e.g. HIPAA) Compliance
QUESTION: Can you tell me in simple terms about HIPAA secure email, and especially how CheckTLS could help me comply with HIPAA when sending email over the Internet?
See HIPAA How-To for step-by-step compliance instructions.
NIST is the Mother of All Security
Most laws, rules, and regulations like HIPAA, HITECH, PCI DSS, Sarbanes-Oxley, GLBA, SB1386, SEC 17a-4, NASD3010, FRCP, FINRA, etc. refer to the United States government National Institute of Standards and Technology NIST security requirements. In general, any organization that is NIST compliant is compliant with whatever other data protection requirements they fall under.
You Can Use Email to Send Protected Information
NIST says email can be used to transport Protected Health Information (PHI, or colloquially "HIPAA data") over the Internet if the email is TLS encrypted. Encrypting data makes it very very very hard for anyone to read it.
So you can use email to send sensitive information safely and legally, including ePHI (Protected Health Information), ePCI (Payment Card Information), ePII (Personally Identifiable Information), or anything else that should be kept confidential.
Compliance Requires Confidence
NIST requires that protected information in email is encrypted. Just because an email system can encrypt data to NIST standards does not mean it is encrypting data to NIST standards. An email system that can do strong encryption is necessary not not sufficient for compliance. NIST compliance means a high degree of confidence that an email system is encrypting protected information.
The Sender Is Responsible
The email sender is responsible for making sure sensitive data is protected. You must be sure you always use TLS when sending email, and you must be sure the recipient is using TLS. You should be sure you always use TLS when receiving email, or the sender may (should!) refuse to send the email.
One quick test can tell you if your email has TLS turned on for receiving email. One quick test can tell if your email has TLS turned on for sending email. Alas, you have to test if every trading partner has TLS turned on for receiving email.
Opportunistic TLS Is Not Enough
Modern email systems can do strong enough encryption (TLS) to meet any security requirement. But they adhere to the mantra of the Internet: get the data through no matter what. In the case of email, that means sending the email in plain, easy to steal, text if anything goes wrong with the encryption.
Back when the Internet was polite and had an Acceptable Use Policie that forbade advertising, commerce, and spam, this so called "Opportunistic TLS" was the right thing to do. In today's world, on today's Internet, this is the wrong thing to do. And it is specifically called out as unacceptable in many security requirements.
If you get TLS turned on, and even if you test it to be sure, you ARE NOT HIPAA etc. compliant. You are using Opportunistic TLS, and that is not good enough.
You have to be sure TLS is being used.
Confidence in Encrypting Email
You can be confident that your email is encrypted in several ways:
- add a device in-line with your outgoing and/or incoming email server(s)
- route your email from and to an on-line email service
- switch your email to a secure email provider
- add encryption plugins to your devices
- use the encryption you already have
These each have their pros and cons.
In-line Encryption Devices
An in-line device is an additional piece of hardware inserted between your email system and the Internet. It encrypts email going out, and possibly blocks un-encrypted email from coming in. An in-line device could also be an additional feature set of your firewall or other edge security devices.
In-line devices have to be purchased ($$), configured, installed, maintained, and monitored. If (when?) they fail, you have to route around them until they get fixed.
On-line Encryption Service
On-line filters have a monthly fee ($) and have to be configured, and the traffic to/from them has to be protected (encrypted) as well. If (when?) they fail, they are typically fixed before you have to route around them.
Switch to a Secure Email Provider
Switching your email to a good on-line email service is a very good option. Google "HIPAA email provider" for a list of hundreds of options. On-line email does cost a monthly fee ($), you have to protect (encrypt) your connection to them, and they are not as easy as using Outlook directly on your PC/Mac.
Add Encryption Plugins to your Devices
Software like OpenPGP "plugs in" to Outlook on your PC, Apple Mail on your Apple device, and Gmail on your Android device. It uses PGP (Pretty Good Privacy) to encrypt email before it is sent, so your email cannot be viewed by even your own IT people. It requires the recipient to have the same kind of software on their end so they can decrypt your message, and both of you must have agreed on a key, password, or some other trust mechanism ahead of time.
In theory this is a very good option, and Proton is a good implementation. In practice, the difficulty of supporting software on every PC, tablet, and phone that sends or receives email, and managing trust mechanisms (passwords etc.) between every person using email is too high. It is easy to demand that a trading partner use encryption for sensitive information, but it is hard to ask them to put software on their PC or click a link and enter a password to read your email.
Use The Encryption You Already Have
Or you can use your existing email system. Almost every email system today supports TLS encryption. It's probably using it already, or it can be easily turned on.
To use the encryption you already have, you have to make sure your email system:
- receives with TLS
- sends with TLS
- always uses TLS
And you have to make sure the the people you send to are also using TLS. Both ends of the Red Arrow on our home page have to have working TLS encryption. See Use The Encryption You Already Have below.
Whatever Encryption You Use, Test It
No matter how you implement your HIPAA etc. email security, you can only be confident your email is compliant if you test everything regularly. The tests available here on CheckTLS are a great and inexpensive way to independently test your email.
Regular testing and documentation is a very strong part of a security policy, and it makes it easier to pass stringent security audits.
Use The Encryption You Already Have
Compliance with Mandatory TLS
Your email system may have the ability to force the use of TLS for every email using Mandatory TLS. Setup and maintained properly, Mandatory TLS does guarantee that every email is TLS encrypted. In practice this is hard.
If you turn on Mandatory TLS for all your email, you cannot send or receive email from anyone who does not have working TLS. While TLS is becoming more prevalent every year, Google currently estimates that 87% of all email uses TLS. That means more than 1 out of 10 of your emails will fail. And the only way to inform or be informed there is a problem is to figure out who to call and call them.
Some organizations turn on Mandatory TLS for just certain domains. While this is better, in practice it is hard for all the IT departments to maintaining accurate lists of domains and verify them regularly. And again, if TLS fails, some or all email stops and someone has to find and phone someone to fix the problem.
Compliance with Verified TLS℠
Verified TLS℠ is a way to make sure your email system is meeting encryption requirements without the drawbacks of Mandatory TLS. Similar to financial auditing that uses statistical sampling to verify large numbers of documents (invoices, payments, transactions), Verified TLS℠ uses statistical email testing to give you a high level of confidence in your email security.
CheckTLS does not know your specific security requirements and we are not lawyers, so we cannot give legal advice. You should ask your legal department if a security policy based on Verified TLS℠ satisfies your security requirements. See below for a simple draft policy for them to review.
Verified TLS℠ is the "secret sauce" that you can use to make an email system that can do TLS encryption into an email system that is HIPAA compliant.
Strong encryption (TLS) is necessary for HIPAA compliance, but it is not sufficient. You must make sure TLS is always working, both on your end and on the receiver's end. Verified TLS℠ is a recipe of policy, process, and procedure whose main ingredient is regular email audits. As long as the audits are clean and you remediate problems quickly, you can be HIPAA compliant.
What is an Email Audit?
An Email Audit samples your email system to make sure it is HIPAA compliant. The sample can be a look-back at emails that have been sent, or it can be a real-time test of the email system. A look-back selects a sample out of the pool of messages, answering the question: "Were X% of our messages HIPAA compliant?" A real-time test selects a sample out of a time period, answering the question: "Was our email HIPAA compliant X% of the time?"
As long as either sample is big enough and error free, your auditor can have a high degree of confidence that your email is HIPAA compliant.
How Often is Regularly?
It can be daily, weekly, or monthly; whatever your legal department decides is sufficient. Frequency is a trade-off between effort and risk. You could sample every message, or test continuously, and be 100% certain your email is working, although even then you cannot be 100% certain the very next message will be OK. Since it tests right now, real-time testing is a better predictor that the very next message will be OK.
Verified TLS℠ Does More
Because Verified TLS℠ uses CheckTLS tools, you can set the minimum requirements for what "uses TLS" means to your organization. Not only can you tell that TLS is working in general, but that it is using the version(s), ciphers, encryption bits, and other things that you define. Since Verified TLS℠ is an ongoing process, you can quickly and easily tune your requirements as your security standards evolve.
Verified TLS℠ lets you do "what if" analysis to see what effect a security requirement change will have on you and your trading partners.
Do It Yourself Verified TLS℠
You can do look-back sampling manually with no additional tools.
Make sure your have detailed logging turned on for sent and received emails. Extract a sample of records from your send and receive email logs, and check that the proper encryption was used. Document the sample and save it, and repeat the test regularly.
While you can do some real-time sampling using telnet (google: test email with telnet) to test your email system and your trading partners' email systems, there is no (easy) way to manually real-time test that your email system is sending email properly.
Or you can have CheckTLS do it for you. For a monthly fee that is less than the cost of one hour of a person's time.
Verified TLS℠ Using Free CheckTLS
The tools on the CheckTLS web site make real-time testing very easy. Please note that while the CheckTLS tools can be used without a Subscription, our policy requires a paid subscription for commercial use.
Of course you have to do this regularly, and you have to do it for all of your trading partners. Or you can have CheckTLS do it for you. For a monthly fee that is less than the cost of one hour of a person's time.
Verified TLS℠ Using Subscription CheckTLS
A Corporate Subscription to CheckTLS can do all of the required real-time testing automatically.
Setup a Thru BatchTest to test both your sender and receiver at once. Setup one or more BatchTests for lists of your Trading Partners (about 1000 email targets per Batch is best). Schedule these BatchTests to run regularly and email you the results. Have someone review the results, and document what they should do if your, or a trading partner's, email has a problem. Save the results to document your HIPAA compliance.
That's it. Set it and forget it. HIPAA compliance with Verified TLS℠. We cannot think of a way to make HIPAA compliance any easier!
See the instructions about BatchTesting on our site for more information and for how to setup these tests. With a subscription, we can help you setup regular email testing and email monitoring.
See below for a draft HIPAA compliance policy using Verified TLS℠.
Policy for Email Transmission of Protected Information
[define Protected Information here if not defined elsewhere]
Email may be used to transmit Protected Information as long as the communication is protected by Transport Layer Security implemented per NIST Special Publication 800-52: Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations at https://www.hhs.gov/
To assure that Protected Information is communicated securely, YOURCOMPANY verifies that:
- a new trading partner will receive email compliant with NIST guidelines before communicating any PI
- the partner continues to receive email compliant with NIST guidelines
- YOURCOMPANY continues to receive email compliant with NIST guidelines
- YOURCOMPANY continues to send email compliant with NIST guidelines
NOTE: it is the partner's responsibility to verify that they send email compliant with NIST guidelines
Before communicating any Protected Information with a new trading partner, YOURCOMPANY will assure the partner's email system has a CheckTLS.com Confidence Factor of 90 or above. Confidence Factors are retrieved at https://www.checktls.com/TestReceiver.
YOURCOMPANY maintains a list of all trading partners with which it exchanges PI, and it monitors [weekly] the Confidence Factors of those trading partners. Any change in a partner's Confidence Factor creates a problem ticket in YOURCOMPANY's ticketing system for further action.
YOURCOMPANY monitors [weekly] its own email system Confidence Factor, and any change creates a problem ticket for further action.
YOURCOMPANY monitors [weekly] its own system for SENDING email to verify that TLS is properly configured and operable. Any issues found by this monitoring creates a problem ticket for further action.
YOURCOMPANY's auditors check the accuracy of the list of trading partners and a selection of the periodic monitoring reports, and they verify that any changes were properly reported and remediated.