How to COPE with BYOD

If you've been in the IT industry long enough, you'll start seeing the same concepts "reinvented" every few years or so.

The current panacea is so-called Bring Your Own Device--the idea that an end user can use their own technology devices in a corporate setting while having some level of access to corporate data. While we went through this with laptops and personal computers over the years, now the devices we are bring our own of? Mobile phones/tablets.

Another acronym I've heard recently describes the state of IT, again, as long as I've been in it--Corporate Owned, Personally Enabled. Here, the idea is that a corporate-owned asset is used for an employee's personal needs. This has been the case with corporate-owned PCs forever without any formal policy for the last couple of decades. Now we're starting to see this with mobile devices, either with or without the use of third party tools.

The reality is that, regardless of whether companies adopt BYOD, COPE, something else, or neither, the reality is, employees are going to use personal devices to do work. And, likewise, use corporate devices for "personal use." This has always been the case and will always be the case, regardless of any formal policies to the contrary.

From a security point of view, this creates some rather obvious issues. On corporate-owned devices, some sort of "device management" or "Endpoint Security" offering is installed, which users tolerate to varying degrees. (I happen to like Check Point's Endpoint Security offering, but I will admit, I'm biased.) BYOD won't work because users are often asked to submit "device management" or an "Endpoint Security" installation in order to use their own device on the corporate network.

But ask yourself: what is it that you're really trying to protect on that endpoint? Prevent malicious software? You have a properly segmented network, right? You have the technology to detect any malicious traffic from that segment, right? Good. That should take care of it.

But what if the software doesn't "phone home" while on the corporate network (or generate malicious traffic), but collects data and then sends it out over the mobile operator's network? Modern mobile operating systems have these things called sandboxes that prevent one app from reading data from another in the first place. Obviously, if you're jailbroken or rooted, all bets are off.

And malicious apps, while not unheard of, are nearly non-existent in the official App Stores for iOS or Android. Same with potential privilege escalation-type attacks in iOS and Android. Not impossible but a lot harder to pull off, given that Android and (moreso) iOS are pretty secure out-of-the-box.

Really there's only one thing to worry about on these devices: the corporate data. This data needs to be protected. Which is generally pretty easy to do assuming only a trusted application is able to access the data, the regular OS protections are in place (i.e. device isn't rooted or jailbroken). And, of course, the data has to come on and off the device in a secure manner (e.g. either with strong encryption or using a physical access mechanism).

Once you have the magic, trusted app (or suite of apps) to access, work with, and secure the small amounts of corporate data the device can work with, congratulations! You've now eliminated the headache of managing potentially unknown devices in the hands of users who will do everything they can to thwart your security controls anyway. If users want to work with corporate data, they can use the "trusted" apps to do it, which should have appropriate hooks back to corporate to validate whether you are able to even use the data and, if you or your device goes rogue, wipe the data from your device without wiping the entire device (which has personal data on it).

While I believe there are great solutions along these lines (yet), this is the only kind of solution I believe makes any sense in the long term. People will be able to bring their own devices and access business data while infosec will rest easy knowing business data is still  accessed and stored safely.

It's a BYOD solution everyone can COPE with.

Securing Mobile Devices May Be Impossible

From via Securing Mobile Devices May Be an Impossible Task:

Attacks against smartphones such as BlackBerrys, iPhones and Android phones have become quite prevalent in recent years and many of them have focused on getting malicious apps on users phones. Thats a quick and easy way to get access to user data and sensitive information. But there are a slew of other real and potential vectors that attackers have at their disposal no, as well. Going after the device firmware is one potential method, as is attacking the mobile infrastructure itself."

If I can update your phone remotely, I own the phone at every level and I own you. Its game over," said Don Bailey, a senior security consultant at iSEC Partners, said during the panel discussion.

While I myself have been thinking about mobile security, this is an angle I didn't even consider. If hackers can pwn the mobile phone network itself, well, everyone's mobile device is in danger. There's not much you can do about it, either.

Thinking About Mobile Security

Mobile devices are, like any powerful tool, a double edged sword. They enable unprecedented ability to access and create information from anywhere! They are also a huge problem for information security.

Unlike a traditional PC, where there are a number of solutions to address various information security needs, mobile devices (those running iOS, Android, Symbian, Blackberry and others) provide little if any mechanisms for third parties to provide security solutions. Beyond ActiveSync integration, which itself is potentially untrustworthy (remember how iOS used to lie to Exchange servers that their mail store was encrypted?), other options for securing the device or data on the device are limited.

