About the author:Joel Snyder is a senior partner with consulting firm Opus One in Tucson, Ariz. He has worked in IT for more than 25 years.

Read the full transcript from this video below:

Joel Snyder’s five-step mobile device protection plan

Joel Snyder: Specifically here I'm going to mostly be thinking about Smartphones and a little bit about laptops; but mostly about Smartphones, when I say mobile devices. The reason for that is not because I think the risk is any different for laptops, it's just that I think, and my experience is that people have kind of a better seat of the pants feel on what to do with laptops than they do with Smartphones and other kinds of mobile devices. So I'm going to keep using this term, mobile device, mobile device or PDA or Smartphone, but mostly what I'm thinking about is those Smartphone type devices, because that's where I think the advice is best. So now I have this sort of insert statistics here kind of slides, oh look there are many devices. "Oh look, they have lots of storage capacity. Oh look, we lose them very frequently". And the next slide is "oh look, it can be really expensive if we lose customer data". So you've all heard that, you all know that, presumably you all made that decision before you flew or came all the way to Chicago, so I'm not going to go into all that nonsense.

Instead I want to talk about how to secure mobile devices. Now there are a couple of options. Plan A, which I have seen in a number of companies, is well we solve our mobility security problem by simply forbidding the use of mobile devices. And you can see a little bit of clip art that I stole off the Internet showing some mad, angry mob ready to lynch the person that made that ridiculous decision. So Plan A is probably not going to work for most companies, although it is an option. And if you've chosen to do that then you can go back to posting on your blog or whatever and you don't have to pay any attention to me. Plan B, accompanied by another equally insidious and stupid piece of clip art, is to use policy and technology to do secure mobile devices. And so I'm going to be mostly talking about plan B today, for companies in which plan A is not the option. So I decided, arbitrarily, by making up a number and figuring that five was better than seven, that there were five things that you should do to get mobility security. I'm just going to walk through those five things over the next 46 minutes.

First. A number one thing, and I know people hate it when I say this, you have to have a policy about these mobile devices. And the reason is that if you don't have a policy, you cannot build anything else on top of that. There are a whole bunch of specific issues for not having policies. So, for example, if you don't have a policy what to do about mobile devices then what happens is everyone becomes their own little, miniature IT department. They go off to the Verizon store or the T-Mobile store or whatever and they spend a couple of hours and they talk to some sales person, who definitely has your company's best interest at heart, about which device is the one they should get. Then they talk to their 14 year old and they talk to their 9 year old and they buy the one with the pink case, or something like that. That's a very inefficient way for you to acquire and use mobile devices in your enterprise.

If you have no policy you also open yourself up to a claim of negligence. Now negligence is a magic word I am not a lawyer, of course, but I do know enough about the law that when you just sort of do something stupid then you can be punished for it. But if you do something stupid and it is found that you are negligent, then often you are punished three times for it. So this is where this trouble damages sort of thing comes in. So, if you are negligent in your behavior, as opposed to just accidentally running into the guy in front of you in your Suburban or whatever, then it's much, much, much worse; and not having a policy can be considered negligence. In addition, of course, if you don't have a policy then you haven't set any boundaries and there's a mobile device right there. If you haven't set any boundaries and that tells people implicitly that anything goes and that you haven't made any decisions.

All right, so this is a picture of what a policy looks like. If you ever have been to any of my talks, you know I love these little cycles. These are the different elements that you would have in a mobile device security policy. And I came up with sort of four big areas. Selection, deployment, use and recovery and then there's some little steps that take you around that whole picture. The idea is that you select a device, you somehow get it out to people, people use it, and then at some point or another, they lose it, it breaks, or it gets worn out or outdated, you recover it and then they go onto the next device. That's why it's done as a big huge cycle.

When you're putting together your mobile device policy, which is going to include security in it, you want to look to make sure that you have covered all of these different areas. How are we going to pick devices? How do we get them out to people? How are they allowed and how should they use them? And then, how do we deal with the loss, breakage, replacement, obsolescence issue? Which is inevitable in mobile devices and much more significant than it is in things like laptops and desktops.

