Email encryption through CRES when we support TLS?

[keithsauer507]

I was wondering since our Exchange 2013 server supports TLS and I activly see in the message tracking logs that the Ironport is recieving the emails from our Exchange (and vice versa) by accepting TLS, can we avoid the requirement to open the securedoc.html file for encrypted emails?

Lets say the user sends email out and it is flagged for encryption.  The end user gets into the portal and replies to this message via the CRES portal.  Can this reply be sent via TLS (since we support it) to Exchange and the reply is viewable right in our employee's Outlook 2010/2013/2016 inbox without having to open the html attachment and log in?

We need this ability for two reasons.

1) Ease of use.

2) We have some employees of a third party under our organization and that third party requires all emails are archived to their archive inbox.  This works fine today becasue these users are in their own Exchange DB that has archiving turned on.  However replies would be archived with the general "You have recieved a secure message" template with the secure html attachment.  This third party agreement requires that their journaling / archiving has ability to view all messages.  So since our Exchange server and Ironport are talking TLS (its set to preferred), can this happen?

Thanks!

[keithsauer507]

I found in the encrypt & deliver rule for our various outgoing mail filters has an option to only use CRES if the other side does not support TLS.  However is this secure enough?

I changed this option and tested it with a subject tag.  Got the email saying my message was delivered securely.  I checked my personal gmail account and it was there, no logging into cres needed.  Replied from that message and recieved it in my work's Outlook inbox, again no cres or securedoc.html file needed.  Checked the mail logs and exchange to ironport spoke TLS, and gmail to ironport was TLS.

But is that secure enough?  CRES does make you log in which is sort of a verification that its your real e-mail address, and not someone else who hacked the email address / stole the password /etc.

[Mathew Huynh]

Hello Keith,

Generally SSL Encrypted connections under TLS is secure so there's not much worry there.

In terms of security, having the encrypted envelope for more sensitive data would be a more secure approach as the envelope when sending to CRES is TLS encrypted for transfer, and to access this envelope will require the user credentials, so if someone hacked into the mail box, unless they have the CRES credentials, they won't have access.

But this just comes down to personal preference with security.

Regards,

Matthew

[keithsauer507]

Thank you for that information.

What we did was enable ldap connectivity, and create an outbound mail policy which checks if mail is sent from a particular AD group.  The automatic encryption filters we have in place have been duplicated and altered to only send through cres if the endpoint does not support TLS.  We applied these altered encryption filters only to this new mail policy.  It tested out great.

Now we are in compliance as this AD group is contracted by another company (though using our facilities and email addresses).  The other company requires all communication to be journaled to them, so we have that configured through Exchange.  Their issue was if the user send out a message secure through CRES, the recpipients reply would journal back as the "you have recieved a secure email" and the third party company would have no visibility into that communication.  I know it sounds a little "big brother", but it is a stipulation for the realtionship as they are really employees and representatives of the other institution, just working under our roof.  The other thing I was able to do is on the CRES admin site enable the TLS so when CRES sends a reply back to us, if TLS can be used it will not re-wrap it in another securedoc message envelope.  This enhances our end user experience.  We know mail coming in is protected by our AD account access, strong password policies, password change enforcment, activesync approval through MDM software, and OWA access protected by Two Factor Authentication.