5 MDM tools for BYOD management

When we tested mobile device management (MDM) last year, the products were largely focused on asset management – provisioning, protecting and containing mobile devices.

What a difference a year makes. The products we compared in this round of testing have much stronger controls of specific smartphones and mobile operating systems, plus features like location-based tracking, usage tracking, two-factor authentication and sandboxing of personal and corporate identities.

Of the five MDM apps we reviewed, SOTI’s MobiControl was very strong and understood specific phones and OS platforms very well. Tangoe had very strong enterprise-focused management features. Newcomer Webroot is promising, but still has work to do to catch up to the others in our test. SAP’s Afaria, which we tested last year, sported a new, almost radical makeover that’s a dramatic improvement over their last edition. Venerable LanDesk has added MDM to its desktop management suite, and while the installation phase gave us moderate willies, we came to appreciate the product’s device controls, easy policy management and reporting.

Overall, MobiControl and Afaria tied for first place in our test, with Tangoe not far behind.

Watch a slideshow version of this story.

The specific purpose of our test was to examine mobile device management. However, it’s important to note that all five vendors offer MDM as well as a variety of other optional applications. These additional features were not tested.

For example, Tangoe also offers telephony cost control and asset lifecycle applications. LanDesk adds their highly seasoned Windows-based systems management console. SAP/Afaria adds in optional analytics and its MDM app can be internally hosted on SAP/Sybase database infrastructure (Microsoft’s, too). SOTI adds MobiAssist, a PC/mobile device help desk center with rapid remote control. And Webroot adds a line of consumer virus/malware detection systems and secure web browsing.

Here are the individual reviews:

Tangoe MDM

Tangoe installs on their hosts (at a Data Foundry collocation facility and elsewhere), or can be deployed on premises, or run as a managed service within a client’s data center (by Tangoe or Tangoe affiliates). We went with the hosted cloud model (because it’s easier, frankly). A full stack of the installation can be accessed via VPN.

Tangoe started in telephony cost containment and asset control applications, and their products offer complete mobile device life-cycle management. The MDM functionality was mature and reflects workflow used in larger organizations well. The web UI in our test didn’t quite define the workflow, but became rapidly maneuverable.

The Tangoe MDM app can cover iOS, Android, BlackBerry, and Windows Mobile. The customer intake process starts with provisioning the elements of Tangoe MDM, then deploying the apps and software into their destinations. In our case, that was Tangoe’s cloud.

Tangoe MDM workflow wanted us to go through the steps of deciding security and compliance policies in one of two ways: a flat model that treats all devices the same, or one that divides devices into two profiles, personal and corporate.

Apps, data, encryption, and settings are partitioned on the device for control purposes, although this feature, called Divide, costs extra per device, per month.

This optional corporate/personal profile becomes the crux of a device sandbox methodology; the device then maintains and partitions the two personalities. We tested this on an Android phone, and we found that some resources (applications, settings, and configurations) must be duplicated, so the resources of the device in terms of storage must be considered. Lots of apps will mean lots of storage and the amount set aside for business vs. personal storage (music, apps, videos) must be understood well, or one of the roles will suffer for want of space.

The amount of data, voice, and texting resources used is also tracked on the device, and the information is available (by policy option) to the user so that costs can be shown. This includes a breakdown by application of how much phone resources are used on the device (a phone in our case) and how much remains within the billing period. Individual apps can be “outed” for their voracious use (example: videos).

To get there, we had to define a Carrier Plan, which spells out various options. The device sends information which is used to create a working graph of usage against the Carrier Plan. The resource tracking can portend a reality check for the user, although we weren’t able to run up sufficient numbers to live in fear for our monthly costs. Will it tame the wild user? We think it could help.

There’s integration available with Active Directory, and/or Microsoft Office 365, and Microsoft’s Business Productivity Online Services, but we didn’t strongly test these features.

We could also choose application delivery for devices, crafted through mobile device-specific categories. App distribution would be through an organization’s “Enterprise Store” or chosen from platform stores such as GooglePlay. The apps aren’t vetted for security first; that’s up to the client organization. We could add to the pool of apps, and additionally choose to push applications (again by OS-specific methods) to phones for initial updates, replacements, or other uses.

Although the policy-making steps gave us questions about operations, we found a handy “test” button so that we could try them out before inflicting them on groups of new users. We liked that. The online help docs are good, but lack flow suggestions and integration information, so Tangoe help, in at least initial integration, is likely for first-time integration of Tangoe MDM.

Overall, it’s a powerful application with understandable flow and good controls.

SOTI MobiControl