Now, it's not necessarily true that your policy is just a bunch of stupid words on paper. You can get technology that will support your policy. So this whole section here that I've circled, the provisioning, the deployment and the configuration of devices, that actually can be a technology solution. So yes, you have to write down what it is that you want to did with the device, but then you can get technology which will help support that. That will go into the device and blast the perimeters properly and set it up or whatever it is that's required to get the device properly set up for deployment to the end user. So your policy is not just a bunch of words that you write down and no one bothers to ever read, your policy actually can get implemented in technology. And that's an important part of writing your policy. Because as you're going around in this circle and trying to figure out what's happening here, you might say "we can get technology which will let us enforce this or let us enforce that". Or "we can get the technology to do this, so let's try to put stuff into the policy and make ourselves a nice big circle". Now you don't want your policy to be dictated by the piece of junk software you happen to have bought the week before or whatever you saw demoed at ISD or whatever. That's not how you write your policy. But it is good to have your policy at least live within the constraints of the technology which are available.

Now, one critical part of policy is device use. And Dr. Thompson's talk, just before me, was all about sort of changing security culture. Well this is part of changing security culture. When you start handing out devices, which are critical to the data integrity of your organization, you have to get the people who are touching those devices and using them every day to actually buy into your security policy. I use those terms specifically, because I'm not talking about buying into a security policy in the sense that there's a seven page document and they have to check every paragraph, which they do just to get the device and then sign at the bottom and then throw it away. I'm talking about actually making sure that people really understand what it is you're trying to accomplish and say "you know what, I will do my part to help you". I think Thompson said, "People want to do the right thing". Well people will only want to do the right thing if you tell them what the right thing is with these devices. If they have no guidelines from you, if you have just some dense legalese document that doesn't make any sense, then they're not going to know what the right thing is. But on the other hand, if you spend the time to do a little bit of employee education, a little webinar here or there, a little bit of training, maybe a 15 minute seminar that they can go to at lunch time or watch on the company multicast or whatever, that actually pays off. Because then people will tend to the best thing. And as well all know the weakest link in all of our security is the person. That's where the real weakness occurs, is human error. That's where the biggest set of problems come from.

Now, as you're constructing your policy, at the very beginning, maybe I should have put this slide a little earlier, you have to make an absolutely critical, fundamental decision. Which is who owns this phone. Now I don't mean who owns as in who paid for it, no one cares who paid for it. You paid for it, they paid for it, the carrier pays for it, that's not really relevant. But who is in charge of this device. And, obviously, there are two answers. Either the end user is in charge of the device, they make the decisions on the device. Or, the organization is in charge and "owns", and I put that in quote, "owns" in the sense of is responsible for the management and control of the device. You have to make this decision and you have to be very explicit about it. Maybe should be the first sentence in your policy because everything else devolves from that.

If you say we are responsible for the device, then that puts responsibility on your for configuration, management and control, but it also gives you the flexibility to put data on that device and to let the user use the device in a way which will empower them and give them a lot of access and make them a better, faster, more productive mobile worker. If you say "no, we are not going to do this, the device is the users problem, they're the ones that manage it and control it and effectively are responsible for it", then that's going to severely restrict the kind of information you are allowed to push out to that device because you have lost control of, in many cases, critical business information. So you have to decide up front whether you are going to take responsibility; and then also get that nice empowerment, or you're going to say "we are just not prepared for that, that's not the way our company works, or that's not the way we want to do it". In which case you acknowledge what you cannot let people do with these devices.

Now I talked yesterday about generation Y and I'll reiterate that. That the mobile device problem has gotten much, much worse because of this generation Y of workers that are now moving into the organization. Folks for whom work always includes home. So on that device at work they will also expect to be doing something like SMS'ing to their buddies about lunch dates, which are not business related, but also when they're at home they will want to have access to work information. So they're going to expect to have access to the same kinds of data that they have at their desktop that they have in their office, or their little cube city or whatever it is you stick workers in, as they do when they're at home. So this pressure here is what's pushing us towards mobile devices, and towards innovative use of mobile devices. Not just ship and email out on a phone, we've been to do that for more than 10 years, that's no big deal, that's old hat. This is much, much more interesting use of these devices to get people more connected to their own organization. Of course there are some organizations that don't even have the cubes anymore, everything is done on the mobile device, more often it's a laptop than a phone.

