Seems like everyone right now is scrambling to MDM (Mobile Device Management) to get a handle of their BYOD (Bring Your Own Device) situation. CIO’s across the board are seeing the benefits ($$$) of BYOD, but adoption of this strategy translates to headaches for IT Support and migraines for Security staff and introduces a whole new set of hidden costs and exposures.
In this article we’re going to highlight the common mistakes organizations make when adopting BYOD policies or deploying MDM solutions.
We’re going to skip the background regarding WHY CIO’s are shifting to BYOD, or whether it is or is not a recipe for disaster and just assume you are either in the middle of an MDM deployment or seriously considering and/or piloting one right now.
3 Major Risks
1. Legal risks:
Loss of access to data from a lost or compromised device: An organization would have a difficult time showing that they took due care in the storing and management of their data or their customer’s data if the support and management strategy for these devices is “do it yourself”.
Additionally, issues around liability arise if a company does not prohibit or control the use of personal devices for company business. If this is the case, then the expectation should be that the employee is not liable with the responsibility for loss or damage to the data would fall upon the company not the employee. This is akin to using a personal vehicle for business use related work when it is required as part of their job function – in case of an accident both the company and the employee are liable.
Recovery of Data: Does a CIO expect that an employee who has been terminated will hand over their personal device for IT to verify all corporate data has been removed? This process needs to be automatic and smooth.
2. Unmanaged Devices (Virus, Torrents, oh my):
The rise of malware targeted at mobile devices of is amongst the largest risks facing organizations. According to the Juniper 2011 Malware report “identified a 155 percent increase in mobile malware across all platforms compared to the previous year” and the growth of the Android operating system, as the predominant mobile operating system has seen a 3,325 percent increase in the last seven months” (Juniper, 2011).
3. Maintaining Corporate Data Access:
Enterprises struggle with the identification and the classification of their data and may not even realize where their most sensitive data resides. This is evidenced through the adoption of DLP technologies that focus on the identification of these data initially before moving into enforcement. This is exacerbated with the proliferation of unmanaged devices that likely will store these data as part of their daily use.
So now that we know the risks, what can we do to mitigate it without eliminating BYOD altogether (Security Folks would rejoice!). Mitigating the risks of BYOD depends on a) the level of access you’re granting to the network and b) scope of devices being used. For this first article, in a multi-part series, we’ll discuss limited access to the network and smartphones/tablets only.
Enter MDM (Mobile Device Management)
So you want your users to use corporate mobile apps, browse the intranet, test betas of public apps, and get onto the corporate wireless (802.1x) network. MDM can help you do most of this by:
● Configuring OnDemand VPN profiles
● Distributing 802.1x certs
● Enabling an Enterprise AppStore for in house and beta apps
● Enabling a document store
We won’t be talking about how to configure each of these technologies, but instead possible security pitfalls in each of the configurations.
MISTAKES and SOLUTIONS
1. Weak Passcode/PIN Security
Once someone has physical access to your device: The game might be over… unless you took decent precautions ahead of time. For example, Apple devices are hardware encrypted, however those keys are still accessible and bypassed via the device PIN/password with physcial access to the device. As of this article, full access to an iOS device with a 4-digit PIN can be achieved in 20-40 minutes with physical access of the device. This includes access to the keychain which most likely contains your Active Directory password, RSA softtoken, Gmail password, Amazon Account info, and Banking username. Game over.
- Use a strong PIN/password. 5 or 6 at the very least mixed-case alphanumeric. As with all encryption, if the cost is too high for an attacker to sit and decrypt, they are more likely to just walk away from the data.
2. Failing to turn on Device Encryption
- Self-explanatory. Just turn it on. It’s crazy how many people never take this step.
3. Unrestricted Mobile VPN Access
So you decide that it’s cool to have OnDemandVPN on your device. OnDemandVPN is when a user browses to http://intranet.acme.local a VPN connection is spun up with the built-in cert and bam they’re online on the corporate network! Pretty nifty!
Did you lock down all the connections possible with that VPN profile? Is there really a need to access your ENTIRE corporate network from the mobile device? If not, lock it down! Are there ANY other authentication steps into your data, or is this is?
- Separate the mobile VPN profile from the mainline VPN profile.
- Create a whitelist of IP’s and ports that are allowed to enter your network from that mobile VPN profile.
- Separate the change process of whitelist approval from the team responsible for adding the whitelist to the VPN.
4. Lengthy Certificate Lifetimes
Having a certificate lifetime of 1 year or more can be very questionable, depending on what the certificate is used for and the level of access it provides (Corp Wireless, Mobile VPN, App Authentication) and more importantly if this is the single factor of authentication for your data.
- The lifetime of the certification must be inversely proportional to the classification of data access. The shorter the lifetime of the cert, the less time a stolen certificate would be of use.
- Use jailbreak detection
- High PIN Security, protecting the keychain and thus the stored certs
5. No Certificate PINs
In order to best secure a public/private key pair, a password or passphrase is placed onto the private key to protect it. This is in addition to making the certificate non-exportable. It adds assurance that the ONLY person who should move the cert is the original owner.
No Solution Available:
- In mobile deployments building in an automated mechanism to prompt for a password/pin with current technology is not currently feasible. It would be nice to see this mechanism a reality and deployable in the mobile world. However, customers need to demand it first.
6. Un-Encrypted Backups
Your device can be secured like Fort Knox, but if your iTunes backups are not encrypted and your computer is compromised or lost, your data is easily accessible from that backup file, bypassing any security controls to begin with. If your backup file is encrypted, then a password would need to be entered to open the file and you have bought yourself some time; lots of time if it’s a good long password.
- Encrypt your iTunes backup. Mandate this in your MDM policy.
7. Relying on Keychain Security
This is geared more for the Mobile Application space. IMHO, one should not trust the built-in keychain/keystore entirely. Have your application hash or encrypt the key or password before putting it in the keychain. In the event the keychain is compromised, the data is thus useless.
- If you have any concern on losing what is in your keychain, increase your PIN security and encrypt your backups as mentioned above.
8. Allowing Jailbroken Phones
So you’re an admin of the network and very tech saavy. You probably have a jailbroken iPhone. Why be limited? Sorry to break it to you (no pun intended), but a Jailbroken or rooted phone is a big problem. It’s no holds barred at that point, since all the isolation & security controls on JB/rooted devices are bypassed. Malware Apps are very prevalent on underground markets and very powerful. Especially if any of your userbase are using pirated apps (very accesible) or “questionable” material (ie porn).
- Keep your jailbroken phones for home use only.
9. Uncooperative Device Vendors & Manufacturers
Many MDM providers have found it difficult to do low level operations on devices just as jailbreak detection. So MDM providers have had to become very creative (at the expense of user experience sometimes) in detecting jailbroken devices. One vendor for example uses location services hooks to detect a jailbroken device. So every time a user’s location changes, a routine is activated to check-in the phone and check for jailbreak. However, the location triangle is frequently displayed and users are thus concerned about battery life. Device manufacturers need to provide a clear path for MDM providers for jailbreak detection.
- Pressure Device Vendors & Manufacturers to easily accommodate security detection controls.
- Pressure MDM vendors for these features.
10. Poor User Termination Procedures
When a user leaves the organization, ensure all corporate data is removed from the device and all profiles deactivated. iTunes will still have their backup though. Something to ponder.
- Bake in exit process the removal of enterprise data and apps from all employee devices.
3 Attack Scenarios:
The Brute Force attack
Your laptop is stolen and your hard drive is unencrypted. Your iTunes backup is unencrypted as well and is recent. Attacker accesses your iTunes backup and now has all your Keychain passwords (Active Directory, VPN Certificate, Banking Username, website cookies, etc) and device PIN. They now have:
● Mobile VPN access
● Corporate VPN access if you don’t use 2-factor
● Depending on the OS, your Wireless pre-shared keys (PSK).
● Lots of other stuff… all of it bad. You’ve been pwned.
The Sneak Attack
Your iPad is left unattended in a public area such as an airplane, café, etc and you only have a 4-digit PIN for security. A malicious person takes possession from your briefcase/handbag without your knowledge for a couple hours making an image of your device and then returning it. Done.
They now have all the information above, and what’s worse is you don’t know that it transpired. They can now maintain the same access to your network until you change your AD password or your cert expires.
The Misconfigured MDM Hack
Users are allowed to use jailbroken/rooted devices with your MDM. User downloads a pirated app containing nasty malware. Malware asks for superuser privileges to perform its “function”, but is actually siphoning your keychain entries, screenshots of your banking passwords, and your browser cookies. Done. The strongest PIN and encryption in the world would have no effect here.
As you can see, it doesn’t take much to crumble or compromise your mobile security posture. All an attacker needs is one gap.
Everything above has been focused on MDM and device security and is meant for those looking do so and have existing and non-complex MDM implementations. Hopefully, something here has been of benefit.
In our next in the series, we will talk about Mobile Application Management and Data security.
The way of the future, which is here now is to focus on the Data. Just as in our infrastructure we’ve moved away from focusing only on securing the perimeter and OS, and instead focusing on securing the data closer to the source.
The same applies to Mobile, and is more important because of the mixed use of devices. What a world it would be if the user never had to enter a PIN to take a picture or make a call, but only have to when checking corporate email, or browsing the intranet via VPN? Focusing on the data and applications, gives us that.
Stay tuned for more on catering to full corporate remote access and all devices (Mobile and laptop) and the future of MDM and Mobile Application Management (MAM).
Founded in 2004, 3Hemispheres works with Enterprises helping them navigate the uncharted and dark security seas. Whether it’s building a security program from scratch, getting & staying compliant, or security assessment & response, 3Hemispheres has helped Enterprises along the way. Clients include Financial Services, eCommerce, Technology, and Fortune 500 corporations. Contact them at firstname.lastname@example.org or visit their site for more info.