Share this post:
This is the first of a two-part Q&A on mobile device security with Kevin Johnson, a security consultant and founder of Secure Ideas. As a SANS instructor, he teaches courses in Mobile Device Security, as well as penetration testing.
Kevin is on the Advisory Council of the first Mobile Device Security Summit, to be held March 12-13 in Nashville, Tenn., where he will teach his SANS course March 14-15.
In this post, Kevin talks about the mobile device security policy conundrum and offers some straightforward, common sense advice.
Security Bistro: From a policy perspective, where does BYOD (bring your own device) get really dicey?
Kevin Johnson: It’s always a fun problem to have from a security perspective: The crossing of the streams with personal devices and corporate devices make every policy you have about mobile devices difficult. There’s a very simple reason for that. As an organization, it’s not your device, right? It’s very simple if I provide phones to all my staff. It’s really easy for me to say, "Don’t Do That." Whatever "THAT" happens to be: installing apps, using personal email, IM.
For years and years and years, we’ve understood that when I get hardware from my company, it’s the company’s and they can look at it, they can monitor it, they can seize it back; they can do whatever they want because it’s theirs. When you start dealing with personal devices being used for the organization, we start running into problems, like, right off the bat, can you tell staff not to put their personal email on their personal device just because it also has corporate email on it? In most cases answer to that question is no.
SB: Even if I have a mobile device security policy, isn’t enforcement a real problem?
KJ: Yes. How do you enforce, or monitor and detect when someone has received something from their corporate email, this internal email that’s secret and confidential, and forward it out through their Gmail account? Because both are on the phone; both are accessible. This can be done maliciously or accidentally; so, we’ve really built into the policy violation a really easy way to excuse it” ‘Oh, I didn’t mean to do that.’ So that’s where you start with the problem: how do you control things, how do you limit things? How do you tell someone “You can’t install Angry Birds, or you can’t install that cool flashlight app that also happens to be malware.
What good is policy I can’t enforce? If we have policy that says you can’t install apps on your phone, but everybody install apps on their phone, can I discipline somebody because they did it? No, you’re opening yourself up for lawsuits. So you now have a policy that’s unenforceable.
SB: If I don’t own the mobile device, what happens when the device is involved in a security incident?
From policy perspective, if this phone or device is involved in an incident or suspected to be involved in incident, or even just related, do you have the right to seize that phone? So, I go to the staff member and say, “Hey, your brand new iPhone, I need that now, because we had an incident. Somebody stole credit card numbers or Social Security numbers or whatever. Your phone may have evidence, so give me your phone. Oh, by the way, it’s going to take two weeks to take the image and analyze it to determine if I need the phone still.
So I’ve now taken the cell phone from a staff member. Their phone. Do I provide a replacement phone? Do we have policy for that? What about when a staff member leaves? Do we have a policy in place that says we can take an image of the phone, so that if in three months we find out we got hacked and that user was one of the people involved — not maliciously, they were one of the people hit. We have a drive image of the phone to analyze. If we do have a policy to take an image when they leave, do we have a policy that we are going to take that phone image when they leave?
How do we protect it? Do we have a policy that says we’ll protect it? That personal phone has their online banking credentials stored in the app. By taking an image, I have access to their bank account. Your policy has no value.
SB: Then, does BYOD mean give up on security policy? Can I make it work?
KJ: You have to take into account how to write the policy so it is enforceable. As you start to plan, either you have mobile policies already, and you’re adjusting them because you’ve moved to a BYOD system because of the imagined cost savings, or you’re writing new policies cause you’re just getting into this — we’re just deciding to have mobile policies.
You have to write the policies with the understanding that they are personal devices, that you have less control. So you try to take that into account. So you don’t have a policy that says you can’t install apps, because we can’t enforce that. But we do have a policy that says, while you may have a personal email account on your device, don’t handle corporate data through that account. Don’t forward things; don’t reply to things using your personal account. And, then watch for it. That’s a pretty simple thing to look for on your own mail servers. If I see somebody who works for me responding to an email from an external account, but they are addressing it to internal addresses, that’s a sign that there is the potential they have made that mistake.
SB: From a policy perspective, it sounds like that’s not so different from securing laptops.
KJ: Absolutely. In fact, in most cases, when work with my clients about policies, my typical recommendation is don’t create brand new mobile policy. Adjust your existing policies to take mobile devices into account. So, you have a laptop policy. Change the policy so it just doesn’t say, “these are your laptop restrictions.” It says, instead, any portable device: your iPad, your Android phone, your Blackberry Playbook, and then put in whatever exceptions you need. For example, on a corporate laptop, you’re not allowed to install extra apps, but the exception is that on personal mobile devices, such as phones being used for corporate use, we ask you to take caution when installing third-party apps. We adjust the existing policies. There are two reasons:
1. They are pretty much the same risk.
2. It is much easier to get an adjustment to policy approved and moved through the bureaucracy that is your organization than it is to get a brand-new policy. I’ll actually see where an organization has attempted to create brand-new mobile policy, and the mobile policy either has weaker restrictions than the corresponding device policies or they are much, much stricter, both being a disparity that is a problem. So, your mobile devices are allowed to be unencrypted, have no password. But why the difference from your laptops? The answer is, typically, when they took it to whatever group is responsible for policies in that organization, they went nitpicky on it and started changing stuff, and the result is a policy that was so weak it was useless.
In Part II of Kevin Johnson’s Q&A on mobile device security, he explains why mobile devices are a major security issue and some ways to mitigate the risk to the business.
Share this post: