Yearly Archives :

2017

Gmail TLS Email Encryption – is it good enough? 1024 403 Alex Mushkin

Gmail TLS Email Encryption – is it good enough?

Major cloud email services such as Gmail and Yahoo Mail announced their use of TLS about two years ago (TLS is transport layer security – a type of encryption that can be applied to email transmissions). Both services announced they would send email (and attachments) using TLS whenever possible – which means – whenever the receiving email service or server is configured to accept TLS encrypted email.

For the average user – this is a good thing. We certainly hear enough these days about unsecure email and exposure of private conversations – so we should all be thinking about using a secure email service just to keep our communications private. After all – if we wanted them to be public – we could always post them on Facebook! And private conversations can cause harm if exposed to the wrong people – even if there’s nothing nefarious being disclosed regarding our business or personal dealings.

As noted – TLS has been the default transmission policy for Gmail for at least two years – but it was just brought to my attention that you can check if a Gmail message is sent or received using TLS by clicking on the ‘details’ of the message. It looks like this:

Gmail offers details of what TLS encryption is and how it is applied – ‘Learn More’ will take you to a page that describes what is happening when Standard (TLS) encryption is being used:

“TLS is being adopted as the standard for secure email. While it’s not a perfect solution, if everyone uses it, snooping on email will be more difficult and costly than it is today.”

‘While it’s not a perfect solution’ – this means it’s applied ‘opportunistically’. If the far end email service/server is configured to accept TLS – great – everything is secure end-to-end. If not – it drops back to unsecure delivery – and the risks of exposure that presents.

Gmail links to another page that goes into more detail about how TLS works – and again notes that it’s not going to work all the time:

 “Whenever possible, Gmail protects your info by using Transport Layer Security (TLS) to automatically encrypt emails you send or receive. TLS doesn’t work with messages from some email services. 

If you’re on a computer or Android device, you’ll know an email is not encrypted when you see the No TLS icon redlcok1 or redlock2 . It looks like an open red padlock.”

SafeTLS Trumps Opportunistic TLS Email Encryption

Where Gmail’s ‘opportunistic TLS’ is good, DataMotion SafeTLS is better.  As an overlay to virtually any email service or address, SafeTLS checks the availability of TLS email encryption before it send the message – and if it is not available, it falls back to an alternative email encryption method that is not dependent on the recipient’s email service or server – so it always works.

SafeTLS gives users and recipients the best of both worlds. TLS is great because it is virtually transparent to the sender and recipient – it just works, and there’s no complexity to receiving the message or attachments. But to be really confident your message is secure (READ COMPLIANT!) – SafeTLS is the way to go. Yes – there’s a small cost to have it. But exposing your secrets, or the regulated information of a patient, partner, or business associate – can cost a whole lot more – in reputation, notification costs, fines or intellectual property loss.

Is TLS email encryption good enough? 1024 403 Alex Mushkin

Is TLS email encryption good enough?

As most people are aware, the need for secure messaging, email encryption or email compliance is on the mind (or should be) of almost all managers inside every business. The need for TLS (Transport Layer Security) can vary from avoiding a data leak, ensuring there are no prying eyes on confidential information or even something as simple as validating that someone received your message.

Working for an email encryption and security company I constantly get questions and inquiries about TLS  and why using TLS isn’t “good enough”. Most of the time these questions are immediately followed by statements like “It’s good enough, and it’s free!” Free? Sure, but remember there is no such thing as a free lunch!

Here are a few different points that should be considered before making a decision on whether TLS is “good enough” for you and your organization’s email needs.

What is TLS?

Before any comparisons or pro’s and con’s discussion, we need to establish what TLS actually is and where it is used. TLS stands for Transport Layer Security and is intended to secure the communications between two points. When we talk about TLS in relation to a web browser we have the little “lock” icon on our URL bar showing a secure connection from the web server to your browser. This means when you submit a form with your credit card information on it, no one can snatch that data if they intercepted your web session.

