Home > Security

Computerworld - Surprises often dictate where I focus my attention. And what makes a surprise a surprise, of course, is that you never know where the next one will come from. This week, it was the company chat board.

Our chat board, which is part of the company intranet, draws a fair amount of employee input, covering everything from advice on international travel to ideas about innovation and technology. We don't have a formal process for moderating these discussions, but I like to check in when time allows. Unfortunately, time doesn't allow often enough. And when I logged on the other day, I found a days-old posting describing a way to configure a Microsoft Outlook client to download corporate e-mail without using VPN software.

My face flushed; I knew immediately we had a problem. A couple of years ago, I had asked the Exchange administrator to disallow RPC over HTTPS, which is the only way to do this work-around.

RPC over HTTPS, although secure in transit, doesn't provide for encryption at rest, and that puts our company data at risk. I'm never happy about that.

The only exception to our remote-access requirement of two-factor authentication and VPN is the use of Microsoft Outlook Web Access (OWA) when outside the corporate network on a shared machine -- at an Internet kiosk, for example. I would rather not have this exception, but our budget at the time made buying an additional 2,000 tokens impossible. Still, I'm generally comfortable with this arrangement because the only way e-mail could remain on a shared system once an employee closed the browser would be for the employee to save it to the local PC, which is an extra step that seems unlikely to be taken.

The discovery of the VPN work-around led me to take a closer look at our mail configuration, and I found out that our firewall allows for outbound POP (Post Office Protocol) and IMAP (Internet Message Address Protocol). That means employees can use their Outlook clients to receive mail from other accounts, such as Web mail. There are huge risks with this. For one thing, any mail entering our network in this way would bypass our spam filters, opening us up not only to more spam for that user, but also to phishing expeditions and other threats. In addition, we can't guarantee that the external mail server being used by the client is not used by spammers as a relay server. That could land our company on a blacklist. And finally, if an employee used the secure version of these protocols, we wouldn't be able to scan the content of the e-mails with our data leak prevention software.

What Now?

I have some work to do. The simplest thing would be to just turn everything off, but that's not something I would do without checking the consequences first. Therefore, I must determine whether there are any legitimate business users for both the RPC/HTTPS and the POP/IMAP protocols. (I've already learned that several of our executives who serve on other boards of directors use POP/IMAP to download that e-mail into their clients.) Once I've done that, I can deal with any exceptions and send out an announcement about the termination of these two dubious features. That probably won't make me very popular, since these features are considered productivity enhancement tools.

On the other hand, because our company's financial situation has improved, it could be a good time to revisit the possibility of configuring two-factor authentication for OWA. I also plan to ask Microsoft if RPC over HTTPS can be secured to prevent untrusted or unauthorized PCs from downloading corporate e-mail.

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.

Join in the discussions about security: computerworld.com/blogs/security

Read more about Security in Computerworld's Security Topic Center.