kriterion 0.0.1

data/standards/stig_firewall_security_requirements_guide.json

@@ -0,0 +1,257 @@
+{
+  "name": "stig_firewall_security_requirements_guide",
+  "date": "2018-03-21",
+  "description": "This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.",
+  "title": "Firewall Security Requirements Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-79409",
+      "title": "The firewall must be configured to use filters that use packet headers and packet attributes, including source and destination IP addresses and ports, to prevent the flow of unauthorized or suspicious traffic between interconnected networks with different security policies (including perimeter firewalls and server VLANs).",
+      "description": "Information flow control regulates where information is allowed to travel within a network and between interconnected networks. Blocking or restricting detected harmful or suspicious communications between interconnected networks enforces approved authorizations for controlling the flow of traffic.\n\nThe firewall that filters traffic outbound to interconnected networks with different security policies must be configured with filters (i.e., rules, access control lists [ACLs], screens, and policies) that permit, restrict, or block traffic based on organization-defined traffic authorizations. Filtering must include packet header and packet attribute information, such as IP addresses and port numbers.\n\nConfigure filters to perform certain actions when packets match specified attributes, including the following actions:\n\n- Apply a policy\n- Accept, reject, or discard the packets\n- Classify the packets based on their source address\n- Evaluate the next term in the filter\n- Increment a packet counter\n- Set the packets’ loss priority\n- Specify an IPsec SA (if IPsec is used in the implementation)\n- Specify the forwarding path\n- Write an alert or message to the system log",
+      "severity": "high"
+    },
+    {
+      "id": "V-79411",
+      "title": "The firewall must fail closed if the firewall filtering function is nonfunctional.",
+      "description": "While failure to an open state may ensure users are not inconvenienced, it also circumvents a critical security network function that guards against direct and indirect network attacks. Allow traffic to flow without filtering or inspection puts the entire network and DoD critical assets at immediate risk. An example is a network element that blocks all traffic rather than allowing all traffic when a network element component fails (e.g., fail closed and do not forward traffic). This prevents an attacker from forcing a failure of the system in order to obtain access.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79413",
+      "title": "The firewall must employ filters that prevent or limit the effects of all types of commonly known denial-of-service (DoS) attacks, including flooding, packet sweeps, and unauthorized port scanning.",
+      "description": "Not configuring a key boundary security protection device such as the firewall against commonly known attacks is an immediate threat to the protected enclave because they are easily implemented by those with little skill. Directions for the attack are obtainable on the Internet and in hacker groups. Without filtering enabled for these attacks, the firewall will allow these attacks beyond the protected boundary.\n\nConfigure the perimeter and internal boundary firewall to guard against the three general methods of well-known DoS attacks: flooding attacks, protocol sweeping attacks, and unauthorized port scanning.\n\nFlood attacks occur when the host receives too much traffic to buffer and slows down or crashes. Popular flood attacks include ICMP flood and SYN flood. A TCP flood attack of SYN packets initiating connection requests can overwhelm the device until it can no longer process legitimate connection requests, resulting in denial of service. An ICMP flood can overload the device with so many echo requests (ping requests) that it expends all its resources responding and can no longer process valid network traffic, also resulting in denial of service. An attacker might use session table floods and SYN-ACK-ACK proxy floods to fill up the session table of a host.\n\nIn an IP address sweep attack, an attacker sends ICMP echo requests (pings) to multiple destination addresses. If a target host replies, the reply reveals the target’s IP address to the attacker. In a TCP sweep attack, an attacker sends TCP SYN packets to the target device as part of the TCP handshake. If the device responds to those packets, the attacker gets an indication that a port in the target device is open, which makes the port vulnerable to attack. In a UDP sweep attack, an attacker sends UDP packets to the target device. If the device responds to those packets, the attacker gets an indication that a port in the target device is open, which makes the port vulnerable to attack.\n\nIn a port scanning attack, an unauthorized application is used to scan the host devices for available services and open ports for subsequent use in an attack. This type of scanning can be used as a DoS attack when the probing packets are sent excessively.",
+      "severity": "high"
+    },
+    {
+      "id": "V-79415",
+      "title": "The firewall must be configured to use filters that prevent or limit the effects of all types of commonly known denial-of-service (DoS) attacks, including flooding, packet sweeps, and unauthorized port scanning.",
+      "description": "To prevent malicious or accidental leakage of traffic, organizations must implement a deny-by-default security posture at the network perimeter. Such rulesets prevent many malicious exploits or accidental leakage by restricting the traffic to only known sources and only those ports, protocols, or services that are permitted and operationally necessary.\n\nAs a managed boundary interface, the firewall must block all inbound and outbound network traffic unless a filter is installed to explicitly allow it. The allow filters must comply with the Ports, Protocols, and Services Management (PPSM) Category Assurance List (CAL) and Vulnerability Assessment (VA).",
+      "severity": "high"
+    },
+    {
+      "id": "V-79417",
+      "title": "The firewall must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services on the network segment in accordance as defined in the Ports, Protocols, and Services Management (PPSM) CAL and vulnerability assessments.",
+      "description": "Some ports, protocols, or services have well-known exploits or security weaknesses that can be leveraged in an attack against the enclave and put it at immediate risk. These ports, protocols, and services must be prohibited or restricted in the packet or stateful filtering firewall configuration in accordance with DoD policy. \n \nPolicy filters restrict traffic destined to the enclave perimeter as defined in the PPSM CAL and vulnerability assessments.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79419",
+      "title": "The firewall must block outbound traffic containing denial-of-service (DoS) attacks to protect against the use of internal information systems to launch any DoS attacks against other networks or endpoints.",
+      "description": "DoS attacks can take multiple forms but have the common objective of overloading or blocking a network or host to deny or seriously degrade performance. If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users.\n\nInstallation of a firewall 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\nThe firewall must include protection against DoS attacks that originate from inside the enclave that can affect either internal or external systems. These attacks may use legitimate or rogue endpoints from inside the enclave. These attacks can be simple \"floods\" of traffic to saturate circuits or devices, malware that consumes CPU and memory on a device or causes it to crash, or a configuration issue that disables or impairs the proper function of a device. For example, an accidental or deliberate misconfiguration of a routing table can misdirect traffic for multiple networks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79421",
+      "title": "The firewall implementation must manage excess bandwidth to limit the effects of packet flooding types of denial-of-service (DoS) attacks.",
+      "description": "A firewall experiencing a DoS attack will not be able to handle production traffic load. The high utilization and CPU caused by a DoS attack will also have an effect on control keep-alives and timers used for neighbor peering resulting in route flapping and will eventually black hole production traffic.\n\nThe device must be configured to contain and limit a DoS attack's effect on the device's resource utilization. The use of redundant components and load balancing are examples of mitigating \"flood-type\" DoS attacks through increased capacity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79423",
+      "title": "The firewall that filters traffic from the VPN access points must be configured with organization-defined filtering rules that apply to the monitoring of remote access traffic.",
+      "description": "Remote access devices (such as those providing remote access to network devices and information systems) that lack automated capabilities increase risk and make remote user access management difficult at best.\n\nRemote access is access to DoD non-public information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network.\n\nAutomated monitoring of remote access sessions allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities from a variety of information system components (e.g., servers, workstations, notebook computers, smart phones, and tablets).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79425",
+      "title": "The firewall that filters traffic from the wireless access points must be configured with organization-defined filtering rules that apply to the monitoring of remote access traffic.",
+      "description": "Remote access devices (such as those providing remote access to network devices and information systems) that lack automated capabilities increase risk and make remote user access management difficult at best.\n\nRemote access is access to DoD non-public information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. \n\nAutomated monitoring of remote access sessions allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities from a variety of information system components (e.g., servers, workstations, notebook computers, smart phones, and tablets).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79427",
+      "title": "The firewall must immediately use updates made to policy enforcement mechanisms such as firewall rules, security policies, and security zones.",
+      "description": "Information flow policies regarding dynamic information flow control include, for example, allowing or disallowing information flows based on changes to the Ports, Protocols, Services Management [PPSM] Category Assurance Levels [CAL] list, vulnerability assessments, or mission conditions. Changing conditions include changes in the threat environment and detection of potentially harmful or adverse events.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79429",
+      "title": "The firewall must generate traffic log records when traffic is denied, restricted, or discarded.",
+      "description": "Without generating log records that log usage of objects by subjects and other objects, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.\n\nSecurity objects are data objects that are controlled by security policy and bound to security attributes.\n\nThe firewall must not forward traffic unless it is explicitly permitted via security policy. Logging for firewall security-related sources such as screens and security policies must be configured separately. To ensure security objects such as firewall filters (i.e., rules, access control lists [ACLs], screens, and policies) send events to a syslog server and local logs, security logging must be configured one each firewall term.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79431",
+      "title": "The firewall must generate traffic log records when attempts are made to send packets between security zones that are not authorized to communicate.",
+      "description": "Without generating log records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.\n\nAccess for different security levels maintains separation between resources (particularly stored data) of different security domains.\n\nThe firewall can be configured to use security zones that are configured with different security policies based on risk and trust levels. These zones can be leveraged to prevent traffic from one zone from sending packets to another zone. For example, information from certain IP sources will be rejected if the destination matches specified security zones that are not authorized.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79433",
+      "title": "The firewall must be configured to allow authorized users to record a packet capture based IP, traffic type (TCP, UDP, or ICMP), or protocol.",
+      "description": "Without the ability to capture, record, and log content related to a user session, investigations into suspicious user activity would be hampered.\n\nThis configuration ensures the ability to select specific sessions to capture in order to support general auditing/incident investigation or to validate suspected misuse.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79435",
+      "title": "The firewall must generate traffic log entries containing information to establish what type of events occurred.",
+      "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.\n\nAudit event content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.\n\nAssociating event types with detected events in the network element logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured network element.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79437",
+      "title": "The firewall must generate traffic log entries containing information to establish when (date and time) the events occurred.",
+      "description": "Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack.\n\nIn order to compile an accurate risk assessment, and provide forensic analysis of network traffic patterns, it is essential for security personnel to know when flow control events occurred (date and time) within the infrastructure.\n\nAssociating event types with detected events in the network traffic logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured network element.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79439",
+      "title": "The firewall must generate traffic log entries containing information to establish the location on the network where the events occurred.",
+      "description": "Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack.\n\nIn order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know where events occurred, such as network element components, modules, device identifiers, node names, and functionality. \n\nAssociating information about where the event occurred within the network provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured network element.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79441",
+      "title": "The firewall must generate traffic log entries containing information to establish the source of the events, such as the source IP address at a minimum.",
+      "description": "Without establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In order to compile an accurate risk assessment and provide forensic analysis, security personnel need to know the source of the event.\n\nIn addition to logging where events occur within the network, the traffic log events must also identify sources of events, such as IP addresses, processes, and node or device names.",
+      "severity": "low"
+    },
+    {
+      "id": "V-79443",
+      "title": "The firewall must generate traffic log entries containing information to establish the outcome of the events, such as, at a minimum, the success or failure of the application of the firewall rule.",
+      "description": "Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the network.\n\nEvent outcomes can include indicators of event success or failure and event-specific results. They also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79445",
+      "title": "The firewall must be configured to send traffic log entries to a central audit server for management and configuration of the traffic log entries.",
+      "description": "Without the ability to centrally manage the content captured in the traffic log entries, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack.\n\nThe DoD requires centralized management of all network component audit record content. Network components requiring centralized traffic log management must have the ability to support centralized management. The content captured in traffic log entries must be managed from a central location (necessitating automation). Centralized management of traffic log records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. \n\nEnsure at least one syslog server is configured on the firewall.\n\nIf the product inherently has the ability to store log records locally, the local log must also be secured. However, this requirement is not met since it calls for a use of a central audit server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79447",
+      "title": "If communication with the central audit server is lost, the firewall must generate a real-time alert to, at a minimum, the SCA and ISSO.",
+      "description": "Without a real-time alert (less than a second), security personnel may be unaware of an impending failure of the audit functions and system operation may be adversely impacted. Alerts provide organizations with urgent messages. Automated alerts can be conveyed in a variety of ways, including via a regularly monitored console, telephonically, via electronic mail, via text message, or via websites.\n\nLog processing failures include software/hardware errors, failures in the log capturing mechanisms, and log storage capacity being reached or exceeded. Most firewalls use UDP to send audit records to the server and cannot tell if the server has received the transmission, thus the site should either implement a connection-oriented communications solution (e.g., TCP) or implement a heartbeat with the central audit server and send an alert if it is unreachable.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79449",
+      "title": "The firewall must be configured to send a real-time alert to the ISSO and SA (at a minimum) in the event of an audit processing failure on the firewall itself.",
+      "description": "It is critical for the appropriate personnel to be aware if a system is at risk of failing to process traffic logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. \n\nAudit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Most firewalls use User Datagram Protocol (UDP) to send audit records to the server and cannot tell if the server has received the transmission. Thus, when the event daemon stops working, messages and notifications cannot be sent to the event monitor (e.g., Network Management System [NMS], Security Information and Event Management [SIEM], Syslog) or to the Simple Network Management Protocol (SNMP) server. Another method such as a keep-alive with the central audit server may be required.\n\nThis requirement applies to each audit data storage repository (i.e., distinct information system component where traffic log records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both. \n\nNote that CCI-001858 requires that audit failure alerts be in real time; thus, simply sending a log event to the central audit server is not sufficient.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79451",
+      "title": "In the event that communication with the central audit server is lost, the firewall must continue to queue traffic log records locally.",
+      "description": "It is critical that when the network element is at risk of failing to process traffic logs as required, it takes action to mitigate the failure. Audit 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 on the nature of the failure mode.\n\nIn accordance with DoD policy, the traffic log must be sent to a central audit server. When logging functions are lost, system processing cannot be shut down because firewall availability is an overriding concern given the role of the firewall in the enterprise. The system should either be configured to log events to an alternative server or queue log records locally. Upon restoration of the connection to the central audit server, action should be taken to synchronize the local log data with the central audit server.\n\nIf the central audit server uses User Datagram Protocol (UDP) communications instead of a connection oriented protocol such as TCP, a method for detecting a lost connection must be implemented.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79453",
+      "title": "The firewall must protect traffic log records from unauthorized access while in transit to the central audit server.",
+      "description": "Auditing and logging are key components of any security architecture. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or identify an improperly configured firewall. Thus, it is imperative that the collected log data be secured and access be restricted to authorized personnel. Methods of protection may include encryption or logical separation.\n\nThis does not apply to traffic logs generated on behalf of the device itself (management). Some devices store traffic logs separately from the system logs.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79455",
+      "title": "The firewall must protect traffic log records from unauthorized read access while stored locally.",
+      "description": "Auditing and logging are key components of any security architecture. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or identify an improperly configured firewall. Thus, it is imperative that the collected log data be secured and can only be accessed by authorized personnel.\n\nThis does not apply to traffic logs generated on behalf of the device itself (management). Some devices store traffic logs separately from the system logs.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79457",
+      "title": "The firewall must protect the traffic log from unauthorized modification of local log records.",
+      "description": "If audit data were to become compromised, forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve.\n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification. This can be achieved through multiple methods, which will depend on system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions and limiting log data locations.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.\n\nThis does not apply to traffic logs generated on behalf of the device itself (management).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79459",
+      "title": "The firewall must protect the traffic log from unauthorized deletion of local log files and log records.",
+      "description": "If audit data were to become compromised, forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve.\n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification. This can be achieved through multiple methods, which will depend on system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions and limiting log data locations.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.\n\nThis requirement does not apply to traffic logs generated on behalf of the device itself (device management).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79461",
+      "title": "The firewall must disable or remove unnecessary network services and functions that are not used as part of its role in the architecture.",
+      "description": "Network devices are capable of providing a wide variety of functions (capabilities or processes) and services. Some of these functions and services are installed and enabled by default. The organization must determine which functions and services are required to perform the content filtering and other necessary core functionality for each component of the firewall. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.\n\nSome services may be security related but, based on the firewall’s role in the architecture, must not be installed on the same hardware. For example, the device may serve as a router, VPN, or other perimeter services. However, if these functions are not part of the documented role of the firewall in the enterprise or branch architecture, the software and licenses should not be installed on the device. This mitigates the risk of exploitation of unconfigured services or services that are not kept updated with security fixes. If left unsecured, these services may provide a threat vector.\n\nSome services are not authorized for combination with the firewall and individual policy must be in place to instruct the administrator to remove these services. Examples of these services are Network Time Protocol (NTP), domain name server (DNS), email server, FTP server, web server, and Dynamic Host Configuration Protocol (DHCP). \n\nOnly remove unauthorized services. This control is not intended to restrict the use of firewalls with multiple authorized roles.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79463",
+      "title": "The firewall must fail to a secure state if the firewall filtering functions fail unexpectedly.",
+      "description": "Firewalls that fail suddenly and with no incorporated failure state planning may leave the hosting system available but with a reduced security protection. Failure to a known safe state helps prevent systems from failing to a state that may cause unauthorized access to make changes to the firewall filtering functions. \n\nThis applies to the configuration of the gateway or network traffic security function of the device. Abort refers to stopping the firewall filtering function before it has finished naturally. The term abort refers to both requested and unexpected terminations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79465",
+      "title": "In the event of a system failure of the firewall function, the firewall must be configured to save diagnostic information, log system messages, and load the most current security policies, rules, and signatures when restarted.",
+      "description": "Failure to a secure state can 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 firewall application and a return to the operational mode with less disruption.\n\nThis requirement applies to a failure of the firewall 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 functionality in a production environment, systems should be validated either in a testing environment or prior to installation. This requirement is usually a function of the design of the firewall. Compliance can be verified by acceptance/validation processes or vendor attestation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79467",
+      "title": "The perimeter firewall must be configured for service redundancy, load balancing, or other organization-defined safeguards to limit the effects of types of denial-of-service (DoS) attacks on the network.",
+      "description": "As a critical security system, perimeter firewalls must be safeguarded with redundancy measures. If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Service redundancy techniques reduce the susceptibility of the firewall to many DoS attacks.\n\nA firewall experiencing a DoS attack will not be able to handle the traffic load. The high CPU utilization caused by a DoS attack will also have impact control keep-alives and timers used for neighbor peering, resulting in route flapping and eventually black hole traffic.\n\nThough redundant hardware is the primary means of compliance, there are a number of ways to meet this requirement. The firewall can also be configured for filter-based forwarding, per-flow load balancing, and/or per-packet load balancing.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79469",
+      "title": "The firewall must apply ingress filters to traffic that is inbound to the network through any active external interface.",
+      "description": "Unrestricted traffic to the trusted networks may contain malicious traffic that poses a threat to an enclave or to other connected networks. Additionally, unrestricted traffic may transit a network, which uses bandwidth and other resources.\n\nFirewall filters control the flow of network traffic, ensure the flow of traffic is only allowed from authorized sources to authorized destinations. Networks with different levels of trust (e.g., the Internet) must be kept separated.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79471",
+      "title": "The firewall must apply egress filters to traffic that is outbound from the network through any internal interface.",
+      "description": "If outbound communications traffic is not filtered, hostile activity intended to harm other networks or packets from networks destined to unauthorized networks may not be detected and prevented. \n\nAccess control policies and access control lists implemented on devices, such as firewalls, that control the flow of network traffic ensure the flow of traffic is only allowed from authorized sources to authorized destinations. Networks with different levels of trust (e.g., the Internet) must be kept separated.\n\nThis requirement addresses the binding of the ingress filter to the interface/zone rather than the content of the ingress filter.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79473",
+      "title": "The firewall must establish ingress filters that block inbound packets where the destination is an IP address assigned to the management or loopback addresses of the enclave protection devices unless the packet has a source address assigned to the management network or network infrastructure.",
+      "description": "The firewall must reject requests for access or services where the source address received by the firewall specifies a loopback address. The loopback address is used by an Inter-Processor Control (IPC) mechanism that enables the client and server portion of an application running on the same machine to communicate, and so it is trusted. It should never be used as the source IP address of an inbound or outbound transmission.\n\nIt is a best practice for the management network to use the loopback addresses.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79475",
+      "title": "The firewall must block or restrict inbound IP packets destined to the control plane of the firewall itself.",
+      "description": "As a critical security system, perimeter firewalls must be safeguarded against direct attacks to the device. The firewall must have a filter that rejects requests for access or services where the source address received by the firewall specifies an external address and the destination address specifies the control plane of the firewall.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79477",
+      "title": "The premise firewall (located behind the premise router) must block all outbound management traffic.",
+      "description": "The management network must still have its own subnet in order to enforce control and access boundaries provided by Layer 3 network nodes such as routers and firewalls. Management traffic between the managed network elements and the management network is routed via the same links and nodes as that used for production or operational traffic. \n\nSafeguards must be implemented to ensure that the management traffic does not leak past the managed network's premise equipment. If a firewall is located behind the premise router, all management traffic must be blocked at that point, with the exception of management traffic destined to premise equipment.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79479",
+      "title": "The firewall must restrict traffic entering the VPN tunnels to the management network to only the authorized management packets based on destination address.",
+      "description": "Protect the management network with a filtering firewall configured to block unauthorized traffic. This requirement is similar to the out-of-band management (OOBM) model, when the production network is managed in-band. The management network could also be housed at a Network Operations Center (NOC) that is located locally or remotely at a single or multiple interconnected sites. \n\nNOC interconnectivity, as well as connectivity between the NOC and the managed networks’ premise routers, would be enabled using either provisioned circuits or VPN technologies such as IPsec tunnels or MPLS VPN services.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79481",
+      "title": "The firewall must block outbound IP packets that contain  illegitimate packet attributes including, at a minimum, invalid source address or packets that fail minimum length tests (TCP length, UDP length, IP data length) that have undefined protocol numbers, improper use of hop-by-hop header, or IPv6 RH0 header.",
+      "description": "If outbound communications traffic is not filtered, hostile activity intended to harm other networks may not be detected and prevented.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79483",
+      "title": "The firewall must be configured to fail securely in the event of an operational failure of the firewall filtering or boundary protection function.",
+      "description": "If a boundary protection device fails in an unsecure manner (open), information external to the boundary protection device may enter, or the device may permit unauthorized information release.\n\nSecure failure ensures that when a boundary control device fails, all traffic will be subsequently denied.\n\nFail secure is a condition achieved by employing information system mechanisms to ensure that in the event of operational failures of boundary protection devices at managed interfaces (e.g., routers, firewalls, guards, and application gateways residing on protected subnetworks commonly referred to as demilitarized zones), information systems do not enter into unsecure states where intended security properties no longer hold.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79485",
+      "title": "The perimeter firewall must filter traffic destined to the internal enclave in accordance with the specific traffic that is approved and registered in the Ports, Protocols, and Services Management (PPSM) Category Assurance List (CAL), Vulnerability Assessments (VAs) for that the enclave.",
+      "description": "The enclave's internal network contains the servers where mission-critical data and applications reside. Malicious traffic can enter from an external boundary or originate from a compromised host internally.\n\nVulnerability assessments must be reviewed by the SA and protocols must be approved by the IA staff before entering the enclave. \n\nFirewall filters (e.g., rules, access control lists [ACLs], screens, and policies) are the first line of defense in a layered security approach. They permit authorized packets and deny unauthorized packets based on port or service type. They enhance the posture of the network by not allowing packets to even reach a potential target within the security domain. The filters provided are highly susceptible ports and services that should be blocked or limited as much as possible without adversely affecting customer requirements. Auditing packets attempting to penetrate the network but stopped by the firewall filters will allow network administrators to broaden their protective ring and more tightly define the scope of operation. \n\nIf the perimeter is in a Deny-by-Default posture and what is allowed through the filter is in accordance with the PPSM CAL and VAs for the enclave, and if the permit rule is explicitly defined with explicit ports and protocols allowed, then all requirements related to the database being blocked would be satisfied.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79487",
+      "title": "The firewall must be configured to allow the system administrator to select a subset of DoD-required auditable events.",
+      "description": "The generation of logs with a subset of criteria aide the system administrator, maintainers, and auditors when troubleshooting issues or reviewing the log for trends or security breaches. \n\nTraffic log records can be generated from various components within the information system (e.g., network interface, access control list, or filter).\n\nThe DoD list of auditable events include the logging and audit requirements required by this document and any additional local requirements.",
+      "severity": "low"
+    },
+    {
+      "id": "V-79489",
+      "title": "The firewall must generate an alert that can be forwarded to, at a minimum, the ISSO and ISSM when denial-of-service (DoS) 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\nThe firewall generates an alert that notifies designated personnel of the Indicators of Compromise (IOCs), which require real-time alerts. These messages should include a severity level indicator or code as an indicator of the criticality of the incident. These indicators reflect the occurrence of a compromise or a potential compromise.\n\nSince these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.\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 1, 2, 4, or 7 detection events) will require an alert when an event is detected.\n\nAlerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The firewall 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": "low"
+    }
+  ]
+}