Same thing for email. When you have one email server send a message to another email server over TLS, the connection itself is encrypted so no one can intercept the payload information. But, the actual data itself is still unencrypted. It’s secure and compliant because it was sent over an encrypted channel.

When we talk about encryption in every day talk, we have openly accepted and use the “TLS” acronym to imply that it only applies to email and “SSL” as it applies to the web. In reality you can apply TLS encryption to a variety of protocols, including HTTP for the web and SMTP for email. For clarity, the predecessor of TLS is SSL or Secure Socket Layer, which was more commonly used on the web before email so hence the common associations of the acronyms. Now that we have a bit of a primer we can take a deeper dive and talk about workflows as they relate to email.

TLS and SPAM/Anti-Virus Workflows

When we talk about servers we know that if TLS is used between servers then that connection is secure. It’s assumed that if two servers have TLS then the message is secure and they don’t need to worry about anything. This is a VERY common misconception that while mostly accurate needs to have some additional questions asked of the recipient mail server.

Most companies have some kind of SPAM and Anti-Virus service implemented. We know that those services or appliances look at messages and if they are deemed “OK” they are then delivered to the receiving mail server. The question needs to be asked does SPAM or Anti-Virus service actually sends messages to the receiving server over TLS or not. Just because a sender sent the message and something received it via TLS does not mean that the whole connection to the receiving server is encrypted. This is a potential point for a breach. So it is important to ask recipients where auto TLS delivery or a forced TLS delivery is in place, to see if true end-to-end TLS is implemented, or if there is a gap.

TLS and Replies

As an email recipient sending a reply, we can have a scenario where the recipient needs to reply securely. Just because a message is received from someone over TLS there is no guarantee that the recipient’s sending email server will use TLS to send a reply. The question that needs to be asked of the recipient’s IT team is about priority of use. For example, will TLS always be used? Is there a fallback to an encryption or delivery provider in situations where TLS is not available or is there even support of TLS for sending messages?

The number of organizations that I see where they accept TLS due to having some kind of email SPAM or AV service but don’t have TLS in use for inbound or outbound email on their server is more than I would like to admit. So if you are adopting TLS as your primary method for security it’s important to establish trusted relationships with the people you send messages to and ensure that you (as the sender) have your email server forced to send messages only to those recipients via TLS.

Special Considerations

Another point to be considered as a sender is to determine if you want your message to be available to the recipient in their own mailbox with no secondary level of protection. Traditionally the answer is yes, but what if you are sending a confidential document or sensitive information like a routing or account number and the someone you are sending to has a traditional email account from a provider like Gmail. We traditionally would feel OK since we know that Gmail does support TLS. However we often don’t consider the risk of have the account itself breached. Putting it simply, if someone has their public email account compromised then in all cases the confidential information you sent them is also compromised.

Yes, in the eyes of compliance you are covered but there are certain ethical and best practice issues that you should take into account. By forcing people to use two-factor authentication, or to log into a portal with a separate password, or even have a message exist for a finite amount of time, you can ensure security for confidential information regardless of whether the recipient’s primary account is compromised.

As a recipient there isn’t too much you can do. In situations where you are the one receiving content, you can insist that people send you confidential messages through their own secure portal system. In many cases you can leverage a custom portal or messaging center if made available by your vendor. A best practice should always be to not send sensitive information unless it is encrypted. Most secure email providers (DataMotion included) provide a means for you to reply to the sender securely. Alternatively you could initiate a new secure message so that your recipient can reply to you securely as well.

In closing, TLS is great for making sure that messages and data between servers and systems are encrypted from prying eyes. However, it is only part of a somewhat potentially complex equation and it is in your best interest as a sender or a recipient to ask some key questions around how your information is sent, stored and delivered to its final destination. In many cases just because there are open standards or something may be free, it is commonly not the full answer to your needs. TLS is the foundation for solutions but may not be a solution in itself.

Achieve Office 365 CJIS Compliance 1024 403 Christian Grunkemeyer

