Is Amazon Simple Email Service (SES) HIPAA Compliant?

Because Amazon Web Services (AWS) is very inexpensive, very well known, and offers “HIPAA-compliant” solutions to some degree, we are often asked if, and to what degree, Amazon Simple Email Service (SES) is HIPAA compliant. AWS is a big player offering countless services on which companies can build and/or host applications and infrastructures. One of the myriad of services provided by Amazon is their “Simple Email Service” (AWS SES for short).  Organizations are very interested in determining if the services offered are appropriate for their use cases and if use of specific Amazon services will leave them non-compliant or at risk.  Indeed, the larger the organization, the more concern we encounter.

 

Amazon Simple Email Service (SES) & HIPAA Business Associate Agreement (BAA)

The interest in signing a HIPAA Business Associate agreement is one first and most fundamental aspects in determining if a company provides HIPAA-compliant services or not.  The BAA is required by law and specifies the shared responsibility between the customer and the organization (i.e., Amazon in this case) for properly protecting sensitive patient information.

Like all the big players, Amazon does sign HIPAA Business Associate Agreements (BAAs) with customers. The AWS BAA is a standardized document that covers many of their services and which is not negotiable.  I.e., if your organization requires special terms, modifications, or considerations in this contract, Amazon will not be accommodating at all.  The AWS BAA also does not cover all of their services; the list of services that it does cover is expanding and it does now include  SES, the “Simple Email Service”.

However, one must be very careful with business decisions at this point.  Just because a company will sign a BAA with you does not mean that they will protect your data in the way that you need.  For example, Google with sign a BAA with you to “cover” G Suite; however, Google does not provide HIPAA-compliant outbound email encryption with G Suite.  If you naively sign their BAA and then start sending sensitive emails — you will be immediately out of compliance.  You really need to know the technical details of what your organization needs to accomplish, how that fits into your compliance requirements, and what is specifically being promised in a particular Business Associate Agreement and in a particular solution.

Proceeding without this context can be considered negligence.

What does Amazon Simple Email Service (SES) Do?

At first blush, SES is for “Sending Email.”  However, that is an incomplete assessment of its feature set.  As of this writing, SES:

1. Can be used to send email
2. Can be used to receive email and save it in an AWS S3 Bucket

So, the scope of SES is larger than just “Sending Email.”  According to Amazon’s standard documentation on using their services in a HIPAA-compliant context:

“AWS requires customers to encrypt PHI stored in or transmitted using HIPAA-eligible services in accordance with guidance from the Secretary of Health and Human Services (HHS).”

“AWS follows a standards-based risk management program to ensure that the HIPAA-eligible services specifically support the security, control, and administrative processes required under HIPAA. Using these services to store and process PHI allows our customers and AWS to address the HIPAA requirements applicable to our utility-based operating model.”

“When determining how to implement encryption, customers may evaluate and take advantage of the encryption features native to the HIPAA-eligible services, or they can satisfy the encryption requirements through other means consistent with the guidance from HHS. “

What this means is that AWS SES has “security, control, and administrative processes required under HIPAA” and that customers need to:

1. Evaluate and determine if any of the encryption services native to SES are appropriate for the desired application, and if so, ensure that those are used, OR
2. Use external appropriate encryption services.

It is completely up to Amazon customers to fully understand the AWS solutions and to do the right things.   This is the opposite of “if I buy it and use it, I’m fine.”

This is what we often see from email providers and is something that we call “quasi-compliant.”  Amazon is agreeing to take care of the data stored at rest, the administrative and other requirements on their site; however, it is not clear if the “encryption services” for email are actually appropriate or adequate.  And that is “OK” … as you can always either (a) not actually email outbound PHI (you could just receive inbound PHI), or you could (b) introduce your own email encryption to fill the compliance gap.  That is up to you, not Amazon.

Amazon Simple Email Service: Email Encryption

Amazon can encrypt your inbound email before it is stored in your S3 buckets.

For those interested in using SES for sending outbound email messages containing ePHI, it is critical to understand the email encryption options provided by AWS so that they can evaluate and determine if they can properly be leveraged meet their compliance requirements.  Amazon lays these details out in its SES Developer’s guide.  In particular, SES supports:

1. Opportunistic TLS: SMTP TLS encryption will be used, if possible, when messages are transmitted between Amazon and the recipients’ email servers.
2. Option to not send if TLS is not supported: You can choose to have messages dropped if AWS can not use TLS to encrypt the transport to recipients.

There is also talk in this developer’s guide of support for end-to-end encryption via PGP and S/MIME.  Reading this content a little more deeply, it is clear that SES does not actually implement PGP or S/MIME at all … it just “allows you” to send and receive email that is already encrypted with PGP and S/MIME, just like it allows you send and receive any other normal email message.  If you want to use S/MIME or PGP, the implementation of that technology is on you as the developer.

So, Amazon’s email encryption support is on par with most “quasi-compliant” email providers — they can do TLS if possible, and can allow you to not send if TLS is not possible.  There are several severe limitations of clinging on to this level of email security in a compliance context.

