Chapter 15 Wireless Security Policies

IN THIS CHAPTER, YOU WILL LEARN ABOUT THE FOLLOWING:

✓ General policy

• Policy creation

• Policy management

✓ Functional policy

• Password policy

• RBAC policy

• Change control policy

• Authentication and encryption policy

• WLAN monitoring policy

• Endpoint policy

• Acceptable use policy

• Physical security policy

• Remote office policy

✓ Government and industry regulations

• Department of Defense (DoD) Directive 8420.1

• Federal Information Processing Standards (FIPS 140-2)

• Sarbanes Oxley (SOX)

• Graham-Leach-Bliley Act (GLBA)

• Health Insurance Portability and Accountability Act (HIPAA)

• Payment Card Industry (PCI) Standard

• Compliance reports

✓ 802.11 WLAN Policy Recommendations

In the previous chapters of this book, you learned about many of the major components that are required for strong WLAN security. Segmentation, data privacy, AAA, and monitoring can all be accomplished with the technology solutions that were discussed. Another component is still needed to provide the foundation for a fortified WLAN solution. This additional item, and perhaps most important component, is policy. All companies should have a written WLAN security policy just as they should have a written wired network security policy. All of the technical WLAN security solutions you have learned about in this book are worthless unless proper WLAN security policies are documented and enforced. WLAN security policies can be as diverse as the variety of 802.11 wireless deployments they cover. Each organization or person deploying wireless devices must use their own set of criteria and evaluation methods in reaching what they believe to be their level of acceptable risk. WLAN security that may be safe enough in a small office/home office (SOHO) environment may not be safe enough in an enterprise environment. Likewise, WLAN security that may be secure enough in an enterprise environment could be viewed as overkill as well as an undesirable expense in a SOHO environment.

In addition to an organization’s budget and internal acceptable use policies, governmental and industry regulations greatly influence security models in wireless networking. A corporate WLAN may be secure but could still fall out of compliance with an external government or industry regulation with which they must comply. WLAN policy makers must often strike a balance between productivity, budget, and security. Very often, mandated security policies hinder normal business operations. Even more common is the possibility that allowing business operations to flow without proper security can put company assets at risk. A well-crafted security policy must take into account business functions and security as well as any external regulations. Finding the proper balance is a key part of any security policy development.

After the policy is created to meet all of the business and regulatory requirements, the policy must be enforced to be effective. The policy must be enforceable and adaptable as requirements change. All WLAN policies must have the full backing of management if employees are to be expected to abide by policy. Management and employees alike must be properly trained so that all security policies are understood. The best written policy that is neither followed nor enforced is truly worthless. All policies must also be flexible and adaptable if the intended use of the WLAN changes and as WLAN technology progresses. With the introduction of the Internet of Things (IoT) and bring your own device (BYOD), having an inclusive yet flexible security policy has never been so important. This chapter will explore some of the fundamental aspects of a wireless security policy that are needed to cement the foundation of good Wi-Fi security.

General Policy

When establishing a wireless security policy, you must first define a general policy. A general wireless security policy establishes why a wireless security policy is needed for an organization. Even if a company has no plans for deploying a wireless network, there should be, at minimum, a policy for dealing with rogue wireless devices. A general wireless security policy will define the following items:

Statement of Authority Defines who put the WLAN policy in place and the executive management that backs the policy

Applicable Audience Defines the audience to whom the policy applies, such as employees, visitors, and contractors

Risk Assessment and Threat Analysis Defines the potential wireless security risks and threats and what the financial impact will be on the company if a successful attack occurs

Security Auditing Defines internal auditing procedures as well as the need for independent outside audits

Violation Reporting Procedures Defines how the WLAN security policy will be enforced, including what actions should be taken and who is in charge of enforcement

Increasingly, organizations of all sizes and types have started amending their network usage policies to include a wireless policy section. If you have not done so already, a WLAN section should be added to your organization’s security policy. Two good resources for learning about best practices and computer security policies are the SANS Institute and the National Institute of Standards and Technology (NIST).

General security policies covering networking are not directly focused on any one area of technology. For this reason, you will find that general security policies tend to encompass vast portions of networking if not all of it. These policies are the larger framework from which other more specific policies are formed. In this section, we will explore policy creation and policy management, as well as internal and external policy influences.

Policy Creation

Policy creation involves decisions that can impact business as a whole in both positive and negative ways. The creation of network security policy should be part of the overall network design. However, security and its related policies are often afterthoughts that develop once it is too late. WLAN security, such as a WIPS monitoring solution, is often deployed in response to a breach in WLAN security. Likewise, security policies are often applied after the WLAN has been deployed in response to an industry concern. Creating documented security policies in advance during the design phase of a WLAN is a much better strategy. If the security team is the sole developer of a security policy, management and other departments may not want to subscribe to the defined policies. If the policies are not relevant or are too restrictive, they are likely to be ignored or impede business. Therefore, the first task in policy development must be to assemble a committee that will begin the construction of a relevant and usable policy. This group should include representatives from each group of stakeholders within the organization. The stakeholders are part of the applicable audience that should be involved in creating the policies to which they must abide. Everyone must endorse the security policy for it to be effective. Having such an endorsement requires an executive-level champion. Often a “C”-level executive is needed to get the ball rolling. The CEO, CIO, CTO, or CSO usually champions the cause so that the policy has the energy to move forward. Here are some of the departments that should be represented in policy creation:

• Security

• Legal

• Human Resources

• Management

• Networking

• Desktop Support

• Finance

• Users

• Research and Development

• Any group using the technology covered by the policy

Once the policy creation team is assembled, the next step is to define the scope of the policy. It is important to determine and specify whether you are creating a general policy or a functional policy. Whereas a general policy establishes a framework for enforcement, a functional policy defines technical aspects of security. WLAN functional policies will be discussed in greater detail later in this chapter.

When building a general policy, you should look for existing written policies first and attempt to see if they are applicable and determine if they are being followed and enforced. If there is a written policy, you may only need to adapt it to current business and security needs or just ensure it is being adhered to and enforced. If there is no written policy, you will need to start from scratch, which, in some instances, may be an easier task than adjusting an existing policy. The WLAN may also fall under an industry or governmental network security regulation that does not apply to the wired infrastructure. When building a WLAN security policy, you should determine if any external influences such as governmental regulations or industry standards exist that would impact your decision making. Internal and external influences should also be considered when modifying an existing policy. Several government and industry regulations will also be discussed in greater detail later in this chapter. Defining the applicable audience that must abide by this policy is critical. Obviously, all employees will have to abide by policy, but contractors and temporary workers are often overlooked.

With the policy development team assembled and the scope of the policy defined, you are ready to start building and documenting your policy. A large part of general policy creation is risk assessment. Risk assessment involves determining what assets are at risk, as well as the value of the assets that need protection. Often the value of the asset being protected will determine the security measures that are needed. Assets such as corporate trade secrets and credit card databases require the strongest security available. Threat analysis is also a form of risk assessment. Determining in advance what potential WLAN security threats exist will help determine the risk due to a successful WLAN attack occurring. For example, how much would it cost the company if an intruder used a rogue AP to access the customer credit card database? What would the potential legal liability be to the company if employee healthcare records were illegally accessed? What would it cost the company if a denial-of-service attack prevented the sales team from accessing email for four hours? If a specific dollar value can be assigned to these types of potential threats, better decisions can be made when choosing the proper WLAN security solution, and better policies can be written. Furthermore, if threat analysis and risk assessment can be used to determine financial impact, it will be easier to convince management to budget for needed security solutions. Having an external audit team look for vulnerabilities in your deployment and or make recommendations about your policy based on their findings or experience can improve the finished policy immensely. Even more importantly, management is more likely to endorse the enforcement of policy if they have a better understanding of the risks and are aware of the potential financial impact of a breach in security.

The final phase of policy deployment is policy communication. This involves making sure that all of the users are aware of the policies, understand them, and realize they must comply with them. This goal can be reached using several methods. Documentation of the policy must exist to eliminate confusion and to provide reference should points of clarity be required. Users need to be trained to understand and abide by security policies. This is one of the reasons why user representation in policy creation is so important. If the users are not trained on policy conformity or do not buy into the policy, it will not be followed. A formal training class regarding policy is usually necessary and highly recommended. After training, users must be required to read the corporate security policy and sign a document stating that they have read and understand it as well as agreeing to comply with the written policy.

Many organizations make the mistake of creating policy documents that are too technical, hard to read, and hard to understand. The policy document should be written in a straightforward manner that all employees can comprehend without any unneeded technical jargon. Another mistake often made within an organization is that employees read the security policy document, sign the document, and never see it again. The policy document will often change based on changes in business needs, user requirements, industry or governmental influence, or changes in technology; therefore, it should be thought of as a living and breathing document. Many companies store the security policy document on a public share on a corporate server and then provide a link to the document for employee access when the document changes, or on a scheduled basis when the employees are required to read and agree to the policy as part of the security plan. Such a link allows the employees to read and reference the security document whenever necessary. The lengths you go to in policy communication may vary by user, department, or organization. The key aspects of building an effective policy are that the policy should be relevant, include both internal and external requirements, and be properly documented and well communicated.

