kriterion 0.0.1

data/standards/stig_infoblox_7.x_dns.json

@@ -0,0 +1,419 @@
+{
+  "name": "stig_infoblox_7.x_dns",
+  "date": "2018-01-03",
+  "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.",
+  "title": "Infoblox 7.x DNS Security Technical Implementation Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-68515",
+      "title": "Infoblox systems which perform zone transfers to non-Infoblox Grid DNS servers must be configured to limit the number of concurrent sessions for zone transfers.",
+      "description": "Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation.\n\nInfoblox DNS servers configured in a Grid do not utilize zone transfers; data is replicated using an encrypted management connection. However when a zone contains both Infoblox Grid DNS servers and non-Grid DNS servers a protocol compliant zone transfer is performed.\n\nName servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.\n\nPrimary name servers also make outbound connection to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to only be made to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the master zone server and result in DoS to legitimate users. Primary name servers should be configured to limit the hosts from which they will accept dynamic updates.\n\nAdditionally, the number of concurrent clients, especially TCP clients, needs to be kept to a level that does not risk placing the system in a DoS state.",
+      "severity": "low"
+    },
+    {
+      "id": "V-68517",
+      "title": "Primary authoritative name servers must be configured to only receive zone transfer requests from specified secondary name servers.",
+      "description": "Authoritative name servers (especially primary name servers) should be configured with an allow-transfer access control substatement designating the list of hosts from which zone transfer requests can be accepted. These restrictions address the denial-of-service threat and potential exploits from unrestricted dissemination of information about internal resources. Based on the need-to-know, the only name servers that need to refresh their zone files periodically are the secondary name servers. Zone transfer from primary name servers should be restricted to secondary name servers. The zone transfer should be completely disabled in the secondary name servers. The address match list argument for the allow-transfer substatement should consist of IP addresses of secondary name servers and stealth secondary name servers.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68519",
+      "title": "The Infoblox system must limit the number of concurrent client connections to the number of allowed dynamic update clients.",
+      "description": "Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation.\n\nName servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.\n\nPrimary name servers also make outbound connections to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to only be made to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the master zone server and result in DoS to legitimate users. Primary name servers should be configured to limit the hosts from which they will accept dynamic updates.\n\nAdditionally the number of concurrent clients, especially TCP clients, needs to be kept to a level that does not risk placing the system in a DoS state.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68521",
+      "title": "The Infoblox system audit records must be backed up at least every seven days onto a different system or system component than the system or component being audited.",
+      "description": "Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on a defined frequency helps to assure, in the event of a catastrophic system failure, the audit records will be retained. \n\nThis helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records.\n\nThis requirement only applies to applications that have a native backup capability for audit records. Operating system backup requirements cover applications that do not provide native backup functions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68523",
+      "title": "Infoblox systems configured to run the DNS service must be configured to prohibit or restrict unapproved ports and protocols.",
+      "description": "In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems.\n\nApplications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services); however, doing so increases risk over limiting the services provided by any one component.\n\nTo support the requirements and principles of least functionality, the application must support the organizational requirements by providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68525",
+      "title": "Only the private key corresponding to the ZSK alone must be kept on the name server that does support dynamic updates.",
+      "description": "Infoblox systems when deployed in a Grid configuration store DNSSEC keys on the designated Grid Master system. As the central point of administration, the Grid Master should be configured for administration of the DNS, DHCP, and IP Address Management (IPAM) system. No clients should be configured to utilize the Grid Master or backup Candidate systems for protocol transactions.\n\nAn alternative solution is through deployment of a Hardware Security Module (HSM), which provides hardware encrypted storage of key data.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68527",
+      "title": "Signature generation using the KSK must be done off-line, using the KSK-private stored off-line.",
+      "description": "Infoblox systems when deployed in a Grid configuration store DNSSEC keys on the designated Grid Master system. As the central point of administration, the Grid Master should be configured for administration of the DNS, DHCP, and IP Address Management (IPAM) system. No clients should be configured to utilize the Grid Master or backup Candidate systems for protocol transactions.\n\nAn alternative solution is through deployment of a Hardware Security Module (HSM), which provides hardware encrypted storage of key data.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68529",
+      "title": "The Infoblox system must be configured to employ strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions.",
+      "description": "If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data. \n\nNonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric.\n\nLack of authentication enables anyone to gain access to the network or possibly a network element that provides opportunity for intruders to compromise resources within the network infrastructure. Network access control mechanisms interoperate to prevent unauthorized access and to enforce the organization's security policy. Authorization for access to any network element requires an individual account identifier that has been approved, assigned, and configured on an authentication server. Authentication of all administrator accounts for all privilege levels must be accomplished using two or more factors that include the following:\n\n(i) something you know (e.g., password/PIN); \n(ii) something you have (e.g., cryptographic identification device, token); or \n(iii) something you are (e.g., biometric).\n\nInfoblox systems support authentication using multiple authenticators including; LDAP, RADIUS, Microsoft Active Directory, OCSP, and local user database. Strong authentication can be enabled by implementation of two or more authentication forms.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68531",
+      "title": "The Infoblox system must be configured to provide additional data origin artifacts along with the authoritative data the system returns in response to external name/address resolution queries.",
+      "description": "The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. The security objective is to verify the integrity of each response received. An integral part of integrity verification is to ensure that valid data has originated from the right source. Establishing trust in the source is called data origin authentication. \n\nThe security objectives—and consequently the security services—that are required for securing the DNS query/response transaction are data origin authentication and data integrity verification.\n\nThe specification for a digital signature mechanism in the context of the DNS infrastructure is in IETF’s DNSSEC standard. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted zone (such as the root zone) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone is called the trust anchor.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68533",
+      "title": "A DNS server implementation must provide the means to indicate the security status of child zones.",
+      "description": "If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its subdomain, from the top of the DNS hierarchy down.\n\nA DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data. \n\nIn DNS, trust in the public key of the source is established by starting from a trusted name server and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. \n\nA trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and Domain Name System Security Extensions (DNSSEC). \n\nWhen there is a chain of trust, usually the top entity to be trusted becomes the trust anchor. A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate. In DNS, a trust anchor is a DNSKEY that is placed into a validating resolver so the validator can cryptographically validate the results for a given request back to a known public key (the trust anchor). \n\nAn example means to indicate the security status of child subspaces is through the use of delegation signer (DS) resource records in the DNS.\n\nPath validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Without path validation and a chain of trust, there can be no trust that the data integrity authenticity has been maintained during a transaction.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68535",
+      "title": "The Key Signing Key (KSK) rollover interval must be configured to no less than one year.",
+      "description": "The DNS root key is a cryptographic public-private key pair used for DNSSEC signing of the DNS root zone records. The root zone KSK serves as the anchor for the “chain of trust” that enables DNS resolvers to validate the authenticity of any signed data in the DNS. The integrity of the DNS depends on a secure root key. \nRolling the KSK means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers, including: Internet Service Providers; enterprise network administrators and other Domain Name System (DNS) resolver operators; DNS resolver software developers; system integrators; and hardware and software distributors who install or ship the root's \"trust anchor.\" The KSK is used to cryptographically sign the Zone Signing Key (ZSK), which is used by the Root Zone Maintainer to DNSSEC-sign the root zone of the Internet's DNS.\nMaintaining an up-to-date KSK is essential to ensuring DNSSEC-validating DNS resolvers continue to function following the rollover. Failure to have the current root zone KSK will mean that DNSSEC-validating DNS resolvers will be unable to resolve any DNS queries.\nAn attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. \n\nTo prevent the impact of a compromised KSK, a delegating parent should also set the signature validity period for RRSIGs covering DS RRs in the range of a few days to one week. This re-signing does not require frequent rollover of the parent's ZSK, but scheduled ZSK rollover should still be performed at regular intervals.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68537",
+      "title": "The Infoblox system implementation must enforce approved authorizations for controlling the flow of information between DNS servers and between DNS servers and DNS clients based on DNSSEC policies.",
+      "description": "A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all application information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data.\n\nApplication-specific examples of enforcement occurs in systems that employ rule sets or establish configuration settings that restrict information system services or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics).\n\nApplications providing information flow control must be able to enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy.\n\nWithin the context of DNS, this is applicable in terms of controlling the flow of DNS information between systems, such as DNS zone transfers.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68539",
+      "title": "A DNS server implementation must provide the means to enable verification of a chain of trust among parent and child domains (if the child supports secure resolution services).",
+      "description": "If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its subdomain, from the top of the DNS hierarchy down.\n\nA DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS to map between host/service names and network addresses must provide other means to assure the authenticity and integrity of response data.\n\nDNSSEC provides the means to verify integrity assurances for the host/service name to network address resolution information obtained through the service. By using the delegation signer (DS) resource records in the DNS, the security status of a child domain can be validated. The DS resource record is used to identify the DNSSEC signing key of a delegated zone.\n\nStarting from a trusted name server (such as the root name server) and down to the current source of response through successive verifications of signature of the public key of a child by its parent, the chain of trust is established. The public key of the trusted name servers is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. This requires that responses consist of not only the requested RRs but also an authenticator associated with them. In DNSSEC, this authenticator is the digital signature of a Resource Record (RR) Set. The digital signature of an RRSet is encapsulated through a special RRType called RRSIG. The DNS client using the trusted public key of the source (whose trust has just been established) then verifies the digital signature to detect if the response is valid or bogus.\n\nThis control enables the DNS to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Without indication of the security status of a child domain and enabling verification of a chain of trust, integrity and availability of the DNS infrastructure cannot be assured.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68543",
+      "title": "All authoritative name servers for a zone must be geographically disbursed.",
+      "description": "In addition to network-based dispersion, authoritative name servers should be dispersed geographically as well. In other words, in addition to being located on different network segments, the authoritative name servers should not all be located within the same building. One approach that some organizations follow is to locate some authoritative name servers in their own premises and others in their ISPs' data centers or in partnering organizations.\n\nA network administrator may choose to use a \"hidden\" master authoritative server and only have secondary servers visible on the network. A hidden master authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. If the master authoritative name server is \"hidden\", a secondary authoritative name server may reside in the same building as the hidden master.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68545",
+      "title": "Infoblox DNS servers must protect the authenticity of communications sessions for zone transfers.",
+      "description": "DNS is a fundamental network service that is prone to various attacks, such as cache poisoning and man-in-the middle attacks. \n\nIf communication sessions are not provided appropriate validity protections, such as the employment of DNSSEC, the authenticity of the data cannot be guaranteed.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68547",
+      "title": "Infoblox DNS servers must be configured to protect the authenticity of communications sessions for dynamic updates.",
+      "description": "DNS is a fundamental network service that is prone to various attacks, such as cache poisoning and man-in-the middle attacks. If communication sessions are not provided appropriate validity protections, such as the employment of DNSSEC, the authenticity of the data cannot be guaranteed.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68549",
+      "title": "In the event of a system failure, The Infoblox system must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes.",
+      "description": "Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving application state information helps to facilitate application restart and return to the operational mode of the organization with less disruption to mission-essential processes.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68551",
+      "title": "The Infoblox system must be configured to restrict the ability of individuals to use the DNS server to launch Denial of Service (DoS) attacks against other information systems.",
+      "description": "A DoS is a condition where a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. Individuals of concern can include hostile insiders or external adversaries that have successfully breached the information system and are using the system as a platform to launch cyber attacks on third parties.\n\nApplications and application developers must take the steps needed to ensure users cannot use an authorized application to launch DoS attacks against other systems and networks. For example, applications may include mechanisms that throttle network traffic so users are not able to generate unlimited network traffic via the application. Limiting system resources that are allocated to any user to a bare minimum may also reduce the ability of users to launch some DoS attacks.\n\nWhen it comes to DoS attacks, most of the attention is paid to ensuring that systems and applications are not victims of these attacks. A DoS attack against the DNS infrastructure has the potential to cause a denial of service to all network users. As the DNS is a distributed backbone service of the Internet, numerous forms of attacks result in DoS, and they are still prevalent on the Internet today. Some potential DoS attacks against the DNS include malformed packet flood, spoofed source addresses, and distributed DoS, and the DNS can be exploited to launch amplification attacks upon other systems.\n\nWhile it is true that those accountable for systems want to ensure they are not affected by a DoS attack, they also need to ensure their systems and applications are not used to launch such an attack against others. To that end, a variety of technologies exist to limit the effects of DoS attacks, such as careful configuration of resolver and recursion functionality.\n\nDNS administrators must take the steps needed to ensure other systems and tools cannot use exploits to launch DoS attacks against other systems and networks. An example would be designing the DNS architecture to include mechanisms that throttle DNS traffic and resources so that users/other DNS servers are not able to generate unlimited DNS traffic via the application.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68553",
+      "title": "The Infoblox system must be configured to manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks.",
+      "description": "A DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. \n\nIn the case of application DoS attacks, care must be taken when designing the application to ensure the application makes the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time. \n\nA denial of service (DoS) attack against the DNS infrastructure has the potential to cause a DoS to all network users. As the DNS is a distributed backbone service of the Internet, various forms of amplification attacks resulting in DoS, while utilizing the DNS, are still prevalent on the Internet today. Some potential DoS flooding attacks against the DNS include malformed packet flood, spoofed source addresses, and distributed DoS. Without the DNS, users and systems would not have the ability to perform simple name to IP resolution. \n\nConfiguring the DNS implementation to defend against cache poisoning, employing increased capacity and bandwidth, building redundancy into the DNS architecture, utilizing DNSSEC, limiting and securing recursive services, DNS black holes, etc., may reduce the susceptibility to some flooding types of DoS attacks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68555",
+      "title": "The Infoblox system must be configured to activate a notification to the system administrator when a component failure is detected.",
+      "description": "Predictable failure prevention requires organizational planning to address system failure issues. If components key to maintaining systems security fail to function, the system could continue operating in an insecure state. The organization must be prepared and the application must support requirements that specify if the application must alarm for such conditions and/or automatically shut down the application or the system. \n\nThis can include conducting a graceful application shutdown to avoid losing information. Automatic or manual transfer of components from standby to active mode can occur, for example, upon detection of component failures.\n\nIf a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fail, the DNS server should shut itself down to prevent continued execution without the necessary security components in place. Transactions such as zone transfers would not be able to work correctly anyway in this state.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68557",
+      "title": "An Infoblox DNS server must strongly bind the identity of the DNS server with the DNS information using DNSSEC.",
+      "description": "Weakly bound credentials can be modified without invalidating the credential; therefore, non-repudiation can be violated.\n\nThis requirement supports audit requirements that provide organizational personnel with the means to identify who produced specific information in the event of an information transfer. Organizations and/or data owners determine and approve the strength of the binding between the information producer and the information based on the security category of the information and relevant risk factors.\n\nDNSSEC uses digital signatures to verify the identity of the producer of particular pieces of information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68559",
+      "title": "The Infoblox system must be configured to provide the means for authorized individuals to determine the identity of the source of the DNS server-provided information.",
+      "description": "Without a means for identifying the individual that produced the information, the information cannot be relied upon. Identifying the validity of information may be delayed or deterred.\n\nThis requirement provides organizational personnel with the means to identify who produced specific information in the event of an information transfer. DNSSEC and TSIG/SIG(0) both use digital signatures to establish the identity of the producer of particular pieces of information. These signatures can be examined and verified to determine the identity of the producer of the information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68561",
+      "title": "The Infoblox system must be configured to validate the binding of the other DNS servers identity to the DNS information for a server-to-server transaction (e.g., zone transfer).",
+      "description": "Validation of the binding of the information prevents the modification of information between production and review. The validation of bindings can be achieved, for example, by the use of cryptographic checksums. Validations must be performed automatically.\n\nDNSSEC and TSIG/SIG(0) technologies are not effective unless the digital signatures they generate are validated to ensure that the information has not been tampered with and that the producer's identity is legitimate.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68563",
+      "title": "The Infoblox system must be configured to allow DNS administrators to change the auditing to be performed on all DNS server components, based on all selectable event criteria.",
+      "description": "If authorized individuals do not have the ability to modify auditing parameters in response to a changing threat environment, the organization may not be able to effectively respond, and important forensic information may be lost.\n\nThis requirement enables organizations to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve information system resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, within minutes, or within hours.\n\nFor a DNS server, the actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68565",
+      "title": "Recursion must be disabled on Infoblox DNS servers which are configured as authoritative name servers.",
+      "description": "A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to non-existent hosts (which constitutes a denial of service), or, worse, hosts that masquerade as legitimate ones to obtain sensitive data or passwords. \n\nTo guard against poisoning, name servers authoritative for .mil domains should be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine: one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation.\n\nDNSSEC ensures that the answer received when querying for name resolution actually comes from a trusted name server. Since DNSSEC is still far from being globally deployed external to DoD, and many resolvers either have not been updated or do not support DNSSEC, maintaining cached zone data separate from authoritative zone data mitigates the gap until all DNS data is validated with DNSSEC. \n\nSince DNS forwarding of queries can be accomplished in some DNS applications without caching locally, DNS forwarding is the method to be used when providing external DNS resolution to internal clients.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68567",
+      "title": "The Infoblox system must authenticate the other DNS server before responding to a server-to-server transaction.",
+      "description": "Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices can access the system. \n\nThis requirement applies to server-to-server (zone transfer) transactions only and is provided by TSIG/SIG(0), which enforces mutual server authentication using a key that is unique to each server pair (TSIG) or using PKI-based authentication (SIG(0)).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68569",
+      "title": "The DNS server implementation must authenticate another DNS server before establishing a remote and/or network connection using bidirectional authentication that is cryptographically based.",
+      "description": "Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk.\n\nThis requirement applies to server-to-server (zone transfer) transactions only and is provided by TSIG/SIG(0), which enforces mutual server authentication using a key that is unique to each server pair (TSIG) or using PKI-based authentication (SIG(0)).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68571",
+      "title": "A DNS server implementation must provide data origin artifacts for internal name/address resolution queries.",
+      "description": "The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. This requirement enables remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. \n\nA DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS to map between host/service names and network addresses must provide other means to assure the authenticity and integrity of response data. \n\nIn the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68573",
+      "title": "A DNS server implementation must provide data integrity protection artifacts for internal name/address resolution queries.",
+      "description": "The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. This requirement enables remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. \n\nA DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS to map between host/service names and network addresses must provide other means to assure the authenticity and integrity of response data. \n\nIn the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68575",
+      "title": "A DNS server implementation must provide additional integrity artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries.",
+      "description": "The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. This requirement enables remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. \n\nA DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS to map between host/service names and network addresses must provide other means to assure the authenticity and integrity of response data. \n\nIn the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68577",
+      "title": "A DNS server implementation must request data origin authentication verification on the name/address resolution responses the system receives from authoritative sources.",
+      "description": "If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data origin authentication must be performed to thwart these types of attacks.\n\nEach client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68579",
+      "title": "A DNS server implementation must request data integrity verification on the name/address resolution responses the system receives from authoritative sources.",
+      "description": "If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks.\n\nEach client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68581",
+      "title": "A DNS server implementation must perform data integrity verification on the name/address resolution responses the system receives from authoritative sources.",
+      "description": "If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks.\n\nEach client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68583",
+      "title": "A DNS server implementation must perform data origin verification authentication on the name/address resolution responses the system receives from authoritative sources.",
+      "description": "If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed which would result in query failure or denial of service. Data origin authentication verification must be performed to thwart these types of attacks.\n\nEach client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68585",
+      "title": "The Infoblox system must be configured to must protect the integrity of transmitted information.",
+      "description": "Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. \n\nCommunication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.\n\nConfidentiality is not an objective of DNS, but integrity is. DNSSEC and TSIG/SIG(0) both digitally sign DNS information to authenticate its source and ensure its integrity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68587",
+      "title": "The Infoblox system must implement cryptographic mechanisms to detect changes to information during transmission unless otherwise protected by alternative physical safeguards, such as, at a minimum, a Protected Distribution System (PDS).",
+      "description": "Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. \n\nConfidentiality is not an objective of DNS, but integrity is. DNSSEC and TSIG/SIG(0) both digitally sign DNS information to authenticate its source and ensure its integrity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68589",
+      "title": "The DNS server implementation must maintain the integrity of information during preparation for transmission.",
+      "description": "Information can be either unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.\n\nConfidentiality is not an objective of DNS, but integrity is. DNS is responsible for maintaining the integrity of DNS information while it is being prepared for transmission.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68591",
+      "title": "The DNS server implementation must maintain the integrity of information during reception.",
+      "description": "Information can be either unintentionally or maliciously disclosed or modified during reception, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.\n\nConfidentiality is not an objective of DNS, but integrity is. DNS is responsible for maintaining the integrity of DNS information while it is being received.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68593",
+      "title": "The DNS server implementation must follow procedures to re-role a secondary name server as the master name server should the master name server permanently lose functionality.",
+      "description": "Failing to an unsecure condition negatively impacts application security and can lead to system compromise. Failure conditions include, for example, loss of communications among critical system components or between system components and operational facilities. Fail-safe procedures include, for example, alerting operator personnel and providing specific instructions on subsequent steps to take (e.g., do nothing, reestablish system settings, shut down processes, restart the system, or contact designated organizational personnel).\n\nIf a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fail, the DNS server should shut itself down to prevent continued execution without the necessary security components in place. Transactions such as zone transfers would not be able to work correctly anyway in this state.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68595",
+      "title": "The DNS server implementation must log the event and notify the system administrator when anomalies in the operation of the signed zone transfers are discovered.",
+      "description": "Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights. \n\nIf anomalies are not acted upon, security functions may fail to secure the system. \n\nThe DNS server does not have the capability of shutting down or restarting the information system. The DNS server can be configured to generate audit records when anomalies are discovered, and the OS/NDM can then trigger notification messages to the system administrator based on the presence of those audit records.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68597",
+      "title": "The DNS server must implement NIST FIPS-validated cryptography for provisioning digital signatures, generating cryptographic hashes, and protecting unclassified information requiring confidentiality.",
+      "description": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.",
+      "severity": "high"
+    },
+    {
+      "id": "V-68599",
+      "title": "The Zone Signing Key (ZSK) rollover interval must be configured to no less than two months.",
+      "description": "An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing.\n\nTo minimize the impact of a compromised ZSK, a zone administrator should set a rollover interval of no less than two months for the ZSK.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68601",
+      "title": "NSEC3 must be used for all internal DNS zones.",
+      "description": "To ensure that RRs associated with a query are really missing in a zone file and have not been removed in transit, the DNSSEC mechanism provides a means for authenticating the nonexistence of an RR. It generates a special RR called an NSEC (or NSEC3) RR that lists the RRTypes associated with an owner name as well as the next name in the zone file. It sends this special RR, along with its signatures, to the resolving name server. By verifying the signature, a DNSSEC-aware resolving name server can determine which authoritative owner name exists in a zone and which authoritative RRTypes exist at those owner names.\n\nIETF's design criteria consider DNS data to be public. Confidentiality is not one of the security goals of DNSSEC. DNSSEC is not designed to directly protect against denial-of-service threats but does so indirectly by providing message integrity and source authentication. An artifact of how DNSSEC performs negative responses allows a client to map all the names in a zone (zone walking). \n\nA zone which contains zone data that the administrator does not want to be made public should use the NSEC3 RR option for providing authenticated denial of existence.\n\nIf DNSSEC is enabled for a server, the ability to verify a particular server which may attempt to update the DNS server actually exists. This is done through the use of NSEC3 records to provide an \"authenticated denial of existence\" for specific systems whose addresses indicate that they lie within a particular zone.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68603",
+      "title": "The Infoblox system must ensure each NS record in a zone file points to an active name server authoritative for the domain specified in that record.",
+      "description": "Poorly constructed NS records pose a security risk because they create conditions under which an adversary might be able to provide the missing authoritative name services that are improperly specified in the zone file. The adversary could issue bogus responses to queries that clients would accept because they learned of the adversary's name server from a valid authoritative name server, one that need not be compromised for this attack to be successful. The list of slave servers must remain current within 72 hours of any changes to the zone architecture that would affect the list of slaves. If a slave server has been retired or is not operational but remains on the list, then an adversary might have a greater opportunity to impersonate that slave without detection, rather than if the slave were actually online. For example, the adversary may be able to spoof the retired slave's IP address without an IP address conflict, which would not be likely to occur if the true slave were active.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68605",
+      "title": "All authoritative name servers for a zone must be located on different network segments.",
+      "description": "Most enterprises have an authoritative primary server and a host of authoritative secondary name servers. It is essential that these authoritative name servers for an enterprise be located on different network segments. This dispersion ensures the availability of an authoritative name server not only in situations in which a particular router or switch fails but also during events involving an attack on an entire network segment.\n\nA network administrator may choose to use a \"hidden\" master authoritative server and only have secondary servers visible on the network. A hidden master authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. If the master authoritative name server is \"hidden\", a secondary authoritative name server may reside on the same network as the hidden master.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68607",
+      "title": "An authoritative name server must be configured to enable DNSSEC Resource Records.",
+      "description": "The specification for a digital signature mechanism in the context of the DNS infrastructure is in IETF's DNSSEC standard. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted zone (such as the root zone) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. DNSSEC mechanisms involve two main processes: sign and serve, and verify signature.\n\nBefore a DNSSEC-signed zone can be deployed, a name server must be configured to enable DNSSEC processing.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68609",
+      "title": "Digital signature algorithm used for DNSSEC-enabled zones must be FIPS-compatible.",
+      "description": "The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) [FIPS186] provides three algorithm choices:\n* Digital Signature Algorithm (DSA)\n* RSA\n* Elliptic Curve DSA (ECDSA).\nOf these three algorithms, RSA and DSA are more widely available and hence are considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. Hence, RSA is the recommended algorithm as far as this guideline is concerned. RSA with SHA-1 is currently the only cryptographic algorithm mandated to be implemented with DNSSEC, although other algorithm suites (i.e. RSA/SHA-256, ECDSA) are also specified. It can be expected that name servers and clients will be able to use the RSA algorithm at the minimum. It is suggested that at least one ZSK for a zone use the RSA algorithm.\nNIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 as approved hash algorithms to be used as part of the algorithm suite for generating digital signatures using the digital signature algorithms in NIST's DSS[FIPS186]. It is expected that there will be support for Elliptic Curve Cryptography in the DNSSEC. The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before September 30th, 2015.",
+      "severity": "high"
+    },
+    {
+      "id": "V-68611",
+      "title": "For zones split between the external and internal sides of a network, the RRs for the external hosts must be separate from the RRs for the internal hosts.",
+      "description": "Authoritative name servers for an enterprise may be configured to receive requests from both external and internal clients. \n\nExternal clients need to receive RRs that pertain only to public services (public Web server, mail server, etc.) \n\nInternal clients need to receive RRs pertaining to public services as well as internal hosts. \n\nThe zone information that serves the RRs on both the inside and the outside of a firewall should be split into different physical files for these two types of clients (one file for external clients and one file for internal clients).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68613",
+      "title": "In a split DNS configuration, where separate name servers are used between the external and internal networks, the external name server must be configured to not be reachable from inside resolvers.",
+      "description": "Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. \n\nOne set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (Web servers that serve external Web pages or provide B2C services, mail servers, etc.) \n\nThe other set, called internal name servers, is to be located within the firewall and should be configured so they are not reachable from outside and hence provide naming services exclusively to internal clients.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68615",
+      "title": "In a split DNS configuration, where separate name servers are used between the external and internal networks, the internal name server must be configured to not be reachable from outside resolvers.",
+      "description": "Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. \n\nOne set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (Web servers that serve external Web pages or provide B2C services, mail servers, etc.) \n\nThe other set, called internal name servers, is to be located within the firewall and should be configured so they are not reachable from outside and hence provide naming services exclusively to internal clients.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68617",
+      "title": "The DNS implementation must enforce a Discretionary Access Control (DAC) policy that limits propagation of access rights.",
+      "description": "Discretionary Access Control (DAC) is based on the premise that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly.\n\nThe primary objective of DNS authentication and access control is the integrity of DNS records; only authorized personnel must be able to create and modify resource records, and name servers should only accept updates from authoritative master servers for the relevant zones. Integrity is best assured through authentication and access control features within the name server software and the file system the name server resides on. In order to protect the zone files and configuration data, which should only be accessed by the name service or an administrator, access controls need to be implemented on files, and rights should not be easily propagated to other users. Lack of a stringent access control policy places the DNS infrastructure at risk to malicious persons and attackers, in addition to potential denial of service to network resources.\n\nDAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. DAC models have the potential for the access controls to propagate without limit, resulting in unauthorized access to said objects.\n\nWhen applications provide a DAC mechanism, the DNS implementation must be able to limit the propagation of those access rights.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68619",
+      "title": "A secure Out Of Band (OOB) network must be utilized for management of Infoblox Grid Members.",
+      "description": "The Infoblox Grid Master is the central point of management within an Infoblox Grid. The Grid Master retains a full copy of the configuration used for the entire Grid. The Grid Master should communicate to Grid Members using their Management port connected to an Out Of Band (OOB) network which clients cannot access.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68621",
+      "title": "The DHCP service must not be enabled on an external authoritative name server.",
+      "description": "The site DNS and DHCP architecture must be reviewed to ensure only the appropriate services are enabled on each Grid Member. An external authoritative name server must be configured to allow only authoritative DNS.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68623",
+      "title": "Infoblox systems must be configured with current DoD password restrictions.",
+      "description": "The Infoblox systems must be configured to meet current DoD password policy when using the Infoblox Local User Database as the authentication source.",
+      "severity": "high"
+    },
+    {
+      "id": "V-68625",
+      "title": "Infoblox Grid configuration must be backed up on a regular basis.",
+      "description": "The Infoblox Grid Master is the central point of management within an Infoblox Grid. The Grid Master retains a full copy of the configuration used for the entire Grid. In the event of system failure, a configuration backup must be preserved. An Infoblox member may also be configured as a Grid Master Candidate which is a synchronized to the Grid Master. The Candidate can be promoted in the event of system failure on the Grid Master.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68627",
+      "title": "The Infoblox system must be configured with the approved DoD notice and consent banner.",
+      "description": "Configuration of the DoD notice and consent banner requires all administrators to acknowledge the current DoD notice and consent by clicking an \"Accept\" button.",
+      "severity": "low"
+    },
+    {
+      "id": "V-68629",
+      "title": "The Infoblox system must be configured to display the appropriate security classification information.",
+      "description": "Configuration of the informational banner displays the security classification of the Infoblox system using both color and text. Text may be added for additional security markings.",
+      "severity": "low"
+    },
+    {
+      "id": "V-68631",
+      "title": "The Infoblox system must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.",
+      "description": "Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the application, including the parameters required to satisfy other security control requirements.\n\nConfiguring the DNS server implementation to follow organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68633",
+      "title": "CNAME records must not point to a zone with lesser security for more than six months.",
+      "description": "The use of CNAME records for exercises, tests, or zone-spanning aliases should be temporary (e.g., to facilitate a migration). When a host name is an alias for a record in another zone, an adversary has two points of attack: the zone in which the alias is defined and the zone authoritative for the alias's canonical name. This configuration also reduces the speed of client resolution because it requires a second look-up after obtaining the canonical name. Furthermore, in the case of an authoritative name server, this information is promulgated throughout the enterprise to caching servers and thus compounds the vulnerability.\nThe exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated (AO approval of use of a commercial cloud offering would satisfy this requirement). Additional exceptions are CNAME records in a multi-domain Active Directory environment pointing to hosts in other internal domains in the same multi-domain environment.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68635",
+      "title": "The private keys corresponding to both the ZSK and the KSK must not be kept on the DNSSEC-aware primary authoritative name server when the name server does not support dynamic updates.",
+      "description": "The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. \n\nThis strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept off-line.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68637",
+      "title": "The platform on which the name server software is hosted must be configured to send outgoing DNS messages from a random port.",
+      "description": "OS configuration practices as issued by the US Computer Emergency Response Team (US CERT) and the National Institute of Standards and Technology's (NIST's) National Vulnerability Database (NVD), based on identified vulnerabilities that pertain to the application profile into which the name server software fits, should be always followed. In particular, hosts that run the name server software should not provide any other services and therefore should be configured to respond to DNS traffic only. In other words, the only allowed incoming ports/protocols to these hosts should be 53/udp and 53/tcp. \n\nOutgoing DNS messages should be sent from a random port to minimize the risk of an attacker guessing the outgoing message port and sending forged replies.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68639",
+      "title": "The platform on which the name server software is hosted must be configured to respond to DNS traffic only.",
+      "description": "OS configuration practices as issued by the US Computer Emergency Response Team (US CERT) and the National Institute of Standards and Technology's (NIST's) National Vulnerability Database (NVD), based on identified vulnerabilities that pertain to the application profile into which the name server software fits, should be always followed. In particular, hosts that run the name server software should not provide any other services and therefore should be configured to respond to DNS traffic only. In other words, the only allowed incoming ports/protocols to these hosts should be 53/udp and 53/tcp. Outgoing DNS messages should be sent from a random port to minimize the risk of an attacker's guessing the outgoing message port and sending forged replies.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68641",
+      "title": "The IP address for hidden master authoritative name servers must not appear in the name servers set in the zone database.",
+      "description": "A hidden master authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. All of the name servers that do appear in the zone database as designated name servers get their zone data from the hidden master via a zone transfer request. In effect, all visible name servers are actually secondary slave servers. This prevents potential attackers from targeting the master name server because its IP address may not appear in the zone database.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68643",
+      "title": "The Infoblox NIOS version must be at the appropriate version.",
+      "description": "Infoblox NIOS is updated on a regular basis to add feature support, implement bug fixes, and address security vulnerabilities. NIOS is a hardened system with no direct user access to the software components. The review of security vulnerabilities such as MITRE Common Vulnerabilities and Exposure (CVE) can be accomplished by review of the running system NIOS version and published security information. Review of specific or individual software component versions within NIOS is not sufficient validation, as Infoblox modifies these software components and may or may not be subject to vulnerabilities that exist in unmodified publicly available source code.\n\nInfoblox may support multiple versions of NIOS, each of which may address the same security vulnerability at different patch releases. It is not necessary for an Infoblox customer to run the highest possible version, rather they should run the supported version applicable to their environment and ensure it is patched to address all known vulnerabilities.\n\nInfoblox publishes security information within each NIOS version release notes and on the Infoblox Support Knowledge Base. Infoblox customers can also use the support portal to validate security questions and applicability of vulnerabilities.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68645",
+      "title": "The Infoblox system must utilize valid root name servers in the local root zone file.",
+      "description": "All caching name servers must be authoritative for the root zone because, without this starting point, they would have no knowledge of the DNS infrastructure and thus would be unable to respond to any queries. The security risk is that an adversary could change the root hints and direct the caching name server to a bogus root server. At that point, every query response from that name server is suspect, which would give the adversary substantial control over the network communication of the name servers' clients. When authoritative servers are sent queries for zones that they are not authoritative for, and they are configured as a non-caching server (as recommended), they can either be configured to return a referral to the root servers or they can be configured to refuse to answer the query. The recommendation is to configure authoritative servers to refuse to answer queries for any zones for which they are not authoritative. This is more efficient for the server and allows it to spend more of its resources doing what its intended purpose is, answering authoritatively for its zone.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68647",
+      "title": "The DNS implementation must implement internal/external role separation.",
+      "description": "DNS servers with an internal role only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks, including the Internet). The set of clients that can access an authoritative DNS server in a particular role is specified by the organization using address ranges, explicit access control lists, etc. In order to protect internal DNS resource information, it is important to isolate the requests to internal DNS servers. Separating internal and external roles in DNS prevents address space that is private (e.g., 10.0.0.0/24) or is otherwise concealed by some form of Network Address Translation from leaking into the public DNS system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68699",
+      "title": "Infoblox systems which are configured to perform zone transfers to non-Grid name servers must utilize transaction signatures (TSIG).",
+      "description": "Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. This applies to server-to-server (zone transfer) transactions only and is provided by TSIG, which enforces mutual server authentication using a key that is unique to each server pair (TSIG), thus uniquely identifying the other server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68701",
+      "title": "Infoblox DNS servers must be configured to protect the authenticity of communications sessions for queries.",
+      "description": "The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. An integral part of integrity verification is to ensure that valid data has originated from the right source. DNSSEC is required for securing the DNS query/response transaction by providing data origin authentication and data integrity verification through signature verification and the chain of trust.",
+      "severity": "medium"
+    }
+  ]
+}

