Version: 2.0
2022-09-30
National Information Assurance Partnership
| Version | Date | Comment |
|---|---|---|
| 2.0 | 2022-09-30 | Added 6 GHz spectrum slice |
| 1.0 | 2020-09-30 | Initial Release - PP-Module for NDcPP |
This Protection Profile Module (PP-Module) describes security requirements for a 802.11 Wireless Intrusion Detection System (WIDS) defined to be an IEEE 802.11 network intrusion detection product located at the edge of a private network that can collect, inspect, and analyze real-time network traffic and alert the administrator of policy violations. This PP-Module is intended to provide a minimal baseline set of requirements that are targeted at mitigating well defined and described threats.
This PP-Module contains optional requirements for a Wireless Intrusion Protection System (WIPS), a security product that in addition to the 802.11 WIDS capability, provides network security administrators with the additional ability to react in real-time to potentially malicious wireless (IEEE 802.11) network traffic.
This PP-Module is intended for use with the following Base-PP:
A TOE that conforms to a PP-Configuration containing this PP-Module must be a 'Distributed TOE' as defined in the NDcPP. The expectation for this PP-Module is that a WIDS must include distributed sensor nodes to ensure that the full physical range of a wireless network to ensure that user interactions with the network cannot evade detection.
A part or parts of the TOE that have to be relied upon for enforcing a closely related subset of the rules from the TSP. The security policy enforced by an SF.Assurance | Grounds for confidence that a TOE meets the SFRs [CC]. |
Base Protection Profile (Base-PP) | Protection Profile used as a basis to build a PP-Configuration. |
Collaborative Protection Profile (cPP) | A Protection Profile developed by international technical communities and approved by multiple schemes. |
Common Criteria (CC) | Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408). |
Common Criteria Testing Laboratory | Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations. |
Common Evaluation Methodology (CEM) | Common Evaluation Methodology for Information Technology Security Evaluation. |
Distributed TOE | A TOE composed of multiple components operating as a logical whole. |
Functional Package (FP) | A document that collects SFRs for a particular protocol, technology, or functionality. |
Operational Environment (OE) | Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy. |
Protection Profile (PP) | An implementation-independent set of security requirements for a category of products. |
Protection Profile Configuration (PP-Configuration) | A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module. |
Protection Profile Module (PP-Module) | An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs. |
Security Assurance Requirement (SAR) | A requirement to assure the security of the TOE. |
Security Function (SF) | A part or parts of the TOE that have to be relied upon for enforcing a closely related subset of the rules from the TSP. |
Security Function Policy (SFP) | The security policy enforced by an SF. |
Security Functional Requirement (SFR) | A requirement for security enforcement by the TOE. |
Security Target (ST) | A set of implementation-dependent security requirements for a specific product. |
Target of Evaluation (TOE) | The product under evaluation. |
TOE Security Functionality (TSF) | The security functionality of the product under evaluation. |
TOE Summary Specification (TSS) | A description of how a TOE satisfies the SFRs in an ST. |
Access Point (AP) | A device that provides the network interface that enables 802.11 wireless client hosts to access a wired network. |
End User Device (EUD) | An 802.11 enabled device that has the ability to process, transmit, and/or store information. |
Service Set Identifier (SSID) | The primary name associated with an 802.11 wireless local area network (WLAN). |
Wireless Intrusion Detection System (WIDS) | A security product that provides network security administrators with the ability to monitor, collect, and log real-time to potentially malicious wireless (IEEE 802.11) network traffic. |
Wireless Intrusion Prevention System (WIPS) | A security product that provides network security administrators with the ability to monitor, collect, log, and react in real-time to potentially malicious wireless (IEEE 802.11) network traffic. |
Wireless Local Area Network (WLAN) | An 802.11 wireless computer network that links two or more devices using wireless communication to form a local area network (LAN) within a limited area such as a home, school, computer laboratory, campus, office building etc. |
This PP-Module specifically addresses WIDS/WIPS. A conformant WIDS is a product that can monitor, collect, inspect, and analyze real-time network traffic and alert the administrator of policy violations. WIPS functionality is not required to conform to this PP-Module, and it is optional for the TOE to have the additional ability to react in real-time to potentially malicious wireless (IEEE 802.11) network traffic.
A WIDS/WIPS TOE consists of multiple sensors that passively scan the RF environment on the WLAN radio frequency spectrum and a centralized mechanism such as a Server or Controller that processes the data collected by the sensors. Conformant TOEs must use a secure communication path(s) between WIDS/WIPS components.
A WIDS/WIPS can be Integrated (be part of the WLAN infrastructure) or Standalone (independent from WLAN) architecture depending on vendor implementation. The two different architectures are illustrated in Figure 1 below. The TOE boundary is indicated by the yellow box.
A WIDS/WIPS is expected to inspect layers 1 and 2 network traffic, per the OSI network model, and monitor wireless frames in the RF spectrum utilized by IEEE 802.11 a, b, g, n, and ac. Monitoring and inspection of other technologies (e.g., cellular) and protocols are optional.
Conformant TOEs will detect potentially malicious network traffic using various approaches. Broadly speaking, the traffic analysis could be based on identification of 'known' threats, or 'unknown' threats. Identification of 'known' threats may be performed through pattern matching, (e.g. by matching strings of characters within a frame with known patterns, or by matching traffic patterns common with reconnaissance or denial of service (DoS) attacks). Identification of 'unknown' threats may be performed through use of various forms of anomaly detection whereby the WIDS/WIPS is provided with (or learns/creates) a definition of expected/typical traffic patterns, such that it’s able to detect and react to anomalous (unexpected/atypical) traffic patterns.
A WIDS consists of sensors (preferably dedicated) and a central controller working together to provide 24/7 monitoring, primarily to the 802.11 Wireless Local Area Network (WLAN) spectrum and protocol, to detect, identify, and geolocate WLAN devices within a controlled space.
The WIDS may be capable of detecting or monitoring traffic other than 802.11 WLAN, such as 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. 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.
This PP-Module inherits exact conformance as required from the specified Base-PP and as defined in the CC and CEM addenda for Exact Conformance, Selection-based SFRs, and Optional SFRs (dated May 2017).
The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module.
WIDS address a range of security threats related to detection of and reaction to potentially malicious WLAN traffic. The malicious traffic may pose a threat to one or more endpoints on the monitored networks, to the network infrastructure, or to the TOE itself. Attacks against a WLAN could compromise the confidentiality and integrity of WLAN users and system data as well as the availability of the WLAN to legitimate users.
The term “monitored network” is used here to represent
any WLAN and/or wired network that the TOE is configured to monitor and detect intrusions on.
This extends to the wired networks as intrusions on the wireless network can also be damaging to
the wired infrastructure. The WIDS/WIPS also protect the wired infrastructure by detecting rogue
devices that are directly connected to the wired infrastructure, which may expose the wired
network, or unauthorized WLAN devices deployed in a no-wireless zone.
The proper installation, configuration, and administration of the WIDS is critical to
its correct operation. A site is responsible for developing its security policy and configuring
a rule set that the WIDS will enforce and provide an appropriate response to meet their needs,
relative to their own risk analysis and their perceived threats.
Note that this PP-Module does not repeat the threats identified in the NDcPP, though they all apply given the conformance and hence dependence of this PP-Module on the NDcPP. Note also that while the NDcPP contains only threats to the ability of the TOE to provide its security functions, this PP-Module addresses only threats to resources in the operational environment. Together the threats of the NDcPP and those defined in this PP-Module define the comprehensive set of security threats addressed by a WIDS TOE.
An organization deploying the TOE is expected to satisfy the organizational security policy listed below in addition to all organizational security policies defined by the claimed Base-PP.
To be able to analyze and react to potential network policy violations, the WIDS must be able to collect and store essential data elements of network traffic on monitored networks. A conformant TOE may also implement a self-protection mechanism to ensure that undetected network policy violations cannot occur when a sensor is unavailable.
The WIDS must be able to analyze collected or observed WLAN activity on monitored network to identify potential violations of approved WLAN policies, unauthorized connections involving internal WLAN devices, and non-secure communications.
The TOE must be able to react, as configured by the administrators, to configured policy violations or other potential malicious activity.
To address the threat of unauthorized administrator access that is defined in the Base-PP, conformant TOEs will provide the functions necessary for an administrator to configure the WIDS capabilities of the TOE. A conformant TOE may also implement a self-protection mechanism to ensure that a TSF failure cannot be used as a way to modify the TOE's configuration without authorization.
| Threat, Assumption, or OSP | Security Objectives | Rationale |
| T.UNAUTHORIZED_DISCLOSURE_OF_INFORMATION | O.SYSTEM_MONITORING | The threat T.UNAUTHORIZED_DISCLOSURE_OF_INFORMATION is countered by O.SYSTEM_MONITORING as this provides for visibility into the network which enables detection of network violations. |
| O.TRUSTED_COMMUNICATIONS | The threat T.UNAUTHORIZED_DISCLOSURE_OF_INFORMATION is countered by O.TRUSTED_COMMUNICATIONS as this ensures that data in transit is protected from unauthorized disclosure through authentication of endpoints and use of trusted protocols. | |
| O.WIDS_ANALYZE | The threat T.UNAUTHORIZED_DISCLOSURE_OF_INFORMATION is countered by O.WIDS_ANALYZE as this provides detection of potential violations of approved network usage. | |
| O.WIDS_REACT | The threat T.UNAUTHORIZED_DISCLOSURE_OF_INFORMATION is countered by O.WIDS_REACT as this provides containment of unauthorized APs and EUDs. | |
| T.UNAUTHORIZED_ACCESS | O.SYSTEM_MONITORING | The threat T.UNAUTHORIZED_ACCESS is countered by O.SYSTEM_MONITORING as this provides for visibility into the network which enables detection of unauthorized APs and EUDs. |
| O.WIDS_ANALYZE | The threat T.UNAUTHORIZED_ACCESS is countered by O.WIDS_ANALYZE as this provides detection of potential violations of approved network usage. | |
| O.WIDS_REACT | The threat T.UNAUTHORIZED_ACCESS is countered by O.WIDS_REACT as this provides containment of unauthorized APs and EUDs. | |
| O.TOE_ADMINISTRATION | The threat T.UNAUTHORIZED_ACCESS is countered by O.TOE_ADMINISTRATION. | |
| T.DISRUPTION | O.SYSTEM_MONITORING | The threat T.DISRUPTION is countered by O.SYSTEM_MONITORING as this provides for visibility into the network which enables detection of DoS attacks. |
| O.WIDS_ANALYZE | The threat T.DISRUPTION is countered by O.WIDS_ANALYZE as this provides for detection of potential violations of approved network usage. | |
| O.WIDS_REACT | The threat T.DISRUPTION is countered by O.WIDS_REACT as this provides containment of unauthorized APs and EUDs. | |
| A.CONNECTIONS | OE.CONNECTIONS | The operational environment objective OE.CONNECTIONS is realized through A.CONNECTIONS. |
| A.PROPER_ADMIN | OE.PROPER_ADMIN | The operational environment objective OE.PROPER_ADMIN is realized through A.PROPER_ADMIN. |
| P.ANALYZE | O.WIDS_ANALYZE | The organizational security policy P.ANALYZE is facilitated through O.WIDS_ANALYZE. |
FPT_ITT.1 is optional in NDcPP, however, since a WIDS/WIPS TOE is distributed, FPT_ITT.1 shall be included in the ST and is applicable to the data transmitted between the sensors and controller.
This requirement ensures all communications between components of a distributed TOE is protected through the use of an encrypted communications channel. The data passed in this trusted communication channel are encrypted as defined in the protocol chosen in the selection. The ST author chooses the mechanisms supported by the TOE, and then ensures that the detailed protocol requirements in Appendix B of NDcPP corresponding to their selection are included in the ST, if not already present.
This SFR is modified from its definition in the Base-PP by adding a selection for a database server capability. If the TSF uses a separate database server to support its security-relevant functionality, this selection must be included in the ST.
The intent of the database server is to store WIDS/WIPS data that must be queryable, such as events/alarms, triangulation calculations, wireless spectrum analysis (including RF jammer/Denial of Service (DoS)), and packet capture analysis. Authorized Administrators must be permitted to view alarms, raw event data, and any other data stored in the database. The Administrator must access the database through a trusted channel if done so remotely.
The intent of this requirement is to provide a means by which a cryptographic protocol may be used to protect external communications with authorized IT entities that the TOE interacts with to perform its functions. The TOE uses at least one of the listed protocols for communications with the server that collects the audit information.
If other authorized IT entities are protected, the ST author makes the appropriate assignments (for those entities) and selections (for the protocols that are used to protect those connections). The ST author selects the mechanism or mechanisms supported by the TOE, and then ensures that the detailed protocol requirements in Appendix B of NDcPP corresponding to their selection are included in the ST.
If "capture raw frame traffic that triggers the violation" is selected then FAU_STG_EXT.1/PCAP must be included in the ST.
FAU_SAA.1 defines the rules for monitoring the wireless traffic to detect for potential security violations. FAU_INV_EXT.2 defines the information the TOE needs to collect for all APs and EUDs within range of the the TOE's sensors. Device attributes can then be individually filtered and/or selected in order to be displayed as part of the alert.
| Requirement | Auditable Events | Additional Audit Record Contents |
| FAU_ANO_EXT.1 (selection-based) | None | None |
| FAU_ARP.1 | Actions taken due to potential security violations | None |
| FAU_ARP_EXT.1 | None | None |
| FAU_GEN.1/WIDS | Any authentication event | Failed login attempts, successful login attempts, administrator logins, changes to the WIDS native authentication system (creation of an account, deletion of an account, modification of user accounts, changes to groups or group membership, attempts for privilege escalation) |
| FAU_IDS_EXT.1 | None | None |
| FAU_INV_EXT.1 | Presence of allowlisted device | Type of device (AP or EUD), MAC Address |
| FAU_INV_EXT.2 | None | None |
| FAU_INV_EXT.3 | Location of AP or EUD | MAC Address, device type, classification of device, sensor(s) that detected device, signal strength as received by detecting sensor(s), proximity to detecting sensor(s) |
| FAU_INV_EXT.4 (objective) | None | None |
| FAU_INV_EXT.5 (objective) | None | None |
| FAU_MAC_EXT.1 (objective) | None | None |
| FAU_RPT_EXT.1 | None | None |
| FAU_SAA.1 | None | None |
| FAU_SIG_EXT.1 (selection-based) | None | None |
| FAU_STG_EXT.1/PCAP (selection-based) | None | None |
| FAU_WID_EXT.1 | Detection of rogue AP or EUD | None |
| Detection of unauthorized SSID | None | |
| FAU_WID_EXT.2 | Sensor wireless transmission capabilities | Wireless transmission capabilities are turned on |
| FAU_WID_EXT.3 (optional) | Detection of network devices operating in selected RF bands | Frequency band, channel used within frequency band, identification information (MAC address if applicable or other similar unique ID), device technology (i.e., cellular), sensor(s) that detected devices |
| FAU_WID_EXT.4 (optional) | None | None |
| FAU_WIP_EXT.1 (objective) | Isolation of AP or EUD | Description of violation, type of containment used, was containment triggered manually or automatically, sensor performing the containment (if wireless), details about the device (s) being contained (classification, device type, MAC address) |
| FDP_IFC.1 | None | None |
| FMT_SMF.1/WIDS | None | None |
| FPT_FLS.1 (objective) | Information about failure | Indication that there was a failure, type of failure, device that failed, sensor connectivity and operating status, and time of failure |
The auditable events defined in Table 2 are for the SFRs that are explicitly defined in this PP-Module and are intended to extend FAU_GEN.1 in the Base-PP. The events in the Auditable Events table should be combined with those of the NDcPP in the context of a conforming Security Target.
The Auditable Events (Table 2) includes optional and objective SFRs. The auditing of optional and objective SFRs is only required if that SFR is included in the ST.
Per FAU_STG_EXT.1 in the Base-PP, the TOE must support transfer of the audit data to an external IT entity using a trusted channel.
At least one detection method must be selected. If multiple detection methods are supported, each supported method must be selected.
If anomaly-based detection is selected, then FAU_ANO_EXT.1 shall be included in the ST. If signature-based detection is selected, then FAU_SIG_EXT.1 shall be included in the ST.
This inventory is used as an allowlist to indicate to the WIDS which APs and EUDs are authorized members of the wireless network. The inventory of authorized APs and EUDs is configured by FMT_SMF.1/WIDS.
The terminology used to describe an inventoried or allowlisted device may vary by vendor product. This PP-Module utilizes allowlisted to describe APs and EUDs that are part of the inventory and non-allowlisted to describe APs and EUDs that are not part of the inventory.
These rules are used to detect a potential security violation. Maintenance of the rules by adding, modifying or deletion of rules from the set of rules is handled by FMT_SMF.1/WIDS.
If a potential security violation is detected the alert generated for the Administrator is handled by FAU_ARP.1.
If nonsimultaneously is selected, then Define the amount of time sensor monitors a specific channel must be selected in FMT_SMF.1/WIDS.
The "802.11 monitoring SFP" is a security function policy and the SFRs that reference this policy describe what the policy does. The "802.11 monitoring SFP" is established in FDP_IFC.1 and defined through FAU_WID_EXT.1, FAU_WID_EXT.2, in addition to optional SFRs FAU_WID_EXT.3 and FAU_WID_EXT.4. A vendor does not have to formally define this policy, it only needs to comply with the SFRs.
If "can be configured to prevent transmission of data" is selected then "Enable/Disable transmission of data by wireless sensor" must be selected in FMT_SMF.1/WIDS.
The intent of this SFR is to employ WIDS sensors that can have all wireless transmission capabilities disabled for instances where a site wishes to implement a no wireless policy.
The "802.11 monitoring SFP" is a security function policy and the SFRs that reference this policy describe what the policy does. The "802.11 monitoring SFP" is established in FDP_IFC.1 and defined through FAU_WID_EXT.1, FAU_WID_EXT.2, in addition to optional SFRs FAU_WID_EXT.3 and FAU_WID_EXT.4. A vendor does not have to formally define this policy, it only needs to comply with the SFRs.
"Authorized" EUDs/APs are those that are assigned to the allowlist as defined by FMT_SMF.1/WIDS.
The "802.11 monitoring SFP" is a security function policy and the SFRs that reference this policy describe what the policy does. The "802.11 monitoring SFP" is established in FDP_IFC.1 and defined through FAU_WID_EXT.1, FAU_WID_EXT.2, in addition to optional SFRs FAU_WID_EXT.3 and FAU_WID_EXT.4. A vendor does not have to formally define this policy, it only needs to comply with the SFRs.
Define authorized WLAN authentication and encryption schemes does not enforce, but rather establishes a baseline to determine if an unauthorized scheme is used.
If FAU_ANO_EXT.1 is included in the ST, "Specification of periods of network activity that constitute baseline of expected behavior" must be selected. If FAU_ANO_EXT.1 is included in the ST and "manual configuration by administrators" is selected in FAU_ANO_EXT.1, then "Definition of anomaly activity" must be selected.
If "can be configured to prevent transmission of data" is selected in FAU_WID_EXT.2 then "Enable/Disable transmission of data by wireless sensor" must be selected.
It is expected that an Authorized Administrator will be responsible for configuring the AP to operate on a specific frequency pursuant to the 802.11 standard. The TSF will have the ability to adjust the amount of time it passively monitors and captures WLAN traffic on a given frequency and channel.
The following rationale provides justification for each security objective for the TOE,
showing that the SFRs are suitable to meet and achieve the security objectives:
| Objective | Addressed by | Rationale |
|---|---|---|
| O.SYSTEM_MONITORING | FAU_GEN_EXT.1 (from Base-PP) | FAU_GEN_EXT.1 supports the objective by requiring the TSF to identify the records of its own operation that its various components generate. |
| FAU_STG_EXT.1 (from Base-PP) | FAU_STG_EXT.1 supports the objective by requiring the TSF to implement an external storage method for the records it generates of its own operation. | |
| FAU_GEN.1/WIDS | FAU_GEN.1/WIDS supports the objective by defining the auditable events that the TSF must implement in support of the behavior this PP-Module defines. | |
| FAU_RPT_EXT.1 | FAU_RPT_EXT.1 supports the objective by requiring the TSF to implement an external import and reporting mechanism for its monitoring data to integrate with third-party components. | |
| FAU_STG_EXT.1/PCAP | FAU_STG_EXT.1/PCAP supports the objective by defining an optional reporting mechanism for monitored data. | |
| FPT_FLS.1 (objective) | FPT_FLS.1 supports the objective by ensuring that a potential sensor failure triggers the TOE to fail into a secure state which prevents undetected wireless communications. | |
| O.WIDS_ANALYZE | FAU_ARP.1 | FAU_ARP.1 supports the objective by defining how the TSF must react when data consistent with an IDS violation is collected. |
| FAU_ARP_EXT.1 | FAU_ARP_EXT.1 supports the objective by defining a filtering method that the TSF may implement to suppress certain reactions. | |
| FAU_IDS_EXT.1 | FAU_IDS_EXT.1 supports the objective by defining the specific IDS methods that the TSF may implement to detect potential malicious activity. | |
| FAU_INV_EXT.1 | FAU_INV_EXT.1 supports the objective by defining how the TSF takes an inventory of allowed and disallowed devices in its operational environment. | |
| FAU_INV_EXT.2 | FAU_INV_EXT.2 supports the objective by requiring the TSF to collect and report on specific properties of inventoried devices. | |
| FAU_INV_EXT.3 | FAU_INV_EXT.3 supports the objective by requiring the TSF to implement measures that can be used to determine the physical location of inventoried devices. | |
| FAU_SAA.1 | FAU_SAA.1 supports the objective by defining the specific conditions that the TSF must apply to determine if collected data is indicative of potential malicious activity. | |
| FAU_WID_EXT.1 | FAU_WID_EXT.1 supports the objective by requiring the TSF to implement a method to distinguish between benign and malicious devices in its operational environment. | |
| FAU_WID_EXT.2 | FAU_WID_EXT.2 supports the objective by requiring the TSF to implement stateful monitoring of network traffic on various RF bands. | |
| FDP_IFC.1 | FDP_IFC.1 supports the objective by defining the specific network traffic that the TSF must have the ability to monitor. | |
| FAU_WID_EXT.3 (optional) | FAU_WID_EXT.3 supports the objective by optionally requiring the TSF to detect network devices operating on frequency bands beyond what is required by FAU_WID_EXT.2. | |
| FAU_WID_EXT.4 (optional) | FAU_WID_EXT.4 supports the objective by optionally requiring the TOE to implement wireless spectrum analysis functionality on a dedicated sensor. | |
| FAU_ANO_EXT.1 (selection-based) | FAU_ANO_EXT.1 supports the objective by defining the specific anomaly-based detection mechanisms that the TSF is required to implement if it claims to support anomaly-based detection. | |
| FAU_SIG_EXT.1 (selection-based) | FAU_SIG_EXT.1 supports the objective by requiring the TSF to support user-defined and customizable attack signatures if it claims to support signature-based detection. | |
| FAU_INV_EXT.4 (objective) | FAU_INV_EXT.4 supports the objective by optionally requiring the TSF to detect when unauthorized wireless devices connect to a protected network over a wired interface. | |
| FAU_INV_EXT.5 (objective) | FAU_INV_EXT.5 supports the objective by optionally requiring the TSF to include a signal library. | |
| FAU_MAC_EXT.1 (objective) | FAU_MAC_EXT.1 supports the objective by optionally requiring the TSF to detect potential device impersonation through MAC spoofing. | |
| O.WIDS_REACT | FAU_ARP.1 | FAU_ARP.1 supports the objective by defining how the TSF reacts when anomalous or potentially malicious traffic is detected. |
| FAU_SAA.1 | FAU_SAA.1 supports the objective by defining potentially malicious traffic patterns that the TSF must detect. | |
| FMT_SMF.1/WIDS | FMT_SMF.1/WIDS supports the objective by allowing administrators to define potentially malicious or anomalous behavior. | |
| FAU_ANO_EXT.1 (selection-based) | FAU_ANO_EXT.1 supports the objective by optionally requiring the TSF to detect when traffic is detected that meets a condition for anomalous behavior. | |
| FAU_WIP_EXT.1 (objective) | FAU_WIP_EXT.1 supports the objective by requiring the TSF to implement wireless containment as a method of enforcing wireless intrusion prevention. | |
| O.TOE_ADMINISTRATION | FMT_SMF.1/WIDS | FMT_SMF.1/WIDS supports the objective by requiring the TSF to implement management functions that support its configuration. |
| FPT_FLS.1 (objective) | FPT_FLS.1 supports the objective by ensuring that a potential compromise of the TSF triggers the TOE to fail into a secure state, which prevents unauthorized administration. | |
| O.TRUSTED_COMMUNICATIONS | FCO_CPC_EXT.1 (from Base-PP) | FCO_CPC_EXT.1 supports the objective by ensuring that distributed components are properly registered and authenticated. |
| FPT_ITT.1 (from Base-PP) | FPT_ITT.1 supports the objective by defining the trusted communications protocol used to secure communications between TOE components. | |
| FTP_ITC.1 (from Base-PP) | FTP_ITC.1 supports the objective by defining the trusted communications protocol used to secure communications between the TOE and its operational environment. |
| PP-Module Threat, Assumption, OSP | Consistency Rationale |
|---|---|
| T.UNAUTHORIZED_DISCLOSURE_OF_INFORMATION | This threat is similar to the T.UNDETECTED_ACTIVITY threat in the Base-PP but it applies to the attacker performing malicious actions on the network monitored by the TOE rather than against the TOE itself. |
| T.UNAUTHORIZED_ACCESS | This threat is similar to the T.UNAUTHORIZED_ADMINISTRATOR_ACCESS threat in the Base-PP but it applies to the attacker gaining unauthorized access to an asset on the network monitored by the TOE rather than against the TOE itself. |
| T.DISRUPTION | This threat is for a denial-of-service attack against an asset on the network monitored by the TOE. The Base-PP does not define any threats for availability but there is no consistency issue here because the threat applies to an interface that does not exist in the Base-PP. |
| A.CONNECTIONS | This assumption defines the TOE’s placement in a network such that it is able to perform its required security functionality. The Base-PP does not define any assumptions about the TOE’s architectural deployment so there is no conflict here. |
| A.PROPER_ADMIN | This assumption is comparable to the A.TRUSTED_ADMINISTRATOR assumption from the Base-PP, applied to the specific administrative functions defined in this PP-Module. |
| P.ANALYZE | This organizational security policy expects the data produced by the TSF about the behavior of external entities to be used in an organization’s analytical process. There is no conflict with the Base-PP because the Base-PP does not define any functionality for the TOE to produce data about any entities other than itself. |
The objectives for the TOEs are consistent with the NDcPP based on the following rationale:
| PP-Module TOE Objective | Consistency Rationale |
|---|---|
| O.SYSTEM_MONITORING | The Base-PP does not define any TOE objectives. However, it does define requirements for the collection and secure remote transmission of audit data. The PP-Module adds requirements for the similar handling of network traffic data. |
| O.WIDS_ANALYZE | This objective refers to behavior on wireless interfaces that are beyond the original scope of the Base-PP. |
| O.WIDS_REACT | This objective refers to behavior on wireless interfaces that are beyond the original scope of the Base-PP. |
| O.TOE_ADMINISTRATION | The Base-PP does not define any TOE objectives. However, it does define requirements for the execution of security-relevant management functions. The PP-Module expands upon this by adding requirements for the security-relevant management functions that are introduced by the PP-Module. |
| O.TRUSTED_COMMUNICATIONS | The Base-PP does not define any TOE objectives. However, it clearly intends to ensure that communications are trusted because the SFRs the PP-Module uses to demonstrate this objective is satisfied are derived from the Base-PP. |
The objectives for the TOE's OE are consistent with the NDcPP based on the following rationale:
| PP-Module OE Objective | Consistency Rationale |
|---|---|
| OE.CONNECTIONS | This objective expects the TOE to be placed in a network such that it is able to perform its required security functionality. The Base-PP does not define any objectives about the TOE’s architectural deployment so there is no conflict here. |
| OE.PROPER_ADMIN | This objective is comparable to the OE.TRUSTED_ADMIN objective from the Base-PP, applied to the specific administrative functions defined in this PP-Module. |
| PP-Module Requirement | Consistency Rationale |
|---|---|
| Modified SFRs | |
| FAU_GEN_EXT.1 | This PP-Module mandates the inclusion of this selection-based SFR because a TOE that conforms to this PP-Module will always be deployed in a configuration that requires this SFR to be claimed. |
| FAU_STG_EXT.1 | This PP-Module modifies the Base-PP SFR to remove a selection that is not permitted by the TOE architecture that it specifies. |
| FCO_CPC_EXT.1 | This PP-Module mandates the inclusion of this optional SFR because it is required to implement functionality required by this PP-Module. |
| FPT_ITT.1 | This PP-Module mandates the inclusion of this optional SFR because it is required to implement functionality required by this PP-Module. |
| FTP_ITC.1 | This PP-Module refines the Base-PP SFR to add a selection for a specific external entity that may be applicable to a TOE that conforms to this PP-Module. |
| Additional SFRs | |
| This PP-Module does not add any requirements when the NDcPP is the base. | |
| Mandatory SFRs | |
| FAU_ARP.1 | This SFR defines operations to be performed on collected WIDS data, which is collected using an external interface defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_ARP_EXT.1 | This SFR defines operations to be performed on collected WIDS data, which is collected using an external interface defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_GEN.1/WIDS | This SFR iterates the FAU_GEN.1 SFR defined in the Base-PP to define auditable events for the functionality that is specific to this PP-Module. |
| FAU_IDS_EXT.1 | This SFR defines operations to be performed on collected WIDS data, which is collected using an external interface defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_INV_EXT.1 | This SFR defines operations to be performed on assets in the TOE’s operational environment, which is behavior defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_INV_EXT.2 | This SFR defines operations to be performed on assets in the TOE’s operational environment, which is behavior defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_INV_EXT.3 | This SFR defines operations to be performed on assets in the TOE’s operational environment, which is behavior defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_RPT_EXT.1 | This SFR defines operations to be performed on collected WIDS data, which is collected using an external interface defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_SAA.1 | This SFR defines operations to be performed on collected WIDS data, which is collected using an external interface defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_WID_EXT.1 | This SFR defines operations to be performed on assets in the TOE’s operational environment, which is behavior defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_WID_EXT.2 | This SFR defines operations to be performed on assets in the TOE’s operational environment, which is behavior defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FDP_IFC.1 | This SFR defines operations to be performed on assets in the TOE’s operational environment, which is behavior defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FMT_SMF.1/WIDS | This SFR iterates the FMT_SMF.1 SFR defined in the Base-PP to define management functions for the functionality that is specific to this PP-Module. |
| Optional SFRs | |
| FAU_WID_EXT.3 | This SFR defines operations to be performed on assets in the TOE’s operational environment, which is behavior defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_WID_EXT.4 | This SFR defines an optional capability for a distributed component to be dedicated to one particular function. This function (wireless spectrum analysis) is defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_WID_EXT.5 | This SFR defines operations to be performed on assets in the TOE’s operational environment, which is behavior defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_WID_EXT.5 | This SFR defines operations to be performed on assets in the TOE’s operational environment, which is behavior defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| Objective SFRs | |
| FAU_INV_EXT.4 | This SFR defines operations to be performed on assets in the TOE’s operational environment, which is behavior defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_INV_EXT.5 | This SFR defines operations to be performed on assets in the TOE’s operational environment, which is behavior defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_MAC_EXT.1 | This SFR defines operations to be performed on assets in the TOE’s operational environment, which is behavior defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_WIP_EXT.1 | This SFR defines WIPS behavior in response to detection of potential malicious activity in the TOE’s operational environment. This extends the logical scope of the TOE beyond what the Base-PP defines. |
| FPT_FLS.1 | This SFR defines preservation of a secure state in the event that a failure condition is detected. The Base-PP does not define an SFR for this behavior but this SFR mitigates the T.SECURITY_FUNCTIONALITY_FAILURE threat defined in the Base-PP, so it is clear that this behavior is consistent with the security expectations of the Base-PP. |
| Implementation-based SFRs | |
| This PP-Module does not define any Implementation-based requirements. | |
| Selection-based SFRs | |
| FAU_ANO_EXT.1 | This SFR defines operations to be performed on collected WIDS data, which is collected using an external interface defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_SIG_EXT.1 | This SFR defines operations to be performed on collected WIDS data, which is collected using an external interface defined in this PP-Module that extends the logical scope of the TOE beyond what the Base-PP defines. |
| FAU_STG_EXT.1/PCAP | This SFR iterates the FAU_STG_EXT.1 SFR defined in the Base-PP for storage of audit data and applies it to storage of packet captures. |
It is expected that an Authorized Administrator will be responsible for confirming the AP or EUD as a rogue AP or EUD to initiate wireless containment.
In this SFR the containment of an an unauthorized AP connected to the internal corporate wired network refers to an unauthorized AP that is physically connected (via wire) to the protected internal wired infrastructure.
This PP-Module does not define any Implementation-based SFRs.
| Functional Class | Functional Components |
|---|---|
| Security Audit (FAU) | FAU_ANO_EXT Anomaly-Based Intrusion Detection FAU_ARP_EXT Security Alarm Filtering FAU_IDS_EXT Intrusion Detection Methods FAU_INV_EXT Environmental Inventory FAU_MAC_EXT Device Impersonation FAU_RPT_EXT Reporting Methods FAU_SIG_EXT Signature-Based Intrusion Detection FAU_WID_EXT Wireless Intrusion Detection FAU_WIP_EXT Wireless Intrusion Prevention |
FAU_ARP_EXT.1, Security Alarm Filtering, requires the TSF to implement a filtering mechanism to selectively suppress the generation of security alarms.
No specific management functions have been identified.
There are no auditable events foreseen.
FAU_IDS_EXT.1, Intrusion Detection System - Intrusion Detection Methods, requires the TSF to specify the methods of intrusion detection that it supports.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FAU_INV_EXT.1, Environmental Inventory, requires the TSF to determine if inventoried objects are authorized or unauthorized.
FAU_INV_EXT.2, Characteristics of Environmental Objects, requires the TSF to discover network assets in its operational environment and maintain an inventory of them based on collected attributes.
FAU_INV_EXT.3, Location of Environmental Objects, requires the TSF to approximate the physical location of network assets in its operational environment based on triangulation of wireless emissions.
FAU_INV_EXT.4, Detection of Unauthorized Connections, requires the TSF to identify if an unauthorized network asset in its inventory is attempting to access a protected network using a wired connection.
FAU_INV_EXT.5, Signal Library, requires the TSF to maintain a signal library.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security Audit Data Generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: | FAU_INV_EXT.2 Characteristics of Environmental Objects |
The following actions could be considered for the management functions in FMT:
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
No specific management functions are identified.
The following actions should be auditable if FAU_GEN Security Audit Data Generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: | FAU_INV_EXT.2 Characteristics of Environmental Objects |
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | FAU_INV_EXT.1 Environmental Inventory |
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FAU_RPT_EXT.1, Intrusion Detection System - Reporting Methods, requires the TSF to implement a specified reporting mechanism for collected data for compatibility with third parties that may consume this data.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | FAU_GEN.1 Audit Data Generation |
FAU_WID_EXT.1, Wireless Intrusion Detection - Malicious Environmental Objects, requires the TSF to implement a mechanism to distinguish between authorized and unauthorized network assets.
FAU_WID_EXT.2, Wireless Intrusion Detection - Passive Information Flow Monitoring, requires the TSF to surveil certain wireless frequency bands and perform stateful inspection of traffic on them.
FAU_WID_EXT.3, Wireless Intrusion Detection - Non-Wireless Spectrum Monitoring, requires the TSF to surveil certain radio frequency bands that fall outside the typical wireless spectrum used by consumer-grade electronics.
FAU_WID_EXT.4, Wireless Intrusion Detection - Wireless Spectrum Analysis, requires the TSF to implement wireless spectrum analysis in a dedicated physical component.
FAU_WID_EXT.5, Wireless Intrusion Detection - Bluetooth Spectrum Monitoring, requires the TSF to surveil certain radio frequency bands that fall outside the typical wireless spectrum used by consumer-grade electronics.
FAU_WID_EXT.5, Wireless Intrusion Detection - Cellular Spectrum Monitoring, requires the TSF to surveil certain radio frequency bands that fall outside the typical wireless spectrum used by consumer-grade electronics.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security Audit Data Generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: | FAU_INV_EXT.1 Environmental Inventory |
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security Audit Data Generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
No specific management functions are identified.
The following actions should be auditable if FAU_GEN Security Audit Data Generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: |
[FAU_WID_EXT.2 Wireless Intrusion Detection - Passive Information Flow Monitoring, or FAU_WID_EXT.3 Wireless Intrusion Detection - Non-Wireless Spectrum Monitoring] |
No specific management functions are identified.
The following actions should be auditable if FAU_GEN Security Audit Data Generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
No specific management functions are identified.
The following actions should be auditable if FAU_GEN Security Audit Data Generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FAU_ANO_EXT.1, Anomaly-Based Intrusion Detection, requires the TSF to define how it determines anomalous network traffic that may be indicative of malicious activity.
The following actions could be considered for the management functions in FMT:
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | FAU_IDS_EXT.1 Intrusion Detection System - Intrusion Detection Methods |
FAU_SIG_EXT.1, Signature-Based Intrusion Detection, requires the TSF to support the definition of traffic signatures that can be compared to observed network traffic for the purpose of identifying potential malicious activity.
The following actions could be considered for the management functions in FMT:
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | FAU_IDS_EXT.1 Intrusion Detection System - Intrusion Detection Methods |
FAU_MAC_EXT.1, Device Impersonation, requires the TSF to detect possible MAC address spoofing using various methods.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | FAU_INV_EXT.2 Characteristics of Environmental Objects |
FAU_WIP_EXT.1, Wireless Intrusion Prevention, requires the TSF to support reactive behavior if potential malicious traffic is observed to be originating from or targeted to a particular network asset.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security Audit Data Generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: | FAU_WID_EXT.1 Wireless Intrusion Detection - Malicious Environmental Objects |
This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP-Module. These requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.2 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the PP-Module provides evidence that these controls are present and have been evaluated.
| Requirement | Rationale for Satisfaction |
| FDP_IFF.1 - Information Flow Control Functions | CC Part 2 specifies FDP_IFF.1 as a dependency of FDP_IFC.1 because the TSF must define the information flow control SFP rules associated with a given SFP. This dependency is implicitly addressed through FAU_WID_EXT.2, which defines the rules for the 802.11 monitoring SFP defined by FDP_IFC.1. |
| Requirement | Description | Distributed TOE SFR Allocation |
| FAU_ANO_EXT.1 | Anomaly-Based Intrusion Detection | Feature Dependent |
| FAU_ARP.1 | Security Alarms | One |
| FAU_ARP_EXT.1 | Security Alarm Filtering | One |
| FAU_GEN.1/WIDS | Audit Data Generation (WIDS) | Feature Dependent |
| FAU_IDS_EXT.1 | Intrusion Detection System - Intrusion Detection Methods | Feature Dependent |
| FAU_INV_EXT.1 | Environmental Inventory | Feature Dependent |
| FAU_INV_EXT.2 | Characteristics of Environmental Objects | Feature Dependent |
| FAU_INV_EXT.3 | Location of Environmental Objects | Feature Dependent |
| FAU_INV_EXT.4 | Detection of Unauthorized Connections | Feature Dependent |
| FAU_INV_EXT.5 | Signal Library | Feature Dependent |
| FAU_MAC_EXT.1 | Device Impersonation | Feature Dependent |
| FAU_RPT_EXT.1 | Intrusion Detection System - Reporting Methods | Feature Dependent |
| FAU_SAA.1 | Potential Violation Analysis | Feature Dependent |
| FAU_SIG_EXT.1 | Signature-Based Intrusion Detection | Feature Dependent |
| FAU_STG_EXT.1/PCAP | Protected Audit Event Storage (Packet Captures) | Feature Dependent |
| FAU_WID_EXT.1 | Wireless Intrusion Detection - Malicious Environmental Objects | Feature Dependent |
| FAU_WID_EXT.2 | Wireless Intrusion Detection - Passive Information Flow Monitoring | Feature Dependent |
| FAU_WID_EXT.3 | Wireless Intrusion Detection - Non-Wireless Spectrum Monitoring | Feature Dependent |
| FAU_WID_EXT.4 | Wireless Intrusion Detection - Wireless Spectrum Analysis | Feature Dependent |
| FAU_WIP_EXT.1 | Wireless Intrusion Prevention | Feature Dependent |
| FDP_IFC.1 | Subset Information Flow Control | Feature Dependent |
| FMT_SMF.1/WIDS | Specification of Management Functions (WIDS) | Feature Dependent |
| FPT_FLS.1 | Basic Internal TSF Data Transfer Protection | Feature Dependent |
| Acronym | Meaning |
|---|---|
| AES | Advanced Encryption Standard |
| AP | Access Point |
| Base-PP | Base Protection Profile |
| BSSID | Basic Service Set Identifier |
| CC | Common Criteria |
| CEM | Common Evaluation Methodology |
| cPP | Collaborative Protection Profile |
| DDoS | Distributed Denial of Service |
| DHCP | Dynamic Host Configuration Protocol |
| DoS | Denial of Service |
| EUD | End User Device |
| FP | Functional Package |
| HTTPS | Hypertext Transfer Protocol Secure |
| ICS | Internet Connection Sharing |
| IPsec | Internet Protocol Security |
| MAC | Media Access Control |
| OE | Operational Environment |
| OSI | Open Systems Interconnection |
| PP | Protection Profile |
| PP-Configuration | Protection Profile Configuration |
| PP-Module | Protection Profile Module |
| SAR | Security Assurance Requirement |
| SF | Security Function |
| SFP | Security Function Policy |
| SFR | Security Functional Requirement |
| SNMP | Simple Network Management Protocol |
| SSH | Secure Shell |
| SSID | Service Set Identifier |
| ST | Security Target |
| TKIP | Temporal Key Integrity Protocol |
| TLS | Transport Layer Security |
| TOE | Target of Evaluation |
| TSF | TOE Security Functionality |
| TSFI | TSF Interface |
| TSS | TOE Summary Specification |
| WEP | Wired Equivalent Protocol |
| WIDS | Wireless Intrusion Detection System |
| WIPS | Wireless Intrusion Prevention System |
| WLAN | Wireless Local Area Network |
| WPA | WLAN Protected Access |
| Identifier | Title |
|---|---|
| [CC] | Common Criteria for Information Technology Security Evaluation -
|
| [NDcPP] | collaborative Protection Profile for Network Devices, Version 2.2e, March 23, 2020 |
| [NDcPP SD] | Supporting Document - Evaluation Activities for Network Device cPP, Version 2.2, December 2019 |