What if TLS is not supported by a Recipient?

Not all recipient email servers support SMTP TLS for email delivery.  While TLS support has been steadily growing over time, it is certainly not universal.  If you need to send email to someone whose servers do not support TLS, then it is clear that you can not rely on AWS SES to provide encryption for you: you will need to either (a) not send the email, or (b) provide encryption yourself.

But how do you know?  If you are sending sensitive messages to 1000s of people, how do you know whose email can’t accept TLS encryption.  It seems you choices are:

1. Send email using AWS’s default settings — some messages will be delivered without TLS and be non-compliant, leaving you in danger of breach or negligence.
2. Enable AWS’s feature to not delivery without TLS.  Then, some messages will not be delivered at all.  In cases such as email marketing, this could be “Ok.”  However, in general email delivery needs to be reliable or it is not useful.
3. Do not rely on AWS’s TLS encryption and use some other form of encryption or other email service.

Is TLS encryption in general HIPAA compliant?

HIPAA does require that ePHI be encrypted in transport and that is what SMTP TLS does. There is a general consensus that TLS is minimally viable for of email encryption for HIPAA compliance.  However, the use of SMTP TLS is riskier than other forms of encryption in the context of compliance.  For this reason, we often see customers either:

1. Choosing to only use TLS in limited scenarios (i.e., for messages between employees in their organization), or
2. Using more secure methods for messages that are more sensitive.  E.g., they may send an appointment  notice over TLS but send lab results and other more sensitive communications via more secure methods (such as Escrow, a.k.a. “web portal pickup”).  These more secure methods, among other things:
   1. Ensure the messages are encrypted at rest.
   2. Implement authentication mechanisms to ensure that only the intended recipient can see the message.
   3. Add more logging and auditing.

The upshot is that the onus is on each organization to understand the nature of their email sending: What kinds of messages are going where?  What are the sensitivity levels? etc.  Then, to determine the degree to which using only TLS is appropriate for their compliance needs and risk profile.

Is SMTP TLS in Amazon Web Services Simple Email Service actually HIPAA-compliant?

Assuming that TLS use is “OK” for some or all of your email sending needs, organizations must then evaluate and determine if the type of SMTP TLS implemented by AWS is appropriate for their compliance.  If it is not, it should not be relied upon for HIPAA-compliant email encryption.

TLS (Transport Layer Encryption) is actually a complex encryption system that has evolved over time and which can be implemented in many ways.  See: All about email delivery over TLS.  In particular, for HIPAA compliance, TLS must use the recommendations set forth in the NIST guidelines.  In particular, for compliance, TLS v1.2+ must be used along with a specific set of encryption ciphers.  See: What level of SSL and TLS is Required for HIPAA Compliance?

If we cut to the chase and look at how AWS SES implements TLS, we see:

“Amazon SES supports TLS 1.2, TLS 1.1 and TLS 1.0 for TLS connections.”

This by itself indicates that TLS delivery may use non-compliant forms of the TLS protocol for email delivery, and there is no way to restrict your messages to using TLS 1.2+ only.  Furthermore, AWS is completely silent on what “ciphers” they support.  So, even for TLS 1.2 connections, it is quite likely that they support the delivery of messages through ciphers that are weak and not NIST-recommended (as that is a tight list compared to the overall list of ciphers available for use).

To use SMTP TLS effectively in a HIPAA-compliant manner, organizations need to be sure that messages are only transported using TLS in a NIST-recommended way.  There is absolutely no way to ensure that this happens with Amazon SES.  Hence, LuxSci would recommend that anyone using SES in a HIPAA-compliance context not rely on Amazon email encryption for compliance, at all — else you are in non-compliance for some unknown subset of email message deliveries and that puts risk and liability on you should there be a breach.

Are there other HIPAA Considerations with Amazon?

Especially for larger organizations with a smaller risk tolerance, there are many reasons to be well-considered in your selection of a provider.  For Amazon AWS, some of these considerations include:

• Not dedicated.  SES in Amazon uses a big shared cloud. Sure, you can pay to send outbound email through a dedicated IP address, but your messages are still flowing through some large shared cloud infrastructure. There is much less risk if you choose a solution where your servers and even your networking hardware are dedicated to your organization.
• Not automatically compliant / high risk.  You have to actively understand and configure things properly for compliance to be remotely possible.  It is very easy to make a mistake and land in non-compliance land.
• Knowledge required.  It is completely up to Amazon customers to fully understand the AWS solutions and to do the right things.  This is the opposite of “if I buy it and use it, I’m fine.”
• Not HITRUST.  Amazon AWS has a number of security certifications; however, they are not HITRUST-certified.  HITRUST is the de facto agreed-upon standard that large organizations use to evaluate an organization’s policies, procedures, and practices with respect to HIPAA compliance.

So: Is Amazon Simple Email Service (SES) HIPAA compliant?

Yes, it can be, but a company would be hard-pressed to find a way to make sending of ePHI over SES actually HIPAA compliant.