Developing a Wireless Security Policy

Again, using the house analogy, before you put the shovel in the ground, a surveyor comes to the property and maps its dimensions. Well, before you start your site survey policy, you need to map your organization's security policy. Develop a security policy that addresses the use of wireless technology, including 802.11, 802.15, 802.16, and 802.20. A security policy is the foundation on which you rationalize and implement other countermeasures the operational and technical ones. A documented security policy allows your organization to define acceptable architecture, implementation, and uses for wireless technologies. It answers the big questions. Do you allow ad hoc mode? Do you allow departments or units to install access points? Do you allow WPAN, WLAN, or WWAN technology? There are many formal statements that you need to make in your policy.

Keep in mind that policies are mandated specifications or operations. They deal with the assessment of risk within your organization. You cannot write effective policy until you understand the risks to your organization and how you intend organizationally to deal with those risks. These policies provide the basis for operations and consequently, the basis of compliance reviews.

Policies are not stagnant; you don't write them in stone. Your internal and external environments are constantly changing as a result, so are the threats and the attendant risks. You should periodically review and update your policy to address technology improvements that may provide practical application for your organization without introducing additional security risks and vulnerabilities. Determine what works and why it works. Determine what doesn't work and why it does not. Make sure that your policy is current by rewriting any dysfunctional or archaic policies. This is a constant and cyclic process as your organization moves forward.

It is important to remember the intended audience when you draft security policy. Don't make the policy too difficult to read or comprehend. It is important to create formal policy to minimize potential confusion and to clear up any ambiguity. Sometimes your policy only formalizes the status quo. Make sure that your policies are relevant. If people don't understand what the policy means to them, they will disregard it. Make your policy succinct but precise.

Every organization has or should have a format or template for policy, so we won't tell you how to write your policy. However, you should consider the following topics:

Purpose:
Tell the audience that the policy applies to wireless networks.

Scope:
The policy may apply only to WLANs, but it may also apply to all wireless technology, so you need to specify the scope. People can read the scope and decide whether their network is in or out of scope and whether the policy applies to them.

Policy:
State the policy very clearly. A good policy document is usually a maximum of three pages long. Generally, you specify the clients' rights and responsibilities and expected actions or behaviors. Many organizations include standards and procedures in their policy, which you should not do. If you are not sure of the difference, you can refer to ISO 17799 (www.iso17799.net), which tells you about the many tiers of documentation.

Enforcement:
You should state what someone can expect in the way of sanctions should they not comply with your policy. Your legal counsel should review this section carefully (well, actually, the whole document).

Exceptions:
Circumstances may arise in which, for one reason or another, someone cannot comply with the policy. You should have a mechanism in place to handle the reporting and approval of any exceptions.

Definitions:
You cannot (and should not) expect every reader of your document to understand all the technical jargon. You should write the policy so the average layperson can understand it. Where jargon is unavoidable, you may need to define some terms.

Document history:
Whether you put it at the beginning or the end is inconsequential, you must include a document history. The reader should have the trail of revisions for the document.

After the powers that be approve the policy, make sure that everyone gets a copy. If need be, make sure that everyone understands the policy. We often see gaps in security programs in which people who have the necessary skills want to do the right thing but don't understand how. Tell them. After you tell them, get them to sign a document saying they read and understood the policy. It is also a worthwhile idea to reaffirm annually that they understand the policy.

Every organization is different, but some typical security policy topics are:

• Use of default SSIDs, encryption keys, and passwords.
• Trust level of base station, bridges, and clients.
• Access control method(s): MAC ACLs, 802.1x, and SSL.
• Method for configuration changes: console ports, TFTP, Telnet, HTTP, and HTTPS.
• Access policies for authorized APs, stations, groups, users, and guests.
• Authentication credentials.
• Authentication method(s): none, shared key, EAP, VPN, and SSL login.
• Encryption technology: 802.11, WEP, WPA, AES, network, transport, and application.
• Required software and settings for AP, authentication servers, and clients (including firewall and antivirus).
• Filtering: MAC, protocol, and watch lists.