Computerworld - Over the past seven months, I have led a team of IT representatives in making sure that all mobile devices are aligned with our new security policy. I thought this was going to be straightforward -- a few mouse clicks to check off some boxes, and our policy would be in effect on our entire inventory of mobile devices.
But because months have gone by since our previous CIO (more on that later) signed off on our security policy, you can probably guess that things weren't as easy as I expected.
At issue: It has taken months to implement a new security policy for mobile devices, and meanwhile a new CIO has arrived.
Action plan: Start by helping the new CIO understand the value of passwords.
The policy is pretty simple. It states that all mobile devices that are used to connect directly to our network or that otherwise synchronize data with the network must have four-digit passwords, must time out after 30 minutes of inactivity, must wipe themselves of all data after 10 unsuccessful log-on attempts, and must be capable of being controlled by our IT department and of being remotely wiped if lost or stolen.
The first problem is variety: We use something like 25 or 30 different kinds of phones worldwide. While most of them are BlackBerries, iPhones or Windows smartphones, there are plenty of variations. Nokia, Samsung, Motorola, LG, HTC and PCD are just some of the vendors we use. That diversity makes it pretty much impossible to fully test every phone with every operating system.
On the other hand, there are only two methods by which mobile phones can connect to our internal network: one for BlackBerries, and one for every other device. The latter uses Microsoft ActiveSync. One of the major differences is that ActiveSync passwords can't be reset. If a user forgets his password, he must wipe the device to the factory default setting. Ouch! That was a factor in one notable complication we encountered as we began testing some widely used devices.
Nokia phones that some employees were using in Singapore had come preconfigured with default passwords. The passwords weren't activated but were nonetheless bound to the devices. When we pushed the ActiveSync policy to those phones, they locked, and the users thought that they were supposed to create new passwords. Many of them ended up trying to input a password 10 times; guess what happened.
After many trials and tribulations during our limited tests (the Nokia situation is only one example), I suddenly found myself back at square one. That's because our previous CIO had procrastinated on approving an executive communication authorizing us to deploy the mobile device policy to a handful of BlackBerry-using executives before undertaking a global rollout. (We've had no problems with BlackBerries.) He probably didn't care to get involved in the issue because he knew he would be leaving soon.
When I approached our new CIO, he began to question me on the need for passwords for mobile phones. He wasn't reacting to our deployment woes; he simply didn't see the need for such a policy. I had to explain about the risks involved should an unprotected BlackBerry phone fall into the wrong hands.
To underscore the potential for theft of intellectual property, I used my BlackBerry to browse to an unprotected, internal Web site that is loaded with sensitive materials that it is my job to protect. Without passwords, I said, a competitor who came into possession of one of our BlackBerry phones would have unimpeded access to all such sites and the information that they contain.
Sometimes a security manager just has to conjure up some scary scenarios to make a point. I'm pretty sure he got it, but I'll know for sure in a week or so when I pester him again to approve the executive communication.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
To join in the discussions about security, go to computerworld.com/blogs/security
Read more about Security in Computerworld's Security Topic Center.
Free Insider GuideCopyright © 1994 - 2012 Computerworld Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Computerworld Inc. is prohibited. Computerworld and Computerworld.com and the respective logos are trademarks of International Data Group Inc.