data/standards/stig_infrastructure_l3_switch.json

@@ -0,0 +1,599 @@
+{
+  "name": "stig_infrastructure_l3_switch",
+  "date": "2018-03-02",
+  "description": "Infrastructure L3 Switch Security Technical Implementation Guide",
+  "title": "Infrastructure L3 Switch Security Technical Implementation Guide",
+  "version": "8",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-14667",
+      "title": "Network devices must be configured with rotating keys used for authenticating IGP peers that have a duration of 180 days or less.",
+      "description": "If the keys used for routing protocol authentication are guessed, the malicious user could create havoc within the network by advertising incorrect routes and redirecting traffic. Changing the keys frequently reduces the risk of them eventually being guessed. When configuring authentication for routing protocols that provide key chains, configure two rotating keys with overlapping expiration dates, both with 180-day or less expirations.",
+      "severity": "low"
+    },
+    {
+      "id": "V-14668",
+      "title": "FTP servers on the device must be disabled.",
+      "description": "The additional services enabled on a router increases the risk for an attack since the router will listen for these services. In addition, these services provide an unsecured method for an attacker to gain access to the router.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-14669",
+      "title": "Network devices must have BSDr commands disabled.",
+      "description": "Berkeley Software Distribution (BSD) \"r\" commands allow users to execute commands on remote systems using a variety of protocols. The BSD \"r\" commands (e.g., rsh, rlogin, rcp, rdump, rrestore, and rdist) are designed to provide convenient remote access without passwords to services such as remote command execution (rsh), remote login (rlogin), and remote file copy (rcp and rdist). The difficulty with these commands is they use address-based authentication. An attacker who convinces a server that he is coming from a \"trusted\" machine can essentially get complete and unrestricted access to a system. The attacker can convince the server by impersonating a trusted machine and using IP address, by confusing DNS so that DNS thinks that the attacker's IP address maps to a trusted machine's name, or by any of a number of other methods.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-14671",
+      "title": "Network devices must authenticate all NTP messages received from NTP servers and peers.",
+      "description": "Since NTP is used to ensure accurate log file time stamp information, NTP could pose a security risk if a malicious user were able to falsify NTP information. To launch an attack on the NTP infrastructure, a hacker could inject time that would be accepted by NTP clients by spoofing the IP address of a valid NTP server. To mitigate this risk, the time messages must be authenticated by the client before accepting them as a time source. \n\nTwo NTP-enabled devices can communicate in either client-server mode or peer-to-peer mode (aka \"symmetric mode\"). The peering mode is configured manually on the device and indicated in the outgoing NTP packets. The fundamental difference is the synchronization behavior: an NTP server can synchronize to a peer with better stratum, whereas it will never synchronize to its client regardless of the client's stratum. From a protocol perspective, NTP clients are no different from the NTP servers. The NTP client can synchronize to multiple NTP servers, select the best server and synchronize with it, or synchronize to the averaged value returned by the servers.\n\nA hierarchical model can be used to improve scalability. With this implementation, an NTP client can also become an NTP server providing time to downstream clients at a higher stratum level and of decreasing accuracy than that of its upstream server. To increase availability, NTP peering can be used between NTP servers. In the event the device loses connectivity to its upstream NTP server, it will be able to choose time from one of its peers. \n\nThe NTP authentication model is opposite of the typical client-server authentication model. NTP authentication enables an NTP client or peer to authenticate time received from their servers and peers. It is not used to authenticate NTP clients because NTP servers do not care about the authenticity of their clients, as they never accept any time from them.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-14672",
+      "title": "The network device must use its loopback or OOB management interface address as the source address when originating authentication services traffic.",
+      "description": "Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router's loopback address instead of the numerous physical interface addresses. TACACS+, RADIUS messages sent to management servers should use the loopback address as the source address.",
+      "severity": "low"
+    },
+    {
+      "id": "V-14673",
+      "title": "The network device must use its loopback or OOB management interface address as the source address when originating syslog traffic.",
+      "description": "Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router's loopback address instead of the numerous physical interface addresses. Syslog messages sent to management servers should use the loopback address as the source address.",
+      "severity": "low"
+    },
+    {
+      "id": "V-14674",
+      "title": "The network device must use its loopback or OOB management interface address as the source address when originating NTP traffic.",
+      "description": "Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router's loopback address instead of the numerous physical interface addresses. NTP messages sent to management servers should use the loopback address as the source address.",
+      "severity": "low"
+    },
+    {
+      "id": "V-14675",
+      "title": "The network device must use its loopback or OOB management interface address as the source address when originating SNMP traffic.",
+      "description": "Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router's loopback address instead of the numerous physical interface addresses. SNMP messages sent to management servers should use the loopback address as the source address.",
+      "severity": "low"
+    },
+    {
+      "id": "V-14676",
+      "title": "The network device must use its loopback or OOB management interface address as the source address when originating IP Flow/NetFlow traffic.",
+      "description": "Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router's loopback address instead of the numerous physical interface addresses. NetFlow messages sent to management servers should use the loopback address as the source address.",
+      "severity": "low"
+    },
+    {
+      "id": "V-14677",
+      "title": "The network device must use its loopback or OOB management interface address as the source address when originating TFTP or FTP traffic.",
+      "description": "Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of network devices. It is easier to construct appropriate ingress filters for management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router's loopback address instead of the numerous physical interface addresses. TFTP and FTP messages sent to management servers should use the loopback address as the source address.",
+      "severity": "low"
+    },
+    {
+      "id": "V-14681",
+      "title": "The network device must use its loopback interface address as the source address for all iBGP peering sessions.",
+      "description": "Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability. It is easier to construct appropriate filters for control plane traffic. Log information recorded by authentication and syslog servers will record the router's loopback address instead of the numerous physical interface addresses.",
+      "severity": "low"
+    },
+    {
+      "id": "V-14693",
+      "title": "The network device must be configured to ensure IPv6 Site Local Unicast addresses are not defined in the enclave, (FEC0::/10). Note that this consist of all addresses that begin with FEC, FED, FEE and FEF.",
+      "description": "As currently defined, site local addresses are ambiguous and can be present in multiple sites.  The address itself does not contain any indication of the site to which it belongs.  The use of site-local addresses has the potential to adversely affect network security through leaks, ambiguity and potential misrouting, as documented in section 2 of RFC3879.  RFC3879 formally deprecates the IPv6 site-local unicast prefix defined in RFC3513, i.e., 1111111011 binary or FEC0::/10.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-14707",
+      "title": "The network element must be configured from accepting any outbound IP packet that contains an illegitimate address in the source address field via egress ACL or by enabling Unicast Reverse Path Forwarding in an IPv6 enclave.",
+      "description": "Unicast Reverse Path Forwarding (uRPF) provides a mechanism for IP address spoof protection.  When uRPF is enabled on an interface, the router examines all packets received as input on that interface to make sure that the source address and source interface appear in the routing table and match the interface on which the packet was received.  If the packet was received from one of the best reverse path routes, the packet is forwarded as normal.  If there is no reverse path route on the same interface from which the packet was received, it might mean that the source address was modified.  If Unicast RPF does not find a reverse path for the packet, the packet is dropped.\n\nIf internal nodes automatically configure an address based on a prefix from a bogus Router Advertisement a dangerous situation may exist. An internal host may contact an internal server which responds with a packet that could be routed outside of the network via default routing (because the routers do not recognize the destination address as an internal address).  \n\nTo prevent this, filtering should be applied to network interfaces between internal host LANs and internal server LANs to insure that source addresses have valid prefixes. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-14717",
+      "title": "The network device must not allow SSH Version 1 to be used for administrative access.",
+      "description": "SSH Version 1 is a protocol that has never been defined in a standard. Since SSH-1 has inherent design flaws which make it vulnerable to attacks, e.g., man-in-the-middle attacks, it is now generally considered obsolete and should be avoided by explicitly disabling fallback to SSH-1.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-15288",
+      "title": "ISATAP tunnels must terminate at an interior router.",
+      "description": "ISATAP is an automatic tunnel mechanism that does not provide authentication such as IPSec.  As a result of this limitation, ISATAP is thought of as a tool that is used inside the enclave among trusted hosts, which would limit it to internal attacks.  ISATAP is a service versus a product, and is readily available to most users.  If a user knows the ISATAP router IP address, they can essentially get onto the IPv6 intranet.  To control the vulnerability of this tunnel mechanism, it is critical to control the use of protocol 41 and use IPv4 filters to control what IPv4 nodes can send protocol 41 packets to an ISATAP router interface.  Although the ISATAP tunneling mechanism is similar to other automatic tunneling mechanisms, such as IPv6 6to4 tunneling, ISATAP is designed for transporting IPv6 packets between sites within an enclave, not between enclaves.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-15432",
+      "title": "Network devices must use two or more authentication servers for the purpose of granting administrative access.",
+      "description": "The use of Authentication, Authorization, and Accounting (AAA) affords the best methods for controlling user access, authorization levels, and activity logging.  By enabling AAA on the routers in conjunction with an authentication server such as TACACS+ or RADIUS, the administrators can easily add or remove user accounts, add or remove command authorizations, and maintain a log of user activity.\n\nThe use of an authentication server provides the capability to assign router administrators to tiered groups that contain their privilege level that is used for authorization of specific commands.   For example, user mode would be authorized for all authenticated administrators while configuration or edit mode should only be granted to those administrators that are permitted to implement router configuration changes.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-15434",
+      "title": "The emergency administration account must be set to an appropriate authorization level to perform necessary administrative functions when the authentication server is not online.",
+      "description": "The emergency administration account is to be configured as a local account on the network devices. It is to be used only when the authentication server is offline or not reachable via the network. The emergency account must be set to an appropriate authorization level to perform necessary administrative functions during this time.",
+      "severity": "high"
+    },
+    {
+      "id": "V-17754",
+      "title": "IPSec tunnels used to transit management traffic must be restricted to only the authorized management packets based on destination and source IP address.",
+      "description": "The Out-of-Band Management (OOBM) network is an IP network used exclusively for the transport of OAM&P data from the network being managed to the OSS components located at the NOC. Its design provides connectivity to each managed network device enabling network management traffic to flow between the managed NEs and the NOC.  This allows the use of paths separate from those used by the network being managed. Traffic from the managed network to the management network and vice-versa must be secured via IPSec encapsulation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17814",
+      "title": "Gateway configuration at the remote VPN end-point is a not a mirror of the local gateway ",
+      "description": "The IPSec tunnel end points may be configured on the OOBM gateway routers connecting the managed network and the NOC. They may also be configured on a firewall or VPN concentrator located behind the gateway router. In either case, the crypto access-list used to identify the traffic to be protected must be a mirror (both IP source and destination address) of the crypto access list configured at the remote VPN peer.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17815",
+      "title": "IGP instances configured on the OOBM gateway router do not peer only with their appropriate routing domain.",
+      "description": "If the gateway router is not a dedicated device for the OOBM network, several safeguards must be implemented for containment of management and production traffic boundaries. Since the managed network and the management network are separate routing domains, separate IGP routing instances must be configured on the router—one for the managed network and one for the OOBM network. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17816",
+      "title": "The routes from the two IGP domains are redistributed to each other.",
+      "description": "If the gateway router is not a dedicated device for the OOBM network, several safeguards must be implemented for containment of management and production traffic boundaries. Since the managed network and the management network are separate routing domains, separate IGP routing instances must be configured on the router—one for the managed network and one for the OOBM network. In addition, the routes from the two domains must not be redistributed to each other.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17817",
+      "title": "Traffic from the managed network is able to access the OOBM gateway router",
+      "description": "If the gateway router is not a dedicated device for the OOBM network, several safeguards must be implemented for containment of management and production traffic boundaries. It is imperative that hosts from the managed network are not able to access the OOBM gateway rouiter.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17818",
+      "title": "Traffic from the managed network will leak into the management network via the gateway router interface connected to the OOBM backbone.",
+      "description": "If the gateway router is not a dedicated device for the OOBM network, several safeguards must be implemented for containment of management and production traffic boundaries such as using interface ACLs or filters at the boundaries between the two networks. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17819",
+      "title": "Management network traffic must not leak onto the managed network.",
+      "description": "If the gateway router is not a dedicated device for the OOBM network, several safeguards must be implemented for containment of management and production traffic boundaries. To provide separation, access control lists or filters must be configured to block any traffic from the management network destined for the managed network's production address spaces.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17821",
+      "title": "The network devices OOBM interface must be configured with an OOBM network address.",
+      "description": "The OOBM access switch will connect to the management interface of the managed network device. The management interface of the managed network device will be directly connected to the OOBM network. An OOBM interface does not forward transit traffic; thereby, providing complete separation of production and management traffic. Since all management traffic is immediately forwarded into the management network, it is not exposed to possible tampering. The separation also ensures that congestion or failures in the managed network do not affect the management of the device. If the OOBM interface does not have an IP address from the managed network address space, it will not have reachability from the NOC using scalable and normal control plane and forwarding mechanisms.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17822",
+      "title": "The network devices management interface must be configured with both an ingress and egress ACL.",
+      "description": "The OOBM access switch will connect to the management interface of the managed network device. The management interface can be a true OOBM interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network device will be directly connected to the OOBM network.\n\nAn OOBM interface does not forward transit traffic; thereby, providing complete separation of production and management traffic. Since all management traffic is immediately forwarded into the management network, it is not exposed to possible tampering. The separation also ensures that congestion or failures in the managed network do not affect the management of the device. If the device does not have an OOBM port, the interface functioning as the management interface must be configured so that management traffic does not leak into the managed network and that production traffic does not leak into the management network.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17823",
+      "title": "The management interface must be configured as passive for the IGP instance deployed in the managed network.",
+      "description": "The OOBM access switch will connect to the management interface of the managed network devices. The management interface can be a true OOBM interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network devices will be directly connected to the OOBM network.\n\nAn OOBM interface does not forward transit traffic; thereby, providing complete separation of production and management traffic. Since all management traffic is immediately forwarded into the management network, it is not exposed to possible tampering. The separation also ensures that congestion or failures in the managed network do not affect the management of the device. If the device does not have an OOBM port, the interface functioning as the management interface must be configured so that management traffic, both data plane and control plane, does not leak into the managed network and that production traffic does not leak into the management network.",
+      "severity": "low"
+    },
+    {
+      "id": "V-17824",
+      "title": "The management interface is an access switchport and has not been assigned to a separate management VLAN. ",
+      "description": "The OOBM access switch will connect to the management interface of the managed network elements. The management interface can be a true OOBM interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network element will be directly connected to the OOBM network. If the device does not have an OOBM port, the interface functioning as the management interface must be configured so that management traffic does not leak into the managed network and that production traffic does not leak into the management network.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17825",
+      "title": "An address has not been configured for the management VLAN from space belonging to the OOBM network assigned to that site.",
+      "description": "The OOBM access switch will connect to the management interface of the managed network elements. The management interface can be a true OOBM interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network element will be directly connected to the OOBM network.\n\nAn OOBM interface does not forward transit traffic; thereby, providing complete separation of production and management traffic. Since all management traffic is immediately forwarded into the management network, it is not exposed to possible tampering.  The separation also ensures that congestion or failures in the managed network do not affect the management of the device. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-17826",
+      "title": "The access switchport connecting to the OOBM access switch is not the only port with membership to the management VLAN.",
+      "description": "The OOBM access switch will connect to the management interface of the managed network elements. The management interface can be a true OOBM interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network element will be directly connected to the OOBM network.\n\nAn OOBM interface does not forward transit traffic; thereby, providing complete separation of production and management traffic. Since all management traffic is immediately forwarded into the management network, it is not exposed to possible tampering.  The separation also ensures that congestion or failures in the managed network do not affect the management of the device. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17827",
+      "title": "The management VLAN is not pruned from any VLAN trunk links belonging to the managed network’s infrastructure. \n\n",
+      "description": "The OOBM access switch will connect to the management interface of the managed network elements. The management interface can be a true OOBM interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network element will be directly connected to the OOBM network.\n\nAn OOBM interface does not forward transit traffic; thereby, providing complete separation of production and management traffic. Since all management traffic is immediately forwarded into the management network, it is not exposed to possible tampering.  The separation also ensures that congestion or failures in the managed network do not affect the management of the device. If the device does not have an OOBM port, the interface functioning as the management interface must be configured so that management traffic does not leak into the managed network and that production traffic does not leak into the management network. ISL and 802.1q trunking enables multiple VLANs to traverse the same physical links between layer 2 switches or between a layer 2 switch and a router. If the management VLAN is not pruned from any VLAN trunk links belonging to the managed network’s infrastructure, management traffic has the potential to leak into the production network.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-17832",
+      "title": "The management VLAN must be configured with an IP address from the management network address block.",
+      "description": "If the management systems reside within the same layer 2 switching domain as the managed network device, then separate VLANs will be deployed to provide separation at that level. In this case, the management network still has its own subnet while at the same time it is defined as a unique VLAN.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17833",
+      "title": "The ISSO will ensure that only authorized management traffic is forwarded by the multi-layer switch from the production or managed VLANs to the management VLAN.",
+      "description": "If the management systems reside within the same Layer 2 switching domain as the managed network elements, then separate VLANs will be deployed to provide separation at that level. In this case, the management network still has its own subnet while at the same time it is defined as a unique VLAN.  Inter-VLAN routing or the routing of traffic between nodes residing in different subnets requires a router or multi-layer switch (MLS). Access control lists must be used to enforce the boundaries between the management network and the network being managed. When using a MLS, an alternate method to prevent inter-VLAN routing is to configure the management Virtual Routing and Forwarding (VRF) to not import route targets from other VRFs which would ensure there is no reachability between networks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17834",
+      "title": "An inbound ACL is not configured for the management network sub-interface of the trunk link to block non-management traffic.\n\n",
+      "description": "If the management systems reside within the same layer 2 switching domain as the managed network elements, then separate VLANs will be deployed to provide separation at that level. In this case, the management network still has its own subnet while at the same time it is defined as a unique VLAN. Inter-VLAN routing or the routing of traffic between nodes residing in different subnets requires a router or multi-layer switch (MLS). Access control lists must be used to enforce the boundaries between the management network and the network being managed. All physical and virtual (i.e. MLS SVI) routed interfaces must be configured with ACLs to prevent the leaking of unauthorized traffic from one network to the other. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17835",
+      "title": "Traffic entering the tunnels is not restricted to only the authorized management packets based on destination address. ",
+      "description": "Similar to the OOBM model, when the production network is managed in-band, the management network could also be housed at a NOC that is located locally or remotely at a single or multiple interconnected sites. NOC interconnectivity as well as connectivity between the NOC and the managed networks’ premise routers would be enabled using either provisioned circuits or VPN technologies such as IPSec tunnels or MPLS VPN services. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-17836",
+      "title": "Management traffic is not classified and marked at the nearest upstream MLS or router when management traffic must traverse several nodes to reach the management network.",
+      "description": "When network congestion occurs, all traffic has an equal chance of being dropped. \nPrioritization of network management traffic must be implemented to ensure that even during periods of severe network congestion, the network can be managed and monitored. Quality of Service (QoS) provisioning categorizes network traffic, prioritizes it according to its relative importance, and provides priority treatment through congestion avoidance techniques. Implementing QoS within the network makes network performance more predictable and bandwidth utilization more effective. Most important, since the same bandwidth is being used to manage the network, it provides some assurance that there will be bandwidth available to troubleshoot outages and restore availability when needed. \n\nWhen management traffic must traverse several nodes to reach the management network, management traffic should be classified and marked at the nearest upstream MLS or router. In addition, all core routers within the managed network must be configured to provide preferred treatment based on the QoS markings. This will ensure that management traffic receives preferred treatment (per-hop behavior) at each forwarding device along the path to the management network. traffic.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-17837",
+      "title": "The core router within the managed network has not been configured to provide preferred treatment for management traffic that must traverse several nodes to reach the management network.",
+      "description": "When network congestion occurs, all traffic has an equal chance of being dropped. \nPrioritization of network management traffic must be implemented to ensure that even during periods of severe network congestion, the network can be managed and monitored. Quality of Service (QoS) provisioning categorizes network traffic, prioritizes it according to its relative importance, and provides priority treatment through congestion avoidance techniques. Implementing QoS within the network makes network performance more predictable and bandwidth utilization more effective. Most important, since the same bandwidth is being used to manage the network, it provides some assurance that there will be bandwidth available to troubleshoot outages and restore availability when needed. \n\nWhen management traffic must traverse several nodes to reach the management network, management traffic should be classified and marked at the nearest upstream MLS or router. In addition, all core routers within the managed network must be configured to provide preferred treatment based on the QoS markings. This will ensure that management traffic receives preferred treatment (per-hop behavior) at each forwarding device along the path to the management network. traffic.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-18522",
+      "title": "Server VLAN interfaces must be protected by restrictive ACLs using a deny-by-default security posture.",
+      "description": "Protecting data sitting in a server VLAN is necessary and can be accomplished using access control lists on VLANs provisioned for servers.  Without proper access control of traffic entering or leaving the server VLAN, potential threats such as a denial of service, data corruption, or theft could occur, resulting in the inability to complete mission requirements by authorized users.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18523",
+      "title": "The IAO will ensure the Server Farm infrastructure is secured by ACLs on VLAN interfaces that restrict data originating from one server farm segment destined to another server farm segment.",
+      "description": "ACLs on VLAN interfaces do not protect against compromised servers. The Server farm vlans need to protect the servers located on one subnet from servers located on another subnet. Protecting a client’s data from other clients is necessary and can be accomplished using VLAN provisioning, layer 3 filtering and content filtering at the Server Farm entry point. Restricting protocol, source and destination traffic via filters is an option; however additional security practices such as content filtering are required.\n\nThe Server farm private vlans need to protect the servers located on one subnet from servers located on another subnet.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18544",
+      "title": "Printers must be assigned to a VLAN that is not shared by unlike devices.",
+      "description": "Aspects of hardening the network wall plate may include traffic filtering or restrictions on connectivity to enforce a device-, community of interest-, or user-specific security policy. For example, if a printer were plugged into a switch port, it would be prudent to ensure that only printer traffic is allowed on that switch port. If the printer is unplugged and a substitute device other than a printer is plugged into that switch port, the substitute device should not be able to communicate arbitrarily with other devices because only printer traffic is allowed on that switch port.",
+      "severity": "low"
+    },
+    {
+      "id": "V-18545",
+      "title": "The SA will ensure a packet filter is implemented to filter the enclave traffic to and from printer VLANs to allow only print traffic.",
+      "description": "A firewall rule set can filter network traffic within the printer VLAN to only expected printer protocols. The SA managing the local enclave should identify the printer port traffic within the enclave. Ports commonly used by printers are typically tcp port 515, 631, 1782 and tcp ports 9100, 9101, 9102 but others are used throughout the industry. The SA can review RFC 1700 Port Assignments and review printer vendor documents for the filter rule-set.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18565",
+      "title": "The IAO will ensure that all switchports configured using MAC port security will shutdown upon receiving a frame with a different layer 2 source address than what has been configured or learned for port security.",
+      "description": "The Port Security feature remembers the Ethernet MAC address connected to the switch port and allows only that MAC address to communicate on that port. If any other MAC address tries to communicate through the port, port security will disable the port. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18566",
+      "title": "The switch must only allow a maximum of one registered MAC address per access port.",
+      "description": "Limiting the number of registered MAC addresses on a switch access port can help prevent a CAM table overflow attack.  This type of attack lets an attacker exploit the hardware and memory limitations of a switch.  If there are enough entries stored in a CAM table before the expiration of other entries, no new entries can be accepted into the CAM table. An attacker will able to flood the switch with mostly invalid MAC addresses until the CAM table’s resources have been depleted.  When there are no more resources, the switch has no choice but to flood all ports within the VLAN with all incoming traffic.  This happens because the switch cannot find the switch port number for a corresponding MAC address within the CAM table, allowing the switch to become a hub and traffic to be monitored.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18790",
+      "title": "Default routes must not be directed to the tunnel entry point.",
+      "description": "Routing in the network containing the tunnel entry point must be configured to direct the intended traffic into the tunnel.  Depending on the router products used this may be done by creating routes to a tunnel by name, by address, or by interface.  \n\nIf multiple tunnels are defined or IPv6 interfaces, you must be selective with static routes, policy based routing, or even let the interior gateway protocol (IGP) make the decision since a ipv4 or ipv6 address has been configured on the tunnel. The key is the administrator should carefully plan and configure or let the IGP determine what goes into each tunnel.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19188",
+      "title": "The network device must have control plane protection enabled.",
+      "description": "The Route Processor (RP) is critical to all network operations as it is the component used to build all forwarding paths for the data plane via control plane processes. It is also instrumental with ongoing network management functions that keep the routers and links available for providing network services. Hence, any disruption to the RP or the control and management planes can result in mission critical network outages. \n\nIn addition to control plane and management plane traffic that is in the router's receive path, the RP must also handle other traffic that must be punted to the RP--that is, the traffic must be fast or process switched. This is the result of packets that must be fragmented, require an ICMP response (TTL expiration, unreachable, etc.) have IP options, etc. A DoS attack targeting the RP can be perpetrated either inadvertently or maliciously involving high rates of punted traffic resulting in excessive RP CPU and memory utilization. To maintain network stability, the router must be able to securely handle specific control plane and management plane traffic that is destined to it, as well as other punted traffic. \n\nUsing the ingress filter on forwarding interfaces is a method that has been used in the past to filter both forwarding path and receiving path traffic. However, this method does not scale well as the number of interfaces grows and the size of the ingress filters grow. Control plane policing can be used to increase security of routers and multilayer switches by protecting the RP from unnecessary or malicious traffic. Filtering and rate limiting the traffic flow of control plane packets can be implemented to protect routers against reconnaissance and DoS attacks allowing the control plane to maintain packet forwarding and protocol states despite an attack or heavy load on the router or multilayer switch.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19189",
+      "title": "The administrator must ensure that multicast routers are configured to establish\nboundaries for Admin-local or Site-local scope multicast traffic.",
+      "description": "A scope zone is an instance of a connected region of a given scope. Zones of the same scope cannot overlap while zones of a smaller scope will fit completely within a zone of a larger scope. For example, Admin-local scope is smaller than Site-local scope, so the administratively configured boundary fits within the bounds of a site. According to RFC 4007 IPv6 Scoped Address Architecture (section 5), scope zones are also required to be \"convex from a routing perspective\"-that is, packets routed within a zone must not pass through any links that are outside of the zone. This requirement forces each zone to be one contiguous island rather than a series of separate islands. As stated in the DoD IPv6 IA Guidance for MO3, \"One should be able to identify all interfaces of a zone by drawing a closed loop on their network diagram, engulfing some routers and passing through some routers to include only some of their interfaces.\"\n\nAdministrative scoped multicast addresses are locally assigned and are to be used exclusively by the enterprise network or enclave. Hence, administrative scoped multicast traffic must not cross the perimeter of the enclave in either direction. Admin-local scope could be used to contain multicast traffic to a portion of an enclave or within a site. This can make it more difficult for a malicious user to access sensitive traffic if the traffic is restricted to links that the user does not have access to. Admin-local scope is encouraged for any multicast traffic within a network that is intended for network management as well as control plane traffic that must reach beyond link-local destinations.",
+      "severity": "low"
+    },
+    {
+      "id": "V-23747",
+      "title": "Network devices must use at least two NTP servers to synchronize time.",
+      "description": "Without synchronized time, accurately correlating information between devices becomes difficult, if not impossible. If logs cannot be successfully compared between each of the routers, switches, and firewalls, it will be very difficult to determine the exact events that resulted in a network breach incident. NTP provides an efficient and scalable method for network devices to synchronize to an accurate time source.",
+      "severity": "low"
+    },
+    {
+      "id": "V-28784",
+      "title": "A service or feature that calls home to the vendor must be disabled.",
+      "description": "Call home services or features will routinely send data such as configuration and diagnostic information to the vendor for routine or emergency analysis and troubleshooting.  The risk that transmission of sensitive data sent to unauthorized persons could result in data loss or downtime due to an attack.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3000",
+      "title": "The network device must log all interface access control lists (ACL) deny statements.",
+      "description": "Auditing and logging are key components of any security architecture.  It is essential for security personnel to know what is being done, attempted to be done, and by whom in order to compile an accurate risk assessment.  Auditing the actions on network devices provides a means to recreate an attack, or identify a configuration mistake on the device.",
+      "severity": "low"
+    },
+    {
+      "id": "V-3008",
+      "title": "The IAO will ensure IPSec VPNs are established as tunnel type VPNs when transporting management traffic across an ip backbone network.",
+      "description": "Using dedicated paths, the OOBM backbone connects the OOBM gateway routers located at the premise of the managed networks and at the NOC.  Dedicated links can be deployed using provisioned circuits (ATM, Frame Relay, SONET, T-carrier, and others or VPN technologies such as subscribing to MPLS Layer 2 and Layer 3 VPN services) or implementing a secured path with gateway-to-gateway IPsec tunnel.  The tunnel mode ensures that the management traffic will be logically separated from any other traffic traversing the same path.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3012",
+      "title": "Network devices must be password protected.",
+      "description": "Network access control mechanisms interoperate to prevent unauthorized access and to enforce the organization's security policy. Access to the network must be categorized as administrator, user, or guest so the appropriate authorization can be assigned to the user requesting access to the network or a network device. Authorization requires an individual account identifier that has been approved, assigned, and configured on an authentication server. Authentication of user identities is accomplished through the use of passwords, tokens, biometrics, or in the case of multi-factor authentication, some combination thereof. Lack of authentication enables anyone to gain access to the network or possibly a network device providing opportunity for intruders to compromise resources within the network infrastructure.",
+      "severity": "high"
+    },
+    {
+      "id": "V-3013",
+      "title": "Network devices must display the DoD-approved logon banner warning.",
+      "description": "All network devices must present a DoD-approved warning banner prior to a system administrator logging on. The banner should warn any unauthorized user not to proceed. It also should provide clear and unequivocal notice to both authorized and unauthorized personnel that access to the device is subject to monitoring to detect unauthorized usage. Failure to display the required logon warning banner prior to logon attempts will limit DoD's ability to prosecute unauthorized access and also presents the potential to give rise to criminal and civil liability for systems administrators and information systems managers. In addition, DISA's ability to monitor the device's usage is limited unless a proper warning banner is displayed.\n\nDoD CIO has issued new, mandatory policy standardizing the wording of \"notice and consent\" banners and matching user agreements for all Secret and below DoD information systems, including stand-alone systems by releasing DoD CIO Memo, \"Policy on Use of Department of Defense (DoD) Information Systems Standard Consent Banner and User Agreement\", dated 9 May 2008. The banner is mandatory and deviations are not permitted except as authorized in writing by the Deputy Assistant Secretary of Defense for Information and Identity Assurance. Implementation of this banner verbiage is further directed to all DoD components for all DoD assets via USCYBERCOM CTO 08-008A.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3014",
+      "title": "The network devices must timeout management connections for administrative access after 10 minutes or less of inactivity.",
+      "description": "Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled between the managed network device and a PC or terminal server when the later has been left unattended. In addition quickly terminating an idle session will also free up resources committed by the managed network device as well as reduce the risk of a management session from being hijacked. Setting the timeout of the session to 10 minutes or less increases the level of protection afforded critical network components.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3020",
+      "title": "Network devices must have DNS servers defined if it is configured as a client resolver.",
+      "description": "The susceptibility of IP addresses to spoofing translates to DNS host name and IP address mapping vulnerabilities. For example, suppose a source host wishes to establish a connection with a destination host and queries a DNS server for the IP address of the destination host name. If the response to this query is the IP address of a host operated by an attacker, the source host will establish a connection with the attacker's host, rather than the intended target. The user on the source host might then provide logon, authentication, and other sensitive data.",
+      "severity": "low"
+    },
+    {
+      "id": "V-3021",
+      "title": "Network devices must only allow SNMP access from addresses belonging to the management network.",
+      "description": "Detailed information about the network is sent across the network via SNMP.  If this information is discovered by attackers it could be used to trace the network, show the networks topology, and possibly gain access to network devices.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3034",
+      "title": "Network devices must authenticate all IGP peers.",
+      "description": "A rogue router could send a fictitious routing update to convince a site's premise router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information of the site's network, or merely used to disrupt the network's ability to effectively communicate with other networks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3043",
+      "title": "The network device must use different SNMP community names or groups for various levels of read and write access.",
+      "description": "Numerous vulnerabilities exist with SNMP; therefore, without unique SNMP community names, the risk of compromise is dramatically increased. This is especially true with vendors default community names which are widely known by hackers and other networking experts. If a hacker gains access to these devices and can easily guess the name, this could result in denial of service, interception of sensitive information, or other destructive actions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3056",
+      "title": "Group accounts must not be configured for use on the network device.",
+      "description": "Group accounts configured for use on a network device do not allow for accountability or repudiation of individuals using the shared account.  If group accounts are not changed when someone leaves the group, that person could possibly gain control of the network device.  Having group accounts does not allow for proper auditing of who is accessing or changing the network.",
+      "severity": "high"
+    },
+    {
+      "id": "V-3057",
+      "title": "Authorized accounts must be assigned the least privilege level necessary to perform assigned duties.",
+      "description": "By not restricting authorized accounts to their proper privilege level, access to restricted functions may be allowed before authorized personnel are trained or experienced enough to use those functions. Network disruptions or outages may occur due to mistakes made by inexperienced persons using accounts with greater privileges than necessary.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30577",
+      "title": "The administrator must ensure that Protocol Independent Multicast (PIM) is disabled on all interfaces that are not required to support multicast routing.",
+      "description": "A scope zone is an instance of a connected region of a given scope. Zones of the same scope cannot overlap while zones of a smaller scope will fit completely within a zone of a larger scope. For example, Admin-local scope is smaller than Site-local scope, so the administratively configured boundary fits within the bounds of a site. According to RFC 4007 IPv6 Scoped Address Architecture (section 5), scope zones are also required to be “convex from a routing perspective”—that is, packets routed within a zone must not pass through any links that are outside of the zone. This requirement forces each zone to be one contiguous island rather than a series of separate islands. As stated in the DoD IPv6 IA Guidance for MO3, “One should be able to identify all interfaces of a zone by drawing a closed loop on their network diagram, engulfing some routers and passing through some routers to include only some of their interfaces.” Hence, it is imperative that the network has documented their multicast topology and thereby knows which interfaces are enabled for multicast.  Once, this is done, the zones can be scoped as required.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30578",
+      "title": "The administrator must ensure that a PIM neighbor filter is bound to all interfaces that have PIM enabled.",
+      "description": "Protocol Independent Multicast (PIM) is a routing protocol used to build multicast distribution tress for forwarding multicast traffic across the network infrastructure. 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3058",
+      "title": "Unauthorized accounts must not be configured for access to the network device.",
+      "description": "A malicious user attempting to gain access to the network device may compromise an account that may be unauthorized for use.  The unauthorized account may be a temporary or inactive account that is no longer needed to access the device.  Denial of Service, interception of sensitive information, or other destructive actions could potentially take place if an unauthorized account is configured to access the network device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30617",
+      "title": "Network devices must have a maximum hop limit of at least 32.",
+      "description": "The Neighbor Discovery protocol allows a hop limit value to be advertised by routers in a Router Advertisement message to be used by hosts instead of the standardized default value. If a very small value was configured and advertised to hosts on the LAN segment, communications would fail due to hop limit reaching zero before the packets sent by a host reached its destination.",
+      "severity": "low"
+    },
+    {
+      "id": "V-3062",
+      "title": "Network devices must be configured to ensure passwords are not viewable when displaying configuration information.",
+      "description": "Many attacks on information systems and network devices are launched from within the network. Hence, it is imperative that all passwords are encrypted so they cannot be intercepted by viewing the console or printout of the configuration.",
+      "severity": "high"
+    },
+    {
+      "id": "V-30660",
+      "title": "The administrator must ensure the 6-to-4 router is configured to drop any IPv4 packets with protocol 41 received from the internal network. ",
+      "description": "The 6to4 specific filters accomplish the role of endpoint verification and provide assurance that the tunnels are being used properly. This primary guidance assumes that only the designated 6to4 router is allowed to form tunnel packets. If they are being formed inside an enclave and passed to the 6to4 router, they are suspicious and must be dropped. In accordance with DoD IPv6 IA Guidance for MO3 (S5-C7-8), packets as such must be dropped and logged as a security event.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3069",
+      "title": "Management connections to a network device must be established using secure protocols with FIPS 140-2 validated cryptographic modules.",
+      "description": "Administration and management connections performed across a network are inherently dangerous because anyone with a packet sniffer and access to the right LAN segment can acquire the network device account and password information.  With this intercepted information they could gain access to the router and cause denial of service attacks, intercept sensitive information, or perform other destructive actions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3070",
+      "title": "Network devices must log all attempts to establish a management connection for administrative access.",
+      "description": "Audit logs are necessary to provide a trail of evidence in case the network is compromised.  Without an audit trail that provides a when, where, who and how set of information, repeat offenders could continue attacks against the network indefinitely.  With this information, the network administrator can devise ways to block the attack and possibly identify and prosecute the attacker.",
+      "severity": "low"
+    },
+    {
+      "id": "V-3072",
+      "title": "The running configuration must be synchronized with the startup configuration after changes have been made and implemented.",
+      "description": "If the running and startup router configurations are not synchronized properly and a router malfunctions, it will not restart with all of the recent changes incorporated.  If the recent changes were security related, then the routers would be vulnerable to attack.",
+      "severity": "low"
+    },
+    {
+      "id": "V-30736",
+      "title": "The administrator must ensure the 6-to-4 router is configured to drop any outbound IPv6 packets from the internal network with a source address that is not within the 6to4 prefix 2002:V4ADDR::/48 where V4ADDR is the designated IPv4 6to4 address for the enclave.",
+      "description": "An automatic 6to4 tunnel allows isolated IPv6 domains to be connected over an IPv4 network and allows connections to remote IPv6 networks. The key difference between this deployment and manually configured tunnels is that the routers are not configured in pairs and thus do not require manual configuration because they treat the IPv4 infrastructure as a virtual non-broadcast link, using an IPv4 address embedded in the IPv6 address to find the remote end of the tunnel. In other words, the tunnel destination is determined by the IPv4 address of the external interface of the 6to4 router that is concatenated to the 2002::/16 prefix in the format 2002: V4ADDR::/48.  Hence, the imbedded V4ADDR of the 6to4 prefix must belong to the same ipv4 prefix as configured on the external-facing interface of the 6to4 router. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-30744",
+      "title": "L2TPv3 sessions must be authenticated prior to transporting traffic.",
+      "description": "L2TPv3 sessions can be used to transport layer-2 protocols across an IP backbone. These protocols were intended for link-local scope only and are therefore less defended and not as well-known. As stated in DoD IPv6 IA Guidance for MO3 (S4-C7-1), the L2TP tunnels can also carry IP packets that are very difficult to filter because of the additional encapsulation. Hence, it is imperative that L2TP sessions are authenticated prior to transporting traffic.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3079",
+      "title": "Network devices must have the Finger service disabled.",
+      "description": "The Finger service supports the UNIX Finger protocol, which is used for querying a host about the users that are logged on. This service is not necessary for generic users. If an attacker were to find out who is using the network, they may use social engineering practices to try to elicit classified DoD information.",
+      "severity": "low"
+    },
+    {
+      "id": "V-3081",
+      "title": "IP source routing must be disabled.",
+      "description": "Source routing is a feature of IP, whereby individual packets can specify routes. This feature is used in several different network attacks by bypassing perimeter and internal defense mechanisms.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3085",
+      "title": "Network devices must have HTTP service for administrative access disabled.",
+      "description": "The additional services the router is enabled for increases the risk for an attack since the router will listen for these services. In addition, these services provide an unsecured method for an attacker to gain access to the router. Most recent software versions support remote configuration and monitoring using the World Wide Web's HTTP protocol. In general, HTTP access is equivalent to interactive access to the router. The authentication protocol used for HTTP is equivalent to sending a clear-text password across the network, and, unfortunately, there is no effective provision in HTTP for challenge-based or one-time passwords. This makes HTTP a relatively risky choice for use across the public Internet. Any additional services that are enabled increase the risk for an attack since the router will listen for these services. The HTTPS server may be enabled for administrative access.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-31285",
+      "title": "Network devices must authenticate all BGP peers within the same or between autonomous systems (AS).",
+      "description": "As specified in RFC 793, TCP utilizes sequence checking to ensure proper ordering of received packets. RFC 793 also specifies that RST (reset) control flags should be processed immediately, without waiting for out of sequence packets to arrive. RFC 793 also requires that sequence numbers are checked against the window size before accepting data or control flags as valid. A router receiving an RST segment will close the TCP session with the BGP peer that is being spoofed; thereby, purging all routes learned from that BGP neighbor. A RST segment is valid as long as the sequence number is within the window. The TCP reset attack is made possible due to the requirements that Reset flags should be processed immediately and that a TCP endpoint must accept out of order packets that are within the range of a window size. This reduces the number of sequence number guesses the attack must make by a factor equivalent to the active window size. Each sequence number guess made by the attacker can be simply incremented by the receiving connections window size. The BGP peering session can protect itself against such an attack by authenticating each TCP segment. The TCP header options include an MD5 signature in every packet and are checked prior to the acceptance and processing of any TCP packet--including RST flags.\n\nOne way to create havoc in a network is to advertise bogus routes to a network. A rogue router could send a fictitious routing update to convince a BGP router to send traffic to an incorrect or rogue destination. This diverted traffic could be analyzed to learn confidential information of the site's network, or merely used to disrupt the network's ability to effectively communicate with other networks. An autonomous system can advertise incorrect information by sending BGP updates messages to routers in a neighboring AS. A malicious AS can advertise a prefix originated from another AS and claim that it is the originator (prefix hijacking). Neighboring autonomous systems receiving this announcement will believe that the malicious AS is the prefix owner and route packets to it.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3143",
+      "title": "Network devices must not have any default manufacturer passwords.",
+      "description": "Network devices not protected with strong password schemes provide the opportunity for anyone to crack the password thus gaining access to the device and causing network outage or denial of service. Many default vendor passwords are well-known; hence, not removing them prior to deploying the network devices into production provides an opportunity for a malicious user to gain unauthorized access to the device.",
+      "severity": "high"
+    },
+    {
+      "id": "V-3160",
+      "title": "Network devices must be running a current and supported operating system with all IAVMs addressed.",
+      "description": "Network devices not running the latest tested and approved versions of software are vulnerable to network attacks. Running the most current, approved version of system and device software helps the site maintain a stable base of security fixes and patches, as well as enhancements to IP security. Viruses, denial of service attacks, system weaknesses, back doors and other potentially harmful situations could render a system vulnerable, allowing unauthorized access to DoD assets.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3175",
+      "title": "The network device must require authentication prior to establishing a management connection for administrative access.",
+      "description": "Network devices with no password for administrative access via a management connection provide the opportunity for anyone with network access to the device to make configuration changes enabling them to disrupt network operations resulting in a network outage.",
+      "severity": "high"
+    },
+    {
+      "id": "V-3196",
+      "title": "The network device must use SNMP Version 3 Security Model with FIPS 140-2 validated cryptography for any SNMP agent configured on the device.",
+      "description": "SNMP Versions 1 and 2 are not considered secure. Without the strong authentication and privacy that is provided by the SNMP Version 3 User-based Security Model (USM), an unauthorized user can gain access to network management information used to launch an attack against the network.",
+      "severity": "high"
+    },
+    {
+      "id": "V-3210",
+      "title": "The network device must not use the default or well-known SNMP community strings public and private.",
+      "description": "Network devices may be distributed by the vendor pre-configured with an SNMP agent using the well-known SNMP community strings public for read only and private for read and write authorization. An attacker can obtain information about a network device using the read community string \"public\". In addition, an attacker can change a system configuration using the write community string \"private\".",
+      "severity": "high"
+    },
+    {
+      "id": "V-3966",
+      "title": "In the event the authentication server is unavailable, the network device must have a single local account of last resort defined.",
+      "description": "Authentication for administrative access to the device is required at all times. A single account of last resort can be created on the device's local database for use in an emergency such as when the authentication server is down or connectivity between the device and the authentication server is not operable. The console or local account of last resort logon credentials must be stored in a sealed envelope and kept in a safe.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3967",
+      "title": "The network devices must time out access to the console port at 10 minutes or less of inactivity.",
+      "description": "Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition quickly terminating an idle session will also free up resources committed by the managed network device. Setting the timeout of the session to 10 minutes or less increases the level of protection afforded critical network components.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3969",
+      "title": "Network devices must only allow SNMP read-only access.",
+      "description": "Enabling write access to the device via SNMP provides a mechanism that can be exploited by an attacker to set configuration variables that can disrupt network operations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3971",
+      "title": "VLAN 1 must not be used for user VLANs.",
+      "description": "In a VLAN-based network, switches use VLAN 1 as the default VLAN for in-band management and to communicate with other networking devices using Spanning-Tree Protocol (STP), Cisco Discovery Protocol (CDP), Dynamic Trunking Protocol (DTP), VLAN Trunking Protocol (VTP), and Port Aggregation Protocol (PAgP)--all untagged traffic. As a consequence, VLAN 1 may unwisely span the entire network if not appropriately pruned. If its scope is large enough, the risk of compromise can increase significantly.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-3972",
+      "title": "VLAN 1 must be pruned from all trunk and access ports that do not require it.",
+      "description": "VLAN 1 is a special VLAN that tags and handles most of the control plane traffic such as Spanning-Tree Protocol (STP), Cisco Discovery Protocol (CDP), Dynamic Trunking Protocol (DTP), VLAN Trunking Protocol (VTP), and Port Aggregation Protocol (PAgP) all VLAN 1 tagged traffic. VLAN 1 is enabled on all trunks and ports by default. With larger campus networks, care needs to be taken about the diameter of the VLAN 1 STP domain; instability in one part of the network could affect VLAN 1, thereby influencing control-plane stability and therefore STP stability for all other VLANs.",
+      "severity": "low"
+    },
+    {
+      "id": "V-3973",
+      "title": "Disabled switch ports must be placed in an unused VLAN (do not use VLAN1).",
+      "description": "It is possible that a disabled port that is assigned to a user or management VLAN becomes enabled by accident or by an attacker and as a result gains access to that VLAN as a member.",
+      "severity": "low"
+    },
+    {
+      "id": "V-3984",
+      "title": "Access switchports must not be assigned to the native VLAN.",
+      "description": "Double encapsulation can be initiated by an attacker who has access to a switch port belonging to the native VLAN of the trunk port. Knowing the victim's MAC address and with the victim attached to a different switch belonging to the same trunk group, thereby requiring the trunk link and frame tagging, the malicious user can begin the attack by sending frames with two sets of tags. The outer tag that will have the attacker's VLAN ID (probably the well-known and omnipresent VLAN 1) is stripped off by the switch, and the inner tag that will have the victim's VLAN ID is used by the switch as the next hop and sent out the trunk port.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-4582",
+      "title": "The network device must require authentication for console access.",
+      "description": "Network devices with no password for administrative access via the console provide the opportunity for anyone with physical access to the device to make configuration changes enabling them to disrupt network operations resulting in a network outage.",
+      "severity": "high"
+    },
+    {
+      "id": "V-4584",
+      "title": "The network device must log all messages except debugging and send all log data to a syslog server.",
+      "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. Syslog levels 0-6 are the levels required to collect the necessary information to help in the recovery process.",
+      "severity": "low"
+    },
+    {
+      "id": "V-5611",
+      "title": "The network devices must only allow management connections for administrative access from hosts residing in the management network.",
+      "description": "Remote administration is inherently dangerous because anyone with a sniffer and access to the right LAN segment could acquire the device account and password information. With this intercepted information they could gain access to the infrastructure and cause denial of service attacks, intercept sensitive information, or perform other destructive actions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-5612",
+      "title": "The network devices must be configured to timeout after 60 seconds or less for incomplete or broken SSH sessions.",
+      "description": "An attacker may attempt to connect to the device using SSH by guessing the authentication method, encryption algorithm, and keys. Limiting the amount of time allowed for authenticating and negotiating the SSH session reduces the window of opportunity for the malicious user attempting to make a connection to the network device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-5613",
+      "title": "The network device must be configured for a maximum number of unsuccessful SSH logon attempts set at 3 before resetting the interface.",
+      "description": "An attacker may attempt to connect to the device using SSH by guessing the authentication method and authentication key or shared secret. Setting the authentication retry to 3 or less strengthens against a Brute Force attack.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-5622",
+      "title": "The native VLAN must be assigned to a VLAN ID other than the default VLAN for all 802.1q trunk links.",
+      "description": "VLAN hopping can be initiated by an attacker who has access to a switch port belonging to the same VLAN as the native VLAN of the trunk link connecting to another switch in which the victim is connected to. If the attacker knows the victim's MAC address, it can forge a frame with two 802.1q tags and a layer 2 header with the destination address of the victim. Since the frame will ingress the switch from a port belonging to its native VLAN, the trunk port connecting to victim's switch will simply remove the outer tag because native VLAN traffic is to be untagged. The switch will forward the frame unto the trunk link unaware of the inner tag with a VLAN ID for which the victim's switchport is a member of.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-5623",
+      "title": "Port trunking must be disabled on all access ports (do not configure trunk on, desirable, non-negotiate, or auto--only off).",
+      "description": "Double encapsulation can be initiated by an attacker who has access to a switch port belonging to the native VLAN of the trunk port. Knowing the victims MAC address and with the victim attached to a different switch belonging to the same trunk group, thereby requiring the trunk link and frame tagging, the malicious user can begin the attack by sending frames with two sets of tags. The outer tag that will have the attackers VLAN ID (probably the well-known and omnipresent VLAN 1) is stripped off by the switch, and the inner tag that will have the victims VLAN ID is used by the switch as the next hop and sent out the trunk port.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-5624",
+      "title": "The ISSO/NSO will ensure if 802.1x Port Authentication is implemented, re-authentication must occur every 60 minutes.",
+      "description": "Eliminating unauthorized access to the network from inside the enclave is vital to keeping a network secure. Internal access to the private network is enabled by simply connecting a workstation or laptop to a wall plate or access point located in the work area.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-5626",
+      "title": "The switch must be configured to use 802.1x authentication on host facing access switch ports.",
+      "description": "The IEEE 802.1x standard is a client-server based access control and authentication protocol that restricts unauthorized clients from connecting to a local area network through host facing switch ports.  The authentication server authenticates each client connected to to a switch port before making any services available to the client from the LAN.  Unless the client is successfully authenticated, 802.1x access control allows only Extensible Authentication Protocol over LAN (EAPOL) traffic through the port to which the client is connected.  After authentication is successful, normal traffic can pass through the port.  Without the use of 802.1x, a malicious user could use the switch port to connect an unauthorized piece of computer or other network device to inject or steal data from the network without detection.",
+      "severity": "high"
+    },
+    {
+      "id": "V-5628",
+      "title": "A dedicated management VLAN or VLANs must be configured to keep management traffic separate from user data and control plane traffic.",
+      "description": "All ports, including the internal sc0 interface, are configured by default to be members of VLAN 1. In a VLAN-based network, switches use VLAN 1 as the default VLAN for in-band management and to communicate with other networking devices using Spanning-Tree Protocol (STP), Cisco Discovery Protocol (CDP), Dynamic Trunking Protocol (DTP), VLAN Trunking Protocol (VTP), and Port Aggregation Protocol (PAgP) all untagged traffic. As a consequence, VLAN 1 may unwisely span the entire network if not appropriately pruned. If its scope is large enough, the risk of compromise can increase significantly.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-5646",
+      "title": "The network device must drop half-open TCP connections through filtering thresholds or timeout periods.",
+      "description": "A TCP connection consists of a three-way handshake message sequence. A connection request is transmitted by the originator, an acknowledgement is returned from the receiver, and then an acceptance of that acknowledgement is sent by the originator.\n\nAn attacker's goal in this scenario is to cause a denial of service to the network or device by initiating a high volume of TCP packets, then never sending an acknowledgement, leaving connections in a half-opened state. Without the device having a connection or time threshold for these half-opened sessions, the device risks being a victim of a denial of service attack. Setting a TCP timeout threshold will instruct the device to shut down any incomplete connections. Services such as SSH, BGP, SNMP, LDP, etc. are some services that may be prone to these types of denial of service attacks. If the router does not have any BGP connections with BGP neighbors across WAN links, values could be set to even tighter constraints.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-7011",
+      "title": "The auxiliary port must be disabled unless it is connected to a secured modem providing encryption and authentication.",
+      "description": "The use of POTS lines to modems connecting to network devices provides clear text of authentication traffic over commercial circuits that could be captured and used to compromise the network.  Additional war dial attacks on the device could degrade the device and the production network.\n\nSecured modem devices must be able to authenticate users and must negotiate a key exchange before full encryption takes place.  The modem will provide full encryption capability (Triple DES) or stronger.  The technician who manages these devices will be authenticated using a key fob and granted access to the appropriate maintenance port, thus the technician will gain access to the managed device (router, switch, etc.).  The token provides a method of strong (two-factor) user authentication.  The token works in conjunction with a server to generate one-time user passwords that will change values at second intervals.  The user must know a personal identification number (PIN) and possess the token to be allowed access to the device.",
+      "severity": "low"
+    }
+  ]
+}