All right. Number two, second task for mobile security is dealing with data in motion. And there's a very, very simple rule here. Nothing important moves unencrypted. That should be a simple maxim for any secure use of a mobile device. Now on the left-hand side I have this idea that there is some sort of spectrum. Well we talked about nothing important moves unencrypted but we've got really important data and sort of important data and not really important data. That is a huge trap, do not go down that trap. There is no such thing as a spectrum from important to unimportant. There are only two kinds of data in the world. There is our data and there's stuff that's not our data. If it's our data by definition it's important. So don't spend your time when you're dealing with mobility security trying to decide this is sort of important or kind of important and really important. No, no, no, you're making things too hard for yourself, you're making things too complicated, you're opening yourself up for all kinds of error of judgment and of technology. Instead simply say everything that belongs to us is important. Everything important must go across the airwaves or the wire encrypted. Period. That's a very, very simple statement to make, not necessarily so easy to do.

Now when I say anything moving, what I mean is any sort of wireless communication. Now when we look at these mobile devices there are three wireless radios in these devices nowadays, if you don't count the GPS receiver. First is going to be what I'm just going to generally call the mobile device service. So if you're on GSM then that's going to be a GPRS or 3G or 2.5G or edge. If you're on CDMA then it's some sort of CDMA data service. Whatever the data service is, I don't really care, but this is a service that's provided in conjunction with the mobile voice radio part of the device. Now the nice thing about those is that this week, today, as of 10:15, your average bad guy can't walk into a Radio Shack and walk out with $50 worth of parts to eavesdrop on that data. It's actually hard for someone without very expensive laboratory equipment to actually eavesdrop on that data. So because of that people tend to think of it as lower risk. And it is slightly lower risk. If it's hard to eavesdrop on it then it becomes lower risk. It's inherently a little bit more secure. However, that's today as of 10:15 in the morning. Now at 10:30 tomorrow or 10:30 today that could entirely change. So you cannot depend on the risk of disclosure of data over the cellular network as being any less significant than WiFi, which we all know is horribly insecure and anyone can sniff that with their laptops. In fact, it's hard not to sniff it with your laptop, when you open up your laptop everything you see is all the data flying around you.

So whether you are sending the data through the cellular network or through the WiFi network, that's the second radio in all these devices, it has to be encrypted. Don't ever fall into the trap of thinking that somehow because it's a private network, I hate it when people say that, there's no such thing as a private network anymore, because it's a private network that somehow your data are more secure. It's not the way it works.

Now there's a third radio in these devices which is the Bluetooth radio. Most of these devices are using Bluetooth for that little weird thing that you stick in your ear so you look like a sylon borg kind of weird character, but it's also often used in more advance devices for syncing to your laptop. So when you're not doing over the air sync, which is the best thing to do, but you're actually syncing to a laptop when you have to be next to it, you're also doing data transfer. Now the problem with Bluetooth is not that there's not security in it but that we have almost no control over the security. Now most of us have spent time working with WiFi and we know there's a whole bunch of check boxes and by going to eight years worth of lectures, you've determined that this is the good check box and that's the bad check box and we don't use weapon, we do use WPA blah, blah, blah. But you feel very much in control of the security. You know that if you check the WPA box that people are not going to be listening to your transmissions. Well Bluetooth was designed to be really easy to use hence there's like a four digit PIN to pair two devices, which is completely a crock of shit, but that's just the way it is. And it's always 1234 or 5555 or whatever it is, it's usually 1234. Anyway, the point is that we don't have all those check boxes with Bluetooth which means that we are not in control. So therefore, you should not be using Bluetooth for data transfer because you cannot control the encryption at the network layer.

Now I'm going to talk about other kinds of encryption that we want to add on top of this. But normally when we do a device sync, from a device to a laptop with Bluetooth, we are very much out of control of what's going on with that device. And therefore, one of the things that you may have to give up to do mobility securely is the ability to do Bluetooth sync to your device. Now Bluetooth headset has it's own little set of security issues, but that's more a charging issue. You know, someone's going to take over your device with their headset, they'll start making 900 number calls, blah, blah, blah. But that's not what I'm so concerned about because that's not a data issue for me.

