For authentication, something I am currently working on a beta for is EyeVerify. I should stress this is not my product nor affiliated with my organisation. This solution uses eye vein biometrics much like a fingerprint but without the need for any additional equipment, just the devices camera. The product is not GA yet but I know they are working with the key MDM providers to integrate the solution into their products. You can find more info here:
http://www.eyeverify.com
With regards to securely wiping a device, the only handsets I have discovered that actually do this are BlackBerrys.
Integrating something like Jonathon Zdziarski's iErase into the actions performed by x number of failed password attempts may help, however this only looks at free space on the device. The reality is deleted data will still reside within live files on the device and the tool is unable to touch this. More info here:
http://www.zdziarski.com/blog/?page_id=407
Even when a selective wipe is performed by an MDM solution data will still remain on the device, particularly iDevices. This is partly due to the way the selective wipe is enacted. Removing the email profile may make the profile disappear on the device rendering the mail application UI un-usabe to the user, however underneath the skin all email data remains. Add to this the way that the SQLite databases work on the device and it is still possible to recover other exchange data from the live files still resident on the device. So, in short, a selective wipe achieves very little to protect corporate data from a persistent malicious 'spy'. The best way to protect the data - as was already - mentioned is to use a secure container which is independently encrypted on top of the device level encryption. However, as was also pointed out the encryption keys must be on the device somewhere. So, we need to look at only allowing specific device types to enrol in the MDM solution to prevent being able to circumvent any kind of device level passcode cracking and ensuring that enforced passcodes are part of the organisations mobile policy. For iOS this means disallowing anything other than iPhone 4S or iPad 2 or newer devices as it is not possible to load a RAM disk on these and attack the passcode unless the device is already jailbroken and SSH happens to be installed. MDM solutions have the function to prevent specific makes, or even OS versions from enrolling ensuring that sensitive corporate data never makes it down to easily compromise-able devices. They also have the capability to identify and act upon compromised (rooted/jailbroken) devices.
Android is a different kettle of fish altogether. Samsung are to soon to release their 'Knox' container for supported devices which will create a protected and encrypted partition on the devices for corporate data. The security is good enough that the US DoD have approved these devices for use by soldiers for BYOD and company liable devices. This supports the position that the 'Knox' solution has gone a long way to providing solid security on this platform, at least for Samsung devices. However, again the keys must be there somewhere.
Unfortunately the keys have to be stored somewhere, and even if they were not stored on the device but say, the device received the keys over the air each time an encrypted application was used they would still need to cached on the device in order to be used by the application, and on top of that the user would have to be online in order to do anything. This makes the aim of trying to encourage productivity of employees by facilitating BYOD or mobile working practices more of a challenge as there are still areas of poor reception, and how would someone work on a plane where there is no WiFi? There is no getting away from this. There will always be an issue with regards to key storage vulnerabilities IMO until there is a practical and cost effective way to use something like a CAC card or RSA type token which houses the keys, and application developers find a way to effectively use the keys and then scrub the memory where the keys were cached prior to use.
Like all things information security related a layered approach is required to ensure that IF someone can get into the device they need to be a specialist not just some have a go hacker who stumbles across sensitive data. The first layer being MDM to protect the device (which ultimately is a foundation and not the answer to everything) and then tie this together with MAM technology to protect the data. There are also companies currently working on VDI type technologies which house the data behind the corporate firewall and use applications on the device only as a viewer/editor and use a secure connection to tunnel back behind the corporate firewall. I am yet to evaluate any of these as right now they are not GA either, though they look far better than traditional VDI which is useless on mobile devices.
Any organisation which takes security seriously will apply data loss prevention technologies to ensure that the most sensitive types of data never make it to the mobile device in the first place. Whether that be by using a dedicated DLP solution or for example simply disallowing email attachments to be pushed to mobile devices for example. An organisation can have an assessment conducted on the devices they allow into their environment to understand the weaknesses of the devices and the time it would take to exploit them. Next perform a risk assessment and adjust their practices and policies accordingly.
Risk assessment IMO is a key step. If the company knows their devices are vulnerable but that it will take 6 months to exploit that vulnerability, and they know that the sensitive information they have on the devices will only be valuable to an attacker for 3 months then there is ultimately less risk than if those figures were the other way around.
Thanks
↧