Just in case you haven’t noticed lately, the BYOD Juggernaut appears to be stumbling in the security department.  It’s time to get your mobile enterprise house in order and containerize your apps to create islands of security on potentially insecure mobile devices.

We’ve seen buggy mobile operating system updates that allow users to bypass lock screens, public app markets full of malware-infected apps, and the easy ability to jailbreak/root devices making them instantly untrustworthy.  There are devices that base their encryption on the user PIN (1111) which doesn’t make the cut with any security professional.  There are mobile device management vendors that claim they can detect jailbroken/rooted devices, but they can’t because the hacked OS cleverly reports incorrect information to the MDM agent.

How secure can your PIN-enforced, fully encrypted, managed device be when it comes with a built-in Trojan Horse back door that allows users to unwittingly download infected apps designed to steal data and send it to another country?

Make no mistake, we are living in the middle of a Cyber war where your mobile devices, your company servers, and your government is being attacked daily by super-empowered individuals, organizations, and even other governments.  They want to steal your ideas and sensitive data while creating chaos and inflicting damage on vital infrastructure.  As a CIO/CSO, it’s your job to keep your organization’s data safe no matter where it resides. Sometimes, following all the best practices to lock down your employee’s devices aren’t enough when users can innocently download an app designed for espionage.  In most BYOD environments, employees resist having their personal devices heavily-managed.  The best thing you can do is treat all mobile devices as hostile and never give any of them direct access to your internal corporate assets.  Expand your organization’s “Guest” Wi-Fi network and send all those un-trusted devices out to the Internet.

I realize this sounds like I want you to suck the life out of the amazing productivity gains we’ve achieved through the use of smartphones and tablets.  Nothing could be further from the truth.  For starters, you can easily implement a baseline level of device security in exchange for allowing your employees to use their device at work.  Remember, virtually every smartphone and tablet on the planet comes preloaded with Exchange ActiveSync client bits that allows you to enforce a complex PIN, device encryption, periodic PIN expiration (like your PC’s), and remote wipe for lost or stolen device.  Beyond that, it’s about keeping your corporate data safe.  Since data is presented to users via enterprise apps, you need to containerize and bulletproof them:

1) Enterprise mobile apps should prompt a user for credentials in order to launch the app.  When assessing a potential threat, assume that an already logged-in device has fallen into the hands of a bad actor.  Yes, for certain apps that deal with sensitive data, requiring additional credentials to get it to launch can slow down a hacker.  I recommend having your users enter their standard corporate credentials including Domain\Username, and Password.  This will make them easier to remember.  You’ll want your app to clear the entered password from memory as soon as possible.  Since a string that captures an entered password is immutable, apps should instead implement either a specialized secure string capability or use char[] arrays depending on the platform.  A mobile OS that doesn’t implement a shared file system that spans across all apps will make this even more effective.  To reduce the vulnerability of an active session, the app should logout after a predetermined time of inactivity or if it notices that the device has moved from a secure location to an insecure one. The takeaway is it’s the app’s responsibility to containerize its contents through the use of credentials.

2) Enterprise mobile apps must protect their local data-at-rest with encryption.  This is important not only for unencrypted devices, but also the encrypted ones where the bad actor is already logged-in and can see everything as plain text.  In this scenario, the app is your last line of defense to protect sensitive data.  The apps should employ AES 256 encryption on their data at rest and the cryptographic modules and algorithms provided by the mobile operating system must be FIPS 140-2 certified.  Oh and guess what, I now have a use for those corporate credentials I asked your apps to require.  Creating an encryption key requires a password and a salt value.  In this case, the Domain\Username can serve as the password and Password will serve as the salt value.  While some mobile platforms have APIs to secure your credentials or keys, it might be better to assume the device is already compromised that therefore require the user to enter their credentials each time in order to encrypt and decrypt the information.  Keep in mind that your banking web site requires you to enter your credentials every single time as well.  Why should your mobile enterprise app be any different?  The takeaway is it’s the app’s responsibility to containerize data-at-rest.

