Skip to content
ATO Pathways
Log In
Overview
Search
Catalogs
SCAP
OSCAL
Catalogs
Profiles
Documents
References
Knowledge Base
Platform Documentation
Compliance Dictionary
Platform Changelog
About
Catalogs
XCCDF
Network WLAN AP-NIPR Platform Security Technical Implementation Guide
Profiles
No profile (default benchmark)
No profile (default benchmark)
An XCCDF Profile
Details
Items
Prose
10 rules organized in 10 groups
SRG-NET-000512
1 Rule
<GroupDescription></GroupDescription>
WLAN SSIDs must be changed from the manufacturer's default to a pseudo random word that does not identify the unit, base, organization, etc.
Low Severity
<VulnDiscussion>An SSID identifying the unit, site, or purpose of the WLAN or that is set to the manufacturer default may cause an OPSEC vulnerability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-NET-000514
1 Rule
<GroupDescription></GroupDescription>
The WLAN inactive/idle session timeout must be set for 30 minutes or less.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-NET-000063
1 Rule
<GroupDescription></GroupDescription>
WLAN components must be Wi-Fi Alliance certified with WPA2 or WPA3.
Medium Severity
<VulnDiscussion>Wi-Fi Alliance certification ensures compliance with DoD interoperability requirements between various WLAN products.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-NET-000070
1 Rule
<GroupDescription></GroupDescription>
WLAN must use EAP-TLS.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-NET-000151
1 Rule
<GroupDescription></GroupDescription>
WLAN components must be FIPS 140-2 or FIPS 140-3 certified and configured to operate in FIPS mode.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-NET-000070
1 Rule
<GroupDescription></GroupDescription>
WLAN EAP-TLS implementation must use certificate-based PKI authentication to connect to DoD networks.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-NET-000384
1 Rule
<GroupDescription></GroupDescription>
WLAN signals must not be intercepted outside areas authorized for WLAN access.
Low Severity
<VulnDiscussion>Most commercially available WLAN equipment is preconfigured for signal power appropriate to most applications of the WLAN equipment. In some cases, this may permit the signals to be received outside the physical areas for which they are intended. This can occur when the intended area is relatively small, such as a conference room, or when the access point is placed near or window or wall, thereby allowing signals to be received in neighboring areas. In such cases, an adversary may be able to compromise the site's posture by measuring the presence of the signal and the quantity of data transmitted to obtain information about when personnel are active and what they are doing. If the signal is not appropriately protected through defense-in-depth mechanisms, the adversary could possibly use the connection to access DoD networks and sensitive information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-NET-000512
1 Rule
<GroupDescription></GroupDescription>
Wireless access points and bridges must be placed in dedicated subnets outside the enclave's perimeter.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-NET-000205
1 Rule
<GroupDescription></GroupDescription>
The network device must be configured to only permit management traffic that ingresses and egresses the out-of-band management (OOBM) interface.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-NET-000131
1 Rule
<GroupDescription></GroupDescription>
The network device must not be configured to have any feature enabled that calls home to the vendor.
Medium Severity
<VulnDiscussion>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.)</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>