Policy Management

The management of any security policy is a crucial part of an effective security solution. Policy management includes policy adaptation as well as compliance monitoring, security audits, and policy enforcement. A policy that is not enforced is not effective. Policies are also not effective when they become obsolete. As mentioned earlier, the policy document needs to be a living document that is adaptable to new business requirements and advances in technology. With the rapid growth and acceptance of BYOD, having a flexible and adaptable WLAN security policy has become extremely important. Knowing the requirements and monitoring for compliance allows security staff members to identify devices or communications that fall outside the policy. When such situations are located, they can be corrected—hopefully before a security incidence occurs. Should new technology be incorporated into your network, the general policy may cover it. However, functional policy for the newer technology may not exist and may need to be created prior to allowing such new things on your network. By monitoring policy, holes such as these can be identified, documented, and included in the next revision of the policy, or they may prompt a specific policy to be created for its use. As new threats arise, a policy can be augmented to address the threats. It is important to realize that both internal and external changes can drive the need to update the security policy.

Many organizations have a specific monetary value defined for every minute of downtime faced by the network. Downtime can be caused by hardware failure, improper configuration, firmware issues, software glitches, or security problems. Striving for 99.999 percent uptime is very common. Unmanaged security policies, or those that are too restrictive due to failure to adapt to business requirements, can cause downtime. Those that fail to comply with external requirements, industry or governmental, could result in networks being shut down until compliance is reached. This could also result in fines or a loss of assets due to noncompliance. As external mandates change, the network security policy must also change. The loss of money or time due to noncompliance is, essentially, a loss of corporate assets, although not via an attack but rather through not being vigilant in regard to changes in the industry, regulations, or technology. Policy management involves monitoring for compliance, both internal and external.

Policy management may also include security audits and penetration testing. In Chapter 13, “Wireless LAN Security Auditing,” you learned about many of the tools and procedures needed to perform a successful audit. Penetration testing and audits will assist the security staff in determining compliance with corporate policy, as well as finding oversights in the policies, or identifying areas for improvements based on newer technologies or methods. Before conducting a security audit, or penetration test, consult the written policies to help ensure that your actions are covered within corporate guidelines. Internal corporate audits should be conducted on a regular basis. Consideration should be given to hiring a third-party to perform penetration tests and audits. Third-party audits often reveal security flaws that were missed by the organization.

Policy management also includes the area of enforcement. As mentioned earlier, if policies are not enforced, they become meaningless. Your general policy should outline procedures to be taken if there are policy violations. Actions taken after a policy violation usually depend on the value of what was lost or compromised. An employee who violates security policy at a nuclear power plant will probably get fired, whereas an employee who violates policy at a retail store might just be retrained. Policy enforcement and reporting of violations are often hampered by the following:

• Lack of corporate standards and documentation

• Ineffective or missing management support

• Non-uniform enforcement

• No client-side enforcement

• Lack of education about risks

• Regulation compliance

• Deployment management

• Cost (this is a big one)

All policy violations and subsequent actions must be accurately documented to meet compliance with many government regulations. Documenting any violations will also help to identify where things can be improved. Was the violation caused by ignorance, attack, or changes in business practices or technologies that went unnoticed? Knowing why the problem occurred can help prevent future occurrences of the same problem or by the same person. Documentation of policy violations is also important for liability reasons and may even be needed in case human resources or law enforcement gets involved.

Functional Policy

General policies are the framework from which functional policies are derived. A functional policy is required to define the technical aspects of wireless security. The functional security policy establishes how to implement and secure the wireless network, defining what solutions and actions are needed. A functional wireless security policy will at a minimum define the following items:

Policy Essentials Defines basic security procedures such as password policies, training, and proper use of the wireless network

Baseline Practices Defines minimum wireless security practices such as configuration checklists, staging and testing procedures, and so on

Design and Implementation Defines the actual authentication, encryption, and segmentation solutions that are to be put in place

Monitoring and Response Defines all wireless intrusion detection procedures and the appropriate responses to alarms

Password Policy

Functional policies should include a password policy. This policy should state the length, complexity, and age limits of passwords used in authentication, in addition to simply requiring a password. Where possible, systems should be configured to enforce the password policies and not allow users to authenticate with weak or noncompliant passwords. Users should also be forced to change their password upon first login. This prevents administrators from knowing the users’ password beyond the initial account creation. The complexity and length of the password is derived from a delicate balance of difficulty to guess (or brute force the password), and ease of remembrance. If the password is too simple or too short, it is easily guessed or cracked. If it is too long or too complex, users may forget them or write them down near their work area. This could allow someone to easily find the password and use it to gain access to network resources beyond their approved access. Additional authentication measures may also be required beyond passwords to improve security, such as multifactor security measures. These measures take into account usernames and passwords (what you know), token devices or client certificates (what you have), biometrics (who you are), and RFID tags (where you are). Some of these measures include

• Certificate usage

• Smart card usage

• Fingerprint scan

• Retina scan

• Voice recognition

• Facial recognition

• Real-time location systems (RTLSs)

As basic as it seems, the policy should also include a statement prohibiting users from disclosing their passwords and or preshared keys to others. Often an employee or contractor may need to use the station of their coworker, and request the coworker’s credentials to log in. This practice should be prohibited, as should the user logging in and allowing others to use their system.

A base password complexity and length that is commonly used is a password of at least eight characters in length, at least one uppercase letter, at least one lowercase letter, at least one number, and at least one special character. For example, 8H4pT@b$ would meet the criteria of an eight-character strong password. Resources within an organization may require additional complexity or length to be more secure. Some organizations require users to maintain separate credentials for each resource. As you learned in Chapter 4, “802.1X/EAP Authentication,” most organizations synchronize user passwords across resources but use centralized authentication solutions, such as Lightweight Directory Access Protocol (LDAP) and/or Remote Authentication Dial-In User Service (RADIUS), in addition to complex password requirements. The length, complexity, and age of passwords should all be spelled out in a functional policy, and followed to reach the desired security level.

The same philosophies of complex passwords—not distributing them to others and age limits and so forth—that apply to a user’s password should also apply to the preshared key(s) used on your network. The preshared key (PSK) should be complex enough to prevent guessing of the key without the use of some extraordinary measure such as a cracking tool and still be simple enough for legitimate users to enter the key(s) on their own. The PSK(s) should be changed on a regular interval, not repeated or too similar to the last key or keys used, just like changing a user password.

RBAC Policy

In Chapter 8, “WLAN Security Infrastructure,” you learned about the technical aspects of role-based access control (RBAC), which is a method of providing or restricting WLAN access based on the identity of the user or device. Every user has his or her own job and should have access to the appropriate resources to do that job. To that end, users should all have their own accounts and credentials. This helps in building nonrepudiation into network activities. Granting access to resources beyond those required by users to do their job is a security hole. RBAC helps ensure that networking resources can only be accessed by users with permission to do so.

Written RBAC policies should be clearly defined, specifying what groups of users get to access which network resources. RBAC policies also define what type of devices get access to which network resources. People who need to do the same tasks usually require access to the same resources. By placing users into groups related to their job functions and assigning resource permissions to their groups, administration is an easier task and security is enhanced due to RBAC. As a user moves from job to job within an organization, permissions are easily assigned by moving the user’s account into and out of the appropriate groups. If written RBAC policies are clearly defined, the RBAC technical implementations will be better planned and deployed.

Change Control Policy

Periodically, vendors release firmware and software updates to improve functionality of their products or to correct errant releases of their products or new products. A good functional policy will include a well-designed change control procedure governing the upgrading or downgrading of firmware and software, as well as for performing hardware maintenance or hardware replacement. Change control processes help to ensure that changes to a product or system are introduced in a controlled and coordinated manner. Additionally, they should reduce the possibility that unnecessary changes are brought into a system, which could introduce problems or undo required changes made by other users. Change control policy usually includes procedures to minimize disruption to services, reduce back-out activities, and provide for cost-effective utilization of resources, while adhering to the security policy. Changing firmware or software may open security holes that were not there before. Things such as sockets or ports that were used by a previous version may not be used by the currently installed version and may not have been checked or secured when the security baseline was created. Just because the newer version is compatible with everything else running on the device does not mean it meets the security requirements within your policies. Even when the objectives of the changes are to meet security requirements, the changes must still be covered under written policy to help protect assets and reduce your exposure to risk.

