Email, email, in the cloud

As my company continues to move enterprise applications to the cloud, the latest development presents a security opportunity. We are giving up our on-premises Microsoft Exchange email in favor of the Microsoft Office 365 service. With the transition, we might be able to curtail the common employee practice of communicating and storing sensitive business-related data in email.

Trouble Ticket

At issue: The company email system is moving to the cloud.

Action plan: Work with IT to make sure information is better secured after the change than it is now.

I am encouraging the IT organization to tighten security by implementing controls that were either not available in our on-premises deployment or never implemented. The first order of business is a cleanup of accounts and distribution lists. We have hundreds of email-enabled distribution lists, and too many of them are available to the world. We should be able to cut down the number of lists and set rules about who can use them.

For example, one list that includes all members of the customer support team has been available to anyone, though only internal employees have a need for it. Customers will have access to a separate support distribution list that will integrate with Salesforce to automatically generate a support ticket.

We will also restrict to managers the ability to send to “all.” Too many people use the “all” alias to send messages that most employees perceive as spam. That’s a problem in a growing company.

Then there’s auto-forwarding. Doing it internally is one thing (having your mail go to a co-worker while you’re on vacation, for example), but auto-forwarding to personal email accounts simply increases the potential for data loss. Now we can disable auto-forwarding for some employees or restrict the domains they can auto-forward mail to.

Another issue involves the devices users access email on. I don’t want them to install the Outlook client on non-corporate computers. This could be especially risky on public computers, such as in hotel lobbies, because the mail will stay on the device after log-off. We will try to circumvent that risk by requiring that employees use our corporate single sign-on (SSO) solution to log into Outlook. One plus is that our SSO uses multifactor authentication, but it also can be configured to restrict Outlook access to one device (presumably the corporate-issued device). Another way to restrict access is to issue a machine certificate to the corporate PC and configure Office 365 to allow connections only from machines with valid certificates.

Eventually we will deploy a robust third-party mobile device management application to employees who use their phones for business purposes. Until then, we will use the built-in mobile device policies that come with Office 365. These include password requirements, device timeout, encryption, brute-force protection, restrictions against jailbroken devices and the ability to selectively wipe phones (corporate mail only) when a user leaves the company.

We’ll use what Microsoft calls “MailTips” to help with data loss prevention. For instance, if a user creates an email containing sensitive data, such as a credit card number, MailTips will send a warning that that is a bad practice. Similar warnings will be issued when users try to send emails to a distribution list that contains an external user.