Posts Tagged ‘secureline’

A majority of companies and hospitals that offer email encryption for HIPAA compliance allow senders to “opt in” to encryption on a message-by-message basis. E.g., if the sender “does nothing special” then the email will be sent in the normal/insecure manner of email in general. If the sender explicitly checks a box or adds some special content to the body or subject of the message, then it will be encrypted and HIPAA compliant.

Opt-in encryption is desirable because it is “easy” … end users don’t want any extra work and don’t want encryption requirements to bog them down, especially if many of their messages do not contain PHI. It is “good for usability” and thus easy to sell.

However, opt-in encryption is a very bad idea with the inception of the HIPAA Omnibus rule. Opt-in encryption imposes a large amount of risk on an organization, which grows exponentially with the size of the organization. Organizations are responsible for the mistakes and lapses of their employees; providing an encryption system where inattention can lead to a breach is something to be very wary of.

Do you have an application or system that needs to send secure messages on demand? Do you need the flexibility to encrypt messages in different ways, to include files, HTML, and read receipts, or to have the messages be fully HIPAA compliant?

What is being discussed here is a very real attack on Opportunistic TLS. I.e. the kind of automated establishment of encryption that can happen when two email servers being their dialog and discover that “hey, great, we both support TLS so lets use it!” In such cases, servers take the “opportunity” to use TLS to encrypt the delivery of an email message from one server to another. Opportunistic TLS is great as it is enabling automatic encryption of more and more email over time (see: Who supports TLS?).

The problem is that the initial negotiation of the SMTP email connection, before TLS is established, occurs over an insecure channel. A man-in-the-middle attacker can interfere with this connection so that it appears that TLS (i.e. the STARTTLS command) is not supported by the server (when it really is). As a result, the sending server will never try to use TLS and the connection will remain insecure — transmitting the email message “in the clear” and ripe for eavesdropping.

facebook has a great feature where you can have all facebook notifications sent to you using PGP-encrypted email. This is great if you want to be sure that noone except for you can read these messages.

We have long held that leaving it to each sender/employee to properly enable encryption for each sensitive message (a.k.a “Opt In Encryption”) is too risky. Why? Any mistake or oversight immediately equals a breach and liability.

Instead, LuxSci has always promoted use of “Opt Out Encryption,” in which the account default is to encrypt everything unless the sender specifically indicates that the message is not sensitive. The risk with Opt Out Encryption is very much smaller than with Opt In. (See Opt-In Email Encryption is too Risky for HIPAA Compliance).

The problem is: many companies use Opt In Encryption because it is convenient when sending messages without sensitive information — you just send these messages “as usual,” without forethought. These companies are trading large risks in return for conveniences.

LuxSci has solved the “Opt In vs. Opt Out” conundrum with its SecureLine Email Encryption Service. You could say that SecureLine enables the “Next Generation” of Opt In Email Encryption — combining both usability and security.