In addition to including a mandated change control process in your policies, you must include monitoring and inspection of devices to make certain that required firmware and software is installed. You should also include statements covering the installation of unapproved software, such as freeware or user-purchased software. In large environments, adhering to a change control process helps to ensure uniformity of deployment. However, some devices can still be missed. Within the auditing statements of your security policy, you should include a mandate that software and firmware be at the required version level. An auditing requirement may also be included within a general policy or any policy covering risk assessment. Auditing is often required by an external regulation or industry policy. Devices missing patches are often exposed to attackers. When a vendor releases a security patch, attackers know where holes may be in unpatched systems, if they did not already know about them. Your policies may require that security patches be installed within a given period of time from their release. Once new software or firmware is installed, a new security baseline should be established and documented.

Whenever WLAN infrastructure is deployed, or changes to configurations are made, all settings should be documented. The encryption, authentication, RBAC, and VLAN settings for APs and WLAN controllers should always be documented and validated with checklists.

Authentication and Encryption Policy

Throughout this book, you have learned about enterprise solutions that are used to protect the WLAN portal. Many of these solutions only authorize network resource access for users who have had their credentials properly validated. Whenever possible, a functional policy mandating the use of 802.1X/EAP authentication mechanisms should be used. Consideration should also be given to mandate the use of multifactor authentication solutions before access is granted. Handheld devices like VoWiFi phones may need to use weaker authentication solutions, such as WPA2-Personal, if they do not support fast secure roaming mechanisms such as opportunistic key caching (OKC) or fast BSS transition (FT). Guest networks may use captive portal authentication for liability and auditing purposes.

You have also learned about the many available enterprise encryption solutions that are used to provide data privacy for the Layer 3–7 payload of 802.11 data frames. Dynamic CCMP/AES encryption should be used. Dynamic TKIP and WEP encryption are legacy encryption methods and are not supported for 802.11n and 802.11ac data rates. Legacy encryption will not be acceptable in any modern-day WLAN deployment.

WLAN Monitoring Policy

The WLAN should be monitored by a WIDS/WIPS solution for any compromise or attack of the WLAN, including rogue devices, ad hoc clients, and DoS attacks. Functional policy should define what steps should be taken when a breach is detected by the WIDS/WIPS solution. For example, will the WIPS be used to perform automatic or manual rogue containment? What action will be taken if a Layer 1 DoS attack is detected? What thresholds will be set for WIPS alarms, and how will the WIPS administrator be alerted to alarms? As you learned in Chapter 14, “Wireless Security Monitoring,” a WIPS can also be used to help enforce certain functional policies. For example, the WIPS may detect authorized WLAN clients with improperly configured security settings. The WIPS also may be used to contain or blacklist improperly configured client stations and effectively enforce encryption and authentication functional policies.

Endpoint Policy

It is likely that end-user client devices will leave a company’s controlled environment and operate outside of the area monitored by the WIPS. Employees will use access points that do not meet the corporate encryption and authentication policies. It is almost a certainty that employees will use company-provided client devices to access the Internet at Wi-Fi hotspots and other public access WLANs. Therefore, organizations must also implement an endpoint policy that governs the security of all client stations. While some devices such as VoWiFi phones and barcode scanners may never leave the corporate facilities, employee laptops, tablets, smartphones, and other smaller wireless devices are coming and going every day. When end users are at off-site locations, these company-owned devices are associating with other noncompany WLANs and therefore are not able to be monitored by the company WIPS.

Throughout this book, we have discussed the reasons and solutions needed for enterprise WLAN infrastructure security, with the goal of protecting corporate assets from attackers. One of the most important facts that a WLAN security professional should always remember is that the greatest WLAN security risks will always exist off-site. The only security that Wi-Fi hotspots and public access WLANs usually have is a captive portal. There is no expectation to have encryption, and any client station is exposed to the majority of the WLAN security risks that were discussed in Chapter 12, “Wireless Security Risks.” Public access WLANs are breeding grounds for peer-to-peer attacks, Wi-Fi phishing attacks, data theft or manipulation, eavesdropping attacks, and other malicious events. Always remember that WLAN hackers lurk at Wi-Fi hotspots and open public access WLANs.

Large organizations should delegate endpoint security to a group dedicated to malware prevention, detection, and response across all technology areas.

Network World, June 2014

Endpoint security measures within both general and functional policies should always be considered mandatory. At a minimum, the functional policy should mandate the use of a personal firewall and an IPsec VPN client solution. The personal firewall will protect client stations from peer-to-peer attacks. The IPsec VPN client will be used to establish an encrypted tunnel back to the corporate VPN server. The client’s data will not only be protected across the Internet, but will also provide data privacy in the air at the Wi-Fi hotspot. Because there is no security at the Wi-Fi hotspot, it is imperative that the employee bring the security to the unprotected WLAN.

WLAN specific policies that might be enforced with an endpoint solution include the following:

• Requiring specific WLAN encryption and authentication settings on the client side

• Preventing ad hoc connectivity

• Preventing bridging between wired and wireless network interfaces

• Enforcing VPNs

• Authorizing only certain SSIDs

• Blacklisting certain SSIDS

In recent years, WLAN client endpoint security and management has changed drastically due to the influx of BYOD devices such as smartphones and mobile tablets. As discussed in detail in Chapter 10, WLAN client policy enforcement is usually handled by more robust mobile device management solutions (MDM) or network access control (NAC) solutions. MDM and NAC software agents are often used for client-side policy enforcement for both personal and corporate-owned WLAN devices.

Acceptable Use Policy

The acceptable use policy defines the purpose of the WLAN and how the company employees may utilize the WLAN. The WLAN is obviously not to be used for illegal purposes and usually only for company activities. Acceptable use policies will also define what applications may be used over the WLAN. For example, the use of video streaming applications may not be allowed for employees. Certain types of downloading activities may also be banned because of the effect on throughput of the WLAN. The good news is that RBAC mechanisms, such as firewall restrictions and bandwidth throttling, can often be used to limit the activities of WLAN end users and therefore enforce acceptable use policies.

Physical Security

If you do not have physical security, do you really have security at all or just the illusion of security? The physical security policy will define how WLAN infrastructure will be protected from theft and vandalism. An attacker may also access the exposed ports of an unsecured AP to extract information about WLAN configuration settings. The location of all access points will be documented, and often the APs will be secured in indoor enclosure units that can be locked. Outdoor APs will also be secured in National Electrical Manufacturers Association (NEMA) enclosure units for protection from the weather. All WLAN controllers and servers should be secured in a data closet. Inventory and documentation of all client devices is also highly recommended.

Remote Office Policy

Given the widespread small office and home use of 802.11 wireless networks, the discussion of wireless security policy for the home and small office is worth having. To date, there are no regulations or industry standards focused on how to secure wireless home networks that are used for nonbusiness reasons. However, some laws, regulations, and standards apply to businesses no matter what the size, whereas others vary the requirements based on size of the business and the amount and type of information to be protected. Although the policy formation process may be less involved and the policy created less encompassing than required by an enterprise security solution, SOHO environments should also create and follow wireless security policies. Budgets and network size do not allow the same protections in SOHO environments as found in the enterprise. A small five-person office with only five laptops and one printer is not likely to install a WIPS for protection. There is no security team conducting daily audits in the SOHO environment. However, small and medium-sized business (SMB) offices must comply with external policy influences just as large corporations must comply. A great example would be a doctor’s office having the need to be Health Insurance Portability and Accountability Act (HIPAA) compliant. HIPAA requires any needed access to patient data to be accomplished in a secure manner based on maintaining patient confidentiality. If the office uses wireless communications to transfer patient data, the office must take measures to protect that data. A small collection agency may be required to meet Gramm-Leach-Bliley Act of 1999 (GLBA) compliance to continue to do business with their customers, putting a policy in place to protect the customers’ information from foreseeable security and data integrity threats. The Sarbanes-Oxley Act of 2002 (SOX) has a financial privacy rule that applies to companies receiving private financial information, whether or not they are financial institutions, requiring that anyone processing or storing such information must be SOX compliant. They may also be required to meet Payment Card Industry (PCI) standards as well. The business partner of a large corporation could have a small branch office that is insecure, potentially providing an attacker with an entrance into the network of the larger firm.

Securing your wireless network should be part of the design process, whether you are an office with a single remote AP or an enterprise with thousands of APs. Just as in the enterprise, SMB deployments should develop, follow, and adapt wireless security policies to protect the assets of the organization. If the business is not required to follow industry or governmental guidelines, a simple policy covering physical security, authentication, and encryption may suffice. However, if the SMB operates in business areas where regulations exist, the policy must take into account all the external policy influences as well as simple protection policies. The smaller deployment size of SOHO wireless networks in no way negates the need for security and written, followed, enforced, and adaptable wireless security solutions and policies.

Government and Industry Regulations

In most countries, mandated regulations exist, describing how to protect and secure data communications within all government agencies. In the United States, NIST is responsible for maintaining the Federal Information Processing Standards (FIPS). The FIPS PUB 200 standard specifies minimum security requirements for federal information and information systems in seventeen security-related areas. The FIPS specifications for minimum security requirements include access control, configuration management, authentication, risk assessment, auditing, and much more. Even if your organization is not required to meet FIPS PUB 200 requirements, reading FIPS PUB 200 and adopting some if not all of the requirements into your own security policy would not be a bad idea. Of special interest to wireless security is the FIPS 140-2 standard, which defines security requirements for cryptography modules. The use of validated cryptographic modules is required by the U.S. government for all unclassified communications. Other countries also recognize the FIPS 140-2 standard or have similar regulations. All the FIPS publications can be found online at http://csrc.nist.gov/publications/PubsFIPS.html.

