Creating a wireless security policy

Purpose

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.

Content

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:

1. 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.

2. 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.

3. 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?

4. 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.

5. 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).

6. 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.

7. 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.

8. 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

• 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

Read about Lisa