COMMERCIAL SOLUTIONS for CLASSIFIED 

(CSfC)

Wireless Intrusion Detection System/Wireless 

Intrusion Prevention System (WIDS/WIPS) 

Annex 2.0.0

Version 2.0.0

5 March 2024
 

i

CHANGE HISTORY

Title Version Date Change Summary

Commercial Solutions for Classified (CSfC) 

Wireless Intrusion Detection System 

(WIDS)/ Wireless Intrusion Prevention 

System (WIPS)

2.0.0 5 March

2024

 Updated all Diagrams

 Added additional detail on 

exporting WIDS data to 

SIEMs

 Added Wi-Fi 6E monitoring 

requirements

 Expanded extended 

detection section to include 

Cellular detection

 Expanded extended 

detection section to include 

Bluetooth detection

Commercial Solutions for Classified (CSfC) 

Wireless Intrusion Detection System 

(WIDS)/ Wireless Intrusion Prevention 

System (WIPS)

1.0 February 

15, 2021

 Release of WIDS/WIPS 

Annex. 
 

ii

Table of Contents

1 Introduction ..........................................................................................................................................1

2 Purpose and Use ...................................................................................................................................1

3 Legal Disclaimer ....................................................................................................................................2

4 Overview ...............................................................................................................................................2

5 Deployment Architecture .....................................................................................................................3

5.1 WIDS/WIPS Deployments.............................................................................................................4

5.1.1 Integrated WIDS/WIPS Deployments ...................................................................................4

5.1.2 Overlay WIDS/WIPS Deployments........................................................................................5

5.1.3 WIDS/WIPS Sensor Deployments .........................................................................................7

5.2 WIDS/WIPS Security......................................................................................................................8

5.3 Continuous Monitoring...............................................................................................................10

6 Wireless Intrusion Detection System (WIDS)......................................................................................11

6.1 WLAN Detection..........................................................................................................................12

6.1.1 Authorized Wireless Network Devices Detection...............................................................13

6.1.2 Unauthorized Client and Access Points Detection..............................................................14

6.2 Extended Detection ....................................................................................................................15

6.2.1 Cellular Detection ...............................................................................................................16

6.2.2 Wireless Personal Area Network (WPAN) Detection..........................................................16

6.2.3 Bluetooth ............................................................................................................................17

7 Wireless Intrusion Prevention System (WIPS)....................................................................................22

7.1 WIPS Deployment Considerations..............................................................................................23

7.2 WIPS Operations.........................................................................................................................23

7.2.1 WIPS Allowlist .....................................................................................................................24

7.2.2 WIPS Graylist.......................................................................................................................24

7.2.3 WIPS Denylist......................................................................................................................24

8 Information to Support AO.................................................................................................................25

9 Requirements Overview .....................................................................................................................25

9.1 Threshold and Objective Requirements .....................................................................................26

9.2 Requirements Designators..........................................................................................................26

10 WIDS/WIPS Requirements..................................................................................................................27
 

iii

10.1 Wireless Intrusion Detection System (WIDS) General Requirements........................................27

10.2 WLAN Detection Requirements for Wireless Intrusion Detection System (WIDS) ....................28

10.3 Wireless Intrusion Detection Systems (WIDS) Extended Detection Requirements ...................31

10.4 WIDS Cellular Detection (CL) Requirements...............................................................................31

10.5 WIDS Bluetooth Detection (BT) Requirements...........................................................................32

10.6 Wireless Intrusion Prevention System (WIPS) Requirements ....................................................34

10.7 WIDS Auditing Requirements .....................................................................................................34

10.8 Continuous Monitoring Requirements.......................................................................................35

10.9 Testing Requirements.................................................................................................................36

Appendix A. WIDS/WIPS Guidance for Systems Not Integrated with CSfC Data-In-Transit Solutions....38

Overview.................................................................................................................................................38

Deployment Architecture .......................................................................................................................38

WIDS/WIPS Deployments.......................................................................................................................39

Integrated WIDS/WIPS............................................................................................................................39

Overlay WIDS/WIPS ................................................................................................................................40

WIDS/WIPS Security................................................................................................................................40

WIDS/WIPS Continuous Monitoring .......................................................................................................42

Wireless Intrusion Detection & Wireless Intrusion Prevention..............................................................43

Appendix B. Glossary of Terms...................................................................................................................44

Appendix C. Acronyms................................................................................................................................46

Appendix D. References..............................................................................................................................50

Table of Figures

Figure 1. WLAN with Integrated Gray WIDS/WIPS .......................................................................................4

Figure 2: MA with Integrated WIDS/WIPS ....................................................................................................5

Figure 3: Campus WLAN CP Black Integrated WIDS .....................................................................................5

Figure 4: MA with Overlay WIDS/WIPS in Gray Management .....................................................................6

Figure 5: MA with Overlay WIDS/WIPS in Black Management.....................................................................6

Figure 6: WLAN with Overlay WIDS/WIPS in Gray Management.................................................................7
 

iv

Figure 7: WLAN with Integrated WIDS/WIPS Single Network ......................................................................7

Figure 8: WLAN with Separate WIDS/WIPS Networks..................................................................................8

Figure 9: WIDS/WIPS Components...............................................................................................................9

Figure 10: WIDS/WIPS Dataflow Model......................................................................................................11

Figure 11: Unauthorized Wireless Peer-to-Peer Connection .....................................................................13

Figure 12: Unauthorized Wireless AP .........................................................................................................14

Figure 13: Unauthorized Wired AP .............................................................................................................15

Figure 14: Integrated WIDS/WIPS...............................................................................................................39

Figure 15: Overlay WIDS/WIPS ...................................................................................................................40

Figure 16: WIDS Components.....................................................................................................................41

Figure 17: WIDS/WIPS Remote Systems.....................................................................................................42

List of Tables

Table 1. 802.11 Monitoring Protocol..........................................................................................................12

Table 2. Bluetooth MAC Address Types......................................................................................................18

Table 3. Bluetooth Connection Mode........................................................................................................19

Table 4. Requirement Digraphs ..................................................................................................................26

Table 5. WIDS General Requirements (GR).................................................................................................27

Table 6. WLAN (WL) Detection Requirements for WIDS ............................................................................28

Table 7. WIDS Extended Detection (ED) Requirements..............................................................................31

Table 8. WIDS Cellular (CL) Requirements..................................................................................................31

Table 9. WIDS Bluetooth (BT) Requirements..............................................................................................32

Table 10. WIPS Requirements.....................................................................................................................34

Table 11. WIDS Auditing (AU) Requirements..............................................................................................35

Table 12. Continuous Monitoring (CM) Requirements...............................................................................36

Table 13. Testing Requirements .................................................................................................................37
 

1

1 INTRODUCTION

The Commercial Solutions for Classified (CSfC) program within the National Security Agency (NSA) 

Cybersecurity Directorate (CSD) uses a series of Capability Packages (CPs) to provide configurations that 

allow customers to independently implement secure solutions using layered Commercial Off-the-Shelf 

(COTS) products. The CPs are vendor-agnostic and provide high-level security and configuration 

guidance for customers and/or integrators.

CSD is delivering the Wireless Intrusion Detection System (WIDS)/Wireless Intrusion Prevention System 

(WIPS) Annex to meet the demand for monitoring and protection of wireless 802.11 End User Devices 

(EUD) (e.g., tablets, smartphones, and laptop computers) accessing secure enterprise services over a 

campus wireless network or authorized wireless deployment. In addition to the WIDS/WIPS Annex 

requirements for CSfC cryptographic solutions, CSfC provides additional guidance for U.S. Government 

customers to deploy WIDS/WIPS solutions for monitoring controlled spaces, even in the absence of a 

CSfC cryptographic solution (See Appendix A). Cryptographic algorithms, known as Commercial National 

Security Algorithms (CNSA), are used to protect classified data using products in a dual layered 

approach. This Annex builds on lessons learned from three proof-of-concept demonstrations, 

implemented through layered use of COTS products for the protection of classified information. 

2 PURPOSE AND USE 

This Annex provides reference architecture and corresponding configuration information that allows 

customers to select COTS products from the CSfC Components List to develop a WIDS/WIPS solution and 

then properly configure those products to achieve a level of assurance sufficient for a solution used to 

protect classified Data-in-Transit (DIT). Throughout this document, requirements imposed on the 

WIDS/WIPS implementation are identified by a label consisting of the prefix “WIDS,” a two-letter 

category, and a sequence number (e.g., WIDS-GR-11). To successfully implement a solution based on 

this Annex, all Threshold (T) requirements, or the corresponding Objective (O) requirements, must be 

implemented as described in Section 9.1.

Customers who want to use this Annex must register their solution with NSA. Additional information 