3) Enterprise mobile apps must protect their data-in-transit with SSL.  Don’t assume that the corporate network is already providing a VPN tunnel to allow for the traversal of insecure data.  You also shouldn’t assume that your mobile device automatically supports the wide variety of different VPN protocols employed by all the different vendors out there.  Lastly, employees hate to setup a VPN connection before using their apps and transmitting data because it’s cumbersome and takes too long.  Responsible mobile enterprise app developers will always provide built-in support for SSL for all their app’s data movement needs.  The apps will either use one of the public certificates already found on the device or an imported cert from your company’s enterprise certificate authority.  The takeaway is it’s the app’s responsibility to containerize data-in-transit.

4) Enterprise mobile apps must present credentials to the web services they’re calling in order to send/receive data.  The one thing you can count on across all mobile devices is support for Basic authentication.  Enabling this type of auth on your web server prompts the user for their credentials.  You won’t need to worry about clear text problems because your communications channel is already wrapped in SSL.  On IIS for instance, for the virtual directory exposing the web services, you will enable Basic auth and have the default Domain set to your company’s Domain name.  The web service calls from your mobile apps will conveniently pass along the Domain credentials the device user entered to launch the app and encrypt the local data.  Appropriate Active Directory users and groups will have access to this directory to ensure that only authorized users can access the data provided by the web services.  In other words, it takes the combination of the enterprise mobile app and correct user credentials entered on the device side to unlock the data provided by the web services.  Oh and one more thing, the Domain credentials passed in from the device can also be used to provide or deny access to the SQL Server containing the sensitive data.  And yes, you can encrypt the data-at-rest found in the tables, rows, and columns of SQL Server.  The takeaway is it’s the app’s responsibility to containerize the secure passing of credentials through each tier of your enterprise mobile solution.

5) An Internet gateway at the edge of the network must be employed to securely publish web services.  Since you’re not going to do anything foolish like directly expose your web servers to the Internet and the whole VPN question is often uncertain, you need a way to access those web services from devices roaming on mobile data networks.  Luckily, this problem may already be solved for you if your company is using Exchange servers for email.  Most companies expose Exchange ActiveSync out to the Internet via ISA, TMG, or UAG in order to access email, calendar, contacts, and device management policies.  This same technology can securely proxy the virtual directories where your web services are located out to the Internet using Web Publishing.  These reverse proxy servers typically reside in your company’s DMZ between your front and back firewalls.  Keep in mind that this method of exposing corporate data can often be more secure than providing VPN access.  A VPN tunnel extends your corporate network out to the device and it seems to make people feel safe when combined with device encryption and an enforced PIN.  But what if you have one of those devices that comes complete with a built-in Trojan Horse gateway to a malware-infested app market in the cloud.  You’ve now created a security vulnerability because one of those un-vetted, untested, rogue apps can drive a truck through the VPN tunnel and attack your corporate network directly.  Jailbroken and rooted devices bring the same type of risk and some device operating systems can work with alternate app markets right out of the box.  On the other hand, securely publishing discreet web services via reverse proxy technologies that provide deep packet inspection shrinks your attack surface dramatically.  Visualize a tiny pinpoint on a server that can only be accessed by your mobile app instead of a tunnel that can see all your servers and is accessible by everything on your device.  I think you get the picture.  The takeaway is to containerize access to web services rather than blindly delivering the entire network to a potentially compromised device.

Mobile devices offer the promise of unprecedented productivity by allowing employees to work anywhere at anytime.  Unfortunately, some of them can present security risks that must be mitigated if we all want to see the momentum behind BYOD continue.  You might be wondering why I referred to containerized apps as islands of security.  I guess it’s because I imagine a compromised smartphone or tablet as an ocean of insecurity where the hacker thinks he’s already won.  But he hasn’t.  Those enterprise mobile apps you’ve built following the 5 principles I’ve discussed above are the islands breaking through the water that require their own credentials to launch and take care of encrypting their own data-at-rest and data-in-transit.  Remember, Cyber security threats are at the highest levels they’ve ever been and everyone must take data protection seriously.

This is your Chief Mobility Officer telling you not to get mindlessly swept away by trends like the Consumerization of IT and BYOD without first addressing your company’s security needs.  Containerize your apps!

- Rob