Now if you are going to protect your mobile data services there are essentially two ways that you can do it. Now I just talked about the cellular network or the WiFi network. Yeah, that's one way of applying encryption, we don't have control over the cell network. So on top of that we have two layers. We've got an IP layer and we've got an app layer. And those are more or less the two choices that have come up with these mobile devices. If we protected that app layer, what does that mean? Well that means that every single app has to have it's encryption. So a good example is going to be a web browser, one of the most common app access tools nowadays. You would have to https instead of http, in order to get encryption of data in transit using these devices. Now the problem with app layer encryption is that you have to have every single application have encryption in it. Now if you only have two applications, a web browser and email, that's not so hard because they come with SSL-ish based encryption. But if you start to do more innovated things with the API on the device, now you're going to have to make sure that you're always calling an SSL library and that every single application has somehow been SSL-ified, or TLS-ified or SSH, or however you want to do your encryption and authentication. That all has to be handled by you as the app developer. And if you start buying third party apps and the third party app doesn't have the tool then you've got a problem.

Now I've got a whole bunch of bullet points here. The nice thing about doing application layer encryption is that you get to enforce at the firewall, you only let people in on ports 443. What it does though as it opens up this area where anyone off on the internet can actually get access to any of your applications, although in an encrypted way, by knowing what the name or IP address is and the relevant port on the inside. So you do have this issue that you're opening up this nice, fat hole for internal applications that you want to blow out to people. So some people don't like that. If you're also doing app layer encryption that also limits access to what you are willing to open up through your external firewall. Because, again, these devices are coming in, they're going to look like they're coming over the internet. Yes, in some cases you can make a carrier agreement and have a backdoor channel but most people don't do that unless you're a 50,000 employee company and if you are you're probably not here listening to me in Chicago right now. Now the nice thing about app layer encryption is it's less intrusive to the end user, it tends to be more device independent because the web browser or the email client is provided by the vendor and you don't have to go an add that in.

All right. Well, what's the alternative? The alternative is going to be to do IP layer encryption for data in motion, which we would call a VPN client. So if you're going to do IP layer encryption that means that you have to have a VPN client that you throw onto each device. And that can be a potential interoperability or support issue if you don't have VPN clients for all the devices that you want to use. Now the nice thing about IP layer protection is you don't have a big attack surface, you're not opening up a bunch of holes to the internet, you just have that one VPN concentrator and since you've already got that VPN concentrator set up for your mobile workers, that's no big deal. The problem with the VPN client, it can be intrusive, it can be annoying, it can slow down transmissions, it can take a while to actually bring up the VPN connection if you've got old devices, like the old Palms or whatever, these can be quite slow. And you have to actually get that VPN client. But the nice thing is if you have a VPN client then any application works because you don't have to worry about individual application layer encryption, you just send the stuff in the clear at the app layer but it's encrypted at the IP layer.

Now is there a right or wrong answer to this? No, there's no right or wrong answer. These are your two option, you do whatever you want. But you have to pick one of the two. You can try and mix and match but once you've got the VPN client up you don't need app layer encryption. In fact, it's just going to slow things down on these fairly underpowered devices.

Now when you start talking about WiFi, that's another transmission mechanism and in the enterprise, I've got a picture here of some companies world headquarters, this happens to be Amazons world headquarters, there you can have any sort of encryption that you want at the data transmission later. So that's easy to control. But once someone leaves the company and goes out to the wide world of hotspots and hotels and convention centers and people doing internet sharing and whatever else it is that they're going to do to get access, then you lose a lot of control. So now you don't have the option of calling for encryption at that transmission layer. Well as far as I'm concerned that's OK because WiFi is hard to control. You either go back to that IP layer, application layer encryption. If it's encrypted at the app layer or the IP layer, you don't have to worry about WiFi encryption. So the point of this slide and the previous slide is to say there is really no change in your WiFi policy that you have do because of the mobile devices. Whatever you were doing before is fine because we already said that you're going to encrypt at either the app layer or the IP layer, so I don't care if you encrypt at the WiFi layer. In fact, if you want to let your users get on to a WiFi network as though they were guest users rather than bringing them into the corporate side of the WiFi network with their authentication and all that kind of stuff, that's fine too; because you've already taken care of the encryption and authentication for all their applications. So either way is fine, it really doesn't matter. We're engineering for the internet not for the special case of the WiFi in your company.

