kriterion 0.0.1

data/standards/stig_intrusion_detection_and_prevention_systems_idps_security_requirements_guide.json

@@ -0,0 +1,371 @@
+{
+  "name": "stig_intrusion_detection_and_prevention_systems_idps_security_requirements_guide",
+  "date": "2017-07-07",
+  "description": "The IDPS Security Requirements Guide (SRG) is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the NIST 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.letterkenny.FSO.mbx.stig-customer-support-mailbox@mail.mil.",
+  "title": "Intrusion Detection and Prevention Systems (IDPS) Security Requirements Guide",
+  "version": "2",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-34484",
+      "title": "The IDPS must enforce approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic within the network as defined in the PPSM CAL and vulnerability assessments.",
+      "description": "The flow of all communications traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data.\n\nRestricting the flow of communications traffic, also known as Information flow control, regulates where information is allowed to travel as opposed to who is allowed to access the information and without explicit regard to subsequent accesses to that information.\n\nThe IDPS will include policy filters, rules, signatures, and behavior analysis algorithms that inspects and restricts traffic based on the characteristics of the information and/or the information path as it crosses internal network boundaries. The IDPS monitors for harmful or suspicious information flows and restricts or blocks this traffic based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34485",
+      "title": "The IDPS must restrict or block harmful or suspicious communications traffic between interconnected networks based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.",
+      "description": "The IDPS enforces approved authorizations by controlling the flow of information between interconnected networks to prevent harmful or suspicious traffic does spread to these interconnected networks.\n\nInformation flow control policies and restrictions govern where information is allowed to travel as opposed to who is allowed to access the information. The IDPS includes policy filters, rules, signatures, and behavior analysis algorithms that inspects and restricts traffic based on the characteristics of the information and/or the information path as it crosses external/perimeter boundaries. IDPS components are installed and configured such that they restrict or block detected harmful or suspect information flows based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34540",
+      "title": "The IDPS must produce audit records containing sufficient information to establish what type of event occurred, including, at a minimum, event descriptions, policy filter, rule or signature invoked, port, protocol, and criticality level/alert code or description.",
+      "description": "Without establishing what type of event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Associating an event type with each event log entry provides a means of investigating an attack or identifying an improperly configured IDPS.\n\nWhile auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34541",
+      "title": "The IDPS must produce audit records containing information to establish when (date and time) the events occurred.",
+      "description": "Without establishing the time (date/time) an event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Associating the date and time the event occurred with each event log entry provides a means of investigating an attack or identifying an improperly configured IDPS. \n\nWhile auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34542",
+      "title": "The IDPS must produce audit records containing information to establish where the event was detected, including, at a minimum, network segment, destination address, and IDPS component which detected the event.",
+      "description": "Associating where the event was detected with the event log entries provides a means of investigating an attack or identifying an improperly configured IDPS. This information can be used to determine what systems may have been affected.\n\nWhile auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34543",
+      "title": "The IDPS must produce audit records containing information to establish the source of the event, including, at a minimum, originating source address.",
+      "description": "Associating the source of the event with detected events in the logs provides a means of investigating an attack or suspected attack.\n\nWhile auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34544",
+      "title": "The IDPS must produce audit records containing information to establish the outcome of events associated with detected harmful or potentially harmful traffic, including, at a minimum, capturing all associated communications traffic.",
+      "description": "Associating event outcome with detected events in the log provides a means of investigating an attack or suspected attack.\n\nWhile auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.\n\nThe logs should identify what servers, destination addresses, applications, or databases were potentially attacked by logging communications traffic between the target and the attacker. All commands that were entered by the attacker (such as account creations, changes in permissions, files accessed, etc.) during the session should also be logged.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34555",
+      "title": "In the event of a logging failure caused by the lack of audit record storage capacity, the IDPS must continue generating and storing audit records if possible, overwriting the oldest audit records in a first-in-first-out manner.",
+      "description": "It is critical that when the IDPS is at risk of failing to process audit logs as required, it takes action to mitigate the failure.\n\nThe IDPS performs a critical security function, so its continued operation is imperative. Since availability of the IDPS is an overriding concern, shutting down the system in the event of an audit failure should be avoided, except as a last resort.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34594",
+      "title": "The IDPS must provide audit record generation capability for events where communication traffic is blocked or restricted based on policy filters, rules, signatures, and anomaly analysis.",
+      "description": "Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nWhile auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.\n\nThe IDPS must have the capability to capture and log events where communications traffic was blocked or restricted because of a security violation or potential security violations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34625",
+      "title": "The IDPS must be configured to remove or disable non-essential features, functions, and services of the IDPS application.",
+      "description": "An IDPS can be capable of providing a wide variety of capabilities. Not all of these capabilities are necessary. Unnecessary services, functions, and applications increase the attack surface (sum of attack vectors) of a system. These unnecessary capabilities are often overlooked and therefore may remain unsecured.\n\nThis requirement applies to unnecessary features of the IDPS application itself.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34707",
+      "title": "The IDPS must block outbound traffic containing known and unknown DoS attacks by ensuring that security policies, signatures, rules, and anomaly detection techniques are applied to outbound communications traffic.",
+      "description": "The IDPS must include protection against DoS attacks that originate from inside the enclave which can affect either internal or external systems. These attacks may use legitimate or rogue endpoints from inside the enclave. \n\nInstallation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type.\n\nTo comply with this requirement, the IDPS must inspect outbound traffic for indications of known and unknown DoS attacks. Sensor log capacity management along with techniques which prevent the logging of redundant information during an attack also guard against DoS attacks. This requirement is used in conjunction with other requirements which require configuration of security policies, signatures, rules, and anomaly detection techniques and are applicable to both inbound and outbound traffic.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34743",
+      "title": "The IDPS must block any prohibited mobile code at the enclave boundary when it is detected.",
+      "description": "Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations, Shockwave videos, and macros embedded within Microsoft Office documents. Mobile code can be exploited to attack a host. It can be sent as an e-mail attachment or embedded in other file formats not traditionally associated with executable code. \n\nWhile the IDPS cannot replace the anti-virus and host-based IDS (HIDS) protection installed on the network's endpoints, vendor or locally created sensor rules can be implemented, which provide preemptive defense against both known and zero-day vulnerabilities. Many of the protections may provide defenses before vulnerabilities are discovered and rules or blacklist updates are distributed by anti-virus or malicious code solution vendors.\n\nTo block known prohibited mobile code or approved mobile code that violates permitted usage requirements, the IDPS must implement policy filters, rules, signatures, and anomaly analysis.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34749",
+      "title": "The IDPS must fail to a secure state which maintains access control mechanisms when the IDPS hardware, software, or firmware fails on initialization/shutdown or experiences a sudden abort during normal operation. ",
+      "description": "Failure to a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. Preserving information system state information also facilitates system restart and return to the operational mode of the organization with less disruption to mission-essential processes. \n\nThis requirement applies to the device itself, not the network traffic. Abort refers to stopping a program or function before it has finished naturally. The term abort refers to both requested and unexpected terminations. \n\nSince it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34750",
+      "title": "In the event of a failure of the IDPS function, the IDPS must save diagnostic information, log system messages, and load the most current security policies, rules, and signatures when restarted.",
+      "description": "Failure in a secure state address safety or security in accordance with the mission needs of the organization. Failure to a 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 state information helps to facilitate the restart of the IDPS application and a return to operation with minimum disruption.\n\nThis requirement applies to a failure of the IDPS function rather than the device or operating system as a whole which is addressed in the Network Device Management SRG.\n\nSince it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34759",
+      "title": "The IDPS must verify the integrity of updates obtained directly from the vendor.",
+      "description": "If the integrity of updates downloaded directly from the vendor is not verified, then malicious code or errors may impact the ability of the IDPS to protect against harmful communication traffic. \n\nThe recommended verification method depends on the update's format, as follows: \n\n1. For files downloaded from a Web site or FTP site, administrators should compare file checksums provided by the vendor with checksums that they compute for the downloaded files. \n\n2. For updates downloaded automatically through the IDPS user interface, if an update is downloaded as a single file or a set of files, either checksum provided by the vendor should be compared to checksums generated by the administrator, or the IDPS user interface itself should perform some sort of integrity check. In some cases, updates are downloaded and installed as one action, precluding checksum verification. In this case, the IDPS user interface should check each update'\ns integrity as part of this process. \n\n3. In the case of removable media (e.g., CD, DVD), vendors may not provide a specific method for customers to verify the legitimacy of removable media apparently sent by the vendors. If media verification is a concern, administrators should contact their vendors to determine how the media can be verified, such as comparing vendor-provided checksums to checksums computed for files on the media, or verifying digital signatures on the media's contents to ensure they are valid. Administrators should also consider scanning the media for malware, with the caveat that false positives may be triggered by IDPS signatures for malware on the media.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34762",
+      "title": "The IDPS must block malicious code.",
+      "description": "Configuring the IDPS to delete and/or quarantine based on local organizational incident handling procedures minimizes the impact of this code on the network.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-34788",
+      "title": "The IDPS must block outbound ICMP Destination Unreachable, Redirect, and Address Mask reply messages.",
+      "description": "Internet Control Message Protocol (ICMP) messages are used to provide feedback about problems in the network. These messages are sent back to the sender to support diagnostics. However, some messages can also provide host information and network topology that may be exploited by an attacker.\n\nAn IDPS must be configured to \"silently drop\" the packet and not send an ICMP control message back to the source. In some cases, it may be necessary to direct the traffic to a null interface.\n\nThree ICMP messages are commonly used by attackers for network mapping: Destination Unreachable, Redirect, and Address Mask Reply.\n\nThese responses must be blocked on external interfaces; however, blocking the Destination Unreachable response will prevent Path Maximum Transmission Unit Discovery (PMTUD), which relies on the response \"ICMP Destination Unreachable--Fragmentation Needed but DF Bit Set\". PMTUD is a useful function and should only be \"broken\" after careful consideration.\n\nAn acceptable alternative to blocking all Destination Unreachable responses is to filter Destination Unreachable messages generated by the IDPS to allow ICMP Destination Unreachable--Fragmentation Needed but DF Bit Set (Type 3, Code 4) and apply this filter to the external interfaces.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55317",
+      "title": "The IDPS must immediately use updates made to policy filters, rules, signatures, and anomaly analysis algorithms for traffic detection and prevention functions.",
+      "description": "Information flow policies regarding dynamic information flow control include, for example, allowing or disallowing information flows based on changes to the PPSM CAL, vulnerability assessments, or mission conditions. Changing conditions include changes in the threat environment and detection of potentially harmful or adverse events.\n\nChanges to the IDPS must take effect when made by an authorized administrator and the new configuration is put in place or committed, including upon restart or the application or reboot of the system. With some devices, the changes take effect as the configuration is changed, while with others, the new configuration must be submitted to the device. In any case, the behavior of the IDPS must immediately be affected to reflect the configuration change.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55319",
+      "title": "The IDPS must provide audit record generation capability for detection events based on implementation of policy filters, rules, signatures, and anomaly analysis.",
+      "description": "Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nWhile auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.\n\nThe IDPS must have the capability to capture and log detected security violations and potential security violations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55321",
+      "title": "The IDPS must provide audit record generation with a configurable severity and escalation level capability.",
+      "description": "Without the capability to generate audit records with a severity code it is difficult to track and handle detection events.\n\nWhile auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.\n\nThe IDPS must have the capability to collect and log the severity associated with the policy, rule, or signature. IDPS products often have either pre-configured and/or a configurable method for associating an impact indicator or severity code with signatures and rules, at a minimum.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55323",
+      "title": "IDPS must support centralized management and configuration of the content captured in audit records generated by all IDPS components.",
+      "description": "Without the ability to centrally manage the content captured in the log records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an attack. Centralized management and storage of log records increases efficiency in maintenance and management of records as well as facilitates the backup and archiving of those records.\n\nThe IDPS must be configured to support centralized management and configuration of the content to be captured in audit records generated by all network components. IDPS sensors and consoles must have the capability to support centralized logging. They must be configured to send log messages to centralized, redundant servers and be capable of being remotely configured to change logging parameters (such as facility and severity levels).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55325",
+      "title": "The IDPS must off-load log records to a centralized log server.",
+      "description": "Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading ensures audit information does not get overwritten if the limited audit storage capacity is reached and also protects the audit record in case the system/component being audited is compromised.\n\nThis also prevents the log records from being lost if the logs stored locally are accidentally or intentionally deleted, altered, or corrupted.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55327",
+      "title": "The IDPS must off-load log records to a centralized log server in real-time.",
+      "description": "Off-loading ensures audit information does not get overwritten if the limited audit storage capacity is reached and also protects the audit record in case the system/component being audited is compromised.\n\nOff-loading is a common process in information systems with limited audit storage capacity. The audit storage on the IDPS is used only in a transitory fashion until the system can communicate with the centralized log server designated for storing the audit records, at which point the information is transferred. However, DoD requires that the log be transferred in real-time which indicates that the time from event detection to off-loading is seconds or less.\n\nThis does not apply to audit logs generated on behalf of the device itself (management).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55329",
+      "title": "The IDPS must assign a critical severity level to all audit processing failures.",
+      "description": "It is critical that when the IDPS is at risk of failing to process audit logs as required, it takes action to mitigate the failure\n\nAudit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Since action must be taken immediately, these messages will be designated as a critical severity level and this level must be sent as part of the alert message.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55331",
+      "title": "The IDPS must provide an alert within less than a second to, at a minimum, the SCA and ISSO when any audit failure events occur.",
+      "description": "Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis may be impeded.\n\nThis requirement includes, but is not limited to, failures where the detection and/or prevention function is unable to write events to either local storage or the centralized server. The IDPS must generate an alert which will notify designated personnel of the logging failure. Alerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less). Alert messages must include the severity level.\n\nThe IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSO.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55333",
+      "title": "In the event of a logging failure, caused by loss of communications with the central logging server, the IDPS must queue audit records locally until communication is restored or until the audit records are retrieved manually or using automated synchronization tools.",
+      "description": "It is critical that when the IDPS is at risk of failing to process audit logs as required, it take action to mitigate the failure.\n\nAudit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure.\n\nThe IDPS performs a critical security function, so its continued operation is imperative. Since availability of the IDPS is an overriding concern, shutting down the system in the event of an audit failure should be avoided, except as a last resort. The SYSLOG protocol does not support automated synchronization, however this functionality may be provided by Network Management Systems (NMSs) which are not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55335",
+      "title": "The IDPS must provide log information in a format that can be extracted and used by centralized analysis tools.",
+      "description": "Centralized review and analysis of log records from multiple IDPS components gives the organization the capability to better detect distributed attacks and provides increased data points for behavior analysis techniques. These techniques are invaluable in monitoring for indicators of complex attack patterns. \n\nTo support the centralized analysis capability, the IDPS components must be able to provide the information in a format (e.g., Syslog) that can be extracted and used, allowing the application to effectively review and analyze the log records.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55337",
+      "title": "The IDPS must be configured in accordance with the security configuration settings based on DoD security policy and technology-specific security best practices.",
+      "description": "Configuring the IDPS to implement 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.\n\nConfiguration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the network element. Security-related parameters are those parameters impacting the security state of the network element, including the parameters required to satisfy other security control requirements. For the network element, security-related parameters include settings for communications traffic management configurations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55339",
+      "title": "The IDPS must be configured to remove or disable non-essential capabilities which are not required for operation or not related to IDPS functionality (e.g., DNS, email client or server, FTP server, or web server).",
+      "description": "An IDPS can be capable of providing a wide variety of capabilities. Not all of these capabilities are necessary. Unnecessary services, functions, and applications increase the attack surface (sum of attack vectors) of a system. These unnecessary capabilities are often overlooked and therefore may remain unsecured.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55341",
+      "title": "The IDPS must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments.",
+      "description": "Some ports, protocols, or services have known exploits or security weaknesses. These ports, protocols, and services must be prohibited or restricted in the IDPS configuration in accordance with DoD policy. \n\nPolicy filters restrict traffic destined to the enclave perimeter in accordance with the guidelines contained in DoD Instruction 8551.1 for all ports, protocols, and functions.\n\nSCAs will review the vulnerability assessment for each port allowed into the enclave and apply all appropriate mitigations defined in the Vulnerability Assessment report. Only ports, protocols, and functions allowed into the enclave should be registered in the PPSM database. It is the responsibility of the enclave owner to have the applications the enclave uses registered in the PPSM database.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55343",
+      "title": "The IDPS must detect, at a minimum, mobile code that is unsigned or exhibiting unusual behavior, has not undergone a risk assessment, or is prohibited for use based on a risk assessment.",
+      "description": "Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations, Shockwave videos, and macros embedded within Microsoft Office documents. Mobile code can be exploited to attack a host. It can be sent as an e-mail attachment or embedded in other file formats not traditionally associated with executable code. \n\nWhile the IDPS cannot replace the anti-virus and host-based IDS (HIDS) protection installed on the network's endpoints, vendor or locally created sensor rules can be implemented, which provide preemptive defense against both known and zero-day vulnerabilities. Many of the protections may provide defenses before vulnerabilities are discovered and rules or blacklist updates are distributed by anti-virus or malicious code solution vendors.\n\nTo monitor for and detect known prohibited mobile code or approved mobile code that violates permitted usage requirements, the IDPS must implement policy filters, rules, signatures, and anomaly analysis.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55345",
+      "title": "The IDPS must protect against or limit the effects of known and unknown types of Denial of Service (DoS) attacks by employing rate-based attack prevention behavior analysis.",
+      "description": "If the network does not provide safeguards against DoS attack, network resources will be unavailable to users.\n\nInstallation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type.\n\nDetection components that use rate-based behavior analysis can detect attacks when signatures for the attack do not exist or are not installed. These attacks include zero-day attacks which are new attacks for which vendors have not yet developed signatures. Rate-based behavior analysis can detect sophisticated, Distributed DoS (DDoS) attacks by correlating traffic information from multiple network segments or components.\n\nThis requirement applies to the communications traffic functionality of the IDPS as it pertains to handling communications traffic, rather than to the IDPS device itself.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55347",
+      "title": "The IDPS must protect against or limit the effects of known and unknown types of Denial of Service (DoS) attacks by employing anomaly-based attack detection.",
+      "description": "If the network does not provide safeguards against DoS attack, network resources will be unavailable to users.\n\nInstallation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks.\n\nDetection components that use anomaly-based attack detection can detect attacks when signatures for the attack do not exist or are not installed. These attacks include zero-day attacks which are new attacks for which vendors have not yet developed signatures.\n\nThis requirement applies to the communications traffic functionality of the IDPS as it pertains to handling communications traffic, rather than to the IDPS device itself.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55349",
+      "title": "The IDPS must protect against or limit the effects of known types of Denial of Service (DoS) attacks by employing signatures.",
+      "description": "If the network does not provide safeguards against DoS attack, network resources will be unavailable to users. \n\nInstallation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume, type, or protocol usage.\n\nDetection components that use signatures can detect known attacks by using known attack signatures. Signatures are usually obtained from and updated by the IDPS component vendor. These attacks include SYN-flood, ICMP-flood, and Land Attacks.\n\nThis requirement applies to the communications traffic functionality of the IDPS as it pertains to handling communications traffic, rather than to the IDPS device itself.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55351",
+      "title": "The IDPS must, for fragmented packets, either block the packets or properly reassemble the packets before inspecting and forwarding.",
+      "description": "Packet fragmentation is allowed by the TCP/IP specifications and is encouraged in situations where it is needed. However, packet fragmentation has been used to make some attacks harder to detect (by placing them within fragmented packets), and unusual fragmentation has also been used as a form of attack. For example, some network-based attacks have used packets that should not exist in normal communications, such as sending some fragments of a packet but not the first fragment, or sending packet fragments that overlap each other. These, and other types of packet fragmentation, aim to evade the IDPS. \n\nSince it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55355",
+      "title": "The IDPS must block malicious ICMP packets by properly configuring ICMP signatures and rules.",
+      "description": "Internet Control Message Protocol (ICMP) messages are used to provide feedback about problems in the network. These messages are sent back to the sender to support diagnostics. However, some messages can also provide host information, network topology, and a covert channel that may be exploited by an attacker.\n\nGiven the prevalence of ICMP traffic on the network, monitoring for malicious ICMP traffic would be cumbersome. Vendors provide signatures and rules which filter for known ICMP traffic exploits.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55357",
+      "title": "The IDPS must install updates for application software files, signature definitions, detection heuristics, and vendor-provided rules when new releases are available in accordance with organizational configuration management policy and procedures.",
+      "description": "Failing to update malicious code protection mechanisms, including application software files, signature definitions, and vendor-provided rules, leaves the system vulnerable to exploitation by recently developed attack methods and programs. \n\nThe IDPS is a key malicious code protection mechanism in the enclave infrastructure. To ensure this protection is responsive to changes in malicious code threats, IDPS components must be updated, including application software files, anti-virus signatures, detection heuristics, vendor-provided rules, and vendor-provided signatures.\n\nUpdates must be installed in accordance with the CCB procedures for the local organization. However, at a minimum: \n\n1. Updates designated as critical security updates by the vendor must be installed immediately.\n\n2. Updates for signature definitions, detection heuristics, and vendor-provided rules must be installed immediately.\n\n3. Updates for application software are installed in accordance with the CCB procedures.\n\n4. Prior to automatically installing updates, either manual or automated integrity and authentication checking is required, at a minimum, for application software updates.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55359",
+      "title": "The IDPS must perform real-time monitoring of files from external sources at network entry/exit points.",
+      "description": "Real-time monitoring of files from external sources at network entry/exit points helps to detect covert malicious code before it is downloaded to or executed by internal and external endpoints. Using malicious code, such as viruses, worms, Trojan horses, and spyware, an attacker may gain access to sensitive data and systems.\n\nIDPSs innately meet this requirement for real-time scanning for malicious code when properly configured to meet the requirements of this SRG. However, most products perform communications traffic inspection at the packet level.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55361",
+      "title": "The IDPS must quarantine and/or delete malicious code.",
+      "description": "Configuring the network element to delete and/or quarantine based on local organizational incident handling procedures minimizes the impact of this code on the network.\n\nMalicious code includes, but is not limited to, viruses, worms, Trojan horses, and spyware. The code provides the ability for a malicious user to read from and write to files and folders on a computer's hard drive. Malicious code may also be able to run and attach programs, which may allow the unauthorized distribution of malicious mobile code.\n\nSometimes it is necessary to generate a log event and then automatically delete the malicious code; however, for critical attacks or where forensic evidence is deemed necessary, the preferred action is for the file to be quarantined for further investigation.\n\nThis requirement is limited to network elements that perform security functions, such as ALG and IDPS.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55363",
+      "title": "The IDPS must send an immediate (within seconds) alert to, at a minimum, the SCA when malicious code is detected.",
+      "description": "Without an alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis and detect rate-based and other anomalies will be impeded.\n\nThe IDPS generates an immediate (within seconds) alert which notifies designated personnel of the incident. Sending a message to an unattended log or console does not meet this requirement since that will not be seen immediately. These messages should include a severity level indicator or code as an indicator of the criticality of the incident.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55365",
+      "title": "IDPS components, including sensors, event databases, and management consoles must integrate with a network-wide monitoring capability.",
+      "description": "An integrated, network-wide intrusion detection capability increases the ability to detect and prevent sophisticated distributed attacks based on access patterns and characteristics of access.\n\nIntegration is more than centralized logging and a centralized management console. The enclave's monitoring capability may include multiple sensors, IPS, sensor event databases, behavior-based monitoring devices, application-level content inspection systems, malicious code protection software, scanning tools, audit record monitoring software, and network monitoring software. Some tools may monitor external traffic while others monitor internal traffic at key boundaries. \n\nThese capabilities may be implemented using different devices and therefore can have different security policies and severity-level schema. This is valuable because content filtering, monitoring, and prevention can become a bottleneck on the network if not carefully configured.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55375",
+      "title": "The IDPS must detect network services that have not been authorized or approved by the ISSO or ISSM, at a minimum.",
+      "description": "Unauthorized or unapproved network services lack organizational verification or validation and therefore may be unreliable or serve as malicious rogues for valid services. \n\nExamples of network services include service-oriented architectures (SOAs), cloud-based services (e.g., infrastructure as a service, platform as a service, or software as a service), cross-domain, Voice Over Internet Protocol, Instant Messaging, auto-execute, and file sharing.\n\nTo comply with this requirement, the IDPS may be configured to detect services either directly or indirectly (i.e., by detecting traffic associated with a service).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55377",
+      "title": "The IDPS must generate a log record when unauthorized network services are detected.",
+      "description": "Unauthorized or unapproved network services lack organizational verification or validation and therefore may be unreliable or serve as malicious rogues for valid services. \n\nExamples of network services include service-oriented architectures (SOAs), cloud-based services (e.g., infrastructure as a service, platform as a service, or software as a service), cross-domain, Voice Over Internet Protocol, Instant Messaging, auto-execute, and file sharing.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55379",
+      "title": "The IDPS must generate an alert to the ISSM and ISSO, at a minimum, when unauthorized network services are detected.",
+      "description": "Unauthorized or unapproved network services lack organizational verification or validation and therefore may be unreliable or serve as malicious rogues for valid services.\n\nAutomated mechanisms can be used to send automatic alerts or notifications. Such automatic alerts or notifications can be conveyed in a variety of ways (e.g., telephonically, via electronic mail, via text message, or via websites).\n\nThe IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSO to the vulnerability discussion.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55381",
+      "title": "The IDPS must continuously monitor inbound communications traffic for unusual/unauthorized activities or conditions.",
+      "description": "If inbound communications traffic is not continuously monitored for unusual/unauthorized activities or conditions, there will be times when hostile activity may not be noticed and defended against. \n\nAlthough some of the components in the site's content scanning solution may be used for periodic scanning assessment, the IDPS sensors and other components must provide continuous, 24 hours a day, 7 days a week monitoring. \n\nUnusual/unauthorized activities or conditions related to information system inbound communications traffic include, for example, internal traffic that indicates the presence of malicious code within organizational information systems or propagating among system components, the unauthorized exporting of information, or signaling to external information systems. Anomalies within organizational information systems include, for example, large file transfers, long-time persistent connections, use of unusual protocols and ports, and communications with suspected or known malicious external entities.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55383",
+      "title": "The IDPS must continuously monitor outbound communications traffic for unusual/unauthorized activities or conditions.",
+      "description": "If outbound communications traffic is not continuously monitored for unusual/unauthorized activities or conditions, there will be times when hostile activity may not be noticed and defended against. \n\nAlthough some of the components in the site's content scanning solution may be used for periodic scanning assessment, the IDPS sensors and other components must provide continuous, 24 hours a day, 7 days a week monitoring.\n\nUnusual/unauthorized activities or conditions related to information system outbound communications traffic include, for example, internal traffic that indicates the presence of malicious code within organizational information systems or propagating among system components, the unauthorized exporting of information, or signaling to external information systems. Anomalies within organizational information systems include, for example, large file transfers, long-time persistent connections, use of unusual protocols and ports, and communications with suspected or known malicious external entities.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55385",
+      "title": "The IDSP must send an alert to, at a minimum, the ISSM and ISSO when intrusion detection events are detected which indicate a compromise or potential for compromise.",
+      "description": "Without an alert, security personnel may be unaware of intrusion detection incidents that require immediate action and this delay may result in the loss or compromise of information.\n\nIn accordance with CCI-001242, the IDPS is a real-time intrusion detection system. These systems must generate an alert when detection events from real-time monitoring occur. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSM and ISSO.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55387",
+      "title": "The IDPS must send an alert to, at a minimum, the ISSM and ISSO when threats identified by authoritative sources (e.g., IAVMs or CTOs) are detected which indicate a compromise or potential for compromise.",
+      "description": "Without an alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis and detect rate-based and other anomalies will be impeded.\n\nAlerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSM and ISSO.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55389",
+      "title": "The IDPS must generate an alert to, at a minimum, the ISSM and ISSO when root level intrusion events which provide unauthorized privileged access are detected.",
+      "description": "Without an alert, security personnel may be unaware of major detection incidents that require immediate action and this delay may result in the loss or compromise of information.\n\nCJCSM 6510.01B, \"Cyber Incident Handling Program\", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category I, II, IV, and VII detection events) will require an alert when an event is detected.\n\nAlerts messages must include a severity level indicator or code as an indicator of the criticality of the incident. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.\n\nAlerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSM and ISSO.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55391",
+      "title": "The IDPS must send an alert to, at a minimum, the ISSM and ISSO when user level intrusions which provide non-privileged access are detected.",
+      "description": "Without an alert, security personnel may be unaware of major detection incidents that require immediate action and this delay may result in the loss or compromise of information.\n\nCJCSM 6510.01B, \"Cyber Incident Handling Program\", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category I, II, IV, and VII detection events) will require an alert when an event is detected.\n\nAlerts messages must include a severity level indicator or code as an indicator of the criticality of the incident. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.\n\nAlerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSM and ISSO.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55393",
+      "title": "The IDPS must send an alert to, at a minimum, the ISSM and ISSO when denial of service incidents are detected.",
+      "description": "Without an alert, security personnel may be unaware of major detection incidents that require immediate action and this delay may result in the loss or compromise of information.\n\nCJCSM 6510.01B, \"Cyber Incident Handling Program\", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category I, II, IV, and VII detection events) will require an alert when an event is detected.\n\nAlerts messages must include a severity level indicator or code as an indicator of the criticality of the incident. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.\n\nAlerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSM and ISSO.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55395",
+      "title": "The IDPS must generate an alert to, at a minimum, the ISSM and ISSO when new active propagation of malware infecting DoD systems or malicious code adversely affecting the operations and/or security\nof DoD systems is detected.",
+      "description": "Without an alert, security personnel may be unaware of major detection incidents that require immediate action and this delay may result in the loss or compromise of information.\n\nCJCSM 6510.01B, \"Cyber Incident Handling Program\", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category I, II, IV, and VII detection events) will require an alert when an event is detected.\n\nAlerts messages must include a severity level indicator or code as an indicator of the criticality of the incident. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.\n\nAlerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55397",
+      "title": "To protect against unauthorized data mining, the IDPS must prevent code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.",
+      "description": "Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack databases may result in the compromise of information.\n\nInjection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. Web applications frequently access databases to store, retrieve, and update information. An attacker can construct inputs that the database will execute. This is most commonly referred to as a code injection attack. This type of attack includes XPath and LDAP injections. \n\nIDPS component(s) with the capability to prevent code injections must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55399",
+      "title": "To protect against unauthorized data mining, the IDPS must prevent code injection attacks launched against application objects including, at a minimum, application URLs and application code.",
+      "description": "Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack applications may result in the compromise of information.\n\nInjection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. These attacks include buffer overrun, XML, JavaScript, and HTML injections.\n\nIDPS component(s) with the capability to prevent code injections must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55401",
+      "title": "To protect against unauthorized data mining, the IDPS must prevent SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.",
+      "description": "Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack databases may result in the compromise of information.\n\nSQL injection attacks are the most prevalent attacks against web applications and databases. These attacks inject SQL commands that can read, modify, or compromise the meaning of the original SQL query. An attacker can spoof identity; expose, tamper, destroy, or make existing data unavailable; or gain unauthorized privileges on the database server.\n\nIDPS component(s) with the capability to prevent SQL code injections must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for SQL injection attacks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55403",
+      "title": "To protect against unauthorized data mining, the IDPS must detect code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.",
+      "description": "Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack databases may result in the compromise of information.\n\nInjection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. Web applications frequently access databases to store, retrieve, and update information. An attacker can construct inputs that the database will execute. This is most commonly referred to as a code injection attack. This type of attack includes XPath and LDAP injections.\n\nIDPS component(s) with anomaly detection must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55407",
+      "title": "To protect against unauthorized data mining, the IDPS must detect code injection attacks launched against application objects including, at a minimum, application URLs and application code.",
+      "description": "Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack applications may result in the compromise of information.\n\nInjection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. These attacks include buffer overrun, XML, JavaScript, and HTML injections.\n\nIDPS component(s) with anomaly detection must be included in the IDPS implementation. These components must include rules and anomaly detection algorithms to monitor for atypical application behavior, commands, and accesses.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55409",
+      "title": "To protect against unauthorized data mining, the IDPS must detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.",
+      "description": "Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack databases may result in the compromise of information.\n\nSQL injection attacks are the most prevalent attacks against web applications and databases. These attacks inject SQL commands that can read, modify, or compromise the meaning of the original SQL query. An attacker can spoof identity; expose, tamper, destroy, or make existing data unavailable; or gain unauthorized privileges on the database server.\n\nIDPS component(s) with anomaly detection must be included in the IDPS implementation to monitor for and detect unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for SQL injection attacks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55595",
+      "title": "The IDPS must fail securely in the event of an operational failure.",
+      "description": "Since the IDPS is a boundary protection device, if the IDPS fails in an unsecure manner the device may permit unauthorized information release. The operational failure may have been the result of a direct attack on the IDPS device which may be followed by  a DoS attack or unauthorized entry attempt. Without the IDPS to monitor and detect these attacks,  network is at risk.\n\nFail secure is achieved by employing mechanisms to ensure that if the IDPS traffic monitoring and detection functions fail, it does not continue processing while security policies, filters, and signatures are not being applied. \n\nIf the IDPS traffic monitoring and detection functions fail for any reason, the IDPS must stop forwarding traffic altogether or maintain the configured security policies. For this reason, device redundancy rather than a policy of failing open is vital to maintaining network availability while protecting DoD networks.\n\nSince it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-55597",
+      "title": "The IDPS must automatically install updates to signature definitions, detection heuristics, and vendor-provided rules.",
+      "description": "Failing to automatically update malicious code protection mechanisms, including application software files, signature definitions, and vendor-provided rules, leaves the system vulnerable to exploitation by recently developed attack methods and programs. An automatic update process ensures this important task is performed without the need for SCA intervention.\n\nThe IDPS is a key malicious code protection mechanism in the enclave infrastructure. To ensure this protection is responsive to changes in malicious code threats, IDPS components must be automatically updated, including anti-virus signatures, detection heuristics, vendor-provided rules, and vendor-provided signatures.\n\nIf a DoD patch management server or update repository having the tested/verified updates is available for the IDPS component, the components must be configured to automatically check this server/site for updates and install new updates. \n\nIf a DoD server/site is not available, the component must be configured to automatically check a trusted vendor site for updates. A trusted vendor is either commonly used by DoD, specifically approved by DoD, the vendor from which the equipment was purchased, or approved by the local program's CCB.",
+      "severity": "medium"
+    }
+  ]
+}

