PP-Module for Wireless Intrusion Detection/Prevention System
Version: 2.0 2022-09-30 National Information Assurance Partnership
Foreword
This is a Supporting Document (SD), intended to complement the Common Criteria version 3
and the associated Common Evaluation Methodology for
Information Technology Security Evaluation.
SDs may be “Guidance Documents”, that highlight specific approaches
and application of the standard to areas where no mutual recognition of
its application is required, and as such, are not of normative nature,
or “Mandatory Technical Documents”, whose application is mandatory for evaluations
whose scope is covered by that of the SD.
The usage of the latter class is not only mandatory, but certificates
issued as a result of their application are recognized under the CCRA.
Technical Editor:
National Information Assurance Partnership (NIAP)
Document history:
Version
Date
Comment
2.0
2022-09-30
Added 6 GHz spectrum slice
1.0
2020-09-30
Initial Release - PP-Module for NDcPP
General Purpose:
The purpose of this SD is to define evaluation methods for the functional behavior of
Wireless Intrusion Detection/Prevention System
products.
Acknowledgments:
This SD was developed with support from NIAP
Wireless Intrusion Detection/Prevention System
Technical Community members, with representatives from industry, government
agencies, Common Criteria Test Laboratories, and members of academia.
1.1 Technology Area and Scope of Supporting Document
The scope of the
PP-Module for Wireless Intrusion Detection/Prevention System is
to describe the security functionality of
Wireless Intrusion Detection/Prevention System
products in terms of
[CC] and to define functional and assurance requirements for them.
The PP-Module is intended for use with the following Base-PP:
This SD is mandatory for evaluations of TOEs that claim conformance to a PP-Configuration that includes the PP-Module for :
Wireless Intrusion Detection/Prevention System, Version 2.0
As such it defines Evaluation Activities for the functionality described in the PP-Module as well as any impacts to the Evaluation Activities to the Base-PP(s) it modifies.
Although Evaluation Activities are defined mainly for the evaluators to follow, in general they also help developers to prepare for evaluation by identifying specific requirements for their TOE.
The specific requirements in Evaluation Activities may in some cases clarify the meaning of Security
Functional Requirements (SFR), and may identify particular requirements for the content of Security
Targets (ST) (especially the TOE Summary Specification), user guidance documentation, and possibly
supplementary information (e.g. for entropy analysis or cryptographic key management architecture).
1.2 Structure of the Document
Evaluation Activities can be defined for both SFRs and Security Assurance Requirements (SAR),
which are themselves defined in separate sections of the SD.
If any Evaluation Activity cannot be successfully completed in an evaluation, then
the overall verdict for the evaluation is a 'fail'.
In rare cases there may be acceptable reasons why an Evaluation Activity
may be modified or deemed not applicable for a particular TOE,
but this must be approved by the Certification Body for the evaluation.
In general, if all Evaluation Activities (for both SFRs and SARs) are successfully
completed in an evaluation then it would be expected that the overall verdict for
the evaluation is a ‘pass’.
To reach a ‘fail’ verdict when the Evaluation Activities have been successfully
completed would require a specific justification from the evaluator as to why the
Evaluation Activities were not sufficient for that TOE.
Similarly, at the more granular level of assurance components, if the Evaluation
Activities for an assurance component and all of its related SFR Evaluation
Activities are successfully completed in an evaluation then it would be expected
that the verdict for the assurance component is a ‘pass’.
To reach a ‘fail’ verdict for the assurance component when these Evaluation
Activities have been successfully completed would require a specific justification
from the evaluator as to why the Evaluation Activities were not sufficient for that TOE.
1.3 Terms
The following sections list Common Criteria and technology terms used in this document.
1.3.1 Common Criteria Terms
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.
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.
1.3.2 Technical Terms
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.
2 Evaluation Activities for SFRs
The EAs presented in this section capture the actions the evaluator performs
to address technology specific aspects covering specific SARs (e.g. ASE_TSS.1,
ADV_FSP.1, AGD_OPE.1, and ATE_IND.1) – this is in addition to the CEM workunits
that are performed in Section 3 Evaluation Activities for SARs.
Regarding design descriptions (designated by the subsections labeled TSS, as
well as any required supplementary material that may be treated as proprietary),
the evaluator must ensure there is specific information that satisfies the EA.
For findings regarding the TSS section, the evaluator’s verdicts will be
associated with the CEM workunit ASE_TSS.1-1.
Evaluator verdicts associated with the supplementary evidence will also be
associated with ASE_TSS.1-1,
since the requirement to provide such evidence is specified in ASE in the PP.
For ensuring the guidance documentation provides sufficient information for
the administrators/users as it pertains to SFRs, the evaluator’s verdicts will
be associated with CEM workunits ADV_FSP.1-7, AGD_OPE.1-4, and AGD_OPE.1-5.
Finally, the subsection labeled Tests is where the authors have determined
that testing of the product in the context of the associated SFR is necessary.
While the evaluator is expected to develop tests, there may be instances where
it is more practical for the developer to construct tests, or where the
developer may have existing tests.
Therefore, it is acceptable for the evaluator to witness developer-generated
tests in lieu of executing the tests.
In this case, the evaluator must ensure the developer’s tests are executing both
in the manner declared by the developer and as mandated by the EA.
The CEM workunits that are associated with the EAs specified in this section
are: ATE_IND.1-3, ATE_IND.1-4, ATE_IND.1-5, ATE_IND.1-6, and ATE_IND.1-7.
2.1 Collaborative
Protection Profile for Network Device
The EAs defined in this section are only applicable in cases where the TOE claims conformance
to a PP-Configuration that includes the NDcPP.
2.1.1 Modified SFRs
2.1.1.1 Security Audit (FAU)
FAU_GEN_EXT.1 Security Audit Data Generation for Distributed TOE Components
FAU_GEN_EXT.1
There is no change to the EAs specified for this SFR in the NDcPP SD.
The PP-Module modifies this SFR to make its inclusion mandatory rather than selection-based, but there is no change to how the SFR must be implemented.
FAU_STG_EXT.1 Protected Audit Event Storage
FAU_STG_EXT.1
There is no change to the EAs specified for this SFR in the NDcPP SD.
The PP-Module modifies this SFR to remove one of the possible selection items, but there is no change to how the SFR is to be implemented.
2.1.1.2 Communications (FCO)
FCO_CPC_EXT.1 Communication Partner Control
FCO_CPC_EXT.1
There is no change to the EAs specified for this SFR in the NDcPP SD.
The PP-Module modifies this SFR to make its inclusion mandatory rather than optional, but there is no change to how the SFR is to be implemented.
2.1.1.3 Protection of the TSF (FPT)
FPT_ITT.1 Basic Internal TSF Data Transfer Protection
FPT_ITT.1
There is no change to the EAs specified for this SFR in the NDcPP SD.
The PP-Module modifies this SFR to make its inclusion mandatory rather than optional, but there is no change to how the SFR is to be implemented.
2.1.1.4 Trusted Paths/Channels (FTP)
FTP_ITC.1 Inter-TSF trusted channel
FTP_ITC.1
There is no change to the EAs specified for this SFR in the NDcPP SD.
If ‘database server’ is selected in FTP_ITC.1.1, the evaluator shall ensure that the required tests are performed on that external interface in addition to the other claimed interfaces.
The evaluator shall also perform test 4 for this SFR in the NDcPP SD, which is objective in NDcPP.
2.2 TOE SFR Evaluation Activities
2.2.1 Security Audit (FAU)
FAU_ARP.1 Security Alarms
FAU_ARP.1
TSS
The evaluator shall verify that the TSS describes where to find the WIDS alerts
on the Administrator console/interface.
Guidance
The evaluator shall use the operational guidance for instructions on where
the alerts generated are displayed within the WIDS interface. If "capture raw frame traffic that triggers the violation is selected", the
evaluator shall use the operational guidance to configure the traffic capture
capabilities.
Tests
Test FAU_ARP.1:1:
The evaluator shall perform a series of events or generate traffic that
would successfully trigger an alert for each of the rules defined in FAU_SAA.1. The evaluator should verify and record
whether the TOE generated the alert for each rule, and provided sufficient details. The evaluator should also record the events
or traffic that was generated as each alert was attempted to be triggered and
record the details provided by the TOE in the alert.
Test FAU_ARP.1:2:
[conditional] If capturing of raw frames was selected, verify
that the packet capture was triggered and stored as appropriate.
FAU_ARP_EXT.1 Security Alarm Filtering
FAU_ARP_EXT.1
TSS
The evaluator shall verify that the TSS describes the ability of the TOE to filter
WIDS/WIPS alerts.
Guidance
The evaluator shall verify that the operational guidance includes
instructions on enabling and disabling alerts.
Step 1: The evaluator shall use the operational guidance to enable/disable
detection of available detection capabilities through the WIDS administrator
interface. The evaluator shall then generate traffic that would successfully
trigger the alert. The evaluator should verify that the TOE generated the
alert.
Step 2: The evaluator shall disable the alert. The evaluator shall then generate
events as in previous test that should successfully trigger the alert. The
evaluator shall verify that the TOE did not generate an alert.
FAU_GEN.1/WIDS Audit Data Generation (WIDS)
FAU_GEN.1/WIDS
TSS
There are no TSS evaluation activities for this SFR.
Guidance
There are no operational guidance activities for this SFR.
Tests
The evaluator shall test the TOE’s ability to correctly generate audit records
by having the TOE generate audit records in accordance with the evaluation activities
associated with the functional requirements in this PP-Module. When verifying the
test results, the evaluator shall ensure the audit records generated during testing
match the format specified in the administrative guide, and that the fields in each
audit record have the proper entries.
Note that the testing here can
be accomplished in conjunction with the testing of the security mechanisms directly.
FAU_IDS_EXT.1 Intrusion Detection System - Intrusion Detection Methods
FAU_IDS_EXT.1
TSS
The evaluator shall verify that the TSS includes which intrusion detection
method(s) the TOE utilizes. If multiple methods are selected, the evaluator shall
confirm that the TSS describes how the different methods are
incorporated.
Guidance
The evaluator shall verify that the operational guidance provides
instructions on how to configure the TOE in order for it to detect such
intrusions.
Tests
Depending on the detection technique used by the TOE, the evaluator shall
confirm and note the existence of the capability and test for the appropriate
selection-based requirements.
FAU_INV_EXT.1 Environmental Inventory
FAU_INV_EXT.1
TSS
The evaluator shall verify that the TSS describes how the presence of authorized
EUDs and APs is presented by the TOE. The evaluator shall verify that the TSS
includes where in the WIDS interface the list of detected APs and EUDs is
displayed.
Guidance
The evaluator shall verify that the operational guidance provides
instructions on how to view authorized and unauthorized APs and EUDs that are within
range of the TOE sensors.
Step 1: Deploy a non-allowlisted AP and EUD and connect the EUD to the
AP.
Step 2: Verify that the list of detected APs and EUDs contains the
non-allowlisted AP and EUD that were just deployed.
Step 3: If the AP and EUD are detected verify that they are not classified as
allowlisted devices.
FAU_INV_EXT.2 Characteristics of Environmental Objects
FAU_INV_EXT.2
TSS
The evaluator shall verify that the TSS explains the capability of detecting the information specified in the requirements for all APs and EUDs within the TOE's wireless range.
Guidance
The evaluator shall review the operational guidance in order to verify that
there are instructions that show how to locate the device inventory mentioned
above.
Step 1: Deploy an allowlisted AP, non-allowlisted AP and two allowlisted
EUDs.
Step 2: Connect one allowlisted EUD to the allowlisted AP and one to the
non-allowlisted AP.
Step 3: Check the WIDS user interface for a list of detected APs and
EUDs.
Step 4: Verify that current RF band, current channel, MAC Address, received signal strength, device detection timestamps, classification of device, are part of the information presented on the WIDS user interface for all the APs and EUDs detected.
For APs verify that encryption, number of connected EUDs, SSID (if not hidden), received frames/packets and beacon rate are presented.
For EUDs verify that the SSID and BSSID of AP it is connected and DHCP configuration is presented.
FAU_INV_EXT.3 Location of Environmental Objects
FAU_INV_EXT.3
TSS
The evaluator shall verify that the TSS includes information on location
tracking, optimal number of sensors and sensor placement to meet the required level
of accuracy.
The evaluator shall verify that the TSS contains
information regarding the TSF’s ability to record signal strength of hardware
operating within range of its sensors.
Guidance
The evaluator shall review the operational guidance for instructions on how
to configure location tracking, how to load a location map (if applicable), and
where in the TSF administrator interface the location of APs and EUDs can be
viewed.
If the option for detection of RF power levels above a
predetermined threshold is selected, the evaluator shall use the operational
guidance to set or check what the threshold is in a given test. The evaluator should
also verify that the operational guidance provides instruction on how to configure
the TOE to generate an alert when the threshold is exceeded.
Step 1: Deploy an allowlisted AP and connect it to the protected wired
infrastructure via wire.
Step 2: Confirm that the TSF can observe and capture traffic and events
generated by the AP.
Step 3: Confirm that the TSF can use the reporting mechanisms specified in the TSS.
Step 4: Verify that the TSF can import and export observable event data in
each of the formats specified in the TSS.
FAU_SAA.1 Potential Violation Analysis
FAU_SAA.1
TSS
The evaluator shall verify that the TSS describes the ability of the TOE to detect the network behavior described by the SFR. The evaluator shall verify that the TSS describes the methods that the TOE uses to detect the presence of unauthorized connections and unauthorized network traffic. The evaluator shall examine the TSS to verify that it describes the denial of service attacks that can be detected by the TOE. The evaluator shall verify that the TSS describes the ability of the TOE to detect when unauthorized WLAN authentication schemes and encryption schemes are used. The evaluator shall verify that the TSS describes the ability of the TOE to detect when unauthorized APs and EUDs send or receive unencrypted data.
Guidance
If the ability of the TSF to detect the different potential security violations is configurable, the evaluator shall verify that the operational guidance provides instructions on how to configure the TOE.
Step 2: Verify that the EUD is detected as an non-allowlisted EUD.
Test FAU_SAA.1:3:
Detection of authorized EUD establishing peer-to-peer connection with any other EUD:
Test FAU_SAA.1:3.1:
Create the following connections between two allowlisted EUDs.
Windows ad hoc
Mac OS ad hoc
Linux ad hoc
Wi-Fi Direct
Test FAU_SAA.1:3.2:
Create the following connections between one allowlisted EUD and a
non-allowlisted EUD
Windows ad hoc
Mac OS ad hoc
Linux ad hoc
Wi-Fi Direct
Verify that alerts were generated by each of the connections in each test.
Test FAU_SAA.1:4:
Detection of EUD bridging two network interfaces:
Bridge two network interfaces on an allowlisted EUD (one must be the wireless card listed as allowlisted).
Step 1: Create a Windows Hosted Network with an allowlisted EUD.
Step 2: Connect a different allowlisted EUD to the network.
Verify that alerts were generated by each of the connections in each test.
Test FAU_SAA.1:5:
Detection of unauthorized point to point wireless bridges by allowlisted APs:
Step 1: Setup a point-to-point wireless bridge using allowlisted APs in the
range of the wireless sensors.
Step 2: Verify that the TSF detects the bridge.
Test FAU_SAA.1:6:
Alert generated by violation of user defined signature:
Step 1: Setup a user defined detection signature.
Step 2: Verify that the TSF generates an alert once the rules of signature have been violated.
Step 1: Deploy an allowlisted AP and connect authorized EUDs.
Step 2: Generate disassociation frames from an unauthorized EUD.
Step 3: Verify that the TSF detected the disassociation flooding.
Test FAU_SAA.1:18:
Detection of request-to-send/clear-to-send abuse:
Step 1: Deploy allowlisted AP and configure to a set channel.
Step 2: Connect two allowlisted EUDs to the AP.
Step 3: Send an flood of CTS frames to reserve RF medium.
Step 4: Verify that the TSF detects the CTS abuse.
Test FAU_SAA.1:19:
Detection of unauthorized authentication scheme use:
The evaluator shall configure the TOE, per FMT_SMF.1/WIDS, with 802.1x authentication as the only mode of authorized WLAN authentication scheme.
The evaluator shall verify that the TSS describes how the TOE detects malicious
APs/EUDs and whether the TOE supports automatic detection. The evaluator shall
verify that the TSS includes how the TOE determines if a given SSID is authorized.
Guidance
If TOE supports automatic detection, the evaluator shall
verify that the operational guidance contains instructions for configuring the
automatic detection metrics. The evaluator shall verify that the operational guidance
provides instructions on how to configure SSIDs as authorized.
Tests
For test 1 and 2 below the evaluator shall verify that the TOE detects and appropriately classifies the APs and EUDs. It is acceptable if the TOE uses different but equivalent descriptors for the classification. If the TOE does not support automatic detection metrics and equates a non-allowlisted AP/EUD as malicious, than it is sufficient that the the classification given to the AP/EUD in step 1 is the same as in step 2. If the TOE supports automatic detection metrics and distinguishes between a non-allowlisted AP/EUD and a malicious AP/EUD, then the classification for the AP/EUD should differ between step 1 and step 2.
Step 1: Deploy a non-allowlisted AP in the area of the WIDS sensor, but take no action against the network. Verify that the AP is classified as non-authorized.
Step 2: Deploy a non-allowlisted AP in the area of the WIDS sensor and launch an attack against the network. This can be any variation of Fake AP, Spoof AP, Flood or DoS attack.
Step 3: Verify that the AP is classified as malicious.
Step 1: Deploy a non-allowlisted EUD in the area of the WIDS sensor, but take no action against the network. Verify that the EUD is classified as non-authorized.
Step 2: Launch an RF Flooding, DoS/DDoS, masqueraded or spoofing attack against authorized AP with an unauthorized EUD.
Step 3: Verify that the EUD is classified as malicious.
Step 1: Deploy an AP with an unauthorized SSID in the area of the WIDS sensor.
Step 2: Verify that the TOE detects the unauthorized SSID.
FAU_WID_EXT.2 Wireless Intrusion Detection - Passive Information Flow Monitoring
FAU_WID_EXT.2
TSS
The evaluator shall verify that the TSS includes which channels the TOE can
detect and monitor. Additionally, the TSS shall include whether the TOE
simultaneously or nonsimultaneously monitors network traffic across these channels.
The evaluator shall verify that the TSS includes information on if the sensors are
completely passive, by default, or if the sensors ability to transmit data is
configurable.
Guidance
The evaluator shall review the operational guidance for how to configure
the TOE to monitor the channels as selected in the SFR. If the sensor ability to
transmits data is configurable, the evaluator shall review the operational guidance
for how to disable wireless transmissions from the sensor. The evaluator shall verify that the operational guidance provides
instructions on how to specify and confirm that stateful frame capture and
inspection is being performed.
Step 1: Configure the TSF to monitor the channels as selected in the SFR.
Step 2: Deploy AP on at least 2 different channels on non-standard channel
frequencies.
Step 3: Verify that the AP gets detected on each channel tested.
Wireless Sensor Transmission of Data
If the TOE provides the ability to disable wireless transmission, the evaluator shall follow the operational guidance to configure the sensor to not transmit wirelessly. The evaluator shall then deploy a signal analyzer in order to check for wireless emanations from the TOE.
Repeat the two tests below, for both the 2.4 GHz, 5 GHz, and 6 GHz band.
Step 3: Deploy a protocol analyzer or native capability within the WIDS Controller between the AP and EUD.
Step 4: Verify from the network traffic packet capture that all frames are being inspected to validate their connection state from the TSF
2.2.2 User Data Protection (FDP)
FDP_IFC.1 Subset Information Flow Control
FDP_IFC.1
TSS
There are no TSS evaluation activities for this SFR.
Guidance
If this functionality is configurable, the evaluator shall verify that the
operational guidance provides instructions on how to configure the TOE to monitor
different types of IEEE 802.11 frame types and subtypes.
Send a set number of frames to the sensor for all IEEE 802.11 a, b, g, n, ac frame types and subtypes from/to the following:
authorized APs and authorized EUDs
authorized APs and unauthorized EUDs
unauthorized APs and authorized EUDs
Verify that there are frames from all the types and subtypes in the
capture.
2.2.3 Security Management (FMT)
FMT_SMF.1/WIDS Specification of Management Functions (WIDS)
FMT_SMF.1/WIDS
TSS
The evaluator shall review the TSS to verify that it includes information the
ability of the TOE to define inventory of authorized APs and EUDs.
The evaluator shall verify that the TSS describes the ability of the TOE to
allow authorized administrators to define authorized WLAN authentication
schemes.
Guidance
The evaluator shall review the operational guidance for instructions on how
to configure and change classification of APs and EUDs to indicate that they are part
of the allowlist.
The evaluator shall review the operational guidance to determine how to configure which SSIDs are permitted on the network.
The evaluator shall examine the operational guidance to verify that it
provides instructions on how to define a WLAN authentication scheme as authorized or
unauthorized for the purposes of detection.
The evaluator shall examine the operational guidance to verify that it
provides instructions on how to define a WLAN encryption scheme as authorized or
unauthorized for the purposes of detection.
Tests
Test FMT_SMF.1/WIDS:1:
The evaluator shall define an inventory of authorized APs and EUDs. The ability to detect allowlisted and non-allowlisted APs and EUDs will be tested in FAU_INV_EXT.1 and FAU_SAA.1.
Test FMT_SMF.1/WIDS:2:
The evaluator shall define authorized SSIDs. The ability to detect authorized and unauthorized SSIDs will be tested in FAU_WID_EXT.2.3 and FAU_SAA.1.
Test FMT_SMF.1/WIDS:3:
The evaluator shall configure the TSF with a set of allowed authentication and encryption
schemes. The ability to detect violation of this policy will be tested in FAU_SAA.1.
Test FMT_SMF.1/WIDS:4:
(conditional): If "Define the amount of time sensor monitors a specific frequency or channel" is selected:
Step 1: Deploy an allowlisted AP and connect it to the protected wired
infrastructure via wire.
Step 2: Confirm that the TSF can observe and capture traffic and events
generated by the AP.
Step 3: Verify that the TSF can be configured to capture traffic on a specific
channel for specific interval of time, and assign a specified frequency and
time interval.
Step 4: Confirm that the TSF remains on the frequency and channel for the
time period specified.
The evaluator shall verify that the TSS includes the set of RF bands and
technologies that the TSF can detect the use of. The TSS should also include
instructions on how to enable and the hardware that is necessary for the additional
band detection.
Guidance
The evaluator shall verify that the operational guidance describes how to
enable and configure detection of the technologies included in the ST as well as the
hardware that is needed to perform this function.
Tests
The evaluator shall enable and configure detection of the selected
technologies.
Test FAU_WID_EXT.3:1:
Deploy a device within the given technology and verify that the TSF detects
the device.
The evaluator shall verify that the TSS to verify that the TOE provides a
dedicated sensor for wireless spectrum analysis.
Guidance
The evaluator shall verify that the operational guidance describes how to
enable and configure dedicated spectrum analysis as well as the hardware that is
needed to perform this function.
Tests
The evaluator shall enable and configure dedicated spectrum analysis and test
the capabilities listed in the TSS.
FAU_WID_EXT.5 Wireless Intrusion Detection - Bluetooth Spectrum Monitoring
FAU_WID_EXT.5
TSS
The evaluator shall verify that the TSS includes the set of RF bands and
technologies that the TSF can detect the use of. The TSS should also include
instructions on how to enable and the hardware that is necessary for the additional
band detection.
Guidance
The evaluator shall verify that the operational guidance describes how to
enable and configure detection of the technologies included in the ST as well as the
hardware that is needed to perform this function.
Tests
The evaluator shall enable and configure detection of the selected
technologies.
Test FAU_WID_EXT.5:1:
Deploy a device within the given technology and verify that the TSF detects
the device.
The evaluator shall verify that the TSS includes the set of RF bands and
technologies that the TSF can detect the use of. The TSS should also include
instructions on how to enable and the hardware that is necessary for the additional
band detection.
Guidance
The evaluator shall verify that the operational guidance describes how to
enable and configure detection of the technologies included in the ST as well as the
hardware that is needed to perform this function.
Tests
The evaluator shall enable and configure detection of the selected
technologies.
Test FAU_WID_EXT.5:1:
Deploy a device within the given technology and verify that the TSF detects
the device.
2.4 Evaluation Activities for Selection-Based SFRs
2.4.1 Security Audit (FAU)
FAU_ANO_EXT.1 Anomaly-Based Intrusion Detection
FAU_ANO_EXT.1
TSS
The evaluator shall verify that the TSS describes the composition and
construction of baselines or anomaly-based attributes specified in the SFR. The
evaluator shall verify that the TSS provides a description of how baselines are
defined and implemented by the TSF, or a description of how anomaly-based rules are
defined and configured by the administrator.
The evaluator shall
verify that the TSS describes the available modes of configuration (manual or
automatic) and how to configure or import the baseline.
Guidance
The evaluator shall verify that the operational guidance describes how to
configure baseline and/or anomalous traffic patterns based on what is stated in the
TSS.
The evaluator shall verify that the operational guidance
describes how to perform automatic and/or manual definition of anomaly activity
based on what is selected in the ST.
Tests
The evaluator shall use the instructions in the operational guidance to
configure baselines or anomaly-based rules through automated and/or manual means
based on what is selected in the ST. The evaluator shall send traffic that does not
match the baseline or matches the anomaly-based rule and verify the TSF detects the
anomalous behavior and generates an alert.
FAU_SIG_EXT.1 Signature-Based Intrusion Detection
FAU_SIG_EXT.1
TSS
The evaluator shall verify that the TSS describes the user-defined and
customizable attack signatures that the TOE can define.
Guidance
The evaluator shall verify that the operational guidance provides
information on how to configure user-defined and customizable attack signatures,
including a description of the customization options that are
available.
The evaluator shall verify that the TSS includes the list of trusted channels
(as specified in FTP_ITC.1) available in the TSF to transmit packet captures to an
external entity. The evaluator shall verify that the TSS describes the ability of
the TOE to store packet capture data within itself, how much storage space is
available for packet capture data and where that data is stored. The evaluator shall
verify that the TSS describes the behavior of the TOE when local storage space for
packet capture data is exhausted and whether this behavior is
configurable.
Guidance
The evaluator shall verify that the operational guidance provides
instructions on how to configure the trusted channel. If the behavior of the TOE
when local storage space for packet capture data is exhausted is configurable, the
evaluator shall verify that the operational guidance provides information on what
the configurable behaviors are and how they can be set.
Tests
Test FAU_STG_EXT.1/PCAP:1:
The evaluator shall configure packet captures according to the guidance
specified. The evaluator shall then trigger an event that starts a capture and
verify through the tests in FTP_ITC.1 that the captured traffic being sent to
the external device is being sent through a trusted channel.
Test FAU_STG_EXT.1/PCAP:2:
The evaluator shall configure packet captures to be stored on the TSF
according to the guidance specified. The evaluator shall then trigger an event
that starts a capture and verify that the packet capture was stored on the
TSF.
Test FAU_STG_EXT.1/PCAP:3:
The evaluator shall define packet data retention and deletion rules on the
TSF according to the guidance specified and test the functionality of the
specified rules.
2.5 Evaluation Activities for Objective SFRs
2.5.1 Security Audit (FAU)
FAU_INV_EXT.4 Detection of Unauthorized Connections
FAU_INV_EXT.4
TSS
The evaluator shall verify that the TSS includes guidance on whether the TSF has
the capability of detecting APs connecting to the protected wired network
infrastructure. If the capability is present the TSS shall include configuration
guidance for this feature.
Guidance
The evaluator shall review the operational guidance for instructions on how
to configure the WIDS to detect unauthorized APs connected to the protected wired
infrastructure.
Step 2: Connect the AP via wire to the protected network infrastructure.
Step 3: Check the WIDS user interface for a list of detected APs and
EUDs.
Step 4: Verify that the rogue AP is detected and an alert generated on the
detection of an AP connected to the protected wired infrastructure.
FAU_INV_EXT.5 Signal Library
FAU_INV_EXT.5
TSS
There are no TSS evaluation activities for this SFR.
Guidance
The evaluator shall review the operational guidance for instructions on how
to locate and verify that the WIDS comes preloaded with a signal library, as well as
possesses the ability to import, export, and update the existing signal library if
present.
Tests
Depending on operation guidance provided for the TOE, the evaluator shall
confirm and note the existence of the signal library, and test for the ability to
import, export, and update the signal library.
Step 1: Deploy an allowlisted AP and connect it to the protected wired
infrastructure via wire.
Step 2: Confirm and note whether the TSF has an existing signal library.
Step 3: If existence is confirmed, verify that the TSF can import, export, and
update the existing signal library.
FAU_MAC_EXT.1 Device Impersonation
FAU_MAC_EXT.1
TSS
The evaluator shall verify that the TSS describes the behavior of the TOE when
two sensors in non-overlapping locations receive traffic from the same MAC address
simultaneously.
Guidance
The evaluator shall verify that the operational guidance provides
instructions on how to deploy the TOE in a manner that allows the TSF to detect when
two sensors in non-overlapping locations receive traffic from the same MAC address
simultaneously (i.e. information about the range and placement of sensors to ensure
non-overlapping coverage).
The evaluator shall verify that the
operational guidance provides instructions on how to configure the timeframe that
should be allowed between two subsequent attempts for an EUD to connect from two
separate locations.
Step 3: Setup a second allowlisted AP and a non-allowlisted EUD in a separate
non-overlapping location where the WIDS also has sensors. Or simulate the
distant non-overlapping locations by deploying the second AP in a shielded
environment connected to the valid network (Location 2).
Step 4: Spoof the MAC address of the EUD in location 1 with the EUD in location
2 and connect it to the allowlisted AP in location 2. Make sure both EUDs
are connected at the same time.
Step 5: Verify that the TSF detected and generated an alert.
Step 1: Configure the timeframe allowed between connection of two EUDs in two
separate locations (Location 1, Location 2).
Step 2: Setup an allowlisted AP (Location 1).
Step 3: Connect an allowlisted EUD to AP.
Step 4: Setup a second allowlisted AP and a non-allowlisted EUD in a separate
non-overlapping location where the WIDS also has sensors. Or simulate the
distant non-overlapping locations by deploying the second AP in a shielded
environment connected to the valid network (Location 2).
Step 5: Spoof the MAC address of the EUD in location 1 with the EUD in location
2 and connect it to the allowlisted AP in location 2. Make sure that the
time between connections is shorter than the time timeframe
allowed/configured.
Step 6: Verify that the TSF detected and generated an alert.
FAU_WIP_EXT.1 Wireless Intrusion Prevention
FAU_WIP_EXT.1
TSS
The evaluator shall verify that the TSS includes a list of available containment
methods on the TSF and how to configure them.
Guidance
There are no operational guidance activities for this SFR.
Tests
Configure the containment methods available on the TSF and perform the
following test for each method.
Step 1: Deploy a non-allowlisted AP and connect to the protected wired
infrastructure via wire (make sure it gets classified as rogue, or manually
classify as such).
Step 2: Connect an allowlisted EUD to the AP.
Step 3: Verify that TSF generates an alert, breaks the connection of the
allowlisted EUD from the rogue AP, and contains the rogue AP.
2.5.2 Protection of the TSF (FPT)
FPT_FLS.1 Basic Internal TSF Data Transfer Protection
FPT_FLS.1
TSS
The evaluator shall review the TSS section to determine that the TOE’s
implementation of the fail secure functionality is documented. The evaluator shall
examine the TSS section to ensure that all failure modes specified in the ST are
described.
Guidance
The evaluator shall review the operational guidance to verify that it
identifies the potential TOE failures, how the TSF preserves a secure state
following these failures, and any actions that are required to restore the TOE to
normal operation following the transition to a failure state.
Tests
Test FPT_FLS.1:1:
For each failure mode specified in the ST, the evaluator shall ensure that
the TOE attains a secure state after initiating each failure mode type.
2.6 Evaluation Activities for Implementation-based SFRs
The PP-Module does not define any implementation-based requirements.
3 Evaluation Activities for SARs
The PP-Module does not define any SARs beyond those defined within the
base NDcPP to which it must claim conformance.
It is important to note that a TOE that is evaluated against the PP-Module is
inherently evaluated against this Base-PP as well.
The NDcPP
includes a number of Evaluation Activities associated with both SFRs and SARs.
Additionally, the PP-Module includes a number of SFR-based Evaluation Activities
that similarly refine the SARs of the Base-PPs.
The evaluation laboratory will evaluate the TOE against the Base-PP
and supplement that evaluation with the necessary SFRs that are taken from the PP-Module.
4 Required Supplementary Information
This Supporting Document has no required supplementary information beyond the ST, operational
guidance, and testing.
Appendix A - References
Identifier
Title
[CC]
Common Criteria for Information Technology Security Evaluation -