All right. Number three, third rule, third guideline, third strategy for mobile device security, is that nothing sits around unencrypted. Now it is absolutely true that as long as no one ever loses a device, you can simply ignore this. So if no one has ever lost a device in your company and you're sure that no one ever will then you don't need to encrypt the data on the device because you don't have to worry about that data falling into ill hands. This picture here, I live in Tucson, is the University of Arizona's lost cell phone box, or it was as of a year or so before, when I took this picture. So there are lots and lots and lots and lots of lost cell phones out there. Now. you can start by making sure that the data that you send over to the device, once it gets decrypted because I already said that you were encrypting this here, is then re-encrypted before it's stuck onto the individual device.

Now, here we get into a lot of hairiness with different device characteristics and different device capabilities. Sometimes you have to do document level encryptions. Sometimes you can do a partition inside of the device, you can encrypt there. Sometimes you encrypt the whole device. There's all kinds of different issues but now we're running into, wait a second, can I do this? What will this work on this device? What about that device? I've got a Palm, I have no concept of any of this sort of stuff. And then what do I do about devices that are just too stupid to do the encryption for me? Well that's one area that you have to worry about when it comes to data at rest. But data at rest is not just your data that you have to worry about. The data on the device and be very valuable even if you didn't put it there. So, for example, when people send SMS's or MMS's, I guess you call them text messages here nowadays, those are stuck in the device in the sent mailbox or in the in box, they could be in the outbox. Those often have very sensitive information in them, and they're usually not encrypted because that's not considered your data. If you have a corporate phone directory and you're syncing to the device, that has valuable information in it. If you have an application which is a web browser on the device and that web browser is talking to various pages in your company, encrypted data that are stored may well not be encrypted when their cached. And remember these devices try to give the user a good experience and they do it by caching as much data as they can on the local hard disk or SD drive, whatever you want to call it.

Another issue that you need to worry about on these devices is that most people nowadays have multiple email accounts. They have an enterprise or corporate email account and they have between one and 80 yahoo and Hotmail and gmail and one and one and whatever additional email accounts. It is generally true that people tend to co-mingle business email and personal email. I don't know, does Sarah Palin mean anything to you? People will have their business email in their yahoo mail account. People will have their personal email in their corporate email account. Just because you've spent time trying to protect your corporate email account doesn't mean that the other account which is being downloaded onto this device or read with a web browser is not going to have equally important information on it. So there's all kinds of issues with the data actually stuck on the device. Now the problem that we have as IT people is that the device vendors don't care about this. They do not care about encryption. First of all it slows down the device, second of all it's a very, very special case kind of project. It's not the sort of thing that they care about. So what you end up having to do, if you want to talk about encryption of devices, is go to one of these third party players that want to sell you some sort of device or device software that works with your mobile devices to add additional encryption onto the device. And this is sort of the ugly, unpleasant part of device mobility and device security. I made this number three because I think this is very important. You do have to worry about data loss because you have to worry about device loss.

Now one nice thing for us is that we have what I call Craig Methiasis law, which says that actually the device vendors will get their act together. There's going to be some organic growth. Inevitably the security features that we need today will start showing up in these devices three years from now or four years from now or five years from now. People will tend to roll this stuff up into the operating system as they begin to figure out that it really is useful and that enterprise users need this kind of stuff. Unfortunately, they're not going to fix it today. So you're going to have to go back to this magic quadrant kind of crapola, and find some device software vendor that can help you encrypt data on that device, if you want to use it securely. That's the ugliest part of my plan, that whole encrypting the data on the device. Sorry.

