How to plan your mobile threat defense deployment

EMM and app components

Firstly, let’s assume that there is an EMM in place, as this will inevitably play a role in the orchestrating and pushing of your chosen product to the mobile devices. Before selecting an MTD solution, it is worth looking at what level of integration, if any, each platform has with your EMM. Getting this bit right might not make a massive difference to the users, but can save vast amounts of administrative overhead.

Most MTD solutions require an additional app to be installed on the mobile devices. This app can usually be imported into your EMM from a public app store, but not always. Some apps need to be signed locally before distribution, and ensuring that the skills required to do this are available can be a determining factor for smaller companies.

Other MTD solutions don’t require an app on the endpoint, either being built into the EMM app already on the device, or leveraging the app inventory collected by the EMM. Those that read app inventory from your EMM can certainly save time in deployment planning, but can often lack remediation capability, and be limited in the threats they can protect against, particularly network threats.

What type of user are you targeting?

The next step is to consider the user base.

For COSU devices, the limited functionality of the device often prevents exposure to threats, so protection might not be required, although this depends on what features are available to the user. If there is a browser available, or public messaging apps, then obviously there is an attack surface that can be exploited.

For COPE or COBO estates, usually the administrators can add software to the endpoints as the company sees fit, with minimal pushback from users.

Where there is a BYOD policy, it is still possible to gain user buy-in, but careful messaging is required and often privacy concerns need to be addressed. In this case, fewer features can often be better, and be careful to avoid implementing additional features such as browsing restrictions.

Many leading MTD solutions now offer phishing protection, and while users can only benefit from this, it is worth communicating that the defense is triggered by clicking malicious links, and reminding the users that this does not mean that IT staff can read their SMS or chat messages. It is also possible in many platforms to anonymize user data, and if this is implemented, BYOD users know that they gain protection without surveillance.

For Android Enterprise devices using a work profile, decide whether the MTD will protect the entire device or just the work profile. If the entire device needs to be protected, then this will require two instances of the app to be installed. Be sure to mention this to your supplier as part of discussions to avoid paying double for licenses, as the software will naturally show twice as many enrollments as there are physical devices. The supplier should be prepared for this scenario, but you need to call it out in advance to avoid confusion later.

Lastly, it should go without saying, but a well-constructed acceptable usage policy combined with clear and honest messaging can often make the difference between a successful rollout and admins chasing down mobile users to complete the project.

Designing mobile threat defense policies

Once a platform has been selected and integrated with the EMM, the business of designing an MTD policy can begin.

Often the first step is to disable some of the threats that MTD solutions often detect, particularly those that relate to the device posture. If your MTD can detect jailbreak, decryption, etc., this is already covered by the EMM, and you don’t need two alarms going off every time a single fault occurs. If the EMM covers it, leave it to the EMM, as there will more likely be a remediation playbook, such as quarantining the device, as opposed to just an alert from the MTD.

Now, designing the MTD policy itself can be counter-intuitive. Where the mobile threat defense solution allows companies to determine the severity of particular threat types, the immediate reaction for many is to move a lot of lower-class threats up in severity. During the pilot phase, this doesn’t cause many issues, but once the policy is applied to thousands of devices, it can trigger so many alerts that administrators find their inboxes flooded.

This, in turn, can lead to rules being created to filter away the deluge of emails; alerts that aren’t being read are as bad as not receiving alerts. So, avoid the urge to upgrade threats, at least at first. Once the endpoints are enrolled, policy can be amended as required, and severity can always be dialed-up.

It is also worth remembering the nature of mobile applications when considering app behaviors that trigger alerts. For example, banning apps that access the address book can result in benign apps getting blacklisted. The better mobile threat defense solutions can determine the difference between accessing contacts and transmitting them, and only the latter is a threat. Any MTD I’ve come across to date offers a default weighting for apps, and for the most part, this will suffice to protect your organization.

Alerts for threats can come in two forms: user alerts and admin alerts. Each threat type needs to be looked at and decided upon practically. The main mistake I encounter is administrators receiving alerts when an app leaks passwords. This might initially seem like the correct thing to do, but unless you’re deploying a bespoke app you’ve had built, you should only be responsible for line-of-business apps, which should have robust development standards. If your user adds a personal app, the integrity of that app is their responsibility, and telling them that the app is leaking information should prompt them to uninstall the app. You can also customize the alert message to remind the user that if they have been using a password identical or similar to their corporate passwords, that they should change those corporate passwords immediately, as this is really the main risk they pose to your organization.

When network threats are encountered, there is often an option to disable Wi-Fi on the device. Some MTD platforms instead offer an option to secure all traffic, and when available, it is the best option, as disabling traffic might lead to a loss in productivity.

It is also worth distinguishing between “risky” hotspots and man in the middle (MitM) attacks. A risky hotspot is one where the safety of the connection cannot be verified, and often generates an alert when a captive portal redirects the user. This unknown posture is different to actual attacks, and should have a separate response.

Advising the user is often enough in this scenario. However, where certificate spoofing or SSL stripping is detected, someone is actively interfering with the data and either trying to read the upstream content, or inject something into the downstream. In this situation, more than an alert is required, and traffic should be either secured at the device, or Wi-Fi should be disconnected from the malicious hotspot.  

Where EMM integration allows messaging back to the EMM platform, some mobile threat defense solutions offer a default remediation group or label, while others allow individual groups to be applied for individual threat types. It is worth taking the time to set up a specific group with appropriate lockdowns for each threat where this is available. The time taken to initially design these groups will be saved many times over when remediation is largely automated without administrator intervention.

Users will be prompted to fix conditions that can be resolved locally, and the business can be assured that the threats to the organization will result in appropriate restrictions being applied. While MTD is great at detecting problems, it often lacks the ability to manage device policy (iOS, for example, only permits a single management profile to be installed). If MTD is the brains for threat management, EMM is the muscle often required to turn the information into action.

Mobile App Reputation Service (MARS), is available in the leading MTD solutions, and this can be used to automate app whitelisting or blacklisting based on behaviors, permissions, or even the geographical placement of the servers that apps communicate with. Recommended settings for this part differ greatly from one country to another, and communication with the relevant legal department can help steer these decisions greatly.

Final thoughts

Despite the amount of thought that needs to go into mobile threat defense solution selection and rollout, the good news is that once these decisions are made, configuring a robust MTD policy usually takes only a few hours. If implemented correctly, MTD can add a great degree of protection with very little day-to-day interaction required.