Mobile security policies

Mobile security policies are necessary for a safe mobile environment. In this series you'll discover three key elements that are essential to your mobile security policy and learn how government regulations affect what is required in your policy.

This Content Component encountered an error
This Content Component encountered an error

Mobile security policies are necessary for a safe mobile environment. In this series you'll discover three key elements that are essential to your mobile security policy and learn how government regulations affect what is required in your policy.

In this series:

  Why a policy is important
  Defining your mobile security policy
  Government regulations

Why a policy is important

Security, unfortunately, is one area where IT professionals are never "done." I work on plans for network installations and upgrades all the time, and we eventually wind up with a list of required equipment, a cutover/migration plan, an operational plan and similar documents covering user training, help desk and other support, and on and on. And, of course, a security plan is always part of the process. But whereas almost all of the installed elements can at some point be declared to be operational and finished for a particular cycle (subject to occasional updates, bug fixes and revisions), security is so critical a component that, in all but the smallest organizations, it requires near-continuous attention. Come to think of it, even small companies should have a good security plan and set of procedures in place, with regular reviews, even if nothing seems to be amiss. As I said, this is the one area where you are never done.

I occasionally give talks on information security, and I love to ask the audience how many of them have never been hit by a security breach or other security-related problem. They almost all raise their hands, and then I lower the boom -- how do they know?

The fact is that information and network security are usually compromised without anyone knowing, at least right away, that anything has occurred, and -- compounding the problem -- there is often no process or set of procedures in place to deal with the problem once it is identified. Knowing security has been compromised is one thing; not knowing what to do about this situation is perhaps even worse. And when sensitive information is in mobile devices that could literally be anywhere -- including lost -- the value of up-front planning becomes very clear indeed.

Everyone will agree that information and network security are important, but the biggest push-backs I get when talking about security relate to two factors: cost and convenience. It is possible to spend vast sums on security, and this is often justified -- as with government and military networks -- but the commercial world has two specific security threats, and one of them is usually minor: the casual hacker. These folks have way too much time on their hands, and this is manifested in the need to cause mischief or obtain bragging rights among the like-minded, or simply in a pathological need for Internet access. But though the casual hacker seldom causes a major meltdown -- and indeed, helps to keep a focus on the need for security in the first place -- the other threat, the professional information thief, is and must always be a major concern.

Driven by profit, these nefarious individuals have detailed technical knowledge of networks and understand and often develop the techniques for cracking nets with a high degree of effectiveness and stealth. Information is often long-gone before their tracks -- if any -- are discovered. But let's be fair: What are the chances of getting hit by one of these guys? Should those vast sums be spent simply in anticipation of an attack that may never come? And with that expense comes the second push-back -- inconvenience. There is little doubt that security measures can and often do affect productivity and create additional support costs. Security solutions that are hard to use are often counterproductive -- users just write down difficult-to-remember passwords or otherwise leave mobile devices unlocked. All that expense can indeed be wasted in such situations.

But, based on the theory that if you don't know where you're going, any road will take you there, it is best -- despite the obvious urgency and criticality involved (to say nothing of increasingly strict regulatory requirements) -- to take a deep breath and start with a plan to tackle your particular security challenge. And this plan begins not with a purchase but with a document -- the development of an enterprise security policy. We'll cover the contents of a security policy in the next section.

Defining your mobile security policy

A security policy is a document that defines how a given enterprise approaches the security of its IT resources. The scope here can be very broad indeed -- physical security, network security, information security, and (especially important for our purposes here) mobile device security. It's very important that a security policy be in place before any decisions are made as to specific solutions -- while basic security measures should always, of course, be operational, too often major and otherwise expensive upgrades are made before a real need for them has been established. A security policy therefore serves as a vital focal point for any enterprise or organization.

In general, a security policy defines what information is to be treated as sensitive (and therefore protected), who should have access to this information and under what conditions, and -- very importantly -- what to do when security is compromised (or even suspected of being compromised). From a physical security perspective, it should define who may have access to IT-specific areas of a given installation or building and how these areas are to be secured. But the following three elements are most important with respect to mobile security:

  • Information security -- this defines what information should be treated as sensitive. I generally recommend adopting an approach similar to that used by the government, which is to have multiple levels of security with fewer people or groups having access as the classification level rises. For example, we might use a legend of "Company Confidential" for any data that is restricted to employees, and "Company Most Confidential" for that restricted to only certain employees. This policy might also restrict access to certain applications to authorized users only.

  • Network security -- there are two key elements to the solution here, strong authentication and the encryption of sensitive data wherever it is stored. Note again that while a security policy will not usually define the actual solution in any given case, it will mention, for example, that two-factor and/or mutual authentication is required and that a VPN must be used when accessing the enterprise network remotely. It might even restrict the choice of a specific network to certain approved carriers.

  • Device security -- Finally, this part of the policy defines how security is maintained on mobile devices outside the perimeter and otherwise outside the protection of the physical enterprise. It might restrict the ability of a user to install an application on the device, for example, and it might specify that mobile devices are to be backed up or virus-checked or that a particular firewall configuration might be required. I think that eventually so much will be required of mobile devices that they will simply need to be provided by the enterprise. There's no effective way to manage security -- or anything else, for that matter -- on a device that the company does not own.

