Protected Information

Security of electronic information is more important to corporations now than ever before. Data security has visibility at the C-level of every company that keeps any information about people. The ever increasing number, breadth, and depth of information security rules has companies scrambling to create and meet compliance requirements like:

  • Protected Health Information (PHI) to meet HIPAA, HITECH, and Omnibus regulations.
  • Payment Card Information Data Security Standard (PCI DSS) to process credit cards.
  • Personally Identifiable Information (PII) to stay out of the news.

Emailing Protected Information

Information about Individuals must not be shared with unauthorized persons. When sending over the Internet, Personal Information must be encrypted. Internet encryption is required by law, by corporate policy, by industry best practices, and by common sense.

For example, HIPAA’s section 164.312(e)(1), relating to Transmission Security, calls for Covered Entities to “Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network” and to “Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.”

There are three main ways to encrypt email:

End-to-end
Encrypt each message at the sender's PC, and decrypt it at the receiver's PC.
Forced-transit
Force the sending and receiving email systems to encrypt the email in transit.
Test-and-verify
Test new email connections before using them, and continuously test existing connections.

End-to-end

End-to-end encryption is the safest and hardest way to encrypt Internet email. Individual messages are encrypted at the sender's PC and only decrypted on the receiver's PC. A variation on this theme is store-and-notify, where the sender uploads the message or the message payload, and the receiver goes to a web site and retrieves it.

End-to-end encryption requires a client on every sending and receiving PC. Store-and-notify can get around requiring software on the PCs, but it requires users to navigate to a web page and enter a login/password to send and receive email.

Forced-transit

Forced-transit encryption is mandatory TLS. Most email systems are opportunistic TLS, meaning they use TLS if both sides agree to use it, otherwise they fall back to insecure (normal) email. This is insufficient to meet HIPAA/HITECH and PCI DSS regulations. TLS encryption is sufficient, but the automatic fall back to insecure email is problematic, especially since there is no notification of TLS failure.

Companies can use TLS to meet HIPAA/HITECH and PCI DSS by turning on mandatory TLS, meaning any email has to be encrypted or it is bounced back to the sender. This requires no changes on either the sending or receiving ends, and requires no additional steps from either sender or receiver. TLS is widely used for Internet email, but it is not used everywhere, so turning mandatory TLS on for every domain results in so many bounces as to make email unusable. This will change as TLS continues to become more and more ubiquitious, but until then mandatory TLS is typically turned on just for specific domains. For example ABC company configures their email system to mandate TLS for any email being sent to XYZ company.

As long as the company using mandatory TLS regularly audits their list of required TLS domains and checks that their software is actually requiring TLS, this method typically meets all the requirements for protecting PHI, PCI, and PII. The CheckTLS "Assure TLS" tests can be used to verify that TLS is properly configured to mandate TLS; it cannot, however, verify that the right domains are listed for mandatory TLS.

Test-and-verify

Test-and-verify is the easiest way to achieve compliance with email security requirements. Every modern email system has TLS encryption capability, and most companies with any security requirements have it turned on. TLS encryption is HIPAA and PCI compliant. The problem with using these email systems for HIPAA or PCI is in the Internet RFC email standard: it requires these email systems to fall back to plain text, unencrypted, and non-HIPAA non-PCI compliant email if for any reason TLS isn't available or doesn't work. This is called "Opportunistic TLS", and Opportunistic TLS is not HIPAA or PCI compliant.

Opportunistic TLS will use TLS as long as both sides have it working. TLS encryption is compliant. If a company can make sure that TLS is being used, i.e. that their email is not falling back to sending in unencrypted clear text, then their email is HIPAA and PCI compliant, even though it may labeled "opportunistic TLS".

The easiest way to make sure that TLS is being used is to test it.

Most modern email systems can be HIPAA and PCI compliant without any changes from either the sender or the receiver. All that is needed is regular testing to be sure these systems are working properly and are using TLS.

Test-and-verify with Verified TLS℠

CheckTLS is used by some of the largest hospitals and financial institutions in the world as part of their compliance policies and procedures for HIPAA, PCI DSS, and others. They use CheckTLS to implement a "Test-and-verify" (see above) email security policy. Because NIST, HIPAA/HITEST, and most corporate policies consider TLS encryption of email to be sufficient, an institution just needs to be sure that TLS is working.

Here's what they do:

  • regularly test that they are using TLS to send email
  • regularly test that their trading partners are using TLS to receive email

While it is not technically their responsiblity, most organizations we serve do regularly test that they are using TLS to receive email as well. It is the sender's responsibility to make sure encryption is used.

See Secure Email Compliance for more information about meeting HIPAA and PCI DSS compliance, and Secure Email Compliance Policy for sample security policy language.

We can help you with the testing required to meet HIPAA and PCI DSS compliance with Verified TLS℠.

Or Contact Us.