Of the MDM apps we tested, SOTI is the more comprehensive (for Android and iOS), if not the most scary MDM app we’ve seen. The fright comes from the degree of controls that can be applied — and the fact that it can track phone locations across most parts of the planet on its console’s Google Map. We got visuals in Google Map of where the phone was going, as though we were tracking the device (and user) down the street as it traveled. We thought of three-letter agency appeal.

Using specific brand phone technology — Samsung’s in our test — it can put you on a specific hole at a golf course using Google Maps. On other devices, it’s just slightly less accurate in finding location and sometimes merely put us in a vicinity, rather than an exact location, when we were in downtown areas.

This means: No more fudging about “Oh, I’m at home today with a sick child”, or “I’m still in Stockholm”. Of course, that same location-based user vectoring can also be tremendously useful. “Which plant is she in?” “Oh, look, he’s stuck on the FDR Expressway again.” “No, he’s still in his hotel.”

Only the administrator of the Mobicontrol can “see” this information, but we get the feeling that it opens up a Pandora’s box of interesting situations.

Getting there

There are two versions of MobiControl; we tested the cloud version, rather than the on-premises one. Customer intake includes Active Directory linking where needed or desired.

We used a Windows 7 virtual machine hardwired to an IPv4 address in our network operations center as a virtual machine; this machine needs a world-accessible IP address or FQDN or proxy connection, as devices will communicate with this machine. If there are many devices, the machine will need reasonable firewalling/protection and high availability resources.

The SOTI proxy machine needs to have two ports open (and cleared to it from the outside world), and that machine also needs a clear path to an Active Directory catalog server for proxy authentication purposes. This allows user requests from outside a network to get to it, and permits Active Directory commands and changes to pass through SOTI for control purposes.

The SOTI MobiControl covers iOS, Android and older Windows Mobile versions. We had to create groups, then devices to fill-in the groups, then describe, via a Device Agent Manager, the device itself. It was only slightly laborious for basic connectivity and control. The real work comes in designing payloads and managing authentication keys (where needed) and accessibility components for organizational access via Active Directory where desired.

Fleet provisioning can be detailed for various qualities of mobile devices, depending on their brand/model, OS and version, and other qualifiers. The details could be specific to phones for application payload purposes (one can include a varying payload of apps if desired), or departmentally sorted payloads (apps, policies). Inside the payload can be things like security keys to access SSL-secured Exchange Mail, or app packages and/or data and/or links to them or settings controls. Workflow, like Tangoe MDM, isn’t quite obvious, but setup strategy can be decided with a little bit of experimentation.

We obtained the MobiControl device app from the Apple AppStore and GooglePlay. We installed the app, and entered a code. The code, in turn, vectors to the aforementioned Windows 7 MobiControl admin app that we’d configured. Once linked, the phone is locked down to whatever’s been configured in the management app. The phone also then sends, via the carrier or WiFi, the approximate location of the device.

Also included is a company store-like app catalog, which SOTI doesn’t vet through AppThority or other third-party mobile application analyzer.

We found MobiControl’s provisioning and administration model to be both well-thought through, and in terms of user locational privacy, a bit scary from a management perspective — very useful in some cases, but onerous in others. We might choose it for both reasons, but only after a review about what ethical locational privacy standards should be.

Webroot SecureAnywhere Business-Mobile Protection

Webroot has taken its online, graduated-feature-set of personal/consumer MDM control apps (called SecureAnywhere Personal), and upgraded it to a small organization-sized cloud product. We believe we’re first to review it, as the “Business” version is brand new. We found it immature, but promising.

Webroot is known for their highly rated desktop virus/malware protection products, and SAB-MP is an extension of a portal-based MDM product. Webroot tries to protect the phone through secure browsing, SMS examination for origin of malware, and has a virus/malware scanning app.

As a cloud-only product and in its first iteration, it’s a little raw, but has pretensions towards eventual features covered by SOTI, such as location-based geolocating of users, and certificate-based phone control. It’s less complicated, but also not as strongly featured as SOTI and Afaria.

Like other packages we tested, there are two sides to the installation, first an administrative setup, and the second, a user-side download either to an Android or iOS device. Today, there isn’t control for ActiveSync/Microsoft devices or BlackBerry. The payload deposited on Windows or Android mobile devices and the payload and subsequent mobile device app isn’t configurable or “skinned” with corporate logos, surgically applied policy controls, etc. Control is based on approved apps, and contained web surfing.

We went through a simple customer intake experience (sign up on the web), and in a few short steps, were inside the SaaS-based cloud UI. We liked the two-method authentication process for administrative portal access. We added users, which could be done manually or from an imported Active Directory list (instructions included). You can delete Active Directory users who don’t have phones.

