Does TLS Email Encryption Meet Compliance Requirements?

In this article, we discuss what types of email encryption are sufficient to comply with government regulations. TLS encryption is a good option for many organizations dealing with sensitive data and legal requirements. However, TLS does not protect data at rest. Each organization must undertake their own risk assessment to determine which encryption methods are suitable to fulfill legal requirements.

Email Encryption Options

Before we review the requirements for each law, let’s compare email encryption options to determine their suitability for compliance requirements.

SMTP TLS (Transport Layer Security)

There are many ways to encrypt email, but TLS is the easiest to use. With SMTP TLS, messages are transported between the sender and recipient securely. Over 90% of email providers support TLS, meaning that most users can receive emails encrypted with TLS. No passwords are required to read the message- it looks like a normal email in the recipient’s inbox.

SMTP TLS is only able to encrypt emails in transmission from sender to recipient. It does not in protect email messages at rest, including in the sender’s “ent email folder, queued or backed up on the email servers of the sender or recipient, or saved and stored in the email recipient’s folders. Anyone with access to the email inbox can read the secure message.

Secure Portal Pickup

Secure Portal Pickup encrypts messages both in transit and at rest. It works like this:

1. The sender sends the message and attachments.
2. The message is encrypted and stored in a secure database.
3. The recipient is notified via email with a link to retrieve their message. This notice does not include any of the sensitive information from the original message.
4. The recipient connects to a secure website, verifies their identity, and reads the message over a secure connection.
5. The recipient can reply securely back to the sender.

Secure Portal Pickup allows users to send secure messages to any recipient. It is very secure but requiring users to login to another website to read their messages means that a large portion of recipients just won’t bother to read them.

PGP and S/MIME

When comparing to TLS and Secure Portal Pickup, PGP and S/MIME are two technologies that perform the same kind of encryption but through slightly different methods. In both cases, the message body and attachments are encrypted inside of the message itself. This protects the data in transmission and at rest.

However, PGP and S/MIME are difficult to use. The sender and recipient must be able to communicate their keys to each other before sending secure emails. This is not an issue if everyone involved uses the same secure email provider or understands email technology. PGP and S/MIME are impractical for communicating securely with external recipients who are not tech-savvy.

Does TLS Email Encryption Meet Compliance Requirements?

Since TLS is widely supported and easy to use, many organizations would like to encrypt emails this way. However, since TLS emails are visible as plaintext at rest, TLS may not be sufficient to meet compliance requirements. Organizations should review their legal obligations to determine if they need to encrypt messages at rest. If so, Secure Portal Pickup or another form of encryption should be used to ensure sensitive data is secured.

Now we dive into some of the most common US government regulations and discuss the suitability of TLS for each. Note that this is not legal advice, and organizations should conduct their own risk analysis to determine what course to take.

HIPAA: Health Insurance Portability and Accountability Act

HIPAA strictly requires that all Electronic Protected Health Information (ePHI) must be encrypted during transport. The law says that ePHI can be encrypted by:

“the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key and such confidential process or key that might enable decryption has not been breached. To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.”

They go on to state what valid encryption processes for HIPAA compliance are:

“Valid encryption processes for data in motion are those which comply, as appropriate, with NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113, Guide to SSL VPNs, or others which are Federal Information Processing Standards (FIPS) 140-2 validated.”

In other words, if TLS is configured to meet NIST standards, it can be used. Emails do not need to be encrypted at rest. If they are, it can provide protection from liability if a breach occurs. TLS-only email encryption is good enough for email security under HIPAA; however, each organization must perform its own risk analysis and determine what level of encryption is appropriate to minimize risk.

TLS Okay? YES, but consider your internal Risk Analysis.

GLBA: Gramm-Leach-Bliley Act

With respect to email encryption, GLBA has a Safeguards Rule. This rule does not reference any particular technology or encryption mechanism, instead it focuses on ensuring that each organization:

“…sets forth standards for developing, implementing, and maintaining reasonable administrative, technical, and physical safeguards to protect the security, confidentiality, and integrity of customer information.”

In GLBA, businesses must:

1. ensure the security and confidentiality of customer information;
2. protect against any anticipated threats or hazards to the security or integrity of such information, and
3. protect against unauthorized access to or use of such information that could result in substantial harm or inconvenience to any customer.

There is no specific mandate for how organizations must protect their email. Unencrypted email transmission is a risk that can be mitigated by using SMTP TLS (or one of the other methods). Similarly, it could be decided that based on the email contents and storage, explicit email encryption at rest is not needed to mitigate the risk.

TLS Okay? YES, but consider your internal Risk Analysis.

SOX: Sarbanes-Oxley Act

All U.S. Publicly Traded Companies must abide by the Sarbanes-Oxley Act (SOX). Sarbanes-Oxley is like GLBA in that it does not address email encryption in particular, but instead seeks to ensure that organizations analyze their risk and establish internal controls to protect sensitive information. Furthermore, SOX requires that organizations provide evidence of the effectiveness of these internal controls in their annual reports.

While SOX does not discuss email encryption, it is consensus-established that the COBIT and COSO frameworks are good guidelines for SOX compliance. COBIT says:

DSS5.11: Exchange of sensitive data: “Exchange sensitive transaction data only over a trusted path or medium with controls to provide authenticity of content, proof of submission, proof of receipt and non-repudiation of origin.”

TLS meets most of these criteria (though the other encryption methods provide more). Adding other technologies like DKIM to email workflows will add protection against forgery and non-repudiation of origin without having use PGP, S/MIME, or Secure Portal Pickup.