From government to healthcare, banking, or even energy sectors, more and more external regulations, laws, and standards are affecting how we use wireless networking. In this section, we will explore how some of the more widely known external mandates are directly influencing wireless use and how they should be incorporated into WLAN security policies. We will specifically examine the following as they pertain to the use of 802.11-based wireless devices:

• The U.S. Department of Defense (DoD) Directive 8420.01

• The U.S. Federal Information Processing Standards (FIPS 140-2)

• Sarbanes-Oxley Act (SOX)

• Graham-Leach-Bliley Act (GLBA)

• Health Insurance Portability and Accountability Act (HIPAA)

• Payment Card Industry (PCI) Standard

The U.S. Department of Defense (DoD) Directive 8420.1

On April 24, 2004, the U.S. Department of Defense issued a directive covering the use of commercial wireless devices, services, and technologies within the Global Information Grid (GIG). This directive, titled the Department of Defense (DoD) Directive 8100.2, details the DoD policy for the secure use of wireless networks and devices. It also includes policy statements requiring the monitoring of wireless devices that are deployed, and monitoring for wireless devices in areas that do not have authorized wireless deployments. Furthermore, this directive states that there are areas in which the use of wireless networking is banned. The policy covers both authorized and banned wireless usage.

In November of 2009, the original directive was replaced with DoD Directive 8420.1 for Commercial Wireless Local-Area Network (WLAN) Devices, Systems, and Technologies. The directive allows for the embracing of technologies from open standards–based solutions while providing a framework from within which this can be done securely. Directive 8420.1 applies to 802.11-based communications and devices but does not cover cellular, Worldwide Interoperability for Microwave Access (WiMAX), Bluetooth, or proprietary RF communication mechanisms. Directive 8420.1 applies to all DoD components, military and civilian alike. It covers any personal electronic devices, laptops, PDAs, cell phones, and so on, that are able to process, store, or transmit information wirelessly.

All components parts of the DoD must ensure that devices are certified and validated under DoD regulations for interoperability and that there is secure end-to-end communications. The 8420.1 directive requires the following measures be taken:

• All cryptographic functionality must meet, at a minimum, NIST FIPS 140-2 Level 1 validation.

• All WLAN devices deployed must be National Information Assurance Partnership (NIAP) Common Criteria Certified.

• WLAN devices must be certified by the Wi-Fi Alliance and be WPA2 certified.

• Personal electronic devices, laptops, PDAs, and so forth must use a NIAP Common Criteria Certified Personal Firewall and Antivirus.

All portions of the DoD components were required to implement WLAN solutions that are IEEE 802.11i compliant and WPA2 Enterprise certified. The policy also mandates that they implement 802.1X access control with EAP-TLS mutual authentication and a configuration that ensures exclusive use of FIPS 140-2 (minimum overall Level 1) validated AES-CCMP encrypted transmissions. Directive 8420.1 also requires the use of wireless intrusion detection systems (WIDSs), something not included in the original 8100.2 directive. Some components of the DoD have included wireless intrusion prevention systems (WIPSs) in addition to basic WIDS functionality. Directive 8420.1 states that

• WIDSs are required for all DoD wired and wireless networks.

• WIDSs must continually scan for and detect both authorized and unauthorized devices. Continually scanning is defined as 24/7 monitoring.

• WIDSs must also have location tracking capability.

• WIDSs must be validated under NIAP Common Criteria Certification.

The DoD has well-defined policies at both the general and functional policy levels. Given that users within the DoD travel the globe and may have access to high-priority data, the policies for their network may be too restrictive for some environments to the point of enforcing no wireless zones. Directive 8420.1 addresses security beyond configuration. It mandates monitoring for wireless devices, even where none are deployed, and covers encryption, certification, and validation. Such high standards limit the hardware and software that can be used due to the level of compliance, certification, and validation required. So who must comply with DoD Directive8420.1? The answer is any DoD employee, contractor, or visitor to any DoD facility as well as any others who have access to DoD information.

Federal Information Processing Standards (FIPS) 140-2

The Federal Information Processing Standards (FIPS) are issued by NIST. They were created in the United States under the Information Technology Management Reform Act (Public Law 104-106). The Secretary of Commerce approves the standards and guidelines that are developed by NIST. These standards are created by NIST when there is a specific need for security and/or interoperability, and there are no industry standards that meet the requirements. We will focus on only FIPS 140-2 compliance requirements as they relate to wireless communication. FIPS Publication 140-2 was released on May 25, 2001. It super-sedes FIPS 140-1, which was released on January 11, 1994. FIPS 140-2 covers the federal requirements for cryptographic modules. Specifically, it covers the security requirements that will be satisfied by a cryptographic module utilized within a security system protecting sensitive but unclassified information. Many businesses and individuals conducting operations with the U.S. government and/or selling communication devices to the government must comply with this publication.

FIPS 140-2 has increasing levels of requirements from Level 1 to Level 4. Each higher level must meet all of the lower-level requirements in addition to their own specifications. These mandates cover areas of both secure design and secure deployment of applications and communications. The appendices of this standard summarize the requirements and describe each of the four levels of requirements. Each of the four levels spell out their functional requirements. As FIPS 140-2 relates to cryptographic modules, the four levels are as follows:

Level 1 Security requirements are specified for a cryptographic module at this level. No specific physical security mechanisms are required in a Security Level 1 cryptographic module beyond the basic requirement for production-grade components. However, at least one Approved algorithm or Approved security function should be used.

Level 2 Level 2 requires features that show evidence of tampering, including tamperevident coatings or seals that must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters (CSPs) within the module, or pick-resistant locks on covers or doors to protect against unauthorized physical access. (Many devices use painted screws, seals, or tamper-evident tape to meet this requirement.)

Level 3 Level 3 attempts to prevent the intruder from gaining access to critical security parameters (CSPs) held within the cryptographic module. Physical security mechanisms required at Security Level 3 are intended to have a high probability of detecting and responding to attempts at compromising the cryptographic module. The practice of erasing sensitive parameters such as keys from a cryptographic module to prevent their disclosure if the equipment is captured is known as zeroization. Physical security mechanisms may include the use of strong enclosures and tamper detection/response circuitry that zeroizes all plaintext CSPs when the removable covers/doors of the cryptographic module are opened.

Level 4 Level 4 provides the highest level of security. Here the physical security mechanisms have the intent of detecting and responding to all unauthorized attempts at physical access. Any compromise of the cryptographic module enclosure is most likely going to be detected, resulting in the immediate zeroization of all plaintext CSPs. Level 4 cryptographic modules are important to use in physically unprotected environments. Level 4 also requires protection for a cryptographic module against compromise due to environmental conditions, such as temperature and power variations beyond normal operation. Cryptographic modules are required to include special environmental protection features designed to detect fluctuations and zeroize CSPs, or as an alternative undergo rigorous environmental failure testing providing reasonable assurance that the module will not be compromised by fluctuations outside of the normal operating range in a manner that can reduce or negate the security of the module at Level 4 certification.

So who must comply with FIPS 140-2? Just about all U.S. government agencies must comply. The applicable audience for FIPS 140-2 is all federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. Any devices sold for deployment in these areas must meet this standard. Any systems, applications, or devices approved for classified transmissions can be substituted, since they comply with standards that exceed those mandated in FIPS 140-2. In simpler words, within any federal agency that handles data of sensitive nature, the computer network solution must be FIPS 140-2 compliant.

The standard also includes an implementation schedule, export rules, and contact information for valid interpretation of its content. Realizing that there may be a need for some exceptions, there is even a waiver process outlined to allow for exemptions if needed and justified. This applies to wireless communications and the associated devices used by anyone required to follow this standard. Even outside areas where FIPS compliance and certification is mandated, following these measures improves an organization’s security posture. With all of the security measures spelled out in FIPS 140-2, it is easy to see why your organization may want to follow its guidelines. However, the most compelling reason to follow FIPS 140-2 is that it is a federal mandate. This mandate will continue to be adapted as technology changes, as evidenced by the continued exploration of security standardization by NIST.

The Sarbanes-Oxley Act of 2002 (SOX)

The Sarbanes-Oxley Act of 2002 (SOX) defines more stringent controls on corporate accounting and auditing procedures with a goal of corporate responsibility and enhanced financial disclosure. The act is named Sarbanes-Oxley after Senator Paul Sarbanes and Representative Michael Oxley, the key figures who drafted it in 2002. The legislation set new or enhanced standards for all U.S. public company boards, management, and public accounting firms. Since SOX applies to publicly traded companies, it does not apply to privately held companies or those publicly traded companies that do not operate within the United States. The act contains 11 titles and multiple sections, ranging from additional corporate board responsibilities to criminal penalties, and it requires the Securities and Exchange Commission (SEC) to implement rulings on the requirements to comply with the new law. The two most relevant sections for a wireless security discussion are 302 and 404.