A URL/QR Code is then emailed or SMS-sent to desired devices that takes them to Google Play or an Apple AppStore link, where the device-specific application that will serve as a phone controller is located. The user clicks on that link and is sent a payload that installs on the phone. The Google Play link didn’t require a Google account to download in our tests. After installation is complete on the phone, a user name and password (sent in the SMS or email) is entered, and the phone then falls into Webroot’s clutches.

Webroot supplies users with a restricted browser setting. The setting serves as an optional URL filtering authority that limits, through blacklisting, the sites that the browser can surf to. Webroot keeps a list of sites that are off limits and will prevent users from surfing to sites on their list. Although this list is said to be mature, it’s difficult for us to test. We noted that it doesn’t blacklist by content type; the phrase “NSFW” is meaningless. There’s also a USB Debugging Shield and “Unknown Sources” shield that can be used to filter content entering the phone from USB, Bluetooth, or memory card.

SecureAnywhere for iOS requires an initial administrative step to build an Apple Push Notification Certificate so that the download for the site can exist in the Apple AppStore. One gets a link (specific to the organization), downloads the app, and the app behaves largely like the Android version.

The mobile device payload/app can query the phone for location information, then gives the longitude/latitude best-guess to Google Maps on the Webroot administrative console, then like SOTI, shows the ostensible location of the phone. A map with a pinpoint means: you’re there. A wider diameter circle on the map means: somewhere in the area roughly inside the circle. The phone has to have some type of geolocation service turned on, or at least provide carrier-based information, to do this. Using apps like Google Play to locate a user takes longer than having GPS enabled (which is a minor battery waster).

The Lost Device Protection includes geolocation, the ability to make the device Scream (where did I leave it?), wipe the device, lock, unlock, and lock with message. We noticed a few delays getting messages to our test phones, while others were nearly instantaneous. It might have been the carrier’s fault, although the inconsistencies were odd to us.

In all, the SAB/MP app is rudimentary and easy to understand, has no device payloads, or model-specific widgets, and is poised more towards smaller organizations. The docs were primitive but explained the operations at the level of a systems operator. Civilians might have problems, but support and community forums are available at the Webroot website.

Webroot did not identify our Android rootkit, SuperUser, as malware. A Webroot spokesperson says that they identify malware through their own processes, and “benign rootkits” are not identified as malware. We hope they change their policy, as we believe there is no such thing as an active “benign” rootkit. Secondly, WebRoot uses its own system of identification of malware apps to be flagged. Although we didn’t seed malware onto our phones, we could not test this claim.

In all, Webroot needs a bit of polish to get to the point where the other products start, although it looks promising.

LanDesk Mobility Manager

The LanDesk Management Console platform is based on Windows Active Directory Services, Exchange 2007 or 2010, and the RIM Business Enterprise Server/BES Server, if you use it (we don’t).

The LanDesk Mobility Manager is an add-on to the basic (and required) LanDesk Management Console. It can be used without the Active Directory services, but we don’t recommend this, as the ActiveSync infrastructure and Microsoft Exchange would likely be a hassle without it. Your management day will be bad if you try.

The LanDesk MDM product would be the third server in your Windows-based network after a Windows 2003/8 (or R2) primary “catalog” server, and a second server that hosts the Management Console.

Windows server licenses can be minimal; they just need to be in the same forest and can be virtual machines. If VMs or discrete bare metal servers are used, they need a minimum of 50 free gigs of storage. If you have Microsoft Exchange (check your version as there are differences in functionality between 2007 and 2010; we used Exchange 2010), it can understand and utilize the APIs that Exchange offers to control devices.

The easy part is initial device provisioning. Get the LanDesk app from the Apple App Store, or from Google Play. Install it, and authentication to the server is next. Also, the Mobility server needs to be on your DMZ with a world (or at least carrier-accessible) FQDN or IP address. This is similar to how SOTI and Webroot work. From there, it’s possible to add a device app that allows an additional portal access (after it’s configured in the Mobility Manager) for apps, files, etc. that can be downloaded to the device.

Mobility Manager does an initial check of the client mobile device for rootkits and jailbreaks on enrollment; flags can be set to allow enrollment despite the presence of these device states. After enrollment, they can be detected, we found, but aren’t necessarily quarantined, although their state is noted in the inventory reports. There are no restrictions placed on browsing. Our rooted/jailbroken devices were identified, but you can “grandfather”-in devices whose states are questionable. However, your devices won’t be geolocated because location tracking isn’t offered.

Active Directory policies, in terms of control, are easily applied. You can lock a phone, change its PIN, wipe the phone (and can remove the wipe command if you get the timing right, so as to allow a user time to find it). We could also send VPN and email settings, and even WiFi pre-shared keys to the devices we controlled.