data/standards/stig_ipsec_vpn_gateway.json

@@ -0,0 +1,521 @@
+{
+  "name": "stig_ipsec_vpn_gateway",
+  "date": "2018-03-08",
+  "description": "IPSec VPN Gateway Security Technical Implementation Guide",
+  "title": "IPSec VPN Gateway Security Technical Implementation Guide",
+  "version": "1",
+  "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-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-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-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-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-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-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-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-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-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-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-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-3078",
+      "title": "Network devices must have TCP and UDP small servers disabled.",
+      "description": "Cisco IOS provides the \"small services\" that include echo, chargen, and discard. These services, especially their User Datagram Protocol (UDP) versions, are infrequently used for legitimate purposes. However, they have been used to launch denial of service attacks that would otherwise be prevented by packet filtering. For example, an attacker might send a DNS packet, falsifying the source address to be a DNS server that would otherwise be unreachable, and falsifying the source port to be the DNS service port (port 53). If such a packet were sent to the Cisco's UDP echo port, the result would be Cisco sending a DNS packet to the server in question. No outgoing access list checks would be applied to this packet, since it would be considered locally generated by the router itself. The small services are disabled by default in Cisco IOS 12.0 and later software. In earlier software, they may be disabled using the commands no service tcp-small-servers and no service udp-small-servers.",
+      "severity": "low"
+    },
+    {
+      "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-3080",
+      "title": "The Configuration auto-loading feature must be disabled when connected to an operational network.",
+      "description": "Devices can find their startup configuration either in their own NVRAM or access it over the network via TFTP or Remote Copy (rcp). Loading the image from the network is taking a security risk since the image could be intercepted by an attacker who could corrupt the image resulting in a denial of service. Configuration auto-loading can be enabled when the device is connected to a non-operational network. Once the device is connected to an operational (i.e. production) network, configuration auto-loading must be disabled.",
+      "severity": "medium"
+    },
+    {
+      "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-3083",
+      "title": "IP directed broadcast must be disabled on all layer 3 interfaces.",
+      "description": "An IP directed broadcast is a datagram sent to the broadcast address of a subnet that is not directly attached to the sending machine. The directed broadcast is routed through the network as a unicast packet until it arrives at the target subnet, where it is converted into a link-layer broadcast. Because of the nature of the IP addressing architecture, only the last router in the chain, which is connected directly to the target subnet, can conclusively identify a directed broadcast.\n\nIP directed broadcasts are used in the extremely common and popular smurf, or Denial of Service (DoS), attacks. In a smurf attack, the attacker sends ICMP echo requests from a falsified source address to a directed broadcast address, causing all the hosts on the target subnet to send replies to the falsified source. By sending a continuous stream of such requests, the attacker can create a much larger stream of replies, which can completely inundate the host whose address is being falsified. This service should be disabled on all interfaces when not needed to prevent smurf and DoS attacks. Directed broadcast can be enabled on internal facing interfaces to support services such as Wake-On-LAN. Case scenario may also include support for legacy applications where the content server and the clients do not support multicast. The content servers send streaming data using UDP broadcast. Used in conjunction with the ip multicast helper-map feature, broadcast data can be sent across a multicast topology. The broadcast streams are converted to multicast and vice versa at the first-hop routers and last-hop routers before entering leaving the multicast transit area respectively. The last-hop router must convert the multicast to broadcast. Hence, this interface must be configured to forward a broadcast packet (i.e. a directed broadcast address is converted to the all nodes broadcast address).",
+      "severity": "low"
+    },
+    {
+      "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-3086",
+      "title": "BOOTP services must be disabled.",
+      "description": "BOOTP is a user datagram protocol (UDP) that can be used by Cisco routers to access copies of Cisco IOS Software on another Cisco router running the BOOTP service. In this scenario, one Cisco router acts as a Cisco IOS Software server that can download the software to other Cisco routers acting as BOOTP clients. In reality, this service is rarely used and can allow an attacker to download a copy of a router's Cisco IOS Software.",
+      "severity": "low"
+    },
+    {
+      "id": "V-30939",
+      "title": "The VPN gateway must use IKE for negotiating and establishing all IPSec security associations.",
+      "description": "An IPSec Security Associations (SA) is established using either Internet Key Exchange (IKE) or manual configuration. When using IKE, the security associations are established when needed and expire after a period of time or volume of traffic threshold. If manually configured, they are established as soon as the configuration is complete at both end points and they do not expire. When using IKE, the Security Parameter Index (SPI) for each security association is a pseudo-randomly derived number. Without IKE, the SPI is manually specified for each security association. IKE peers will negotiate the encryption algorithm and authentication or hashing methods as well as generate the encryption keys. \n\nWith manual configuration of the IPSec security association, both the cipher key and authentication key are static. Hence, if the keys are compromised, the traffic being protected by the current IPSec tunnel can be decrypted as well as traffic in any future tunnels established by this SA. Furthermore, the peers are not authenticated prior to establishing the SA which could result in a rouge device establishing an IPSec SA with either of the VPN end points.\n\nIKE provides primary authentication to verify the identity of the remote system before negotiation begins. IKE also enables anti-replay services and will establish a lifetime for each IPSec session. These features are lost when the IPSec security associations are manually configured which results in a non-terminating session using static pre-shared keys.\n",
+      "severity": "high"
+    },
+    {
+      "id": "V-30941",
+      "title": "The VPN gateway must authenticate the remote server, peer, or client prior to establishing an IPSec session.",
+      "description": "Both IPSec endpoints must authenticate each other to ensure the identity of each by additional means besides an IP address which can easily be spoofed. The objective of IPSec is to establish a secured tunnel with privacy between the two endpoints traversing an IP backbone network. In the case of teleworkers accessing the enclave using a laptop configured with an IPSec software client, the secured path will also traverse the Internet. The secured path will grant the remote site or client access to resources within the private network; thereby establishing a level of trust. Hence, it is imperative that some form of authentication is used prior to establishing an IPSec session for transporting data to and from the enclave from a remote site.",
+      "severity": "high"
+    },
+    {
+      "id": "V-30943",
+      "title": "The VPN gateway must use PKI or digital-signature for authenticating the remote server, peer, or client.",
+      "description": "Using shared secrets between two IPSec endpoints is easy to implement but are also easy to compromise. Regardless of the strength of the password, they can be cracked using software tools that are readily available. Furthermore, implementation using shared secrets is not scalable since all VPN gateways and software clients would need to be configured with the shared secrets. In addition, there cannot be a preshared key for every user because the VPN gateway server does not know the client’s identity (the IP address is commonly used). Hence, remote users must use a group-based preshared key for authentication. When an individual leaves the group, changing the key must be coordinated with the other users of the group. PKI mitigates the risk involved with group passwords because each user has a certificate.\n\nPKI offers a scalable way to authenticate all IPSec endpoints in a secure manner. Every VPN gateway or remote client that needs to participate in IPSec VPN is issued a digital certificate by the Certification Authority (CA). The digital certificate binds the identity information of a VPN gateway (e.g., hostname or IP address) to the device’s public key by means of digital signature. This involves the use of public key cryptography algorithms, such as RSA. Based on this binding, any device that trusts the CA certificate, i.e., trusts the signature of the CA, would accept the identity inside the signed certificate. This model enables all VPN gateways and clients that trust the same CA to authenticate each other. \n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30944",
+      "title": "The VPN gateway must only accept certificates issued by a DoD-approved Certificate Authority when using PKI for authentication.",
+      "description": "When using digital certificates, Internet Key Exchange (IKE) negotiation between peers is restricted by either manually configuring each peer with the public key for each peer to which it is allowed to connect, or enrolling each peer with a Certificate Authority (CA). All peers to which the peer is allowed to connect must enroll with the same CA server and belong to the same organization.\n\nCertificates are issued and signed by a CA. Hence, the signature on a certificate identifies the particular CA that issued a certificate. The CA in turn has a certificate that binds its identity to its public key, so the CA’s identity can be verified. The primary role of the CA is to digitally sign and publish the public key bound to a given user or device via a digital certificate. This is done using the CA's own private key, so that trust in the user’s key relies on trust in the validity of the CA's key. Hence, to establish trust in the certificate of the remote client or peer, the VPN gateway must be configured to validate the peer’s certificate with the DoD-approved CA, as well as validate the identity of the DoD-approved CA. If the peer’s certificate is not validated, there is a risk of establishing an IPSec Security Association with a malicious user or a remote client that is not authorized.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30945",
+      "title": "The VPN gateway server must enforce a policy to the software client to disallow the remote client from being able to save the logon password locally on the remote PC.",
+      "description": "Enabling the password save function requires users to only enter their password once when establishing the VPN tunnel. After that the software client will automatically re-enter the password when prompted for credentials by the VPN gateway.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30946",
+      "title": "The VPN gateway server must enforce a policy to the software client to display a DoD approved warning banner prior to allowing access to the VPN.",
+      "description": "All software remote clients must present a DoD approved warning banner prior allowing access to VPN. 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 network is subject to monitoring to detect unauthorized usage. Failure to display the required warning banner prior to logon attempts will limit the 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. \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-30947",
+      "title": "The VPN gateway must not accept certificates that have been revoked when using PKI for authentication.",
+      "description": "Situations may arise in which the certificate issued by a Certificate Authority (CA) may need to be revoked before the lifetime of the certificate expires. For example, the certificate is known to have been compromised. To achieve this, a list of certificates that have been revoked, known as a Certificate Revocation List (CRL), is sent periodically from the CA to the IPSec gateway. When an incoming Internet Key Exchange (IKE) session is initiated for a remote client or peer whose certificate is revoked, the CRL will be checked to see if the certificate is valid; if the certificate is revoked, IKE will fail and an IPSec security association will not be established for the remote end-point.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30948",
+      "title": "The VPN gateway server must enforce a policy to the remote software client to check for the presence of a personal firewall before enabling access to the VPN.",
+      "description": "The security posture of the remote PC connecting to the enclave via VPN is vital to the overall security of the enclave. While on-site hosts are behind the enclave’s perimeter defense, a remote PC is not and therefore is exposed to many vulnerabilities existing in the Internet when connected to a service provider via dial-up or broadband connection. Though it is policy to have a firewall installed on the remote PC according to the Secure Remote Computing Endpoint STIG (SRC-EPT-405), it is imperative the VPN gateway enforce the policy to the software client to verify the firewall is active prior to enabling access to the VPN.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30950",
+      "title": "The VPN gateway must use Secure Hash Algorithm for IKE cryptographic hashing operations required for authentication and integrity verification.",
+      "description": "Because hash algorithms create a short fixed-length hash value to represent data of any size, there are far more possible input values than there are unique hash values. Hence, multiple input values exist that will produce the same hash value. This is known as a collision and for a hash function to be deemed cryptographically secure and collision resistant, it has to be hard to find two inputs that hash to the same output. Various methods have been published stating that an MD5 collision has been found in less than a minute. Therefore, MD5 is considered cryptographically broken and should be not be used—and certainly not for security-based services relying on collision resistance. Using a weak hash algorithm such as MD5 could enable a rogue device to discover the authentication key enabling it to establish an Internet Key Exchange (IKE) Security Association with either of the VPN end points. Hence, Secure Hash Algorithm (SHA) must be used for IKE cryptographic hashing operations required for authentication and integrity verification.",
+      "severity": "high"
+    },
+    {
+      "id": "V-30951",
+      "title": "The VPN gateway server must enforce a no split-tunneling policy to all remote clients.",
+      "description": "A VPN hardware or software client with split tunneling enabled provides an unsecured backdoor to the enclave from the Internet. With split tunneling enabled, a remote client has access to the Internet while at the same time has established a secured path to the enclave via an IPSec tunnel. A remote client connected to the Internet that has been compromised by an attacker in the Internet, provides an attack base to the enclave’s private network via the IPSec tunnel. Hence, it is imperative that the VPN gateway enforces a no split-tunneling policy to all remote clients.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30952",
+      "title": "The VPN gateway must use AES for IKE cryptographic encryption operations required to ensure privacy of the IKE session.",
+      "description": "While there is much debate about the security and performance of Advance Encryption Standard (AES), there is a consensus that it is significantly more secure than any of the algorithms supported by IPSec implementations today. AES is available in three key sizes: 128, 192 and 256 bits, versus the 56 bit DES. Therefore, there are approximately 1021 times more AES 128-bit keys than DES 56-bit keys. In addition, AES uses a block size of 128 bits—twice the size of DES or 3DES. To ensure the privacy of the IKE session responsible for establishing the security association and key exchange for an IPSec tunnel, it is imperative that AES is used for encryption operations.",
+      "severity": "high"
+    },
+    {
+      "id": "V-30953",
+      "title": "The VPN gateway peer at a remote site must receive all ingress traffic and forward all egress traffic via the IPSec tunnel or other provisoned WAN links connected to the central or remote site.",
+      "description": "A VPN gateway peer at the remote site provides connectivity to the central or other remote sites belonging to the enclave via an IPSec tunnel across an IP backbone network such as the NIPRNet. This creates an extension or Intranet for the enclave using IPSec tunnels in lieu of traditional or legacy WAN services (T carrier, ATM, frame relay, etc). Unless the remote site has the required enclave perimeter defense (firewall, IPS, deny by default, etc), it is imperative that all inbound and outbound traffic traverse only the IPSec tunnels or other provisioned WAN links connecting the remote site to other sites belonging to the enclave. \nIn other words, no packets can leak out an external-facing interface as “native” IP traffic into an IP backbone (i.e. NIPRNet, Internet). In addition, the external interface must not receive any traffic that is not secured by an IPSec tunnel or other provisioned WAN links connected to the central or remote site. This not only ensures that inbound and outbound traffic does not bypass the enclave’s perimeter defense, but also eliminates any backdoor connection.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30954",
+      "title": "The VPN gateway must ensure traffic from a remote client with an outbound destination does not bypass the enclaves perimeter defense mechanisms deployed for egress traffic.",
+      "description": "Packets from a remote client destined outbound must be inspected and proxied the same as any other traffic that will egress the enclave. Otherwise, there is the risk that the return traffic that will ingress the IPSec tunnel could compromise the remote client and possibly the remote LAN. This scenario can exist with a VPN-on-a-stick implementation that allows traffic to u-turn—that is, traffic from the remote site that traverses the IPSec tunnel is immediately forwarded out the same interface towards the NIPRNet and Internet with no upstream firewall. If a remote LAN is breached, the entire enclave could be exposed via the secured tunnel or any other provisioned link between the compromised remote LAN and other remote sites and the central site. Hence, it is imperative that traffic from the remote site that is destined outbound does not bypass the applicable inspection and proxy services deployed for the enclave’s perimeter defense. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30955",
+      "title": "IPSec Security Association parameters must be compliant with all requirements specified for VPN Suite B when transporting classified traffic across a non-classified network.",
+      "description": "RFC 6379 Suite B Cryptographic Suites for IPSec defines four cryptographic user interface suites for deploying IPSec. Each suite provides choices for Encapsulating Security Payload (ESP) and Internet Key Exchange (IKE). The four suites are differentiated by the choice of IKE authentication and key exchange, cryptographic algorithm strengths, and whether ESP is to provide both confidentiality and integrity or integrity only. The suite names are based on the Advanced Encryption Standard (AES) mode and AES key length specified for ESP. Two suites are defined for transporting classified information up to SECRET level—one for both confidentiality and integrity and one for integrity only. There are also two suites defined for transporting classified information up to TOP SECRET level.",
+      "severity": "high"
+    },
+    {
+      "id": "V-30956",
+      "title": "The VPN gateway must enable anti-replay for all IPSec security associations.",
+      "description": "Replay attack is a type of injection attack when an IPSec packet is captured by an attacker and re-inserts it into the legitimate flow to disrupt service or create undesired behavior. IPSec anti-replay service can mitigate a replay attack by running sequence numbers for each end of the tunnel and incrementing it for each packet sent. If a packet that is received does not have the expected sequence number, it is dropped. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30957",
+      "title": "The VPN gateway must use IKE main mode for the purpose of negotiating an IPSec security association policy when pre-shared keys are used for authentication",
+      "description": "Aggressive mode is completed using only three messages instead of the six used in main mode. Essentially, all the information needed to generate the Diffie-Hellman secret is exchanged in the first two messages exchanged between the two peers. The identity of the peer is also exchanged in the first two packets which have been sent in the clear. There are risks to configurations that use pre-shared keys which are exaggerated when aggressive mode is used. The entire session may be intercepted and manipulated. An adversary can either use a pre-shared key to impersonate a trusted end-point or client and connect to the protected network, or it can mount a Man-in-the-Middle attack on any new session.",
+      "severity": "low"
+    },
+    {
+      "id": "V-30959",
+      "title": "The VPN gateway must use a key size from Diffie-Hellman Group 14 or larger during IKE Phase 1.",
+      "description": "Diffie-Hellman (DH) is a public-key cryptography scheme that allows two parties to establish a shared secret over an insecure communications channel. IKE uses DH to create keys used to encrypt both the Internet Key Exchange (IKE) and IPsec communication channels. The process works by two peers both generating a private and a public key and then exchanging their public keys with each other. The peers produce the same shared secret by using each other’s public key and their own private key using the DH algorithm. \n\nThe DH group is configured as part of the IKE Phase 1 key exchange settings. DH public key cryptography is used by all major VPN gateways. DH group 1 consists of a 768 bit modulus, group 2 consists of 1024 bit modulus, group 5 uses a 1536 bit modulus, and group 14 uses a 2048 bit modulus.  The security of the DH key exchange is based on the difficulty of solving the discrete logarithm in which the key was derived from. Hence, the larger the modulus, the more secure the generated key is considered to be.",
+      "severity": "low"
+    },
+    {
+      "id": "V-30960",
+      "title": "The VPN gateway must specify Perfect Forward Secrecy during IKE negotiation.",
+      "description": "The Internet Key Exchange (IKE) Phase-2 (Quick Mode) Security Association (SA) is used to create an IPSec session key.  Hence, its rekey or key regeneration procedure is very important. The Phase-2 rekey can be performed with or without Perfect Forward Secrecy (PFS). With PFS, every time a new IPSec Security Association is negotiated during the Quick Mode, a new Diffie-Hellman (DH) exchange occurs. The new DH shared secret will be included with original keying material (SYKEID_d, initiator nonce, and responder nonce from Phase 1) for generating a new IPSec session key. If PFS is not used, the IPSec session key will always be completely dependent on the original keying material from the Phase-1. Hence, if an older key is compromised at any time, it is possible that all new keys may be compromised. \n\nThe DH exchange is performed in the same manner as was done in Phase 1 (Main or Aggressive Mode). However, the Phase-2 exchange is protected by encrypting the Phase-2 packets with the key derived from the Phase-1 negotiation. Because DH negotiations during Phase-2 are encrypted, the new IPSec session key has an added element of secrecy.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30961",
+      "title": "The VPN gateway must implement IPSec security associations that terminate after one hour or less of idle time.",
+      "description": "When a VPN gateway creates an IPSec Security Association (SA), resources must be allocated to maintain the SA. These resources are wasted during periods of IPSec endpoint inactivity which could result in the gateway’s inability to create new SAs for other endpoints; thereby, preventing new sessions from connecting. The IPSec SA idle timer allows SAs associated with inactive endpoints to be deleted before the SA lifetime has expired.",
+      "severity": "low"
+    },
+    {
+      "id": "V-30962",
+      "title": "The VPN gateway must implement IPSec security associations that terminate within 8 hours or less.",
+      "description": "The IPSec SA and its corresponding key will expire either after the number of seconds or amount of traffic volume has exceeded the configured limit. A new SA is negotiated before the lifetime threshold of the existing SA is reached to ensure that a new SA is ready for use when the old one expires. The longer the life time of the IPSec Security Association, the longer the life time of the session key used to protect IP traffic. The SA is less secure with a longer lifetime because an attacker has a greater opportunity to collect traffic encrypted by the same key and subject it to cryptanalysis. However, a shorter lifetime causes IPSec peers to have to renegotiate IKE Phase II more often resulting in the expenditure of additional resources. Nevertheless, it is imperative the IPSec SA lifetime terminates within 8 hours.",
+      "severity": "low"
+    },
+    {
+      "id": "V-30963",
+      "title": "The VPN gateway must use a key size from Diffie-Hellman Group 14 or larger during IKE Phase 2.",
+      "description": "Diffie-Hellman (DH) is a public -key cryptography scheme allowing two parties to establish a shared secret over an insecure communications channel. IKE uses Diffie-Hellman to create keys used to encrypt both the Internet Key Exchange (IKE) and IPsec communication channels. The process works by two peers both generating a private and a public key and then exchanging their public keys with each other. The peers produce the same shared secret by using each other’s public key and their own private key using the DH algorithm.\n\nWith Perfect Forward Secrecy (PFS), every time a new IPsec SA is negotiated during the Quick Mode, a new DH exchange occurs.  The new DH shared secret will be included with original keying material (SYKEID_d, initiator nonce, and responder nonce from Phase 1) for generating a new IPsec session key.  If PFS is not used, the IPsec session key will always be completely dependent on the original keying material from the Phase-1.  Hence, if an older key is compromised at any time, it is possible that all new keys may be compromised.",
+      "severity": "low"
+    },
+    {
+      "id": "V-30964",
+      "title": "The VPN gateway must use ESP tunnel mode for establishing secured paths to transport traffic between the organization’s sites or between a gateway and remote end-stations. ",
+      "description": "Encapsulating Security Payload (ESP) is the feature in the IPSec architecture providing confidentiality, data origin authentication, integrity, and anti-replay services. ESP can be deployed in either transport or tunnel mode. Transport mode is used to create a secured session between two hosts. It can also be used when two hosts simply want to authenticate each IP packet with IPSec authentication header (AH). With ESP transport mode, only the payload (transport layer) is encrypted; whereas with tunnel mode, the entire IP packet is encrypted and encapsulated with a new IP header. Tunnel mode is used to encrypt traffic between secure IPSec gateways, or between an IPSec gateway and an end-station running IPSec software. Hence, it is the only method to provide secured path to transport traffic between remote sites or end-stations and the central site.",
+      "severity": "high"
+    },
+    {
+      "id": "V-30965",
+      "title": "The VPN gateway must implement IKE Security Associations that terminate within 24 hours or less.",
+      "description": "The Security Association (SA) and its corresponding key will expire after the number of seconds has exceeded the configured limit. A new SA is negotiated before the lifetime threshold of the existing SA is reached to ensure a new SA is ready for use when the old one expires. The longer the life time of the Internet Key Exchange (IKE) Security Association, the longer the life time of the key used for the IKE session, which is the control plane for establishing IPSec Security Associations. The SA is less secure with a longer lifetime because an attacker has a greater opportunity to collect traffic encrypted by the same key and subject it to cryptanalysis. However, a shorter IKE lifetime causes IPSec peers to have to renegotiate IKE more often resulting in the expenditure of additional resources. Nevertheless, it is imperative the IKE SA lifetime terminates within 24 hours or less.",
+      "severity": "low"
+    },
+    {
+      "id": "V-30966",
+      "title": "The VPN gateway must use AES for IPSec cryptographic encryption operations required to ensure privacy of the IPSec session.",
+      "description": " While there is much debate about the security and performance of Advance Encryption Standard (AES), there is a consensus it is significantly more secure than any of the algorithms supported by IPSec implementations today. AES is available in three key sizes: 128, 192 and 256 bits, versus the 56 bit DES. Therefore, there are approximately 1021 times more AES 128-bit keys than DES 56-bit keys. In addition, AES uses a block size of 128 bits—twice the size of DES or 3DES. Hence, AES must be used to ensure the privacy of the IPSec tunnel. ",
+      "severity": "high"
+    },
+    {
+      "id": "V-30967",
+      "title": "The VPN gateway must use Secure Hash Algorithm for IPSec cryptographic hashing operations required for authentication and integrity verification.",
+      "description": "Because hash algorithms create a short fixed-length hash value to represent data of any size, there are far more possible input values than there are unique hash values. Hence, multiple input values exist that will produce the same hash value. This is known as a collision.  For a hash function to be deemed cryptographically secure and collision resistant, it has to be hard to find two inputs that hash to the same output. Various methods have been published stating that an MD5 collision has been found in less than a minute. Therefore MD5 is considered cryptographically broken and should not be used—and certainly not for security-based services relying on collision resistance. Hence Secure Hash Algorithm (SHA) must be used for IPSec cryptographic hashing operations required for authentication and integrity verification.",
+      "severity": "high"
+    },
+    {
+      "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-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-5614",
+      "title": "Network devices must have the PAD service disabled.",
+      "description": "Packet Assembler Disassembler (PAD) is an X.25 component seldom used.  It collects the data transmissions from the terminals and gathers them into a X.25 data stream and vice versa.  PAD acts like a multiplexer for the terminals.  If enabled, it can render the device open to attacks. Some voice vendors use PAD on internal routers.",
+      "severity": "low"
+    },
+    {
+      "id": "V-5615",
+      "title": "Network devices must have TCP Keep-Alives enabled for TCP sessions.",
+      "description": "Idle TCP sessions can be susceptible to unauthorized access and hijacking attacks. By default, routers do not continually test whether a previously connected TCP endpoint is still reachable. If one end of a TCP connection idles out or terminates abnormally, the opposite end of the connection may still believe the session is available. These \"orphaned\" sessions use up valuable router resources and can also be hijacked by an attacker. To mitigate this risk, routers must be configured to send periodic keepalive messages to check that the remote end of a session is still connected. If the remote device fails to respond to the keepalive message, the sending router will clear the connection and free resources allocated to the session.",
+      "severity": "low"
+    },
+    {
+      "id": "V-5616",
+      "title": "Network devices must have identification support disabled.",
+      "description": "Identification support allows one to query a TCP port for identification.  This feature enables an unsecured protocol to report the identity of a client initiating a TCP connection and a host responding to the connection.  Identification support can connect a TCP port on a host, issue a simple text string to request information, and receive a simple text-string reply.  This is another mechanism to learn the router vendor, model number, and software version being run.",
+      "severity": "low"
+    },
+    {
+      "id": "V-5618",
+      "title": "Gratuitous ARP must be disabled.",
+      "description": "A gratuitous ARP is an ARP broadcast in which the source and destination MAC addresses are the same. It is used to inform the network about a host IP address. A spoofed gratuitous ARP message can cause network mapping information to be stored incorrectly, causing network malfunction.",
+      "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"
+    }
+  ]
+}