While 69 percent of organizations have employees using personal devices to connect to their corporate network, more than one-fifth, or 21 percent, currently have no policy in place to govern the use of personal mobile devices on their network. These new figures, released recently from security-products firm Courion, suggest many security leaders are still ignoring the need to address mobile-device management among their employees.
But according to Chris Silva, Senior Vice President, Research and Service Delivery at security firm IANS, having a mobile device policy in place is the most important step to handling the risk inherent to personal mobile-device use.
"It's not the platform, it's the policy," said Silva. "The whole issue of how secure the device is comes down to what policy is in place. We can't say one device is secure and another is not. It's about who gets to use it and what can they do with it. "
So what goes into a comprehensive mobile security policy? Silva said it includes clear definitions of user-risk profiles, devices that can be supported and where to draw the line on what's allowed, among other considerations. He shared these suggested questions that organizations should consider when crafting their own mobile device security policy.
Which devices will we support?
With so many employees using their own devices, these days Silva recommends organizations move beyond a server that supports just one platform.
"If you have just a Blackberry server, it's time to add something that supports several different platforms," he said. "The one guarantee in mobile is you are going to have at least two or three people will want supported."
But while supporting a variety of platforms may be important, he also suggests drawing a line in the sand and clearly defining what will be allowed and what will not. Too many organizations make the mistake of trying to accommodate any kind of personal device and platform that workers desire to use. This makes the task of supporting them all but impossible for an IT security team.
"They can only do a great job securing a handful of platforms," said Silva. "If you open things up to 57 different types of mobile devices, you can be guaranteed they will be spread so thin the policy won't be robust enough on all of those platforms."
And while some employees may not appreciate being told which type device to use, Silva recommends at least having some minimum standards for age and capabilities.
"Make sure you are dealing with the near-latest and greatest because it will have better security controls," he said. "For example, you may decide iPhone support should drop off for anything made before the iPhone 3Gs. Anything before that doesn't allow device-level encryption."
How will the information be accessed?
Will the information be stored on the device or will it live somewhere else and be accessed remotely? That's an important question to ask for certain organization, depending on how much you are subjected to compliance and reporting mandates, said Silva.
"I've seen a lot of organizations come to us in the legal space and say 'We want to make the whole desktop available on this person's iPad, but we don't want any of that information to live on the device because then it is subject to compliance and reporting.' Those kinds of organizations need to enable mobile devices strictly as a viewing platform, but not an information handling platform. If your risk profile is such that every device that gets information on it is subject to compliance, you probably want to limit that. Taking into account your external liability is critical."
What is the risk profile of the individual using the devices?
Consider a persona-based deployment policy, said Silva. This means allowing different kinds of employees to access varying levels of information from their device.
"When you have four different personas in your organization, one may be high risk and you really don't want them using their device for anything but phone calls and SMS," he explained. "There should be a policy that clearly identifies who these individuals are, what the attributes of those individuals are and what the security controls are that match to those attributes."
Silva said a clear definition of each risk profile makes it easier for a security team to then approach employees and let them know what they can and can't do with their device.
"It takes the subjectivity out of it," he said.
How can we be proactive?
"Waiting until you have 50 people coming to your door asking to use their iPad is going to ensure that your policy is raced to the finish line and probably not as good as it could be," said Silva. "Looking forward at the trends is crucial."
Silva referenced a Christmas two years ago when a much-hyped Android device was approaching market release.
"(Security managers) knew come that the day everyone returned to work after Christmas there were going to be many requests to use Androids. The smart organizations had their ducks in a row and were ready to go so when people showed up with that shiny, new device they got at Christmas. They were ready to go with getting it locked down and in the device management platform."
When should we say no?
Sometimes a secure mobile policy has to include saying no to certain requests. This will be paramount at compliance-heavy organizations, said Silva.
"For example, you can't have a trader executing trades on their own personal device for many reasons. Locking those people out or down to a point is important."
Silva also said more companies are looking to virtualization as a way to enable access to information and applications while keeping the information off of the device.
"If you are in a place where you have to block users because you don't want any information living on their device, virtualization holds a lot of promise," he said. "The ability to have a sandbox where all of your desktop exists, where applications work but can and then pulled away without leaving any information on the device, is going to open up the possibilities for these compliance-heavy industries."
This story, "Mobile Device Security: Questions to Ask for Creating Policy" was originally published by CSO.