Section 302: Corporate Responsibility for Financial Reporting This section may be the best known one. It requires the CEO and CFO to certify that they have reviewed the financial reports, that the information is complete and accurate, and that effective disclosure controls and procedures are in place to ensure material information is made known to them. Section 302 of the Act mandates a set of internal procedures that ensure accurate financial disclosure.

Section 404: Management Assessment of Internal Controls This is a newer section with the following three basic requirements:

• Establishment of effective internal controls by corporate management for accurate and complete reporting

• Annual assessment by management of the effectiveness of internal controls supported by documented evidence

• Validation of management’s assessment by a registered public accounting firm

SOX Section 404 does not specifically discuss information technology (IT) and the related security requirements. However, most financial reporting systems are heavily dependent on technology. The burden falls on the CIO and IT staff members to establish effective internal controls over the network and storage infrastructure supporting the financial reporting process. Businesses are increasingly implementing wireless networks to improve productivity and reduce costs. The introduction of wireless networking also brings new security challenges and reporting and monitoring requirements for those requiring SOX compliance. Since its passing in 2002, SOX Section 404 has been the topic of debate to either remove or replace the section. Section 404b is thought to increase investor risk.

SOX also created a quasi-public agency, the Public Company Accounting Oversight Board (PCAOB). The PCAOB has the responsibility of overseeing, regulating, inspecting, and disciplining accounting firms in their roles as auditors of public companies. Furthermore, SOX covers auditor independence, corporate governance, internal control assessment, and enhanced financial disclosure. The goal of SOX was to restore faith in publicly traded companies’ reporting of earnings in the wake of several large trading scandals. The applicable audience for SOX consists of all public companies in the United States, international companies that have registered equity or debt securities with the SEC, and the accounting firms that provide auditing services to them.

Where does information assurance (IA) fit into SOX compliance? IA fits within SOX compliance in the following manner:

• SOX covers everything revolving around the confidentiality, availability, and (especially) integrity of financial data.

• SOX requires a recognized internal control framework.

• The Committee of Sponsoring Organizations (COSO) framework provides structured and comprehensive guidelines for implementing internal controls for SOX.

• The COSO recommended (but did not require) a framework by PCAOB.

• Five components of effective internal control are stipulated: Control Environment, Risk Assessment, Control Activities, Information & Communication, and Monitoring.

• The Control Objectives for Information and Related Technology (COBIT) framework, which was developed by the Information Systems Audit and Control Association (ISACA), bridges the gap between IT governance and SOX, and it addresses 34 IT processes that can all be mapped to COSO.

IA and IT fit within SOX under information security policies, network security, access controls, authentication, encryption, logging, monitoring and alerting, incident response and forensics, and IT audit. The secure implementation, use, and monitoring of wireless devices and networks clearly fits into these areas and therefore into SOX compliance.

Graham-Leach-Bliley Act (GLBA)

The Financial Modernization Act of 1999, which is more commonly known as the Gramm-Leach-Bliley Act (GLBA), requires banks and financial institutions to notify customers of policies and practices disclosing customer information. The goal is to protect personal information such as credit card numbers, Social Security numbers, names, addresses, and so forth. There are five core requirements for GLBA:

• Designate employees for information security.

• Identify and assess all risks and safeguards.

• Design, implement, test, and monitor safeguard programs.

• Respond to security events, and remediate and adjust based on monitoring.

• Select appropriate service providers.

To these ends, GLBA gives authority to states and eight federal agencies to administer and enforce two rules: the Financial Privacy Rule and the Safeguards Rule. Financial institutions are the applicable audience for these two regulations. This includes banks, securities firms, insurance companies, and companies providing several other types of financial products and services. These cover a wide range of services, including lending, brokering or servicing any type of consumer loan, transferring money, safeguarding money, preparing individual tax returns, providing financial advice, credit counseling, providing residential real estate settlement services, collecting consumer debts, and several other common financial services. Let’s examine the two rules as well as discuss the concept of pretexting:

The Financial Privacy Rule This rule covers the collection and disclosure of any personal financial information by financial institutions. It also applies to companies receiving such information, whether or not they are financial institutions.

The Safeguards Rule This rule requires that all financial institutions design, implement, and maintain safeguards protecting customer information. This applies to financial institutions that collect information from their own customers and any other financial institutions that receive customer information from other financial institutions, such as reporting agencies.

Pretexting There is also coverage of fraudulently obtaining personal information. Obtaining this information under false pretenses is called pretexting. Social engineering is often used to obtain the private information of others. Attackers solicit the data by using what appears to be a legitimate request.

Whether or not a financial institution discloses personal information, there must be a policy in place to protect the information from foreseeable threats in security and data integrity. Institutions must take reasonable protective measures to secure client data. This is a mandatory portion of GLBA compliance and also where wireless security comes into play. Maintaining data privacy is specifically covered in Title 5 of the Act, and has the following mandates covering data privacy:

• Requires clear disclosure to clients and others by all financial institutions of their privacy policy regarding the sharing of personal information with both affiliates and third parties.

• Requires a notice to consumers and an opportunity to opt out of sharing of personal information with nonaffiliated third parties, subject to certain limited exceptions. (Clients often must notify the institution of their desire to opt out.)

• Addresses a potential imbalance between the treatment of large financial services conglomerates and small banks by including an exception, subject to strict controls, for joint marketing arrangements between financial institutions. (Consumers often see the exemptions as additional offerings from the institutions’ partners.)

• Clarifies that the disclosure of a financial institution’s privacy policy is required to take place at the time of establishing a customer relationship with a consumer and not less than annually during the continuation of such relationship. (This may only be done once a year or may be done as changes to the initial agreement are implemented.)

• Provides for a separate rather than joint rulemaking to protect client privacy; the relevant agencies are directed, however, to consult and coordinate with one another for purposes of assuring, to the maximum extent possible, that the regulations that each prescribes are consistent and comparable with those prescribed by the other agencies.

• Allows the functional regulators sufficient flexibility to prescribe necessary exceptions and clarifications to the prohibitions and requirements of section 502.

• Clarifies that the remedies described in section 505 are the exclusive remedies for violations of the subtitle.

• Clarifies that nothing in this title is intended to modify, limit, or supersede the operation of the Fair Credit Reporting Act.

• Extends the time period for completion of a study on financial institutions’ informationsharing practices from 6 to 18 months from the date of enactment.

• Requires that rules for the disclosure of institutions’ privacy policies must be issued by regulators within six months of the date of enactment. The rules will become effective six months after they are required to be prescribed unless the regulators specify a later date.

• Assigns authority for enforcing the privacy provisions to the Federal Trade Commission and the federal banking agencies, the National Credit Union Administration, and the Securities and Exchange Commission, according to their respective jurisdictions, and it provides for enforcement of the privacy provisions by the states.

Identity theft, or using the identity of another person fraudulently, is a crime that hurts society as a whole, undermining financial institutions and the economy alike. GLBA compliance helps reduce the occurrence of this crime by regulating the protection of personal information collected by financial institutions. As financial institutions, like many other conservative organizations, begin to introduce wireless networking, additional steps must be taken to protect private data. Wireless networks introduce additional entry points into financial institutions’ networks that must be monitored and secured. Mandated followers of GLBA include

• Banks, thrifts, and credit unions

• Financial advisers/investment firms

• Insurance companies

• Credit card/financial transaction processing providers

• Consumer credit reporting agencies

• Frontend/backend (core) providers and check printers

• Tax information preparers/processors

• Other service providers receiving customer information from financial institutions as regulated by the GLBA’s Safeguards Rule

GLBA emphasizes that threats to information security are ever changing and describes them in general terms. Financial institutions must evaluate and adjust their information assurance programs to keep up with changes in technology, such as the increased use of Wi-Fi, and new or emerging threats that indicate they are vulnerable to attack or compromise.

More information about GLBA and identity theft can be found at www.ftc.gov.

Health Insurance Portability and Accountability Act (HIPAA)

The Health Insurance Portability and Accountability Act (HIPAA) establishes national standards for electronic healthcare transactions and national standards for providers, health insurance plans, and employers. The goal is to protect patient information and maintain privacy. One major goal of the Privacy Rule found in HIPAA is to assure that health information is properly protected while still allowing the flow of information about an individual’s health needed to provide and promote high-quality healthcare as well as protecting the public’s health and well-being. The Privacy Rule seeks a balance that permits important uses of information, while protecting the individual’s privacy. Healthcare is a diverse industry. The Privacy Rule is designed to be flexible and comprehensive, allowing coverage of the large variety of uses and disclosures that need to be addressed within reasonable privacy.

