EMM as a Security Approach - Part II. Popular misconceptions of MDM and Mobile Security

Participating at different conferences and events, it was noticed lots of misconceptions about different security frameworks. It happened when someone applies and uses solutions in wrong way or present disadvantages of these solutions are. Let me share a set of most popular fails on MDM and Mobile Security that usually might be get by specialist as like about " We gonna present our thoughts about <fill the gaps>, because we've just read the screaming headlines 5 minutes ago .... ":

1. "MDM is not good for a protection, it is good for configuration". It's a type solution not directly providing a protection but providing an opportunity to support devices, enumerate devices, configure devices and manage device policies in alignment with a compliance.
2. "MDM is unsafe, because provide weak self-protection mechanisms". First of all, health services are widely known for various systems, cloud-based even. There were a few targeted attack on MDM software. Most of them had a purpose to show MDM was not enough to implement good mobile security. Second, MDM software can only be as secure as the underlying operating system., so it might be challenge to use dedicated solutions as intended.
3. "Any MDM agent (client-side application) can disabled or deinstalled". Not any I guess. According to my experience there are cases when it is hard to disable
   
   • Firmware agents. To make such agents are afunctional, you need to bypass OS security features or update OS by another firmware. 
   • OS and/or additional software like MDM doesn't provide a way to programmatically install, reinstall and uninstall applications
   • There is no way to bypass security features unless you jailbreak or root the device that might wipe all data stored on device.
   • Disabling agent results no access to corporate resources. The rest data stored on a device is subject of the acceptable risk
4. "There is no MDM with a function management protocol". In fact, such MDM has been in existence last 10 years when BES (BlackBerry solution) was the only one MDM. It's obvious that not all of MDM solutions provide so-called Administration API, but since MDM & EMM has come inter-plugged into another services it is impossible not to have these API.
5. "MDM doesn't provide features to restrict application installation ". Say honestly, MDM has weak capabilities to manage applications are limited by black/whitelisting, but these two features are exactly enough to (dis-)allow what application should be or not on certain device. To extend MDM capabilities, it's better to rely on MAM solutions. Let's the previous sentence is wrong and analyze the cases when we could bypass MDM
   
   • Android OS allows sideload application installation
   • iOS prevents any sideload activities since Ch. Miller discovered a vulnerability and was fired from Apple Developer's community
   • BlackBerry OS. BlackBerry OS was allowing this installation type unless new QNX-based BlackBerry OS had arrived. New BB OS prevent any double-click installation too except user performs a double click on APK-file (not .BAR file). Usually, BlackBerry doesn't support insecured Android API. So, there is s possible to bypass MDM with built-in Android simulator and run a sideload installation. On another hand, MDM prevent third-party installation that means no one of APK files could be loaded on the device. 
   • Windows Phone OS prevent sideload activity unless you jailbreak it, but if you do that, you will get a broken application market 
   • Android OS Zoo (android-based OS) is officially not supported by EMM technology stack yet.
   • MDM vendors expect that every OS should prevent it by itself, thus, MDM solution is probably not overload with that feature.
6. "MDM doesn't protect data-in-transit/in-motion". MDM vendors try to support data protection between the device and MDM as well as between MDM and web services that supports a HTTPS/SSL in turn. Obviously, you should use special-purpose software like a VPN or another depends on needs
7. "MDM doesn't provide a control of inbound/outbound data ". Like a previous statement, MDM vendors try to provide a resource management by black/whitelisting to restrict access to certain URL. In fact, there is a better solution - Network Access Control (NAC) to implement rule-based policies and define who has access, what resource is accessed, when and where it goes.
8. "MDM is pure if you want to manage Android OS". This statement should be paraphrased in a different way like "Android OS capabilities is pure to be managed by MDM solutions". If you're familiar with EMM in general, you know that officially published capabilities on Android remote administration is pure more than other OS. Thus, the root of evil in what OS offers from a management viewpoint, not vice versa. Moreover, Samsung accepted that challenge and presented new firmware to extend Android OS capabilities. In other words, 
9. "MDM should protect application data, while MDM doesn't". The question is why software developers (of that applications) don't protect your data and why MDM vendors is obliged to do it instead? There were enough presentations on inprivacy of application data and two last years (at least) several companies has grown up and improved their skills in MAM & data protection. They offer enterprise app markets, they share reports on data leakage while software developers still doesn't protect data of application we use and share everyday.

Additioally, check my post to find out what is EMM techonology stack & framework and what the difference between layers are