Understanding the Purpose of Secure Email Gateways
We run Exchange 2010. Our edge servers run ‘passive opportunistic TLS’ for 99% of the domains we communicate with. For a handful of domains, we have forced TLS on both our end and the other domain’s end.
We’re in the process of deploying a secure email gateway appliance. It will basically park your email message on the HTTPS-secured appliance and send a link to the recipient to create a username/password and log into the appliance to retrieve the message.
For outbound email, what does this give us that TLS doesn’t? Am I missing something here?
I work for a large company and hear many complaints about Portal Based Email (PBE). It is the cause of many issues, namely:
- Logging into a portal slows down the email transaction. If you’re taking in orders or need to read PII data, this extra step or steps may negatively affect productivity
- Some portals require software on the PC such as Java. This means it’s impossible to read email on BYOD devices like Phones, iPads, etc. A PC or Mac would be required. Not to mention the wrong version of Java or lack of administrator rights to install it means you can’t read the email. period.
- Users need to remember a new password for a portal. This password is stored on a remote system. Sometimes this password IS the person’s work password. This is a security risk as it encourages the user to type in the corporate password instead of picking a new one.
- The receiver may have a firewall enabled that prohibits access to non-standard HTTPS ports. A very well-known vendor currently uses ports numbered above 2000 for users to HTTP/S POST to get the data.
- Receiver compliance auditing is at risk. If the receiver is a broker-dealer, or they are required to journal and archive plain text emails for auditing in the future, then if the recipient replies to your email via the portal, they are possibly in a compliance violation.
- It bypasses SPAM and other AV controls on the receiver.
- It encourages the pattern of clicking links within emails, which can be spoofed and lead to nasty HTTP-browser based viruses if your portal renders data that could leverage that vulnerability.
On the plus side
These portals are good to protect passwords sent to the user.
The portals are also required to maintain compliance with Massachusetts PII privacy laws that require data in transit to be encrypted. This is important for non-opportunistic TLS receivers, or for where the TLS connection is broken and unusable for whatever reason.