DS11.6: Security Requirements for Data Management: “Define and implement policies and procedures to identify and apply security requirements applicable to the receipt, processing, storage, and output of data to meet business objectives, organizational security policy, and regulatory requirements.”

DS11.6 can apply to “encrypted email at rest.” There is no mandate to encrypt individual messages. Organizations are only required to review their risk and implement policies and procedures to protect that data in an appropriate way.

When considering SOX compliance, as with GLBA and HIPAA, it comes back to the organization’s processes and risk analysis to determine what level of encryption is appropriate for compliance needs.

TLS Okay? YES, but consider your internal Risk Analysis.

SB 1386: California Senate Bill 1386

California Senate Bill No. 1386 (“SB 1386”), requires any company that stores customer data electronically to notify California customers of a security breach to the company’s computer system if the company knows or reasonably believes that unencrypted information about the customer has been stolen.

This is an example of a breach notification law that exists in most states. It does not say anything explicit about email, but it does imply a lot. Customer data is often contained in emails. If emails containing unencrypted customer data are breached, SB 1386 would require companies to notify their customers.

TLS encrypts email during transport. Using it prevents the capture of customer data in transmission from the sender to the recipient.

If stored email is breached and not encrypted at rest, it triggers the breach notification requirement. Companies need to consider where and how email under their control is stored. If there is a significant risk of stored email being breached, then companies may choose to encrypt emails or the disks/drives where they are stored.

This would start with encrypting end user devices (phones, laptops, exchange servers, etc), as these are the most frequent breach targets. Organizations should also consider the likelihood of the breach of email stored with SaaS (Software-as-a-Service) cloud email providers.

TLS Okay? YES, but consider your internal Risk Analysis.

NASD 3010

NASD 3010 is concerned with written policies and the oversight of correspondence with the public relating to investment banking or the securities business. As such, compliance with NASD 3010 has to do with transparency and email archival, but not with how email messages are transmitted or stored with respect to encryption.

TLS Okay? YES.

FRCP: Federal Rules for Civil Procedure

FRCP ensures that organizations retain copies of emails so that they can be retrieved as evidence in civil lawsuits. This imposes a strong requirement for archiving copies of all sent and received email messages.

FRCP does not delineate when or how the original email messages themselves should be encrypted. Email archives need to be secured and tamper resistant. As long as archival happens in real time with respect to the actual flow of email, the encryption of those messages is of marginal relevance to this law.

TLS Okay? YES.

SEC 17a-4: Securities and Exchange Commission

SEC Rule 17a-4, enacted on May 12, 2003, lays out requirements for the retention and archiving of electronic communications. This rule describes how to properly archive email communications and other documents.

Like with FRCP, SEC 17a-4 does not delineate when or how the original email messages themselves should be encrypted. That is really the purview of Sarbanes-Oxley. So, SEC 17a-4 compliance is not relevant to the use of TLS for email delivery.

TLS Okay? YES.

FINRA: Financial Industry Regulatory Authority

The key FINRA regulations related to email include:

FINRA 3110: Requires each firm to preserve accounts, records, and correspondence in adherence with applicable laws and FINRA rules, regulations, and policy statements, as well as those prescribed by SEC Rule 17a-4.

FINRA 3010: Requires firms to maintain a system to supervise transactions and correspondence with their users. Companies should establish and maintain a supervisory system with written procedures and review incoming and outgoing electronic correspondence on a regular basis.

FINRA is about archival, data preservation, supervision of compliance with procedure, and review of correspondence. Like FRCP and SEC 17a-4, FINRA does not specify when or how the flow of email messages should be secured.

TLS Okay? YES.

PCI DSS: Payment Card Industry Data Security Standard

PCI is not a law, but a set of requirements imposed by the credit card industry. Many small organizations want to send credit card information over secure email, but they need to proceed with caution.

PCI says in section 4.2.b: “Verify the existence of a policy stating that unencrypted PANs (Primary Account Number- i.e. the credit card numbers) are not to be sent via end-user messaging technologies.”

E-mail, instant messaging, SMS, and online chats can be easily intercepted across internal and public networks. Do not utilize these messaging tools to send credit card numbers unless they are configured to provide strong encryption.

Never send credit card numbers over regular email. If necessary to send credit card numbers over email, they must be encrypted before transmission. TLS should not be used, because it cannot secure the PAN at rest. PGP, S/MIME, or Secure Portal Pickup are better options for sending highly sensitive information like credit card numbers.

TLS Okay? NO.

Is TLS Email Encryption Sufficient for Compliance?

It would be simpler if the government’s guidelines and requirements spelled out exactly what types of encryption to use. However, there are good reasons why the laws are written ambiguously- they provide flexibility for organizations to implement technology consistent with their particular and unique business methods.

The regulations described above leave the choice of security implementation up to the security officer, who must make choices based on a detailed risk analysis and evaluation of how the use of various technologies would impact business processes, profits, and risk profile.

In many cases, TLS satisfies compliance requirements. However, even if it meets requirements, businesses may want to opt for a stronger method of encryption to reduce liability. At a minimum, TLS should be used for every email. To reduce risk, organizations should choose encryption technologies that are flexible and enable users to dial up the level of security for highly sensitive emails (like those that contain medical records or credit card data).

What are the next steps?

1. Perform a risk analysis to understand where sensitive data is stored and sent and what rules govern the organization.
2. See if current email usage aligns with risk mitigation.
3. Find an email security provider, like LuxSci, that enables secure SMTP TLS and provides configurable options for more secure email encryption methods, to tailor email usage to changing security needs.