“My buddy Aamir Lakhani is developing a iOS security class and recently posted about hacking iOS devices. This is a very popular subject and want to share this. Also shout out to Tom Bedwell for his assistance with the research. You can find the original posting at www.cloudcentrics.com”
iOS devices can be booted with their own kernel and micro operating systems instead of approved Apple firmware. When iOS devices are loaded with a micro kernel, you can run attacks such as bypassing the passcode, decrypting passwords, copying file systems, viewing emails and much more. The following guide describes how to create a RAM DISK, however it may not function precisely as a step-by-step instruction set, since each system is unique and requires some level of customization.
Note: If you run in to trouble when creating a RAM DISK due to unique OS configurations and code versions, don’t despair.
Zenprise recently released an upgrade to their flagship mobile device management MDM solution. My team has been showcasing a previous version 6.6 and went through the upgrade to Zenprise 7.01 this week. The Zenprise ZDM upgrade took around 15- 20 minutes, which steps included upgrading the software and java on the hosting server. Here is a comparison of both versions of Zenprise ZDM.
Dashboard:Zenprise 7.01 now includes a dashboard or centralized landing page. From a visual perspective, it’s a great way to quickly identify the state of the system and managed endpoints. The picture below is customized for 6 different reports. Functionality wise, the previous version of Zenprise could accomplish the same things by clicking around.
iOS and Android Enrollment: The new 7.01 version of Zenprise offers a dedicated section for device enrollment that includes options such as MDM server discovery, email or SMS notification. We felt enrollment was a weak spot for Zenprise however this release dramatically simplifies the process. The group enrollment features makes it much easier to deploy the Zenprise MDM software to a larger number of users at once. Furthermore, Zenprise 7.01 can import a CSV file to populate its database for bulk enrollment.
iOS Location Services, Geo-tracking and Geo-fencing: This is a huge feature. Admins can set location service policies to located devices at any given time. Geofencing allows admins to define a geographic perimeter and perform a selective or full wipe upon perimeter breach. We have had requests for Geofencing that range from stopping students from walking off with school issued mobile devices to military secured facilities wiping any device that leaves the controlled area. In high security areas it it possible to wipe a device on-demand as it exists a “safe” zone. Continue reading →
Many corporations fail to establish and enforce a network policy. A network policy is a set of conditions, limitations, and customized settings designed to control how authorized subjects use network resources. Common examples of a network policy are controlling access to adult, gambling, hacking, blacklisted and other website categories that violate human resource (HR) and security standards. Network Policy requirements can change based on device type, time of day and user role. Its key that network policy is automatically enforced rather than something end-users choose to abide by or most likely will fail when most needed.
Users are the weakest link in any network. Hackers know this and target the majority of attacks at this vulnerability. I constantly hear customers complain about phishing attacks (users clicking a link in a email) or users bringing devices infected with malware most likely obtained while surfing websites that violate network policy. Its also common to see users violate security controls if it impacts their work flow. I had one audit identify internal users VPNing from their workstations to bypass internal network policy due to lack of controls for remote users. Poorly enforced policies will impact your security, reduce workflow and become very costly as a result of failed audits and compromised systems.
Common solutions for enforcing network policy are layer 7 / application layer firewalls, content filters and bolt-on technology such as cloud applications or agent technology that control network traffic from end-points. I wrote a post about the concepts behind web-gateway solutions HERE. The standard offering provides content categories (Gambling, Social Networks, Hate, Sex, etc.) that can be denied, limited or monitored. The more advanced solutions include security components such as anti-virus / anti-malware, layer-4 monitoring, website reputation scoring and other features.
The problem with these solutions is scalability. Most content filers require either user devices to be configured inline (hardcoding proxy settings) or routing traffic to the device (example WCCP). These solutions become difficult to enforce outside of the internal network as well as on devices that are not cooperate assets such as mobile devices.
(Cisco’s Web-Security Portfolio)
A common solution that addresses external devices is VPNs routing traffic through network policy enforcement solutions (example Cisco AnyConnect with Ironport or ScanSafe). An alternative is using sandbox-based methods such as remotely controlling internal machines (example Citrix). Sandboxes work well however may encourage the wrong user behavior such as emailing information to a g-mail account to bypass the sandbox. One solution I like is Cisco’s OEAP which extends the internal network (including corporate SSIDs) to my home office.
Agent and cloud based technology can enforce network policy for laptops and desktops however fail for most mobile device types such as androids and apple devices. The reason is most mobile device manufactures give power to the end-user meaning users can opt out of security (more on this HERE). Some MDM vendors such as Zenprise offer the ability to force network traffic through a VPN tunnel, which is great when devices are managed by a MDM provider but fail when the MDM agent is not present. The only protection that can be applied for mobile devices not using MDM is controlling access to sensitive data through data loss prevention, sandbox sessions or encryption technology. I personally like the MDM enforced by Access Control technology approach.
Network policy can be enforced many ways but must meet your overall business goals and extend to all devices regardless of location. The technology is available however requires investment from leadership to properly build a policy and purchase the necessary tools to enforce it. Most failures in network policy are caused by a lack of focus from leadership.
Bring Your Own Device (BYOD) has become a hot topic for many industries. Lately security people are using the term BYOD like datacenter folks classify everything as Cloud. My team has advised our customers using a best practice BYOD architecture (more info HERE) and like many consultants feel Mobile Device Management aka MDM is a key factor.
A few months ago I posted about one of the market leaders, MobileIron, HERE. I have received multiple requests for another vendor and chose the current leader Zenprise according to Gartner’s Report “Critical Capabilities for Mobile Device Management”. Plus I really like Zenprise.
Zenprise offers all the popular features expected from leading MDM vendors such as controlled remote wipe, policy enforcement (passwords, etc.), flagging jailbroken devices and enabling location. A few differentiators as of today for Zenprise are the ability to remotely login into phones (similar to remote desktop for windows), secure content distribution and Mobile DLP, application-specific VPN tunnels, and SIEM integration.
The architecture of Zenprise is similar to other MDM vendors. They have a management system (Zenprise Device Manager, or ZDM) and enforcement system (Zenprise Secure Mobile Gateway (SMG)). The Zenprise SMG is what denies email services to devices that violate policy. They also have a component that sits inside the network and does advanced diagnostics and troubleshooting for Microsoft Exchange and BlackBerry Enterprise Server (Zenprise Service Manager, or ZSM). Like many MDM vendors, Zenprise has an agent that sits on endpoints to enforce policy. Most people install both the ZDM and Zenprise SMG since it makes sense to enforce policies. Licensing for cloud or on-premise is based on the number of endpoints and drops as larger quantities are purchased.
To try Zenrpise out, go to https://zencloud.zenprise.com/zencloud/cloudUser/create and fill out the form to gain access to a free trial of the cloud service. You can also request Zenprise software to setup an on-premise trial however you will have to request that from a Zenprise sales person or partner such as World Wide Technology Inc. One you gain access to the management system, login in and you should hit the main dashboard.
After logging in, the main Zenprise landing page will show devices you are managing. Details include Jailbroken / Rooted, Managed / Unmanaged, Serial numbers, IMEI/MEID, last connected, User, OS Version, etc. You can click a device and see details such as what apps are installed, how much battery life is available, installed certificates, etc.
Zenprise policies are pretty easy to setup and can be device specific. The screenshot below shows a blacklist policy for Angry Birds and Dropbox on iOS devices.
You have a few options in Zenprise to add a new device. One option is downloading the Zenprise agent from iTunes / Google Play and enrolling. Enrolling requires the ZDM address, username and password. Once you login, it will prompt you for certificates and any profiles configurations setup by administration.
Once Zenprise is installed, the user can access apps offered by administration and view the agent configuration.
Other methods in Zenprise to add devices include registration using the administration dash (asks for the serial number of the device) and sending out a registration link via email or txt.
There are many options in Zenprise for reports which include inventory, software, jailbroken / rooted and hardware. Below is a screenshot from the next release coming out in June/July 2012. Check out www.zenprise.com for more info on their solution.
Everybody hates losing things. It drives you mad looking in the same places thinking a magic gnome will put your item back. Usually that doesn’t happen. Especially when it’s a highly desired product such as a mobile device. Mobile devices are becoming a leading target for theft since they can carry as much sensitive data as a standard laptop. Hackers can steal your photos, instant messages and web history. Some mobile app leverage cookies that never expire meaning hackers could essentially access sensitive websites such as your bank account through replaying old sessions.
How are these types of hacks executed? For iOS products, a hacker could take your device, spend 10 minutes jailbreaking it so they can install a remote Trojan / Administration app before returning it. This would permit the hacker unlimited continuous access into your life. Another option is dumping the records on their computer to go through later and selling the hardware on ebay. Either way, you have been PWN3D and possible put your employer as well as family at risk of future attacks.
These are just some of the methods used if your device is stolen. See this post regarding an attack calling your phone and remotely hacking your voicemail HERE
There are things you can do to defend against mobile device theft outside not misplacing your phone. Most manufactures offer password protection as well as limiting information exposed pre-login (IE not displaying text messages or other alerts until the phone is unlocked). Enable password features and stay away from easy passwords such as a row of numbers (1234) or the same number (4444). Some devices offer more complex password options than PINs which is great if available. Shorten the sleep/auto lock timer so the window your device is unlocked is limited in the event its stolen. When you are not using your device, press the lock button. Many mobile device screens absorb fingerprints after use, which make it easy for hackers to guess your password. Consider a protection screen that includes fingerprint resistants. Some devices offer location and remote wiping services that can be used to locate and secure lost or stolen devices. Also make sure to notify your employer if a device containing cooperate email or other sensitive services is stolen.
Employers should take securing mobile devices accessing cooperate data very seriously. Some approaches to improve mobile device security are utilizing endpoint management products such as Mobile Iron or Zenprise to enable features described above as well as check for Jailbroken devices (More info on this subject can be found HERE). Employees may not be willing to apply security applications on their mobile devices, which IT could focus on protecting the network as well as data that rests on mobile devices as an alternative to MDM (mobile device management). Some examples are using access control technology to check if mobile device meets company standards before permitting access. Other options are leveraging Data Loss Prevention (DLP) technology, which stops sensitive data from moving to a mobile device or encrypting that data with additional authentication to access. Sandbox solutions are an alternative by locking down the data in a secure session that expires after use (example is Good Technology). Another important function to consider is enforcing VPN tunnels whenever a mobile device accesses data outside of the internal network. This protects against common man in the middle attacks targeted at mobile devices using open wireless networks.
The good news for employers is there are many options for securing mobile devices and the data they use. The investment in mobile security should at a minimal match securing other devices with sensitive data such as laptops and servers. Don’t let mobile devices be the weakest link into your network!
The most successful attacks by hackers typically are not technical. Hackers take advantage of the human element, which is usually caused by laziness or being unaware of a vulnerability. A prime example of this is people not changing their default passwords. Here are two examples of password vulnerabilities you should be aware of.
1 – Hacking a mobile devices (example iPhone):
Your mobile device is a database of your LIFE. Most people don’t want what’s on their mobile devices to become public. Look at all the embarrassing celebrity photos posted in popular magazines such as US today. How do you think those pictures are captured? In many cases, it’s through celebrity mobile devices. If you leave the default password on your voicemail on your mobile device, YOU ARE VULNERABLE to being compromised. Here is the hack and how to fix it.
HACKING A iPhone via Spoofing:
1) Go to spoofcard.com and sign up for the spoofing service 2) Enter the phone number of the target 3) Choose the phone number that will be displayed when you call the target 4) Call and get their voicemail. 5) If they haven’t changed their default password for their voicemail or changed auto access the voicemail, you will access their phone’s records
*Note: Most wireless carriers maintained direct dial numbers to their voice mail management systems. If known these numbers can be used to bypass a call being placed to the mobile device. Resulting in no missed call being registered.
What this means: This is one method of exposing information such as Voicemail, Photo’s, Messages, and browser history.
Fix: Change your default voicemail password. Also change the feature on some voicemails to not auto login into the system. Here is a link to change iPhone Voicemail passwords. http://support.apple.com/kb/ht1687 . Look up your models voicemail password settings and change it from the default.
2 – Hacking a wireless router (example Linksys):
HACK: I find this problem on many networks regardless of size (home to enterprise). Basically connect to a wireless network and look at the IP address provided. Open a web browser and type in the IP with a .1 ending (example 192.168.10.1). Most wireless routers offer a web GUI and default access is usually .1. Open a second screen and Google what the default login is for the device (example admin cisco123).
What does this means: I can own your network. I can see where you browse, what is on your network, etc.
Fix: Change the default password on your wireless network management GUI. You can also change the web GUI interface IP from .1 to something else.
CHANGE YOUR DEFAULT PASSWORDS!!!!
Credits to Aamir Lakhani, Tim Adams and Joseph Muniz. Posting is also HERE
Mobile device security is a hot topic for 2012 and some current industry leaders are Mobile Iron, Airwatch, Good Technologies and Zenprise. There are two approaches to addressing mobile device security, which are a “sandbox” or “application management” approach (more info can be found HERE). My team found the majority of our customers prefer the application management approach offered by Mobile Iron and Airwatch. For those interested in evaluating Mobile Iron, below are some steps to setup a basic lab for testing functions such as remote wipe, policy enforcement, flagging jailbroken devices and other features.
Mobile Iron has two parts to their solution. There is a Mobile Iron VSP (management system) and Sentry (policy enforcement) server that can be a physical appliance or virtual server. The Sentry piece isn’t required but used 95% of the time since it enforces policies built by the VSP. A basic Mobile Iron lab will need ESX4.0 or greater, around 4GB of memory and 40GB of disk space. You can download a Mobile Iron ISO from https://info.mobileiron.com/free-smart-start-trial.html. Mobile Iron will need some ports opened for communicating to devices and data synchronization. Plan to open outside ports 8080 or 8443, 9997, 9998, 443, 2195 / 2196 and inside ports 25, 389 / 636, 9090, 443, 22 and 8443 depending on what services you will be testing. Ports can be changed on the main dashboard if needed.
After booting the Mobile Iron VSP for the first time, you will be prompted to enter basic network information (subnet, gateway, etc.). Fill out the requested information and wait for the VSP to boot up. Access your Mobile Iron system via the domain name you provided plus /admin (IE. mydomain/admin) and you will see a login. Login with the username and password specified during the initial build and you will see the following dashboard.
You can add local users by clicking “Smartphone and users” or a LDAP (under LDAP) for user database integration. At the very top, there is a system link to configure management settings. Make sure to configure SMTP under email settings so you can test alerting. Verify and update basic network info that configured during the initial setup. You can also check for software updates under the maintenance tab.
For those testing Apple products, Mobile Iron recently added an enhanced certificate option that doesn’t require a Apple development license to generate a cert (we learned this the hard way and paid the $299 weeks before the update). For users looking to test custom built applications, a developer license is required however labs testing basic functions such as managing existing apps via the app store, mobile security, etc. won’t need this. Create a certificate and upload it under Smartphones, Settings and Local Certificate Authorities. To read more on generating IOS certificates, go HERE.
At this point, you have a working Mobile Iron VSP and can register a test device a few different ways. One way is to click the Register button in the VSP and fill in the request page. An email will be send to the user you created explaining how to download the Mobile Iron application, server name, user name and password. A second way is to go the user GUI, which is your domain without /admin at the end. Users can log in and register their devices based on accounts created in the Mobile Iron VSP. A third way is having users find the Mobie Iron app using their mobile devices and filling out the server information that is sent via email requests from the VSP. Below are some pictures me registering devices
.
Labels are used to group device types and policies together. The default labels and new ones can be built under Smartphones & Users, Managed Labels. Policies are checks that can be performed on devices part of Labels. Policies can be found at Security & Policies, All Polices. Compliance Actions are what can be done if a Policy is violated (IE blocking or sending a alert if somebody violates the policy “Downloading Angry Birds”. Test out building a label and apply some policies to that label. Create a few Compliance Actions for each policy such as sending out alerts. Place some users under your test label and register a device. Below is a screenshot of testing a policy against Angry Birds on IOS devices.
This is a very brief crash course on Mobile Iron. Check out http://www.mobileiron.com/ for more information on their solution. I’ll probably do a simliar post for those looking to test AirWatch in the near future. Happy New Year!
The majority of today’s workforce uses multiple devices such as laptops, tablets and smartphones (IE brings their own device or BYOD). Leadership from most industries is being asked to permit these devices on the network in some limited or full fashion. Common BYOD questions are “how do I support growth for users with multiple devices?”, “what type of access should guest and employees use for mobile devices?”, “how do I provision corporate mobile devices?”, and “what security vulnerabilities am I exposed to by permitting mobile devices?”. All are good questions and can be addressed by focusing on three core BYOD concepts: Infrastructure, Access Control and Device Management.
The first thing to consider for BYOD is if your wireless network can support growing from one device per user to potentially 2-4 devices. The best way to find out is by performing a wireless assessment to verify capabilities and potential risks caused by obstacles and nearby rouge networks (IE Starbucks using a similar RFID channel). Security features such as wireless intrusion detection and prevention (WIDS /WIPS) as well as controlling the number of permitted associated devices per user should be considered for BYOD to guarantee scalability and service.
Another common area of concern for BYOD is provisioning access to employees and guests. The first BYOD question typically asked is “should all mobile devices be handled by a separate network or should employee owned mobile devices share the same core network while guest devices use another network?”. However you plan to permit mobile devices, best practice for BYOD is to automate the process based on multiple factors such as device type, user authentication and risk status. Policies permitting employee access using personal devices should have a process to register and track those devices (IE web registration page like in hotels) rather than an “employee wireless password” that could get compromised and not associated to a device. Many solutions such as Cisco Identity Services Engine (ISE) offer self-registration to eliminate the need for employee or guest users to deal with an IT member to gain network access. Solutions that leverage profiling technologies can automatically assigned specific access types based operating system, device type and other details (IE provide different access for iPhones and Androids) so you know who and what is on your network. “Knowing is half the battle”, GI JOE
The final piece to the BYOD puzzle is device management. Most mobile hardware vendors give power to device owners meaning Apple, Android, etc. device users can take themselves out of compliance at anytime (blackberry is the only exception). Solutions such as Mobile Iron and AirWatch provide methods to assess devices for high risk factors such as jailbreaking or using unapproved applications which is crucial for BYOD. Application based endpoint management solutions verify devices and either permit or deny corporate services such as providing email based on policy status (IE no email service while angry birds is installed). Common BYOD policies are enforcing the use of passwords, remote locking devices, denying hacked devices, provisioning specific applications and having the ability to remote wipe only corporate data. The mobile security market leaders offer a breath of operating systems and hardware options as well as easy methods to communicate when end users fall out of compliance.
Industry leaders for security are focusing on BYOD by developing solutions for mobile devices. RSA and Symantec recently released data loss prevention (DLP) for mobile devices to deny sensitive information such as social security numbers from moving to or from mobile devices. Network vendors such as Cisco are partnering with mobile manufactures to address BYOD by offering VPN technology that encrypt traffic from mobile devices while off the corporate network. There are many options for endpoint security when looking at BYOD, which the investment for mobile security should match protecting laptops and desktops regardless if the employee owns the asset.
My team built a Cisco Identity Services Engine ISE demo lab designed to secure mobile devices such as iPads, Androids, etc. We ran into a few snags however in the end got the system to work nicely. Here is a guide to help you build a Cisco ISE lab for securing mobile devices.
First the assumption is you have a standard Cisco ISE configuration built. In our lab, we use Cisco UCS to host a virtualized ISE appliance, Active Directory and other services. For hardware, we had a Cisco 3560 switch running 12.2 55E (downgraded from 12.2 58), ASA 5505 (for outbound NATing, info HERE) and Cisco Wireless network consisting of two APs and WLC appliance (NOTE: WLC MUST run 7.X code for Radius between ISE and WLC to work!!!). The ISE system was synched with AD for three identity groups (employees, contractors and guests). We used the default 90-day demo license and enabled all profiling probes. The wireless system was built in a standard fashion.
To start off, its VERY important to check the time in AD (windows clock) and ISE (show clock command). If time is not synched, your radius authentication will fail with a variation of funky error messages (see ISE monitor image above). Once groups are added, test AD users in ISE under external identity store, AD, Connect to make sure the AD / ISE integration is working. Next go to Authentication and verify you have a default 802.1x policy. Click the little triangle and change the ISE identity sources to AD (see below). This will tell ISE to query AD for any device accessing the network using 802.1x. Next go to Network Devices under Administration and add a new network device. Fill out the form for your Wireless LAN controller and configure a shared radius key (cisco guides explain this).
On WLC, go to security and add ISE for radius authentication and accounting. Make sure to match the shared secret used in ISE! Next create the WLAN for your environment. Under Security and Layer 2 in your WLAN, make sure Auth Key Mgmt is set to 802.1x. Under the AAA Server tab add your services via selecting from the scroll down section or manually. Under advanced, check AAA override and scroll down to radius NAC under NAC state. Enable your WLAN and save.
Back in ISE, go to Profiling under Policy and select the mobile profiles you want to include in your lab. Each profile by default will state “Use Hierarchy”. Change this to “Create Matching Identity Group” (see image below).
Next go to Rules under Policy and click down into the Authorization Profiles section under Authorization. This section tells what to do with authorized users. In our ISE lab, we created an iPad Employe and iPad Guest policy which employees were put into VLAN 10 and guests in VLAN 20. You can put users on the same vlan and apply ACLs for control, create a redirection if posture is desired or other combinations of security. Spend time learning the different options for authorization.
The final step is buiding your ISE Authorization policy under the Policy tab. We created rules for specified devices as the Identity Source such as Apple-iPad and Apple-Device as seen in the default profiling section. NOTE: The device profiles you changed to “Create Matching Identity Group” will appear here. Under conditions, click new condition, select your AD, select = and whichever group of users should apply. Below is our ISE policy covering general Apple Devices, Ipads, Iphones and PC workstations for employees and guests. An example is the Identity Group is Apple-iPad, Condition is AD users = to AD_group_employes then apply iPadEmployees which means all iPads used by Employees will end up in Vlan 10 as specified by the iPadEmployee policy.
Hopefully this guide helps you with your ISE mobile device testing.
IT administrators are being asked to come up with ways to permit mobile devices onto the corporate network in a secure fashion (via MDM Solution or other technology) . This subject touches a few technology areas such as access control, secure wireless, data protection and secure management of mobile devices however the focus for this piece will be mobile device management. Members of my team have tested the MDM leaders such as Mobile Iron, Airwatch, Zenprise, Good Technology, McAfee, Symantec, etc. and summed up the following as things to consider when evaluating a Mobile Device Management solution.
The first thing to consider is your desired MDM Solution Policy. Typically there are three scenarios to address:
1) GUESTS / PERSONAL DEVICES – Devices coming on the network as guests that you don’t manage or access internal data
2)CONTRACTORS / PERSONAL DEVICES ON NETWORK-Devices coming on network with partial access to corporate data
3) EMPLOYEES / CORPORATE DEVICES - Devices with full network access and managed by corporate.
The target of most MDM solution requirements is addressing items 2 and 3 while item 1 is typically covered by an access control technology. The two common approaches taken by MDM vendors are a sandbox or endpoint management offering. Sandbox or secure container technologies provide the most security by protecting corporate data within a sandbox application. Policies for encryption, data loss prevention and limiting data access can be controlled through MDM issued access methods rather than what is offered by the device manufactures. Most mobile device offerings give power to users (all but blackberry) however sandbox technology protects the data regardless of rights provided to users. The main con against the sandbox approach is not utilizing native device applications such as built in email, which tends to impact user acceptance. Good Technologies is an example of a sandbox based MDM solution.
MDM solutions that offer an endpoint management approach support specific vendors (Apple iOS, Android, etc) and compliment existing native applications. Application management MDM solutions leverage an agent on mobile devices to control applications as well as issue commands such as remotely wiping sensitive data. Its hard to say application management MDM solutions address a specific threat category however risk is dramatically reduced by using them to remove hacked / jail-broken devices, permitting approved applications and managing native security options such as passwords and data removal. Application management MDM solutions tend to be more suited for “Bring your own device” requirements while sandboxed MDM solutions favor corporate issued mobile devices.
Other factors to consider are provisioning mobile devices and proper control of data access. Consider the activation and enrollment options for the three use cases listed above (Guests, Contractors and Employees). Can employees register personal devices for access via a GUI or will it require an administrator? How well does the MDM solution assign and manage corporate controlled devices? What are the maintenance options regarding standardizing and upgrading mobile device software for corporate managed assets? Can the MDM solution provide reports listing all applications on mobile devices accessing the network? A strong MDM solution should handle all of these, which specific data access is controlled based on how users authenticate via local authentication or advance access control solutions.
The final thing to consider is MDM security features which usually are common across the leading vendors. Top features include verifying device configuration policies such as checking for hacks or jailbreaks. Policies should be flexible depending on if devices are corporate or personal. Mobile device applications should be verified and controlled to avoid vulnerable software such as a game with backdoor malicious intent. Remote wipe capabilities should be available and focus only on corporate data (IE do not wipe personal email, contacts, etc. without the end-users’ permission). Data protection such as password enforcement should be enabled through a centralized platform. All of these features should be displayed in a report so leadership can verify the security status of mobile devices accessing corporate data.
Every MDM vendor has their own way to accomplish its features so it’s a good idea to develop your policy and match it to MDM solution rather than an open comparison between products. Hopefully this gives you some points to consider for your MDM evaluation. Also note subjects like access control, two-factor authentication, secure wireless and other technologies should be considered for a complete solution.
