Designing and Applying the Rule Set

At first look, it would seem you might only need a few simple rules, however, there are deeper issues that will require more complex configuration. The first thing to understand is that policies are processed top-down with an explicit deny at the end.

1. There are many proxies that exists in the cloud for email applications which store passwords, capture traffic, etc. and are generally not secure. For this reason, we supply an IP-based block list which denies anything that comes from cloud service providers like Azure, Amazon Web Services, etc. Add a rule, set the location to IaaS Provider IPs and Anonymizers set the access method to both SSO Auth or ActiveSync, and set the Action to Deny. The IP and Anonymizer block lists updates automatically.
   
   
   
2. The mobile Outlook client is proxied through a cloud-based service to assist mobile client access, hence we will see both the source IP and User agent are modified versus using the standard email application. Given that the source IP address of hosted services can change (load balanced, or dynamic servers), we cannot rely on allowing only the source address as a way of filtering the traffic out. We can however use the User-Agent. The following is a list of user-agents sent by different email applications:
   • Office 2013 PC Desktop (ActiveSync)
   • Outlook/15.0 (15.0.4753.1003; C2R; x86)
   • Office 2013 Mac Desktop (MAPI)
   • MacOutlook/0.0.0.151105+(Intel+Mac+OS+X+Version+10.10.5+(Build+14F1021))
   • Outlook App iPhone:
   • Outlook-iOS-Android/1.0
   • Outlook App Android:
   • Outlook-iOS-Android/1.0
   • Standard Email Application, Android Device:
   • Android-SAMSUNG-SM-G900T/101.50101
   • Standard Email Application, Mac Device:
   • Apple-iPhone7C2/1208.143
     Note: What this means is that we can use User-Agent filtering in the policy and set it to Outlook-iOS-Android to catch the mobile Outlook Application traffic only! As a side note, the matches in the policies are searched with a wildcard on both sides of the term. If you set the User-Agent to Outlook, it would catch both the mobile Outlook Application, and the 2013 PC Desktop software.

     • To create the rule, create a policy and click on Device, then OS & User-Agent. Click the + symbol in the User-Agent section, fill in Outlook-iOS-Android and click OK to match the mobile Outlook Application clients.
       
       
       
3. Set the Access Method to ActiveSync and Action to Secure DLP (set watermarking to visible, etc. as needed.) As the Outlook Application traffic comes from AWS, we need this policy to permit traffic before the block list IPs. Grab the policy and drag it to the top so that it is processed first. With this, we will allow ActiveSync traffic from the Outlook Application, but deny all other AWS/Azure/Etc. proxies. Once the policy is in place, save it. You should now have the following setup:
   
   
   
4. To control access to Forcepoint ONE SSE by only mobile devices which have a password set, a setting is present under the Devices tab which sends a policy to the phone. When a phone is joined (or for existing users, when the change is made), the client is notified that they must meet the password complexity set. If a client does not set the password to the settings required, the phone will not sync with the Exchange server. For Forcepoint ONE SSE we send a request to apply the policy, however, we cannot block email access if the client does not make the change explicitly. To apply the setting, go to the Protect > Mobiles Security and check mark Enforce Forcepoint Policy and Require Device Password. Select the password characteristics you wish to enforce and click save.