Achieve Office 365 CJIS Compliance

Moving from an on-premises Exchange server to Microsoft Office 365 (O365) can have numerous benefits. Microsoft promotes its cloud productivity suite to yield better collaboration, increased productivity and a reduced cost of ownership.  Many state and local government agencies eager for those benefits are making a move to the cloud with O365. According to Microsoft, approximately 5.2 million people use Microsoft Cloud for Government services including Azure Government, Office 365 Government, and Dynamics CRM Online Government, an impressive figure. However some government agencies need to access the FBI’s Criminal Justice Information Systems (CJIS) database to fulfill their mission. These agencies must achieve Office 365 CJIS compliance for security rules that restrict their ability to use O365 to exchange CJIS information, or CJI for short. This information must be protected in motion and at rest whenever it is outside a secure CJIS datacenter.  Specific rules and the entire FBI CJIS Security Policy are posted here.

According to its website, Microsoft will sign a CJIS Security Addendum for Office 365 CJIS compliance in states where they have established CJIS Information Agreements. At this time there are 26 states where Microsoft has a signed CJIS Security Addendum – the most recent being with Missouri (February 2017).   States that don’t have CJIS approval for O365 as of March 2017 include Alabama, Connecticut, Florida, Idaho, Indiana, Iowa, Louisiana, Maine, Maryland, Mississippi, Nebraska, Nevada, New Hampshire, New Jersey, New Mexico, North Dakota, Ohio, Oklahoma, Rhode Island, South Dakota, Vermont, West Virginia, Wisconsin and Wyoming.

While these states are not prohibited from using cloud services, they must be able to demonstrate Office 365 CJIS compliance if using those services.   For them to use O365 to transmit CJI and PII (Personally Identifiable Information), the following CJIS security policy sections must be addressed.

“5.8        Policy Area 8: Media Protection

Media protection policy and procedures shall be documented and implemented to ensure that access to digital and physical media in all forms is restricted to authorized individuals. Procedures shall be defined for securely handling, transporting and storing media.

5.8.1      Media Storage and Access

The agency shall securely store digital and physical media within physically secure locations or controlled areas. The agency shall restrict access to digital and physical media to authorized individuals. If physical and personnel restrictions are not feasible then the data shall be encrypted per Section 5.10.1.2.

5.8.2      Media Transport

The agency shall protect and control digital and physical media during transport outside of controlled areas and restrict the activities associated with transport of such media to authorized personnel.

5.8.2.1   Digital Media during Transport

 Controls shall be in place to protect digital media containing CJI while in transport (physically moved from one location to another) to help prevent compromise of the data. Encryption, as defined in Section 5.10.1.2 of this Policy, is the optimal control during transport; however, if encryption of the data isn’t possible then each agency shall institute physical controls to ensure the security of the data.”

When an agency moves from an on premise secure Exchange server to O365, emails containing CJI must be protected – and that is commonly done through encryption. While O365 does contain an email encryption capability, that encryption occurs after the O365 cloud receives the unencrypted data.  For those 24 states without a Microsoft CJIS Security Addendum, this is a violation of CJIS security policy. To achieve Office 365 CJIS compliance, the email must be encrypted before it arrives in the O365 cloud, and must remain encrypted until it is received or retrieved by the intended recipient.

One solution to this issue is to employ a third party email encryption solution designed to enhance the security of O365 and address the CJIS security policy issues.  Such solutions offer more depth in encryption features and capabilities and integrate well with the Office 365 suite of applications. To achieve this end-to-end encryption requirement, the email can be encrypted at the Outlook client using an encryption plug-in, and routed through O365 to the recipient, or to an email encryption platform in a CJIS compliant datacenter to await recipient retrieval. In this way – O365 can be adopted, while maintaining CJIS compliance for PII and CJI. You can learn more about securing email in Office 365 here.

Office 365 is a great tool and can offer state and local agencies many benefits – and with proper implementation can meet the stringent requirements for CJIS security.