![](\"http:\/\/zapt3.staticworld.net\/images\/article\/2017\/05\/mail_cloud-100721740-large.3x2.jpg\"\/)
<\/p>\n
Credit to Author: Mathias Thurman| Date: Mon, 08 May 2017 03:45:00 -0700<\/strong><\/p>\n 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.<\/p>\n At issue: <\/strong>The company email system is moving to the cloud.<\/p>\n Action plan:<\/strong>\u00a0Work with IT to make sure information is better secured after the change than it is now.<\/p>\n 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.<\/p>\n 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.<\/p>\n We will also restrict to managers the ability to send to \u201call.\u201d Too many people use the \u201call\u201d alias to send messages that most employees perceive as spam. That\u2019s a problem in a growing company.<\/p>\n Then there\u2019s auto-forwarding. Doing it internally is one thing (having your mail go to a co-worker while you\u2019re 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.<\/p>\n Another issue involves the devices users access email on. I don\u2019t 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.<\/p>\n 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.<\/p>\n We\u2019ll use what Microsoft calls \u201cMailTips\u201d 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.<\/p>\n We will also prevent users from pulling in webmail to Outlook. It\u2019s best to ban that activity outright because we just can\u2019t vouch for the integrity of those personal messages, and we also don\u2019t want to store it on corporate devices.<\/p>\n Finally, we will (of course) enable any and all malware and spam protection. I\u2019ve always said that if my company is going to get hacked, it will most likely result from someone clicking on something in an email. Anything I can do to block malicious emails is well worth the effort. This includes blocking certain email attachments, such as executable files and scripts, that are typically associated with malware. We will also continue to enforce Sender Policy Framework (SPF), which validates the IP address of the email sender.<\/p>\n There are other more advanced configuration options that Microsoft offers that we will evaluate and deploy, so long as they don\u2019t impact our ability to conduct business. The last thing I want is to implement so many restrictions that legitimate email is prevented from reaching its destination. As always in this job, it\u2019s all about finding that balance of security and usability.<\/p>\n This week’s journal is written by a real security manager,\u00a0“Mathias Thurman,”<\/strong>\u00a0whose name and employer have been disguised for obvious reasons. Contact him at\u00a0mathias_thurman@yahoo.com<\/a>.<\/em><\/p>\n Click\u00a0here<\/a>\u00a0for more security articles.<\/strong><\/p>\n