Recently, a bounce-back message from one of my company's internal email distribution lists led to a startling discovery: People are automatically forwarding their company email offsite to Gmail and other personal webmail services.
It all started when our marketing group set up a meeting using the marketing email distribution list in Outlook. One person then replied to all that she wouldn't be able to attend. She then received the bounce-back message -- from an outside email address. Because she assumed that the error meant there was a problem with our email system, she opened a help desk ticket.
Our email administrator tipped me off to the problem. How could an internal email message result in an error from an outside email service? There's only one explanation: The internal message had been forwarded to an outside email account.
In fact, the webmail service in question was experiencing an outage, resulting in error messages in response to every email sent to its customers.
The important questions for me were, "How did our internal email get outside, and does this sort of thing happen a lot?" The answer to the first question was in Microsoft Outlook, which lets users set up rules to manage email in various ways, including forwarding email to another inbox -- any inbox, in fact, with a valid SMTP email address.
The guilty culprit in this case was the manager of the marketing group. I explained to her that our security policy prohibits internal company data from being sent outside our network, without appropriate security. Her position was that her job required her to keep in touch 24 hours a day, so she found it convenient to get her email in more than one place. She tried to make a case for the importance of mixing personal and business systems, claiming that we all lead what she calls "blended lives" -- meaning that our professional and personal time are mixed together. We take calls from our kids during the workday, make appointments with our dentists, hairdressers and mechanics, and we take calls at night from our management or support staff.
As someone whose workday sometimes seems endless, I have some sympathy for what she was saying, but her argument didn't change my stance. I'm responsible for protecting our data and intellectual property. Auto-forwarding rules just do not allow appropriate protection of information. There are other ways to get company email,includingOutlook Web Access and VPN, which are useful for people who are traveling or working from home. I think the only reason our marketing colleague was trying to use webmail was that she is more comfortable with that service than with the services my company provides. But personal comfort can't always override security.
Concerned about who else might be doing the same thing, I asked our email administrator to track down every Outlook account that had set up auto-forwarding rules. Unfortunately, I'm told that there's no way to do that using Microsoft's Exchange software. I thought that there surely must be other ways to detect automatic forwarding that wouldn't involve checking everyone's Outlook settings, but evidently that's not true. The only way to find email rules that have been set up by end users is to examine each account, one by one. That's a big job. So I've added it to my IT request list, along with the other things I need from IT.
Another option might be to detect and quarantine email leaving our network using DLP or something similar. However, it turns out that a huge amount of email goes to webmail accounts each day (mostly for legitimate purposes), so wholesale detection or blocking of webmail cannot help. We simply don't have the staff to comb through every email looking for inappropriate leakage of internal messages.
So, in the meantime, I'll be reinforcing my company's security policy through education and awareness.
This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.
To join in the discussions about security, go to blogs.computerworld.com/security.