Securing mobile devices in the enterprise is a hot button issue in today’s IT security world. Security luminary Joel Snyder, senior partner with Arizona-based consulting firm, Opus One, discusses his five-step mobile device protection plan. His plan includes:
1.) Building a policy (3:18)
2.) Dealing with data in motion (11:55)
3.) Mobile encryption (23:09)
4.) Mobile malware protection (28:21)
5.) Mobile authentication (34:04)
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.