Fourth issue, Malware; fourth strategy Malware protection. I can tell you that these mobile devices are high priority targets for Malware. Just because you haven't seen it on your device does not mean that there aren't folk actively trying to break into these devices. And one of the reasons that we don't see too much of it is, going back to Thompson's lecture, that there's not much money in it. Now I do have a great story about a colleague who was out of work, lives in the UK. And his strategy for making money now is to make a little gadgety thing that he sticks into a briefcase and walks around London airports. London airports are nice because there are a lot of people walking around in them. They're often wealthier than your average person because they're flying, and they all have mobile phones. And they all have Bluetooth enabled. And what his device does is try to crack into every device that he walks by. Now what is he going to do when he cracks into the device? What is he going to do when he manages to pair with that device using the 1234 code or whatever it is that's necessary to get into the device? All he wants to do is make a phone call. Just like you could with your headset. And what is he calling?

Well he's calling the UK equivalent of a 900 number that he happens to control. Which means that if you're walking through Heathrow Airport and he manages to knock your phone and it's sitting in your pocket, you can walk around for 10, 15, 20 minutes at $4 a minute calling some sort of 900 number equivalent, that's putting money into his bank account. And yes of course there are charge backs but not enough to actually keep him from doing this. That's the kind of targeting that I've seen so far. But I'm also seeing just general malware and viruses that are spreading through these devices. I see more of it in Asia than I do in Europe. I see more of it in Europe than I do in the US. But just because it's there does not mean that it's not going to be here very, very soon.

So what's the obvious answer if we have this problem with malware with things like viruses is going to have anti-malware protection. Well. the equally obvious problem is that every single device has a different operating system. So if you've got Palms and Windows Mobile and Blackberry's and Nokia's and iPhones and Androids next week then now you've got to have anti-malware for all these different platforms. That turns out to be a major nightmare for you. But anti-malware is actually not sufficient, that's just one piece of the big puzzle. Now we need to turn back to that policy and say we want to put anti-malware on your device, if we can find anti-malware for your device, which could be an issue. But there are other things you might want to stick in your policy that might help reduce exposure to malware in the first place. For example, turn off Bluetooth if you're not using it, don't make your device advertisable or visible to other devices because there's really no point in it. Don't let your 12 year-olds or 13 year-olds or 14 year-olds use that phone because they want to play the games and do the download and get the ringtones and whatever, which are going to be vectors for malware to get onto the device. Don't open attachments in email that you're not absolutely expecting from your company and don't make sense. It's the same rule for the desktop, doubly the rule for the device. Don't be downloading all kinds of tools and software onto your device, because that's a good way to get trapped into this malware pit. Now, if you only do one thing for policy, if there's only one piece of advice that you give people for malware protection it would be turn off Bluetooth. Bluetooth is the biggest unmitigated risk that we have on these mobile devices today, and that will only get worse. So yes, you need anti-malware protection, if you can find it. But in addition tell people to shut off Bluetooth. Their email is probably going through your corporate filter so that's probably got some anti-virus on it. Hopefully their 12 year old is not using the device. Bluetooth is the biggest threat.

Now if you want to go all out, you can get some device management software which will help enforce some of this policy and help manage the anti-malware. There are a whole bunch of different functions that I've listed here that are built into various device management tools. Now depending on how your company works, whether you have a single contract with a carrier, some of this can actually be outsourced. In effect the carriers have already bought this software and they will help you control end user devices. In other cases, things like Windows Mobile, you'll do something through your exchange server. Stuff like a Windows exchange active sync will let you do a device wipe, a real commonly requested feature, device lock, device unlock are commonly requested features. So in addition to anti-malware software you also want to make sure you mitigate the Bluetooth risk and if possible get some of this device management software to enforce that policy. And of course the problem with the device management software is that now again we have five devices with five different operating systems and as far as I know there is no single vendor that gives you five out of five. So if you decide that you're going to go the device management system software or the anti-malware, again, you're going to find it difficult to be completely cross platform. You're going to have to zero in on a small set of supported platforms. But that's going to be an organizational cost, an unfortunate one, that comes out of having secure mobility.