The use of wireless technology has proven to be a method of delivering patient care that is faster for the patients and more convenient for the caregivers. However, this more timely delivery of care may introduce situations that are outside the industry’s guiding privacy standard, HIPAA. Securing WLANs within the healthcare industry is critical. Interruptions in service can lead to life-threatening situations as well as data compromise. Electronic patient records make much of the behind-the-scenes work done by doctors, nurses, and other healthcare professionals an easier task. Multidimensional bar codes on drugs and arm bands allow caregivers rapid access to life-saving information. Unlike many other enterprise environments, hospitals have many areas of physical public access that also have access to data ports such as the patient rooms. The use of wireless networking increases this risk to care and patient data privacy.

The applicable audience for the Privacy Rule, as well as all the administrative simplification rules, are health plans, healthcare clearinghouses, and any healthcare provider that transmits health information in electronic form in connection with transactions for which the Secretary of Health and Human Services (HHS) has adopted standards under HIPAA. The electronic transfer of health information includes wireless transmissions. Under section 164.530(i), HIPAA requires covered entities to develop and implement written privacy policies and procedures that are consistent with the Privacy Rule. They must also assign a person to oversee the procedure for receiving complaints about their privacy procedures and to provide individuals with information about the procedures upon request. The two largest sections that pertain to wireless as well as networking in general are as follows:

Mitigation Covered entities must reduce the effect of any loss of private data, to the extent practicable, and any harmful effect it learns was caused by use or disclosure of protected health information. This loss could have been caused by its own workforce or its business associates in violation of its privacy policies and procedures or the Privacy Rule.

Data Safeguards Covered entities must maintain reasonable and appropriate administrative, technical, and physical safeguards to prevent compromise of protected health information in violation of the Privacy Rule. Covered entities must also limit their incidental use and disclosure pursuant to otherwise permitted or required use or disclosure.

HIPAA allows each organization to determine the appropriate measures they must take to secure private information. This is largely due to the variation in healthcare areas. Both large and small organizations determine how best to meet the requirements of HIPAA.

Therefore, there is no specified format for compliance. In general, covered entities must do the following:

• Put in place administrative safeguards to manage the selection and execution of security measures chosen.

• Ensure physical safeguards are in place protecting electronic systems, buildings, and the equipment used from environmental and unauthorized intrusions that may compromise private data.

• Make certain that technical safeguards are in place, including automated processes to control access to private data and to protect private data.

• Conduct risk assessments and document security policies and procedures.

• Covered entities must have a device, such as a firewall, to screen traffic from the Internet.

Accountability is a great area to look for a wireless fit in HIPAA when trying to ensure your organization’s compliance. The Privacy Rule has the foundation for accountability within an electronic health information exchange environment. It requires all covered entities involved in the exchange of protected health information, on paper or electronically, to comply with the administrative requirements of HIPAA and to extend these obligations to all business associates. The Privacy Rule promotes this accountability with established mechanisms addressing potential noncompliance. The Privacy Rule has standards, through a covered entity’s voluntary compliance, a resolution agreement, and a corrective action plan, or the imposition of civil money penalties ranging from $100 to $50,000 or higher per incident.

More information about HIPAA can be found at www.hhs.gov/ocr/privacy.

Payment Card Industry (PCI) Standard

As more of us continue to rely on credit cards as our primary method of payment, more of us risk losing our card numbers to attackers and identity thieves through unsecure processing and/or storing of our cardholder information. The Payment Card Industry (PCI) realizes that in order to sustain continued business growth, measures must be taken to protect customer data and card numbers. The PCI Security Standards Council (SSC) has implemented regulations for those processing and storing cardholder information. This is commonly referred to as the Payment Card Industry (PCI) Standard. Within this standard are components governing the use of wireless devices.

As a further explanation of PCI requirements governing wireless devices, the information supplement PCI Data Security Standard (DSS) Wireless Guideline was prepared by the PCI SSC Wireless Special Interest Group (SIG) Implementation Team and released in July 2009 and updated in 2011. The PCI standards cover many aspects of credit card use, acceptance, and processing. This standard is designed to protect the cardholder data environment (CDE). The CDE is defined as the computer environment wherein cardholder data is transferred, processed, or stored, and any networks or devices directly connected to that environment.

Let’s focus on the PCI implications of wireless networking and device use. The PCI DSS wireless requirements can be broken down into two main categories: (1) generally applicable wireless requirements and (2) requirements applicable for in-scope wireless networks. They cover protection against rogue devices and protection of networks storing or processing cardholder data.

What does PCI DSS call a rogue AP? A rogue AP is any device that adds an unauthorized (and therefore unmanaged and unsecured) WLAN to the organization’s network. This rogue device need not be placed by an attacker. In this context, a rogue AP could be added by inserting a WLAN card into a back-office server, attaching an unknown WLAN router to the network, or by various other means. Most rogue devices are placed by internal sources, often just trying to be more productive.

There is also provision for legitimate wireless use on the same network as the CDE. If an organization decides to deploy a WLAN for any purpose and connects the WLAN to the CDE, that WLAN becomes part of the CDE and is therefore within the scope of the PCI DSS and must comply with the PCI guidelines for wireless device use. If an organization deploys a WLAN that in no way touches the network that is part of the CDE, then that WLAN is out of the scope of the PCI DSS. However, should that WLAN touch the firewall that is connected to the CDE, the firewall then falls into the scope of PCI DSS. Roughly, any network that processes or stores cardholder information or any network, wired or wireless, that touches the CDE must be PCI DSS compliant. PCI DSS requires that wireless networks that do not store, process, or transmit cardholder data must be isolated from the CDE using a firewall. Any organization required to comply with PCI standards using WLANs that do not touch the CDE must also be able to prove that there is no connectivity from the WLANs to the CDE.

Specifically the two main areas of PCI covering wireless devices state the following:

Generally Applicable Wireless Requirements All organizations that wish to comply with PCI DSS should have in place methods to protect their networks from attacks via rogue or unknown wireless APs and clients. They apply to organizations regardless of their use of wireless technology and regardless of whether the wireless technology is a part of the CDE.

Requirements Applicable for In-Scope Wireless Networks All these requirements apply in addition to the universally applicable set of requirements. All organizations that wish to comply with PCI DSS that transmit payment card information over wireless technology should have in place mechanisms to protect those systems. These requirements are specific to the usage of wireless technology that is in scope for PCI DSS compliance.

Organizations that must comply with the PCI standard must also maintain an inventory of devices. It is recommended that such organizations scan for wireless devices to keep an up-to-date listing of all known WLAN devices, making rogue detection easier. PCI standard section 11.1 states that organizations must test for the presence of wireless APs by using a wireless analyzer at least quarterly or by deploying a WIDS/WIPS to identify all wireless devices in use. This means that every location, retail outlet, warehouse, office, and so on that stores or processes cardholder information be scanned each quarter or have a WIDS/WIPS deployed to scan for them. Since travel to thousands of locations of a large retailer, for example, is time consuming and expensive, many organizations have come to rely on the scanning and protection offered by WIPS. Section 12.9 states that there must also be an incidence response plan that is followed should a rogue device be detected. This is another compliance requirement that can be automated by an effective WIPS deployment.

The PCI Security Standards Council recommends the following with regard to rogue wireless devices and PCI compliance:

• Use a wireless analyzer or a WIDS/WIPS at least quarterly at all locations to detect unauthorized/rogue wireless devices that could be connected to the CDE. For large organizations having several CDE locations, a centrally managed WIDS/WIPS to detect and contain unauthorized/rogue wireless devices is recommended.

• Enable automatic alerts and containment mechanisms on the wireless IPS to eliminate rogues and unauthorized wireless connections into the CDE.

• Create an incident response plan to physically eliminate rogue devices immediately from the CDE in accordance with PCI DSS requirement 12.9.

Section 1.2.3 requires that organizations install perimeter firewalls between any wireless networks and the CDE. These firewalls must be configured to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment going into or leaving the CDE. These firewalls are required to be audited at least every six months. This section also states that the reliance on VLAN protection of the CDE alone is not sufficient. To reduce the risk to the CDE, any protocol or traffic that is not necessary in the processing or storing of credit card transactions or cardholder data should be blocked. To this end, the PCI Security Standards Council recommends the following practices for firewalls:

• Use a stateful packet inspection firewall to block wireless traffic from entering the CDE. Augment the firewall with a WIDS/WIPS.

• Do not use VLAN-based segmentation with MAC address filters for segmenting wireless networks.

• Monitor firewall logs daily and verify firewall rules at least once every six months.

PCI DSS compliance for networks that include WLANs as a part of the CDE requires extra attention to WLAN-specific technologies and processes such as the following:

• Physical security of wireless devices

• Changing of default passwords and settings on wireless devices

• Logging of wireless access and intrusion prevention

• Strong wireless authentication and encryption

• Use of strong cryptography and security protocols

• Development and enforcement of wireless usage policies