data/standards/stig_forescout_counteract_alg.json

@@ -0,0 +1,83 @@
+{
+  "name": "stig_forescout_counteract_alg",
+  "date": "2018-01-03",
+  "description": "This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.",
+  "title": "ForeScout CounterACT ALG Security Technical Implementation Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-75913",
+      "title": "CounterACT, when providing user access control intermediary services, must display the Standard Mandatory DoD-approved Notice and Consent Banner before granting access to the network.",
+      "description": "Display of a standardized and approved use notification before granting access to the network ensures privacy and security notification verbiage used is consistent with DoD requirements.\n\nSystem use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist, for example, with CounterACT guest access function. This requirement applies to network elements that have the concept of a user account and have the logon function residing on the network element. This requirement is not for access to the device itself, such as with system administrators of CounterACT, but rather is related to the network access control function provided to the users.\n\nThe banner must be formatted in accordance with DTM-08-060. Use the following verbiage for network elements that can accommodate banners of 1300 characters:\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n\n-At any time, the USG may inspect and seize data stored on this IS.\n\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\"",
+      "severity": "medium"
+    },
+    {
+      "id": "V-75931",
+      "title": "CounterACT, when providing user access control intermediary services, must retain the Standard Mandatory DoD-approved Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access.",
+      "description": "The banner must be acknowledged by the user prior to allowing the user access to the network. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law.\n\nTo establish acceptance of the application usage policy, a click-through banner at application logon is required. The network element must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating \"OK\".\n\nThis policy only applies to gateways (e.g., identity management or authentication gateways) that provide user account services as part of the intermediary services.",
+      "severity": "low"
+    },
+    {
+      "id": "V-75933",
+      "title": "CounterACT, when providing user access control intermediary services for publicly accessible applications, must display the Standard Mandatory DoD-approved Notice and Consent Banner before granting access to the system.",
+      "description": "Display of a standardized and approved use notification before granting access to the publicly accessible network element ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.\n\nSystem use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. This requirement applies to network elements that have the concept of a user account and have the logon function residing on the network element.\n\nThe banner must be formatted in accordance with DTM-08-060. Use the following verbiage for network elements that can accommodate banners of 1300 characters:\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following:",
+      "severity": "medium"
+    },
+    {
+      "id": "V-75935",
+      "title": "CounterACT must send an alert to, at a minimum, the ISSO and SCA when an audit processing failure occurs.",
+      "description": "It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected.\n\nAudit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Possible audit processing failures also include the inability of ALG to write to the central audit log.\n\nWhile this requirement also applies to the event monitoring system (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers), CounterACT can also be configured to send notifications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-75937",
+      "title": "If user authentication services are provided, CounterACT must be configured with a pre-established trust relationship and mechanisms with a central directory service that validates user account access authorizations and privileges.",
+      "description": "User account and privilege validation must be centralized in order to prevent unauthorized access using changed or revoked privileges.\n\nCounterACT can implement functions such as traffic filtering, authentication, access, and authorization functions based on computer and user privileges. However, the directory service (e.g., Active Directory or LDAP) must not be installed on CounterACT, particularly if the gateway resides on the untrusted zone of the Enclave.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-75939",
+      "title": "If user authentication services are provided, CounterACT must restrict user authentication traffic to specific authentication server(s).",
+      "description": "User authentication can be used as part of the policy filtering rule sets. Some URLs or network resources can be restricted to authenticated users only. Users are prompted by the application or browser for credentials. Authentication service may be provided by CounterACT as an intermediary for the application; however, the authentication credential must be stored in the site's directory services server.\n\nThis requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., proxy capability). This does not apply to authentication for the purpose of configuring the device itself (i.e., device management).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-75941",
+      "title": "CounterACT, when providing user authentication intermediary services, must implement replay-resistant authentication mechanisms for network access to non-privileged accounts.",
+      "description": "A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack.\n\nAn authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.\n\nA non-privileged account is any account with the authorizations of a non-privileged user. Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. Security relevant roles include key management, account management, network and system administration, database administration, and web administration.\n\nTechniques used to address this include protocols using nonces (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS). Additional techniques include time-synchronous or challenge-response one-time authenticators.\n\nThis requirement applies to ALGs that provide user authentication intermediary services.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-75943",
+      "title": "CounterACT must off-load audit records onto a centralized log server.",
+      "description": "Information stored in one location is vulnerable to accidental or incidental deletion or alteration.\n\nOff-loading is a common process in information systems with limited audit storage capacity.\n\nThis does not apply to audit logs generated on behalf of the device itself (management).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76185",
+      "title": "CounterACT, when providing user authentication intermediary services, must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.",
+      "description": "Without reauthentication, users may access resources or perform tasks for which they do not have authorization.\n\nIn addition to the reauthentication requirements associated with session locks, organizations may require reauthentication of individuals and/or devices in other situations, including (but not limited to) the following circumstances: \n\n1. When authenticators change\n2. When roles change\n3. When security categories of information systems change\n4. When the execution of privileged functions occurs\n5. After a fixed period of time\n6. Periodically\n\nWithin the DoD, the minimum circumstances requiring reauthentication are privilege escalation and role changes.\n\nThis requirement only applies to components where this is specific to the function of the device or has the concept of user authentication (e.g., VPN or ALG capability). This does not apply to authentication for the purpose of configuring the device itself (i.e., device management).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76187",
+      "title": "CounterACT, when providing user authentication intermediary services, must implement multifactor authentication for remote access to non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access.",
+      "description": "For remote access to non-privileged accounts, the purpose of requiring a device that is separate from the information system gaining access for one of the factors during multifactor authentication is to reduce the likelihood of compromising authentication credentials stored on the system.\n\nMultifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD common access card.\n\nA privileged account is defined as an information system account with authorizations of a privileged user.\n\nRemote access is access to DoD-nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.\n\nAn example of compliance with this requirement is the use of a one-time password token and PIN coupled with a password; or the use of a CAC/PIV card and PIN coupled with a password.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76189",
+      "title": "CounterACT must off-load audit records onto 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 ALG 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-76191",
+      "title": "CounterACT must use an Enterprise Manager or other high availability solution to ensure redundancy in case of audit failure in this critical network access control and security service.",
+      "description": "It is critical that when the network element is at risk of failing to process audit logs as required, it take action to mitigate the failure. Audit 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 mode.\n\nWhen availability is an overriding concern, other approved actions in response to an audit failure are as follows: \n\n1. If the failure was caused by the lack of audit record storage capacity, the network element must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner.\n\n2. If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the network element must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.\n\nA NAC is an essential security service and should not be shut down in the event of an audit failure. Redundancy and rollover features of the CounterACT enterprise or a high availability solution should be leveraged. Load balancing and redundancy is a function of the CounterAct enterprise architecture by default.",
+      "severity": "medium"
+    }
+  ]
+}

