Network WLAN AP-NIPR Platform Security Technical Implementation Guide

DoD networks are at risk and DoD data could be compromised if wireless scanning is not conducted to identify unauthorized WLAN clients and access points connected to or attempting to connect to the network. DoD Components must ensure that a Wireless Intrusion Detection System (WIDS) is implemented that allows for monitoring of WLAN activity and the detection of WLAN-related policy violations on all unclassified and classified DoD wired and wireless LANs. The WIDS must be implemented regardless of whether or not an authorized WLAN has been deployed. The WIDS must be capable of monitoring IEEE 802.11 transmissions within all DoD LAN environments and detecting nearby unauthorized WLAN devices. The WIDS is not required to monitor non-IEEE 802.11 transmissions. The WIDS must continuously scan for and detect authorized and unauthorized WLAN activities 24 hours a day, 7 days a week. Note: Exceptions to WIDS implementation criteria may be made by the AO for DoD wired and wireless LAN operating environments. This exception allows the AO to implement periodic scanning conducted by designated personnel using handheld scanners during walk-through assessments. Periodic scanning may be conducted as the alternative to the continuous scanning only in special circumstances, where it has been determined on a case-by-case basis that continuous scanning is either infeasible or unwarranted. The AO exception must be documented. The "infeasible" criteria includes the following use case examples: - It is not my building - This scenario means that for contractual or other similar reasons, the DoD component is not allowed to install a WIDS. - There is no power or space is limited - This scenarios means that for space weight and power (SWAP) reasons, the addition of continuous scanning capabilities cannot be accomplished because it would exceeds SWAP availability. Power would also affect the decision to waive continuous scanning requirements if the entire LAN is only in operation periodically (e.g., the wired/wireless LAN is enabled on a vehicle that is only operating when the vehicle is being used for a specific operation). - The exception for "Minimal Impact WLAN Systems" that do not provide connectivity to WLAN-enabled PEDs (e.g., backhaul systems), have no available FIPS 140 validated 802.1X EAP-TLS supplicant, support a very small number of users for a specific mission (e.g., 10 or less users), are standalone networks, or are highly specialized WLAN systems that are isolated from the DODIN (e.g., handheld personal digital assistants [PDAs] used as radio-frequency identification [RFID] readers, a network of WLAN-enabled Voice over Internet Protocol [VoIP] phones) allows the AO to waive any of the security requirements in the Instruction. This includes using non-standard/proprietary FIPS-validated encryption, using an alternative FIPS-validated EAP type, and not having a continuous WIDS. - The cost of the continuous WIDS capability is more expensive that the total cost of the LAN without a WIDS. The AO must conduct a wireless threat risk assessment where analysis has shown that the threat environment is extremely unlikely to non-existent to meet the "unwarranted" exception criteria.

A WLAN session that never terminates due to inactivity may allow an opening for an adversary to highjack the session to obtain access to the network.

Wi-Fi Alliance certification ensures compliance with DoD interoperability requirements between various WLAN products.

EAP-TLS provides strong cryptographic mutual authentication and key distribution services not found in other EAP methods, and thus provides significantly more protection against attacks than other methods. Additionally, EAP-TLS supports two-factor user authentication on the WLAN client, which provides significantly more protection than methods that rely on a password or certificate alone. EAP-TLS also can leverage the DoD Common Access Card (CAC) in its authentication services, providing additional security and convenience.

If the DoD WLAN components (WLAN AP, controller, or client) are not NIST FIPS 140-2/FIPS 140-3 (Cryptographic Module Validation Program, CMVP) certified, the WLAN system may not adequately protect sensitive unclassified DoD data from compromise during transmission.

DoD certificate-based PKI authentication is strong, two-factor authentication that relies on carefully evaluated cryptographic modules. Implementations of EAP-TLS that are not integrated with certificate-based PKI could have security vulnerabilities. For example, an implementation that uses a client certificate on laptop without a second factor could enable an adversary with access to the laptop to connect to the WLAN without a PIN or password. Systems that do not use the certificate-based PKI are also much more likely to be vulnerable to weaknesses in the underlying public key infrastructure (PKI) that supports EAP-TLS. Certificate-based PKI authentication must be used to connect WLAN client devices to DoD networks. The certificate-based PKI authentication should directly support the WLAN EAP-TLS implementation. At least one layer of user authentication must enforce network authentication requirements (e.g., CAC authentication) before the user is able to access DoD information resources.

If an adversary is able to compromise an access point or controller that is directly connected to an enclave network, the adversary can easily surveil and attack other devices from that beachhead. A defense-in-depth approach requires an additional layer of protection between the WLAN and the enclave network. This is particularly important for wireless networks, which may be vulnerable to attack from outside the physical perimeter of the facility or base given the inherent nature of radio communications to penetrate walls, fences, and other physical boundaries. Wireless access points and bridges must not be directly connected to the enclave network. A network device must separate wireless access from other elements of the enclave network. Sites must also comply with the Network Infrastructure STIG configuration requirements for DMZ, VLAN, and VPN configurations, as applicable. Examples of acceptable architectures include placing access points or controllers in a screened subnet (e.g., DMZ separating intranet and wireless network) or dedicated virtual LAN (VLAN) with ACLs.

The OOBM access switch will connect to the management interface of the managed network elements. The management interface can be a true OOBM interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network element will be directly connected to the OOBM network. (See SRG-NET-000205-RTR-000012.) Network boundaries, also known as managed interfaces, include, for example, gateways, routers, firewalls, guards, network-based malicious code analysis, and virtualization systems, or encrypted tunnels implemented within a security architecture (e.g., routers protecting firewalls or application gateways residing on protected subnetworks). Subnetworks that are physically or logically separated from internal networks are referred to as demilitarized zones (DMZs). Methods used for prohibiting interfaces within organizational information systems include, for example, restricting external web traffic to designated web servers within managed interfaces and prohibiting external traffic that appears to be spoofing internal addresses.

Call-home services will routinely send data such as configuration and diagnostic information to the vendor for routine or emergency analysis and troubleshooting. There is a risk that transmission of sensitive data sent to unauthorized persons could result in data loss or downtime due to an attack. (See SRG-NET-000131-RTR-000083.)