Deploying a wireless LAN without security policy is like piloting an airplane without instruction. You'll probably get off the ground, but what happens next is largely a matter of chance, and someone will very likely get hurt. Many organizations realize that they need a WLAN security policy, but don't know how to go about creating one. In this tip, we'll discuss what WLAN security policies are, the kinds of information they should contain, and where to find policy templates and further guidance.
As defined by
There are many kinds of security policies, including Password Policies, Remote Access Policies, Mobile Device Policies, Vulnerability Assessment Policies, Acceptable Use Policies -- and Wireless Communication Policies. The assets protected by each policy may differ, but all share common goals:
- Define assets, risks and security objectives. How would you know what security measures to
implement if you don't know what you're protecting and why?
- Identify required security practices and measures. You can't deploy every available security
measure -- even if you could, you'd be taking shots in the dark. Policies guide implementation by
establishing steps to manage risk.
- Dictate acceptable behavior and enforcement. People can't follow rules if they don't know what
they are, and a policy without teeth isn't worth the paper it's written on.
- Serve as a vehicle for achieving consensus. Obtaining buy-in from all stakeholders -- including management, administrators, and end users -- is essential to successful policy deployment.
There may be relationships between security policies. For example, wireless may be used for both internal and remote network access, with password authentication. New policies are best designed as an extension to existing policies, to reduce duplicated effort and conflicting rules. When creating a WLAN security policy, reusing relevant parts of your wired network and system security policies can help you achieve consistent protection. WLANs may pose unique security risks and require some different measures, but don't needlessly reinvent the wheel.
Every security policy should strive to strike a good balance between being specific and implementable, yet concise and easy to understand. Lengthy policies filled with terms understood by just a few security experts won't be effective, but neither will brief pamphlets that simply say "make sure the [ network | host | router | data ] is secure."
What exactly should your WLAN security policy include? Unfortunately, there's no one-size-fits-all policy. Your policy must identify your organization's assets, quantify your organization's risks, and your organization's consensus on methods to mitigate those risks in accordance with your priorities. But we can identify some topics that are commonly covered by WLAN security policies:
- Objective: What is the policy intended to achieve (or prevent)?
For example, identify the company, organizational unit, network, and type of communication that requires security as dictated by this policy.
- Ownership and authority: Who created, approved, and will enforce this policy?
For example, identify the policy development team, the executive(s) who approved it, and the emergency response team responsible for handling violations.
- Scope: Who will be required to comply with this policy, and where?
For example, identify the groups, users, and wireless devices that must adhere to this policy when accessing a defined set of assets over wireless. Does the policy apply only to employees, to contractors, to visitors? Does it apply when using wireless to access your Intranet, the Internet, or an Extranet?
- Risk assessment: What assets are at risk, to what threats, with what impact?
For example, identify wireless laptops, PDA, and APs, data sent over wireless, and WLAN-facing wired network resources (firewalls, DHCP/DNS servers). What kinds of attacks do they face, and what would the impact be on your business should those resources be lost, damaged, or disclosed? Determining the most-likely and most-costly attacks will help you spend time and budget wisely.
- Security measures: Which security practices and measures will you use?
For example, identify an authentication policy to guide how WLAN credentials (e.g., WEP keys, WPA PSKs, tokens or certificates or passwords used with 802.1X or VPN) will be assigned, distributed, reset, and revoked. Establish minimum requirements for length, complexity, update, and storage; and minimum strengths for authentication protocols and algorithms. Consider not only authentication, but also access control, authorization, confidentiality, integrity, and availability for all at-risk assets (e.g., stations, APs, servers, data).
- Acceptable usage: What must users do to comply with this policy?
For example, identify where users should obtain required WLAN security software and configuration assistance. Once security measures are installed, what best practices are users required to follow, and what behavior is precluded by this policy? User responsibilities should be clearly defined in simple terms.
- Deployment process: How will this policy be implemented, tested, and taught?
For example, describe a plan for staging a trial WLAN, verifying that the recommended measures actually address identified risks, training WLAN administrators, and educating end users. Include a process for reviewing and refining your policy, both during initial testing and periodically thereafter.
- Auditing and enforcement: How will you monitor and ensure policy compliance?
For example, it's not enough to install a wireless IDS to spot rogue APs -- your policy should define a process for rogue blocking, investigation, and permanent resolution, based upon a routinely-maintained authorized AP inventory. If an employee installs a rogue, what are the consequences? Will compliance auditing be conducted internally or by a third party? Are you subject to audit regulations?
This list certainly isn't exhaustive; you'll find security policies that include more -- and less. But it's a starting point to get you thinking about what to include in your own WLAN security policy.
Examples and templates
You can also kick-start your own WLAN security policy by looking at policies created by other organizations, like:
- US DOD Use of Commercial Wireless Devices, Services, and Technologies Directive
- US DOC Unclassified System Remote Access Security Policy
- TechRepublic Sample PDA Support Policy
and working from published policy templates, such as:
- CWNP WLAN Security Policy Template
- TechRepublic Wireless Policy Template
- SANS Wireless Communication Policy Template
- SANS Acceptable Use Policy Template
- SANS Remote Access Policy Template
Some of these focus on WLANs, others on wireless communication in general, and still others on related policies for mobile devices and remote access. Examples and templates like these can be a handy springboard, but don't get stuck on format -- just create a security policy that makes sense for your organization. Remember to look inside your company for existing policies, and consult those responsible for them to find out what works well and what they might do differently if starting over again.
For more information
To learn more about security policy development in general, consult these resources:
SANS Security Policy Page
SecurityFocus Wireless Network Policy Development (Part 1)
SecurityFocus Wireless Network Policy Development (Part 2)
IETF RFC 2196: Site Security Handbook
Australian CERT Site Security Policy Development
WindowsSecurity How to develop a Network Security Policy
|Read about Lisa|
About the author: Lisa Phifer is vice president of Core Competence Inc., a consulting firm
specializing in network security and management technology. Phifer has been involved in the design,
implementation, and evaluation of data communications, internetworking, security, and network
management products for nearly 20 years. She teaches about wireless LANs and virtual private
networking at industry conferences and has written extensively about network infrastructure and
security technologies for numerous publications. She is also a site expert to
SearchMobileComputing.com and SearchNetworking.com.
This was first published in May 2005