data/standards/stig_forescout_counteract_ndm.json

@@ -0,0 +1,239 @@
+{
+  "name": "stig_forescout_counteract_ndm",
+  "date": "2017-09-19",
+  "description": "This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.",
+  "title": "ForeScout CounterACT NDM Security Technical Implementation Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-76193",
+      "title": "For the local account, CounterACT must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.",
+      "description": "By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced.\n\nNonlocal account are configured on the authentication server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76195",
+      "title": "CounterACT must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the device.",
+      "description": "Display of the DoD-approved use notification before granting access to CounterACT ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.\n\nSystem use notifications are required only for access via logon interfaces with human users.",
+      "severity": "low"
+    },
+    {
+      "id": "V-76197",
+      "title": "CounterACT must enforce password complexity by requiring that at least one numeric character be used.",
+      "description": "Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76199",
+      "title": "CounterACT must enforce a 60-day maximum password lifetime restriction.",
+      "description": "Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed at specific intervals.\n\nOne method of minimizing this risk is to use complex passwords and periodically change them. If the network device does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the passwords could be compromised.\n\nThis requirement does not include root account or the account of last resort which are meant for access to the network device in case of failure.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76201",
+      "title": "CounterACT must prohibit password reuse for a minimum of five generations.",
+      "description": "Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nTo meet password policy requirements, passwords need to be changed at specific policy-based intervals.\n\nIf the network device allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76203",
+      "title": "CounterACT must enforce a minimum 15-character password length.",
+      "description": "Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password.\n\nThe shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76205",
+      "title": "CounterACT must enforce access restrictions associated with changes to the system components.",
+      "description": "Changes to the hardware or software components of the network device can have significant effects on the overall security of the network. Therefore, only qualified and authorized individuals should be allowed administrative access to the network device for implementing any changes or upgrades. This requirement applies to updates of the application files, configuration, ACLs, and policy filters.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76207",
+      "title": "CounterACT must generate audit log events for a locally developed list of auditable events.",
+      "description": "Auditing and logging are key components of any security architecture. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or identify an improperly configured network device. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis.",
+      "severity": "low"
+    },
+    {
+      "id": "V-76209",
+      "title": "CounterACT must support organizational requirements to conduct backups of system-level information contained in the information system when changes occur or weekly, whichever is sooner.",
+      "description": "System-level information includes default and customized settings and security attributes, including ACLs that relate to the network device configuration, as well as software required for the execution and operation of the device. Information system backup is a critical step in ensuring system integrity and availability. If the system fails and there is no backup of the system-level information, a denial of service condition is possible for all who use this critical network component.\n\nThis control requires the network device to support the organizational central backup process for system-level information associated with the network device. This function may be provided by the network device itself; however, the preferred best practice is a centralized backup rather than each network device performing discrete backups.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76211",
+      "title": "CounterACT must support organizational requirements to conduct backups of information system documentation, including security-related documentation, when changes occur or weekly, whichever is sooner.",
+      "description": "Information system backup is a critical step in maintaining data assurance and availability. Information system and security-related documentation contains information pertaining to system configuration and security settings. If this information were not backed up, and a system failure were to occur, the security settings would be difficult to reconfigure quickly and accurately. Maintaining a backup of information system and security-related documentation provides for a quicker recovery time when system outages occur.\n\nThis control requires the network device to support the organizational central backup process for user account information associated with the network device. This function may be provided by the network device itself; however, the preferred best practice is a centralized backup rather than each network device performing discrete backups.",
+      "severity": "low"
+    },
+    {
+      "id": "V-76213",
+      "title": "CounterACT must obtain its public key certificates from an appropriate certificate policy through an approved service provider.",
+      "description": "For user certificates, each organization obtains certificates from an approved, shared service provider, as required by OMB policy. For federal agencies operating a legacy public key infrastructure cross-certified with the Federal Bridge Certification Authority at medium assurance or higher, this certification authority will suffice.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76215",
+      "title": "CounterACT must obtain its public key certificates from an appropriate certificate policy through an approved service provider.",
+      "description": "For user certificates, each organization obtains certificates from an approved, shared service provider, as required by OMB policy. For federal agencies operating a legacy public key infrastructure cross-certified with the Federal Bridge Certification Authority at medium assurance or higher, this certification authority will suffice.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76217",
+      "title": "CounterACT must enable Threat Protection notifications to alert security personnel to Cyber events detected by a CounterACT IAW CJCSM 6510.01B.",
+      "description": "CJCSM 6510.01B, \"Cyber Incident Handling Program\", in subsection e.(6)(c) sets forth requirements for Cyber events detected by an automated system.\n\nBy immediately displaying an alarm message, potential security violations can be identified more quickly even when administrators are not logged into the network device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76219",
+      "title": "CounterACT appliances performing maintenance functions must restrict use of these functions to authorized personal only.",
+      "description": "There are security-related issues arising from software brought into the network device specifically for diagnostic and repair actions (e.g., a software packet sniffer installed on a device to troubleshoot system traffic or a vendor installing or running a diagnostic application to troubleshoot an issue with a vendor-supported device). If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system.\n\nThis requirement addresses security-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational network devices. Maintenance tools can include hardware, software, and firmware items. Maintenance tools are potential vehicles for transporting malicious code, either intentionally or unintentionally, into a facility and subsequently into organizational information systems. Maintenance tools can include, for example, hardware/software diagnostic test equipment and hardware/software packet sniffers.\n\nThis requirement does not cover hardware/software components that may support information system maintenance yet are a part of the system (e.g., the software implementing \"ping,\" \"ls,\" \"ipconfig,\" or the hardware and software implementing the monitoring port of an Ethernet switch).",
+      "severity": "high"
+    },
+    {
+      "id": "V-76221",
+      "title": "CounterACT must employ automated mechanisms to centrally apply authentication settings.",
+      "description": "The use of authentication servers or other centralized management servers for providing centralized authentication services is required for network device management. Maintaining local administrator accounts for daily usage on each network device without centralized management is not scalable or feasible. Without centralized management, it is likely that credentials for some network devices will be forgotten, leading to delays in administration, which leads to delays in remediating production problems and addressing compromises in a timely fashion.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76223",
+      "title": "CounterACT must disable all unnecessary and/or nonsecure plugins.",
+      "description": "CounterACT is capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services); however, doing so increases risk over limiting the services provided by any one component.\n\nIf the 802.1x plugin is installed and there are no wireless APs or controllers directly managed by CounterACT, the wireless plugin should be disabled. The wireless plugin enabled with no configuration will also produce a finding.",
+      "severity": "high"
+    },
+    {
+      "id": "V-76225",
+      "title": "CounterACT must terminate all network connections associated with an Enterprise Manager Console session upon Exit, or session disconnection, or after 10 minutes of inactivity, except where prevented by documented and validated mission requirements.",
+      "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 element.\n\nTerminating network connections associated with communications sessions includes, for example, deallocating associated TCP/IP address/port pairs at the operating system level or deallocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection. This does not mean that the device terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76227",
+      "title": "CounterACT must terminate all network connections associated with an SSH connection session upon Exit, session disconnection, or after 10 minutes of inactivity, except where prevented by documented and validated mission requirements.",
+      "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 element.\n\nTerminating network connections associated with communications sessions includes, for example, deallocating associated TCP/IP address/port pairs at the operating system level or deallocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection. This does not mean that the device terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76229",
+      "title": "CounterACT must allow only authorized administrators to view or change the device configuration, system files, and other files stored either in the device or on removable media.",
+      "description": "This protection is required to prevent unauthorized alteration, corruption, or disclosure of information when not stored directly on the network device.\n\nFiles on the network device or on removable media used by the device must have their permissions set to allow read or write access to those accounts that are specifically authorized to access or change them. Note that different administrative accounts or roles will have varying levels of access.\n\nFile permissions must be set so that only authorized administrators can read or change their contents. Whenever files are written to removable media and the media is removed from the device, the media must be handled appropriately for the classification and sensitivity of the data stored on the device.\n\nFlash drive usage must comply with DoD external storage and flash drive policy which includes permission to use and malware verification processes.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76231",
+      "title": "If any logs are stored locally which are not sent to the centralized audit server, CounterACT must back up audit records at least every seven days onto a different system or system component than the system or component being audited.",
+      "description": "Protection of log data includes ensuring log data is not accidentally lost or deleted. Regularly backing up audit records to a different system or onto separate media than the system being audited helps to ensure, in the event of a catastrophic system failure, the audit records will be retained.\n\nThis helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records.\n\nThis requirement can be met by using of a syslog/audit log server if the device is configured to send logs to that server.\n\nBackup requirements would be levied on the target server but are not a part of this check.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76233",
+      "title": "CounterACT must limit privileges to change the software resident within software libraries.",
+      "description": "Changes to any software components of the network device can have significant effects on the overall security of the network. Therefore, only qualified and authorized individuals should be allowed administrative access to the network device for implementing any changes or upgrades. If CounterACT were to enable unauthorized users to make changes to software libraries, those changes could be implemented without undergoing testing, validation, and approval.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76235",
+      "title": "CounterACT must enforce password complexity by requiring that at least one special character be used.",
+      "description": "Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76237",
+      "title": "CounterACT must sent audit logs to a centralized audit server (i.e., syslog server).",
+      "description": "Information stored in one location is vulnerable to accidental or incidental deletion or alteration.\n\nOff-loading is a common process in information systems with limited audit storage capacity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76239",
+      "title": "CounterACT must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC).",
+      "description": "If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis.\n\nTime stamps generated by the application include date and time. Time is expressed in UTC.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76241",
+      "title": "CounterACT must be configured to synchronize internal information system clocks with the organizations primary and secondary NTP servers.",
+      "description": "The loss of connectivity to a particular authoritative time source will result in the loss of time synchronization (free-run mode) and increasingly inaccurate time stamps on audit events and other functions.\n\nMultiple time sources provide redundancy by including a secondary source. Time synchronization is usually a hierarchy; clients synchronize time to a local source while that source synchronizes its time to a more accurate source. CounterACT appliances must use an authoritative time server and/or be configured to use redundant authoritative time sources. This requirement is related to the comparison done in CCI-001891.\n\nDoD-approved solutions consist of a combination of a primary and secondary time source using a combination or multiple instances of the following: a time server designated for the appropriate DoD network (NIPRNet/SIPRNet); United States Naval Observatory (USNO) time servers; and/or the Global Positioning System (GPS). The secondary time source must be located in a different geographic region than the primary time source.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76243",
+      "title": "CounterACT must restrict the ability to change the auditing to be performed within the system log based on selectable event criteria to the audit administrators role or to other roles or individuals.",
+      "description": "If authorized individuals do not have the ability to modify auditing parameters in response to a changing threat environment, the organization may not be able to effectively respond, and important forensic information may be lost.\n\nThis requirement enables organizations to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve information system resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, in near real time, within minutes, or within hours.\n\nThe individuals or roles to change the auditing are dependent on the security configuration of the network device. For example, it may be configured to allow only some administrators to change the auditing, while other administrators can review audit logs but not reconfigure auditing. Because this capability is so powerful, organizations should be extremely cautious about only granting this capability to fully authorized security personnel.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76245",
+      "title": "CounterACT must authenticate any endpoint used for network management before establishing a local, remote, and/or network connection using cryptographically based bidirectional authentication.",
+      "description": "Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk.\n\nA local connection is any connection with a device communicating without the use of a network. A network connection is any connection with a device that communicates through a network (e.g., local area or wide area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet).\n\nBecause of the challenges of applying this requirement on a large scale, organizations are encouraged to only apply the requirement to those limited number (and type) of devices that truly need to support this capability. For network device management, this has been determined to be network management device addresses, SNMP authentication, and NTP authentication. Use of non-secure versions of management protocols with well-known exploits puts the system at immediate risk.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76247",
+      "title": "CounterACT must authenticate SNMPv3 endpoint devices before establishing a local, remote, and/or network connection using bidirectional authentication that is cryptographically based.",
+      "description": "Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk.\n\nA local connection is any connection with a device communicating without the use of a network. A network connection is any connection with a device that communicates through a network (e.g., local area or wide area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet).\n\nFor network device management, this has been determined to be network management device addresses, SNMP authentication, and NTP authentication. Use of non-secure versions of management protocols with well-known exploits puts the system at immediate risk.",
+      "severity": "high"
+    },
+    {
+      "id": "V-76249",
+      "title": "In the event the authentication server is unavailable, one local account must be created for use as the account of last resort.",
+      "description": "Authentication for administrative (privileged-level) access to the device is required at all times. An account can be created on CounterACT'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. This account is referred to as the account of last resort since the emergency administration account is strictly intended to be used only as a last resort when immediate administrative access is absolutely necessary.\n\nThe number of local accounts is restricted to one.  The username and password for the emergency account is contained within a sealed envelope kept in a safe. All other users/groups should leverage the external directory. Remove any other accounts using Single-Local. The default admin account may be used to fulfill this requirement (requires DoD compliant password or cryptographically generated shared secret).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76251",
+      "title": "CounterACT must automatically lock the account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes are exceeded.",
+      "description": "By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76253",
+      "title": "The network device must terminate shared/group account credentials when members leave the group.",
+      "description": "A shared/group account credential is a shared form of authentication that allows multiple individuals to access the network device using a single account. If shared/group account credentials are not terminated when individuals leave the group, the user that left the group can still gain access even though they are no longer authorized. There may also be instances when specific user actions need to be performed on the network device without unique administrator identification or authentication. Examples of credentials include passwords and group membership certificates.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76255",
+      "title": "The network device must be configured to use a centralized authentication server to authenticate privileged users for remote and nonlocal access for device management.",
+      "description": "The use of authentication servers or other centralized management servers for providing centralized authentication services is required for network device management. Maintaining local administrator accounts for daily usage on each network device without centralized management is not scalable or feasible. Without centralized management, it is likely that credentials for some network devices will be forgotten, leading to delays in administration, which itself leads to delays in remediating production problems and in addressing compromises in a timely fashion.",
+      "severity": "low"
+    },
+    {
+      "id": "V-76257",
+      "title": "CounterACT must retain the Standard Mandatory DoD Notice and Consent Banner on the screen until the administrator acknowledges the usage conditions and takes explicit actions to log on for further access.",
+      "description": "The administrator must acknowledge the banner prior to CounterACT allowing the administrator access to CounterACT. This provides assurance that the administrator has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the administrator, DoD will not be in compliance with system use notifications required by law.\n\nTo establish acceptance of the network administration policy, a click-through banner at management session logon is required. The device must prevent further activity until the administrator executes a positive action to manifest agreement.\n\nIn the case of CLI access using a terminal client, entering the username and password when the banner is presented is considered an explicit action of acknowledgement. Entering the username, viewing the banner, and then entering the password is also acceptable.",
+      "severity": "low"
+    },
+    {
+      "id": "V-76259",
+      "title": "CounterACT must compare internal information systems clocks at least every 24 hours with an authoritative time server.",
+      "description": "Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events.\n\nSources outside of the configured acceptable allowance (drift) may be inaccurate. Additionally, unnecessary synchronization may have an adverse impact on system performance and may indicate malicious activity. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76261",
+      "title": "Administrative accounts for device management must be configured on the authentication server and not the network device itself (except for the account of last resort).",
+      "description": "The use of authentication servers or other centralized management servers for providing centralized authentication services is required for network device management. Maintaining local administrator accounts for daily usage on each network device without centralized management is not scalable or feasible. Without centralized management, it is likely that credentials for some network devices will be forgotten, leading to delays in administration, which leads to delays in remediating production problems and addressing compromises in a timely fashion.\n\nAdministrative accounts for network device management must be configured on the authentication server and not the network device itself. This requirement does not apply to the account of last resort.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76263",
+      "title": "If multifactor authentication is not supported and passwords must be used, CounterACT must enforce password complexity by requiring that at least one upper-case character be used.",
+      "description": "Use of a complex passwords helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76265",
+      "title": "If multifactor authentication is not supported and passwords must be used, CounterACT must enforce password complexity by requiring that at least one lower-case character be used.",
+      "description": "Some devices may not have the need to provide a group authenticator; this is considered a matter of device design. In those instances where the device design includes the use of a group authenticator, this requirement will apply. This requirement applies to accounts created and managed on or by the network device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-76267",
+      "title": "CounterACT must limit the number of concurrent sessions to an organization-defined number for each administrator account type.",
+      "description": "Network device management includes the ability to control the number of administrators and management sessions that manage a device. Limiting the number of allowed administrators and sessions per administrator is helpful in limiting risks related to DoS attacks.\n\nThis requirement addresses concurrent sessions for administrative accounts and does not address concurrent sessions by a single administrator via multiple administrative accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system.",
+      "severity": "low"
+    }
+  ]
+}