That said, mobile operating systems have had the benefit of experience of other operating systems. They are designed to be more resistant to intrusion by requiring signed code, employing sandboxing, limiting the available APIs, and more. It doesn't eliminate the risk of security vulnerabilities, but it does minimize the risk known ones will occur.

Unfortunately, the "baked in" security only addresses a small segment of potential security issues. It does nothing to address future security issues that might crop up. Due to the limited APIs, it is not possible for third parties to address these issues without cooperation from the OS vendor (e.g. Apple, Google, Nokia). Unfortunately, security threats evolve far faster than an OS vendor's ability to mitigate these threats on their own. Just look at how long it took Microsoft to enable the firewall in Microsoft Windows by default, implement driver signing, or any number of other security mechanisms that are just the default on mobile operating systems.

Even so, the most important feature of a mobile device--the ability to access and share information from anywhere--is also a threat to an enterprise. The potential for data leakage is substantial! All I have to do is take a picture of a whiteboard in an office with confidential data on it using an Android phone with Google+ automatically uploading my photos "in the cloud" to have a potential data leak! Not to mention using your personal device to access mobile email and working with attachments.

Even if adequate tools existed to address all the issues on mobile devices, one should not blindly rely on these tools. It comes down to people understanding the security implications of their actions and adjusting their actions accordingly.

Product Leaks And What Can Be Done

It's interesting to see Charlie Schick, one of my Nokia colleagues discuss--on the corporate blog no less--a subject that has gotten a lot of attention thanks how well the Nokia E71 was kept secret before it's launch. And like Charlie, I'm going to drag out some thoughts from Nokia's internal blogosphere--my own specifically. However, unlike Charlie, I don't work in marketing and, obviously, am not speaking for the company here.

I am not opposed to the policy of not discussing publicly announced products. I understand the reasoning. That being said, it's frustrating at times to not be able to participate in a particular conversation about something everyone knows about thanks to a product leak. I think pretending the leak didn't happen is simply silly, which is the corporate policy today.

When a product leak does occur--and let's face it, it's going to happen despite our best efforts--we need to have a communications plan in-place for dealing with it. Immediately, not when the product releases. Somewhere between the current "stonewall" policy and "spilling the beans." I'm not sure how realistic that is, but at least that way we might have some control over the messaging versus in the current regime where the blogosphere has already told all before anyone inside Nokia has had a chance to say word one.

Of course, even if every Nokia employee keeps their lips tight about upcoming products, the mobile phones themselves leak information. Whenever you visit a web site, or upload a picture to Share on Ovi or Flickr, the phone will leave bits of information indicating what kind of device it is as well as certain capabilities. For example, look at the number of photos on Ovi taken with the E71. All of the pictures here right now were taken with a pre-production E71. I can tell you from personal experience that pre-production units are somewhat different than production ones, both in terms of hardware and software. Using this sample to judge picture quality will give misleading results.

While this isn't the same as leaking a picture or sending a damned prototype to a reviewer, it's information none the less. It's the kind of information that shouldn't be out there--especially if we can't actually talk about an unreleased device. Our devices--at least in their pre-production form--should not inadvertently leak information about themselves.

I actually think there might be an interesting "security" feature here: relay as little about the end user device as possible with these service, or even provide the facility change it to something else entirely. I know this is possible to do. Why not make this a built-in feature, along with changing EXIF data and other identifying information?

I have more thoughts on this, but most of them are not well formed or not well suited for outside consumption. What do you think about product leaks and what should be done about them, if any?

SecurID Over SMS: Sign Me Up!

As someone who spends an inordinate amount of time working from home, I always have to know where my SecurID token is. Without it and the six digits it provides, I will pound sand trying to get into the corporate network.

But the SecurID token is lame. Sure, it comes in a number of form factors, but I'd rather not mess with it at all. That being said, as a security person, I think it is a necessary evil.

I was excited when I initially read this article on SMS Text News about using SecurID with something I also need to know where is at all times--my mobile phone! Clickatell offers a service that sends those 6 digit codes over SMS to your mobile phone when you need to authenticate some place requiring strong authentication. You then provide that number--along with your PIN--to the remote server.

I like this solution because it requiers no software to be installed on the phone. It can be problematic when your provider has delays with SMS--happens more often than I care to think about, actually. That being said, it appeals to me greatly.