I would like to share my experience with mobile devices security that I have been testing lately. MDM products became one of the strategic products that organizations would like to implement, since nowadays mobile devices store business data and allow remote access to the internal resources.
Choosing a vendor
In order to choose the right vendor, the organization required to map the network architecture, the applications that should be published and the types of the devices that should comply to the security baselines and policies. For instance, the not all MDM vendors support Domino architecture.
Anyway, I suggest to perform the proof of concept stage with 2-3 vendors. As a reminder, see link to Gartner's report from the last month.
In addition, it is required to define the success criteria before performing and functional or security testing.
This is where real fun begins. I would like to share with you the attack vectors for MDM systems.
1. White box testing
In this case, a full security architecture should be implemented since MDM should only be an additional security player. For example, the email services might be protected by smtp relay filters as TMG.
2. White\Black list
Most of the MDM products support white and black lists. However, the common way to handle mobile devices is to allow BYOD (bring your own device), hence on one hand, white listing is not a good solution from user's experience. On the other hand, black list is not a security best practice, actually it is a bad practice. In this case I would suggest to give employees a company's device and then enforce white list or do not enforce anything in case of BYOD. It is important to mention that even white list can be bypassed since mostly the mobile applications send requests to mobile websites, which can be accessed by browsers, e.g. there is no difference between entering the site http://touch.www.linkedin.com/ using mobile browser and using the official LinkedIn application.
It is well known that hacking the mobile device could lead to information leakage between applications, e.g. by bypassing the sandbox. In this case, the risk is that a mobile rootkit\malware will harm or steal business information. MDM products can prohibit jailbroken devices, however, sometimes it is not working. In my case, the MDM product installed its security profiles on my iPad and then I uninstalled the MDM application and followed by jailbreaking the device. As a result, the security profiles left on my device and I could work with the published applications. In order to avoid this exposure, the MDM administrator added mitigations such as smtp relay filters and defined that profiles will be removed due to a jailbreak. My general conclusion form this case is that mostly MDM products have "bugs" that we call them "exposures".
MDM agents and their following configurations mostly communicate with web services. It is pretty simple to use proxy and check what data can be tampered. In addition, don't forget that if malicious user can perform tampering, it might harm the internal resources that the device has access to them (but it depends on internal application's security).
5. Password protection
Don't worry, I don't mean lock screen password. It is important to verify if applications or profiles can be removed by the user, e.g. if iOS profiles can be removed without password requirement, then it might be a security issue.
6. Policy enforcement
It is important to validate whether the policy is enforced de facto. From my experience, there are cases that the policy is not enforced, e.g. the server can require to save a mail history of two weeks, but the mobile device will save everything. Additional examples can include device encryption, remote wipe etc. Policies can be discussed further, but not in this post.
7. Remote support
It is important to verify that if remote support is enabled, then user should approve it. By default, from my experience, remote support notifications are not required by default.
8. Authentication issues
The most common way to authenticate users is by username and password from the Active Directory or other LDAP server (BTW - RODC did not work for me). However, I tested the ability to use an authentication certificate. My conclusion is that this type of authentication can be seriously dangerous since the certificate enrollment process requires access to the CA\RA, which mostly placed in internal networks. Therefore, MDM products perform this action on behalf of the user, which conflicts with the right certificate enrollment process since the private key should be exported, or worse, the user will get the certificate of the MDM with specific additional attribute in the certificate. Hence, it is recommended to test in detail how authentication works and even consider to add a new external mobile domain in order to protect the organization. Of course, administration considerations should be taken into account.
MDM implementation is not a simple process and it requires both infrastructure and application security testing. It is important to mention that MDM products are not matured enough, thus we will always find security vulnerabilities in these products.