The Power of the Proxy: Addressing the Threat of (Outbound) E-Mail

A recent statistic (like, right now recent) says that 80% of incoming e-mail is junk. That’s based on the anecdotal evidence of watching my “junk” and “spam” folders fill up much faster than the valid e-mail that stays in my inbox so I’m not really sure you want to quote that as absolute but I’m betting most people would estimate the same percentage of junk to valid in their own inboxes.

Amongst the junk invariably reside a smaller portion of malicious e-mail. The kind that’s really nothing more than a phishing attempt to deliver a virus or coerce me to share my credentials with them. Smaller, because we (as in the corporate We) like most 72% of organizations, take advantage of SPAM mitigation services. That’s a real stat, from our State of Application Delivery report, by the way.

It would seem, then, that between technology and tireless education from security teams that e-mail is a lot safer than most collaborative applications.

Except when it isn’t.

Which is exactly what CloudLock recently found in its Q3 Cybersecurity Report, among other interesting tidbits. What really stood out to me was the nugget around e-mail “sharing”. CloudLock found that organizations on average collaborate with 865 external parties. Just 25 of these account for 75% of cloud-based sharing per organization. But 70% of sharing occurs with non-corporate e-mail addresses security teams  have little control over. 

In other words, outbound e-mail is a real risk to corporate security. Not necessarily because everyone who shares corporate data with an external, non-corporate e-mail address has malicious intent, but because of the unknown risks associated with storing that data off-premises. Is it encrypted? Probably not. Is it safe from scans and the prying eyes of employees of the e-mail provider? Probably not.

And yet as CloudLock points out, security teams have little control over this type of activity.

While that’s true, there is someone that perhaps does have control (or the ability to control) that type of activity: the network team.

Let’s assume for a moment that your corporate e-mail system is on-premises. While many today are not there are still many more that are, owing to regulations and compliance efforts that simply can’t be adequately enforced offsite. So everyone uses a service that’s in your data center, on your network, and under your control.

Here’s where a programmable proxy can provide the control (by offering visibility) you need to stop (if that’s your desire) sharing of corporate data with non-corporate e-mail addresses.

See, a reverse proxy sits in front of a service. Usually that’s a web server and the proxy is providing load balancing services. In this case, the proxy is going to sit in front of your SMTP service (like Exchange) and provide an out-bound scrubbing service. How’s that happen, you ask? By inspecting every “SEND” and determining whether or not the destination is “corporate” or not, and whether it contains some sensitive data.

Trust me, the former is easier than the latter. SMTP is a well-known and thoroughly described protocol. Data path programmability gives you the ability to parse out that protocol and easily determine "corporate” from “non-corporate”. After all, you know the domains for which you manage e-mail. Those are corporate. Anything else? Not corporate.

Figuring out whether or not attachments or inlined data might contain sensitive (or risky) information or data is a bit trickier. But seeing that you have access to the entire payload – including attachments – you can start by using the same techniques used by web application firewalls to “scan and scrub” sensitive data coming from applications. You might use the attachment’s file name as a clue, too. Perhaps you just block anything that’s a .zip or a .xls. You could allow valid sharing with non-corporate e-mail addresses by allowlisting either those who can send to non-corporate addresses or a list of non-corporate approved addresses which can receive.

Basically, it’s up to you. How tightly do you want to control this potential leak of information? How important is it to address this particular threat?

The power of the (programmable) proxy is pretty much infinite because once you combine the visibility with code you end up with options. You can implement unique solutions to problems that arise without having to rely on new software or solutions that introduce additional architectural and operational challenges. That’s why you need a modern, app proxy with programmability, performance, and (support for many) protocols; because visibility + programmability = win.