Many older devices and WLANs touching or used by the CDE have been using WEP for security. Under PCI compliance, new wireless implementations were prohibited from implementing WEP after March 31, 2009. PCI compliance further required that WEP not be used and stronger security be in place on any network touching the CDE by the end of June 2010. This mandate meant that many wireless devices had to be upgraded or replaced. The PCI Security Standards Council recommends the following practices for WLANs and APs:

• Enable WPA or WPA2, and make sure that default PSKs are changed. Enterprise mode is recommended.

• Disable SNMP access to remote APs if possible. If not, change default SNMP passwords and use SNMPv3 with authentication and privacy enabled.

• Do not advertise organization names in the SSID broadcast.

• Synchronize the APs’ clocks to be the same as other networking equipment used by the organization.

• Disable all unnecessary applications, ports, and protocols.

• WPA or WPA2 Enterprise mode with 802.1X authentication and AES encryption is recommended for WLAN networks.

• It is recommended that WPA2-Personal mode be used with a minimum 13-character random passphrase and AES encryption.

• Preshared keys should be changed on a regular basis.

• Centralized management systems that can control and configure distributed wireless networks are recommended.

• The use of WEP in the CDE is prohibited for all deployments.

The PCI requirements are much more specific than other industry standards covering wireless device use. For example, section 12.3 requires organizations to develop usage policies for critical employee-facing technologies to define proper use of these technologies for all employees and contractors. This requirement covers PDAs, remote access technologies, wireless technologies, removable electronic media (such as USB drives, laptops, and personal data/digital assistants [PDAs]), email usage, and Internet usage.

The PCI standard has many more wireless requirements than most other external influences. This is largely due to the widespread use of wireless devices in networks touching the CDE. There have been several large losses of cardholder information. One of the largest and most publicly known losses involved wireless devices. As technology continues to drive business efforts, look for even more regulation covering the use of electronic devices and communication, especially wireless networking due to its unbounded nature. Keep in mind that where there is something of value that can be stolen, such as the data in the CDE, attackers are more likely to exist. Being compliant is not always the same as being secure. However, the PCI guidelines are forcing those that process payment cards or store cardholder information to create safer environments for the data they use and store as part of meeting that compliance.

More information about the PCI standard can be found at www.pcisecuritystandards.org.

Detailed information about PCI wireless guidelines can be found at www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_Wireless_Guidelines.pdf.

Compliance Reports

Many WIPS solutions and other WLAN auditing software tools have the capability of analyzing existing WLANs and generating industry-specific compliance reports. These compliance reports can be helpful when identifying areas in need of improvement. Furthermore, industry-specific compliance reports can be useful when writing WLAN policies.

802.11 WLAN Policy Recommendations

Although a detailed and thorough policy document should be created for every organization’s deployment of wireless technology, we highly recommend these five wireless security policies:

BYOD Policy Employees like to bring their personal Wi-Fi devices, such as tablets and smartphones, to the workplace. Employees usually expect to be able to use their personal Wi-Fi devices on the secure corporate WLAN. Each employer needs to define a bring your own device (BYOD) policy that clearly states how personal devices will be onboarded onto the secure corporate WLAN. The BYOD policy should also state how the personal devices can be used while connected to the company WLAN and which corporate network resources are accessible. BYOD is discussed in great detail in Chapter 10, “BYOD and Guest Access.”

Guest Access Policy Guest users and devices will most likely need to access the corporate WLAN. Guest WLAN access is typically used only to provide a wireless gateway to the Internet. A guest access policy in regard to guest credentials, guest access times, guest SSID security, and firewall policies will need to be clearly defined.

Remote Access WLAN Policy End users will be taking their laptops and handheld devices off site and away from company grounds. Most users will likely use wireless networks at home and at wireless hotspots to access the Internet. By design, many of these remote wireless networks have absolutely no security in place, and it is imperative that a remote access WLAN policy be strictly enforced. This policy should include the required use of an IPsec VPN solution to provide device authentication, user authentication, and strong encryption of all wireless data traffic. Hotspots are prime targets for malicious eavesdropping attacks. Personal firewalls should also be installed on all remote computers. Personal firewalls will not prevent hijacking attacks or peer-to-peer attacks but will prevent attackers from accessing most critical information. As you have learned, endpoint WLAN policy enforcement software solutions exist that force end users to use VPN and firewall security when accessing any wireless network other than the corporate WLAN. The remote access policy is mandatory because the most likely and vulnerable location for an attack to occur is at a public access hotspot.

Rogue AP Policy No end users should ever be permitted to install their own wireless devices on the corporate network. This includes access points, wireless routers, wireless USB clients, and wireless cards. Any users installing their own wireless equipment could open unsecured portals into the main infrastructure network. This policy should be strictly enforced.

Ad Hoc Policy End users should not be permitted to set up ad hoc or peer-to-peer networks. Peer-to-peer networks rarely use encryption, are susceptible to peer attacks, and can serve as unsecured portals to the infrastructure network if the computer’s Ethernet port is also in use.

Wireless LAN Proper Use Policy A thorough policy should outline the proper use and implementation of the main corporate wireless network. This policy should include proper installation procedures, proper security implementations, and allowed application use on the wireless LAN.

WIDS Policy Policies should be written defining how properly to respond to alerts generated by the wireless intrusion detection system. An example would be how to deal with the discovery of rogue access points and all the necessary actions that should take place.

These seven policies are simplistic but are a good starting point in writing a well-rounded WLAN security policy document. Keep in mind that a proper WLAN policy document should be much more detailed and cover many more topics than XX, and be strictly enforced.

Summary

All of the wonderful benefits and return on investment offered by wireless networking may cease to exist or cease to be allowed should a security and management policy not be in place and enforced. The security of the WLAN should be an integral part of the WLAN design and deployment. The wireless devices must be physically secure. The transmission of data wirelessly must also be secured. To reach the goal of effective and secure communications, written and enforced policy must be in place and communicated to all end users from conception forward. Data confidentiality, integrity, and nonrepudiation have long been goals of network security. The introduction of wireless networking does not change these goals but rather introduces new challenges in meeting them. As the use of wireless technology continues to grow, fueled by productivity gains, convenience, and cost savings, new security challenges are continually faced by networks. WLANs allow users untethered connectivity. This new freedom can often bypass existing security measures. As technology and business requirements change, security measures must keep up in order to avoid loss of private data and/or network functionality. Written, enforced, and adaptable policies help to ensure that when business requirements and technology move forward, security measures will be in place to protect the resources of the organization.

Exam Essentials

Explain the differences between general and functional WLAN security policies. General policy establishes a framework for enforcement; functional policy defines technical aspects of security.

Describe all aspects of general policy creation and management. General policy requires a statement of authority, defines an applicable audience, and requires risk assessment and threat analysis. Security auditing and violation procedures must also be clearly defined.

Explain the importance of functional password policy and functional RBAC policy. All end users should abide by well-defined password policies that require strong passwords and possibly two-factor authentication. Passwords should never be shared. RBAC policies ensure that certain groups of users are only allowed access to certain network resources.

Explain the importance of functional change control policy and WLAN monitoring policy. Change control procedures govern the upgrading or downgrading of firmware and software as well as hardware maintenance. Change control processes help ensure that changes to a product or system are introduced in a controlled and coordinated manner. WLAN monitoring policy defines what steps should be taken when an attack is detected by the WIDS/WIPS solution.

Explain the importance of functional authentication and encryption policies. Whenever possible, a functional policy requiring the use of 802.1X/EAP tunneled authentication should be mandated. Consideration should also be given to mandate the use of multifactor authentication solutions that require two sets of credentials before access is granted. Dynamic CCMP/AES encryption should always be mandated for data privacy.

Define the various aspects of endpoint security policy. Minimum endpoint compliance should mandate the use of IPsec VPNs and personal firewalls. Heavy consideration should also be given to implementing an endpoint policy enforcement software solution.

Describe the functional policies of acceptable use, physical security, and remote office security. All end users should only use applications that are intended for use on the WLAN. All WLAN infrastructure should be locked and protected from theft and vandalism. Policies should also protect WLANs at corporate headquarters as well as at remote offices.

Review Questions

1. Your organization is developing a wireless device usage policy. Which group(s) should be represented in the committee that actually develops this policy?

A. IT staff

B. Security staff

C. Management

D. End users

E. Support staff

F. All of the above

2. A large retail store chain has decided to implement wireless registers in their gardening department to allow for seasonal reconfiguration of the sales area. Knowing that they must follow the PCI standard since they process credit cards at these stations, they have hired you to ensure that their designs are PCI compliant. Which portion of their network designs should you examine to help determine if they are compliant?

A. The wireless registers

B. The APs used by the wireless registers

C. The switches to which the APs are connected

D. The portions that touch the CDE

E. The PCI standard does not allow wireless device use.