Each of these areas can be affected by some kind of security breach, and the security policy defines what to do when a potential (or realized) security problem occurs. For example, a lost handset might involve little more than a phone call to the team that will remotely "zap" (erase) any sensitive data on the unit, while unusual network activity might involve shutting off remote access and waking an emergency response team.

Critical to the success of any security policy is the building of a culture of security within the organization. As with those "Loose Lips Sink Ships" posters from World War II, everyone entrusted with confidential information must always be conscious of the need to protect it. The stakes today are higher than ever (and I'll expand on this next time), so every effective policy must be backed up with an awareness campaign that includes training in both the policy and tools needed to implement and enforce it. And, again, while those tools are not necessarily defined in the policy, solutions must be convenient to use and simple enough that support costs will be limited.

Finally, keep in mind that a security policy isn't all you'll need -- the security policy will need to mesh with an acceptable-use policy and perhaps also with business continuity (integrity and availability) plans as well.

Government regulations

We'll start this section with the final major influence on an enterprise security policy -- the impact of governmental and industry-specific regulations. I want to provide a little additional motivation to create and maintain your security policy -- and regulation across all major industries most certainly serves that purpose. Major, widely publicized security breaches have in recent years provided significant incentive to both the regulatory community and major corporations to upgrade their security postures. Dealing with a failure in IT security can have costs far beyond the obvious need for security policy and technology improvements -- the loss in customer and shareholder confidence, legal expenses, erosion of goodwill and reputation, and just the sheer volume of time that management teams must devote to damage control are major drains on market stature, competitive position and, of course, the bottom line. All of this makes getting one's security policy (and implementation) right the first time of critical importance.

The regulatory environment has become much less tolerant of IT security failures over the past few years. Here are just three examples:

  • Sarbanes-Oxley (SOX) -- SOX was passed during the era of the Enron and WorldCom scandals, primarily to address public-company accountability and openness. Interestingly, SOX does not address the issue of IT security directly, but various sections of the Act do contain wording that has been broadly interpreted to mean that organizations which do not take appropriate steps to protect sensitive information may face significant legal woes.
  • PCI -- The Payment Card Industry has set up its own standard and a set of procedures (including a detailed self-assessment) for its members. Credit-card data has been the source of a good deal of trouble for retailers in recent years, with a number of notable thefts of cardholder information. Anyone involved in retail needs to be familiar with this set of standards and guidelines; more information can be found here: https://www.pcisecuritystandards.org/.
  • HIPAA -- The Health Insurance Portability and Accountability Act (HIPAA) of 1996 is designed to provide individuals with a high degree of privacy with respect to their healthcare records. IT security is of paramount importance here, and the penalties for compromised security can be severe.

But even if your business is not directly subject to these or similar security regulations, it's not a bad idea to conduct your business -- and set your security policy -- as if it were. The key, again, is deciding which information is sensitive, who should have access to it and under what circumstances, and what to do if this information is compromised for any reason -- the core elements of any good security policy.

And once the policy is in place, most functional security solutions will consist of establishing procedures and tools for authenticating users of devices, networks and applications; authorization to use specific services; accounting to keep track of access and what was done; establishing wireless (airlink) security and network (VPN) security; and the encryption of sensitive data wherever it is stored -- even on mobile devices. Strong authentication, ideally two-factor and mutual, is the best solution, and authentication deserves special attention regardless. And no matter which tools you select, be sure to review your security policy at least every six months. Unfortunately, constant awareness is essential in IT security -- this is one area of IT where no one is ever "done."

Finally, you'll note here that we focused in this series on the policies and, to some degree, the techniques of mobile information and network security, but I must confess we left out what might be the most important of all the pieces of the security puzzle: building a culture of security. And this element is so vital that we'll be devoting a series of columns to the topic in a couple of months. Stay tuned!

Craig Mathias
About the author: Craig Mathias is a principal with Farpoint Group, an advisory firm, based in Ashland, Mass., specializing in wireless networking and mobile computing. The firm works with manufacturers, enterprises, carriers, government, and the financial community on all aspects of wireless and mobile. He can be reached at craig@farpointgroup.com.
This was first published in May 2008

Dig deeper on Mobile policy and enforcement for consumerization

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchEnterpriseDesktop

SearchVirtualDesktop

SearchVMware

SearchCIO

SearchSecurity

Close