{
"stig": {
"date": "2018-09-27",
"description": "This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.",
"findings": {
"V-11796": {
"checkid": "C-7782r8_chk",
"checktext": "Determine if a deny-by-default security posture has been implemented for both inbound and outbound traffic on the perimeter router or firewall.\n\nIf a deny-by-default security posture has not been implemented at the network perimeter, this is a finding.",
"description": "To prevent malicious or accidental leakage of traffic, organizations must implement a deny-by-default security posture at the network perimeter. Such rulesets prevent many malicious exploits or accidental leakage by restricting the traffic to only known sources and only those ports, protocols, or services that are permitted and operationally necessary.\n\nApplications, protocols, TCP/UDP ports, and endpoints (specific hosts or networks) are identified and used to develop rulesets and access control lists to restrict traffic to and from an enclave.",
"fixid": "F-11043r6_fix",
"fixtext": "Implement a deny-by-default security posture on either the enclave perimeter router or firewall.",
"iacontrols": null,
"id": "V-11796",
"ruleID": "SV-12294r5_rule",
"severity": "high",
"title": "A deny-by-default security posture must be implemented for traffic entering and leaving the enclave.",
"version": "NET0369"
},
"V-12072": {
"checkid": "C-8089r7_chk",
"checktext": "Work with the traditional reviewer or interview the ISSO or SM.\n\nDetermine if the site SCIF CSA has approved wireless CMDs in the site SCIFs.\n\nDetermine if the SCIF CSA has approved wireless devices in site SCIFs. Ask for approval documentation. \n\nIf wireless devices are allowed in site SCIFs without required approval, this is a finding.",
"description": "Emanations from computing devices in the secured area may be transmitted or picked up inadvertently by wireless devices.",
"fixid": "F-11360r3_fix",
"fixtext": "Train users to comply with this requirement as well as site procedures document and include the requirement in the site User Agreement.",
"iacontrols": null,
"id": "V-12072",
"ruleID": "SV-12625r6_rule",
"severity": "high",
"title": "Unclassified wireless devices must not be allowed in a Sensitive Compartmented Information Facility (SCIF) unless approved by the SCIF Cognizant Security Authority (CSA) in accordance with Intelligence Community Directive (ICD) 503, ICD 705, DIA SCIF policy requirements, the Authorizing Official (AO) and local Special Security officer (SSO).",
"version": "WIR0035"
},
"V-12101": {
"checkid": "C-8118r2_chk",
"checktext": "Interview the ISSM and review the SSAA. GRE tunnels found on a premise or edge SIPRNet router that have an endpoint within the REL IP address space must be documented in the SSAA.\n\nIf the REL LAN has not been documented in the SSAA, this is a finding.",
"description": "The ISSM will ensure Releasable Local Area Network (REL LAN) environments are documented in the SSAA.",
"fixid": "F-11390r2_fix",
"fixtext": "The ISSM will document GRE tunnels defined on a premise or edge SIPRNet router that have an endpoint within the REL IP address space.",
"iacontrols": null,
"id": "V-12101",
"ruleID": "SV-12654r2_rule",
"severity": "medium",
"title": "All Releasable Local Area Network (REL LAN) environments must be documented in the System Security Authorization Agreement (SSAA).",
"version": "NET1815"
},
"V-12102": {
"checkid": "C-8119r2_chk",
"checktext": "Have the ISSM disclose documentation that a REL LAN review has been performed annually.\n\nIf annual reviews are not being performed, this is a finding.",
"description": "The ISSM will ensure Releasable Local Area Network (REL LAN) reviews are performed annually.",
"fixid": "F-11391r2_fix",
"fixtext": "The ISSM will document REL LAN reviews being performed annually.",
"iacontrols": null,
"id": "V-12102",
"ruleID": "SV-12655r2_rule",
"severity": "medium",
"title": "Annual reviews must be performed on all Releasable Local Area Network (REL LAN) environments.",
"version": "NET1816"
},
"V-12106": {
"checkid": "C-8122r7_chk",
"checktext": "Detailed Policy Requirements:\n\nNote: This requirement does not apply to NSA-approved classified WLAN systems.\n\nThe ISSO will ensure wireless devices are not operated in areas where classified information is electronically stored, processed, or transmitted unless:\n- Approved by the Authorizing Official (AO) in consultation with the Certified TEMPEST Technical Authority (CTTA).\n- The wireless equipment is separated from the classified data equipment at the minimum distance determined by the CTTA and appropriate countermeasures, as determined by the CTTA, are implemented.\n\nCheck Procedures:\n\nReview documentation. Work with the traditional security reviewer to verify the following:\n1. If classified information is not processed at this site, mark as not a finding.\n2. If the site has a written procedure prohibiting the use of wireless devices in areas where classified data processing occurs, mark as not a finding. Ask for documentation showing the CTTA was consulted about operation and placement of wireless devices. Acceptable proof would be the signature or initials of the CTTA on the architecture diagram or other evidence of coordination. IAW DoD policy, the CTTA must have a written separation policy for each classified area. \n3. Review written policies, training material, or user agreements to see if wireless usage in these areas is addressed. \n4. Verify proper procedures for wireless device use in classified areas is addressed in training program.\n\nIf wireless devices are used in or around classified processing areas but the CTTA has not designated a separation distance in writing, the AO has not coordinated with the CTTA, or \nusers are not trained or made aware (using signage or user agreement) of procedures for wireless device usage in and around classified processing areas, this is a finding.",
"description": "The operation of electronic equipment and emanations must be controlled in and around areas where sensitive information is kept or processed. Sites should post signs and train users to this requirement to mitigate this vulnerability.",
"fixid": "F-3423r3_fix",
"fixtext": "Central Computer and Telecommunication Agency (CTTA) must designate a separation distance in writing.\n\nAO must coordinate with the CTTA.\n\nTrain users or get a signed user agreement on procedures for wireless device usage in and around classified processing areas.",
"iacontrols": null,
"id": "V-12106",
"ruleID": "SV-12659r5_rule",
"severity": "medium",
"title": "Unclassified wireless devices must not be operated in Secure Spaces (as defined in DoDI 8420.01) unless required conditions are followed.",
"version": "WIR0040"
},
"V-14634": {
"checkid": "C-12650r4_chk",
"checktext": "Inspect the network topology and physical connectivity to verify compliance.\n\nIf the site has a non-DoD external connection and does not have an IDPS located between the site\u2019s Approved Gateway and the perimeter router, this is a finding.\n\nNote: An Approved Gateway (AG) is any external connection from a DoD NIPRNet enclave to an Internet Service Provider, or network owned by a contractor, or non-DoD federal agency that has been approved by either the DoD CIO or the DoD Component CIO. This AG requirement does not apply to commercial cloud connections when the Cloud Service Provider (CSP) network is connected via the NIPRNet Boundary Cloud Access Point (BCAP).",
"description": "The incorrect placement of the external IDPS may allow unauthorized access to go undetected and limit the ability of security personnel to stop malicious or unauthorized use of the network. In order to ensure that an attempted or existing attack goes unnoticed, the data from the sensors must be monitored continuously.",
"fixid": "F-14096r3_fix",
"fixtext": "Install and configure an IDPS between the site\u2019s Approved Gateway and the premise router.",
"iacontrols": null,
"id": "V-14634",
"ruleID": "SV-15259r4_rule",
"severity": "medium",
"title": "If the site has a non-DoD external connection (i.e. Approved Gateway), an Intrusion Detection and Prevention System (IDPS) must be located between the sites Approved Gateway and the perimeter router.",
"version": "NET0168"
},
"V-14638": {
"checkid": "C-13708r10_chk",
"checktext": "Review the network topology diagram and interview the ISSO to verify that all NIPRNet-only applications are located in a local enclave DMZ. \n\nIf there are any NIPRNet-only applications not hosted in the enclave\u2019s DMZ, this is a finding.",
"description": "Without the protection of a DMZ, production networks will be prone to outside attacks as they are allowing externally accessible services to be accessed on the internal LAN. This can cause many undesired consequences such as access to the entire network, Denial of Service attacks, or theft of sensitive information.",
"fixid": "F-14743r6_fix",
"fixtext": "Implement and move NIPRNet-only applications to a local enclave DMZ.",
"iacontrols": null,
"id": "V-14638",
"ruleID": "SV-15263r4_rule",
"severity": "medium",
"title": "All hosted NIPRNet-only applications must be located in a local enclave Demilitarized Zone (DMZ).",
"version": "NET0346"
},
"V-14640": {
"checkid": "C-13707r5_chk",
"checktext": "Review the network topology diagram and interview the ISSO to verify that all Internet-facing applications are hosted in a DoD DMZ Extension.\n\nIf there are any Internet-facing applications hosted in the enclave\u2019s DMZ or private network, this is a finding.",
"description": "Without the protection of a DMZ, production networks will be prone to outside attacks as they are allowing externally accessible services to be accessed on the internal LAN. This can cause many undesired consequences such as access to the entire network, Denial of Service attacks, or theft of sensitive information.",
"fixid": "F-14742r4_fix",
"fixtext": "Implement and move internet facing applications logically to a DoD DMZ Extension.",
"iacontrols": null,
"id": "V-14640",
"ruleID": "SV-15265r4_rule",
"severity": "medium",
"title": "All Internet-facing applications must be hosted in a DoD Demilitarized Zone (DMZ) Extension.",
"version": "NET0348"
},
"V-14642": {
"checkid": "C-12658r8_chk",
"checktext": "Determine which type of solution is used for deep packet inspection at the enclave boundary. Acceptable solutions for meeting this requirement are a deep packet inspection firewall, or a stateful packet inspection firewall in conjunction with any combination of application firewalls or application layer gateways. \n\nIf the organization does not have any implementation of deep packet inspection protecting their network perimeter boundaries, this is a finding.\n\nException: If the perimeter security for the enclave or B/C/P/S is provisioned via the JRSS, then this requirement is not applicable.",
"description": "Deep packet inspection (DPI) examines the packet beyond the Layer 4 header by examining the payload to identify the application or service. DPI searches for illegal statements, predefined criteria, malformed packets, and malicious code, thereby enabling the IA appliances to make a more informed decision on whether to allow or not allow the packet through. DPI engines can delve into application centric information to allow different applications to be protected in different ways from different threats. Examples of DPI appliances include next-generation firewalls, application layer gateways as well as specific gateways for web, email and SSL traffic.",
"fixid": "F-14102r9_fix",
"fixtext": "Implement a deep packet inspection solution at the enclave boundaries. Verify any IA appliances used for deep packet inspection are connected, properly configured, and actively inspecting all ingress and egress network traffic.",
"iacontrols": null,
"id": "V-14642",
"ruleID": "SV-15268r6_rule",
"severity": "high",
"title": "The organization must implement a deep packet inspection solution when protecting perimeter boundaries.",
"version": "NET0365"
},
"V-14716": {
"checkid": "C-12907r2_chk",
"checktext": "Review the network topology and verify that an OOB network provides connectivity from the management network to all of the managed network elements. \n\nIf an OOB network has not been deployed, verify that the network administrators have management access via the console to the managed network elements. \n\nIf there is no OOB network or if network administrators do not have management access via the console to the managed network elements, this is a finding.",
"description": "From an architectural point of view, providing Out-Of-Band (OOB) management of network systems is the best first step in any management strategy. No production traffic resides on an out-of-band network. The biggest advantage to implementation of an OOB network is providing support and maintenance to the network that has become degraded or compromised. During an outage or degradation period the in band management link may not be available. The consequences of loss of availability of a MAC I system is unacceptable and could include the immediate and sustained loss of mission effectiveness. Mission Assurance Category I systems require the most stringent protection measures. Maintenance support for key IT assets must be available to respond 24x7 immediately upon failure.",
"fixid": "F-14183r2_fix",
"fixtext": "The network administrator will manage devices via direct connection or access via OOB management network.",
"iacontrols": null,
"id": "V-14716",
"ruleID": "SV-15442r2_rule",
"severity": "medium",
"title": "An Out-of-Band (OOB) management network must be deployed for MAC I systems or 24x7 personnel must have console access for device management.",
"version": "NET1622"
},
"V-14723": {
"checkid": "C-12939r2_chk",
"checktext": "Review all network element configurations to ensure that an authentication server is being used. Then verify that a two-factor authentication method has been implemented. The RADIUS or TACACS server referenced in the configurations will call a two-factor authentication server.\n\nIf two-factor authentication is not being used to access all network elements, this is a finding.",
"description": "Without secure management implemented with authenticated access controls, strong two-factor authentication, encryption of the management session and audit logs, unauthorized users may gain access to network managed devices compromised, large parts of the network could be incapacitated with only a few commands.",
"fixid": "F-14190r2_fix",
"fixtext": "The network administrator must ensure strong two-factor authentication is being incorporated in the access scheme.",
"iacontrols": null,
"id": "V-14723",
"ruleID": "SV-15473r2_rule",
"severity": "medium",
"title": "Two-factor authentication must be implemented to restrict access to all network elements.",
"version": "NET0445"
},
"V-14737": {
"checkid": "C-12959r6_chk",
"checktext": "Review network device configurations and topology diagrams to validate encapsulated traffic received from other enclaves terminate at the perimeter for filtering and content inspection. If the tunnel is terminated on a VPN gateway, validate the traffic is inspected by a firewall and IDPS before gaining access to the private network.\n\nIf the tunnel is being provided by the perimeter router with a direct connection to the tenant's perimeter router, then the perimeter router (of the enclave providing the transient service) must be configured (examples: policy based routing or VRF bound to this interface with only a default route pointing out) to insure all traffic received by this connecting interface is forwarded directly to the NIPR/SIPR interface regardless of destination. If this isn't being done then the connecting interface will have to be treated as an external interface with all the applicable checks.\n\nSecured connections such as SSL or TLS which are used for remote access, secure web access, etc. is also applicable to this rule. These types of connections like the other types above must terminate at the enclave perimeter, enclave DMZ, or an enclave service network for filtering and content inspection before passing into the enclave's private network.\n\nIf the tunnels do not meet any of the criteria above and bypass the enclave's perimeter without filtering and inspection, this is a finding.\n\nNote: This vulnerability is not applicable for any VPN connectivity between multiple sites of the same enclave, nor is it applicable for VPN remote access to the enclave. For theses deployments, the implementation must be compliant with all requirements specified within IPsec VPN STIG.",
"description": "Allowing encapsulated traffic to bypass the enclave's network perimeter without being filtered and inspected leaves the enclave vulnerable to malicious traffic that could result in compromise and denial of service. The destination of these packets could be servers that provide mission critical services and data.",
"fixid": "F-14203r3_fix",
"fixtext": "Move tunnel decapsulation to a secure end-point at the enclave's perimeter for filtering and inspection.",
"iacontrols": null,
"id": "V-14737",
"ruleID": "SV-15493r5_rule",
"severity": "high",
"title": "Encapsulated and/or encrypted traffic received from another enclave must not bypass the network perimeter defense without being terminated and inspected before entering the enclaves private network.",
"version": "NET-TUNL-026"
},
"V-14738": {
"checkid": "C-12960r2_chk",
"checktext": "Review the enclave's security authorization package and the ATC or Interim ATC amending the connection approval received.\n\nIf the tunneling of classified traffic is not documented in the security authorization package and an ATC or Interim ATC, this is a finding.",
"description": "CJCSI 6211.02E instruction establishes policy and responsibilities for the connection of any information systems to the Defense Information Systems Network (DISN) provided transport. Enclosure E mandates that the CC/S/A document all IP tunnels transporting classified communication traffic in the enclave\u2019s security authorization package prior to implementation. An ATC or IATC amending the current connection approval must be in place prior to implementation.",
"fixid": "F-14204r2_fix",
"fixtext": "Document the tunneling of classified traffic in the security authorization package and the ATC or Interim ATC.",
"iacontrols": null,
"id": "V-14738",
"ruleID": "SV-15494r2_rule",
"severity": "medium",
"title": "Tunneling of classified traffic across an unclassified IP transport network or service provider backbone must be documented in the enclaves security authorization package and an Approval to Connect (ATC), or an Interim ATC must be issued by DISA prior to implementation.",
"version": "NET-TUNL-028"
},
"V-14740": {
"checkid": "C-12962r3_chk",
"checktext": "Review the network topology diagram.\n\nIf there is a connection between the classified network and the unclassified network for the purpose of tunneling classified traffic across a non-DISN or OCONUS DISN unclassified IP network, verify there is approval by the DSAWG.\n\nIf there is no document stating DSAWG approval, this is a finding.",
"description": "CJCSI 6211.02E instruction establishes policy and responsibilities for the connection of any information systems to the Defense Information Systems Network (DISN) provided transport. Enclosure E mandates that the CC/S/A obtain DSAWG approval before tunneling classified data outside component\u2019s local area network boundaries across a non-DISN or OCONUS DISN unclassified IP-wide area transport infrastructure.",
"fixid": "F-14206r3_fix",
"fixtext": "Remove the connection between the classified and unclassified network. Obtain approval from the DSAWG for the purpose of tunneling classified traffic across a non-DISN or OCONUS DISN unclassified IP network.",
"iacontrols": null,
"id": "V-14740",
"ruleID": "SV-15496r2_rule",
"severity": "high",
"title": "DSAWG approval must be obtained before tunneling classified traffic outside the components local area network boundaries across a non-DISN or OCONUS DISN unclassified IP wide area network transport infrastructure.",
"version": "NET-TUNL-030"
},
"V-14741": {
"checkid": "C-12963r3_chk",
"checktext": "Review the topology diagram of the classified network.\n\nIf there are any leased circuits connecting to DoD Vendor, Foreign, or Federal Mission Partner enclave or network without a signed DoD CIO-approved sponsorship memo, this is a finding.\n\nIf classified connectivity is not to a DSS-approved contractor facility or DoD Component-approved foreign government facility, this is a finding.",
"description": "Having a circuit provisioned that connects the SIPRNet enclave to a non-DoD, foreign, or contractor network puts the enclave and the entire SIPRNet at risk. If the termination point is not operated by the government, there is no control to ensure that the network element at the remote facility is not compromised or connected to another network.",
"fixid": "F-14207r2_fix",
"fixtext": "Terminate all leased circuits connecting to DoD Vendor, Foreign, or Federal Mission Partner enclave or network without a signed DoD CIO-approved sponsorship memo.\n\nTerminate all leased circuits for a classified network that is not connecting to a DSS-approved contractor facility or DoD Component-approved foreign government facility.",
"iacontrols": null,
"id": "V-14741",
"ruleID": "SV-15497r2_rule",
"severity": "high",
"title": "Enabling a connection that extends DISN IP network connectivity (e.g., NIPRNet and SIPRNet) to any DoD Vendor, Foreign, or Federal Mission Partner enclave or network without a signed DoD CIO approved sponsorship memo is prohibited. For classified connectivity it must be to a DSS approved contractor facility or DoD Component approved foreign government facility.",
"version": "NET1826"
},
"V-14742": {
"checkid": "C-12964r2_chk",
"checktext": "Review SIPRNet accreditation package and an Interim Authority to Connect/Authority to Connect (IATC/ATC) amending the connection approval received.\n\nIf C2 and non-C2 exceptions are not documented, this is a finding.",
"description": "Any exception to use SIPRNet must be documented in an update to the enclave\u2019s accreditation package and an Authority to Connect (ATC) or Interim ATC amending the connection approval received prior to implementation.",
"fixid": "F-14208r1_fix",
"fixtext": "Document all SIPRNet connections.",
"iacontrols": null,
"id": "V-14742",
"ruleID": "SV-15498r2_rule",
"severity": "medium",
"title": "Command and Control (C2) and non-C2 exceptions of SIPRNet must be documented in the enclaves accreditation package and an Authority to Connect (ATC) or Interim ATC amending the connection approval received prior to implementation.",
"version": "NET1827"
},
"V-14743": {
"checkid": "C-12965r2_chk",
"checktext": "Review the configuration of the IPsec VPN gateway and verify that the tunnel provisioned for transporting classified traffic across an unclassified IP transport network is using cryptographic algorithms in accordance with CNSS Policy No. 15.\n\nIf cryptographic algorithms used for tunneling classified traffic across an unclassified network are not in accordance with CNSS Policy No. 15, this is a finding.",
"description": "When transporting classified data over an unclassified IP network, it is imperative that traffic from the classified enclave or community of interest is encrypted prior reaching the point of presence or service delivery node of the unclassified network. Confidentiality and integrity of the classified traffic must be preserved by employing cryptographic algorithms in accordance with CNSS Policy No. 15 which requires the appropriate Suite B cryptographic algorithms listed in ANNEX B or a commensurate suite of NSA-approved cryptographic algorithms.",
"fixid": "F-14209r2_fix",
"fixtext": "Configure the tunnel used for transporting classified traffic across an unclassified IP transport network to negotiate with the remote end point to employ cryptographic algorithms in accordance with CNSS Policy No. 15.",
"iacontrols": null,
"id": "V-14743",
"ruleID": "SV-15499r2_rule",
"severity": "medium",
"title": "Tunneling of classified traffic across an unclassified IP transport network must employ cryptographic algorithms in accordance with CNSS Policy No. 15.",
"version": "NET-TUNL-031"
},
"V-14745": {
"checkid": "C-12967r2_chk",
"checktext": "Review the network topology diagram. If there is a connection between the classified network and the unclassified network for the purpose of tunneling classified traffic across the unclassified IP network, verify that the IPsec VPN gateway used to provision the tunnel is compliant with appropriate physical security protection standards for processing classified information.\n\nIf appropriate physical security protection has not been enforced, this is a finding.",
"description": "When transporting classified data over an unclassified IP network, it is imperative that the network elements deployed to provision the encrypted tunnels are located in a facility authorized to process the data at the proper classification level.",
"fixid": "F-14211r2_fix",
"fixtext": "Employ the necessary physical security protection for the VPN gateway devices used for tunneling classified traffic across the unclassified IP network.",
"iacontrols": null,
"id": "V-14745",
"ruleID": "SV-15501r2_rule",
"severity": "medium",
"title": "VPN gateways used to create IP tunnels to transport classified traffic across an unclassified IP network must comply with appropriate physical security protection standards for processing classified information.",
"version": "NET1832"
},
"V-17772": {
"checkid": "C-19035r2_chk",
"checktext": "Review the network topology diagram to determine if a management network has been implemented. Validate the IP address space documented for this network by verifying the IP addresses referenced for management access (SSH, NTP, AAA, SNMP manager, Syslog server, etc.) to the managed network elements.\n\nIf a management network has not been implemented, this is a finding.",
"description": "To deploy a management network for the purpose of controlling, monitoring, and restricting management traffic, a separate management subnet must be implemented. Define a large enough address block that will enable the management network to scale in proportion to the managed network.",
"fixid": "F-17671r2_fix",
"fixtext": "Define a large enough address block that will enable the management network to scale in proportion to the managed network.",
"iacontrols": null,
"id": "V-17772",
"ruleID": "SV-18981r2_rule",
"severity": "medium",
"title": "A dedicated management network must be implemented.",
"version": "NET0998"
},
"V-17860": {
"checkid": "C-19370r3_chk",
"checktext": "Review the network topology to determine that there are two NTP servers and what network they are connected to. Verify that they are both online according to the documented IP address. \n\nWhere possible, deploy multiple gateways with diverse paths to the NTP servers. An alternative design is to have one server connected to a reference clock and the other server reference an external stratum-1 server. With this scenario, the NTP clients should be configured to prefer the stratum-1 server over the stratum-2 server.\n\nThe NTP servers should be configured to easily scale by creating a hierarchy of lower level (stratum-2 to stratum-15) servers to accommodate the workload. The width and depth of the hierarchy is dependent on the number of NTP clients as well as the amount of redundancy that is required.\n\nIf two NTP servers have not been deployed in the management network, this is a finding.",
"description": "NTP provides an efficient and scalable method for managed network elements to actively synchronize to an accurate time source. Insuring that there are always NTP servers available to provide time is critical. It is imperative that all single points of failure for the NTP infrastructure are eliminated. Knowing the correct time is not only crucial for proper network functioning but also for security. Compromising an NTP server opens the door to more sophisticated attacks that include NTP poisoning, replay attacks, and denial of service. \n\nWhere possible, deploy multiple gateways with diverse paths to the NTP servers. An alternative design is to have one server connected to a reference clock and the other server reference an external stratum-1 server. With this scenario, the NTP clients should be configured to prefer the stratum-1 server over the stratum-2 server.\n\nThe NTP servers should be configured to easily scale by creating a hierarchy of lower level (stratum-2 to stratum-15) servers to accommodate the workload. The width and depth of the hierarchy is dependent on the number of NTP clients as well as the amount of redundancy that is required.",
"fixid": "F-17801r1_fix",
"fixtext": "Deploy and implement at least two NTP servers in the management network.",
"iacontrols": null,
"id": "V-17860",
"ruleID": "SV-19152r2_rule",
"severity": "low",
"title": "Two Network Time Protocol (NTP) servers must be deployed in the management network.",
"version": "NET0810"
},
"V-18490": {
"checkid": "C-21124r2_chk",
"checktext": "Review the DMZ topology and verify public servers are being monitored by an IDPS.\n\nIf an IDPS sensor is not deployed to monitor all DMZ segments housing public servers, this is a finding.",
"description": "The initial step in IDPS deployment is determining where sensors should be placed. Because attacks originate at the enclave perimeter and within the enclave boundary an IDPS implementation at the enclave perimeter only will not suffice. By placing IDPS technology throughout the Enterprise Regional enclaves and stand-alone enclaves, system administrators can track the spread of attacks and take corrective actions to prevent attacks reaching critical resources.",
"fixid": "F-19077r1_fix",
"fixtext": "Place an IDPS sensor in the enclave to monitor public servers.",
"iacontrols": null,
"id": "V-18490",
"ruleID": "SV-20025r2_rule",
"severity": "medium",
"title": "An Intrusion Detection and Prevention System (IDPS) sensor must be deployed to monitor all Demilitarized Zone (DMZ) segments housing public servers.",
"version": "NET-IDPS-016"
},
"V-18492": {
"checkid": "C-21126r3_chk",
"checktext": "Review topology of the network segment hosting the web, application, and database servers. \n\nIf this segment is not being monitored by an IDPS sensor, this is a finding.",
"description": "Attacks can originate within the enclave boundary. Hence, deploying an IDPS on the network segment hosting web, application, and database servers is imperative. The servers are critical resource and the network segment hosting them will receive the most traffic within the enclave. Deploying IDPS on this network is promotes defense-in-depth principles that will enable operations to detect attacks quickly and take corrective actions.",
"fixid": "F-19914r2_fix",
"fixtext": "Implement an IDPS strategy to monitor the network segment hosting web, application, and database servers.",
"iacontrols": null,
"id": "V-18492",
"ruleID": "SV-20027r2_rule",
"severity": "medium",
"title": "An Intrusion Detection and Prevention System (IDPS) sensor must be deployed to monitor the network segment hosting web, application, and database servers.",
"version": "NET-IDPS-018"
},
"V-18493": {
"checkid": "C-21127r3_chk",
"checktext": "Review the management network topology and verify network security management servers are being monitored by an IDPS.\n\nIf an IDPS sensor is not deployed to monitor all segments housing network security management servers, this is a finding.",
"description": "The initial step in IDPS deployment is determining where sensors should be placed. Because attacks originate at the enclave perimeter and within the enclave boundary an IDPS implementation at the enclave perimeter only will not suffice. By placing IDPS technology throughout the Enterprise Regional enclaves and stand-alone enclaves, system administrators can track the spread of attacks and take corrective actions to prevent attacks reaching critical resources.",
"fixid": "F-19083r1_fix",
"fixtext": "Install an IDPS to monitor and protect the Management Network (management subnet or OOB network).",
"iacontrols": null,
"id": "V-18493",
"ruleID": "SV-20028r2_rule",
"severity": "medium",
"title": "An Intrusion Detection and Prevention System (IDPS) sensor must be deployed to monitor network segments that house network security management servers.",
"version": "NET-IDPS-019"
},
"V-18496": {
"checkid": "C-21131r2_chk",
"checktext": "Review the network topology diagram and interview the ISSO to determine how the IDS sensor data is transported between sites.\n\nIf it is not transported across an OOB network or an encrypted tunnel, this is a finding.",
"description": "User interface services must be physically or logically separated from data storage and management services. Data from IDS sensors must be protected by confidentiality controls; from being lost and altered.",
"fixid": "F-19086r2_fix",
"fixtext": "Design a communications path for OOB traffic or create an encrypted tunnel using a FIPS 140-2 validated encryption algorithm to protect data.",
"iacontrols": null,
"id": "V-18496",
"ruleID": "SV-20031r2_rule",
"severity": "medium",
"title": "Sensor traffic in transit must be protected at all times via an Out-of-Band (OOB) network or an encrypted tunnel between site locations.",
"version": "NET-IDPS-024"
},
"V-18497": {
"checkid": "C-21132r2_chk",
"checktext": "Review the network topology diagram and interview the ISSO to determine how the IDPS traffic between the sensor and the security management or sensor data collection servers is transported.\n\nIf the IDPS traffic does not traverse a dedicated VLAN logically separating IDPS traffic from all other enclave traffic, this is a finding.",
"description": "All IDPS data collected by agents in the enclave at required locations must also be protected by logical separation when in transit from the agent to the management or database servers located on the Network Management subnet.",
"fixid": "F-19087r1_fix",
"fixtext": "Design a communications path for OOB traffic or create a VLAN for IDPS traffic to protect the data.",
"iacontrols": null,
"id": "V-18497",
"ruleID": "SV-20032r2_rule",
"severity": "medium",
"title": "Intrusion Detection and Prevention System (IDPS) traffic between the sensor and the security management or sensor data collection servers must traverse a dedicated Virtual Local Area Network (VLAN) logically separating IDPS traffic from all other enclave traffic.",
"version": "NET-IDPS-025"
},
"V-18504": {
"checkid": "C-21198r2_chk",
"checktext": "Interview the IDPS administrator and determine if anomaly-based detection is deployed in the network. If implemented, ensure that any products collecting baselines for anomaly-based detection have their baselines rebuilt periodically to support accurate detection.\n\nIf the collection products do not have their baselines rebuilt periodically, this is a finding.",
"description": "Administrators should ensure that any products collecting baselines for anomaly-based detection have their baselines rebuilt periodically as needed to support accurate detection. \n\nThe ISSM is required to have the enclave prepared for readiness by raising INFOCON levels prior to an activity to ensure the network is as ready as possible when the operation or exercise begins. Because system and network administrators implement many of the INFOCON measures over a period of time in a pre-determined operational rhythm, commanders should raise INFOCON levels early enough to ensure completion of at least one cycle before the operational activity begins. \n\nRecommendations for possible INFOCON changes should be written into Operation Plans (OPLAN) and Concept Plans (CONPLAN). Guidelines can be found in Strategic Command Directive (SD) 527-1.",
"fixid": "F-19095r1_fix",
"fixtext": "Establish procedures to update anomaly-based sensors.",
"iacontrols": null,
"id": "V-18504",
"ruleID": "SV-20039r2_rule",
"severity": "low",
"title": "Products collecting baselines for anomaly-based detection must have their baselines rebuilt based on changes to mission requirements such as Information Operations Conditions (INFOCON) levels and when the traffic patterns are expected to change significantly.",
"version": "NET-IDPS-027"
},
"V-18506": {
"checkid": "C-21207r2_chk",
"checktext": "If the signatures are located on a server, verify that the directories on which the signature packs are placed are protected by read-only access.\n\nIf the directories are not set for read-only access, this is a finding.",
"description": "In a large scale IDPS deployment, it is common to have an automated update process implemented. This is accomplished by having the updates downloaded on a dedicated SFTP server within the management network. The SFTP server should be configured to allow read-only access to the files within the directory on which the signature packs are placed, and then only from the account that the sensors will use. The sensors can then be configured to automatically check the SFTP server periodically to look for the new signature packs and to update themselves once they have been tested.",
"fixid": "F-19097r1_fix",
"fixtext": "Modify the access restrictions to prevent the signatures from being updated.",
"iacontrols": null,
"id": "V-18506",
"ruleID": "SV-20041r2_rule",
"severity": "medium",
"title": "If a Secure File Transfer Protocol (SFTP) server is used to provide updates to the sensors, the server must be configured to allow read-only access to the files within the directory on which the signature packs are placed.",
"version": "NET-IDPS-029"
},
"V-18507": {
"checkid": "C-21208r2_chk",
"checktext": "Review the file server accounts and determine if the accounts with read access to the IDPS signatures are provided only to the IDPS sensors.\n\nIf there are accounts other than those allocated for the IDPS sensors providing access to the signatures, this is a finding.",
"description": "In a large scale IDPS deployment, it is common to have an automated update process implemented. This is accomplished by having the updates downloaded on a dedicated secure file server within the management network. The file server should be configured to allow read-only access to the files within the directory on which the signature packs are placed, and then only from the account that the sensors will use. The sensors can then be configured to automatically check the secure file server periodically to look for the new signature packs and to update themselves.",
"fixid": "F-19098r1_fix",
"fixtext": "Secure the signatures from access to accounts for IDS updates.",
"iacontrols": null,
"id": "V-18507",
"ruleID": "SV-20042r2_rule",
"severity": "medium",
"title": "If an automated scheduler is used to provide updates to the sensors, an account on the file server must be defined that will provide access to the signatures only to the sensors.",
"version": "NET-IDPS-030"
},
"V-18510": {
"checkid": "C-21274r2_chk",
"checktext": "Interview the SA to determine the IDPS maintenance procedures as well as have SA display the backup files saved on the file server.\n\nIf the IDPS configuration is not backed up prior to applying software or signature updates, or when making changes to the configuration, this is a finding.",
"description": "There are two types of IDPS updates: software updates and signature updates. Software updates fix bugs in the IDPS software or add new functionality, while signature updates add new detection capabilities or refine existing detection capabilities (e.g., reducing false positives). For many IDPSs, signature updates cause program code to be altered or replaced, so they are really a specialized form of software update. For other IDPSs, signatures are not written in code, so a signature update is a change to the configuration data for the IDPS. \n\nSoftware updates can include any or all IDPS components, including sensors, agents, management servers, and consoles. Software updates for sensors and management servers, particularly appliance-based devices, are often applied by replacing an existing IDPS CD with a new one and rebooting the device. Many IDPSs run the software directly from the CD, so that no software installation is required. Other components, such as agents, require an administrator to install software or apply patches, either manually on each host or automatically through IDPS management software. Some vendors make software and signature updates available for download from their Web sites or other servers; often, the administrator interfaces for IDPSs have features for downloading and installing such updates. \n\nAdministrators should verify the integrity of updates before applying them, because updates could have been inadvertently or intentionally altered or replaced. The recommended verification method depends on the update\u2019s format, as follows:\n\nFiles downloaded from a Web site or FTP site. Administrators should compare file checksums provided by the vendor with checksums that they compute for the downloaded files. \n\nUpdate downloaded automatically through the IDPS user interface. If an update is downloaded as a single file or a set of files, either checksums provided by the vendor should be compared to checksums generated by the administrator, or the IDPS user interface itself should perform some sort of integrity check. In some cases, updates might be downloaded and installed as one action, precluding checksum verification; the IDPS user interface should check each update\u2019s integrity as part of this. \n\nRemovable media (e.g., CD, DVD). Vendors may not provide a specific method for customers to verify the legitimacy of removable media apparently sent by the vendors. If media verification is a concern, administrators should contact their vendors to determine how the media can be verified, such as comparing vendor-provided checksums to checksums computed for files on the media, or verifying digital signatures on the media\u2019s contents to ensure they are valid. Administrators should also consider scanning the media for malware, with the caveat that false positives might be triggered by IDPS signatures for malware on the media.",
"fixid": "F-19104r1_fix",
"fixtext": "Establish backup procedures and define directories to store the configuration settings and operating system versions.",
"iacontrols": null,
"id": "V-18510",
"ruleID": "SV-20045r2_rule",
"severity": "low",
"title": "The Intrusion Detection and Prevention System (IDPS) configuration must be backed up before applying software or signature updates, or when making changes to the configuration.",
"version": "NET-IDPS-031"
},
"V-18511": {
"checkid": "C-21275r2_chk",
"checktext": "Interview the SA and determine the process of software and signature validation.\n\nIf file checksums provided by the vendor are not compared and verified with checksums computed from CD or downloaded files, this is a finding.",
"description": "There are two types of IDPS updates: software updates and signature updates. Software updates fix bugs in the IDPS software or add new functionality, while signature updates add new detection capabilities or refine existing detection capabilities (e.g., reducing false positives). For many IDPSs, signature updates cause program code to be altered or replaced, so they are really a specialized form of software update. For other IDPSs, signatures are not written in code, so a signature update is a change to the configuration data for the IDPS. \n\nSoftware updates can include any or all IDPS components, including sensors, agents, management servers, and consoles. Software updates for sensors and management servers, particularly appliance-based devices, are often applied by replacing an existing IDPS CD with a new one and rebooting the device. Many IDPSs run the software directly from the CD, so that no software installation is required. Other components, such as agents, require an administrator to install software or apply patches, either manually on each host or automatically through IDPS management software. Some vendors make software and signature updates available for download from their Web sites or other servers; often, the administrator interfaces for IDPSs have features for downloading and installing such updates. \n\nAdministrators should verify the integrity of updates before applying them, because updates could have been inadvertently or intentionally altered or replaced. The recommended verification method depends on the update\u2019s format, as follows:\n\nFiles downloaded from a Web site or FTP site. Administrators should compare file checksums provided by the vendor with checksums that they compute for the downloaded files. \n\nUpdate downloaded automatically through the IDPS user interface. If an update is downloaded as a single file or a set of files, either checksums provided by the vendor should be compared to checksums generated by the administrator, or the IDPS user interface itself should perform some sort of integrity check. In some cases, updates might be downloaded and installed as one action, precluding checksum verification; the IDPS user interface should check each update\u2019s integrity as part of this. \n\nRemovable media (e.g., CD, DVD). Vendors may not provide a specific method for customers to verify the legitimacy of removable media apparently sent by the vendors. If media verification is a concern, administrators should contact their vendors to determine how the media can be verified, such as comparing vendor-provided checksums to checksums computed for files on the media, or verifying digital signatures on the media\u2019s contents to ensure they are valid. Administrators should also consider scanning the media for malware, with the caveat that false positives might be triggered by IDPS signatures for malware on the media.",
"fixid": "F-19105r1_fix",
"fixtext": "Establish change control procedures that include file validation and integrity.",
"iacontrols": null,
"id": "V-18511",
"ruleID": "SV-20046r2_rule",
"severity": "low",
"title": "The Intrusion Detection and Prevention System (IDPS) file checksums provided by the vendor must be compared and verified with checksums computed from CD or downloaded files.",
"version": "NET-IDPS-032"
},
"V-18596": {
"checkid": "C-22258r5_chk",
"checktext": "Detailed Policy Requirements:\n\nDoD components will 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.\n\nThe WIDS shall be capable of monitoring IEEE 802.11 transmissions within all DoD LAN environments and detect nearby unauthorized WLAN devices. WIDS shall not be required to monitor non-IEEE 802.11 transmissions.\n\nWIDS Implementation Criteria. The WIDS shall continuously scan for and detect authorized and unauthorized WLAN activities 24 hours a day, 7 days a week.\n\nNote: 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.\n\nThe \"infeasible\" criteria includes the following use case examples:\n- It's not my building - this scenario means that for contractual, or other similar reasons, the DoD component is not allowed to install a WIDS.\n- There's 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. Another reason power would affect your decision to waive continuous scanning requirements is 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).\n- 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.\n-The cost of the continuous WIDS capability is more expensive that the total cost of the LAN without a WIDS.\n\nThe AO must conduct a wireless threat risk assessment where it has been shown by analysis that the threat environment is extremely unlikely to non-existent to meet the \"unwarranted\" exception criteria.\n\nCheck Procedures:\n\nInterview the site ISSO. Determine if the scanning by a WIDS is being conducted and if it is continuous or periodic.\n\nIf a continuous scanning WIDS is used, there is no finding. \n\nIf periodic scanning is used, verify the exception to policy is documented and signed by the AO. Verify the exception meets one of the required criteria.\n\nIf periodic scanning is being performed but requirements have not been met, this is a finding.\n\nIf no WIDS scanning is being performed at the site, this is a finding.",
"description": "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.",
"fixid": "F-19231r1_fix",
"fixtext": "Perform required WIDS scanning",
"iacontrols": null,
"id": "V-18596",
"ruleID": "SV-20145r4_rule",
"severity": "medium",
"title": "The site must conduct continuous wireless Intrusion Detection System (IDS) scanning.",
"version": "NET-WIDS-001"
},
"V-19900": {
"checkid": "C-25550r2_chk",
"checktext": "Review the WLAN system product documentation. Verify the system is WPA2-Enterprise certified by the Wi-Fi Alliance.\n\nIf the WLAN product is not WPA2-Enterprise certified, this is a finding.",
"description": "Most known security breaches of cryptography result from improper implementation of the cryptography, not flaws in the cryptographic algorithms themselves. FIPS 140-2 validation provides assurance that cryptography is implemented correctly, and is required for Federal Government uses of cryptography in non-classified applications.",
"fixid": "F-34115r2_fix",
"fixtext": "Procure WLAN equipment whose implementation of TLS has been FIPS 140-2 validated.",
"iacontrols": null,
"id": "V-19900",
"ruleID": "SV-22070r3_rule",
"severity": "medium",
"title": "The cryptography implemented by the Wireless Local Area Network (WLAN) components must be FIPS 140-2 validated.",
"version": "WIR0115-02"
},
"V-23735": {
"checkid": "C-28855r4_chk",
"checktext": "Inspect the network element configurations that have been stored offline.\n\nIf the configurations are not encrypted, this is a finding.",
"description": "If a network device's non-volatile memory is lost without a recent configuration stored in an offline location, it may take time to recover that segment of the network. Users connected directly to the switch or router will be without service for a longer than acceptable time. Encrypting the configuration stored offline protects the data at rest and provides additional security to prevent tampering and potentially cause a network outage if the configuration were to be put into service.",
"fixid": "F-25887r3_fix",
"fixtext": "Encrypt all network device configurations stored offline.",
"iacontrols": null,
"id": "V-23735",
"ruleID": "SV-28616r3_rule",
"severity": "medium",
"title": "The organization must encrypt all network device configurations while stored offline.",
"version": "NET1050"
},
"V-25319": {
"checkid": "C-31754r3_chk",
"checktext": "Have the SA show how the guest WLAN is physically connected to the firewall or supporting switch and how it is logically connected through firewall or switch configuration settings. Verify the equipment is connected via a separate WLAN or logical segmentation of the host WLAN (e.g., separate service set identifier (SSID) and virtual LAN). \n\nIf a guest WLAN is set up as a separate WLAN from the DoD network or not set up as a logical segmentation from the DoD network or DoD WLAN, this is a finding.",
"description": "If the access point or its supporting authentication server is placed in front of the perimeter firewall, then it has no firewall protection against an attack. If the access point or its supporting authentication server is placed behind the perimeter firewall (on the internal network), then any breach of these devices could lead to attacks on other DoD information systems.",
"fixid": "F-28238r1_fix",
"fixtext": "Reconfigure physical and logical connections as needed so the Internet-only WLAN infrastructure resides in a dedicated subnet off the perimeter firewall.",
"iacontrols": null,
"id": "V-25319",
"ruleID": "SV-31432r4_rule",
"severity": "medium",
"title": "DoD Components providing Internet-only guest access must use separate WLAN or logical segmentation of the host WLAN (e.g., separate service set identifier (SSID) and virtual LAN) or DoD network.",
"version": "WIR0123"
},
"V-30255": {
"checkid": "C-38911r2_chk",
"checktext": "Review the WLAN system product documentation. Verify the system is WPA2-Enterprise certified.\n\nIf the WLAN product is not WPA2-Enterprise certified, this is a finding.",
"description": "The Wi-Fi Alliance WPA2-Enterprise certification means the WLAN equipment can support DoD requirements, most notably EAP-TLS and AES-CCMP. If the equipment has not been WPA-Enterprise certified, then the equipment may not have the required security functionality to protect DoD networks and information.",
"fixid": "F-34048r1_fix",
"fixtext": "Procure WPA2-Enterprise certified WLAN equipment.",
"iacontrols": null,
"id": "V-30255",
"ruleID": "SV-39891r3_rule",
"severity": "medium",
"title": "The Wireless Local Area Network (WLAN) must be Wi-Fi Protected Access 2 (WPA2)-Enterprise certified by the Wi-Fi Alliance.",
"version": "WIR0114"
},
"V-31632": {
"checkid": "C-40348r4_chk",
"checktext": "Validate global IP addresses in use on unclassified or classified networks registered through the DoD Network Information Center. For NIPRNet, go to the website https://www.nic.mil. For SIPRNet, go to the web portal at http://www.ssc.smil.mil. To verify Department of the Navy IP addresses, go to http://infosec.navy.mil.ipaddress.com.\n\nIf the site is using an address space that has not been registered and allocated to the site, this is a finding.",
"description": "If network address space is not properly configured, managed, and controlled, the network could be accessed by unauthorized personnel resulting in security compromise of site information and resources. Allowing subscribers onto the network whose IP addresses are not registered with the .Mil NIC may allow unauthorized users access into the network. These unauthorized users could then monitor the network, steal passwords, and access classified information.",
"fixid": "F-35552r4_fix",
"fixtext": "Submit any unregistered and/or unauthorized global IP addresses to the DoD Network Information Center (NIC) for registration.",
"iacontrols": null,
"id": "V-31632",
"ruleID": "SV-41919r3_rule",
"severity": "medium",
"title": "All global address ranges used on unclassified and classified networks must be properly registered with the DoD Network Information Center (NIC).",
"version": "NET0180"
},
"V-31637": {
"checkid": "C-40352r12_chk",
"checktext": "Review network diagrams, enterprise sensor reports, and network scans submitted to the Connection Approval Office. Determine that only global IP addresses assigned by the NIC are in use within the organization's SIPRNet enclave.\n\nDetermine whether NAT and unauthorized IP address space is in use in the organization's SIPRNet enclave.\n\nExceptions to this requirement are listed below:\n1. Closed classified networks logically transiting SIPRNet for enclave-to-enclave VPN transport only.\n2. Out-of-Band management networks, where the NATd nodes do not access SIPRNet base enterprise services.\n3. Thin client deployments where the hosting thin client server serves as the SIPRNet access point for its thin clients and that the organization maintains detailed thin client service usage audit logs.\n4. Valid operational mission need or implementation constraints.\n\nAll exceptions must have approval by the SIPRNet DISN accreditation official, DISA AO.\n\nIf NAT and unauthorized IP address space is in use on the organization's SIPRNet infrastructure, this is a finding.",
"description": "The DoD has an enterprise level security-focused configuration management (SecCM) requirement to support end-to-end monitoring of SIPRNet, as a National Security System (NSS). The use of NAT and private IP address space inhibits the view of specialized DISN enterprise tools in tracking client level enclave to enclave traffic, monitoring client use of enterprise level application services, and detecting anomalies and potential malicious attacks in SIPRNet client application traffic flows. Enclave nodes that communicate outside the organization\u2019s enclave to other SIPRNet enclaves or enterprise services cannot use NATd private addresses via an enclave proxy without the permission of the SIPRNet DISN Authorizing Official, the DISA AO.",
"fixid": "F-35556r6_fix",
"fixtext": "Remove the NAT configurations and private address space from the organization's SIPRNet enclave. Configure the SIPRNet enclave with SSC authorized .smil.mil or .sgov.gov addresses. If NAT or private address space is required, as per one of the stated exceptions or for valid mission requirements, then submit a detailed approval request to use private addressing through the DSAWG Secretariat to the DISN accreditation official, DISA AO.",
"iacontrols": null,
"id": "V-31637",
"ruleID": "SV-41924r7_rule",
"severity": "medium",
"title": "Network Address Translation (NAT) and private IP address space must not be deployed within the SIPRNet enclave.",
"version": "NET0185"
},
"V-33831": {
"checkid": "C-41894r5_chk",
"checktext": "Review the Bogon/Martian maintenance policy to validate plans and procedures are in place to protect the enclave from illegitimate network traffic with up to date Bogon/Martian rulesets. \n\nIf the site does not have a policy to keep Bogon/Martian rulesets up to date, this is a finding.",
"description": "A Bogon route or Martian address is a type of packet that should never be routed inbound through the perimeter device. Bogon routes and Martian addresses are commonly found as the source addresses of DDoS attacks. By not having a policy implemented to keep these addresses up to date, the enclave will run the risk of allowing illegitimate traffic into the enclave or even blocking legitimate traffic. Also, if there are rulesets with \"any\" as the source address then Bogons/Martians must be applied.\n\nBogons and Martian addresses can be kept up to date routinely checking the IANA website or creating an account with Team Cymru to retrieve these lists in one of many ways.\n\nhttp://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml\nhttp://www.team-cymru.org/Services/Bogons/",
"fixid": "F-37761r2_fix",
"fixtext": "Implement a Bogon/Martian maintenance policy to protect the enclave from illegitimate network traffic.",
"iacontrols": null,
"id": "V-33831",
"ruleID": "SV-44284r2_rule",
"severity": "medium",
"title": "A policy must be implemented to keep Bogon/Martian rulesets up to date.",
"version": "NET0928"
},
"V-66349": {
"checkid": "C-66995r1_chk",
"checktext": "Review the network topology and interview the ISSO to verify that each external connection to the site\u2019s network has been validated and approved by the AO and CAO and that CAP requirements have been met.\n\nIf there are any external connections that have not been validated and approved, this is a finding.",
"description": "Prior to establishing a connection with another activity, a Memorandum of Understanding (MOU) or Memorandum of Agreement (MOA) must be established between the two sites prior to connecting with each other.",
"fixid": "F-72425r1_fix",
"fixtext": "All external connections will be validated and approved prior to connection. Interview the ISSM to verify that all connections have a mission requirement and that the AO is aware of the requirement.",
"iacontrols": null,
"id": "V-66349",
"ruleID": "SV-80839r1_rule",
"severity": "medium",
"title": "Prior to having external connection provisioned between enclaves, a Memorandum of Agreement (MOA) or Memorandum of Understanding (MOU) must be established.",
"version": "NET0131"
},
"V-66351": {
"checkid": "C-66997r1_chk",
"checktext": "Examine the syslog server to verify that it is configured to store messages for at least 30 days. Have the administrator show you the syslog files stored offline for one year.\n\nIf the syslog messages are not kept online for thirty days and offline for one year, this is a finding.",
"description": "Logging is a critical part of router security. Maintaining an audit trail of system activity logs (syslog) can help identify configuration errors, understand past intrusions, troubleshoot service disruptions, and react to probes and scans of the network.",
"fixid": "F-72427r1_fix",
"fixtext": "Configure the syslog server to store messages for at least 30 days on-line. The administrator must establish a strategy for storing the logs off-line for minimum of 1 year.",
"iacontrols": null,
"id": "V-66351",
"ruleID": "SV-80841r1_rule",
"severity": "low",
"title": "Syslog messages must be retained for a minimum of 30 days online and then stored offline for one year.",
"version": "NET1026"
},
"V-66353": {
"checkid": "C-66999r1_chk",
"checktext": "Review the router configuration to determine if LDP and RSVP messages are being authenticated as shown in the examples below.\n\nIf authentication is not being used for these protocols using a secured hashing algorithm for message authentication, this is a finding.\n\nAn LDP session is secured by configuring a password for each LDP peer as shown in the example below:\n\nmpls ip\nmpls label protocol ldp\nmpls ldp neighbor 10.1.1.1 password xzxxxxxxxxxxx \nmpls ldp neighbor 10.3.3.3 password xxxxxzzzzxxxz\n\nThe IP address 10.1.1.1 and 10.3.3.3 in this example are the router IDs of the neighbors for which this router has an LDP session requiring MD5 authentication. To specify that the router ID 10.1.1.1 is to be found in VPN routing/forwarding instance (VRF) named VPN1 instead of the global route table, the \"vrf\" keyword is used in the command as shown in the following example:\n\nmpls ldp neighbor vrf VPN1 10.1.1.1 password xxxxxxxxxxxxxxxxx\n\nA group of peers using the same MD5 password can be configured as shown in the example below: \n\nmpls ldp password for 10 xxxxxxxxxxxxxxx\nmpls ldp password required for 10\n!\naccess-list 10 permit 10.1.1.1\naccess-list 10 permit 10.3.3.3\naccess-list 10 permit 10.4.4.4\n\nThe access list specifies a password is mandatory for LDP sessions with neighbors whose LDP router IDs are permitted by the access list.\n\nTo configure MD5 or SHA-1 authentication for RSVP, both ip rsvp authentication key and ip rsvp authentication commands must be configured as shown in the example below. The latter command simply enables authentication.\n\ninterface Ethernet0/0\nip address 192.168.101.2 255.255.255.0\nip rsvp bandwidth 7500 7500\nip rsvp authentication type sha-1\nip rsvp authentication key xxxxxxxx ip rsvp authentication\n\nNote: If SHA-1 is not specified using the ip rsvp authentication type command, MD5 will be utilized.",
"description": "Spoofed TCP segments could be introduced into the connection streams for LDP sessions used to build LSPs. By configuring strict authentication between LSR peers, LDP TCP sessions can be restricted and the integrity of LSPs can be guarded using the TCP MD5 Signature Option. The LSR ignores LDP Hellos from any LSR for which a password has not been configured. This ensures that the LSR establishes LDP TCP connections only with LSRs for which the shared secret has been configured. RSVP messages are used to control resource reservations for MPLS TE tunnels inside the MPLS core. The RSVP message authentication permits neighbors to use a secure hash to digitally sign all RSVP signaling messages, thus allowing the receiver of an RSVP message to verify the sender. By protecting against corruption and spoofing of RSVP messages, the integrity of the LSPs for bandwidth provisioning, path setup, and path teardown is maintained.",
"fixid": "F-72429r1_fix",
"fixtext": "Implement neighbor authentication using a secured hashing algorithm for all signaling protocols deployed to build LSP tunnels.",
"iacontrols": null,
"id": "V-66353",
"ruleID": "SV-80843r1_rule",
"severity": "medium",
"title": "Multi-Protocol Labeled Switching (MPLS) protocols deployed to build Label-Switch Path (LSP) tunnels must authenticate all messages with a hash function using the most secured cryptographic algorithm available.",
"version": "NET2000"
},
"V-66355": {
"checkid": "C-67001r1_chk",
"checktext": "Review the DISN-facing interfaces of the enclave perimeter routers to verify that LDP or RSVP is not enabled.\n\nIf any of these interfaces are LDP or RSVP enabled, this is a finding.",
"description": "MPLS label exchange via Label Distribution Protocol (LDP) or Resource Reservation Protocol (RSVP) with any external neighbor creates the risk of label spoofing that could disrupt optimum routing, or even drop packets that are encapsulated with a label that is not in the MPLS forwarding table.",
"fixid": "F-72431r1_fix",
"fixtext": "Disable LDP and RSVP on DISN-facing interfaces on all perimeter routers.",
"iacontrols": null,
"id": "V-66355",
"ruleID": "SV-80845r1_rule",
"severity": "medium",
"title": "Multi-Protocol Labeled Switching (MPLS) labels must not be exchanged between the enclaves edge routers and any external neighbor routers.",
"version": "NET2001"
},
"V-66357": {
"checkid": "C-67003r1_chk",
"checktext": "Review the router configuration and verify that the \"mpls ldp sync\" command is configured on the IS-IS or OSPF configuration as shown in the following example: \n\nmpls ip\nmpls label protocol ldp\n!\ninterface POS0/3\nip router isis\nmpls ip\n...\n...\n...\nrouter isis\nmpls ldp sync\n\nIf not all MPLS routers synchronize IGP and LDP, this is a finding.\n\nNote: If the LDP peer is reachable, the IGP waits indefinitely (by default) for synchronization to be achieved. To limit the length of time the IGP session must wait, enter the \"mpls ldp igp sync holddown\" command. If the LDP peer is not reachable, the IGP establishes the adjacency to enable the LDP session to be established.",
"description": "Packet loss can occur when an IGP adjacency is established and the router begins forwarding packets using the new adjacency before the LDP label exchange completes between the peers on that link. Packet loss can also occur if an LDP session closes and the router continues to forward traffic using the link associated with the LDP peer rather than an alternate pathway with a fully synchronized LDP session. The MPLS LDP-IGP Synchronization feature provides a means to synchronize LDP with OSPF or IS-IS to minimize MPLS packet loss. When an IGP adjacency is established on a link but LDP-IGP synchronization is not yet achieved or is lost, the IGP will advertise the max-metric on that link.",
"fixid": "F-72433r1_fix",
"fixtext": "Configure the MPLS router to synchronize IGP and LDP, minimizing packet loss when an IGP adjacency is established prior to LDP peers completing label exchange.",
"iacontrols": null,
"id": "V-66357",
"ruleID": "SV-80847r1_rule",
"severity": "low",
"title": "Label Distribution Protocol (LDP) must be synchronized with the Interior Gateway Protocol (IGP) to minimize packet loss when an IGP adjacency is established prior to LDP peers completing label exchange.",
"version": "NET2002"
},
"V-66359": {
"checkid": "C-67005r1_chk",
"checktext": "Review the switch configuration to verify that VTP clients and servers are authenticating messages as shown in the following configuration example:\n\nvtp mode server\nvtp version 2\nvtp domain ICAN1\nvtp password xxxxxxxx\n\nIf any switches within the ICAN infrastructure have implemented VTP and are not authenticating VTP messages with a hash function using the most secured cryptographic algorithm available, this is a finding.",
"description": "VLAN Trunk Protocol (VTP) provides central management of VLAN domains, thus reducing administration in a switched network. When configuring a new VLAN on a VTP server, the VLAN is distributed through all switches in the domain. This reduces the need to configure the same VLAN everywhere. VTP pruning preserves bandwidth by preventing VLAN traffic (unknown MAC, broadcast, multicast) from being sent down trunk links when not needed, that is, there are no access switch ports in neighboring switches belonging to such VLANs. An attack can force a digest change for the VTP domain enabling a rogue device to become the VTP server, which could allow unauthorized access to previously blocked VLANs or allow the addition of unauthorized switches into the domain. Authenticating VTP messages with a cryptographic hash function can reduce the risk of the VTP domain's being compromised.",
"fixid": "F-72435r1_fix",
"fixtext": "Configure the switch to authenticate all VLAN Trunk Protocol (VTP) messages with a hash function using the most secured cryptographic algorithm available.",
"iacontrols": null,
"id": "V-66359",
"ruleID": "SV-80849r1_rule",
"severity": "medium",
"title": "VLAN Trunk Protocol (VTP) messages must be authenticated with a hash function using the most secured cryptographic algorithm available.",
"version": "NET2003"
},
"V-66361": {
"checkid": "C-67007r1_chk",
"checktext": "In cases where VLANs do not span multiple switches it is a best practice to not implement STP. Avoiding the use of STP will provide the most deterministic and highly available network topology. If STP is required, then review the switch configuration to verify that RSTP or MSTP has been implemented. Following are example configurations:\n\nRSTP\n\nspanning-tree mode rapid-pvst\n\nMST\n\nspanning-tree mode mst\nspanning-tree mst configuration\n name Region1\n revision 1\n instance 1 vlan 10, 11, 12\n instance 2 vlan 13, 14\n\nIf RSTP or MSTP has not been implemented where STP is required, this is a finding.\n\nNote: Note: Cisco has implemented RSTP as part of MSTP and Rapid-PVST+.",
"description": "Spanning Tree Protocol (STP) is implemented on bridges and switches to prevent Layer 2 loops when a broadcast domain spans multiple bridges and switches and when redundant links are provisioned to provide high availability in case of link failures. Convergence time can be significantly reduced using Rapid STP (802.1w) instead of STP (802.1d), resulting in improved availability. Rapid STP should be deployed by implementing either Rapid Per-VLAN-Spanning-Tree (Rapid-PVST) or Multiple Spanning-Tree Protocol (MSTP), the later scales much better when there are many VLANs.",
"fixid": "F-72437r1_fix",
"fixtext": "Configure Rapid STP be implemented at the access and distribution layers where VLANs span multiple switches.",
"iacontrols": null,
"id": "V-66361",
"ruleID": "SV-80851r1_rule",
"severity": "low",
"title": "Rapid Spanning Tree Protocol (STP) must be implemented at the access and distribution layers where Virtual Local Area Networks (VLANs) span multiple switches.",
"version": "NET2004"
},
"V-66363": {
"checkid": "C-67009r1_chk",
"checktext": "Review each router and verify that a QoS policy has been configured to provide preferred treatment for control plane traffic and C2 real-time services.\n\nStep 1: Verify that the class-maps are configured to match on DSCP values that have been set at the edges as shown in the configuration example below:\n\nclass-map match-all CONTROL_PLANE\nmatch ip dscp 48\nclass-map match-all C2_VOICE\nmatch ip dscp 47\nclass-map match-all VOICE\nmatch ip dscp ef\nclass-map match-all VIDEO\nmatch ip dscp af4\nclass-map match-all PREFERRED_DATA\nmatch ip dscp af3\n\nStep 2: Verify that the policy map applied to the core-layer-facing interface reserves the bandwidth for each traffic type as shown in the following example:\n\npolicy-map QOS_POLICY\nclass CONTROL_PLANE\npriority percent 10\nclass C2_VOICE\npriority percent 10\nclass VOICE\npriority percent 15\nclass VIDEO\nbandwidth percent 25\nclass PREFERRED_DATA\nbandwidth percent 25\nclass class-default\nbandwidth percent 15\n\nStep 3: Verify that an output service policy is bound to the core-layer-facing interface as shown in the configuration example below:\n\ninterface GigabitEthernet1/1\n ip address 10.2.0.2 255.255.255.252\n service-policy output QOS_POLICY\n\nIf a QoS policy has not been implemented within the JIE WAN infrastructure to provide assured services for control plane traffic and C2 real-time services, this is a finding.",
"description": "Different applications have unique requirements and toleration levels for delay, jitter, packet loss, and availability. To manage the multitude of applications and services, a network requires a Quality of Service (QoS) framework to differentiate traffic and provide a method to manage network congestion. The Differentiated Services Model (DiffServ) is based on per-hop behavior by categorizing traffic into different classes and enabling each node to enforce a forwarding treatment to each packet as dictated by a service policy. Packet markings such as IP Precedence and its successor, Differentiated Services Code Points (DSCP), were defined along with specific per-hop behaviors for key traffic types to enable a scalable QoS solution. DiffServ QoS categorizes network traffic, prioritizes it according to its relative importance, and provides priority treatment based on the classification. It is imperative that end-to-end QoS is implemented to guarantee the required bandwidth for control plane traffic and C2 real-time services during periods of congestion within the JIE WAN IP network.",
"fixid": "F-72439r1_fix",
"fixtext": "Configure a QoS policy on each router to provide assured services for control plane traffic and C2 real-time services.",
"iacontrols": null,
"id": "V-66363",
"ruleID": "SV-80853r1_rule",
"severity": "low",
"title": "A Quality of Service (QoS) policy must be implemented to provide preferred treatment for Command and Control (C2) real-time services and control plane traffic.",
"version": "NET2005"
},
"V-66365": {
"checkid": "C-67011r1_chk",
"checktext": "By default, multicast is disabled globally as well as on all interfaces. Multicast routing is enabled on a router with the global command ip multicast-routing. PIM is enabled on an interface with either of the following commands: ip pim sparse-mode, ip pim dense-mode, ip pim sparse-dense-mode. If the global command ip multicast-routing is defined, review all interface configurations and verify that only the required interfaces are enabled for PIM. The following is a sample configuration with multicast routing enabled and PIM enabled on an interface.\n\nip multicast-routing\n!\ninterface FastEthernet0/0 \nip pim sparse-mode\n\nIf PIM is not disabled on interfaces that are not supporting multicast, this is a finding.",
"description": "PIM is a routing protocol that is used by the IP core for forwarding multicast traffic. PIM operates independent of any particular IP routing protocol but makes use of the IP unicast routing table--PIM does not keep a separate multicast routing table. The multicast tree is built by first allowing a flood of traffic from the source to every dense mode router in the network. For a brief time, unnecessary traffic is allowed. As each router receives traffic for the group, it will decide whether it has active recipients wanting to receive the multicast data. If so, the router will let the flow continue. If no hosts have registered for the multicast group, the router sends a prune message to its neighbor toward the source. That branch of the tree is then pruned off so that the unnecessary traffic does not continue. Dense mode is viewed as a \"flood and prune\" implementation. With PIM Sparse Mode (PIM-SM), the multicast tree is not extended to a router unless a local host has already joined the group. The multicast tree is built by beginning with group members at the end leaf nodes and extending back toward a central root point--the tree is built from the bottom up. In either case, if an interface is not going to be supporting any of the multicast traffic--that is, join a multicast tree, PIM should be disabled.",
"fixid": "F-72441r1_fix",
"fixtext": "The router administrator will disable PIM on all router interfaces that are not required to support multicast routing.",
"iacontrols": null,
"id": "V-66365",
"ruleID": "SV-80855r1_rule",
"severity": "medium",
"title": "Protocol Independent Multicast (PIM) must be disabled on all router interfaces that are not required to support multicast routing.",
"version": "NET2006"
},
"V-66367": {
"checkid": "C-67013r1_chk",
"checktext": "Step 1: Verify that an ACL is configured that will specify the allowable PIM neighbors similar to the following example.\n\nip access-list standard pim-neighbors permit 192.0.2.1\npermit 192.0.2.3\n\nStep 2: Verify that a pim neighbor-filter command is configured on all PIM enabled interfaces that is referencing the PIM neighbor ACL similar to the following example:\n\ninterface GigabitEthernet0/3\nip address 192.0.2.2 255.255.255.0\npim neighbor-filter pim-neighbors\n\nIf PIM neighbor filter is not bound to interfaces that have PIM enabled, this is a finding.",
"description": "Protocol Independent Multicast (PIM) is a routing protocol that is used by the IP core for forwarding multicast traffic. PIM traffic must be limited to only known PIM neighbors by configuring and binding a PIM neighbor filter to those interfaces that have PIM enabled.",
"fixid": "F-72443r1_fix",
"fixtext": "The router administrator configures and binds a PIM neighbor filter to those interfaces that have PIM enabled.",
"iacontrols": null,
"id": "V-66367",
"ruleID": "SV-80857r1_rule",
"severity": "low",
"title": "A Protocol Independent Multicast (PIM) neighbor filter must be implemented to restrict and control multicast traffic.",
"version": "NET2007"
},
"V-66369": {
"checkid": "C-67015r1_chk",
"checktext": "The administratively-scoped IPv4 multicast address space is 239.0.0.0 through 239.255.255.255. Packets addressed to administratively-scoped multicast addresses must not cross administrative boundaries. This can be accomplished by applying a multicast boundary statement to all COI-facing interfaces as shown in the following example:\n\nip multicast-routing\n!\ninterface FastEthernet0/0\nip address 199.36.92.1 255.255.255.252\nip pim sparse-mode\nip multicast boundary 1\n!\naccess-list 1 deny 239.0.0.0 0.255.255.255 \naccess-list 1 permit any\n\nIf inbound and outbound administratively-scoped multicast traffic is not blocked, this is a finding.",
"description": "A multicast boundary must be established to ensure that administratively-scoped multicast traffic does not flow into or out of the IP core. The multicast boundary can be created by ensuring that COI-facing interfaces on all PIM routers are configured to block inbound and outbound administratively-scoped multicast traffic.",
"fixid": "F-72445r1_fix",
"fixtext": "Configure a multicast boundary statement at all COI-facing interfaces that has PIM enabled to block inbound and outbound administratively-scoped multicast traffic.",
"iacontrols": null,
"id": "V-66369",
"ruleID": "SV-80859r1_rule",
"severity": "low",
"title": "The multicast domain must block inbound and outbound administratively-scoped multicast traffic at the edge.",
"version": "NET2008"
},
"V-66371": {
"checkid": "C-67017r1_chk",
"checktext": "To prevent Auto-RP messages from entering or leaving the PIM domain, the ip multicast boundary command must be configured on a COI-facing PIM-enabled interface. Verify that the referenced ACL denies multicast addresses 224.0.1.39 and 224.0.1.40, as shown in the example below:\n\nip multicast-routing\n!\ninterface FastEthernet0/0\nip address 199.36.92.1 255.255.255.252\nip pim sparse-mode\nip multicast boundary 1\n!\naccess-list 1 deny 224.0.1.39\naccess-list 1 deny 224.0.1.40\n\nIf COI-facing interfaces do not block inbound and outbound Auto-RP discovery and announcement messages, this is a finding.",
"description": "With static RP, the RP address for any multicast group must be consistent across all routers in a multicast domain. A static configuration is simple and convenient. However, if the statically defined RP router becomes unreachable, there is no automatic failover to another RP router. Auto-RP distributes information to routers as to which RP address must be used for various multicast groups. Auto-RP eliminates inconsistencies and enables scalability and automatic failover. All PIM-enabled routers join the RP discovery group (224.0.1.40), which allows them to receive all group-to-RP mapping information. This information is distributed by an entity called RP mapping agent. Mapping agents themselves join the RP announce group (224.0.1.39). All candidate RPs advertise themselves periodically using the RP announce group address. The mapping agent listens to all RP candidate announcements and determines which routers will be used for each multicast group. It then advertises the RP and its associate multicast groups to all PIM routers in the network using an RP discovery message. Auto-RP announcement and discovery messages provide information (i.e., IP addresses of the RP candidates, multicast groups, etc.) vital to the multicast domain and should not be leaked out of the multicast domain. Using this information, a malicious user could disrupt multicast services by attacking the RP or flooding bogus traffic destined to the learned multicast groups.",
"fixid": "F-72447r1_fix",
"fixtext": "Block inbound and outbound Auto-RP discovery and announcement messages at external-facing PIM-enabled interfaces.",
"iacontrols": null,
"id": "V-66371",
"ruleID": "SV-80861r1_rule",
"severity": "low",
"title": "The multicast domain must block inbound and outbound Auto-RP discovery and announcement messages at the edge.",
"version": "NET2009"
},
"V-66373": {
"checkid": "C-67019r1_chk",
"checktext": "Verify that the RP router is configured to filter PIM register messages using the ip pim accept-register global command as shown in the example below. This command can reference either an ACL or a route-map to identify and prevent unauthorized sources or groups from registering with the RP.\n\nip pim accept-register list PIM_REGISTER_FILTER\n!\nip access-list extended PIM_REGISTER_FILTER\ndeny ip any 224.0.0.0 0.0.0.255\ndeny ip 0.0.0.0 0.255.255.255 any\ndeny ip 1.0.0.0 0.255.255.255 any\ndeny ip 2.0.0.0 0.255.255.255 any\ndeny ip 5.0.0.0 0.255.255.255 any\ndeny ip 7.0.0.0 0.255.255.255 any\ndeny ip 10.0.0.0 0.255.255.255 any\ndeny ip 23.0.0.0 0.255.255.255 any\ndeny ip 27.0.0.0 0.255.255.255 any\n...\n...\n...\ndeny ip 172.16.0.0 0.15.255.255 any\ndeny ip 192.168.0.0 0.0.255.255 any\ndeny ip 197.0.0.0 0.255.255.255 any\ndeny ip 223.0.0.0 0.255.255.255 any\ndeny ip 224.0.0.0 224.255.255.255 any\npermit ip any any\n\nIf the RP router peering with customer PIM-SM routers is not configured with a PIM import policy to block registration messages for reserved multicast groups, this is a finding.",
"description": "Customer networks that do not maintain a multicast domain and only require the IP multicast service will be required to stand up a PIM-SM router that will be incorporated into the JIE shared tree structure by establishing a peering session with an RP router. Both of these implementations expose several risks that must be mitigated to provide a secured IP core network. All RP routers that are peering with customer PIM-SM routers must implement a PIM import policy to block multicast registration requests for reserved or any other undesirable multicast groups.",
"fixid": "F-72449r1_fix",
"fixtext": "Configure RP routers to filter PIM register messages received from a tenant multicast DR for any reserved or any other undesirable multicast groups.",
"iacontrols": null,
"id": "V-66373",
"ruleID": "SV-80863r1_rule",
"severity": "low",
"title": "Protocol Independent Multicast (PIM) register messages received from a downstream multicast Designated Routers (DR) must be filtered for any reserved or any other undesirable multicast groups.",
"version": "NET2010"
},
"V-66375": {
"checkid": "C-67023r1_chk",
"checktext": "Verify that the RP router is configured to filter PIM join messages for any reserved multicast groups using the ip pim accept-rp global command as shown in the example below. The ip pim accept-rp global command causes the router to accept only (*, G) join messages destined for the specified RP address as allowed by the referenced access-list.\n\nip pim accept-rp 10.10.2.1 PIM_JOIN_FILTER\n!\nip access-list standard PIM_JOIN_FILTER\ndeny 224.0.1.2\ndeny 224.0.1.3\ndeny 224.0.1.8\ndeny 224.0.1.22\ndeny 224.0.1.24\ndeny 224.0.1.25\n...\n...\n...\ndeny 225.1.2.3\ndeny 229.55.150.208\ndeny 234.42.42.42 255.255.255.252\ndeny 239.0.0.0 0.255.255.255\npermit any\n\nNote: IOS 12.4T extends the ip multicast-routing command with a group-range or access-list argument that can be used to filter multicast control (PIM, IGMP) and data packets for unauthorized groups. \n\nIf the RP router peering with customer PIM-SM routers is not configured with a PIM import policy to block join messages for reserved and any undesirable multicast groups, this is a finding.",
"description": "Customer networks that do not maintain a multicast domain and only require the IP multicast service will be required to stand up a PIM-SM router that will be incorporated into the JIE shared tree structure by establishing a peering session with an RP router. Both of these implementations expose several risks that must be mitigated to provide a secure IP core network. All RP routers that are peering with customer PIM-SM routers must implement a PIM import policy to block multicast join requests for reserved or any other undesirable multicast groups.",
"fixid": "F-72451r1_fix",
"fixtext": "RP routers that are peering with customer PIM-SM routers must implement a PIM import policy to block join messages for reserved and any undesirable multicast groups.",
"iacontrols": null,
"id": "V-66375",
"ruleID": "SV-80865r1_rule",
"severity": "low",
"title": "Protocol Independent Multicast (PIM) join messages received from a downstream multicast Designated Routers (DR) must be filtered for any reserved or any other undesirable multicast groups.",
"version": "NET2011"
},
"V-66379": {
"checkid": "C-67025r1_chk",
"checktext": "Review the configuration of the DR to verify that it is rate limiting the number of multicast register messages.\n\nIf the DR is not limiting multicast register messages, this is a finding.\n\nThe following is a PIM sparse mode configuration example that limits the number of register messages for each (S, G) multicast entry to 10 per second.\n\nip multicast-routing\n! \ninterface FastEthernet 0/0 \ndescription link to core\nip address 192.168.123.2 255.255.255.0\nip pim sparse-mode \n! \ninterface FastEthernet 0/1\ndescription User LAN\nip address 192.168.122.1 255.255.255.0\nip pim sparse-mode \n!\nip pim rp-address 1.1.1.1\nip pim register-rate 10",
"description": "When a new source starts transmitting in a PIM Sparse Mode network, the DR will encapsulate the multicast packets into register messages and forward them to the Rendezvous Point (RP) using unicast. This process can be taxing on the CPU for both the DR and the RP if the source is running at a high data rate and there are many new sources starting at the same time. This scenario can potentially occur immediately after a network failover. The rate limit for the number of register messages should be set to a relatively low value based on the known number of multicast sources within the multicast domain.",
"fixid": "F-72455r1_fix",
"fixtext": "Configure the Designated Router (DR) to rate limit the number of multicast register messages it will allow for each (S, G) entry.",
"iacontrols": null,
"id": "V-66379",
"ruleID": "SV-80869r1_rule",
"severity": "medium",
"title": "Multicast register messages must be rate limited per each source-group (S, G) entry.",
"version": "NET2012"
},
"V-66381": {
"checkid": "C-67027r1_chk",
"checktext": "Review the configuration of the DR to verify that it is filtering IGMP or MLD report messages allowing hosts to only join those groups that have been approved by the organization.\n\nIf the DR is not filtering IGMP or MLD report messages, this is a finding.\n\nThe following is a PIM sparse mode configuration example filtering specific multicast groups as defined in access-list 11 on the LAN-facing interface.\n\nip multicast-routing\n! \ninterface FastEthernet 0/0 \ndescription link to core\nip address 192.168.123.2 255.255.255.0\nip pim sparse-mode \n! \ninterface FastEthernet 0/1\ndescription User LAN\nip address 192.168.122.1 255.255.255.0\nip pim sparse-mode \nip igmp access-group 11\n!\naccess-list 11 permit 224.10.10.0 0.0.0.255\naccess-list 11 permit 224.11.11.0 0.0.0.255\naccess-list 11 permit 224.20.20.0 0.0.0.255",
"description": "Real-time multicast traffic can entail multiple large flows of data. Large unicast flows tend to be fairly isolated (e.g., someone doing a file download here or there), whereas multicast can have broader impact on bandwidth consumption resulting in extreme network congestion. Hence, it is imperative that there is multicast admission control to restrict which multicast groups that hosts are allowed to join via IGMP (IPv4) or MLD (IPv6).",
"fixid": "F-72457r1_fix",
"fixtext": "Configure the Designated Router (DR) to filter the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) report messages to allow tenant hosts to join only those multicast groups that have been approved by the organization.",
"iacontrols": null,
"id": "V-66381",
"ruleID": "SV-80871r1_rule",
"severity": "low",
"title": "Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) report messages must be filtered to allow hosts to join only those multicast groups that have been approved by the organization.",
"version": "NET2013"
},
"V-66389": {
"checkid": "C-67035r1_chk",
"checktext": "Review the DR configuration to verify that it is limiting the number of mroute states via IGMP or MLD.\n\nIf the DR is not limiting multicast join requests via IGMP or MLD, this is a finding.\n\nThe following is a PIM sparse mode DR configuration example that limits the number of IGMP join requests on both a global and a per-interface basis\n\nip multicast-routing\nip igmp limit 80\n! \ninterface FastEthernet 0/1\ndescription User LAN121\nip address 192.168.122.1 255.255.255.0\nip pim sparse-mode \nip igmp limit 50\n!\ninterface FastEthernet 0/2\ndescription User LAN122\nip address 192.168.122.1 255.255.255.0\nip pim sparse-mode \nip igmp limit 50\n\nNote: If both global and per interface state limiters are configured, the limits configured for per interface state limiters are still enforced but are constrained by the global limit.",
"description": "The current multicast paradigm can let any host join any multicast group at any time by sending an Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership report to the Designated Router (DR). In a PIM Sparse Mode network, the DR will send a PIM Join message for the group to the Rendezvous Point (RP). Without any form of admission control, this can pose a security risk to the entire multicast domain, specifically the multicast routers along the shared tree from the DR to the RP that must maintain the mroute state information for each group join request. Hence, it is imperative that the DR is configured to limit the number of mroute state information that must be maintained to mitigate the risk of IGMP (IPv4) or MLD (IPv6) flooding.",
"fixid": "F-72465r1_fix",
"fixtext": "Configure the Designated Router (DR) on a global or interface basis to limit the number of mroute states resulting from IGMP or MLD membership reports.",
"iacontrols": null,
"id": "V-66389",
"ruleID": "SV-80879r1_rule",
"severity": "medium",
"title": "The number of mroute states resulting from Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership reports must be limited.",
"version": "NET2014"
},
"V-66391": {
"checkid": "C-67037r1_chk",
"checktext": "Review the multicast last-hop router configuration to verify that the SPT switchover threshold is increased (default is 0) or set to infinity (never switch over). The following is a PIM sparse mode last-hop router configuration example that will disable the SPT switchover for all multicast groups:\n\nip multicast-routing\nip pim spt-threshold infinity\n\nIf any multicast router is not configured to increase the SPT threshold or set it to infinity to minimalize (S,G) state, this is a finding.",
"description": "Any Source Multicast (ASM) can have many sources for the same groups (many-to-many). For many receivers, the path via the Rendezvous Point (RP) may not be ideal compared with the shortest path from the source to the receiver. By default, the last-hop router will initiate a switch from the shared tree to a source-specific shortest-path tree (SPT) to obtain lower latencies. This is accomplished by the last-hop router sending an (S, G) PIM Join towards S (the source). When the last-hop router begins to receive traffic for the group from the source via the SPT, it will send a PIM Prune message to the RP for the (S, G). The RP will then send a Prune message towards the source. The SPT switchover becomes a scaling issue for large multicast topologies that have many receivers and many sources for many groups because (S, G) entries require more memory than (*, G). Hence, it is imperative to minimize the amount of (S, G) state to be maintained by increasing the threshold that determines when the SPT switchover occurs.",
"fixid": "F-72467r1_fix",
"fixtext": "Configure the multicast router to increase the SPT threshold or set it to infinity to minimalize (S,G) state within the multicast topology where Any Source Multicast (ASM) is deployed.",
"iacontrols": null,
"id": "V-66391",
"ruleID": "SV-80881r1_rule",
"severity": "medium",
"title": "The number of source-group (SG) states must be limited within the multicast topology where Any Source Multicast (ASM) is deployed.",
"version": "NET2015"
},
"V-66393": {
"checkid": "C-67041r1_chk",
"checktext": "Review the access switches connected to multicast last-hop routers to determine if IGMP snooping is enabled. The following are switch configuration examples with IGMP snooping enabled globally and on a per-VLAN basis:\n\nEnable IGMP Snooping globally: ip igmp snooping\n\nEnable IGMP Snooping for VLAN: ip igmp snooping vlan 7\n\nIf any switches within the ICAN access layer do not have IGMP or MLD snooping enabled, this is a finding.",
"description": "The last-hop router sends the multicast packet out the interface towards the LAN containing interested receivers. The default behavior for a Layer 2 switch is to forward all multicast traffic out every access switch port that belongs to the VLAN. IGMP snooping is a mechanism used by \"Layer 3 aware\" switches to maintain a Layer 2 multicast table by examining all IGMP join and leave messages (destined to the all router's multicast address 224.0.0.2) sent between hosts and the multicast routers on the LAN. This will enable the switch to only forward multicast packets out the access switch ports that have connected hosts that have subscribed to the multicast group, thereby reducing the load on the switching backplane as well as eliminating unwanted traffic to uninterested hosts.",
"fixid": "F-72469r1_fix",
"fixtext": "Configure the switch to implement IGMP or MLD snooping, ensuring multicast traffic for any given multicast group is forwarded to only those hosts that have joined the group.",
"iacontrols": null,
"id": "V-66393",
"ruleID": "SV-80883r1_rule",
"severity": "low",
"title": "Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) snooping must be implemented within the network access layer.",
"version": "NET2016"
},
"V-66397": {
"checkid": "C-67043r2_chk",
"checktext": "All routers or multilayer switches providing first-hop redundancy services must be configured to delay preemption to provide enough time for the IGP to stabilize. Review the router or multilayer switch providing first-hop redundancy services and verify that the preemption delay is configured.\n\nIf preemption delay is not configured, this is a finding.\n\nFollowing is an HSRP configuration example that delays the preemption by 30 seconds.\n\ninterface GigabitEthernet 0/0/0\nip address 10.11.0.2 255.255.255.0\nstandby 1 priority 110\nstandby 1 ip 10.21.0.1\nstandby 1 preempt\nstandby 1 preempt delay minimum 30\n\nFollowing is a VRRP configuration example that delays the preemption by 30 seconds.\n\ninterface GigabitEthernet 0/0/0\nip address 10.11.0.2 255.255.255.0\nvrrp 1 priority 110\nvrrp 1 ip 10.21.0.1\nvrrp 1 preempt delay minimum 30\n\nFor VRRP implementations, a preemptive scheme is enabled by default. If preemption is disabled using the no vrrp preempt command, the virtual router backup that is elected to become virtual router master remains the master until the original virtual router master recovers and becomes master again.",
"description": "The Layer 2 connection between the nodes providing first-hop redundancy comes up quickly. If the preemption takes effect prior to the routing protocol converging, traffic is black holed. Traffic will go to the active router that does not have full routing information. It may take several seconds for the IGP to exchange all the routes, longer than the Hot Standby Router Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), or Gateway Load Balancing Protocol (GLPB) transition. The recommended practice is to delay the preemption action until after the IGP has a chance to stabilize.",
"fixid": "F-72473r1_fix",
"fixtext": "Configure each router and multilayer switch providing first-hop redundancy services to be configured to delay the preempt to provide enough time for the IGP to stabilize.\n\nNote: The amount of delay will be based on the number of IGP routes.",
"iacontrols": null,
"id": "V-66397",
"ruleID": "SV-80887r2_rule",
"severity": "low",
"title": "First-hop redundancy services must be configured to delay any preempt to provide enough time for the Internet Gateway Protocol (IGP) to stabilize.",
"version": "NET2017"
},
"V-8046": {
"checkid": "C-7427r6_chk",
"checktext": "Validate the network diagram by correlating the information with all routers, multi-layer switches, and firewall configurations.\n\nValidate all subnets have been documented accordingly.\n\nValidate any connectivity documented on the diagram by physically examining the cable connections for the downstream and upstream links, as well as connections for major network components (Routers, Switches, Firewalls, IDS/IPS, etc.).\n\nIf the site has not maintained network topology diagrams for the enclave, this is a finding.",
"description": "To assist in the management, auditing, and security of the network infrastructure facility drawings and topology maps are a necessity. Topology maps are important because they show the overall layout of the network infrastructure and where devices are physically located. They also show the relationship and interconnectivity between devices and where possible intrusive attacks could take place. Having up to date network topology diagrams will also help show what the security, traffic, and physical impact of adding a new user(s) will be on the network.",
"fixid": "F-7621r4_fix",
"fixtext": "Update the enclave's network topology diagram to represent the current state of the network and its connectivity.",
"iacontrols": null,
"id": "V-8046",
"ruleID": "SV-8532r3_rule",
"severity": "medium",
"title": "Network topology diagrams for the enclave must be maintained and up to date at all times.",
"version": "NET0090"
},
"V-8047": {
"checkid": "C-7428r3_chk",
"checktext": "Review the network topology and interview the ISSO to verify that each external connection to the site\u2019s network has been validated and approved by the AO and CAO and that CAP requirements have been met.\n\nIf there are any external connections that have not been validated and approved, this is a finding.",
"description": "Every site must have a security policy to address filtering of the traffic to and from those connections. This documentation along with diagrams of the network topology is required to be submitted to the Connection Approval Process (CAP) for approval to connect to the NIPRNet or SIPRNet. SIPRNet connections must also comply with the documentation required by the Classified Connection Approval Office (CCAO) to receive the SIPRNet Interim Approval to Connect (IATC) or final Approval to Connect (ATC). Also any additional requirements must be met as outlined in the Interim Authority to Operate (IATO) or Authority to Operate (ATO) forms signed by the Authorizing Official (AO).",
"fixid": "F-7622r3_fix",
"fixtext": "All external connections will be validated and approved prior to connection. Interview the ISSM to verify that all connections have a mission requirement and that the AO is aware of the requirement.",
"iacontrols": null,
"id": "V-8047",
"ruleID": "SV-8533r3_rule",
"severity": "medium",
"title": "All external connections must be validated and approved by the Authorizing Official (AO) and the Connection Approval Office (CAO) and meeting Connection Approval Process (CAP) requirements.",
"version": "NET0130"
},
"V-8048": {
"checkid": "C-7429r5_chk",
"checktext": "Review the network topology and interview the ISSO to verify that external connections to the network are reviewed and documented on a semi-annual basis. \n\nIf there are any external connections that have not been documented, or if the connections are not reviewed on a semi-annual basis, this is a finding.",
"description": "A network is only as secure as its weakest link. It is imperative that all external connections be reviewed and kept to a minimum needed for operations. All external connections should be treated as untrusted networks. Reviewing who or what the network is connected to empowers the security manager to make sound judgements and security recommendations. Minimizing backdoor circuits and connections reduces the risk for unauthorized access to network resources.",
"fixid": "F-7623r3_fix",
"fixtext": "Implement a semi-annual review process to document and account for external connections to the organization.",
"iacontrols": null,
"id": "V-8048",
"ruleID": "SV-8534r4_rule",
"severity": "medium",
"title": "External connections to the network must be reviewed and the documentation updated semi-annually.",
"version": "NET0135"
},
"V-8049": {
"checkid": "C-7430r3_chk",
"checktext": "Review the network topology to determine external connections and inspect location where CSU/DSUs and data service jacks reside.\n\nIf these components are not in a secured environment, this is a finding.",
"description": "DOD leased lines carry an aggregate of sensitive and non-sensitive data; therefore unauthorized access must be restricted. Inadequate cable protection can lead to damage and denial of service attacks against the site and the LAN infrastructure.",
"fixid": "F-7624r3_fix",
"fixtext": "Move all critical communications to controlled access areas. Controlled access areas in this case means controlled restriction to authorize site personnel, i.e., dedicated communications rooms or locked cabinets. This is an area afforded entry control at a security level commensurate with the operational requirement. This protection will be sufficient to protect the network from unauthorized personnel. The keys to the locked cabinets and dedicated communications rooms will be controlled and only provided to authorized network/network security individuals.",
"iacontrols": null,
"id": "V-8049",
"ruleID": "SV-8535r3_rule",
"severity": "low",
"title": "The connection between the Channel Service Unit/Data Service Unit (CSU/DSU) and the Local Exchange Carriers (LEC) data service jack (i.e., demarc) as well as any service provider premise equipment must be located in a secure environment.",
"version": "NET0140"
},
"V-8051": {
"checkid": "C-7432r8_chk",
"checktext": "Any connection to an internet service provider (ISP) must be approved by the Office of the DoD CIO before a connection is made to the ISP. Based on the use cases below, verify written approval has been obtained from the Office of the DoD CIO or verify a renewal request has been appropriately submitted. There are three basic use cases for an ISP connection. \n\nUse case (1): An ISP connection that originates from an approved DISN infrastructure source (includes IAP connections at the DECCs). A DoDIN Waiver is required for a CC/S/A to connect the unclassified DISN to an ISP. These connection requests must come to the Waiver Panel with a Component CIO endorsement of the requirement. These connections should not be provisioned and put into use until waived. Expired waivers pending renewal from the OSD DoDIN Waiver Panel may be downgraded to a Severity 3 category, if proof of a requested renewal can be verified. A DISN enclave that cannot prove DoDIN Waiver approval for the ISP connection is a Severity 1 category. Note: If discovered during a CCRI assessment, the review team lead will immediately report the unapproved ISP connection to the USCYBERCOM (301-688-3585) and the Connection Approval Office (301-225-2900/2901). USCYBERCOM will direct the connection be immediately disconnected. \n\nUse Case (2): An ISP connection to a Stand Alone Enclave (physically and logically separated from any DISN connection) requires DoDIN Waiver approval prior to connection. The Stand Alone Enclave must have an AO issued ATO and the connection must be logically and physically separated from the DISN. An unapproved ISP connection in this use case will be assigned a Severity 3 category.\n\nUse Case (3): An ISP connection to a non-DoD network (such as a contractor-owned infrastructure) co-located on the same premises as the DoD network. The non-DoD network is physically and logically separated from any DoD IP network. Furthermore, it is not connected to any DoD IP network. The non-DoD network infrastructure is not DoD funded nor is it operated or administered by DoD military or civilian personnel. In addition, the non-DoD network with the ISP connection is not storing, processing, or transmitting any DoD data. For such a network as defined herein, a DoDIN Waiver approval is not required for deploying a connection to an ISP. However, the AO must perform and have on file a risk assessment endorsed by the facility or installation command.\n\nIf any of the above use cases that are applicable and written approval has been not been obtained from the Office of the DoD CIO or if a renewal request has not been submitted, this is a finding.",
"description": "Analysis of DoD reported incidents reveal current protective measures at the NIPRNet boundary points are insufficient. Documented ISPs and validated architectures for DMZs are necessary to protect internal network resources from cyber attacks originating from external Internet sources by protective environments.",
"fixid": "F-7626r4_fix",
"fixtext": "Written mission justification approval must be obtained from the Office of the DoD CIO prior to establishing a direct connection to the Internet via commercial service provider outside DoD CIO approved Internet access points (e.g. DISA IAP, Cloud Access Point, NIPRnet Federated Gateway, DREN IAP, etc.).",
"iacontrols": null,
"id": "V-8051",
"ruleID": "SV-8537r4_rule",
"severity": "high",
"title": "Written mission justification approval must be obtained from the Office of the DoD CIO prior to establishing a direct connection to the Internet via commercial service provider outside DoD CIO approved Internet access points (e.g. DISA IAP, Cloud Access Point, NIPRnet Federated Gateway, DREN IAP, etc.).",
"version": "NET0160"
},
"V-8052": {
"checkid": "C-7433r5_chk",
"checktext": "Review the network topology diagram and verify that ingress and egress traffic via external connections to the enclave do not bypass the enclave\u2019s perimeter security. \n\nIf there are external connections to the enclave that bypass the enclaves\u2019 perimeter security, this is a finding.",
"description": "Without taking the proper safeguards, external networks connected to the organization will impose security risks unless properly routed through the perimeter security devices. Since external networks to the organization are considered to be untrusted, this could prove detrimental since there is no way to verify traffic inbound or outbound on this backdoor connection. An attacker could carry out attacks or steal data from the organization without any notification. An external connection is considered to be any link from the organization's perimeter to the NIPRNet, SIPRNet, Commercial ISP, or other untrusted network outside the organization's defined security policy. The DREN and SREN are DoD's Research & Engineering Network. A DoD Network that is the official DoD long-haul network for computational scientific research, engineering, and testing in support of DoD's S&T and T&E communities. It has also been designated as a DoD IPv6 pilot network by the Assistant Secretary of Defense (Networks & Information Integration)/DoD Chief Information Officer ASD (NII)/DoD CIO. A DISN enclave should not have connectivity to the DREN unless approved by the AO and the requirements have been met for all external connections described in NET0130.",
"fixid": "F-7627r5_fix",
"fixtext": "Disconnect any external network connections not routed through the organization's perimeter security or validated and approved by the AO.",
"iacontrols": null,
"id": "V-8052",
"ruleID": "SV-8538r4_rule",
"severity": "medium",
"title": "External network connections must not bypass the enclaves perimeter security.",
"version": "NET0170"
},
"V-8054": {
"checkid": "C-7435r5_chk",
"checktext": "Inspect the site to validate physical network components are in a secure environment with limited access. \n\nIf there are any network components not located in a secure environment, this is a finding.",
"description": "If all communications devices are not installed within controlled access areas, risk of unauthorized access and equipment failure exists, which could result in denial of service or security compromise. It is not sufficient to limit access to only the outside world or non-site personnel. Not everyone within the site has the need-to-know or the need-for-access to communication devices.",
"fixid": "F-7629r4_fix",
"fixtext": "Move all critical communications into controlled access areas. Controlled access area in this case means controlled restriction to authorize site personnel, i.e., dedicated communications rooms or locked cabinets. This is an area afforded entry control at a security level commensurate with the operational requirement. This protection will be sufficient to protect the network from unauthorized personnel. The keys to the locked cabinets and dedicated communications rooms will be controlled and only provided to authorized network/network security individuals.",
"iacontrols": null,
"id": "V-8054",
"ruleID": "SV-8540r3_rule",
"severity": "medium",
"title": "All network infrastructure devices must be located in a secure room with limited access.",
"version": "NET0210"
},
"V-8060": {
"checkid": "C-7441r2_chk",
"checktext": "Review the network topology and verify that a syslog server is located within the management network. Note the IP address as documented on the management network topology and verify that this is what is configured on the network elements as the host device for sending syslog data.\n\nIf a centralized syslog server has not been deployed in the management network, this is a finding.",
"description": "Maintaining an audit trail of system activity logs can help identify configuration errors, understand past intrusions, troubleshoot service disruptions, and react to probes and scans of the network.",
"fixid": "F-7635r2_fix",
"fixtext": "Stand up a syslog server and connect it to the management network. Configure all managed network elements to send syslog data to the syslog server.",
"iacontrols": null,
"id": "V-8060",
"ruleID": "SV-8546r2_rule",
"severity": "low",
"title": "A centralized syslog server must be deployed in the management network.",
"version": "NET1025"
},
"V-8061": {
"checkid": "C-7442r2_chk",
"checktext": "At a minimum, a copy of the current and previous network element configurations must be saved. Storage can take place on a classified network, OOB network, or offline.\n\nIf the current and previous network element configurations are not stored in a secured location, this is a finding.",
"description": "If the network element's non-volatile memory is lost without a recent configuration stored in an offline location, it may take time to recover that segment of the network. Users connected directly to the switch or router will be without service for a longer than acceptable time.",
"fixid": "F-7636r2_fix",
"fixtext": "The network administrator will store the current and previous router and switch configurations in a secure location. Storage can take place on a classified network, OOB network, or offline. Configurations can only be accessed by server or network admin.",
"iacontrols": null,
"id": "V-8061",
"ruleID": "SV-8547r2_rule",
"severity": "low",
"title": "Current and previous network element configurations must be stored in a secured location.",
"version": "NET1040"
},
"V-8066": {
"checkid": "C-7447r3_chk",
"checktext": "Review the network topology diagrams and visually inspect the firewall location to validate correct position on the network. \n\nIf the firewall is not positioned between the perimeter router and the private network and between the perimeter router and the DMZ, this is a finding.\n\nException: If the perimeter security for the enclave or B/C/P/S is provisioned via the JRSS, then this requirement is not applicable.",
"description": "The only way to mediate the flow of traffic between the inside network, the outside connection, and the DMZ is to place the firewall into the architecture in a manner that allows the firewall the ability to screen content for all three destinations.",
"fixid": "F-7641r2_fix",
"fixtext": "Move the firewall into the prescribed location to allow for enforcement of the Enclave Security Policy and allow for all traffic to be screened.",
"iacontrols": null,
"id": "V-8066",
"ruleID": "SV-8552r3_rule",
"severity": "medium",
"title": "When protecting the boundaries of a network, the firewall must be placed between the private network and the perimeter router and the Demilitarized Zone (DMZ).",
"version": "NET0351"
},
"V-8078": {
"checkid": "C-7459r4_chk",
"checktext": "Interview the SA to determine the IDPS backup procedures as well as have SA display the backup files saved on the file server.\n\nIf the IDPS data is not backed up on a weekly basis, this is a finding.",
"description": "IDPS data needs to be backed up to ensure preservation in the case a loss of data due to hardware failure or malicious activity.",
"fixid": "F-7653r2_fix",
"fixtext": "The organization must establish weekly backup procedures for the network IDS/IPS data.",
"iacontrols": null,
"id": "V-8078",
"ruleID": "SV-8564r3_rule",
"severity": "medium",
"title": "The organization must establish weekly data backup procedures for the network Intrusion Detection and Prevention System (IDPS) data.",
"version": "NET-IDPS-033"
},
"V-8080": {
"checkid": "C-7461r2_chk",
"checktext": "Interview the ISSO and the IDPS administrator. Have the IDPS administrator display update notifications that have been received, the build number or patch level, then search the vendor\u2019s vulnerability database for current release and patch level.\n\nIf software and signatures are not updated when updates are provided by the vendor, this is a finding.",
"description": "Keeping the IDPS software updated with the latest engine and attack signatures will allow for the IDPS to detect all forms of known attacks. Not maintaining the IDPS properly could allow for attacks to go unnoticed.",
"fixid": "F-7655r3_fix",
"fixtext": "Have the IDPS administrator subscribe to the X-press notification or similar service offered by the vendor. Ensure the IDPS software is updated when software is available either by DISA or the vendor for security related distributions.",
"iacontrols": null,
"id": "V-8080",
"ruleID": "SV-8566r2_rule",
"severity": "low",
"title": "The Intrusion Detection and Prevention System (IDPS) software and signatures must be updated when updates are provided by the vendor.",
"version": "NET-IDPS-035"
},
"V-8081": {
"checkid": "C-7462r5_chk",
"checktext": "Inspect switches and associated cross-connect hardware are kept in a secured IDF. If the hardware is located in an open area, verify all hardware is located in a secured and locked cabinet.\n\nIf switches and associated cross-connect hardware are not kept in secured IDFs or locked cabinet, this is a finding.",
"description": "Since the IDF includes all hardware required to connect horizontal wiring to the backbone, it is imperative that all switches and associated cross-connect hardware are kept in a secured IDF or an enclosed cabinet that is kept locked. This will also prevent an attacker from gaining privilege mode access to the switch. Several switch products only require a reboot of the switch in order to reset or recover the password.",
"fixid": "F-7656r4_fix",
"fixtext": "Place switches and associated cross-connect hardware in a secured IDF. If the hardware is located in an open area, ensure the hardware is located in a secured and locked cabinet.",
"iacontrols": null,
"id": "V-8081",
"ruleID": "SV-8567r3_rule",
"severity": "medium",
"title": "The organization must ensure all switches and associated cross-connect hardware are kept in a secure Intermediate Distribution Frame (IDF) or an enclosed cabinet that is kept locked.",
"version": "NET-VLAN-001"
},
"V-8099": {
"checkid": "C-7480r3_chk",
"checktext": "Verify the DHCP audit and event logs include hostnames and MAC addresses of all clients. Also, validate logs are kept online for thirty days and offline for one year.\n\nIf the logs do not include hostnames and MAC addresses or if the logs are not kept online for thirty days and offline for one year, this is a finding.",
"description": "In order to identify and combat IP address spoofing, it is highly recommended that the DHCP server logs MAC addresses and hostnames on the DHCP server.",
"fixid": "F-7674r3_fix",
"fixtext": "Configure the DHCP audit and event logs to log hostname and MAC addresses.\n\nStore the logs for a minimum of thirty days online and then offline for one year.",
"iacontrols": null,
"id": "V-8099",
"ruleID": "SV-8585r3_rule",
"severity": "low",
"title": "Dynamic Host Configuration Protocol (DHCP) audit and event logs must record hostnames and MAC addresses to be stored online for thirty days and offline for one year.",
"version": "NET0198"
},
"V-8100": {
"checkid": "C-7481r3_chk",
"checktext": "Review the configuration of SIPRNet DHCP servers to verify that the lease duration is set to a minimum of thirty days.\n\nIf the lease duration is less than thirty days, this is a finding.",
"description": "In order to trace, audit, and investigate suspicious activity, DHCP servers within the SIPRNet infrastructure must have the minimum lease duration time configured to 30 or more days.",
"fixid": "F-7675r2_fix",
"fixtext": "Configure any DHCP server used on the SIPRNet with a minimum lease duration of thirty days.",
"iacontrols": null,
"id": "V-8100",
"ruleID": "SV-8586r3_rule",
"severity": "low",
"title": "Dynamic Host Configuration Protocol (DHCP) servers used within SIPRNet infrastructure must be configured with a minimum lease duration time of 30 days.",
"version": "NET0199"
},
"V-8272": {
"checkid": "C-3692r5_chk",
"checktext": "Review the network topology to ensure the enclave has the IDPS positioned to monitor all traffic to and from the enclave. Review any type of report that was recently produced from information provided by the sensor showing any recent alerts, an escalation activity and any type of log or configuration changes. This will show the sensor is being actively monitored and alerts are being acted upon. If the enclave\u2019s CNDSP requires continuous monitoring of the IDPS, the CNDSPs management team (e.g. sensor grid management team at DISA) will verify the operational status by providing information about the enclave\u2019s IDPS such as a network diagram, MOA, current alert information, or other information to validate its operational status.\n\nIf there is no IDPS positioned and enabled to monitor all ingress and egress traffic, this is a finding.\n\nException: If the perimeter security for the enclave or B/C/P/S is provisioned via the JRSS, then this requirement is not applicable.",
"description": "Per CJCSI 6510.01F, Enclosure A-5, Paragraph 8, \u201cDOD ISs (e.g., enclaves, applications, outsourced IT-based process, and platform IT interconnections) shall be monitored to detect and react to incidents, intrusions, disruption of services, or other unauthorized activities (including insider threat) that threaten the security of DOD operations or IT resources, including internal misuse.\u201d\n\nAn Intrusion Prevention System (IPS) allows the sensor to monitor, alert, and actively attempt to drop/block malicious traffic. An Intrusion Detection System (IDS) uses a passive method; receiving a copy of the packets to analyze and alert authorized persons about any malicious activity. While an IDS or an IPS in a passive role cannot stop the attack itself, it can typically notify and dynamically assign ACLs or other rules to a firewall or router for filtering. The preferred method of installation is to have the IDPS configured for inline mode. Only when there is a valid technical reason, should the IDPS be placed into a passive or IDS mode. For a full uninhibited view of the traffic, the IDPS must sit behind the enclave\u2019s firewall. This will allow the IDPS to monitor all traffic unencrypted, entering or leaving the enclave.",
"fixid": "F-7899r5_fix",
"fixtext": "Install an IDPS inline or passively, behind the enclave firewall to monitor all unencrypted traffic, inbound and outbound.",
"iacontrols": null,
"id": "V-8272",
"ruleID": "SV-8758r3_rule",
"severity": "medium",
"title": "An Intrusion Detection and Prevention System (IDPS) must be deployed to monitor all unencrypted traffic entering and leaving the enclave.",
"version": "NET-IDPS-021"
}
},
"profiles": {
"MAC-1_Classified": {
"description": "",
"findings": {
"V-11796": "true",
"V-12072": "true",
"V-12101": "true",
"V-12102": "true",
"V-12106": "true",
"V-14634": "true",
"V-14638": "true",
"V-14640": "true",
"V-14642": "true",
"V-14716": "true",
"V-14723": "true",
"V-14737": "true",
"V-14738": "true",
"V-14740": "true",
"V-14741": "true",
"V-14742": "true",
"V-14743": "true",
"V-14745": "true",
"V-17772": "true",
"V-17860": "true",
"V-18490": "true",
"V-18492": "true",
"V-18493": "true",
"V-18496": "true",
"V-18497": "true",
"V-18504": "true",
"V-18506": "true",
"V-18507": "true",
"V-18510": "true",
"V-18511": "true",
"V-18596": "true",
"V-19900": "true",
"V-23735": "true",
"V-25319": "true",
"V-30255": "true",
"V-31632": "true",
"V-31637": "true",
"V-33831": "true",
"V-66349": "true",
"V-66351": "true",
"V-66353": "true",
"V-66355": "true",
"V-66357": "true",
"V-66359": "true",
"V-66361": "true",
"V-66363": "true",
"V-66365": "true",
"V-66367": "true",
"V-66369": "true",
"V-66371": "true",
"V-66373": "true",
"V-66375": "true",
"V-66379": "true",
"V-66381": "true",
"V-66389": "true",
"V-66391": "true",
"V-66393": "true",
"V-66397": "true",
"V-8046": "true",
"V-8047": "true",
"V-8048": "true",
"V-8049": "true",
"V-8051": "true",
"V-8052": "true",
"V-8054": "true",
"V-8060": "true",
"V-8061": "true",
"V-8066": "true",
"V-8078": "true",
"V-8080": "true",
"V-8081": "true",
"V-8099": "true",
"V-8100": "true",
"V-8272": "true"
},
"id": "MAC-1_Classified",
"title": "I - Mission Critical Classified"
},
"MAC-1_Public": {
"description": "",
"findings": {
"V-11796": "true",
"V-12072": "true",
"V-12101": "true",
"V-12102": "true",
"V-12106": "true",
"V-14634": "true",
"V-14638": "true",
"V-14640": "true",
"V-14642": "true",
"V-14716": "true",
"V-14723": "true",
"V-14737": "true",
"V-14738": "true",
"V-14740": "true",
"V-14743": "true",
"V-17772": "true",
"V-17860": "true",
"V-18490": "true",
"V-18492": "true",
"V-18493": "true",
"V-18496": "true",
"V-18497": "true",
"V-18504": "true",
"V-18506": "true",
"V-18507": "true",
"V-18510": "true",
"V-18511": "true",
"V-18596": "true",
"V-19900": "true",
"V-23735": "true",
"V-25319": "true",
"V-30255": "true",
"V-31632": "true",
"V-31637": "true",
"V-33831": "true",
"V-66349": "true",
"V-66351": "true",
"V-66353": "true",
"V-66355": "true",
"V-66357": "true",
"V-66359": "true",
"V-66361": "true",
"V-66363": "true",
"V-66365": "true",
"V-66367": "true",
"V-66369": "true",
"V-66371": "true",
"V-66373": "true",
"V-66375": "true",
"V-66379": "true",
"V-66381": "true",
"V-66389": "true",
"V-66391": "true",
"V-66393": "true",
"V-66397": "true",
"V-8046": "true",
"V-8047": "true",
"V-8048": "true",
"V-8049": "true",
"V-8051": "true",
"V-8052": "true",
"V-8054": "true",
"V-8060": "true",
"V-8061": "true",
"V-8066": "true",
"V-8078": "true",
"V-8080": "true",
"V-8081": "true",
"V-8099": "true",
"V-8100": "true",
"V-8272": "true"
},
"id": "MAC-1_Public",
"title": "I - Mission Critical Public"
},
"MAC-1_Sensitive": {
"description": "",
"findings": {
"V-11796": "true",
"V-12072": "true",
"V-12101": "true",
"V-12102": "true",
"V-12106": "true",
"V-14634": "true",
"V-14638": "true",
"V-14640": "true",
"V-14642": "true",
"V-14716": "true",
"V-14723": "true",
"V-14737": "true",
"V-14738": "true",
"V-14740": "true",
"V-14743": "true",
"V-17772": "true",
"V-17860": "true",
"V-18490": "true",
"V-18492": "true",
"V-18493": "true",
"V-18496": "true",
"V-18497": "true",
"V-18504": "true",
"V-18506": "true",
"V-18507": "true",
"V-18510": "true",
"V-18511": "true",
"V-18596": "true",
"V-19900": "true",
"V-23735": "true",
"V-25319": "true",
"V-30255": "true",
"V-31632": "true",
"V-31637": "true",
"V-33831": "true",
"V-66349": "true",
"V-66351": "true",
"V-66353": "true",
"V-66355": "true",
"V-66357": "true",
"V-66359": "true",
"V-66361": "true",
"V-66363": "true",
"V-66365": "true",
"V-66367": "true",
"V-66369": "true",
"V-66371": "true",
"V-66373": "true",
"V-66375": "true",
"V-66379": "true",
"V-66381": "true",
"V-66389": "true",
"V-66391": "true",
"V-66393": "true",
"V-66397": "true",
"V-8046": "true",
"V-8047": "true",
"V-8048": "true",
"V-8049": "true",
"V-8051": "true",
"V-8052": "true",
"V-8054": "true",
"V-8060": "true",
"V-8061": "true",
"V-8066": "true",
"V-8078": "true",
"V-8080": "true",
"V-8081": "true",
"V-8099": "true",
"V-8100": "true",
"V-8272": "true"
},
"id": "MAC-1_Sensitive",
"title": "I - Mission Critical Sensitive"
},
"MAC-2_Classified": {
"description": "",
"findings": {
"V-11796": "true",
"V-12072": "true",
"V-12101": "true",
"V-12102": "true",
"V-12106": "true",
"V-14634": "true",
"V-14638": "true",
"V-14640": "true",
"V-14642": "true",
"V-14716": "true",
"V-14723": "true",
"V-14737": "true",
"V-14738": "true",
"V-14740": "true",
"V-14741": "true",
"V-14742": "true",
"V-14743": "true",
"V-14745": "true",
"V-17772": "true",
"V-17860": "true",
"V-18490": "true",
"V-18492": "true",
"V-18493": "true",
"V-18496": "true",
"V-18497": "true",
"V-18504": "true",
"V-18506": "true",
"V-18507": "true",
"V-18510": "true",
"V-18511": "true",
"V-18596": "true",
"V-19900": "true",
"V-23735": "true",
"V-25319": "true",
"V-30255": "true",
"V-31632": "true",
"V-31637": "true",
"V-33831": "true",
"V-66349": "true",
"V-66351": "true",
"V-66353": "true",
"V-66355": "true",
"V-66357": "true",
"V-66359": "true",
"V-66361": "true",
"V-66363": "true",
"V-66365": "true",
"V-66367": "true",
"V-66369": "true",
"V-66371": "true",
"V-66373": "true",
"V-66375": "true",
"V-66379": "true",
"V-66381": "true",
"V-66389": "true",
"V-66391": "true",
"V-66393": "true",
"V-66397": "true",
"V-8046": "true",
"V-8047": "true",
"V-8048": "true",
"V-8049": "true",
"V-8051": "true",
"V-8052": "true",
"V-8054": "true",
"V-8060": "true",
"V-8061": "true",
"V-8066": "true",
"V-8078": "true",
"V-8080": "true",
"V-8081": "true",
"V-8099": "true",
"V-8100": "true",
"V-8272": "true"
},
"id": "MAC-2_Classified",
"title": "II - Mission Support Classified"
},
"MAC-2_Public": {
"description": "",
"findings": {
"V-11796": "true",
"V-12072": "true",
"V-12101": "true",
"V-12102": "true",
"V-12106": "true",
"V-14634": "true",
"V-14638": "true",
"V-14640": "true",
"V-14642": "true",
"V-14716": "true",
"V-14723": "true",
"V-14737": "true",
"V-14738": "true",
"V-14740": "true",
"V-14743": "true",
"V-17772": "true",
"V-17860": "true",
"V-18490": "true",
"V-18492": "true",
"V-18493": "true",
"V-18496": "true",
"V-18497": "true",
"V-18504": "true",
"V-18506": "true",
"V-18507": "true",
"V-18510": "true",
"V-18511": "true",
"V-18596": "true",
"V-19900": "true",
"V-23735": "true",
"V-25319": "true",
"V-30255": "true",
"V-31632": "true",
"V-31637": "true",
"V-33831": "true",
"V-66349": "true",
"V-66351": "true",
"V-66353": "true",
"V-66355": "true",
"V-66357": "true",
"V-66359": "true",
"V-66361": "true",
"V-66363": "true",
"V-66365": "true",
"V-66367": "true",
"V-66369": "true",
"V-66371": "true",
"V-66373": "true",
"V-66375": "true",
"V-66379": "true",
"V-66381": "true",
"V-66389": "true",
"V-66391": "true",
"V-66393": "true",
"V-66397": "true",
"V-8046": "true",
"V-8047": "true",
"V-8048": "true",
"V-8049": "true",
"V-8051": "true",
"V-8052": "true",
"V-8054": "true",
"V-8060": "true",
"V-8061": "true",
"V-8066": "true",
"V-8078": "true",
"V-8080": "true",
"V-8081": "true",
"V-8099": "true",
"V-8100": "true",
"V-8272": "true"
},
"id": "MAC-2_Public",
"title": "II - Mission Support Public"
},
"MAC-2_Sensitive": {
"description": "",
"findings": {
"V-11796": "true",
"V-12072": "true",
"V-12101": "true",
"V-12102": "true",
"V-12106": "true",
"V-14634": "true",
"V-14638": "true",
"V-14640": "true",
"V-14642": "true",
"V-14716": "true",
"V-14723": "true",
"V-14737": "true",
"V-14738": "true",
"V-14740": "true",
"V-14743": "true",
"V-17772": "true",
"V-17860": "true",
"V-18490": "true",
"V-18492": "true",
"V-18493": "true",
"V-18496": "true",
"V-18497": "true",
"V-18504": "true",
"V-18506": "true",
"V-18507": "true",
"V-18510": "true",
"V-18511": "true",
"V-18596": "true",
"V-19900": "true",
"V-23735": "true",
"V-25319": "true",
"V-30255": "true",
"V-31632": "true",
"V-31637": "true",
"V-33831": "true",
"V-66349": "true",
"V-66351": "true",
"V-66353": "true",
"V-66355": "true",
"V-66357": "true",
"V-66359": "true",
"V-66361": "true",
"V-66363": "true",
"V-66365": "true",
"V-66367": "true",
"V-66369": "true",
"V-66371": "true",
"V-66373": "true",
"V-66375": "true",
"V-66379": "true",
"V-66381": "true",
"V-66389": "true",
"V-66391": "true",
"V-66393": "true",
"V-66397": "true",
"V-8046": "true",
"V-8047": "true",
"V-8048": "true",
"V-8049": "true",
"V-8051": "true",
"V-8052": "true",
"V-8054": "true",
"V-8060": "true",
"V-8061": "true",
"V-8066": "true",
"V-8078": "true",
"V-8080": "true",
"V-8081": "true",
"V-8099": "true",
"V-8100": "true",
"V-8272": "true"
},
"id": "MAC-2_Sensitive",
"title": "II - Mission Support Sensitive"
},
"MAC-3_Classified": {
"description": "",
"findings": {
"V-11796": "true",
"V-12072": "true",
"V-12101": "true",
"V-12102": "true",
"V-12106": "true",
"V-14634": "true",
"V-14638": "true",
"V-14640": "true",
"V-14642": "true",
"V-14716": "true",
"V-14723": "true",
"V-14737": "true",
"V-14738": "true",
"V-14740": "true",
"V-14741": "true",
"V-14742": "true",
"V-14743": "true",
"V-14745": "true",
"V-17772": "true",
"V-17860": "true",
"V-18490": "true",
"V-18492": "true",
"V-18493": "true",
"V-18496": "true",
"V-18497": "true",
"V-18504": "true",
"V-18506": "true",
"V-18507": "true",
"V-18510": "true",
"V-18511": "true",
"V-18596": "true",
"V-19900": "true",
"V-23735": "true",
"V-25319": "true",
"V-30255": "true",
"V-31632": "true",
"V-31637": "true",
"V-33831": "true",
"V-66349": "true",
"V-66351": "true",
"V-66353": "true",
"V-66355": "true",
"V-66357": "true",
"V-66359": "true",
"V-66361": "true",
"V-66363": "true",
"V-66365": "true",
"V-66367": "true",
"V-66369": "true",
"V-66371": "true",
"V-66373": "true",
"V-66375": "true",
"V-66379": "true",
"V-66381": "true",
"V-66389": "true",
"V-66391": "true",
"V-66393": "true",
"V-66397": "true",
"V-8046": "true",
"V-8047": "true",
"V-8048": "true",
"V-8049": "true",
"V-8051": "true",
"V-8052": "true",
"V-8054": "true",
"V-8060": "true",
"V-8061": "true",
"V-8066": "true",
"V-8078": "true",
"V-8080": "true",
"V-8081": "true",
"V-8099": "true",
"V-8100": "true",
"V-8272": "true"
},
"id": "MAC-3_Classified",
"title": "III - Administrative Classified"
},
"MAC-3_Public": {
"description": "",
"findings": {
"V-11796": "true",
"V-12072": "true",
"V-12101": "true",
"V-12102": "true",
"V-12106": "true",
"V-14634": "true",
"V-14638": "true",
"V-14640": "true",
"V-14642": "true",
"V-14716": "true",
"V-14723": "true",
"V-14737": "true",
"V-14738": "true",
"V-14740": "true",
"V-14743": "true",
"V-17772": "true",
"V-17860": "true",
"V-18490": "true",
"V-18492": "true",
"V-18493": "true",
"V-18496": "true",
"V-18497": "true",
"V-18504": "true",
"V-18506": "true",
"V-18507": "true",
"V-18510": "true",
"V-18511": "true",
"V-18596": "true",
"V-19900": "true",
"V-23735": "true",
"V-25319": "true",
"V-30255": "true",
"V-31632": "true",
"V-31637": "true",
"V-33831": "true",
"V-66349": "true",
"V-66351": "true",
"V-66353": "true",
"V-66355": "true",
"V-66357": "true",
"V-66359": "true",
"V-66361": "true",
"V-66363": "true",
"V-66365": "true",
"V-66367": "true",
"V-66369": "true",
"V-66371": "true",
"V-66373": "true",
"V-66375": "true",
"V-66379": "true",
"V-66381": "true",
"V-66389": "true",
"V-66391": "true",
"V-66393": "true",
"V-66397": "true",
"V-8046": "true",
"V-8047": "true",
"V-8048": "true",
"V-8049": "true",
"V-8051": "true",
"V-8052": "true",
"V-8054": "true",
"V-8060": "true",
"V-8061": "true",
"V-8066": "true",
"V-8078": "true",
"V-8080": "true",
"V-8081": "true",
"V-8099": "true",
"V-8100": "true",
"V-8272": "true"
},
"id": "MAC-3_Public",
"title": "III - Administrative Public"
},
"MAC-3_Sensitive": {
"description": "",
"findings": {
"V-11796": "true",
"V-12072": "true",
"V-12101": "true",
"V-12102": "true",
"V-12106": "true",
"V-14634": "true",
"V-14638": "true",
"V-14640": "true",
"V-14642": "true",
"V-14716": "true",
"V-14723": "true",
"V-14737": "true",
"V-14738": "true",
"V-14740": "true",
"V-14743": "true",
"V-17772": "true",
"V-17860": "true",
"V-18490": "true",
"V-18492": "true",
"V-18493": "true",
"V-18496": "true",
"V-18497": "true",
"V-18504": "true",
"V-18506": "true",
"V-18507": "true",
"V-18510": "true",
"V-18511": "true",
"V-18596": "true",
"V-19900": "true",
"V-23735": "true",
"V-25319": "true",
"V-30255": "true",
"V-31632": "true",
"V-31637": "true",
"V-33831": "true",
"V-66349": "true",
"V-66351": "true",
"V-66353": "true",
"V-66355": "true",
"V-66357": "true",
"V-66359": "true",
"V-66361": "true",
"V-66363": "true",
"V-66365": "true",
"V-66367": "true",
"V-66369": "true",
"V-66371": "true",
"V-66373": "true",
"V-66375": "true",
"V-66379": "true",
"V-66381": "true",
"V-66389": "true",
"V-66391": "true",
"V-66393": "true",
"V-66397": "true",
"V-8046": "true",
"V-8047": "true",
"V-8048": "true",
"V-8049": "true",
"V-8051": "true",
"V-8052": "true",
"V-8054": "true",
"V-8060": "true",
"V-8061": "true",
"V-8066": "true",
"V-8078": "true",
"V-8080": "true",
"V-8081": "true",
"V-8099": "true",
"V-8100": "true",
"V-8272": "true"
},
"id": "MAC-3_Sensitive",
"title": "III - Administrative Sensitive"
}
},
"slug": "network_infrastructure_policy",
"title": "Network Infrastructure Policy Security Technical Implementation Guide",
"version": "9"
}
}