3. A merchant hires you to install a wireless network for processing credit cards in all of their new retail outlets as the stores are opened over the next six months. They have already purchased APs at an auction for you to install. Upon inspection of the APs, you find that they cannot be upgraded to support authentication and encryption beyond 64-bit WEP. You immediately inform the merchant that the APs they have purchased cannot be deployed in their new stores. What is the best reason you can give the merchant for not being able to use the APs they have already purchased?

A. They were not purchased through you, so you cannot warranty them.

B. PCI mandates that 128-bit WEP be used in all new deployments.

C. 64-bit WEP uses a 24-bit initialization vector and 128-bit WEP uses a 48-bit initialization vector.

D. PCI compliance does not allow new installation to use WEP.

E. WEP encryption will slow down card processing, resulting in angry customers.

4. To protect users and their laptops as they travel, your organization has decided to implement a wireless mobile device policy. You have explained to management that you are not able to offer the traveling users the same protection they have within your facilities as they travel, because your company does not own or manage all the hotspots to which your users may need to connect. The executives have instructed you to develop a policy that can be enforced and followed that will improve on the security users find at hotspots. What three things can you include in the policy that will help increase wireless security for traveling users while still allowing them to use the hotspots for connectivity? (Choose all that apply.)

A. All wireless connections must use PEAP.

B. All wireless connections must use AES.

C. All wireless connections must use a VPN.

D. All wireless connections must use a personal firewall.

E. All wireless connections must use antivirus software.

5. As the head of network security for your organization, you discover an unauthorized access point plugged into your network. Upon investigation, the person who placed the rogue AP on your network is determined to be one of your own users, not an attacker. You wish to proceed with appropriate disciplinary measures but are not allowed to do so by the Human Resources department. What is the most likely reason that the HR staff would not allow disciplinary measures to be taken?

A. There is no written policy preventing users from adding their own APs to the network.

B. The user who placed the AP is a member of management.

C. The user who placed the AP is a member of the union.

D. You are not the user’s direct supervisor and cannot discipline the user.

E. No data was lost or altered as a result of the rogue device placement.

6. You have been working with the network staff to expand the wireless coverage within your customer’s building. Halfway through the project you are asked by a member of management to stop and leave the premises. Which step in WLAN deployment did you most likely not take prior to beginning the WLAN expansion?

A. Obtaining a Scope of Work (SOW) agreement

B. Signing a mutual nondisclosure agreement (NDA)

C. Reviewing written corporate security policies

D. Requesting that a facility escort be present

7. When deploying a corporate 802.11 WLAN, what password-related items should always be included in a security policy? (Choose all that apply.)

A. The password policy should mandate a procedure on how passphrases are created for handheld devices that use WPA2-Personal.

B. End-user WPA2-Enterprise passwords should contain numbers, special characters, and upper- and lowercase letters.

C. Client-side certificates should always be used instead of passwords when securing a WLAN.

D. Machine authentication should always be mandated.

8. When developing a security policy, it is important to include many influences such as internal requirements, governmental regulations, and industry standards. When is it allowable not to include a specific external influence in your policy development?

A. When there is little to no chance of being audited for compliance

B. When your organization is not part of the applicable audience of the external policy influence

C. When implementing wireless devices without the knowledge of the governing body that developed the external policy

D. When adherence to the external regulation or standard is cost prohibitive

9. Over the years, your company has deployed various wireless devices throughout its network. Many of these devices have been in place for quite some time and can only be configured for secure transmissions using WEP. What can you do to improve network security with the least disruption of service?

A. Create a new security policy requiring WPA2 to be used.

B. Modify the existing policy requiring WPA2 to be used.

C. Update the firmware on legacy devices to support WPA2.

D. Replace legacy hardware with new devices that support WPA2.

10. After consulting your written security policy, to meet the new demands of an industry standard with which your organization must be compliant, an administrator logs into your WLAN controller and changes the authentication and encryption configurations on all your APs. The help desk becomes overwhelmed with calls from angry users stating that they can no longer access the network. One by one, the users are reconfigured to reconnect to the network, causing significant loss of time. Which portion of a well-written security policy is most likely missing from your company’s wireless security policy that caused this problem?

A. External influence compliance

B. Authentication requirements

C. Encryption compliance

D. Change control process

E. User notification process

11. Your network just passed an external compliance audit. However, the same day it passed the audit there was an intrusion that compromised your company’s private data. Your staff conducted an internal audit immediately after the intrusion was detected and found that your network is still compliant. The security audit files indicate that the network was compliant during the compromise as well. What is the most likely reason that this compromise was possible on your compliant network?

A. The auditor was indeed the attacker.

B. The attacker was a network administrator.

C. Being compliant is not the same as being secure.

D. Your network is not the applicable audience for this compliance.

12. One of the first things you should do when creating a wireless security policy is to conduct an impact analysis to assist you in determining the level of acceptable risk. What should be included in your impact analysis? (Choose all that apply.)

A. Direct costs of compromise

B. Indirect cost of compromise

C. Legal implications

D. Plausible deniability

E. Implementation costs

13. You have been hired to conduct a vulnerability assessment for a chipset manufacturing company. As you conduct the physical inspection of the WLAN devices, you notice that some of their APs are in locked enclosures and others are not. Before you report the unlocked APs as being vulnerable, what should you do first?

A. Determine if the locked and unlocked APs are on the same network.

B. Press the reset button on the unlocked APs to prove their vulnerability.

C. Open the locked enclosures to make sure APs are in them.

D. Verify the physical protection requirements within the written WLAN security policy.

14. While conducting a routine security analysis of your company’s network, you discover an unauthorized access point installed on the network under the vice president’s desk. What should you do in dealing with the rogue device since the vice president is likely to have placed the device there to provide coverage in the office for her own wireless devices?

A. Remove the device and take it to the IT office for forensics.

B. Unplug the device from the network but leave it in place.

C. Follow the procedures for rogue device management in company policy.

D. Ask the vice president what she would like done with the device.

15. Although your organization’s written policy and many external policy influences may require only periodic scanning for rogue devices, you are trying to make a case for deploying a WIPS. What are some of the benefits of using a WIPS to achieve policy compliance that make it more desirable than using periodic handheld or laptop-based scanning solutions? (Choose all that apply.)

A. WIPSs are less expensive and easier to implement.

B. WIPSs can provide 24-hour scanning and protection.

C. WIPSs are a more scalable solution for security.

D. WIPSs can correlate across multiple locations.

E. WIPSs can provide both compliance and security.

16. Your WIPS has detected several ad hoc devices within your building. After performing location tracking in the WIPS on these devices, you and your staff physically locate them. All of the ad hoc devices detected and found have turned out to be new printers that shipped with their wireless cards enabled for ad hoc wireless networking. Ad hoc wireless networking is specifically disallowed in written security policy. Which section of your security policy should be updated to reduce the likelihood of this happening again?

A. Printing policies

B. Deployment policies

C. Purchasing policies

D. Rogue mitigation policy

17. To provide temporary access to the Internet for a group of customers visiting your corporate headquarters, an administrator has installed an access point in your boardroom. Worried about unauthorized access, the administrator has set up the AP to use WPA2 with a very long and complex key along with AES encryption. Your WIPS sees this AP as a rogue and begins to contain it using port suppression and wireless rogue containment procedures. Your visiting customers are not unable to reach the Internet as desired. What part of your security policy may need to be updated to avoid this problem in the future?

A. WIPS usage

B. Rogue containment

C. Rogue definitions

D. Secret key length

E. Guest access

18. Your WIDS detected a rogue AP and sent an email alert to an administrator in the same building in which the rogue was detected. The administrator reads the email and does not respond to the alarm, but rather waits until after lunch and then calls you for direction. This delay has allowed the device to be on the network for over an hour and placed the organization’s private information at risk. What is the most likely reason the administrator took no action?

A. The WIDS detected the rogue, and no further action was required.

B. You are the only person who knows how to deal with rogue APs.

C. The security policy lacks response procedures.

D. Only a properly configured WIPS can mitigate a rogue AP.

19. A very well-written wireless security policy is in place within your organization. However, you still find rogue devices, poorly configured APs, users who are wired leaving their wireless cards enabled, and ad hoc networks throughout your building—all of which are against policy. Policy requires that such events are remediated and documented as they occur. Your WIPS has been configured to assist you in meeting this requirement and is doing so. The only people allowed in your building are your own employees. You are not under an attack but still keep finding the same problems daily. Which portion of good security policy is most likely lacking that has led to this problem?

A. Impact analysis

B. Management approval

C. User training

D. Documentation

20. An employee has installed his own AP on your network. Each day when he leaves, he unplugs the AP and plugs it back in the morning. He has not implemented any security on the AP. After months of being on the network, this “rogue” AP finally leads to a compromise of corporate secrets. Corporate security policy prohibits the installation of APs without approval. What other requirement(s) should be added to the security policy that could have prevented this compromise? (Choose all that apply.)

A. Monitoring for rogue devices

B. Rogue device remediation

C. User training

D. Policy enforcement procedures