If Exchange 2010 is installed, polices can be enabled to prevent user access to mail, if desired, or to allow only users managed by the app to get email, as a policy. We tried this and it works. If organizational mail is sensitive or shouldn’t be accessed by BYOD devices, here’s the place to manage the device, whilst gleefully preventing email-borne problems associated with mobile devices. You get access, but no mail. And you, over there, you get mail.

The device polling frequency is selectable, which we prefer, and we increased it and found that the reaction time in the devices improves as a result. In this setup, there are several potential points of failure, which need to be guarded or made more highly available, as the path to the Mobility Manager server in our test “DMZ” is critical for interaction between the Mobility Manager and its managed devices.

While we like the LanDesk configuration, we’d feel more comfortable if devices brought under its management control received a sound thrashing at installation for root kits and jailbroken conditions. Beyond this, however, for an organization that wants to leverage a sound Active Directory infrastructure, the free Management Infrastructure that you get with the Mobility Control is a decided plus.

SAP Afaria 7

When we looked at what was then Sybase Afaria, we found a comprehensive package whose approach had Frankenstein-like integration. Since that time, Sybase and Afaria have been acquired by SAP, and their approach to MDM is now integrated into a single web-UI portal that, in turn, controls modular servers that perform various elements of device management and control.

Its UI is non-obvious, but with a short bit of reading through the docs and getting light assistance, we found it to be both understandable and packed with workflows poised towards BYOD and mischief control.

The entire Afaria 7 package can be cloud based (we tried ours in Amazon’s Web Services/AWS) or as members — probably virtual machines — in an enterprise network framework. Each portal can be connected to an organization’s Windows Active Directory, but only in the flat model — one domain per instance of Afaria 7 — although a spokesperson said multiple domains/forest can be dealt with by perhaps the end of 2012.

The improvements are major, but some assembly is required. The assembly comes at the crux of a current marketing program where a two-week trial of Afaria on AWS is offered, with optional third party help (you get pre-sales dedicated engineering help) to configure the right initial platform. It’s a complicated decision tree, and you’ll probably need the help. With the trial, Afaria pre-loads the configuration, and in turn, starts allowing a client to go down a decision tree of configuration options appropriate to their workflow and policy mandates.

The “single pane of glass” in Afaria 7 overcomes the several pains of glass that were demonstrated in our last view of Afaria 6, which was comprehensive, but mind-boggling to manage. In the current cloud model, Afaria still uses modular components, but processes are now linked together logically. As an example, we can set up a device with a specific group and policy in about five mouse clicks.

There can also be “master” or distributed servers that cover different business units or logical/geographical areas, subject to the Active Directory limitation mentioned. Or you can go without Active Directory at all, if desired — meaning users and authentication becomes  more manual in administrative nature.

The tasks are similar to other MDM packages: build groups, set policies, get users to sign on, and control the device, whether iOS, Android, or Windows Mobile (to v7). Afaria can provision a device via Active Directory membership, an organization’s Certificate Authority, via MSChapV2, or by allowing a user to download a payload through one of several resources appropriate to the device.

Software application payloads aren’t initially included, but are sent subsequently. One can develop an “enterprise application store” if desired; in the SAP model. SAP’s applications are vetted for behavior, but your applications are on your own — yet easily populated into an enterprise store for subsequent download by subscribed users.

Afaria does the initial two-week customer trial configuration of host services in the AWS cloud, although manual instructions to provision into AWS are included for those who must do this themselves (generally, for security reasons). In a non-preloaded cloud, enterprise installation, the turf is a Windows Server instance using MS SQL Server or Sybase iAnywhere.

We could put users into groups of three kinds: Static, Dynamic, or Individual. Group memberships have policies applied, and if there are two, policies of both groups that a device is a member of. We suggest use of Dynamic Groups, as they also allow the ability to move users whose devices are compromised (rootkit, jailbreak, appearance of a hostile application) into those groups for easy monitoring and mitigation.

We used the included (preconfigured) Self Service Portal to obtain our test device’s initial Afaria client payloads. We chose not to have a device that’s compromised to have allowed access, so that once enrolled, the device could receive a remediation message. Otherwise, if access is denied, a user only receives a message that the device is compromised and the software won’t install. The payload can be re-initialized in this case, after a rootkit or other offending condition is removed.

Afaria immediately found our SuperUser rootkit and classified the device in the way we desired.

Afaria polls groups by default, once a day, but we found ourselves upping the polling rate to detect changes, as we feel other organizations will.

Individual devices can be shutdown. Packaging can be skinned with organizational logos, for customizing. What we found objectionable in our last review, a sense of grafting and disjointed applications, has changed dramatically and for the better.