about the CSfC process is available on the CSfC web page (

https://www.nsa.gov/Resources/Commercial-Solutions-for-Classified-Program/Solution-Registration/). 

Customers using the guidance presented in Appendix A for deployment of a WIDS/WIPS solution in the 

absence of CSfC cryptographic solution are not required to register their solution with the NSA.

The WIDS/WIPS Annex Version 2.0.0 will be reviewed twice a year to ensure that the defined capabilities 

and other instructions still provide the security services and robustness required to account for 

technology development, new security issues, and new use cases. Solutions designed using this Annex 

must be registered with NSA/CSD. Once registered, a signed CSD Approval Letter will be sent validating 

that the WIDS/WIPS solution is registered as a CSfC solution validated to meet the requirements of the 

latest WIDS/WIPS Annex and is approved to protect classified information. Any solution designed 

according to this Annex may be used for one year and must then be revalidated against the most current 

published version of this Annex. Top Secret Solutions will be considered on a case-by-case 

basis. Customers are encouraged to engage their Client Advocate or the CSfC Program Management 
 

2

Office team early in the process to ensure the solutions are properly scoped, vetted, and that the 

customers have an understanding of risks and available mitigations.

Please provide comments on usability, applicability, and/or shortcomings to your NSA/CSS Client 

Advocate and the WIDS/WIPS Annex maintenance team at CSFC_WIDS_team@nsa.gov.

CNSS Policy No. 15, National Information Assurance Policy on the Use of Public Standards for the Secure 

Sharing of Information among National Security Systems (NSS), identifies public algorithms to protect 

information within NSS. Specifically, the following algorithms will be required to protect all NSS up to 

Top Secret:

 AES 256 (confidentiality)

 RSA 3072 or ECDSA P-384 (digital signature and authentication)

 RSA 3072, DH 3072 or ECDH P-384 (key exchange)

 SHA-384 or SHA-512 (hashing and integrity)

WIDS/WIPS solutions must comply with the Committee on National Security Systems (CNSS) policies and 

instructions. Any conflicts identified between this Annex and NSS or local policy should be provided to 

the WIDS/WIPS Maintenance team. If a conflict arises between NSS, local policy, and this Annex, NSS 

and/or local policy should be followed until a time when the WIDS/WIPS Maintenance team rectifies the 

conflict.

3 LEGAL DISCLAIMER

This Annex is provided “as is.” Any express or implied warranties, including but not limited to, the 

implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event 

shall the United States Government be liable for any direct, indirect, incidental, special, exemplary or 

consequential damages (including, but not limited to, procurement of substitute goods or services, loss 

of use, data, or profits, or business interruption) however caused and on any theory of liability, whether 

in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of 

this Annex, even if advised of the possibility of such damage.

The user of this Annex agrees to hold harmless and indemnify the United States Government, its agents 

and employees from every claim or liability (whether in tort or in contract), including attorney’s fees, 

court costs, and expenses, arising in direct consequence of Recipient’s use of the item, including, but not 

limited to, claims or liabilities made for injury to or death of personnel of User or third parties, damage 

to or destruction of property of User or third parties, and infringement or other violations of intellectual 

property or technical data rights.

Nothing in this Annex is intended to constitute an endorsement, explicit or implied, by the U.S. 

Government of any particular manufacturer’s product or service. 

4 OVERVIEW

A WIDS consists of sensors (preferably dedicated) and a central controller working together to provide 

24/7 monitoring to detect, identify, and geo-locate WLAN devices within the controlled space. A WIDS is 
 

3

vital for the security of a CSfC WLAN Access System deployed within a controlled space. A WIDS may be 

used to monitor a controlled space without a CSfC WLAN Access System, this case is outside the scope of 

the CSfC guidance (for additional guidance see Appendix A). The WIDS may be capable of detecting or 

monitoring traffic of additional protocols other than 802.11 WLAN such as 802.15.1 and 802.15.4 based 

protocols, which enhances the security of the controlled space. However, a WIDS is not required to 

monitor additional protocols outside of 802.11 when supporting a WLAN Access Solution. A WIDS 

monitors all 802.11 WLAN traffic emanating from and traversing the controlled space, thus inadvertent 

collection of any 802.11 signals is possible when operating a WIDS. 

A WIPS consists of sensors (preferably dedicated), and a central controller working together to provide 

24/7 active defense of an authorized wireless network by preventing unauthorized connection. A WIDS 

may have the capability of a WIPS or a separate WIPS can be deployed if the chosen WIDS does not have 

the WIPS capability. Currently, a WIPS is an optional capability that may be deployed with a CSfC 

solution at the discretion of the Authorizing Official (AO). A WIPS has the capability to actively protect a 

WLAN by restricting unauthorized WLAN devices from connecting to authorized WLAN devices within 

controlled spaces and defending authorized WLAN networks from attempted attacks with the goal of 

disrupting, degrading or connecting to an authorized WLAN network. WIPSs are capable of causing 

Distributed Denial-of-Service (DDoS) against 802.11 clients within their controlled space. The capabilities 

of both WIDS and the WIPS must be considered by the AO when deploying WIPS. For defensive 

purposes, the AO should seek additional guidance from their relevant decision making bodies regarding 

inadvertent collection of signals and potential DDoS of wireless clients within their controlled space 

when deploying a WIPS solution.

A CSfC solution requires a WIDS only if there is a static WLAN Access System within the CSfC solution 

such as within the Campus WLAN CP or the Mobile Access (MA) CP using the government private 

wireless use case. Deploying a WIDS/WIPS within a CSfC solution requires that the WIDS/WIPS be 

selected from the CSfC Components List and must be configured to use the National Information 

Assurance Partnership (NIAP) - evaluated configuration. A WIDS/WIPS within a CSfC solution may be 

deployed in several different configurations, contingent on the CSfC deployment architecture, type of 

WIDS/WIPS deployed and AO decision. These configurations include being integrated into the WLAN 

Access System and Overlay deployments for the WIDS/WIPS.

5 DEPLOYMENT ARCHITECTURE

A WIDS is required if a WLAN Access System is used within the CSfC solution, either in accordance with 

(IAW) the Campus WLAN CP or a Mobile Access using the Government Private Wireless use case within a 

controlled space. The WIDS/WIPS should be selected from the CSfC Components List and must be 

configured to use the NIAP-evaluated configuration. A long-term (over 3 months) deployment of a 

Campus WLAN solution will always require a WIDS to monitor its WLAN Access System and clients as 

part of its Continuous Monitoring (CM) solution. An MA solution only requires a WIDS if it is a long-term 

(over 3 months) static deployment which uses a WLAN Access System within a controlled space to 

access its Outer Encryption Components IAW MA CP’s government private wireless use case. For more 

information and guidance on the deployment of a Campus WLAN solution or Mobile Access solution, see 

the relevant CPs located on the CSfC website at https://www.nsa.gov/Resources/Commercial-Solutionsfor-Classified-Program/Capability-Packages/).
 

4

5.1 WIDS/WIPS DEPLOYMENTS

A WIDS/WIPS deployed to support a CSfC solution can be arranged in multiple configurations which 

include a WIDS/WIPS integrated into WLAN Access Systems, an Overlay WIDS/WIPS within a CSfC 

network, or an Overlay WIDS/WIPS outside of the CSfC network. When a WIDS/WIPS is integrated into a 

WLAN Access System, the WLAN Access System must have the capability to act as an authorized 

WIDS/WIPS. This integrated solution has the benefit of reducing the number of required components 

and complexity of the WIDS/WIPS. If the WLAN Access System cannot act as a WIDS/WIPS whether 

technically or administratively due to solution architecture decisions, an overlay WIDS/WIPS must be 

used to monitor the WLAN Access System. WIDS/WIPS sensors can be deployed on the same network as 

the WLAN Access System’s Access Points (APs) if the WIDS/WIPS is integrated into the WLAN Access 

System. If the WIDS/WIPS is an Overlay then the WIDS/WIPS sensors must be on a separate network.

5.1.1 INTEGRATED WIDS/WIPS DEPLOYMENTS

Figure 1 shows a possible configuration where the WIDS/WIPS is deployed integrated into the WLAN 

Access System within the Campus WLAN CP. This deployment includes the WIDS as part of the WLAN 

Access System and would be controlled from the Gray Management Network. Both the WLAN APs and 

WIDS Sensors are part of the Gray Network and must be protected as such.

Figure 1. WLAN with Integrated Gray WIDS/WIPS

Figure 2 shows a possible configuration where the WIDS is integrated into the WLAN Access System of 

the MA CP. This configuration depicts the WIDS/WIPS as a function of the WLAN Access system while 

being controlled from the Black Management Network. See Section 5.1.3 for information on the 

deployment of WIDS/WIPS sensors.
 

5

Figure 2: MA with Integrated WIDS/WIPS

Vendors implement encryption differently between the WLAN Client and the WLAN Controller which 

impacts the way WIDS/WIPS sensors must be handled. One implementation of encryption is where the 

WLAN AP passes all outer encryption layer traffic to the WLAN Controller for decryption. In the Campus 

WLAN CP, the implementation of the WLAN APs are considered to be part of the Black Network and 

must be protected accordingly. As shown in Figure 3, when these WLAN APs are used as WIDS sensors, 

they too are considered part of the Black Network. The second type of encryption is when the WLAN AP 

terminates the outer encryption layer. In this case, the WLAN APs are considered to be part of the Gray 

Network and must be protected accordingly. This is true even if there is a layer of encryption between 

the WLAN AP and Controller. The determining factor depends where the WLAN Client’s Outer 

encryption terminates. This implementation means that the WLAN AP acting as a WIDS/WIPS sensor, is 

treated as part of the Gray Network (See Figure 1).

Figure 3: Campus WLAN CP Black Integrated WIDS

5.1.2 OVERLAY WIDS/WIPS DEPLOYMENTS

A WIDS/WIPS may also be deployed as an Overlay WIDS/WIPS that is not integrated into the WLAN 

Access System within a Campus WLAN or MA CP. This configuration may be required if the WLAN Access 

System does not have a WIDS capability or the chosen WIDS/WIPS is not part of a WLAN Access System. 

In this case, the WIDS/WIPS may reside in either the Black Management, Gray Management, or an 
 

6

independent network outside of the CSfC solution. Additionally, any time an Overlay WIDS/WIPS is used, 

the WIDS/WIPS controller or controllers must not be directly connected to the Management Network 

but instead, must go through a firewall for inspection of allowed traffic and/or blocking of disallowed 

traffic. When deployed within the Black or Gray Management Network a WIDS/WIPS controller must 

traverse the associated firewall to access the management network. Figure 4Figure 4 shows an MA 

deployment with an Overlay WIDS/WIPS in the Gray Management and all components of the 

WIDS/WIPS would reside and be controlled from Gray Management. The WIDS/WIPS in this scenario 

cannot correlate data with the WLAN Access System, also the WIDS/WIPS Sensors are all considered to 

be part of the Gray Management Network which will greatly increase both the size and surface of the 

Gray Management Network. This configuration has the benefit of leveraging the Gray Management 

services that are already being used and can leverage additional capabilities such as Enterprise Gray (see 

Section 5.2).

Figure 4: MA with Overlay WIDS/WIPS in Gray Management

Figure 5 shows an MA solution with an Overlay WIDS/WIPS that is part of the Black Management 

Network. The WIDS/WIPS in this scenario can correlate data with the WLAN Access System. Also, the 

WIDS/WIPS requires the Black Management Network support the WLAN Access System and the 

WIDS/WIPS. In this configuration, all the WIDS/WIPS sensors are part of the Black Management Network 

and must be protected as such.

Figure 5: MA with Overlay WIDS/WIPS in Black Management
 

7

When a WIDS/WIPS is used within the Campus WLAN CP, it can be deployed within the Gray 

Management Network or outside the CSfC solution. Figure 6 shows a WIDS/WIPS controlled and 

managed within the Gray Management Network. This configuration is similar to the configuration 

shown in Figure 4 with MA and has nearly an identical capability and use except that since the WLAN 

Access System and WIDS/WIPS are collocated on the same network their data can be correlated 

between each other. 

Figure 6: WLAN with Overlay WIDS/WIPS in Gray Management

5.1.3 WIDS/WIPS SENSOR DEPLOYMENTS

The deployment of the WIDS/WIPS sensors impacts functionality, security and complexity of the 

networks. The Overlay WIDS/WIPS and the integrated WIDS/WIPS both have unique concerns which 

must be addressed when deploying the WIDS/WIPS sensors. 

Figure 7: WLAN with Integrated WIDS/WIPS Single Network

As shown in Figure 7, it is preferable to have the WIDS/WIPS sensors on their own network. However, 

sharing the same network for WIDS/WIPS sensors and WLAN Access System is allowable for both 

Campus WLAN and MA solutions. Additional measures, such as using a Virtual Local Area Networks 

(VLANs), should be taken to segregate the WIDS/WIPS sensors and WLAN APs.
 

8

As shown in Figure 8, when using an Overlay WIDS/WIPS, it is required that the WIDS/WIPS sensors be 

deployed on a separate network from the WLAN APs. This ensures that the WIDS/WIPS sensors and 

controllers do not pose a risk to the network, but at the cost of requiring an entire secondary network 

for both the APs and WIDS/WIPS sensors monitoring the network. In this case, the WIDS/WIPS can be 

deployed in the Black Management Network, Gray Management Network, or outside of the CSfC 

solution, but it is recommended the WIDS/WIPS be co-located with the WLAN Access System so that the 

system can be used together to better correlate data between the two. The WIDS/WIPS controller and 

sensors would be part of the network they are attached to and in Figure 8’s example, the WIDS/WIPS 

sensors and controller would be part of the Gray Management Network.

Figure 8: WLAN with Overlay WIDS/WIPS Networks

5.2 WIDS/WIPS SECURITY

Security of a deployed WIDS/WIPS is required for management, control, and network functionality of 

the WIDS/WIPS components. The components that make up a WIDS/WIPS include the WIDS/WIPS 

sensor, WIDS/WIPS controller, workstation, as well as other supporting components. Communications 

between the WIDS/WIPS sensors and the WIDS/WIPS controller must use secure communication (e.g., 

SSHv2, Internet Protocol Security (IPsec), Direct Transport Layer Security (DTLS), or TLS (1.2 or 

1.3)/Hypertext Transfer Protocol Secure (HTTPS)) and the communication between the WIDS/WIPS 

controller, workstation and other supporting components must also use secure communication (e.g., 

SSHv2, IPsec, DTLS, or TLS (1.2 or 1.3)/HTTPS). All forms of unsecure management, control and sending 

data must be disabled for each WIDS/WIPS Component. 

As shown in Figure 9, a firewall must be in place to block all communications between the WIDS 

controller and relevant management network, which do not facilitate the operation of the WIDS/WIPS 

Controller enterprise services. The firewall protects both the management network and the WIDS/WIPS 

controller by monitoring and controlling all traffic to and from the WIDS/WIPS controller. The firewall 

must filter all unnecessary protocols from reaching the WIDS/WIPS controller. The protocols that are 

exempt from being filtered include, but are not limited to, TLS (1.2 or 1.3), SSHv2, IPsec, Network Time 

Protocol (NTP), Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and system 

log. In addition to the firewall, the WIDS/WIPS controller must be secured to minimize the potential risk 

to the solution. First, there must be no capability to manage or control the WIDS/WIPS controller from 

the interfaces that connect to the sensors. Second, there must not be any routing through the 
 

9

WIDS/WIPS controller between the sensors and the Gray Management Network. Finally, the WIDS/WIPS 

controller must have a management interface used to control, manage, and access Gray Management 

resources. 

Figure 9: WIDS/WIPS Components

A centralized authentication service is a fundamental base of any network and WIDS/WIPS, even if it 

does support local account administration. The system must still use an external authentication service 

such as Remote Authentication Dial in User Service (RADIUS), Active Directory, or Kerberos. The 

WIDS/WIPS can leverage the same authentication system that is being used by its relevant Management 

Network. All WIDS/WIPS components must be integrated into the network’s existing CM capability such 

as an Intrusion Detection System (IDS), or Security Information and Event Management (SIEM) thus all 

WIDS/WIPS components must send all system logs to the solution’s CM capability. 

If the WIDS/WIPS solution is deployed within the Gray Management Network, it may leverage the 

capabilities found within the CSfC Enterprise Gray Implementation Requirements Annex to allow for 

secured communications between WIDS/WIPS solutions, sharing of centralized resources, and remote 

management of the WIDS/WIPS solution. This capability requires that two or more Gray Management 

Networks be connected using either an additional Gray Encryption Component or capable firewall. For 

more information about the Enterprise Gray capabilities or requirements see the CSfC Enterprise Gray 

Implementation Requirements Annex.

The system logs that are collected from the WIDS/WIPS component must log any login event and must 

include any failed login attempts, successful logins, and administrator logins. The system logs must also 

include any changes to the authentication system that includes creation, deletion, or modification of 

user accounts and any changes to groups or group membership. The WIDS/WIPS components must log 

any attempt for escalation of privileges. The WIDS/WIPS components must log when there is any 

configuration changes and whether they are successful. The WIDS/WIPS controller must also log the 
 

10

status of the WIDS/WIPS sensors and must include when a new sensor is connected, when a sensor is 

unreachable, and when any sensor has an error status. These system logs monitor the WIDS/WIPS for 

any possible errors and potential security issues and should be used with additional guidance required 

for CM within the solution.

5.3 CONTINUOUS MONITORING 

When deploying a WIDS/WIPS, logging and notification of system and detection events are required for 

the proper operations and to maintain security of the controlled space. The WIDS/WIPS must have the 

capability to create notifications and alerts of events that it detects. The AO may deem it necessary that 

the alert and notification capabilities of the WIDS/WIPS meet their needs for monitoring. The AO 

alternatively can integrate the WIDS/WIPS into a CM capability, such as a SIEM or IDS, to notify and alert 

security administrators of events detected by the WIDS/WIPS. In this case, WIDS/WIPS must be 

integrated into a CM capability and either send its notifications to a CM capability or send its raw data to 

a CM capability and have it alert on events. The AO and local policy dictate how often these events, logs, 

and notifications must be reviewed. It is recommended that the time frame between reviews be no 

longer than one week.

Either the CM capability, or the WIDS/WIPS interface must filter on notifications based on types, 

severity and number of notifications received. For additional information on CM within CSfC, see the 

CSfC Continuous Monitoring Annex. As shown in Figure 10, a WIDS/WIPS must be integrated into the 

solution’s CM capability in relation to data processing, alerting, notification and retention. Even if the 

WIDS/WIPS is used for notifications, all logs from the WIDS/WIPS must be sent to the CM solution for 

data retention or there must be another system that retains data for the given amount of time. The AO 

and relevant policy will determine the retention time of this data. It is recommended to keep this data a 

minimum of one year.

The WIDS/WIPS captures a large amount of information to monitor the area the WIDS/WIPS operates. 

This data is normally reduced to alerts and notifications to be further analyzed by the personnel 

monitoring and operating the WIDS/WIPS. This data captured by the WIDS/WIPS should be offloaded to 

another system for long term storage and retention. Additionally, this data if moved onto a large-scale 

data analysis system such as a SIEM then can be used to create more advanced analytics and used to 

meet monitoring requirements for which the WIDS/WIPS may not be able to meet.

The interface between the WIDS/WIPS Controller and the Firewall such as the Gray Management 

Firewall must be monitored as part of the Management Network. All MP6 monitoring requirements 

from the CSfC Continuous Monitoring Annex, must be applied to a Gray WIDS/WIPS connection. For a 

WIDS/WIPS deployed within the Black Network, or a stand-alone network outside of the CSfC network 

the following must be monitored on the given interface. 

The WIDS/WIPS must log and forward to a CM capability the following: any user events, failed login 

attempt, whenever a new user is created, whenever a user is added to a group, any change is made to 

group privilege, any user account attribute is changed, and when any authentication rule is created or 

modified. The firewall providing network access must log any attempts to conduct a network scan from 

the WIDS/WIPS or any attempts for the network to scan the WIDS/WIPS solution. Additionally, the 

firewall must log on any unusual traffic between the WIDS/WIPS controller and the management 

network. This unusual traffic may include, but is not limited to, attempting to use unauthorized ports or 
 

11

protocols, attempting to contact an IP address outside of the management network, or a large amount 

of traffic traversing the firewall. The firewall and controller must log if any protocol outside SSH, ESP or 

TLS is being used to log into the WIDS/WIPS. The firewall must log any DNS queries from the WIDS/WIPS 

controller to a domain outside of its management network. The WIDS/WIPS Controller needs to log any 

configuration changes made to it, or its sensors to the networks CM capability. Finally, the WIDS/WIPS 

controller must have a reoccurring vulnerability scan conducted on it within a time designated by the AO 

and relevant governing policies.

Figure 10: WIDS/WIPS Dataflow Model

6 WIRELESS INTRUSION DETECTION SYSTEM (WIDS)

A WIDS consists of sensors (preferably dedicated), and a central controller working together to provide 

24/7 monitoring of the 802.11 WLAN spectrum and protocols. The WIDS identifies unauthorized devices 

interfering with authorized devices, identifies authorized devices operating outside the 802.11 protocol, 

configuration parameters, and identifies the physical location of all 802.11 devices within the controlled 

space. The WIDS may be capable of either detecting or monitoring traffic of additional protocols other 

than 802.11 WLAN; which greatly enhances the security of the controlled space, however this is not 

required when supporting a WLAN Access Solution. Additional protocols may include cellular protocols, 

additional 802.11 protocols, 802.15 protocols, other low latency protocols, and other long range 

wireless protocols.

IAW the Campus WLAN CP or the MA CP, a WIDS is required in a CSfC deployment if a static WLAN 

Access System is used within the solution. The WIDS must be selected from the CSfC Components List 

and must be configured to use the NIAP-evaluated configuration. A long-term deployment of a Campus 

WLAN solution will always require a WIDS to monitor its WLAN Access System and clients as part of its 
 

12

CM solution. If the Campus WLAN solution uses another transport method other than 802.11 in the 2.4 

GHz, 5 GHz, or 6 GHz bands, it is recommended that the WIDS is able to monitor the chosen protocol. An 

MA solution only requires a WIDS if it is a long-term deployment using a WLAN Access System within a 

controlled space to access its Outer Encryption Components. For additional guidance on the deployment 

of a Campus WLAN, or MA solution, see the applicable CP.

6.1 WLAN DETECTION

WLAN detection for the WIDS requires monitoring of the 802.11 2.4 GHz, 5 GHz, and 6 GHz bands and 

does not need to include other bands supported within 802.11. If deemed necessary by the AO, the 3.6 

GHz and 60 GHz may be included in the scope of the WIDS system. The WIDS system must monitor 

802.11 channels within the 2.4 GHz, 5 GHz, and 6 GHz bands both inside and outside the local country’s 

regulatory domain. The WIDS system must perform protocol analysis of captured signals to detect 

violations of 802.11 WLAN standards. If a WLAN Access System is monitored, then the WIDS must be 

able to process 802.11 traffic at the same data rate that the WLAN Access System supports. While in the 

controlled space, the WIDS must be able to geo-locate all WLAN emitters within the 802.11 2.4 GHz, 5 

GHz, and 6 GHz bands. A WIDS may additionally have the capability to geo-locate 802.11 devices to a 25 

feet radius.

Table 1. 802.11 Monitoring Protocol

Protocol Frequencies Monitoring

802.11 b/g/n/ax Wi-Fi 2.4 GHz Required

802.11 a/n/ac/ax Wi-Fi 5 GHz Required

802.11 ax Wi-Fi 6E 6 GHz Required

802.11 y 3.6 GHz Optional

802.11 ad/ay 60 GHz Optional

The system must be configured to detect when 802.11 WLAN emitters within the controlled space acts 

maliciously or anomalously. Users must be able to create custom attack signatures to aid in the 

monitoring of the network and controlled space. A WLAN Access System baseline must be created with 

the WIDS and this baseline must be used comparatively to detect anomalies that deviate from the 

created baseline. The events that should be used to detect anomalies and malicious traffic include, but 

not limited to, WLAN bridges, Denial-of-Service (DoS) attacks, and WLAN emitters working outside of 

the local region's legal channels. The Received Signal Strength Indicator (RSSI) calculated at the WIDS 

sensor, must be captured and logged to aid in the geo-location and detection of anomalous traffic within 

the controlled space. If an RSSI is detected that is equal to, or above the local country’s local regulator 

limit, the WIDS must log and create a notification for this event. The system must also detect and log if 

there are DoS attacks being conducted within the operational space, either against the WLAN Access 

System, or other WLAN emitters within that space. These DoS attacks include radio frequency (RF) based 

DoS attacks, deauthentication flooding, and disassociation flooding DoS attacks. 802.11 WLAN bridges 

must also be detected and logged within the controlled space with special emphasis on whether any 

component connected to the WLAN Access System is conducting wireless bridging, as this type of 

connection should never be allowed by a WLAN Access System. Additionally, any action related to 

wireless bridging must be detected such as a device attempting to form a bridge, a single device 
 

13

beaconing for bridges, and two or more devices transmitting bridges data frames. An additional 

capability that the system may have is for the automatic capture of raw data frames triggered when any 

malicious, or anomalous traffic is detected by the WIDS sensor. 

6.1.1 AUTHORIZED WIRELESS NETWORK DEVICES DETECTION

An Allowlist is a list of authorized WLAN devices, which are allowed to, or be a component of, the WLAN 

Access System, and the configuration which they are expected to operate. The authorized wireless 

network devices, include the wireless clients, APs and WIPS devices that are deployed as part of the 

WLAN Access System and must be documented in a Allowlist and included in the WIDS. Additionally, the 

Service Set Identifiers (SSIDs) of the Allowlisted APs, the channels those SSIDs broadcasting, authorized 

authentication method of the authorized network, and the encryption method of the authorized 

network must all be documented in the WIDS. All Allowlisted wireless network devices must have their 

bandwidth usage, connection status, association, number of connected devices, authentication status, 

and time usage monitored and tracked by the WIDS. 

All frames between the authorized APs and authorized clients must be monitored by the WIDS and 

analyzed for any malicious or anomalous traffic. Additionally, the system must monitor whether there 

are any frame types or subtypes going between any authorized wireless network devices and any 

unauthorized devices. The WIDS must log any traffic that is detected between authorized and 

unauthorized devices. If authorized wireless network devices are detected deviating from the 

documented Allowlisted information, such as using an unauthorized channel, broadcasting an 

unauthorized SSID (including hidden SSID), association to an unauthorized SSID, deviating from an 

authorized association method, or not using the authorized encryption method, they must be logged, 

and a notification created of the deviation from normal operation. As shown in Figure 11, a log and 

notification must be made by the system when a peer-to-peer connections, ad-hoc networks or wireless 

bridges are made by any authorized client device to either an authorized or unauthorized client as this 

behavior can circumvent the security of the WLAN Access System and potentially give other devices 

unauthorized access to the network.

Figure 11: Unauthorized Wireless Peer-to-Peer Connection

If the WIDS system is integrated into the WLAN Access System and has visibility into the authorized 

client’s wired interface, then it should have the capability to detect and log if the client is connected to a 

rogue AP and the wired connection is connected to the authorized network. The WIDS must log and 

notify if an authorized wireless network device’s Media Access Control (MAC) is detected and/or geo-
 

14

located in two or more physically distinct places at the same time. This event could indicate that a 

malicious device is attempting to use the MAC address to spoof an authorized device. Depending on the 

configuration of the system, the system must also log when the authorized wireless network device’s 

MAC is detected in more than two locations not at the same time showing it is either moving through 

controlled spaces and/or someone or something is spoofing the MAC address. The WIDS must detect 

and log illegal state transitions, such as a client device transmitting data frames through an AP to a 

network device before being associated and authenticated. 

6.1.2 UNAUTHORIZED CLIENT AND ACCESS POINTS DETECTION

Depending on the environment in which a WIDS is deployed, an unauthorized wireless device can be any 

device detected within the controlled space of the system, or only APs within the controlled space and 

any device attempting to connect to the WLAN Access System. The AO along with other decision-making 

bodies must define what an unauthorized wireless device is within the operational space and develop a 

plan of action on how to respond to unauthorized wireless devices detected by the WIDS. The AO must 

understand, depending on the reaction to unauthenticated wireless devices, that additional man-hours 

may be required to fulfill such a plan of action.

Figure 12: Unauthorized Wireless AP

APs and WLAN clients within the controlled space, that are not part of the Allowlist are considered 

unauthorized devices and must be detected by the WIDS. The AO and other decision-making bodies 

must also consider that wireless devices outside of the controlled space will be detected by the WIDS as 

the signals propagate into the controlled space. The most important detection capability, is if any 

unauthorized device attempts to connect, or is connected to any authorized device. Such an event must 

be detected, logged, and a notification created within the CM solution. All unauthorized wireless 

devices’ status must be monitored in real time and logs of the status must be created. The status 

includes, but not limited to, whether the client is offline, associated, or authentication is pending. 

A difficult task for the WIDS is to detect MAC Spoofing where an unauthorized device spoofs the MAC 

address of an authorized device within the Allowlist in an attempt to circumvent the detection capability 

of the WIDS. MAC Spoofing cannot be counteracted by the WIDS. The best measure against MAC 

Spoofing is the detection of such an attack, the geo-location of the devices performing the attack, and 

long-term behavioral analysis of authorized wireless devices within the controlled space. A simple 

method of detecting such an attack is to track when and where the authorized devices operate within 
 

15

the WIDS controlled space. If an authorized wireless device is detected at the same time at two separate 

locations, then that is an indicator of MAC Spoofing and must be logged and a notification generated. 

Another indication of possible MAC Spoofing is identifying an authorized device within a location it has 

never been detected before. This event must be logged and a notification must be generated. This 

method of identification of a device performing MAC Spoofing requires a high degree of knowledge of 

the authorized clients within the system to be effective and not give high numbers of false positives. 

More advanced SIEM systems with behavior analytics may be useful in the detection of MAC Spoofing 

but require a far more significant investment of time and resources.

Figure 13: Unauthorized Wired AP

A rogue AP is an unauthorized AP that acts maliciously, or anomalously within the controlled space by 

either attempting to spoof an authorized AP, provides an unauthorized network for authorized and 

unauthorized clients, or tries to circumvent the WLAN Access System. A WIDS must have the capability 

to create administrator-defined rogue AP detection classification rules. As seen in Figure 13, a WIDS may 

also have the capability to detect if a rogue AP is connected to the wired network serving out 

unauthorized connections to the WLAN Access System and if detected the WIDS must be logged and a 

notification created.

6.2 EXTENDED DETECTION

A WIDS deployed for CSfC is only required to monitor the WLAN Access System using 802.11 WLAN 

within the 2.4 GHz, 5 GHz, and 6 GHz frequencies. Any additional capability to detect protocols outside 

of the aforementioned frequency bands are an optional capability and not required when a WIDS 

system monitors a controlled space, or monitors a WLAN Access System. This optional functionality can 

be used to further enhance the security posture of the facility and should be considered for deployment 

by the AO. If the WLAN Access System is not using an 802.11 WLAN Access System, and instead using 

another form of transport, then a WIDS is not required but highly recommended and should be used 

when possible. The AO may make the decision to deploy a WIDS capable of monitoring the specific 

WLAN Access System being implemented.

Additionally, the AO may want to have the capability to detect other protocols within a controlled space 

outside of the required 802.11 WLAN standard. In this case the AO may want to deploy a WIDS capable 

of detecting the desired protocols or a secondary WIDS to augment the detection capability. If a 

secondary WIDS is deployed, it must be deployed IAW Section 5.1. These protocols may include, but are 
 

16

not limited to: cellular communications, Wireless Personal Area Network (WPAN) protocols, short range 

high bandwidth protocols and long range low band width protocols. 

6.2.1 CELLULAR DETECTION

Cellular refers to the broadband cellular communication protocols such as Global System for Mobile 

Communication (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution 

(LTE), 5G New Radio (NR) etc., which the physical spectrum that they occupy vary depending on 

technology and country. Cellular is common within consumer communication devices and used for long 

range communications back to a base station. An AO may desire to monitor these devices operating 

within the controlled space monitored by the WIDS. There is a three phased approach for the detection 

of cellular emitters within a controlled space which are: the detection of cellular signals within the 

controlled space, the geo-location of the cellular emitter within the controlled space, and collection of 

the identifiers of the cellular emitter.

There are currently three generations for cellular communications defined by the 3rd Generation 

Partnership Project (3GPP) in common use. These standards are the older 3G generation, the currently 

used 4G generation, and newer 5G generations. Within each generation of cellular communications 

there are separate standards which are different implementations that fall under a generation of cellular 

communications. Examples of this are UMTS being a 3G standard, LTE being a 4G standard, and NR a 5G 

standard. As of the publication of this revision, 3G is in process of being decommissioned within multiple 

counties and is expected to be fully decommissioned in the US by the end of 2022. 4G is the most 

common cellular communication. 5G is the newest cellular communication technology and is still in 

early stages of deployment. 5G is divided into two groups of frequencies: FR1 which are all bands below 

6 GHz and FR2 which are the frequency bands between 24 GHz and 71 GHz referred to as millimeterwave and for practical purposes does not need to be monitored by the WIDS. The simplest and minimal 

form of cellular detection is when a WIDS sensor can detect the presence of cellular signals by 

monitoring the physical energy of the signals within a controlled space along detecting which cellular 

technology these cellular signals are using. An improvement to this detection capability would for the 

WIDS to be able to discretely identify the detected signals into individual cellular emitters to allow for 

the awareness of the number of devices. Additionally, to identify the cellular base stations which these 

devices are connected to. The WIDS should additionally be able to identify the which cellular carrier 

network a cellular emitter is connected to. To greatly enhance the security posture of the controlled 

space, the WIDS could be able to geo-locate the discrete cellular emitters within the controlled space. 

The capability of a WIDS to detect temporary identifiers from cellular emitters allows for the 

identification of the cellular emitters within the controlled space. This phased approach to WIDS cellular 

detection is an optional capability which is not required, but the AO may decide to implement none, 

some, or all these approaches.

6.2.2 WIRELESS PERSONAL AREA NETWORK (WPAN) DETECTION 

WPAN refers to low powered machine-to-machine communications used for control systems within the 

controlled spaces. This detection capability refers to the different wireless technologies used within the 

fields of Internet of Things (IoT), medical devices, Industrial Control Systems, and building automation. 

These protocols can include but are not limited to; Bluetooth, Bluetooth Low Energy (BLE), ZigBee, ZWave, etc. For more information on Bluetooth and BLE see Section 6.2.3. A phased detection approach, 
 

17

similar to the cellular detection capability is recommended for the desired protocols. The AO must 

choose which protocols, if any, that should be monitored and which level of detection is required for the 

chosen protocols. Bluetooth and BLE should be considered by the AO for detection because of both the 

prevalence in Internet of Things (IoT) and standard wireless devices. In addition, the AO should highly 

consider this capability if there is a system within the controlled space operating using a WPAN protocol 

for both situational awareness and defense of that system.

The simplest and minimal form of WPAN detection is when a WIDS sensor can detect the presence of 

WPAN signals by monitoring the physical energy of the signals within a controlled space. An 

improvement over detection of the given protocols would be the ability to discreetly identify different 

WPAN emitters within the controlled space this would greatly enhance the security posture of the 

controlled space. A further step beyond the detection of discrete WPAN emitters would be the ability to 

geo-locate these emitters within the controlled space. Additionally, the WIDS should have the capability 

to capture the hardware addresses that these devices use to communicate, if not the ability to conduct 

network capture of the WPAN protocol itself. This phased approach to WIDS WPAN detection is an

optional capability which is not required but the AO may decide to implement none, some, or all of 

these approaches.

6.2.3 BLUETOOTH

Of all the WPAN protocols, Bluetooth has become the most widely used with most smart phones, 

laptops and peripheral devices having Bluetooth capability. There are two separate Bluetooth protocols 

encompassed by the Bluetooth standard: the original Bluetooth Basic Rate/Enhanced Data Rate 

(BD/EDR) protocol and the newer Bluetooth Low Energy (BLE) protocol. 

Bluetooth BD/EDR, often referred to as Bluetooth Classic, is a low powered wireless communication 

mainly used for wireless audio streaming and data transfer applications. Bluetooth BR/EDR physically 

operates on the 2.4GHz unlicensed industrial, scientific, and medical (ISM) frequency band with 79 

channels and a frequency hopping algorithm to ensure efficient channel use. 

BLE is designed for very low power operation allowing devices to operate for months. BLE offers a 

number of different network topologies including a meshing topology. BLE is commonly used for health 

and fitness device, sensors, proximity sensors and human interface devices.

6.2.3.1 Bluetooth MAC Addresses

Bluetooth has a 48-bit unique identifier, similar to an Ethernet MAC Address. This identifier is a 

Bluetooth MAC Address and is referred to as BD_ADDR within the Bluetooth specification. Bluetooth 

MAC addresses can be divided into two address types which are Public Addresses and Private Addresses.

Public Addresses are globally fixed addresses which must be registered with the Institute of Electrical 

and Electronics Engineers (IEEE) and follow the same guidelines as other MAC Addresses. This MAC 

Address is divided into three parts (see Figure 14) the Non-Significant Address Part (NAP), the Upper 

Address Part (UAP), and Lower Address Part (LAP). The NAP and UAP together make up the 

Organizationally Unique Identifier (OUI) field of the Bluetooth MAC Address. The LAP is assigned by the 

vendor and is used to uniquely identify a Bluetooth device and sent with every frame. The LAP and UAP 

together are referred to as the Significant Address Part (SAP) of the Bluetooth Address.
 

18

Figure 14: Bluetooth MAC Address 

Random Addresses do not have to be registered with the IEEE and are either programmed into the 

device or generated at runtime. There are two subtypes of random addresses which are Random Static 

Addresses and Random Private Addresses. Random Static Addresses are fixed addresses that can either 

be assigned to the device or can be changed during boot time but cannot be changed while running. 

Random Static Addresses are common since they do not require registration with the IEEE. Random 

Private Addresses are used to protect privacy of the device and further can be subdivided into two 

subtypes, Resolvable Random Private Address and Non-Resolvable Random Private Addresses. 

Resolvable Random Private Addresses are random addresses which are recommended to be changed 

every 15 minutes and are resolvable by trusted devices using a shared key with the trusted device. NonResolvable Random Private Address periodically change their addresses but are not resolvable by other 

devices and commonly only used in beaconing.

Table 2. Bluetooth MAC Address Types

Bluetooth Address Type Description 

Public Address IEEE Compliant MAC Address cannot be changed 

for the lifetime of the device

Random Static Address Random MAC Address cannot be changed while 

operating but may be changed during boot

Random Private Resolvable 

Private Address

Random MAC Address changes on average every 

15 minutes can connect to trusted devices using 

shared key

Random Private NonResolvable Static AddressRandom MAC Address changes on average every 

15 minutes cannot be connected to
 

19

The 4 types of Bluetooth MAC Addresses as seen in Table 2 offer different challenges when it comes to 

detecting Bluetooth Devices operating within Bluetooth BR/EDR and Bluetooth Low Energy. Within 

Bluetooth BR/EDR only the last 3 bytes or LAP of the Bluetooth MAC Address are used during normal 

communications and the only time the full MAC Address is visible is when connections are initially 

established. This means that only the LAP will be visible during most communications no matter what 

type of Bluetooth MAC Address was configured. Bluetooth Low Energy on the other hand sends the 

entire MAC Address for all communications however Random Private Resolvable Private Addresses are 

used more commonly with many devices changing their Bluetooth MAC Addresses every 15 minutes. 

6.2.3.2 Bluetooth Connection

Table 3. Bluetooth Connection Mode

Bluetooth Mode Description 

Discoverable Mode The Bluetooth device is discoverable continuously 

or for no specific condition

Non-Discoverable Mode The Bluetooth device will not respond to 

Bluetooth Inquiry procedure

Limited Discoverable Mode The Bluetooth device will only be discoverable 

only for a limited period of time, during temporary 

conditions, or for a specific event

Connectable Mode The Bluetooth device will enter page scan state 

periodically

Non-Connectable Mode The Bluetooth device will enter page scan state 

thus not being able to respond to page

Pairable Mode The Bluetooth device accepts Bluetooth pairing 

requests 

Non-pairable Mode The Bluetooth device does not accept Bluetooth 

pairing requests

Bluetooth BR/EDR uses an Inquiry procedure to discover nearby devices which are in a mode known as 

discoverable mode. The Inquiry procedure starts with an Inquiry request and discoverable devices will 

respond with an inquiry response. The Inquiry procedure is done on a range of channels and the inquirer 

uses a dedicated Bluetooth MAC Address to conduct the inquiry. The Inquiry procedure exchanges 

information such as local name, supported services, and Bluetooth MAC Address of the responding 

device. Most smart devices only initiate Inquiries when searching for a device to connect to and operate 

in Limited Discoverable Mode, being only discoverable when searching for other devices to connect to. 

Service Discovery Protocol (SDP) is the next step after Inquiry where a Bluetooth device queries another 

device for supported services and additional information about the capabilities of the Bluetooth services 

required for Bluetooth connection.

Bluetooth BR/EDR uses the Paging procedure to complete initial connection between two devices. The 

Paging procedure begins with a device initiating the Paging procedure to another device which is in the 

connectable state. The Paging procedure requires the paging device to have the Bluetooth MAC Address 

of the connectable device in its pages which was stored either during a preceding Inquiry procedure or if 

the two devices had previously formed a connection.
 

20

Bluetooth BR/EDR forms networks called piconets. Within these piconets there are two types of devices 

a single Central device and one or more Peripheral device. A piconet may have up to 8 devices actively 

participating in the network with a single Central device and a maximum of seven (7) active Peripheral 

devices. The devices within a piconet can switch roles, by agreement, and a Peripheral device can become 

the Central Device. The Central device has the responsibility for establishing connections, being the central 

point of communication and setting communication timing. A device may be a Peripheral device of one 

piconet and a Control or a Peripheral device of another piconet forming what is referred to as a scatternet. 

See Figure 15 for a network diagram of multiple Bluetooth BR/EDR piconets forming a scatternet.

Figure 15: Bluetooth Scatternet

BLE devices do not conduct inquiry scans to discover devices within range; instead all BLE devices send 

out advertisement packets on the designated advertisement channels. These advertisements can be 
 

21

used to establish initial connections or used to broadcast data to devices listening to the advertising 

channel. BLE Devices may be both connected to other BLE devices and send advertisements. Devices 

searching for advertisements are known as scanning devices. A scanning device will monitor for 

advertisements on the advertisement channels and may request data from these devices. Similar to 

advertisement mode, devices in scanning mode may both scan and be connected to devices at the same 

time. BLE advertisements are used to discover nearby BLE devices in a procedure like Bluetooth BD/EDR 

but instead the discovering device will listen on the advertisement channels.

BLE follows the same naming convention for its devices within a piconet as Bluetooth BD/EDR but 

instead a piconet only has two devices: the BLE Control device and the BLE Peripheral device. Similar to 

Bluetooth BD/EDR, BLE device piconets can form scatternets with other devices but each connection has 

its own individual piconet.

6.2.3.3 Bluetooth Passive Monitoring

An AO should make the decision on which level of monitoring Bluetooth devices is necessary to meet 

security concerns for their operational environment. This is not required for the CSfC WIDS/WIPS Annex

but is provided as an additional capability provided for AOs to deploy as they see fit. Monitoring of 

Bluetooth devices can be broken down to three tiered capabilities which are the detection of the 

presence of Bluetooth devices, the detection of individual Bluetooth devices, and protocol level 

monitoring of these Bluetooth devices. 

The lowest level of these capabilities is for the WIDS to detect the presence of the Bluetooth devices 

operating within the area monitored by the WIDS. This capability allows for only awareness that there is 

a Bluetooth device operating within the space and may include the ability to differentiate between 

Bluetooth BR/EDR and BLE. 

The second tier of detection of Bluetooth is for the WIDS to capture the unique identifier of Bluetooth 

devices when operating within the area monitored by the WIDS. The identifier the WIDS needs to

capture is the Bluetooth MAC Addresses (see Section 6.2.3.1 for additional information). For Bluetooth 

BR/EDR the WIDS should capture the LAP of the Bluetooth MAC Address as the rest of the address is 

only sent during the setup of connections. For BLE the WIDS should capture the entire Bluetooth MAC 

Address to identify the BLE device. Additionally, the WIDS should be able to identify whether a 

Bluetooth MAC Address is a Public Address or a Random Address to inform the user whether the 

Bluetooth MAC Address may change during the time it's within the area monitored by the WIDS. 

The third tier of detection is monitoring the behavior of active Bluetooth devices in the area monitored 

by the WIDS. For Bluetooth BR/EDR this includes capturing the LAP of the Bluetooth MAC Address and 

the entire MAC Address when transmitted. The WIDS should also be able to detect the Inquiry 

procedure to see if devices are attempting to find devices within the controlled space and additionally 

should detect which devices are responding to these devices and capture any relevant data that has 

been passed by those devices during the Inquiry procedure. The WIDS should also detect and capture all 

information exchanged during the SDP procedure as this indicates a connection is being formed 

between two devices. The WIDS should additionally detect Bluetooth BR/EDR paging events within the 

operation area monitored by the WIDS for this is another indication of connections being formed within 

the space. Finally, the WIDS should detect the network membership of any Bluetooth BR/EDR. This 
 

22

includes determining which piconets devices are a member of, determining if they are a Peripheral 

device or Central device, and if they are a member of more than one piconet.

For BLE much of the same detection capabilities should be implemented to monitor BLE as Bluetooth 

BR/EDR. First the WIDS should detect any BLE device advertising on the Advertisement channels and 

determine if the device is advertising its presence or sending data over the advertisement channel. The 

WIDS should detect when SDP procedure is being used and capture and data being exchanged between 

the BLE devices. The WIDS should detect any BLE devices Paging or responding to the Paging procedure 

within the operational area of the WIDS. Finally, the WIDS should detect the network membership of 

any BLE this includes determining which piconets they are a member of, determining if they are a 

Peripheral device or Central device, and if they are a member of more than one piconet.

6.2.3.4 Bluetooth Active Monitoring

Bluetooth has several methods to discover Bluetooth devices, discover information about available 

capability sets and detect individual devices within a range of a Bluetooth device. These capabilities 

include the Bluetooth BD/EDR Inquiry procedure to detect Bluetooth Devices in discoverable mode, 

BD/EDR and BLE SDP which is used to query a Bluetooth device for device information and supported 

devices capabilities, and Bluetooth Paging which is used to setup connection to individual Bluetooth 

devices. All these capabilities may be implemented into a WIDS and used to detect and gather more 

information about the Bluetooth devices within the area. To implement this the WIDS sensor should 

have a Bluetooth interface capable of transmitting and thus this Bluetooth interface should be in nondiscoverable mode, non-connectable mode, and non-pairable mode to ensure that the WIDS sensor 

cannot be discovered, paged, nor paired to other devices. The WIDS sensor can implement any of the 

Bluetooth discovery features to gather more information about devices within the area. The Bluetooth 

Inquiry procedure can be used to inquire out for Bluetooth in Discoverable mode and gather the entire 

Bluetooth MAC Address and device name. The Bluetooth SDP procedure can be used to query the 

devices for more information about the capabilities, devices class, and additional device information. 

The Paging procedure can be used to ping out to known devices within an area to entice them to 

respond to the page. All these capabilities may be integrated into the WIDS sensors and data aggregated 

by the WIDS controller or other data correlation system, but these are all optional capabilities, and the 

AO should consider if this meets their individual deployment’s particular needs. 

7 WIRELESS INTRUSION PREVENTION SYSTEM (WIPS)

A WIPS consists of sensors (preferably dedicated), and a central controller working together to provide 

24/7 active defense of a wireless network preventing unauthorized connection. The system can either 

be overlay or integrated into the WLAN Access System. WIPS is designed to protect authorized 802.11 

devices within controlled spaces from unauthorized devices attempting to connect to them. 

A WIPS is not required in a CSfC deployment when a WLAN Access System is used, but greatly enhances 

the security of a wireless deployment. A WIPS within a CSfC solution can either be an overlay solution, 

or an integrated solution deployed alongside the wireless controller. In an integrated deployment, WIPS 

must reside along with the wireless controller either within the Gray Network or a control segment of 

the Black Network. In an overlay WIPS deployment, the WIPS system can either be deployed within the 
 

23

Gray Network, or a controlled network segment. Refer to Section 5 for more information on deployment 

of WIPS solutions within the CSfC architecture.

7.1 WIPS DEPLOYMENT CONSIDERATIONS

Before considering to deploy a WIPS with a wireless access solution, the AO must understand the 

technical capability of the WIPS, and the legal authorities under which the system operates. A WIPS is 

capable of a DDoS which can shut down all standard Wi-Fi communications and prevent unauthorized 

signals from forming within the controlled space. This capability is extremely powerful for defending an 

authorized wireless network within the controlled space but can lead to inadvertently disrupting Wi-Fi 

devices. A WIPS is not an ideal solution in a controlled space that is collocated, adjacent to, or near a 

location that allows for Wi-Fi devices, has its own Wi-Fi network, or is a public space. WIPS must be 

tuned to only defend the authorized network and to ignore all other networks and devices it detects.

The use of an authorized WLAN Access System with 802.11w, Protection Management Frame (PMF) 

enabled significantly reduces the capabilities of a WIPS solution to enforce protection functionality. PMF 

functions by extending encryption, authentication and integrity checks to most 802.11 management 

frames with the following frames left unprotected:

 Beacon

 Probe request/response

 Announcement traffic indication message (ATIM)

 Authentication

 Association request/response

 Spectrum management action

A WIPS functions by leveraging disassociation and de-authentication frames to force connections to 

terminate if the WIPS detects a rules violation. The use of PMF requires disassociation and deauthentication frames to be encrypted between clients and APs and have both authentication and 

integrity checks. Thus, removing the WIPS main capability for actively defending the network. Currently, 

CSfC Campus WLAN CP requires the use of PMF for all deployments of WLAN Access System and it is 

highly encouraged for MA CP to deploy PMF as well. Even with the reduction of capability that PMF 

cause to a WIPS the protections which PMF grants to WLAN Access Systems cannot understated and is 

considered to be critical protections provided to the WLAN Access Systems.

7.2 WIPS OPERATIONS

For the proper function of a WIPS and to ensure that the WIPS does not conduct inadvertent DDoS 

attacks against unintended wireless devices, a properly maintained and detailed Allowlist is required. 

The Allowlist is the detailed list of all devices connected to a WLAN Access System and all its expected 

operating behavior. With this list, rules can be made to defend the Allowlisted devices from 
 

24

unauthorized devices and from connecting to the network while in a misconfigured or insecure state. 

There can be more than one Allowlist that the WIPS system monitors. In this case, each Allowlist is 

separate from each other and no interaction between devices on a separate Allowlist is allowed. The 

Graylist is an optional list of expected devices within the controlled space which are known and allowed 

to operate within the area. Graylist devices are not allowed to connect to any Allowlist devices. The 

Denylist, is a list of all devices not contained in the Allowlist, or Graylist. If it exists, these devices must 

be prevented from forming any connection to any devices on the Allowlist (See Section 7.2.1). 

7.2.1 WIPS ALLOWLIST

The Allowlist is the detailed list of all devices connected to a WLAN Access System and all its expected 

operating behavior. A WIPS solution deployed to secure a WLAN Access System requires all information 

on the Allowlist of the WLAN Access System to remain current. For details on the Allowlist see section 

6.1.1. This Allowlist must be maintained and accessible by the WIPS at all times to ensure that the WIPS 

does not either deny access to an authorized device, or allow an unauthorized device to attempt to 

connect to the network.

With a Allowlist established, the standard operating procedures of the network can be created. Any 

device not specifically on the Allowlist should be blocked from establishing any network connection to 

the authorized WLAN Access System and a notification should be made of this event. This includes any 

non-Allowlisted devices attempting to make a network connection to either the WLAN AP or the WLAN 

EUDs. Furthermore, the WIPS should be capable of monitoring the Allowlisted WLAN APs and WLAN 

EUDs and if they are detected deviating from the normal operating parameters of the WLAN Access 

System, they should be blocked from network connectivity and a notification made of this event. This 

includes operating on a different channel than expected, attempting to connect to another network, 

attempting to create a wireless bridge, etc.

7.2.2 WIPS GRAYLIST

The Graylist is a list of devices allowed within the controlled space but are not allowed network 

connectivity and not allowed to communicate with any device on the Allowlist. These devices include 

any known building automation, IoT devices and personal devices that are allowed within the building. 

The existence of a Graylist is left up to the AO and relevant security policy. This list only exists for 

situational awareness of a controlled space and exclusion of these devices from the Denylist. The WIPS 

system should still block all network communications to or from the Graylist devices and the Allowlisted 

WLAN APs and WLAN EUDs.

7.2.3 WIPS DENYLIST

The Denylist is an inclusive list of every device not on the Allowlist or Graylist. The AO using the relevant 

security policy, must decide on the handling of the Denylist by the WIPS. It is recommended that the 

WIPS remain completely defensive in this case and only defend the Allowlisted WLAN APs and WLAN 

EUDs from any misconfiguration or unauthorized connections. The AO may decide, to block all 

Denylisted devices from forming any network connections to prevent them from communicating using a 

WLAN this is not recommended and should only be used in the most controlled environment.
 

25

8 INFORMATION TO SUPPORT AO

This section details items which will assist the system AO in the operation of CSfC WIDS/WIPS Solutions. 

The customer and AO have obligations to perform the following:

 The customer and the AO must create an operation plan for how rogue devices are treated 

when detected by the WIDS System: whether all devices outside of the approved WLAN Access 

System are considered rogue devices or only those attempting to connect to the approved 

WLAN Access System.

 If a WIPS is deployed, the customer and AO must create an operation plan on how the WIPS will 

operate. Determine whether it prevents all connections from forming or only prevents 

communications to the approved WLAN Access System.

 The customer and AO must keep an updated map of the facility and identify where all 

authorized AP and WIDS/WIPS sensors are deployed.

 The customer must decide whether to geographically locate devices within the controlled space 

and additionally, to what degree the locations must be accurate. It is recommended that the 

radius of accuracy for detection be at least 25 feet.

 If the WIDS can geo-locate devices, the customer may want to designate areas where certain 

wireless devices are allowed and where they are not allowed. Such as devices being allowed at 

entrances or common areas; and devices being forbidden from certain areas.

 The customer and AO may decide to use a secondary WIDS or similar system to enhance the 

detection capability within the controlled space. This secondary system must still be deployed 

according to Section 5 and be NIAP validated.

 The customer and AO may decide to include additional protocols that the WIDS monitors and 

protects, such as cellular or Bluetooth. Additionally, they must decide what level of detection is 

required by their solution (See Section 6.2).

 The customer and AO must determine an acceptable alert configuration threshold for the 

WIDS/WIPS sensors before reporting begins. 

The system AO maintains configuration control of the approved solution implementation over the 

lifecycle of the solution. Additionally, the AO must ensure that the solution remains properly configured 

with all required security updates implemented.

9 REQUIREMENTS OVERVIEW

Sections 9 through 10 specify requirements for implementation of WIDS solutions compliant with this 

Annex. 
 

26

9.1 THRESHOLD AND OBJECTIVE REQUIREMENTS

In some cases, multiple versions of a requirement may exist in this Annex. Such alternative versions of a 

requirement are designated as being either a Threshold requirement or an Objective requirement:

 A Threshold (T) requirement specifies a feature or function that provides the minimal acceptable 

capability for the security of the solution.

 An Objective (O) requirement specifies a feature or function that provides the preferred 

capability for the security of the solution.

In general, when separate Threshold and Objective versions of a requirement exist, the Objective 

requirement provides a higher degree of security for the solution than the corresponding Threshold 

requirement. However, in these cases meeting the Objective requirement may not be feasible in some 

environments or may require components to implement features that are not yet widely available. 

Solution owners are encouraged to implement the Objective version of a requirement, but in cases 

where this is not feasible, solution owners may implement the Threshold version of the requirement 

instead. These Threshold and Objective versions are mapped to each other in the “Alternatives” column. 

Objective requirements that have no related Threshold requirement are marked as “Optional’ in the 

“Alternatives” column.

In most cases, there is no distinction between the Threshold and Objective versions of a requirement. In 

these cases, the “Threshold / Objective” column indicates that the Threshold equals the Objective (T=O). 

Requirements listed as Objective in this Annex may become Threshold requirements in a future version 

of this Annex. Solution owners are encouraged to implement Objective requirements where possible in 

order to facilitate compliance with future versions of this Annex.

9.2 REQUIREMENTS DESIGNATORS

Each requirement defined in this Annex has a unique identifier consisting of the prefix “WIDS,” a digraph 

that groups related requirements together (e.g., “WI”), and a sequence number (e.g., 11). 

Table 4 lists the digraphs used to group related requirements together, and identifies the sections in 

which those requirement groups can be found. 

Table 4. Requirement Digraphs

Digraph Description Section Table

GR WIDS General Requirements Section 10.1 Table 5

WL WIDS WLAN Detection Requirements Section 10.2 Table 6

ED WIDS Extended Detection Requirements Section 10.3 Table 7

GP WIDS Cellular Detection Requirements Section 10.4 Table 8

BT WIDS Bluetooth Detection Requirements Section 10.5 Table 9

WIP WIPS WLAN Requirements Section 10.6 Table 10

AU Auditing Requirements Section 10.7 Table 11

CM Continuous Monitoring Requirements Section 10.8 Table 12

TR Testing Requirements Section 10.9 Table 13
 

27

10 WIDS/WIPS REQUIREMENTS

10.1 WIRELESS INTRUSION DETECTION SYSTEM (WIDS) GENERAL REQUIREMENTS

Table 5 identifies the WIDS’s general requirements for deployment. WIDS/WIPS refers to requirements 

that apply to WIDS and WIPS, if deployed.

Table 5. WIDS General Requirements (GR)

Req # Requirement Description Threshold / 

Objective Alternative

WIDS-GR-1 A WIDS must be in place to monitor long-term (over 3 

months) static CSfC Solution which uses a WLAN Access 

System IAW the Campus WLAN CP.

T=O

WIDS-GR-2 A WIDS must be in place to monitor long-term (over 3 

months) static CSfC Solution which uses a WLAN Access 

System IAW the Mobile Access CP government private 

wireless use case within a controlled space. 

T=O

WIDS-GR-3 The product(s) used for the WIDS/WIPS must be chosen 

from the list of WIDS/WIPS on the CSfC Components List.

T=O

WIDS-GR-4 WIDS/WIPS Components must be configured to use the 

NIAP-certified evaluated configuration.

T=O

WIDS-GR-5 The WIDS being deployed to monitor the WLAN Access 

System must be either Integrated into the WLAN Access 

System or a separate Overlay WIDS.

T=O

WIDS-GR-6 If the WLAN Access System is deployed as an integrated 

WIDS/WIPS, the WIDS/WIPS sensors must be deployed 

on, and controlled from, the same network segment that 

the WLAN Access Systems AP(s) operate on.

T WIDS-GR-7

WIDS-GR-7 If the WLAN Access System is deployed as an integrated 

WIDS/WIPS, the WIDS/WIPS sensors must be on their 

own separate network dedicated to only the WIDS 

sensors.

O WIDS-GR-6

WIDS-GR-8 If the WIDS/WIPS is deployed as an overlay WIDS, the 

WIDS/WIPS must be deployed on the Black Management 

Network, Gray Management Network or a standalone 

network.

T=O

WIDS-GR-9 If the WIDS/WIPS is deployed as an overlay WIDS, the 

WIDS/WIPS sensors must be on their own physically 

separate network only connected to the WIDS/WIPS 

Controller.

T=O

WIDS-GR-10 All communication between WIDS/WIPS components 

must be done via a secure connection using Secure Shell 

(SSHv2), IPsec, TLS 1.2 or 1.3, DTLS, or TLS/HTTPS.

T=O

WIDS-GR-11 The WIDS/WIPS components must disable non-secure 

communication paths used for management and event 

monitoring including Hypertext Transfer Protocol (HTTP), 

SNMPv1, File Transfer Protocol (FTP), and Telnet.

T=O
 

28

Req # Requirement Description Threshold / 

Objective Alternative

WIDS-GR-12 The WIDS/WIPS controller must utilize a management 

interface used to control, manage and access 

management resources.

T=O

WIDS-GR-13 If the WIDS/WIPS is deployed as an overlay WIDS, the 

management interface of the WIDS/WIPS controller 

must be connected to the management firewall or 

WIDS/WIPS firewall for the controller’s connection to 

the management network. 

T=O

WIDS-GR-14 The management firewall connected to the WIDS/WIPS

must only allow necessary protocols to reach the WIDS 

controller. The necessary protocols may include, but not 

limited to; TLS (1.2 or 1.3), DTLS, SSHv2, IPsec, NTP, DNS, 

DHCP, and system log.

T=O

WIDS-GR-15 The WIDS/WIPS controller must be configured to block 

or deny all attempts to manage the WIDS controller from 

interfaces which are connected to the WIDS sensors.

T=O

WIDS-GR-16 The WIDS/WIPS controller must not allow routing 

through itself to allow for connections between the 

sensors and the management network.

T=O

WIDS-GR-17 The WIDS/WIPS components, excluding the sensors 

must be integrated into existing network authentication 

to allow for centralized management of roles and access 

of the WIDS/WIPS.

T=O

10.2 WLAN DETECTION REQUIREMENTS FOR WIRELESS INTRUSION DETECTION SYSTEM 

(WIDS)

Table 6 identifies WIDS WLAN detection requirements.

Table 6. WLAN (WL) Detection Requirements for WIDS

Req # Requirement Description Threshold / 

Objective Alternative

WIDS-WL-1 The WIDS must have an up-to-date Allowlist of all 

authorized wireless network devices (e.g., APs and EUDs) 

operating within its coverage area.

T=O

WIDS-WL-2 The WIDS must detect and log AP(s) that are not on the 

Allowlist, but are within the coverage area of the WIDS 

sensors.

T=O

WIDS-WL-3 The WIDS must detect and log EUDs which are not on the 

Allowlist, but are within the coverage area of the WIDS 

sensors.

T=O

WIDS-WL-4 The WIDS/WIPS must detect and log if a rogue AP is 

connected via wire to the WIDS/WIPS sensor network.

O Optional
 

29

Req # Requirement Description Threshold / 

Objective Alternative

WIDS-WL-5 The WIDS must detect and log any unauthorized wireless 

hardware attempting to gain access to the wireless 

network being serviced by the authorized WLAN Control 

System.

T=O

WIDS-WL-6 The WIDS must geographically locate all supported 

802.11 wireless emitters operating in the coverage area 

of the WIDS sensors within a range of 25 feet.

O Optional

WIDS-WL-7 The WIDS must be configured to monitor and log all 

802.11 frame types and subtypes between unauthorized 

EUDs and authorized APs.

T=O

WIDS-WL-8 The WIDS must be configured to monitor and log all 

802.11 frame types and subtypes between unauthorized 

APs and authorized EUDs.

T=O

WIDS-WL-9 The WIDS must be configured to monitor and log all 

802.11 frame types and subtypes between authorized 

APs and authorized EUDs.

T=O

WIDS-WL-10 The WIDS must capture the raw frames that triggered an 

alert as well as options on how long to continue 

capturing the frames.

O Optional

WIDS-WL-11 The WIDS must monitor and analyze traffic from all 

802.11 a/g/b/n/ac/ax channels within the 2.4 GHz, 4.9, 5 

and 6 GHz bands including those outside local regulatory 

domain.

T=O

WIDS-WL-12 The WIDS must detect and log the use of unauthorized 

wireless channels by Allowlisted devices.

T=O

WIDS-WL-13 The WIDS must detect and log Allowlisted APs using 

SSIDs not permitted on the network (including hidden 

SSID).

T=O

WIDS-WL-14 The WIDS must detect and log unauthorized APs 

broadcasting the same SSID as a Allowlisted AP. 

T=O

WIDS-WL-15 The WIDS must detect and log Allowlisted EUDs 

associating to SSIDs and BSSIDs not permitted on the 

network (including hidden SSID).

T=O

WIDS-WL-16 The WIDS must detect and log Allowlisted devices 

attempting to use unauthorized authentication methods.

T=O

WIDS-WL-17 The WIDS must detect and log Allowlisted devices 

attempting to use unauthorized encryption schemes.

T=O

WIDS-WL-18 The WIDS must be configured to process 802.11 traffic 

up to the data rate that is supported by the equipment in 

the wireless network. 

O Optional

WIDS-WL-19 The WIDS must detect and log the signal strength of 

802.11 emitters operating in the coverage area of the 

WIDS sensors.

T=O
 

30

Req # Requirement Description Threshold / 

Objective Alternative

WIDS-WL-20 The WIDS must detect and log when an 802.11 emitter is 

transmitting a signal with unusually high signal strength 

for an extended period of time.

T=O

WIDS-WL-21 The WIDS must detect and log Radio Frequency (RF)-

based Denial-of-Service (DoS) attacks.

T=O

WIDS-WL-22 The WIDS must perform protocol anomaly analysis to 

detect and log violations of 802.11 standard.

O Optional

WIDS-WL-23 The WIDS must detect and log deauthentication flooding. T=O

WIDS-WL-24 The WIDS must detect and log disassociation flooding. T=O

WIDS-WL-25 The WIDS must detect and log when the network’s 

activity deviates from an established network baseline.

O Optional

WIDS-WL-26 The WIDS must detect and log bandwidth usage. O Optional

WIDS-WL-27 The WIDS must detect and log the number of EUDs 

connected to the authorized WLAN Access System.

T=O

WIDS-WL-28 The WIDS must detect and log usage times of EUDs with 

the authorized WLAN Access System.

T=O

WIDS-WL-29 The WIDS must detect and log connection status of each 

client (authorized or unauthorized) in near real time 

including, but not limited to, whether the client is offline, 

associated, or authentication is pending. 

O Optional

WIDS-WL-30 The WIDS must detect and log illegal state transitions, 

such as a client device transmitting data frames through 

an AP to a network device before being associated and 

authenticated. 

O Optional

WIDS-WL-31 The WIDS must detect and log an event where an 

attacker spoofs the Media Access Control (MAC) address 

of an authorized client to attempt to connect to the 

legitimate network. 

O Optional

WIDS-WL-32 The WIDS must detect and log an event where a 

Allowlisted EUD's MAC address appears in multiple 

physically distant locations. 

T=O

WIDS-WL-33 The WIDS must detect and log Allowlisted EUDs 

establishing peer-to-peer connections with other 

Allowlisted devices or unauthorized devices.

T=O

WIDS-WL-34 The WIDS must detect and log EUDs bridging two 

network interfaces (wired and wireless). 

O Optional

WIDS-WL-35 The WIDS must detect and log the presence of an 802.11 

bridge, Ad-Hoc networks or point-to-point networks.

T=O

WIDS-WL-36 The WIDS must detect and log the presence of a single 

device transmitting beacons looking for a bridge.

T=O

WIDS-WL-37 The WIDS must detect and log the presence of two or 

more devices transmitting bridge data frames. 

T=O

WIDS-WL-38 The WIDS must detect and log whether a device is 

operating with 802.11w enabled.

T=O
 

31

10.3 WIRELESS INTRUSION DETECTION SYSTEMS (WIDS) EXTENDED DETECTION 

REQUIREMENTS

Table 7 identifies the WIDS’s extended detection requirements for the detection and geo-location of 

additional protocols outside of 802.11 WLAN. These capabilities are currently optional in the Annex and 

not required, however, the AO may decide to implement a system with such capabilities.

Table 7. WIDS Extended Detection (ED) Requirements

Req # Requirement Description Threshold / 

Objective Alternative

WIDS-ED-1 The WIDS must monitor and analyze traffic from all 

802.11 channels within the 3.6 GHz bands.

O Optional

WIDS-ED-2 The WIDS must monitor and analyze traffic from all 

802.11 channels within 6 GHz bands.

T=O

WIDS-ED-3 The WIDS must monitor and analyze traffic from all 

802.11 channels within 60 GHz band.

O Optional

WIDS-ED-4 Withdrawn

WIDS-ED-5 Withdrawn

WIDS-ED-6 Withdrawn

WIDS-EU-7 Withdrawn

WIDS-EU-8 Withdrawn

WIDS-ED-9 Withdrawn

WIDS-ED-10 Withdrawn

WIDS-ED-11 Withdrawn

WIDS-ED-12 Withdrawn

10.4 WIDS CELLULAR DETECTION (CL) REQUIREMENTS

Table 8 identifies the WIDS’s extended detection requirements for the detection and geo-locating of 

cellular technologies. These capabilities are currently optional in the Annex and not required, however, 

the AO may decide to implement a system with such capabilities.

Table 8. WIDS Cellular (CL) Requirements

Req # Requirement Description Threshold / 

Objective Alternative

WIDS-CL-1 The WIDS must detect and log the presence of Cellular 

3G devices operating within the controlled space.

O Optional

WIDS-CL-2 The WIDS must detect and log the presence of Cellular 

4G/LTE devices operating within the controlled space.

O Optional

WIDS-CL-3 The WIDS must detect and log the presence of Cellular 

5G emitter operating in the FR1 band within the 

controlled space.

O Optional

WIDS-CL-4 The WIDS must detect and log temporary identifiers 

(e.g. TMSI) of cellular devices operating within the 

controlled space. 

O Optional
 

32

WIDS-CL-5 The WIDS must detect and log which cellular 

technology (such as 3G, LTE, UMTS, 5G, etc.) a cellular 

device is using within the controlled space.

O Optional

WIDS-CL-6 The WIDS must detect and log which cellular carrier a 

cellular device is using within a controlled space.

O Optional

WIDS-CL-7 The WIDS must detect and log which base station a 

cellular device is connected to while operating within a 

controlled space.

O Optional

WIDS-CL-8 The WIDS must detect and log whether a cellular 

device is using a cellular uplink or downlink operating 

within the controlled space.

O Optional

WIDS-CL-9 The WIDS must geolocate cellular devices operating 

within the operation area of the WIDS.

O Optional

10.5 WIDS BLUETOOTH DETECTION (BT) REQUIREMENTS

Table 9 identifies the WIDS’s extended detection requirements for the detection and geo-location of 

Bluetooth protocols. These capabilities are currently optional in the Annex and not required, however, 

the AO may decide to implement a system with such capabilities.

Table 9. WIDS Bluetooth (BT) Requirements

Req # Requirement Description Threshold / 

Objective Alternative

WIDS-BT-1 The WIDS must detect and log the presence of 

Bluetooth BR/EDR devices operating within the 

controlled space.

O Optional

WIDS-BT-2 The WIDS must detect and log the presence of BLE 

devices operating within the controlled space.

O Optional

WIDS-BT-3 The WIDS must detect and log the Bluetooth BR/EDR 

device’s LAP, half the Bluetooth MAC Address, within 

the controlled space.

O Optional

WIDS-BT-4 The WIDS must detect and log the BLE device’s 

Bluetooth MAC Address within the controlled space.

O Optional

WIDS-BT-5 The WIDS must geo-locate Bluetooth BR/EDR devices 

within 25 feet of their actual location.

O Optional

WIDS-BT-6 The WIDS must geo-locate BLE devices within 25 feet 

of their actual location.

O Optional

WIDS-BT-7 The WIDS must detect and log Bluetooth BR/EDR 

devices conducting the Inquiry Procedure within the 

controlled space. 

O Optional
 

33

WIDS-BT-8 The WIDS must detect and log Bluetooth BR/EDR 

devices responding to the Inquiry Procedure within the 

controlled space.

O Optional

WIDS-BT-9 The WIDS must detect and log any device information 

transmitted during the Bluetooth BR/EDR Inquiry 

Procedure when occurring within the controlled space.

O Optional

WIDS BT-10 The WIDS must detect and log BLE devices 

advertisements on the Advertisement channels 

(primary and secondary).

O Optional

WIDS-BT-11 The WIDS must detect and log BLE devices exchanging 

information or data on the Advertisement channels.

O Optional

WIDS-BT-12 The WIDS must detect and log Bluetooth BR/EDR 

devices using the SDP procedure

O Optional

WIDS-BT-13 The WIDS must detect and log any device information 

exchanged during the Bluetooth BR/EDR SDP 

procedure.

O Optional

WIDS-BT-14 The WIDS must detect and log any Bluetooth BR/EDR 

devices preforming the Paging Procedure.

O Optional

WIDS-BT-15 The WIDS must detect and log any BLE device 

preforming the Paging Procedure.

O Optional

WIDS-BT-16 The WIDS must detect and log the piconet 

membership of any Bluetooth BR/EDR device. This 

includes role in the piconet (Central or Peripheral), 

piconet ID, device ID, and number of piconets which 

they are members of.

O Optional

WIDS-BT-17 The WIDS must correlate the number of piconets a 

device is a member of.

O Optional

WIDS-BT-18 The WIDS must detect and log the piconet 

membership of any BLE device. This includes role in 

the piconet (Central or Peripheral), piconet ID, device 

ID, and number of piconets which they are members 

of.

O Optional

WIDS-BT-19 If the WIDS is using active methods to detect Bluetooth 

devices, The WIDS Bluetooth interface must be in the 

following modes:

 Non-Discoverable Mode

 Non-Connectable Mode

O Optional
 

34

 Non-Pairable Mode

WIDS-BT-20 If the WIDS is using active methods to detect Bluetooth 

devices, the WIDS must use Bluetooth BR/EDR Inquiry 

Procedure to detect Bluetooth BR/EDR devices in 

discoverable mode within the controlled area.

O Optional

WIDS-BT-21 If the WIDS is using active methods to detect Bluetooth 

devices, the WIDS must use Bluetooth BR/EDR SDP 

procedure to gather information about Bluetooth 

BR/EDR devices within the controlled area.

O Optional

WIDS-BT-22 If the WIDS is using active methods to detect Bluetooth 

devices, the WIDS must use BLE SDP procedure to 

gather information about BLE devices within the 

controlled area.

O Optional

10.6 WIRELESS INTRUSION PREVENTION SYSTEM (WIPS) REQUIREMENTS

Table 10 identifies the WIPS requirements for the defense of 802.11 WLAN Access Systems. These 

capabilities are currently optional in the Annex and not required, however, the AO may decide to 

implement a system with such capabilities.

Table 10. WIPS Requirements

Req # Requirement Description Threshold / 

Objective Alternative

WIDS-WIP-1 A WIPS must be in place to monitor a long-term (over 3 

months) static CSfC Solution which uses a WLAN Access 

System IAW the Campus WLAN CP.

O Optional

WIDS-WIP-2 A WIPS must be in place to monitor a long-term (over 3 

months) static CSfC Solution which uses a WLAN Access 

System IAW the Mobile Access CP government private 

wireless use case within a controlled space. 

O Optional

WIDS-WIP-3 A WIPS must be used to prevent any unauthorized 

device from forming a network connection with an 

authorized Allowlisted device.

O Optional

WIDS-WIP-4 A WIPS must be used to prevent any communication of 

an authorized Allowlisted device if functioning outside 

of authorized use.

O Optional

WIDS-WIP-5 If the AO and local policy requires, the WIPS must 

prevent any network connections from forming 

between any Denylisted devices.

O Optional

10.7 WIDS AUDITING REQUIREMENTS

Table 11 identifies the WIDS Auditing Requirements.
 

35

Table 11. WIDS Auditing (AU) Requirements

Req # Requirement Description Threshold / 

Objective Alternative

WIDS-AU-1 All WIDS/WIPS components excluding the WIDS Sensors must 

send all generated system log data on to the solution’s CM 

capability (such as a SIEM or IDS).

T=O

WIDS-AU-2 The WIDS/WIPS components excluding the WIDS Sensors 

must log any failed attempt to log into its management 

interface.

T=O

WIDS-AU-3 The WIDS/WIPS components excluding the WIDS Sensors 

must log whenever a new user is created.

T=O

WIDS-AU-4 The WIDS/WIPS components excluding the WIDS Sensors 

must log whenever an attempt to escalate privileges on the 

WIDS components is detected.

T=O

WIDS-AU-5 The WIDS/WIPS components excluding the WIDS Sensors 

must log whenever a user is added to a group.

T=O

WIDS-AU-6 The WIDS/WIPS components excluding the WIDS Sensors 

must log whenever a change is made to group privileges.

T=O

WIDS-AU-7 The WIDS/WIPS components excluding the WIDS Sensors 

must log whenever a user account attribute is changed.

T=O

WIDS-AU-8 The WIDS/WIPS components excluding the WIDS Sensors 

must log whenever an authentication rule is created or 

modified.

T=O

WIDS-AU-9 The WIDS/WIPS components excluding the WIDS Sensors 

must log any configuration change on the WIDS components.

T=O

WIDS-AU-10 The WIDS/WIPS components excluding the WIDS Sensors 

must log any configuration failures or errors.

T=O

WIDS-AU-11 The WIDS/WIPS components excluding the WIDS Sensors 

must log when a WIDS sensor connects to the controller. 

T=O

WIDS-AU-12 The WIDS/WIPS components excluding the WIDS Sensors 

must log when a WIDS sensor disconnects or fails to 

communicate.

T=O

WIDS-AU-13 The WIDS/WIPS components excluding the WIDS Sensors 

must log when there is an error state in any of the WIDS 

components.

T=O

10.8 CONTINUOUS MONITORING REQUIREMENTS

The interface between the WIDS/WIPS Controller and the Management Firewall such as the Gray 

Management Firewall must be monitored as part of the Management Network. All monitoring 

requirements from the CSfC Continuous Monitoring Annex MP6 must be applied to a Gray WIDS/WIPS 

connection. 

The following CM requirements apply to the interface between the WIDS/WIPS Controller and 

Management Firewall if they are part of the Black Management Network or part of a standalone 

network. Table 12 identifies the Continuous Monitoring Requirements.
 

36

Table 12. Continuous Monitoring (CM) Requirements

Req # Requirement Description Threshold / 

Objective Alternative

WIDS-CM -1 The authentication service supporting the WIDS/WIPS

components excluding the WIDS Sensors must log any failed 

login attempt.

T=O

WIDS-CM-2 The authentication service supporting the WIDS/WIPS

components excluding the WIDS Sensors must log whenever a 

new user is created.

T=O

WIDS-CM-3 The authentication service supporting the WIDS/WIPS

components excluding the WIDS Sensors must log whenever a 

user is added to a group.

T=O

WIDS-CM-4 The authentication service supporting the WIDS/WIPS

components excluding the WIDS Sensors must log whenever a 

change is made to group privileges.

T=O

WIDS-CM-5 The authentication service supporting the WIDS/WIPS

components excluding the WIDS Sensors must log whenever a 

user account attribute is changed.

T=O

WIDS-CM-6 The authentication service supporting the WIDS/WIPS

components excluding the WIDS Sensors must log whenever 

an authentication rule is created or modified.

T=O

WIDS-CM-7 The monitoring capability must log any attempt to scan the 

WIDS/WIPS components excluding the WIDS Sensors, 

Management Firewall and any other component supporting 

the WIDS.

T=O

WIDS-CM-8 The monitoring capability must log if unusual traffic is 

detected between the WIDS/WIPS components and/or 

management firewall.

T=O

WIDS-CM-9 The monitoring capability must log if a protocol outside of SSH, 

IPsec, or TLS is used to login into network components or 

management services from a dedicated management 

workstation or authorized management device.

T=O

WIDS-CM-10 The monitoring capability must log any DNS queries on the 

WIDS Controller or any supporting components make to a 

domain or IP outside of the management network.

T=O

WIDS-CM-11 If a CDP is used to support the WIDS Components, the WIDS 

Components must log if the version of the CRL downloaded 

from a CDP is older than the current cached CRL.

T=O

WIDS-CM-12 If a CDP is used to support the WIDS Components, the WIDS 

Components must log if signature validation of the CRL 

downloaded from a CDP fails.

T=O

WIDS-CM-13 The WIDS Components must log administrator lockout due to 

excessive authentication failures.

T=O

WIDS-CM-14 Vulnerability scans must be conducted on the WIDS 

components within a time designated by the AO and relevant 

governing policies.

T=O

10.9 TESTING REQUIREMENTS

Table 13 identifies the Testing Requirements.
 

37

Table 13. Testing Requirements

Req # Requirement Description Threshold / 

Objective Alternative

WIDS-TR-1 The organization implementing the annex must perform all 

tests listed in WIDS/WIPS Testing Annex.

T=O
 

38

APPENDIX A. WIDS/WIPS GUIDANCE FOR SYSTEMS NOT INTEGRATED 

WITH CSFC DATA-IN-TRANSIT SOLUTIONS

OVERVIEW

The WIDS/WIPS Annex provides guidance for CSfC customers to deploy a WIDS/WIPS in their CM 

solution if they have the WLAN Access System in accordance to the Mobile Access CP or Campus WLAN 

CP. This Appendix provides engineering instructions and guidance for the deployment of WIDS/WIPS 

solutions to monitor controlled spaces in the absence of a CSfC cryptographic solution. This guidance 

should be used by customers deploying a WIDS/WIPS solution without a CSfC Campus WLAN or Mobile 

Access solution. Use of this Appendix alone does not provide CSfC cryptographic protection, nor is the 

use of this Appendix required to be registered as a CSfC solution.

A WIDS consists of sensors (preferably dedicated), and a central controller working together to provide 

24/7 monitoring of the wireless spectrum focusing on 802.11 WLAN to detect, identify, and geo-locate 

wireless device within controlled space. A WIDS is vital if a WLAN Access System is deployed for 

communication within a space and enhances the security posture of a controlled space even if a WLAN 

Access System is not present. The WIDS must be capable of detecting 802.11 WLAN devices but the 

detection of additional protocols and RF energy enhances the security of the controlled space. A WIPS is 

currently optional and is not required within a controlled space whether or not a WLAN Access System is 

within the controlled space.

A WIPS consists of sensors (preferably dedicated), and a central controller working together to provide 

24/7 active defense of a wireless network preventing unauthorized connection. A WIDS may have the 

capability of a WIPS and can be used as one, but a WIPS is not required at this time for monitoring 

controlled spaces. A WIPS is designed to protect authorized 802.11 devices within controlled spaces 

from any unauthorized device attempting to connect to them; defending authorized 802.11 networks 

and authorized clients from any attempts to attack, disrupt or connect to the clients or the wireless 

networks. These systems are capable of causing DDoS against 802.11 clients within their controlled 

space. Both the capabilities of the WIDS and the WIPS must be considered by the AO when deploying 

either a WIDS or WIPS. The AO should seek additional guidance from their relevant decision making 

bodies on inadvertent collection of signals and potential DDoS of wireless clients within their controlled 

space.

Deploying a WIDS/WIPS to monitor a controlled space requires that the WIDS/WIPS be a NIAP validated 

product and must be configured to use the NIAP-certified evaluation configuration. A WIDS/WIPS being 

deployed within a controlled space has a number of different configurations in which the system can be 

arranged. These configurations include being integrated into the WLAN Access System and overlay 

deployments for the WIDS/WIPS solution.

DEPLOYMENT ARCHITECTURE

A WIDS/WIPS is required if a WLAN Access System is used within the controlled space or if relevant 

policy requires a WIDS/WIPS be deployed for monitoring of the controlled space. The WIDS/WIPS must 

be selected from the NIAP Components List and it must be configured to use the NIAP-evaluated 

configuration. It is recommended that a WIDS/WIPS solution only be used to monitor long term static 
 

39

locations and not for tactical or mobile environments. However refer to relevant policy or AO decision 

when determining when a WIDS/WIPS is required for the given deployment.

WIDS/WIPS DEPLOYMENTS

A WIDS/WIPS solution can be arranged in two general configurations which include a WIDS/WIPS 

integrated into WLAN Access Systems or an overlay WIDS/WIPS solution. When a WIDS/WIPS is 

integrated into a WLAN Access System, the WLAN Access System must have the capability to act as an 

authorized WIDS/WIPS. If a WLAN Access System is already deployed, this integrated solution has the 

benefit of reducing the number of required components and complexity of the WIDS/WIPS. If the WLAN 

Access System cannot act as a WIDS/WIPS, an overlay WIDS/WIPS must be used for monitoring of the 

WLAN Access System. When relevant policy, or an AO’s decision determines that a WIDS/WIPS is 

required for a controlled space without a WLAN Access System, then an overlay WIDS/WIPS must be 

deployed. WIDS/WIPS is integrated into the WLAN Access System, WIDS/WIPS sensors can be deployed 

on the same network as the WLAN Access System’s APs. However, if the WIDS/WIPS is an overlay the 

WIDS/WIPS sensors must be on a separate network.

INTEGRATED WIDS/WIPS

A WIDS/WIPS that is integrated into an already existing WLAN Access System must have separate 

dedicated APs acting as WIDS/WIPS Sensors and WLAN Access APs. The same WLAN Access Controller 

can be used to manage both of the sensors and APs but, the APs and sensors must be separated logically 

from each other and not allowed to communicate with each other. Additionally, there must be a 

firewall between the WLAN Access Controller and the network that it manages. This prevents all but 

essential protocols going to and coming from the controller. This includes, but is not limited to, TLS (1.2 

or 1.3), SSHv2, IPsec, NTP, DNS, DHCP, and system log. An example of this can be seen in Figure 14.

Figure 14: Integrated WIDS/WIPS
 

40

OVERLAY WIDS/WIPS

WIDS/WIPS may also deploy as an Overlay and not as a function of the WLAN Access System. If a WLAN 

Access System is not present, the WIDS may reside on the management network where the WLAN 

Access Controller is located, or on its own separate network. The WIDS sensors cannot be on the same 

network as the WLAN Access APs. As in the integrated WIDs/WIPS, an Overlay WIDS/WIPS controller 

requires a firewall between it and the network it manages to prevent all but essential protocols going to 

and coming from the controller. As seen in Figure 15, this includes, but is not limited to, TLS (1.2 or 1.3), 

SSHv2, IPsec, NTP, DNS, DHCP, and system log.

Figure 15: Overlay WIDS/WIPS

WIDS/WIPS SECURITY

Security of a deployed WIDS/WIPS is required for management, control, and network functionality of 

the WIDS/WIPS components. The components that make up a WIDS/WIPS include the WIDS/WIPS 

sensor, WIDS/WIPS controller, workstation, as well as other supporting components. Communications 

between the WIDS/WIPS sensors and the WIDS/WIPS controller must use secure communication (e.g., 

SSHv2, IPsec, or TLS (1.2 or 1.3)/HTTPS) and the communication between the WIDS/WIPS controller, 

workstation and other supporting components must also use secure communication (e.g., SSHv2, IPsec, 

or TLS (1.2 or 1.3)/HTTPS). All forms of unsecure management, control and sending data must be 

disabled for each WIDS/WIPS Component. 

As shown in Figure 16, a firewall must block all communications between the WIDS Access controller 

and WLAN controller. This firewall protects both the management network and the WIDS/WIPS 

controller by monitoring and controlling all traffic to and from the WIDS/WIPS controller. This firewall 

must filter all but the necessary protocols from reaching the WIDS/WIPS controller. This includes, but is 

not limited to, TLS (1.2 or 1.3), SSHv2, IPsec, NTP, DNS, DHCP, and system log. In addition to the firewall, 

the WIDS/WIPS controller must be locked down to minimize the potential risk to the solution. First, 

there must be no capability to manage or control the WIDS/WIPS controller from the interfaces that are 

connected to the sensors. Second, there must not be any routing through the WIDS/WIPS controller 
 

41

between the sensors and the management network. Finally, the WIDS/WIPS controller must have a 

management interface used to control, manage and access management resources. 

Figure 16: WIDS Components

As shown in Figure 17, the firewall can be replaced with a firewall/Virtual Private Network (VPN) 

gateway to provide an additional level of security for users attempting to log into the system and to 

provide a method of connecting multiple WIDS/WIPS solutions together. Connecting WIDS/WIPS 

solutions together using a VPN Gateway allows for the sharing of centralized resources, remote 

administration, and centralized monitoring of the WIDS/WIPS solution. This capability is considered 

optional to the WIDS/WIPS solution but will provide additional security for scaled WIDS/WIPS solutions.
 

42

Figure 17: WIDS/WIPS Remote Systems

A centralized authentication service is fundamental for any network and WIDS/WIPS, even if it supports 

local account administration. The system must still use an external authentication service such as 

RADIUS, Active Directory, or Kerberos. All WIDS/WIPS components must be integrated into the 

network’s existing CM capability such as an Intrusion Detection System, or Security Information and 

Event Management (SIEM). 

The system logs that are collected from the WIDS/WIPS component must log any login event and must 

include any failed login attempts, successful logins, and administrator logins. The system logs must also 

include any changes to the authentication changes that includes creation, deletion, or modification of 

user accounts and any changes to groups or group membership. The WIDS/WIPS components must log 

any attempt for escalation of privileges. The WIDS/WIPS components must log when there are any 

configuration changes and whether or not the changes were successful. The WIDS/WIPS controller must 

also log the status of the WIDS/WIPS sensors and must include when a new sensor is connected, when a 

sensor is unreachable, and any sensor error status. These system logs are for the purpose of monitoring 

the WIDS/WIPS for any possible errors and potential security issues and should be used with any 

additional guidance required for CM within the solution.

WIDS/WIPS CONTINUOUS MONITORING 

When deploying a WIDS/WIPS, logging and notification of the events within the controlled space are 

required for the proper operations and to maintain security of the controlled space. The WIDS/WIPS 

must have the capability to create notifications and alerts of events that it has detected. The AO may 

deem that this alerting and notification capability of the WIDS/WIPS meets their needs for CM of the 

controlled space. The AO alternatively can integrate the WIDS/WIPS into a SIEM that notifies and alerts 

their security administrators of events that are detected by the WIDS/WIPS. In this case, a WIDS/WIPS 

must support integration of its event logs into a SIEM and either sends its notifications to a SIEM, or set 

up the SIEM to create notifications of the events itself. The AO and local policy will dictate how often 
 

43

these events, logs and notifications must be reviewed but it is recommended that the time frame 

between reviews be no longer than one week.

Either the SIEM, or the WIDS/WIPS interface must filter on notifications based on types, severity and 

number of notifications received. If being generated by the WIDS/WIPS interface, notifications should be 

descriptive and should show their significance. The WIDS/WIPS interface should have the capability to 

export events in industry standard formats such as Comma Separated Value (CSV) and Common Log 

Format (CLF). A WIDS/WIPS can be integrated into a larger CM capability in relation to data processing, 

alerting, notification and retention. Even if the WIDS/WIPS is used for notifications, all logs from the 

WIDS/WIPS must be sent to a long term storage system for data retention for the given amount of time. 

The retention time of this data must be decided by the AO and according to IAW policy but it is 

recommended to keep this data for a minimum of a year. 

The interface between the WIDS/WIPS Controller and the management firewall must be monitored as 

part of the management network. The WIDS/WIPS must log and forward to a CM capability the 

following: user events, any failed login attempt, when a new user is created, when a user is added to a 

group, any change is made to group privilege, any user account attribute is changed, and when any 

authentication rule is created or modified. The firewall providing network access must log any attempts 

to conduct a network scan from the WIDS/WIPS or any attempts for the network to scan the WIDS/WIPS 

solution. The firewall must additionally alert on any unusual traffic between the WIDS/WIPS controller 

and the management network. This unusual traffic may include but is not limited to, attempting to use 

unauthorized ports or protocols, attempting to contact an IP address outside of the management 

network, or a large amount of traffic traversing the firewall. The firewall and controller must log if any 

protocol outside SSH, ESP or TLS is being used to log into the WIDS/WIPS. The firewall must log any DNS 

queries from the WIDS/WIPS controller to a domain outside of its management network. The 

WIDS/WIPS Controller needs to log any configuration changes made to it or its sensors to the networks 

CM capability. Finally, the WIDS/WIPS controller must have a recurring vulnerability scan conducted 

within a time designated by the AO and relevant governing policies.

WIRELESS INTRUSION DETECTION & WIRELESS INTRUSION PREVENTION

See Sections 6 & 7 respectively for WIDS & WIPS requirements. In those sections, ignore any specific 

CSfC requirements that refer to the Campus WLAN and MA CP requirements. If the deployed WIDS 

solutions do not monitor a WLAN Access System, then disregard Section 6.1.1. Section 6.1.1 only covers 

the monitoring of an authorized WLAN Access System within a controlled space. A WIPS may not be 

needed if a WLAN Access System is not being monitored. A WIPS focuses on defending a WLAN Access 

System from unauthorized connections. The WIPS still retains the capability to prevent connections from 

forming within the controlled space. If that is the desired effect, then the WIPS solution may still be 

deployed at the discretion of the AO.
 

44

APPENDIX B. GLOSSARY OF TERMS

Authorizing Official (AO) – A senior (Federal) official or executive with the authority to formally assume 

responsibility for operating an information system at an acceptable level of risk to organizational 

operations (including mission, functions, image, or reputation), organizational assets, individuals, other 

organizations, and the Nation. 

Assurance – Measure of confidence that the security features, practices, procedures, and architecture of 

an information system accurately mediates and enforces the security policy (CNSSI 4009).

Audit – The activity of monitoring the operation of a product from within the product. It includes 

monitoring of a product for a set of pre-determined events. Each audit event may indicate rogue 

behavior, or a condition that is detrimental to security, or provide necessary forensics to identify the 

source of rogue behavior.

Audit Log – A chronological record of the audit events that have been deemed critical to security. The 

audit log can be used to identify potentially malicious activity that may further identify the source of an 

attack, as well as potential vulnerabilities where additional countermeasures or corrective actions are 

required.

Availability – Ensuring timely and reliable access to and use of information (NIST SP 800-37).

Black Network – A network that contains classified data that has been encrypted twice.

Capability Package (CP) – The set of guidance provided by NSA that describes recommended 

approaches to composing COTS components to protect classified information for a particular class of 

security problem. CP instantiations are built using products selected from the CSfC Components List.

Commercial National Security Algorithm (CNSA) - Set of commercial algorithms capable of protecting 

data through Top Secret level (previously known as Suite B).

Committee on National Security Systems Policy No. 15 (CNSSP-15) – Policy specifies which public 

standards may be used for cryptographic protocol and algorithm interoperability to protect NSS.

Confidentiality – Assurance that the data stored in, processed by, or transmitted by the system are 

protected against unauthorized disclosure, and confidence that only the appropriate set of individuals or 

organizations would be provided the information.

End User Device (EUD) – A form-factor agnostic component of the Mobile Access solution that can 

include a mobile phone, tablet, or laptop computer. 

Federal Information Processing Standards (FIPS) – A set of standards that describe the handling and 

processing of information within governmental agencies.

Gray Network – A network that contains classified data that has been encrypted once 

Malicious – Any unauthorized events that are either unexplained or in any way indicate adversary 

activity.
 

45

Red Network – A network that contains classified data that is not encrypted 

Security Level – The combination of classification level, list of compartments, dissemination controls, 

and other controls applied to the information within a network.

Transport Layer Security (TLS) Client – A component on a TLS EUD that can provides the Inner layer of 

Data in Transit encryption.
 

46

APPENDIX C. ACRONYMS

Acronym Meaning

AO Authorizing Official

AP Access Point

BLE Bluetooth Low Energy

CLF Common Log Format

CM Continuous Monitoring 

CNSA Commercial National Security Algorithms

CNSS Committee on National Security Systems

CNSSI Committee on National Security Systems Instruction

CNSSP Committee on National Security Systems Policy

COTS Commercial Off-the-Shelf 

CP Capability Package

CSD Cybersecurity Directorate

CSfC Commercial Solutions for Classified

CSS Cybersecurity Solutions

CSV Comma Separated Value

DDoS Distributed Denial of Service 

DHCP Dynamic Host Configuration Protocol

D/NM Deputy National Manager

DNS Domain Name System

DoS Denial of Service

DTLS Direct Transport Layer Security

EUD End User Device 
 

47

Acronym Meaning

FIPS Federal Information Processing Standards 

FTP File Transfer Protocol

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

GSM Global System for Mobile Communication

IAW In Accordance With

IDS Intrusion Detection System 

IoT Internet of Things

IEEE Institute of Electrical and Electronics Engineers

IP Internet Protocol

IPS Intrusion Prevention System

IPsec Internet Protocol Security

ISM Industrial, Scientific and Medical band

LAP Lower Address Part

LE Low Energy

LTE Long Term Evolution

MA Mobile Access

MAC Media Access Control

NAP Non-Significant Address Part

NIAP National Information Assurance Partnership

NIST National Institute of Standards and Technology

NSA National Security Agency

NSS National Security Systems 
 

48

Acronym Meaning

NTP Network Time Protocol

O Objective

OUI Organizationally Unique Identifier

RADIUS Remote Authentication Dial in User Service

RSA Rivest Shamir Adelman algorithm

RSSI Received Signal Strength Indicator

SAP Significant Address Part

SCRM Supply Chain Risk Management

SIEM Security Information and Event Manager

SSH Secure Shell

SSID Service Set Identifier

SSHv2 Secure Shell Version 2

T Threshold

TLS Transport Layer Security

UAP Upper Address Part

VLAN Virtual Local Area Network

WIDS Wireless Intrusion Detection System

WIPS Wireless Intrusion Prevention System

WLAN Wireless Local Area Network

WPA Wi-Fi- Protected Access

WPA2 Wi-Fi Protected Access II

WPA3 Wi-Fi Protected Access 3
 

49

Acronym Meaning

WPAN Wireless Personal Area Network

VPN Virtual Private Network
 

50

APPENDIX D. REFERENCES

CNSSI 4009 CNSSI 4009, National Information Assurance (IA) Glossary Committee for 

National Security Systems.

http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf

April 2015

CNSSP 15 CNSS Policy (CNSSP) Number 15, National Information Assurance Policy on 

the Use of Public Standards for the Secure Sharing of Information Among 

National Security Systems Committee for National Security Systems

October 

2016

CNSSD 505 CNSS Directive (CNSSD) Number 505, Supply Chain Risk Management 

(SCRM)

March 

2012

FIPS 140 Federal Information Processing Standard 140, Security Requirements For 

Cryptographic Modules National Institute for Standards and Technology 

FIPS Publication

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

May 2001

FIPS 180 Federal Information Processing Standard 180-4, Secure Hash Standard 

(SHS)

March 

2012

FIPS 186 Federal Information Processing Standard 186-4, Digital Signature 

Standard (DSS)

July 2013

FIPS 197 Federal Information Processing Standard 197, Advanced Encryption 

Standard (AES)

November 

2001

FIPS 201 Federal Information Processing Standard 201, Personal Identity 

Verification (PIV) of Federal Employees and Contractors National Institute 

for Standards and Technology FIPS Publication

http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

March 

2006

ISO 09594-8 Iso9594-8 Information Technology-Open Systems Interconnection-The 

Directory: Authentication Framework, 2001

March 

2013

Commercial 

National 

Security 

Algorithm 

Suite

NSA Guidance on Encryption Algorithms

https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm

December 

2015

RFC 3711 IETF RFC 3711 The Secure Real-Time Transport Protocol (SRTP). M. 

Baugher and D. McGrew.

March

2004

RFC 4252 IETF RFC 4252 The Secure Shell (SSH) Authentication Protocol. T. Ylonen 

and C. Lonvick.

January 

2006

RFC 4253 IETF RFC 4253 The Secure Shell (SSH) Transport Layer Protocol. T. Ylonen 

and C. Lonvick.

January 

2006

RFC 4254 IETF RFC 4254 The Secure Shell (SSH) Connection Protocol. T. Ylonen and 

C. Lonvick.

January 

2006

RFC 4256 IETF RFC 4256 Generic Message Exchange Authentication for the Secure 

Shell Protocol (SSH). F. Cusack and M. Forssen.

January 

2006

RFC 4492 IETF RFC 4492 Elliptic Curve Cryptography (ECC) Cipher Suites for 

Transport Layer Security (TLS). S. Blake-Wilson, N. Bolyard, V. Gupta, C. 

Hawk Corriente, B. Moeller, and Ruhr-Uni Bochum.

May 2006
 

51

RFC 5246 IETF RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2. T. 

Dierks and E. Rescorla.

August 

2008

RFC 5996 IETF RFC 5996 Internet Key Exchange Protocol Version 2 (IKEv2). 

C. Kaufman, et. al.

September 

2010

RFC 6188 IETF RFC 6188 The Use of AES 192 and AES 256 in Secure RTP. D. McGrew. March 

2011

RFC 6239 IETF RFC 6239 Suite B Cryptographic Suites for Secure Shell (SSH). K. Igoe. May 2011

RFC 6379 IETF RFC 6379 Suite B Cryptographic Suites for IPsec. L. Law and J. Solinas. October 

2011

RFC 6380 IETF RFC 6380 Suite B Profile for Internet Protocol Security (IPsec). K. 

Burgin and M. Peck.

October 

2011

RFC 6460 IETF RFC 6460 Suite B Profile for Transport Layer Security (TLS). M. Salter 

and R. Housley.

January 

2012

SP 800-53 NIST Special Publication 800-53 Rev. 4, Security and Privacy Controls for 

Federal Information Systems and Organizations. Joint Task Force 

Transformation Initiative.

April 2013

SP 800-56A NIST Special Publication 800-56A Rev. 2, Recommendation for Pair-Wise 

Key Establishment Schemes Using Discrete Logarithm Cryptography. E. 

Barker, et. al.

May 2013

EG v 1.0 CSfC Enterprise Gray Implementation Requirements Annex v1.0 April 2019

CM v 1.0 CSfC Continuous Monitoring Annex v1.0 4 August 

2021

CWLAN v 2.3 CSfC Campus Wireless Local Area Network Capability Package v2.3 4 August 

2021

MACP v 2.5 CSfC Mobile Access Capability Package v2.5 4 August 

2021