All right. Last piece of the mobility security puzzle, last strategy is authentication on the device. Here are some statistics that I got off of some very unreliable web page during 2005 in Chicago taxis 80,000 some cell phones were left in backseats. 20,000 some PDA's were left. Thousands of laptops were left. And even one baby. I want to talk about everything but the baby. Authentication is a basic requirement for any mobility security program. You cannot let users simply open up the phone, turn it on and not have to provide some kind of authentication because of the Chicago taxi statistics. Because otherwise the device will be sitting there ready for someone to grab the information and possibly the passwords will be unlocked. Now you can do authentication in lots of different ways. You can do it only at the point where the device is powered on. You can require periodic authentication. You can do it at every single invocation of an application. And this authentication concept is often tied into the concept of encryption. Which is to say that sometimes we use the same password to authenticate the user to the device that we're also using to decrypt the data on the device. So sometimes this encryption and authentication thing get all mixed up together. Again, even if you go to my strategy number three and you say, 'You know, Joel, I just can't deal with the encryption thing, you're full of crap, I just can't do it', at least go for the authentication piece. I made it number five but that does not make it the least important.

Now how you decide to do authentication I think you want to do based on two key factors. One is compliance and the second is risk. Obviously if users will not comply, if you have non-compliant patients, if they do not take their medicine, if they disable these features, if somehow you can't keep them from disabling these features, then you've got a problem. So you have to come up with something that is reasonable for users to put up with. Is that going to mean that every 15 minutes they type in a nine character password? No. Probably they won't put up with that. Will they put up with a four character password every time they power on the device? Sure. They'd better or else they don't deserve to have any corporate data on their device. Something in between probably better. Now you don't need to have the same policy for all users. And this is where we get into that risk side. If you have an end user who is only getting email and contact syncing, while that email could be very, very valuable, that's not necessarily as important as someone who also has an application which syncs to the CRM database or pulls down all of IT's passwords for the week, or the door codes for every branch of every ATM or remote bank that you're managing or whatever. That's a different level of device importance. If users are having less risk because the information is less valuable, then you can give them lower levels of authentication requirement. For someone that has very, very important data on their device, they have a corresponding responsibility to protect that and they're going to have to put up with more intrusive and annoying authentication then they might have otherwise.

All right. Let me just sum up here. I think that I don't have the ultimate answer for mobility security. But I think that if you take these five steps you will probably get yourself way, way up into the power curve of protecting your organization and your organizations data. And the first step is to have a policy. You have to have a policy that says everything from how we pick devices to how we recycle devices to how we use them. And you have to have user buy in to the use part of that policy. Where possible you can actually support that policy with technology. Number two you have to encrypt all data going over any network. The cell network, the WiFi network, the Bluetooth network, if you could control it, which you can't. Which means that because we can't control cellular encryption because we don't trust it we have to do either application layer or VPN client IP layer security. One of the two. I don't care which, there is no right answer. But make absolutely sure that as you're thinking about this and you think about device capabilities you are aware that you need to have one of those two. The third, most controversial, the biggest pain in the butt for this strategy, encrypting data on the device. You will probably have to get a third party piece of software to do that because device manufacturers don't care about you yet. They will, but not yet, not today. It's a pain, it's difficult, some devices don't support it, some devices don't even have a concept of encryption on the device, so you may have difficulty with this strategy. If you have device which is very sort of Windows-esque, like a Windows mobile device, encryption is very second nature to that kind of device. But like a Palm where you really don't know what the heck is going on, then you're going to find it difficult to get good encryption. Again, you may have to go to a third party to do it. Fourth, malware is going to be an issue. You have to have malware protection. Malware protection starts with that basic anti-virus, anti-malware kind of software that you have probably already bought and probably have a license for for your desktops and your laptops. You might be able to use a different product from the same vendor on your mobile devices but can also include other threats. Try to not just focus on the keeping the viruses off with anti-virus but keeping them off with good practices. Like shutting off your Bluetooth, the biggest threat we've got on devices today. And last, but definitely not least, make sure you require authentication. If possible, link authentication to encryption. So that same password unlocks the device and is used to decrypt the data on the device. That's the best option if you can do it. But in any case absolutely require encryption and if find a device that doesn't let you do that, that doesn't let you require authentication, that's probably not a good candidate for an enterprise device.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy