Intrusion Detection and Prevention Systems (IDPS) Security Requirements Guide

V2R4 2018-10-09       U_IDPS_SRG_V2R4_Manual-xccdf.xml
V2R0 2014-08-01       U_IDPS_V2R0.1_manual-xccdf.xml
The IDPS Security Requirements Guide (SRG) is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the NIST 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: [email protected]
Comparison
All 119
No Change 0
Updated 0
Added 60
Removed 59
V-34484 Added
Findings ID: SRG-NET-000018-IDPS-00018 Rule ID: SV-45260r2_rule Severity: medium CCI: CCI-001368

Discussion

The flow of all communications traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data. Restricting the flow of communications traffic, also known as Information flow control, regulates where information is allowed to travel as opposed to who is allowed to access the information and without explicit regard to subsequent accesses to that information. The IDPS will include policy filters, rules, signatures, and behavior analysis algorithms that inspects and restricts traffic based on the characteristics of the information and/or the information path as it crosses internal network boundaries. The IDPS monitors for harmful or suspicious information flows and restricts or blocks this traffic based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.

Checks

Verify the IDPS enforces approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic within the network as defined in the PPSM CAL and vulnerability assessments. If the IDPS does not enforce approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic within the network as defined in the PPSM CAL and vulnerability assessments, this is a finding.

Fix

Configure the IDPS to enforce approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic within the network as defined in the PPSM CAL and vulnerability assessments.
V-34485 Added
Findings ID: SRG-NET-000019-IDPS-00019 Rule ID: SV-45262r2_rule Severity: medium CCI: CCI-001414

Discussion

The IDPS enforces approved authorizations by controlling the flow of information between interconnected networks to prevent harmful or suspicious traffic does spread to these interconnected networks. Information flow control policies and restrictions govern where information is allowed to travel as opposed to who is allowed to access the information. The IDPS includes policy filters, rules, signatures, and behavior analysis algorithms that inspects and restricts traffic based on the characteristics of the information and/or the information path as it crosses external/perimeter boundaries. IDPS components are installed and configured such that they restrict or block detected harmful or suspect information flows based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.

Checks

Verify the IDPS enforces approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic for controlling the flow of information between interconnected networks as defined in the PPSM CAL and vulnerability assessments. If the IDPS does not enforce approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic for controlling the flow of information between interconnected networks as defined in the PPSM CAL and vulnerability assessments, this is a finding.

Fix

Configure the IDPS to enforce approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic for controlling the flow of information between interconnected networks as defined in the PPSM CAL and vulnerability assessments.
V-34540 Added
Findings ID: SRG-NET-000074-IDPS-00059 Rule ID: SV-45382r2_rule Severity: medium CCI: CCI-000130

Discussion

Without establishing what type of event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Associating an event type with each event log entry provides a means of investigating an attack or identifying an improperly configured IDPS. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.

Checks

Verify the entries sent to the audit log include, at a minimum, event descriptions, policy filter, rule or signature invoked, port, protocol, criticality level/alert code or description. If the audit log event records does not include, at a minimum, event descriptions, policy filter, rule signature invoked, port, protocol, and criticality level/alert code or description, this is a finding.

Fix

Configure the IDPS components to ensure entries sent to the audit log include sufficient information to determine the type or category for each audit event recorded in the audit log, including, at a minimum, event descriptions, policy filter, rule or signature invoked, port, protocol, and criticality level/alert code or description.
V-34541 Added
Findings ID: SRG-NET-000075-IDPS-00060 Rule ID: SV-45383r2_rule Severity: medium CCI: CCI-000131

Discussion

Without establishing the time (date/time) an event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Associating the date and time the event occurred with each event log entry provides a means of investigating an attack or identifying an improperly configured IDPS. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.

Checks

Verify the entries sent to the audit log include the date and time of each event. If the audit log event records do not include the date and time the events occurred, this is a finding.

Fix

Configure the IDPS components to include the date time stamp of events in log messages.
V-34542 Added
Findings ID: SRG-NET-000076-IDPS-00061 Rule ID: SV-45384r2_rule Severity: medium CCI: CCI-000132

Discussion

Associating where the event was detected with the event log entries provides a means of investigating an attack or identifying an improperly configured IDPS. This information can be used to determine what systems may have been affected. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.

Checks

Verify the IDPS produces audit records containing information to establish where the event was detected, including, at a minimum, network segment, destination address, and IDPS component which detected the event. If the audit log events do not include information which establishes where the event was detected, including, at a minimum, network segment, destination address, and IDPS component which detected the event, this is a finding.

Fix

Configure the IDPS to produce audit records containing information to establish where the event was detected, including, at a minimum, network segment, destination address, and IDPS component which detected the event.
V-34543 Added
Findings ID: SRG-NET-000077-IDPS-00062 Rule ID: SV-45385r2_rule Severity: medium CCI: CCI-000133

Discussion

Associating the source of the event with detected events in the logs provides a means of investigating an attack or suspected attack. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.

Checks

Verify configuration produces audit records containing information to establish the source of the event, including, at a minimum, originating source address. If the IDPS does not produce audit records containing information to establish the source of the event, including, at a minimum, originating source address, this is a finding.

Fix

Configure the IDPS to produce audit records containing information to establish the source of the event, including, at a minimum, originating source address.
V-34544 Added
Findings ID: SRG-NET-000078-IDPS-00063 Rule ID: SV-45386r2_rule Severity: medium CCI: CCI-000134

Discussion

Associating event outcome with detected events in the log provides a means of investigating an attack or suspected attack. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail. The logs should identify what servers, destination addresses, applications, or databases were potentially attacked by logging communications traffic between the target and the attacker. All commands that were entered by the attacker (such as account creations, changes in permissions, files accessed, etc.) during the session should also be logged.

Checks

Verify the entries sent to the audit log include, at a minimum, capturing all associated communications traffic. If the audit log event records do not include, at a minimum, capturing all associated communications traffic, this is a finding.

Fix

Configure the IDPS components to ensure entries sent to the audit log include, at a minimum, capturing all associated communications traffic.
V-34555 Added
Findings ID: SRG-NET-000089-IDPS-00069 Rule ID: SV-45397r2_rule Severity: medium CCI: CCI-000140

Discussion

It is critical that when the IDPS is at risk of failing to process audit logs as required, it takes action to mitigate the failure. The IDPS performs a critical security function, so its continued operation is imperative. Since availability of the IDPS is an overriding concern, shutting down the system in the event of an audit failure should be avoided, except as a last resort.

Checks

Verify the IDPS, in the event of a logging failure caused by the lack of audit record storage capacity, continues generating and storing audit records and overwriting the oldest audit records in a first-in-first-out manner. In the event of a logging failure caused by the lack of audit record storage capacity, if the IDPS does not continue generating and storing audit records and overwriting the oldest audit records in a first-in-first-out manner, this is a finding.

Fix

Configure the IDPS to, in the event of a logging failure caused by the lack of audit record storage capacity, continue generating and storing audit records and overwriting the oldest audit records in a first-in-first-out manner.
V-34594 Added
Findings ID: SRG-NET-000113-IDPS-00082 Rule ID: SV-45458r2_rule Severity: medium CCI: CCI-000169

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail. The IDPS must have the capability to capture and log events where communications traffic was blocked or restricted because of a security violation or potential security violations.

Checks

Verify the configuration provides audit record generation capability for events where communication traffic is blocked or restricted based on policy filters, rules, signatures, and anomaly analysis algorithms. If the IDPS does not provide audit record generation capability for events where communication traffic is blocked or restricted based on policy filters, rules, signatures, and anomaly analysis, this is a finding.

Fix

Configure the IDPS to provide audit record generation capability for events where communication traffic is blocked or restricted based on policy filters, rules, signatures, and anomaly analysis algorithms.
V-34625 Added
Findings ID: SRG-NET-000131-IDPS-00097 Rule ID: SV-45500r2_rule Severity: medium CCI: CCI-000381

Discussion

An IDPS can be capable of providing a wide variety of capabilities. Not all of these capabilities are necessary. Unnecessary services, functions, and applications increase the attack surface (sum of attack vectors) of a system. These unnecessary capabilities are often overlooked and therefore may remain unsecured. This requirement applies to unnecessary features of the IDPS application itself.

Checks

Verify the IDPS is configured to remove or disable non-essential features, functions, and services of the IDPS application. If the IDPS is not configured to remove or disable non-essential features, functions, and services of the IDPS application, this is a finding.

Fix

Configure the IDPS to remove or disable non-essential features, functions, and services of the IDPS application.
V-34707 Added
Findings ID: SRG-NET-000192-IDPS-00140 Rule ID: SV-45593r2_rule Severity: medium CCI: CCI-001095

Discussion

The IDPS must include protection against DoS attacks that originate from inside the enclave which can affect either internal or external systems. These attacks may use legitimate or rogue endpoints from inside the enclave. Installation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type. To comply with this requirement, the IDPS must inspect outbound traffic for indications of known and unknown DoS attacks. Sensor log capacity management along with techniques which prevent the logging of redundant information during an attack also guard against DoS attacks. This requirement is used in conjunction with other requirements which require configuration of security policies, signatures, rules, and anomaly detection techniques and are applicable to both inbound and outbound traffic.

Checks

Verify the IDPS blocks outbound traffic containing known and unknown DoS attacks by ensuring that security policies, signatures, rules, and anomaly detection techniques are applied to outbound communications traffic. If the IDPS does not block outbound traffic containing known and unknown DoS attacks, by ensuring that security policies, signatures, rules, and anomaly detection techniques are applied to outbound communications traffic, this is a finding.

Fix

Configure the IDPS to block outbound traffic containing known and unknown DoS attacks, by ensuring that security policies, signatures, rules, and anomaly detection techniques are applied to outbound communications traffic.
V-34743 Added
Findings ID: SRG-NET-000229-IDPS-00163 Rule ID: SV-45652r2_rule Severity: medium CCI: CCI-001662

Discussion

Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations, Shockwave videos, and macros embedded within Microsoft Office documents. Mobile code can be exploited to attack a host. It can be sent as an e-mail attachment or embedded in other file formats not traditionally associated with executable code. While the IDPS cannot replace the anti-virus and host-based IDS (HIDS) protection installed on the network's endpoints, vendor or locally created sensor rules can be implemented, which provide preemptive defense against both known and zero-day vulnerabilities. Many of the protections may provide defenses before vulnerabilities are discovered and rules or blacklist updates are distributed by anti-virus or malicious code solution vendors. To block known prohibited mobile code or approved mobile code that violates permitted usage requirements, the IDPS must implement policy filters, rules, signatures, and anomaly analysis.

Checks

Verify the IDPS blocks any prohibited mobile code at the enclave boundary when it is detected. If the IDPS does not block any prohibited mobile code at the enclave boundary when it is detected, this is a finding.

Fix

Configure the IDPS to block any prohibited mobile code at the enclave boundary when it is detected.
V-34749 Added
Findings ID: SRG-NET-000235-IDPS-00169 Rule ID: SV-45659r3_rule Severity: medium CCI: CCI-001190

Discussion

Failure to a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. Preserving information system state information also facilitates system restart and return to the operational mode of the organization with less disruption to mission-essential processes. This requirement applies to the device itself, not the network traffic. Abort refers to stopping a program or function before it has finished naturally. The term abort refers to both requested and unexpected terminations. Since it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.

Checks

Verify the IDPS fails to a secure state which maintains access control mechanisms when the IDPS hardware, software, or firmware fails on initialization/shutdown or experiences a sudden abort during normal operation. If the IDPS does not fail to a secure state which maintains access control mechanisms when the IDPS hardware, software, or firmware fails on initialization/shutdown or experiences a sudden abort during normal operation, this is a finding.

Fix

Configure the IDPS to fail to a secure state which maintains access control mechanisms when the IDPS hardware, software, or firmware fails on initialization/shutdown or experiences a sudden abort during normal operation.
V-34750 Added
Findings ID: SRG-NET-000236-IDPS-00170 Rule ID: SV-45660r2_rule Severity: medium CCI: CCI-001665

Discussion

Failure in a secure state address safety or security in accordance with the mission needs of the organization. Failure to a secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving state information helps to facilitate the restart of the IDPS application and a return to operation with minimum disruption. This requirement applies to a failure of the IDPS function rather than the device or operating system as a whole which is addressed in the Network Device Management SRG. Since it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.

Checks

Verify the IDPS, upon failure of the IDPS function, saves diagnostic information, logs system messages, and loads the most current security policies, rules, and signatures when restarted. If IDPS function, upon system failure, does not save diagnostic information, log system messages, and load the most current security policies, rules, and signatures when restarted, this is a finding.

Fix

Configure the IDPS to, upon failure of the IDPS function, save diagnostic information, log system messages, and load the most current security policies, rules, and signatures when restarted.
V-34759 Added
Findings ID: SRG-NET-000246-IDPS-00175 Rule ID: SV-45683r2_rule Severity: medium CCI: CCI-001240

Discussion

If the integrity of updates downloaded directly from the vendor is not verified, then malicious code or errors may impact the ability of the IDPS to protect against harmful communication traffic. The recommended verification method depends on the update's format, as follows: 1. For files downloaded from a Web site or FTP site, administrators should compare file checksums provided by the vendor with checksums that they compute for the downloaded files. 2. For updates downloaded automatically through the IDPS user interface, if an update is downloaded as a single file or a set of files, either checksum provided by the vendor should be compared to checksums generated by the administrator, or the IDPS user interface itself should perform some sort of integrity check. In some cases, updates are downloaded and installed as one action, precluding checksum verification. In this case, the IDPS user interface should check each update' s integrity as part of this process. 3. In the case of removable media (e.g., CD, DVD), vendors may not provide a specific method for customers to verify the legitimacy of removable media apparently sent by the vendors. If media verification is a concern, administrators should contact their vendors to determine how the media can be verified, such as comparing vendor-provided checksums to checksums computed for files on the media, or verifying digital signatures on the media's contents to ensure they are valid. Administrators should also consider scanning the media for malware, with the caveat that false positives may be triggered by IDPS signatures for malware on the media.

Checks

Verify the IDPS verifies the integrity of updates obtained directly from the vendor. If the IDPS does not verify the integrity of updates obtained directly from the vendor, this is a finding.

Fix

Configure the IDPS to verify the integrity of updates obtained directly from the vendor.
V-34762 Added
Findings ID: SRG-NET-000249-IDPS-00176 Rule ID: SV-45686r2_rule Severity: medium CCI: CCI-001243

Discussion

Configuring the IDPS to delete and/or quarantine based on local organizational incident handling procedures minimizes the impact of this code on the network.

Checks

Verify the IDPS blocks malicious code. If the IDPS does not block malicious code, this is a finding.

Fix

Configure the IDPS to block malicious code.
V-34788 Added
Findings ID: SRG-NET-000273-IDPS-00198 Rule ID: SV-45716r2_rule Severity: medium CCI: CCI-001312

Discussion

Internet Control Message Protocol (ICMP) messages are used to provide feedback about problems in the network. These messages are sent back to the sender to support diagnostics. However, some messages can also provide host information and network topology that may be exploited by an attacker. An IDPS must be configured to "silently drop" the packet and not send an ICMP control message back to the source. In some cases, it may be necessary to direct the traffic to a null interface. Three ICMP messages are commonly used by attackers for network mapping: Destination Unreachable, Redirect, and Address Mask Reply. These responses must be blocked on external interfaces; however, blocking the Destination Unreachable response will prevent Path Maximum Transmission Unit Discovery (PMTUD), which relies on the response "ICMP Destination Unreachable--Fragmentation Needed but DF Bit Set". PMTUD is a useful function and should only be "broken" after careful consideration. An acceptable alternative to blocking all Destination Unreachable responses is to filter Destination Unreachable messages generated by the IDPS to allow ICMP Destination Unreachable--Fragmentation Needed but DF Bit Set (Type 3, Code 4) and apply this filter to the external interfaces.

Checks

Verify the IDPS blocks outbound ICMP Destination Unreachable, Redirect, and Address Mask reply messages. If the IDPS does not block outbound ICMP Destination Unreachable, Redirect, and Address Mask reply messages, this is a finding.

Fix

Configure the IDPS to block outbound ICMP Destination Unreachable, Redirect, and Address Mask reply messages. An acceptable alternative to blocking all Destination Unreachable responses is to filter Destination Unreachable messages generated by the firewall implementation to allow ICMP Destination Unreachable-- Fragmentation Needed but DF Bit Set (Type 3, Code 4) and apply this filter to the external interfaces.
V-55317 Added
Findings ID: SRG-NET-000019-IDPS-00187 Rule ID: SV-69563r1_rule Severity: medium CCI: CCI-001414

Discussion

Information flow policies regarding dynamic information flow control include, for example, allowing or disallowing information flows based on changes to the PPSM CAL, vulnerability assessments, or mission conditions. Changing conditions include changes in the threat environment and detection of potentially harmful or adverse events. Changes to the IDPS must take effect when made by an authorized administrator and the new configuration is put in place or committed, including upon restart or the application or reboot of the system. With some devices, the changes take effect as the configuration is changed, while with others, the new configuration must be submitted to the device. In any case, the behavior of the IDPS must immediately be affected to reflect the configuration change.

Checks

Verify the IDPS immediately uses updates made to policy filters, rules, signatures, and anomaly analysis algorithms for traffic detection and prevention functions. If the IDPS does not immediately use updates made to policy filters, rules, signatures, and anomaly analysis algorithms to traffic detection and prevention functions, this is a finding.

Fix

Configure the IDPS to immediately use updates made to policy filters, rules, signatures, and anomaly analysis algorithms for traffic detection and prevention functions.
V-55319 Added
Findings ID: SRG-NET-000113-IDPS-00013 Rule ID: SV-69565r1_rule Severity: medium CCI: CCI-000169

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail. The IDPS must have the capability to capture and log detected security violations and potential security violations.

Checks

Verify the configuration provides audit record generation capability for detection events based on implementation of policy filters, rules, signatures, and anomaly analysis. If the IDPS does not provide audit record generation capability for detection events based on implementation of policy filters, rules, signatures, and anomaly analysis, this is a finding.

Fix

Configure the IDPS to provide audit record generation capability for detection events based on implementation of policy filters, rules, signatures, and anomaly analysis.
V-55321 Added
Findings ID: SRG-NET-000113-IDPS-00189 Rule ID: SV-69567r2_rule Severity: medium CCI: CCI-000169

Discussion

Without the capability to generate audit records with a severity code it is difficult to track and handle detection events. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail. The IDPS must have the capability to collect and log the severity associated with the policy, rule, or signature. IDPS products often have either pre-configured and/or a configurable method for associating an impact indicator or severity code with signatures and rules, at a minimum.

Checks

Verify the configuration provides audit record generation with a configurable severity and escalation level capability. If the IDPS does not provide audit record generation with a configurable severity and escalation level capability, this is a finding.

Fix

Configure the IDPS to provide audit record generation with a configurable severity and escalation level capability.
V-55323 Added
Findings ID: SRG-NET-000333-IDPS-00190 Rule ID: SV-69569r1_rule Severity: medium CCI: CCI-001844

Discussion

Without the ability to centrally manage the content captured in the log records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an attack. Centralized management and storage of log records increases efficiency in maintenance and management of records as well as facilitates the backup and archiving of those records. The IDPS must be configured to support centralized management and configuration of the content to be captured in audit records generated by all network components. IDPS sensors and consoles must have the capability to support centralized logging. They must be configured to send log messages to centralized, redundant servers and be capable of being remotely configured to change logging parameters (such as facility and severity levels).

Checks

Verify the IDPS is configured to support centralized management and configuration of the content captured in audit records generated by all IDPS components. If the IDPS does not support centralized management and configuration of the content captured in audit records generated by all IDPS components, this is a finding.

Fix

Configure the IDPS to support centralized management and configuration of the content captured in audit records generated by all IDPS components.
V-55325 Added
Findings ID: SRG-NET-000334-IDPS-00191 Rule ID: SV-69571r1_rule Severity: medium CCI: CCI-001851

Discussion

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading ensures audit information does not get overwritten if the limited audit storage capacity is reached and also protects the audit record in case the system/component being audited is compromised. This also prevents the log records from being lost if the logs stored locally are accidentally or intentionally deleted, altered, or corrupted.

Checks

Verify the IDPS off-loads log records to a centralized log server. If the IDPS does not off-load log records to a centralized log server, this is a finding.

Fix

Configure the IDPS to off-load log records to a centralized log server.
V-55327 Added
Findings ID: SRG-NET-000511-IDPS-00012 Rule ID: SV-69573r1_rule Severity: medium CCI: CCI-001851

Discussion

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. Off-loading is a common process in information systems with limited audit storage capacity. The audit storage on the IDPS is used only in a transitory fashion until the system can communicate with the centralized log server designated for storing the audit records, at which point the information is transferred. However, DoD requires that the log be transferred in real-time which indicates that the time from event detection to off-loading is seconds or less. This does not apply to audit logs generated on behalf of the device itself (management).

Checks

Verify the IDPS off-loads log records to a centralized log server in real-time. If the IDPS does not off-load log records to a centralized log server in real-time, this is a finding.

Fix

Configure the IDPS to off-load log records to a centralized log server in real-time.
V-55329 Added
Findings ID: SRG-NET-000335-IDPS-00223 Rule ID: SV-69575r1_rule Severity: medium CCI: CCI-001858

Discussion

It is critical that when the IDPS is at risk of failing to process audit logs as required, it takes action to mitigate the failure Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Since action must be taken immediately, these messages will be designated as a critical severity level and this level must be sent as part of the alert message.

Checks

Verify the IDPS provides assign a critical severity level to all audit processing failures. If the IDPS does not assign a critical severity level to all audit processing failures, this is a finding.

Fix

Configure the IDPS to assign a critical severity level to all audit processing failures.
V-55331 Added
Findings ID: SRG-NET-000335-IDPS-00014 Rule ID: SV-69577r2_rule Severity: medium CCI: CCI-001858

Discussion

Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis may be impeded. This requirement includes, but is not limited to, failures where the detection and/or prevention function is unable to write events to either local storage or the centralized server. The IDPS must generate an alert which will notify designated personnel of the logging failure. Alerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less). Alert messages must include the severity level. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSO.

Checks

Verify the IDPS provides an immediate real-time alert to, at a minimum, the SCA and ISSO when any audit failure events occur. If the IDPS does not provide an immediate real-time alert to, at a minimum, the SCA and ISSO when any audit failure events occur, this is a finding.

Fix

Configure the IDPS to provide an immediate real-time alert to, at a minimum, the SCA and ISSO when any audit failure events occur.
V-55333 Added
Findings ID: SRG-NET-000089-IDPS-00010 Rule ID: SV-69579r1_rule Severity: medium CCI: CCI-000140

Discussion

It is critical that when the IDPS is at risk of failing to process audit logs as required, it take action to mitigate the failure. 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. The IDPS performs a critical security function, so its continued operation is imperative. Since availability of the IDPS is an overriding concern, shutting down the system in the event of an audit failure should be avoided, except as a last resort. The SYSLOG protocol does not support automated synchronization, however this functionality may be provided by Network Management Systems (NMSs) which are not within the scope of this SRG.

Checks

Verify the IDPS, in the event of a logging failure caused by loss of communications with the central logging server, queues audit records locally until communication is restored or until the audit records are retrieved manually or using automated synchronization tools. In the event of a logging failure caused by loss of communications with the central logging server, if the IDPS does not queue audit records locally until communication is restored or until the audit records are retrieved manually or using automated synchronization tools, this is a finding.

Fix

Configure the IDPS, in the event of a logging failure caused by loss of communications with the central logging server, to queue audit records locally until communication is restored or until the audit records are retrieved manually or using automated synchronization tools.
V-55335 Added
Findings ID: SRG-NET-000091-IDPS-00193 Rule ID: SV-69581r1_rule Severity: medium CCI: CCI-000154

Discussion

Centralized review and analysis of log records from multiple IDPS components gives the organization the capability to better detect distributed attacks and provides increased data points for behavior analysis techniques. These techniques are invaluable in monitoring for indicators of complex attack patterns. To support the centralized analysis capability, the IDPS components must be able to provide the information in a format (e.g., Syslog) that can be extracted and used, allowing the application to effectively review and analyze the log records.

Checks

Verify the IDPS provides log information in a format that can be extracted and used by centralized analysis tools. If the IDPS does not provide log information in a format that can be extracted and used by centralized analysis tools, this is a finding.

Fix

Configure the IDPS to provide log information in a format that can be extracted and used by centralized analysis tools.
V-55337 Added
Findings ID: SRG-NET-000512-IDPS-00194 Rule ID: SV-69583r1_rule Severity: medium CCI: CCI-000366

Discussion

Configuring the IDPS to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the network element. Security-related parameters are those parameters impacting the security state of the network element, including the parameters required to satisfy other security control requirements. For the network element, security-related parameters include settings for communications traffic management configurations.

Checks

Verify the IDPS is configured in accordance with the security configuration settings based on DoD security policy and technology-specific security best practices. If the IDPS is not configured in accordance with the security configuration settings based on DoD security policy and technology-specific security best practices, this is a finding.

Fix

Configure the IDPS to comply with the security configuration settings based on DoD security policy and technology-specific security best practices.
V-55339 Added
Findings ID: SRG-NET-000131-IDPS-00011 Rule ID: SV-69585r1_rule Severity: medium CCI: CCI-000381

Discussion

An IDPS can be capable of providing a wide variety of capabilities. Not all of these capabilities are necessary. Unnecessary services, functions, and applications increase the attack surface (sum of attack vectors) of a system. These unnecessary capabilities are often overlooked and therefore may remain unsecured.

Checks

Have the SCA display the services running on the IDPS components. Review the IDPS configuration to determine if non-essential capabilities not required for operation, or not related to IDPS functionality (e.g., DNS, email client or server, FTP server, or web server) are enabled. If the IDPS is not configured to remove or disable non-essential capabilities which are not required for operation or not related to IDPS functionality (e.g., DNS, email client or server, FTP server, or web server), this is a finding.

Fix

Remove or disable non-essential capabilities from the IDPS. Removal is recommended since the service or function may be inadvertently enabled. However, if removal is not possible, disable the service or function. Document all necessary services.
V-55341 Added
Findings ID: SRG-NET-000132-IDPS-00195 Rule ID: SV-69587r1_rule Severity: medium CCI: CCI-000382

Discussion

Some ports, protocols, or services have known exploits or security weaknesses. These ports, protocols, and services must be prohibited or restricted in the IDPS configuration in accordance with DoD policy. Policy filters restrict traffic destined to the enclave perimeter in accordance with the guidelines contained in DoD Instruction 8551.1 for all ports, protocols, and functions. SCAs will review the vulnerability assessment for each port allowed into the enclave and apply all appropriate mitigations defined in the Vulnerability Assessment report. Only ports, protocols, and functions allowed into the enclave should be registered in the PPSM database. It is the responsibility of the enclave owner to have the applications the enclave uses registered in the PPSM database.

Checks

Verify the IDPS is configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments. If the IDPS is not configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments, this is a finding.

Fix

Configure the IDPS to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments.
V-55343 Added
Findings ID: SRG-NET-000228-IDPS-00196 Rule ID: SV-69589r1_rule Severity: medium CCI: CCI-001166

Discussion

Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations, Shockwave videos, and macros embedded within Microsoft Office documents. Mobile code can be exploited to attack a host. It can be sent as an e-mail attachment or embedded in other file formats not traditionally associated with executable code. While the IDPS cannot replace the anti-virus and host-based IDS (HIDS) protection installed on the network's endpoints, vendor or locally created sensor rules can be implemented, which provide preemptive defense against both known and zero-day vulnerabilities. Many of the protections may provide defenses before vulnerabilities are discovered and rules or blacklist updates are distributed by anti-virus or malicious code solution vendors. To monitor for and detect known prohibited mobile code or approved mobile code that violates permitted usage requirements, the IDPS must implement policy filters, rules, signatures, and anomaly analysis.

Checks

Verify the IDPS detects, at a minimum, mobile code that is unsigned or exhibiting unusual behavior, has not undergone a risk assessment, or is prohibited for use based on a risk assessment. If the IDPS does not detect, at a minimum, mobile code that is unsigned or exhibiting unusual behavior, has not undergone a risk assessment, or is prohibited for use based on a risk assessment, this is a finding.

Fix

Configure the IDPS to detects, at a minimum, mobile code that is unsigned or exhibiting unusual behavior, has not undergone a risk assessment, or are prohibited for use based on a risk assessment.
V-55345 Added
Findings ID: SRG-NET-000362-IDPS-00196 Rule ID: SV-69591r1_rule Severity: medium CCI: CCI-002385

Discussion

If the network does not provide safeguards against DoS attack, network resources will be unavailable to users. Installation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type. Detection components that use rate-based behavior analysis can detect attacks when signatures for the attack do not exist or are not installed. These attacks include zero-day attacks which are new attacks for which vendors have not yet developed signatures. Rate-based behavior analysis can detect sophisticated, Distributed DoS (DDoS) attacks by correlating traffic information from multiple network segments or components. This requirement applies to the communications traffic functionality of the IDPS as it pertains to handling communications traffic, rather than to the IDPS device itself.

Checks

Verify the IDPS protects against or limits the effects of known and unknown types of DoS attacks by employing rate-based attack prevention behavior analysis. If the device does not protect against or limit the effects of known and unknown types of DoS attacks by employing rate-based attack prevention behavior analysis, this is a finding.

Fix

Configure the IDPS to protect against or limit the effects of known and unknown types of DoS attacks by employing rate-based attack prevention behavior analysis.
V-55347 Added
Findings ID: SRG-NET-000362-IDPS-00197 Rule ID: SV-69593r2_rule Severity: medium CCI: CCI-002385

Discussion

If the network does not provide safeguards against DoS attack, network resources will be unavailable to users. Installation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks. Detection components that use anomaly-based attack detection can detect attacks when signatures for the attack do not exist or are not installed. These attacks include zero-day attacks which are new attacks for which vendors have not yet developed signatures. This requirement applies to the communications traffic functionality of the IDPS as it pertains to handling communications traffic, rather than to the IDPS device itself.

Checks

Verify the IDPS protect against or limits the effects of known and unknown types of DoS attacks by employing, also known as anomaly-based detection. If the device does not protect against or limit the effects of known and unknown types of DoS attacks by employing anomaly-based detection, this is a finding.

Fix

Configure the IDPS to protect against or limit the effects of known and unknown types of DoS attacks by employing anomaly-based detection.
V-55349 Added
Findings ID: SRG-NET-000362-IDPS-00198 Rule ID: SV-69595r1_rule Severity: medium CCI: CCI-002385

Discussion

If the network does not provide safeguards against DoS attack, network resources will be unavailable to users. Installation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume, type, or protocol usage. Detection components that use signatures can detect known attacks by using known attack signatures. Signatures are usually obtained from and updated by the IDPS component vendor. These attacks include SYN-flood, ICMP-flood, and Land Attacks. This requirement applies to the communications traffic functionality of the IDPS as it pertains to handling communications traffic, rather than to the IDPS device itself.

Checks

Verify the IDPS protects against or limits the effects of known types of DoS attacks by employing signatures. If the device does not protect against or limit the effects of known types of DoS attacks by employing signatures, this is a finding.

Fix

Configure the IDPS to protect against or limit the effects of known types of DoS attacks by employing signatures.
V-55351 Added
Findings ID: SRG-NET-000401-IDPS-00203 Rule ID: SV-69597r1_rule Severity: medium CCI: CCI-001310

Discussion

Packet fragmentation is allowed by the TCP/IP specifications and is encouraged in situations where it is needed. However, packet fragmentation has been used to make some attacks harder to detect (by placing them within fragmented packets), and unusual fragmentation has also been used as a form of attack. For example, some network-based attacks have used packets that should not exist in normal communications, such as sending some fragments of a packet but not the first fragment, or sending packet fragments that overlap each other. These, and other types of packet fragmentation, aim to evade the IDPS. Since it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.

Checks

Verify the IDPS, for fragmented packets, either blocks the packets or properly reassembles the packets before inspecting and forwarding. For fragmented packets, if the IDPS does not either block the packets or properly reassemble the packets before inspecting and forwarding, this is a finding.

Fix

Configure the IDPS to, for fragmented packets, either block the packets or properly reassemble the packets before inspecting and forwarding.
V-55355 Added
Findings ID: SRG-NET-000273-IDPS-00204 Rule ID: SV-69601r1_rule Severity: medium CCI: CCI-001312

Discussion

Internet Control Message Protocol (ICMP) messages are used to provide feedback about problems in the network. These messages are sent back to the sender to support diagnostics. However, some messages can also provide host information, network topology, and a covert channel that may be exploited by an attacker. Given the prevalence of ICMP traffic on the network, monitoring for malicious ICMP traffic would be cumbersome. Vendors provide signatures and rules which filter for known ICMP traffic exploits.

Checks

Verify the IDPS blocks malicious ICMP packets by properly configuring ICMP signatures and rules. If the IDPS does not block malicious ICMP packets by properly configuring ICMP signatures and rules, this is a finding.

Fix

Configure the IDPS to block malicious ICMP packets by properly configuring ICMP signatures and rules.
V-55357 Added
Findings ID: SRG-NET-000246-IDPS-00205 Rule ID: SV-69603r1_rule Severity: medium CCI: CCI-001240

Discussion

Failing to update malicious code protection mechanisms, including application software files, signature definitions, and vendor-provided rules, leaves the system vulnerable to exploitation by recently developed attack methods and programs. The IDPS is a key malicious code protection mechanism in the enclave infrastructure. To ensure this protection is responsive to changes in malicious code threats, IDPS components must be updated, including application software files, anti-virus signatures, detection heuristics, vendor-provided rules, and vendor-provided signatures. Updates must be installed in accordance with the CCB procedures for the local organization. However, at a minimum: 1. Updates designated as critical security updates by the vendor must be installed immediately. 2. Updates for signature definitions, detection heuristics, and vendor-provided rules must be installed immediately. 3. Updates for application software are installed in accordance with the CCB procedures. 4. Prior to automatically installing updates, either manual or automated integrity and authentication checking is required, at a minimum, for application software updates.

Checks

Verify the IDPS installs updates for application software files, signature definitions, detection heuristics, and vendor-provided rules when new releases are available in accordance with organizational configuration management policy and procedures. If the IDPS does not install updates for application software files, signature definitions, detection heuristics, and vendor-provided rules when new releases are available in accordance with organizational configuration management policy and procedures, this is a finding.

Fix

Configure the IDPS to install updates for application software files, signature definitions, detection heuristics, and vendor-provided rules when new releases are available in accordance with organizational configuration management policy and procedures.
V-55359 Added
Findings ID: SRG-NET-000248-IDPS-00206 Rule ID: SV-69605r1_rule Severity: medium CCI: CCI-001242

Discussion

Real-time monitoring of files from external sources at network entry/exit points helps to detect covert malicious code before it is downloaded to or executed by internal and external endpoints. Using malicious code, such as viruses, worms, Trojan horses, and spyware, an attacker may gain access to sensitive data and systems. IDPSs innately meet this requirement for real-time scanning for malicious code when properly configured to meet the requirements of this SRG. However, most products perform communications traffic inspection at the packet level.

Checks

Verify the IDPS performs real-time monitoring of files from external sources at network entry/exit points. If the IDPS does not perform real-time monitoring of files from external sources at network entry/exit points, this is a finding.

Fix

Configure the IDPS to perform real-time monitoring of files from external sources at network entry/exit points.
V-55361 Added
Findings ID: SRG-NET-000249-IDPS-00221 Rule ID: SV-69607r1_rule Severity: medium CCI: CCI-001243

Discussion

Configuring the network element to delete and/or quarantine based on local organizational incident handling procedures minimizes the impact of this code on the network. Malicious code includes, but is not limited to, viruses, worms, Trojan horses, and spyware. The code provides the ability for a malicious user to read from and write to files and folders on a computer's hard drive. Malicious code may also be able to run and attach programs, which may allow the unauthorized distribution of malicious mobile code. Sometimes it is necessary to generate a log event and then automatically delete the malicious code; however, for critical attacks or where forensic evidence is deemed necessary, the preferred action is for the file to be quarantined for further investigation. This requirement is limited to network elements that perform security functions, such as ALG and IDPS.

Checks

Verify the IDPS quarantines and/or delete malicious code. If the IDPS does not quarantine and/or delete malicious code, this is a finding.

Fix

Configure the IDPS to quarantine and/or delete malicious code.
V-55363 Added
Findings ID: SRG-NET-000249-IDPS-00222 Rule ID: SV-69609r1_rule Severity: medium CCI: CCI-001243

Discussion

Without an alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis and detect rate-based and other anomalies will be impeded. The IDPS generates an immediate (within seconds) alert which notifies designated personnel of the incident. Sending a message to an unattended log or console does not meet this requirement since that will not be seen immediately. These messages should include a severity level indicator or code as an indicator of the criticality of the incident.

Checks

Verify the IDPS sends an immediate (within seconds) alert to, at a minimum, the SCA when malicious code is detected. If the IDPS does not send an immediate (within seconds) alert to, at a minimum, the SCA when malicious code is detected, this is a finding.

Fix

Configure the IDPS to send an immediate (within seconds) alert to, at a minimum, the SCA when malicious code is detected.
V-55365 Added
Findings ID: SRG-NET-000383-IDPS-00208 Rule ID: SV-69611r1_rule Severity: medium CCI: CCI-002656

Discussion

An integrated, network-wide intrusion detection capability increases the ability to detect and prevent sophisticated distributed attacks based on access patterns and characteristics of access. Integration is more than centralized logging and a centralized management console. The enclave's monitoring capability may include multiple sensors, IPS, sensor event databases, behavior-based monitoring devices, application-level content inspection systems, malicious code protection software, scanning tools, audit record monitoring software, and network monitoring software. Some tools may monitor external traffic while others monitor internal traffic at key boundaries. These capabilities may be implemented using different devices and therefore can have different security policies and severity-level schema. This is valuable because content filtering, monitoring, and prevention can become a bottleneck on the network if not carefully configured.

Checks

Verify the IDPS integrates with a network-wide monitoring capability which includes sensors, event databases, and management consoles. If the IDPS does not integrate with a network-wide monitoring capability which includes sensors, event databases, and management consoles, this is a finding.

Fix

Configure the IDPS components, including sensors, event databases, and management consoles to integrate with a network-wide monitoring capability.
V-55375 Added
Findings ID: SRG-NET-000384-IDPS-00209 Rule ID: SV-69621r2_rule Severity: medium CCI: CCI-002683

Discussion

Unauthorized or unapproved network services lack organizational verification or validation and therefore may be unreliable or serve as malicious rogues for valid services. Examples of network services include service-oriented architectures (SOAs), cloud-based services (e.g., infrastructure as a service, platform as a service, or software as a service), cross-domain, Voice Over Internet Protocol, Instant Messaging, auto-execute, and file sharing. To comply with this requirement, the IDPS may be configured to detect services either directly or indirectly (i.e., by detecting traffic associated with a service).

Checks

Verify the IDPS detects network services that have not been authorized or approved by the ISSO or ISSM, at a minimum. If the IDPS does not detect network services that have not been authorized or approved by the ISSO or ISSM, at a minimum, this is a finding.

Fix

Configure the IDPS to detect network services that have not been authorized or approved by the ISSO or ISSM, at a minimum.
V-55377 Added
Findings ID: SRG-NET-000385-IDPS-00210 Rule ID: SV-69623r1_rule Severity: medium CCI: CCI-002684

Discussion

Unauthorized or unapproved network services lack organizational verification or validation and therefore may be unreliable or serve as malicious rogues for valid services. Examples of network services include service-oriented architectures (SOAs), cloud-based services (e.g., infrastructure as a service, platform as a service, or software as a service), cross-domain, Voice Over Internet Protocol, Instant Messaging, auto-execute, and file sharing.

Checks

Verify the IDPS generates a log record when unauthorized network services are detected. If the IDPS does not generate a log record when unauthorized network services are detected, this is a finding.

Fix

Configure the IDPS to generate a log record when unauthorized network services are detected.
V-55379 Added
Findings ID: SRG-NET-000385-IDPS-00211 Rule ID: SV-69625r2_rule Severity: medium CCI: CCI-002684

Discussion

Unauthorized or unapproved network services lack organizational verification or validation and therefore may be unreliable or serve as malicious rogues for valid services. Automated mechanisms can be used to send automatic alerts or notifications. Such automatic alerts or notifications can be conveyed in a variety of ways (e.g., telephonically, via electronic mail, via text message, or via websites). The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSO to the vulnerability discussion.

Checks

Verify the IDPS generates an alert to the ISSM and ISSO, at a minimum, when unauthorized network services are detected. If the IDPS does not generate an alert to the ISSM and ISSO, at a minimum, when unauthorized network services are detected, this is a finding.

Fix

Configure the IDPS to generate an alert to the ISSM and ISSo, at a minimum, when unauthorized network services are detected
V-55381 Added
Findings ID: SRG-NET-000390-IDPS-00212 Rule ID: SV-69627r1_rule Severity: medium CCI: CCI-002661

Discussion

If inbound communications traffic is not continuously monitored for unusual/unauthorized activities or conditions, there will be times when hostile activity may not be noticed and defended against. Although some of the components in the site's content scanning solution may be used for periodic scanning assessment, the IDPS sensors and other components must provide continuous, 24 hours a day, 7 days a week monitoring. Unusual/unauthorized activities or conditions related to information system inbound communications traffic include, for example, internal traffic that indicates the presence of malicious code within organizational information systems or propagating among system components, the unauthorized exporting of information, or signaling to external information systems. Anomalies within organizational information systems include, for example, large file transfers, long-time persistent connections, use of unusual protocols and ports, and communications with suspected or known malicious external entities.

Checks

Verify the IDPS continuously monitors inbound communications traffic for unusual/unauthorized activities or conditions. If the IDPS does not continuously monitor inbound communications traffic for unusual/unauthorized activities or conditions, this is a finding.

Fix

Configure the IDPS to continuously monitor inbound communications traffic for unusual/unauthorized activities or conditions.
V-55383 Added
Findings ID: SRG-NET-000391-IDPS-00213 Rule ID: SV-69629r1_rule Severity: medium CCI: CCI-002662

Discussion

If outbound communications traffic is not continuously monitored for unusual/unauthorized activities or conditions, there will be times when hostile activity may not be noticed and defended against. Although some of the components in the site's content scanning solution may be used for periodic scanning assessment, the IDPS sensors and other components must provide continuous, 24 hours a day, 7 days a week monitoring. Unusual/unauthorized activities or conditions related to information system outbound communications traffic include, for example, internal traffic that indicates the presence of malicious code within organizational information systems or propagating among system components, the unauthorized exporting of information, or signaling to external information systems. Anomalies within organizational information systems include, for example, large file transfers, long-time persistent connections, use of unusual protocols and ports, and communications with suspected or known malicious external entities.

Checks

Verify the IDPS continuously monitors outbound communications traffic for unusual/unauthorized activities or conditions. If the IDPS does not continuously monitor outbound communications traffic for unusual/unauthorized activities or conditions, this is a finding.

Fix

Configure the IDPS to continuously monitor outbound communications traffic for unusual/unauthorized activities or conditions.
V-55385 Added
Findings ID: SRG-NET-000392-IDPS-00214 Rule ID: SV-69631r2_rule Severity: medium CCI: CCI-002664

Discussion

Without an alert, security personnel may be unaware of intrusion detection incidents that require immediate action and this delay may result in the loss or compromise of information. In accordance with CCI-001242, the IDPS is a real-time intrusion detection system. These systems must generate an alert when detection events from real-time monitoring occur. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSM and ISSO.

Checks

Verify the IDPS sends an alert to, at a minimum, the ISSM and ISSO when intrusion detection events are detected which indicate a compromise or potential for compromise. If the IDPS does not send an alert to, at a minimum, the ISSO and ISSM when intrusion detection events are detected which indicate a compromise or potential for compromise, this is a finding.

Fix

Configure the IDPS to send an alert to, at a minimum, the ISSO and ISSM when intrusion detection events are detected which indicate a compromise or potential for compromise.
V-55387 Added
Findings ID: SRG-NET-000392-IDPS-00215 Rule ID: SV-69633r2_rule Severity: medium CCI: CCI-002664

Discussion

Without an alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis and detect rate-based and other anomalies will be impeded. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSM and ISSO.

Checks

Verify the IDPS sends an alert to, at a minimum, the ISSM and ISSO when threats identified by authoritative sources (e.g., IAVMs or CTOs) are detected which indicate a compromise or potential for compromise. If the IDPS does not send an alert to, at a minimum, the ISSM and ISSO when threats identified by authoritative sources (e.g., IAVMs or CTOs) are detected which indicate a compromise or potential for compromise, this is a finding.

Fix

Configure the IDPS to send an alert to, at a minimum, the ISSM and ISSO when threats identified by authoritative sources (e.g., IAVMs or CTOs) are detected which indicate a compromise or potential for compromise.
V-55389 Added
Findings ID: SRG-NET-000392-IDPS-00216 Rule ID: SV-69635r2_rule Severity: medium CCI: CCI-002664

Discussion

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. CJCSM 6510.01B, "Cyber Incident Handling Program", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category I, II, IV, and VII detection events) will require an alert when an event is detected. Alerts messages must include a severity level indicator or code as an indicator of the criticality of the incident. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSM and ISSO.

Checks

Verify the IDPS sends an alert to, at a minimum, the ISSM and ISSO when root level intrusion events which provide unauthorized privileged access are detected. If the IDPS does not send an alert to, at a minimum, the ISSM and ISSO when root level intrusion events which provide unauthorized privileged access are detected, this is a finding.

Fix

Configure the IDPS to send an alert to, at a minimum, the ISSM and ISSO when root level intrusion events which provide unauthorized privileged access are detected.
V-55391 Added
Findings ID: SRG-NET-000392-IDPS-00217 Rule ID: SV-69637r2_rule Severity: medium CCI: CCI-002664

Discussion

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. CJCSM 6510.01B, "Cyber Incident Handling Program", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category I, II, IV, and VII detection events) will require an alert when an event is detected. Alerts messages must include a severity level indicator or code as an indicator of the criticality of the incident. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSM and ISSO.

Checks

Verify the IDPS sends an alert to, at a minimum, the ISSM and ISSO when user level intrusions which provide non-privileged access are detected. If the IDPS does not send an alert to, at a minimum, the ISSM and ISSO when root level intrusion events when user level intrusions which provide non-privileged access are detected, this is a finding.

Fix

Configure the IDPS to send an alert to, at a minimum, the ISSM and ISSO when user level intrusions which provide non-privileged access are detected.
V-55393 Added
Findings ID: SRG-NET-000392-IDPS-00218 Rule ID: SV-69639r2_rule Severity: medium CCI: CCI-002664

Discussion

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. CJCSM 6510.01B, "Cyber Incident Handling Program", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category I, II, IV, and VII detection events) will require an alert when an event is detected. Alerts messages must include a severity level indicator or code as an indicator of the criticality of the incident. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the SCA or other authorized personnel to receive the alert within the specified time, validate the alert, then forward only validated alerts to the ISSM and ISSO.

Checks

Verify the IDPS sends an alert to, at a minimum, the ISSM and ISSO when denial of service incidents are detected. If the IDPS does not send an alert to, at a minimum, the ISSM and ISSO when root level intrusion events when denial of service incidents are detected, this is a finding.

Fix

Configure the IDPS to send an alert to, at a minimum, the IAM and IAO when denial of service incidents are detected.
V-55395 Added
Findings ID: SRG-NET-000392-IDPS-00219 Rule ID: SV-69641r2_rule Severity: medium CCI: CCI-002664

Discussion

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. CJCSM 6510.01B, "Cyber Incident Handling Program", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category I, II, IV, and VII detection events) will require an alert when an event is detected. Alerts messages must include a severity level indicator or code as an indicator of the criticality of the incident. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel.

Checks

Verify the IDPS sends an alert to, at a minimum, the ISSM and ISSO when new active propagation of malware infecting DoD systems or malicious code adversely affecting the operations and/or security of DoD systems is detected. If the IDPS does not send an alert to, at a minimum, the ISSM and ISSO when new active propagation of malware infecting DoD systems or malicious code adversely affecting the operations and/or security of DoD systems is detected, this is a finding.

Fix

Configure the IDPS to send an alert to, at a minimum, the ISSM and ISSO when new active propagation of malware infecting DoD systems or malicious code adversely affecting the operations and/or security of DoD systems is detected.
V-55397 Added
Findings ID: SRG-NET-000318-IDPS-00068 Rule ID: SV-69643r1_rule Severity: medium CCI: CCI-002346

Discussion

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack databases may result in the compromise of information. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. Web applications frequently access databases to store, retrieve, and update information. An attacker can construct inputs that the database will execute. This is most commonly referred to as a code injection attack. This type of attack includes XPath and LDAP injections. IDPS component(s) with the capability to prevent code injections must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses.

Checks

Verify the IDPS prevents code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields. If the IDPS does not prevent code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields, this is a finding.

Fix

Configure the IDPS components to prevent code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.
V-55399 Added
Findings ID: SRG-NET-000318-IDPS-00182 Rule ID: SV-69645r1_rule Severity: medium CCI: CCI-002346

Discussion

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack applications may result in the compromise of information. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. These attacks include buffer overrun, XML, JavaScript, and HTML injections. IDPS component(s) with the capability to prevent code injections must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses.

Checks

Verify the IDPS prevents code injection attacks launched against application objects including, at a minimum, application URLs and application code. If the IDPS does not prevent code injection attacks launched against application objects including, at a minimum, application URLs and application code, this is a finding.

Fix

Configure the IDPS to prevent code injection attacks launched against application objects including, at a minimum, application URLs and application code.
V-55401 Added
Findings ID: SRG-NET-000318-IDPS-00183 Rule ID: SV-69647r1_rule Severity: medium CCI: CCI-002346

Discussion

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack databases may result in the compromise of information. SQL injection attacks are the most prevalent attacks against web applications and databases. These attacks inject SQL commands that can read, modify, or compromise the meaning of the original SQL query. An attacker can spoof identity; expose, tamper, destroy, or make existing data unavailable; or gain unauthorized privileges on the database server. IDPS component(s) with the capability to prevent SQL code injections must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for SQL injection attacks.

Checks

Verify the IDPS prevents SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields. If the IDPS does not prevent SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields, this is a finding.

Fix

Configure the IDPS to prevent SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.
V-55403 Added
Findings ID: SRG-NET-000319-IDPS-00184 Rule ID: SV-69649r1_rule Severity: medium CCI: CCI-002347

Discussion

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack databases may result in the compromise of information. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. Web applications frequently access databases to store, retrieve, and update information. An attacker can construct inputs that the database will execute. This is most commonly referred to as a code injection attack. This type of attack includes XPath and LDAP injections. IDPS component(s) with anomaly detection must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses.

Checks

Verify the IDPS detects code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields. If the IDPS does not detect code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields, this is a finding.

Fix

Configure the IDPS components to detect code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.
V-55407 Added
Findings ID: SRG-NET-000319-IDPS-00185 Rule ID: SV-69653r1_rule Severity: medium CCI: CCI-002347

Discussion

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack applications may result in the compromise of information. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. These attacks include buffer overrun, XML, JavaScript, and HTML injections. IDPS component(s) with anomaly detection must be included in the IDPS implementation. These components must include rules and anomaly detection algorithms to monitor for atypical application behavior, commands, and accesses.

Checks

Verify the IDPS detects code injection attacks launched against application objects including, at a minimum, application URLs and application code. If the IDPS does not detect code injection attacks launched against application objects including, at a minimum, application URLs and application code, this is a finding.

Fix

Configure the IDPS to detect code injection attacks launched against application objects including, at a minimum, application URLs and application code.
V-55409 Added
Findings ID: SRG-NET-000319-IDPS-00186 Rule ID: SV-69655r1_rule Severity: medium CCI: CCI-002347

Discussion

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack databases may result in the compromise of information. SQL injection attacks are the most prevalent attacks against web applications and databases. These attacks inject SQL commands that can read, modify, or compromise the meaning of the original SQL query. An attacker can spoof identity; expose, tamper, destroy, or make existing data unavailable; or gain unauthorized privileges on the database server. IDPS component(s) with anomaly detection must be included in the IDPS implementation to monitor for and detect unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for SQL injection attacks.

Checks

Verify the IDPS detects SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields. If the IDPS does not detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields, this is a finding.

Fix

Configure the IDPS to detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.
V-55595 Added
Findings ID: SRG-NET-000365-IDPS-00199 Rule ID: SV-69841r3_rule Severity: medium CCI: CCI-001126

Discussion

Since the IDPS is a boundary protection device, if the IDPS fails in an unsecure manner the device may permit unauthorized information release. The operational failure may have been the result of a direct attack on the IDPS device which may be followed by a DoS attack or unauthorized entry attempt. Without the IDPS to monitor and detect these attacks, network is at risk. Fail secure is achieved by employing mechanisms to ensure that if the IDPS traffic monitoring and detection functions fail, it does not continue processing while security policies, filters, and signatures are not being applied. If the IDPS traffic monitoring and detection functions fail for any reason, the IDPS must stop forwarding traffic altogether or maintain the configured security policies. For this reason, device redundancy rather than a policy of failing open is vital to maintaining network availability while protecting DoD networks. Since it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.

Checks

Verify the IDPS fails securely in the event of an operational failure. If the IDPS does not fail securely in the event of an operational failure, this is a finding.

Fix

Configure the IDPS to fail securely in the event of an operational failure.
V-55597 Added
Findings ID: SRG-NET-000251-IDPS-00178 Rule ID: SV-69843r1_rule Severity: medium CCI: CCI-001247

Discussion

Failing to automatically update malicious code protection mechanisms, including application software files, signature definitions, and vendor-provided rules, leaves the system vulnerable to exploitation by recently developed attack methods and programs. An automatic update process ensures this important task is performed without the need for SCA intervention. The IDPS is a key malicious code protection mechanism in the enclave infrastructure. To ensure this protection is responsive to changes in malicious code threats, IDPS components must be automatically updated, including anti-virus signatures, detection heuristics, vendor-provided rules, and vendor-provided signatures. If a DoD patch management server or update repository having the tested/verified updates is available for the IDPS component, the components must be configured to automatically check this server/site for updates and install new updates. If a DoD server/site is not available, the component must be configured to automatically check a trusted vendor site for updates. A trusted vendor is either commonly used by DoD, specifically approved by DoD, the vendor from which the equipment was purchased, or approved by the local program's CCB.

Checks

Verify the IDPS automatically installs updates to signature definitions, detection heuristics, and vendor-provided rules. If the IDPS does not automatically install updates to signature definitions, detection heuristics, and vendor-provided rules, this is a finding.

Fix

Configure the IDPS to automatically install updates to signature definitions, detection heuristics, and vendor-provided rules.
SRG-NET-000318-IDPS-000181 Removed
Findings ID: SRG-NET-000318-IDPS-000181 Rule ID: SRG-NET-000318-IDPS-000181_rule Severity: medium CCI: CCI-002346

Discussion

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack databases may result in the compromise of information. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. Web applications frequently access databases to store, retrieve, and update information. An attacker can construct inputs that the database will execute. This is most commonly referred to as a code injection attack. This type of attack includes XPath and LDAP injections. IDPS component(s) with the capability to prevent code injections must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses.

Checks

Verify the IDPS prevents code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields. If the IDPS does not prevent code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields, this is a finding.

Fix

Configure the IDPS components to prevent code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.
SRG-NET-000318-IDPS-000182 Removed
Findings ID: SRG-NET-000318-IDPS-000182 Rule ID: SRG-NET-000318-IDPS-000182_rule Severity: medium CCI: CCI-002346

Discussion

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack applications may result in the compromise of information. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. These attacks include buffer overrun, XML, JavaScript, and HTML injections. IDPS component(s) with the capability to prevent code injections must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses.

Checks

Verify the IDPS prevents code injection attacks launched against application objects including, at a minimum, application URLs and application code. If the IDPS does not prevent code injection attacks launched against application objects including, at a minimum, application URLs and application code, this is a finding.

Fix

Configure the IDPS to prevent code injection attacks launched against application objects including, at a minimum, application URLs and application code.
SRG-NET-000318-IDPS-000183 Removed
Findings ID: SRG-NET-000318-IDPS-000183 Rule ID: SRG-NET-000318-IDPS-000183_rule Severity: medium CCI: CCI-002346

Discussion

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack databases may result in the compromise of information. SQL injection attacks are the most prevalent attacks against web applications and databases. These attacks inject SQL commands that can read, modify, or compromise the meaning of the original SQL query. An attacker can spoof identity; expose, tamper, destroy, or make existing data unavailable; or gain unauthorized privileges on the database server. IDPS component(s) with the capability to prevent SQL code injections must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for SQL injection attacks.

Checks

Verify the IDPS monitors for SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields. If the IDPS does not monitor for SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields, this is a finding.

Fix

Configure the IDPS to monitor for SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.
SRG-NET-000319-IDPS-000184 Removed
Findings ID: SRG-NET-000319-IDPS-000184 Rule ID: SRG-NET-000319-IDPS-000184_rule Severity: medium CCI: CCI-002347

Discussion

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack databases may result in the compromise of information. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. Web applications frequently access databases to store, retrieve, and update information. An attacker can construct inputs that the database will execute. This is most commonly referred to as a code injection attack. This type of attack includes XPath and LDAP injections. IDPS component(s) with anomaly detection must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses.

Checks

Verify the IDPS detects code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields. If the IDPS does not detect code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields, this is a finding.

Fix

Configure the IDPS components to detect code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.
SRG-NET-000319-IDPS-000185 Removed
Findings ID: SRG-NET-000319-IDPS-000185 Rule ID: SRG-NET-000319-IDPS-000185_rule Severity: medium CCI: CCI-002347

Discussion

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack applications may result in the compromise of information. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. These attacks include buffer overrun, XML, JavaScript, and HTML injections. IDPS component(s) with anomaly detection must be included in the IDPS implementation. These components must include rules and anomaly detection algorithms to monitor for atypical application behavior, commands, and accesses.

Checks

Verify the IDPS detects code injection attacks launched against application objects including, at a minimum, application URLs and application code. If the IDPS does not detect code injection attacks launched against application objects including, at a minimum, application URLs and application code, this is a finding.

Fix

Configure the IDPS to detect code injection attacks launched against application objects including, at a minimum, application URLs and application code.
SRG-NET-000319-IDPS-000186 Removed
Findings ID: SRG-NET-000319-IDPS-000186 Rule ID: SRG-NET-000319-IDPS-000186_rule Severity: medium CCI: CCI-002347

Discussion

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks that use unauthorized data mining techniques to attack databases may result in the compromise of information. SQL injection attacks are the most prevalent attacks against web applications and databases. These attacks inject SQL commands that can read, modify, or compromise the meaning of the original SQL query. An attacker can spoof identity; expose, tamper, destroy, or make existing data unavailable; or gain unauthorized privileges on the database server. IDPS component(s) with anomaly detection must be included in the IDPS implementation to monitor for and detect unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for SQL injection attacks.

Checks

Verify the IDPS detects SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields. If the IDPS does not detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields, this is a finding.

Fix

Configure the IDPS to detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.
SRG-NET-000018-IDPS-000018 Removed
Findings ID: SRG-NET-000018-IDPS-000018 Rule ID: SRG-NET-000018-IDPS-000018_rule Severity: medium CCI: CCI-001368

Discussion

The flow of all communications traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data. Restricting the flow of communications traffic, also known as Information flow control, regulates where information is allowed to travel as opposed to who is allowed to access the information and without explicit regard to subsequent accesses to that information. The IDPS will include policy filters, rules, signatures, and behavior analysis algorithms that inspects and restricts traffic based on the characteristics of the information and/or the information path as it crosses internal network boundaries. The IDPS monitors for harmful or suspicious information flows and restricts or blocks this traffic based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.

Checks

Verify the IDPS enforces approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic within the network as defined in the PPSM CAL and vulnerability assessments. If the IDPS does not enforce approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic within the network as defined in the PPSM CAL and vulnerability assessments, this is a finding.

Fix

Configure the IDPS to enforce approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic within the network as defined in the PPSM CAL and vulnerability assessments.
SRG-NET-000019-IDPS-000019 Removed
Findings ID: SRG-NET-000019-IDPS-000019 Rule ID: SRG-NET-000019-IDPS-000019_rule Severity: medium CCI: CCI-001414

Discussion

The flow of all communications traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data. Restricting the flow of communications traffic, also known as Information flow control, regulates where information is allowed to travel as opposed to who is allowed to access the information and without explicit regard to subsequent accesses to that information. The IDPS will include policy filters, rules, signatures, and behavior analysis algorithms that inspects and restricts traffic based on the characteristics of the information and/or the information path as it crosses external/perimeter boundaries. The IDPS monitors for harmful or suspect information flows and restricts or blocks this traffic based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.

Checks

Verify the IDPS enforces approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic for controlling the flow of information between interconnected networks as defined in the PPSM CAL and vulnerability assessments. If the IDPS does not enforce approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic for controlling the flow of information between interconnected networks as defined in the PPSM CAL and vulnerability assessments, this is a finding.

Fix

Configure the IDPS to enforce approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic for controlling the flow of information between interconnected networks as defined in the PPSM CAL and vulnerability assessments.
SRG-NET-000019-IDPS-000187 Removed
Findings ID: SRG-NET-000019-IDPS-000187 Rule ID: SRG-NET-000019-IDPS-000187_rule Severity: medium CCI: CCI-001414

Discussion

Information flow policies regarding dynamic information flow control include, for example, allowing or disallowing information flows based on changes to the PPSM CAL, vulnerability assessments, or mission conditions. Changing conditions include changes in the threat environment and detection of potentially harmful or adverse events. Changes to the IDPS must take effect when made by an authorized administrator and the new configuration is put in place or committed. With some devices, the changes take effect as the configuration is changed, while with others, the new configuration must be submitted to the device. In any case, the behavior of the IDPS must immediately be affected to reflect the configuration change. An IDPS can terminate an information flow if it detects a potentially harmful or adverse event in that specific data flow. This action must take place immediately when triggered.

Checks

Verify the IDPS immediately uses updates made to policy filters, rules, signatures, and anomaly analysis algorithms for traffic detection and prevention functions. If the IDPS does not immediately use updates made to policy filters, rules, signatures, and anomaly analysis algorithms to traffic detection and prevention functions, this is a finding.

Fix

Configure the IDPS to immediately use updates made to policy filters, rules, signatures, and anomaly analysis algorithms for traffic detection and prevention functions.
SRG-NET-000019-IDPS-000188 Removed
Findings ID: SRG-NET-000019-IDPS-000188 Rule ID: SRG-NET-000019-IDPS-000188_rule Severity: medium CCI: CCI-001414

Discussion

Information flow policies may require changes in order to meet changing mission needs or ongoing attacks. If changes are made to the IDPS, but are not saved to the configuration that is loaded upon the next boot-up of the device, the network would be vulnerable to previously mitigated risks. The IDPS must enforce changes to approved authorizations for controlling the flow of information within the network and between interconnected systems by ensuring the device configuration used upon reboot contains the most recent updates made to policy filters, rules, signatures, and anomaly analysis algorithms.

Checks

Verify the IDPS uses the most recent updates made to policy filters, rules, signatures, and anomaly analysis algorithms upon reboot. If the IDPS does not use the most recent updates made to policy filters, rules, signatures, and anomaly analysis algorithms upon reboot, this is a finding.

Fix

Configure the IDPS to use the most recent updates made to policy filters, rules, signatures, and anomaly analysis algorithms upon reboot.
SRG-NET-000113-IDPS-000013 Removed
Findings ID: SRG-NET-000113-IDPS-000013 Rule ID: SRG-NET-000113-IDPS-000013_rule Severity: medium CCI: CCI-000169

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail. The IDPS must have the capability to capture and log detected security violations and potential security violations.

Checks

Verify the configuration provides audit record generation capability for detection events based on implementation of policy filters, rules, signatures, and anomaly analysis. If the IDPS does not provide audit record generation capability for detection events based on implementation of policy filters, rules, signatures, and anomaly analysis, this is a finding.

Fix

Configure the IDPS to provide audit record generation capability for detection events based on implementation of policy filters, rules, signatures, and anomaly analysis.
SRG-NET-000113-IDPS-000082 Removed
Findings ID: SRG-NET-000113-IDPS-000082 Rule ID: SRG-NET-000113-IDPS-000082_rule Severity: medium CCI: CCI-000169

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail. The IDPS must have the capability to capture and log events where communications traffic was blocked or restricted because of a security violation or potential security violations.

Checks

Verify the configuration provides audit record generation capability for events where communication traffic is blocked or restricted based on policy filters, rules, signatures, and anomaly analysis algorithms. If the IDPS does not provide audit record generation capability for events where communication traffic is blocked or restricted based on policy filters, rules, signatures, and anomaly analysis, this is a finding.

Fix

Configure the IDPS to provide audit record generation capability for events where communication traffic is blocked or restricted based on policy filters, rules, signatures, and anomaly analysis algorithms.
SRG-NET-000113-IDPS-000189 Removed
Findings ID: SRG-NET-000113-IDPS-000189 Rule ID: SRG-NET-000113-IDPS-000189_rule Severity: medium CCI: CCI-000169

Discussion

Without the capability to generate audit records with a severity code it is difficult to track and handle detection events. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail. The IDPS must have the capability to collect and log the severity associated with the policy, rule, or signature. IDSP products often have either pre-configured and/or a configurable method for associating an impact indicator or severity code with signatures and rules, at a minimum.

Checks

Verify the configuration provides audit record generation with a configurable severity and escalation level capability. If the IDPS does not provide audit record generation with a configurable severity and escalation level capability, this is a finding.

Fix

Configure the IDPS to provide audit record generation with a configurable severity and escalation level capability.
SRG-NET-000074-IDPS-000059 Removed
Findings ID: SRG-NET-000074-IDPS-000059 Rule ID: SRG-NET-000074-IDPS-000059_rule Severity: medium CCI: CCI-000130

Discussion

Without establishing what type of event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Associating an event types with each event log entry provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured IDPS. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.

Checks

Examine the audit log configuration on the IDPS components or view several alert records on the organization's central audit log server. Verify the entries sent to the audit log include, at a minimum, reporting device name, event descriptions, policy filter, rule, or signature invoked, source and destination address, port, protocol, alert code or description. If the audit log event records does not include, at a minimum, reporting device name, event descriptions, policy filter, rule, or signature invoked, source and destination address, port, protocol, alert code or description, this is a finding.

Fix

Configure the IDPS components to ensure entries sent to the audit log include sufficient information to determine the type or category for each audit event recorded in the audit log, including, at a minimum, reporting device name, event descriptions, policy filter, rule, or signature invoked, source and destination address, port, protocol, alert code or description.
SRG-NET-000075-IDPS-000060 Removed
Findings ID: SRG-NET-000075-IDPS-000060 Rule ID: SRG-NET-000075-IDPS-000060_rule Severity: medium CCI: CCI-000131

Discussion

Without establishing the time (date/time) an event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Associating the date and time the event occurred with each event log entry provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured IDPS. Log records must have accurate date/time stamps since forensic analysis of security incidents and day-to-day monitoring are substantially more difficult if there are no time stamps on log entries. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.

Checks

Examine the audit log configuration on the IDPS components or view several alert records on the organization's central audit log server. Verify the entries sent to the audit log include the date and time of each event. If the audit log event records do not include the date and time the events occurred, this is a finding.

Fix

Configure the IDPS components to include the date time stamp of events in log messages.
SRG-NET-000076-IDPS-000061 Removed
Findings ID: SRG-NET-000076-IDPS-000061 Rule ID: SRG-NET-000076-IDPS-000061_rule Severity: medium CCI: CCI-000132

Discussion

Without establishing where an event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Associating event location with the event log entries provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured IDPS. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail. This requirement refers to capturing information about where the event was detected, rather than where the event originated.

Checks

Examine the audit log configuration on the IDPS components or view several alert records on organization's central audit log server. Verify the entries sent to the audit log include, at a minimum, enclave and sub-enclave, node names, network element name, module, and sub-system as accurately as possible. If the audit log events do not include, at a minimum, enclave and sub-enclave, node names, network element name, module, and sub-system as accurately as possible, this is a finding.

Fix

Configure the IDPS components to ensure log entries include, at a minimum, enclave and sub-enclave, node names, network element name, module, and sub-system as accurately as possible.
SRG-NET-000077-IDPS-000062 Removed
Findings ID: SRG-NET-000077-IDPS-000062 Rule ID: SRG-NET-000077-IDPS-000062_rule Severity: medium CCI: CCI-000133

Discussion

Without establishing the source of an event, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Associating the source of the event with detected events in the logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured IDPS. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.

Checks

Verify configuration produces audit records containing information to establish the source of the event, including, at a minimum, originating source address, process, node, or device name. If the IDPS does not produce audit records containing information to establish the source of the event, including, at a minimum, originating source address, process, node, or device name, this is a finding.

Fix

Configure the IDPS to produce audit records containing information to establish the source of the event, including, at a minimum, originating source address, process, node, or device name.
SRG-NET-000078-IDPS-000063 Removed
Findings ID: SRG-NET-000078-IDPS-000063 Rule ID: SRG-NET-000078-IDPS-000063_rule Severity: medium CCI: CCI-000134

Discussion

Without establishing the outcome of the event, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Associating event outcome with detected events in the log provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured IDPS. While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail. If harmful or potentially harmful communications traffic is detected, the IDPS must capture all of the traffic associated with the incident for forensic analysis. The logs should identify what servers, operating systems, and applications were attacked and the interaction of the target with the attacker. All commands that were entered by the attacker (such as account creations, changes in permissions, files accessed, etc.) during the session should also be logged.

Checks

Examine the audit log configuration on the IDPS components or view several alert records on organization's central audit log server. Verify the entries sent to the audit log include, at a minimum, capturing all associated traffic, the systems accessed, and commands executed on the accessed systems, and the success/failure of these commands. If the audit log event records do not include, at a minimum, capturing all associated traffic, the systems accessed, and commands executed on the accessed systems, and the success/failure of these commands, this is a finding.

Fix

Configure the IDPS components to ensure entries sent to the audit log include, at a minimum, capturing all associated traffic, the systems accessed, and commands executed on the accessed systems, and the success/failure of these commands.
SRG-NET-000079-IDPS-000064 Removed
Findings ID: SRG-NET-000079-IDPS-000064 Rule ID: SRG-NET-000079-IDPS-000064_rule Severity: medium CCI: CCI-001487

Discussion

Without information that establishes the identity of the subjects (i.e., users or processes acting on behalf of users) associated with the events, security personnel cannot determine responsibility for the potentially harmful event. Log record content that may be necessary to satisfy this requirement includes the user or process identifiers.

Checks

Examine the audit log configuration on the IDPS components or view several alert records on organization's central audit log server. Verify the audit records contain information to establish the identity of any individual or process associated with the event, including, at a minimum, user or process identifiers. If the audit log event records do not include, at a minimum, the user or process identifiers associated with the event, this is a finding.

Fix

Configure the IDPS components to ensure entries sent to the audit log include, at a minimum, the user or process identifiers associated with the event.
SRG-NET-000333-IDPS-000190 Removed
Findings ID: SRG-NET-000333-IDPS-000190 Rule ID: SRG-NET-000333-IDPS-000190_rule Severity: medium CCI: CCI-001844

Discussion

Without the ability to centrally manage the content captured in the log records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an attack. Centralized management and storage of log records increases efficiency in maintenance and management of records as well as facilitates the backup and archiving of those records. The IDPS must be configured to support centralized management and configuration of the content to be captured in audit records generated by all network components. IDPS sensors and consoles must have the capability to support centralized logging. They must be configured to send log messages to centralized, redundant servers and be capable of being remotely configured to change logging parameters (such as facility and severity levels).

Checks

Verify the IDPS is configured to support centralized management and configuration of the content captured in audit records generated by all IDPS components. If the IDPS does not support centralized management and configuration of the content captured in audit records generated by all IDPS components, this is a finding.

Fix

Configure the IDPS to support centralized management and configuration of the content captured in audit records generated by all IDPS components.
SRG-NET-000334-IDPS-000191 Removed
Findings ID: SRG-NET-000334-IDPS-000191 Rule ID: SRG-NET-000334-IDPS-000191_rule Severity: medium CCI: CCI-001851

Discussion

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading ensures audit information does not get overwritten if the limited audit storage capacity is reached and also protects the audit record in case the system/component being audited is compromised. This also prevents the log records from being lost if the logs stored locally are accidentally or intentionally deleted, altered, or corrupted.

Checks

Verify the IDPS off-loads log records to a centralized log server. If the IDPS does not off-load log records to a centralized log server, this is a finding.

Fix

Configure the IDPS to off-load log records to a centralized log server.
SRG-NET-000511-IDPS-000012 Removed
Findings ID: SRG-NET-000511-IDPS-000012 Rule ID: SRG-NET-000511-IDPS-000012_rule Severity: medium CCI: CCI-001851

Discussion

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading ensures audit information does not get overwritten if the limited audit storage capacity is reached and also protects the audit record in case the system/component being audited is compromised. This also prevents the log records from being lost if the logs stored locally are accidentally or intentionally deleted, altered, or corrupted. IDPS components must have the capability to support centralized logging. They must be configured to send log messages to centralized, redundant servers in real time (within less than a second).

Checks

Verify the IDPS off-loads log records to a centralized log server in real time. If the IDPS does not off-load log records to a centralized log server in real time, this is a finding.

Fix

Configure the IDPS to off-load log records to a centralized log server in real time.
SRG-NET-000335-IDPS-000014 Removed
Findings ID: SRG-NET-000335-IDPS-000014 Rule ID: SRG-NET-000335-IDPS-000014_rule Severity: medium CCI: CCI-001858

Discussion

Without a real time alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis and detect rate-based and other anomalies will be impeded. The IDPS must generate an alert which will notify designated personnel of the logging failure. Since SAs or IAOs must take action immediately, these messages will be designated as a critical severity level. Alerts provide organizations with urgent messages. Real time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less).

Checks

Verify the IDPS provides a real time alert (i.e., the time from event detection to alert occurs in seconds or less) to the SA and IAO, at a minimum, of all audit failure events where the detection and/or prevention function is unable to write events to either local storage or the centralized server. If the IDPS does not provide a real time alert to the SA and IAO, at a minimum, of all audit failure events where the detection and/or prevention function is unable to write events to either local storage or the centralized server, this is a finding.

Fix

Configure the IDPS to provide a real time alert to the SA and IAO, at a minimum, of all audit failure events where the detection and/or prevention function is unable to write events to either local storage or the centralized server.
SRG-NET-000088-IDPS-000068 Removed
Findings ID: SRG-NET-000088-IDPS-000068 Rule ID: SRG-NET-000088-IDPS-000068_rule Severity: medium CCI: CCI-000139

Discussion

Appropriate personnel must 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. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. If the IDPS becomes unable to write events to either local storage or to a centralized server, this is a logging failure. This can happen when the local storage is full and the device is not configured to overwrite the oldest record in the file with the newest (circular buffer), or when connectivity to the centralized Syslog server is lost, or when the Syslog process is stopped or hung.

Checks

Verify the IDPS alerts the IAO and SA (at a minimum) in the event of an audit processing failure where the detection and/or prevention function is unable to write events to either local storage or the centralized server. If the IDPS does not alert the IAO and SA (at a minimum) in the event of an audit processing failure where the detection and/or prevention function is unable to write events to either local storage or the centralized server, this is a finding.

Fix

Configure the IDPS to alert the IAO and SA (at a minimum) in the event of an audit processing failure where the detection and/or prevention function is unable to write events to either local storage or the centralized server.
SRG-NET-000089-IDPS-000069 Removed
Findings ID: SRG-NET-000089-IDPS-000069 Rule ID: SRG-NET-000089-IDPS-000069_rule Severity: medium CCI: CCI-000140

Discussion

It is critical that when the IDPS is at risk of failing to process audit logs as required, it takes action to mitigate the failure. 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. The IDPS performs a critical security function, so its continued operation is imperative. Since availability of the IDPS is an overriding concern, shutting down the system in the event of an audit failure should be avoided, except as a last resort.

Checks

Verify the IDPS, in the event of a logging failure caused by the lack of audit record storage capacity, continues generating and storing audit records and overwriting the oldest audit records in a first-in-first-out manner. In the event of a logging failure caused by the lack of audit record storage capacity, if the IDPS does not continue generating and storing audit records and overwriting the oldest audit records in a first-in-first-out manner, this is a finding.

Fix

Configure the IDPS, in the event of a logging failure caused by the lack of audit record storage capacity, to continue generating and storing audit records and overwriting the oldest audit records in a first-in-first-out manner.
SRG-NET-000089-IDPS-000010 Removed
Findings ID: SRG-NET-000089-IDPS-000010 Rule ID: SRG-NET-000089-IDPS-000010_rule Severity: medium CCI: CCI-000140

Discussion

It is critical that when the IDPS is at risk of failing to process audit logs as required, it take action to mitigate the failure. 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. The IDPS performs a critical security function, so its continued operation is imperative. Since availability of the IDPS is an overriding concern, shutting down the system in the event of an audit failure should be avoided, except as a last resort.

Checks

Verify the IDPS, in the event of a logging failure caused by loss of communications with the central logging server, queues audit records locally until communication is restored or until the audit records are retrieved manually. In the event of a logging failure caused by loss of communications with the central logging server, if the IDPS does not queue audit records locally until communication is restored or until the audit records are retrieved manually, this is a finding.

Fix

Configure the IDPS, in the event of a logging failure caused by loss of communications with the central logging server, to queue audit records locally until communication is restored or until the audit records are retrieved manually.
SRG-NET-000089-IDPS-000192 Removed
Findings ID: SRG-NET-000089-IDPS-000192 Rule ID: SRG-NET-000089-IDPS-000192_rule Severity: medium CCI: CCI-000140

Discussion

The loss of log messages compromises the accuracy of audits that use those messages. If log messages are missing, then important information may be missed during an audit. Log messages must be synchronized between the IDPS local storage and the centralized log collection server; the centralized log collection server should store every message that the local device storage stores, otherwise an audit using the log records from the centralized log server may be inaccurate. Audit log records must be sent to a centralized collection server; if communication with this server is lost or the server fails, the IDPS 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 must be taken to synchronize the local audit data with the collection server.

Checks

Verify the IDPS, in the event of a logging failure caused by loss of communications with the central logging server, synchronizes the local audit data with the collection server when the connection is restored. If the IDPS does not synchronize the local audit data with the collection server when communications with the central logging server is restored, this is a finding.

Fix

Configure the IDPS to synchronize the local audit data with the collection server when communications with the central logging server is restored.
SRG-NET-000091-IDPS-000193 Removed
Findings ID: SRG-NET-000091-IDPS-000193 Rule ID: SRG-NET-000091-IDPS-000193_rule Severity: medium CCI: CCI-000154

Discussion

Centralized review and analysis of log records from multiple IDPS components gives the organization the capability to better detect distributed attacks and provides increased data points for behavior analysis techniques. These techniques are invaluable in monitoring for indicators of complex attack patterns. To support the centralized analysis capability, the IDPS components must be able to provide the information in a format (e.g., Syslog) that can be extracted and used, allowing the application to effectively review and analyze the log records.

Checks

Verify the IDPS supports the centralized review and analysis of log records from multiple sensors, IDS, IPS, and other IDPS components by providing the information in a format (e.g., Syslog) that can be extracted and used by analysis tools. If the IDPS does not support the centralized review and analysis of log records from multiple sensors, IDS, IPS, and other IDPS components by providing the information in a format that can be extracted and used by analysis tools, this is a finding.

Fix

Configure the IDPS to support the centralized review and analysis of log records from multiple sensors, IDS, IPS, and other IDPS components by providing the information in a format that can be extracted and used by analysis tools.
SRG-NET-000512-IDPS-000194 Removed
Findings ID: SRG-NET-000512-IDPS-000194 Rule ID: SRG-NET-000512-IDPS-000194_rule Severity: medium CCI: CCI-000366

Discussion

Configuring the IDPS to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the network element. Security-related parameters are those parameters impacting the security state of the network element, including the parameters required to satisfy other security control requirements. For the network element, security-related parameters include settings for communications traffic management configurations.

Checks

Verify the IDPS is configured in accordance with the security configuration settings based on DoD security policy and technology-specific security best practices. If the IDPS is not configured in accordance with the security configuration settings based on DoD security policy and technology-specific security best practices, this is a finding.

Fix

Configure the IDPS to comply with the security configuration settings based on DoD security policy and technology-specific security best practices.
SRG-NET-000131-IDPS-000011 Removed
Findings ID: SRG-NET-000131-IDPS-000011 Rule ID: SRG-NET-000131-IDPS-000011_rule Severity: medium CCI: CCI-000381

Discussion

An IDPS can be capable of providing a wide variety of capabilities. Not all of these capabilities are necessary. Unnecessary services, functions, and applications increase the attack surface (sum of attack vectors) of a system. These unnecessary capabilities are often overlooked and therefore may remain unsecured.

Checks

Have the SA display the services running on the IDPS components. Review the IDPS configuration to determine if non-essential capabilities not required for operation, or not related to IDPS functionality (e.g., DNS, email client or server, FTP server, or web server) are enabled. If the IDPS is not configured to remove or disable non-essential capabilities which are not required for operation or not related to IDPS functionality (e.g., DNS, email client or server, FTP server, or web server), this is a finding.

Fix

Remove or disable non-essential capabilities from the IDPS. Removal is recommended since the service or function may be inadvertently enabled. However, if removal is not possible, disable the service or function. Document all necessary services.
SRG-NET-000131-IDPS-000097 Removed
Findings ID: SRG-NET-000131-IDPS-000097 Rule ID: SRG-NET-000131-IDPS-000097_rule Severity: medium CCI: CCI-000381

Discussion

An IDPS can be capable of providing a wide variety of capabilities. Not all of these capabilities are necessary. Unnecessary services, functions, and applications increase the attack surface (sum of attack vectors) of a system. These unnecessary capabilities are often overlooked and therefore may remain unsecured. This requirement applies to unnecessary features of the IDPS application itself.

Checks

Verify the IDPS is configured to remove or disable non-essential features, functions, and services of the IDPS application. If the IDPS is not configured to remove or disable non-essential features, functions, and services of the IDPS application, this is a finding.

Fix

Configure the IDPS to remove or disable non-essential features, functions, and services of the IDPS application.
SRG-NET-000132-IDPS-000195 Removed
Findings ID: SRG-NET-000132-IDPS-000195 Rule ID: SRG-NET-000132-IDPS-000195_rule Severity: medium CCI: CCI-000382

Discussion

Some ports, protocols, or services have known exploits or security weaknesses. These ports, protocols, and services must be prohibited or restricted in the IDPS configuration in accordance with DoD policy. Policy filters restrict traffic destined to the enclave perimeter in accordance with the guidelines contained in DoD Instruction 8551.1 for all ports, protocols, and functions. SAs will review the vulnerability assessment for each port allowed into the enclave and apply all appropriate mitigations defined in the Vulnerability Assessment report. Only ports, protocols, and functions allowed into the enclave should be registered in the PPSM database. It is the responsibility of the enclave owner to have the applications the enclave uses registered in the PPSM database.

Checks

Verify the IDPS is configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments. If the IDPS is not configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments, this is a finding.

Fix

Configure the IDPS to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments.
SRG-NET-000228-IDPS-000196 Removed
Findings ID: SRG-NET-000228-IDPS-000196 Rule ID: SRG-NET-000228-IDPS-000196_rule Severity: medium CCI: CCI-001166

Discussion

Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations, Shockwave videos, and macros embedded within Microsoft Office documents. Mobile code can be exploited to attack a host. It can be sent as an e-mail attachment or embedded in other file formats not traditionally associated with executable code. While the IDPS cannot replace the anti-virus and host-based IDS (HIDS) protection installed on the network's endpoints, vendor or locally created sensor rules can be implemented, which provide preemptive defense against both known and zero-day vulnerabilities. Many of the protections may provide defenses before vulnerabilities are discovered and rules or blacklist updates are distributed by anti-virus or malicious code solution vendors. To monitor for and detect known prohibited mobile code or approved mobile code that violates permitted usage requirements, the IDPS must implement policy filters, rules, signatures, and anomaly analysis.

Checks

Verify the IDPS detects, at a minimum, mobile code that is unsigned or exhibiting unusual behavior, has not undergone a risk assessment, or is prohibited for use based on a risk assessment. If the IDPS does not detect, at a minimum, mobile code that is unsigned or exhibiting unusual behavior, has not undergone a risk assessment, or is prohibited for use based on a risk assessment, this is a finding.

Fix

Configure the IDPS to detects, at a minimum, mobile code that is unsigned or exhibiting unusual behavior, has not undergone a risk assessment, or are prohibited for use based on a risk assessment.
SRG-NET-000229-IDPS-000163 Removed
Findings ID: SRG-NET-000229-IDPS-000163 Rule ID: SRG-NET-000229-IDPS-000163_rule Severity: medium CCI: CCI-001662

Discussion

Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations, Shockwave videos, and macros embedded within Microsoft Office documents. Mobile code can be exploited to attack a host. It can be sent as an e-mail attachment or embedded in other file formats not traditionally associated with executable code. While the IDPS cannot replace the anti-virus and host-based IDS (HIDS) protection installed on the network's endpoints, vendor or locally created sensor rules can be implemented, which provide preemptive defense against both known and zero-day vulnerabilities. Many of the protections may provide defenses before vulnerabilities are discovered and rules or blacklist updates are distributed by anti-virus or malicious code solution vendors. To block known prohibited mobile code or approved mobile code that violates permitted usage requirements, the IDPS must implement policy filters, rules, signatures, and anomaly analysis.

Checks

Verify the IDPS blocks any prohibited mobile code at the enclave boundary when it is detected. If the IDPS does not block any prohibited mobile code at the enclave boundary when it is detected, this is a finding.

Fix

Configure the IDPS to block any prohibited mobile code at the enclave boundary when it is detected.
SRG-NET-000235-IDPS-000169 Removed
Findings ID: SRG-NET-000235-IDPS-000169 Rule ID: SRG-NET-000235-IDPS-000169_rule Severity: medium CCI: CCI-001190

Discussion

Failure to a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. Network elements that fail suddenly and with no incorporated failure state planning may leave the hosting system available but with a reduced security protection capability. Preserving information system state information also facilitates system restart and return to the operational mode of the organization with less disruption to mission-essential processes. If the IDPS fails in an unsecure manner (open), unauthorized traffic originating externally to the enclave may enter, or the device may permit unauthorized information release. Fail secure is a condition achieved by employing information system mechanisms to ensure, in the event of a device initialization failure, device shutdown failure, or an abort failure of the IDPS, it does not enter into an unsecure state where intended security properties no longer hold. If the device fails, it must not fail in a manner that will allow unauthorized access. If the IDPS fails for any reason, it must stop forwarding traffic altogether or maintain the configured security policies. If the device stops forwarding traffic, maintaining network availability would be achieved through device redundancy. Since it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.

Checks

Verify the IDPS stops forwarding traffic or maintains the configured security policies upon the failure of the following actions: system initialization, shutdown, or system abort. If the IDPS does not stop forwarding traffic or maintain the configured security policies upon the failure of the following actions: system initialization, shutdown, or system abort, this is a finding.

Fix

Configure the IDPS to stop forwarding traffic or maintain the configured security policies upon the failure of the following actions: system initialization, shutdown, or system abort.
SRG-NET-000236-IDPS-000170 Removed
Findings ID: SRG-NET-000236-IDPS-000170 Rule ID: SRG-NET-000236-IDPS-000170_rule Severity: medium CCI: CCI-001665

Discussion

If the IDPS (or any other network element) crashes, it is important for Systems Administrators to be able to identify why the device crashed. Retaining the configuration and log records provides information that can be used to identify the cause of the crash and determine what, if any, other parts of the system may have been affected. The device should also create a file containing the recorded state of the working memory and/or other useful information concerning the crash. This provides additional diagnostic information but may need to be enabled in the device configuration. Network availability is maintained, in part, by the use of redundant components in an architecture that maintains operation of the network in case a component fails. The degree of redundancy depends on mission requirements and operational constraints. Each enclave should also maintain sufficient spares of each device or component and maintain device configurations that can be readily accessed by authorized personnel in case of a device failure. In many cases, the failed device can be immediately placed back into service. To facilitate this, the device must maintain its configuration if it crashes. Since it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.

Checks

Verify the IDPS, upon system failure, saves diagnostic information, logs system messages, and loads the most current security policies, rules, and signatures when restarted. If the device does not, upon system failure, save diagnostic information, log system messages, and load the most current security policies, rules, and signatures when restarted, this is a finding.

Fix

Configure the IDPS to, upon system failure, save diagnostic information, log system messages, and load the most current security policies, rules, and signatures when restarted.
SRG-NET-000362-IDPS-000196 Removed
Findings ID: SRG-NET-000362-IDPS-000196 Rule ID: SRG-NET-000362-IDPS-000196_rule Severity: medium CCI: CCI-002385

Discussion

If the network does not provide safeguards against DoS attack, network resources will be unavailable to users. Installation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type. Detection components that use rate-based behavior analysis can detect attacks when signatures for the attack do not exist or are not installed. These attacks include zero-day attacks which are new attacks for which vendors have not yet developed signatures. Rate-based behavior analysis can detect sophisticated, Distributed DoS (DDoS) attacks by correlating traffic information from multiple network segments or components. This requirement applies to the communications traffic functionality of the IDPS as it pertains to handling communications traffic, rather than to the IDPS device itself.

Checks

Verify the IDPS protects against or limits the effects of known and unknown types of DoS attacks by employing rate-based attack prevention behavior analysis. If the device does not protect against or limit the effects of known and unknown types of DoS attacks by employing rate-based attack prevention behavior analysis, this is a finding.

Fix

Configure the IDPS to protect against or limit the effects of known and unknown types of DoS attacks by employing rate-based attack prevention behavior analysis.
SRG-NET-000362-IDPS-000197 Removed
Findings ID: SRG-NET-000362-IDPS-000197 Rule ID: SRG-NET-000362-IDPS-000197_rule Severity: medium CCI: CCI-002385

Discussion

If the network does not provide safeguards against DoS attack, network resources will be unavailable to users. Installation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks. Detection components that use pattern recognition pre-processors can detect attacks when signatures for the attack do not exist or are not installed. These attacks include zero-day attacks which are new attacks for which vendors have not yet developed signatures. This requirement applies to the communications traffic functionality of the IDPS as it pertains to handling communications traffic, rather than to the IDPS device itself.

Checks

Verify the IDPS protect against or limits the effects of known and unknown types of DoS attacks by employing pattern recognition pre-processors. If the device does not protect against or limit the effects of known and unknown types of DoS attacks by employing pattern recognition pre-processors, this is a finding.

Fix

Configure the IDPS to protect against or limit the effects of known and unknown types of DoS attacks by employing pattern recognition pre-processors.
SRG-NET-000362-IDPS-000198 Removed
Findings ID: SRG-NET-000362-IDPS-000198 Rule ID: SRG-NET-000362-IDPS-000198_rule Severity: medium CCI: CCI-002385

Discussion

If the network does not provide safeguards against DoS attack, network resources will be unavailable to users. Installation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume, type, or protocol usage. Detection components that use signatures can detect known attacks by using known attack signatures. Signatures are usually obtained from and updated by the IDPS component vendor. These attacks include SYN-flood, ICMP-flood, and Land Attacks. This requirement applies to the communications traffic functionality of the IDPS as it pertains to handling communications traffic, rather than to the IDPS device itself.

Checks

Verify the IDPS protects against or limits the effects of known types of DoS attacks by employing signatures. If the device does not protect against or limit the effects of known types of DoS attacks by employing signatures, this is a finding.

Fix

Configure the IDPS to protect against or limit the effects of known types of DoS attacks by employing signatures.
SRG-NET-000192-IDPS-000140 Removed
Findings ID: SRG-NET-000192-IDPS-000140 Rule ID: SRG-NET-000192-IDPS-000140_rule Severity: medium CCI: CCI-001095

Discussion

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 attack, network resources will be unavailable to users. Installation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type. The IDPS must include protection against DoS attacks that originate from inside the enclave which can affect either internal or external systems. These attacks may use legitimate or rogue endpoints from inside the enclave. 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. To comply with this requirement, the IDPS must protect outbound traffic for indications of known and unknown DoS attacks. Sensor log capacity management along with techniques which prevent the logging of redundant information during an attack also guard against DoS attacks.

Checks

Verify the IDPS protects against the use of internal information systems to launch Denial of Service (DoS) attacks against other networks or endpoints by preventing outbound traffic containing known and unknown DoS attacks. If the IDPS does not protect against the use of internal information systems to launch Denial of Service (DoS) attacks against other networks or endpoints by preventing outbound traffic containing known and unknown DoS attacks, this is a finding.

Fix

Configure the IDPS to protect against the use of internal information systems to launch Denial of Service (DoS) attacks against other networks or endpoints by preventing outbound traffic containing known and unknown DoS attacks.
SRG-NET-000365-IDPS-000199 Removed
Findings ID: SRG-NET-000365-IDPS-000199 Rule ID: SRG-NET-000365-IDPS-000199_rule Severity: medium CCI: CCI-001126

Discussion

Since the IDPS is a boundary protection device, if the IDPS fails in an unsecure manner (open), unauthorized traffic originating externally to the enclave may enter, or the device may permit unauthorized information release. Fail secure is a condition achieved by employing information system mechanisms to ensure that if the IDPS traffic monitoring and detection functions fail, it does not enter into a non-secure state where configured security properties no longer hold. If the device fails, it must not fail in a manner that will allow unauthorized access. If the IDPS traffic monitoring and detection functions fail for any reason, the IDPS must stop forwarding traffic altogether or maintain the configured security policies. If the device stops forwarding traffic, maintaining network availability can be achieved through device redundancy. Since it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.

Checks

Verify the IDPS fails securely in the event of an operational failure. If the IDPS does not fail securely in the event of an operational failure, this is a finding.

Fix

Configure the IDPS to fail securely in the event of an operational failure.
SRG-NET-000401-IDPS-000203 Removed
Findings ID: SRG-NET-000401-IDPS-000203 Rule ID: SRG-NET-000401-IDPS-000203_rule Severity: medium CCI: CCI-001310

Discussion

Packet fragmentation is allowed by the TCP/IP specifications and is encouraged in situations where it is needed. However, packet fragmentation has been used to make some attacks harder to detect (by placing them within fragmented packets), and unusual fragmentation has also been used as a form of attack. For example, some network-based attacks have used packets that should not exist in normal communications, such as sending some fragments of a packet but not the first fragment, or sending packet fragments that overlap each other. These, and other types of packet fragmentation, aim to evade the IDPS. Since it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.

Checks

Verify the IDPS, for fragmented packets, either the packets or properly reassemble the packets before inspecting and forwarding. For fragmented packets, if the IDPS does not either the packets or properly reassemble the packets before inspecting and forwarding, this is a finding.

Fix

Configure the IDPS to for fragmented packets, either the packets or properly reassemble the packets before inspecting and forwarding.
SRG-NET-000273-IDPS-000198 Removed
Findings ID: SRG-NET-000273-IDPS-000198 Rule ID: SRG-NET-000273-IDPS-000198_rule Severity: medium CCI: CCI-001312

Discussion

Internet Control Message Protocol (ICMP) messages are used to provide feedback about problems in the network. These messages are sent back to the sender to support diagnostics. However, some messages can also provide host information and network topology that may be exploited by an attacker. An IDPS must be configured to “silently drop” the packet and not send an ICMP control message back to the source. In some cases, it may be necessary to direct the traffic to a null interface. Three ICMP messages are commonly used by attackers for network mapping: Destination Unreachable, Redirect, and Address Mask Reply. These responses must be blocked on external interfaces; however, blocking the Destination Unreachable response will prevent Path Maximum Transmission Unit Discovery (PMTUD), which relies on the response “ICMP Destination Unreachable—Fragmentation Needed but DF Bit Set”. PMTUD is a useful function and should only be “broken” after careful consideration. An acceptable alternative to blocking all Destination Unreachable responses is to filter Destination Unreachable messages generated by the IDPS to allow ICMP Destination Unreachable—Fragmentation Needed but DF Bit Set (Type 3, Code 4) and apply this filter to the external interfaces.

Checks

Verify the IDPS blocks outbound ICMP Destination Unreachable, Redirect, and Address Mask reply messages. If the IDPS does not block outbound ICMP Destination Unreachable, Redirect, and Address Mask reply messages, this is a finding.

Fix

Configure the IDPS to block outbound ICMP Destination Unreachable, Redirect, and Address Mask reply messages. An acceptable alternative to blocking all Destination Unreachable responses is to filter Destination Unreachable messages generated by the firewall implementation to allow ICMP Destination Unreachable—Fragmentation Needed but DF Bit Set (Type 3, Code 4) and apply this filter to the external interfaces.
SRG-NET-000273-IDPS-000204 Removed
Findings ID: SRG-NET-000273-IDPS-000204 Rule ID: SRG-NET-000273-IDPS-000204_rule Severity: medium CCI: CCI-001312

Discussion

Internet Control Message Protocol (ICMP) messages are used to provide feedback about problems in the network. These messages are sent back to the sender to support diagnostics. However, some messages can also provide host information, network topology, and a covert channel that may be exploited by an attacker. Given the prevalence of ICMP traffic on the network, monitoring for malicious ICMP traffic would be cumbersome. Vendors provide signatures and rules which filter for known ICMP traffic exploits.

Checks

Verify the IDPS blocks malicious ICMP packets by properly configuring ICMP signatures and rules. If the IDPS does not block malicious ICMP packets by properly configuring ICMP signatures and rules, this is a finding.

Fix

Configure the IDPS to block malicious ICMP packets by properly configuring ICMP signatures and rules.
SRG-NET-000251-IDPS-000178 Removed
Findings ID: SRG-NET-000251-IDPS-000178 Rule ID: SRG-NET-000251-IDPS-000178_rule Severity: medium CCI: CCI-001247

Discussion

Failing to automatically update malicious code protection mechanisms, including application software files, signature definitions, and vendor-provided rules, leaves the system vulnerable to exploitation by recently developed attack methods and programs. An automatic update process ensures this important task is performed without the need for SA intervention. The IDPS is a key malicious code protection mechanism in the enclave infrastructure. To ensure this protection is responsive to changes in malicious code threats, IDPS components must be automatically updated, including anti-virus signatures, detection heuristics, vendor-provided rules, and vendor-provided signatures. If a DoD patch management server or update repository having the tested/verified updates is available for the IDPS component, the components must be configured to automatically check this server/site for updates and install new updates. If a DoD server/site is not available, the component must be configured to automatically check a trusted vendor site for updates. A trusted vendor is either commonly used by DoD, specifically approved by DoD, the vendor from which the equipment was purchased, or approved by the local program's CCB.

Checks

Verify the IDPS automatically installs updates to signature definitions, detection heuristics, and vendor-provided rules. If the IDPS does not install updates to signature definitions, detection heuristics, and vendor-provided rules, this is a finding.

Fix

Configure the IDPS to install updates to signature definitions, detection heuristics, and vendor-provided rules.
SRG-NET-000246-IDPS-000205 Removed
Findings ID: SRG-NET-000246-IDPS-000205 Rule ID: SRG-NET-000246-IDPS-000205_rule Severity: medium CCI: CCI-001240

Discussion

Failing to update malicious code protection mechanisms, including application software files, signature definitions, and vendor-provided rules, leaves the system vulnerable to exploitation by recently developed attack methods and programs. The IDPS is a key malicious code protection mechanism in the enclave infrastructure. To ensure this protection is responsive to changes in malicious code threats, IDPS components must be updated, including application software files, anti-virus signatures, detection heuristics, vendor-provided rules, and vendor-provided signatures. Updates must be installed in accordance with the CCB procedures for the local organization. However, at a minimum: 1. Updates designated as critical security updates by the vendor must be installed immediately. 2. Updates for signature definitions, detection heuristics, and vendor-provided rules must be installed immediately. 3. Updates for application software are installed in accordance with the CCB procedures. 4. Prior to automatically installing updates, either manual or automated integrity and authentication checking is required, at a minimum, for application software updates.

Checks

Verify the IDPS installs updates for application software files, signature definitions, detection heuristics, and vendor-provided rules when new releases are available in accordance with organizational configuration management policy and procedures. If the IDPS does not install updates for application software files, signature definitions, detection heuristics, and vendor-provided rules when new releases are available in accordance with organizational configuration management policy and procedures, this is a finding.

Fix

Configure the IDPS to install updates for application software files, signature definitions, detection heuristics, and vendor-provided rules when new releases are available in accordance with organizational configuration management policy and procedures.
SRG-NET-000246-IDPS-000175 Removed
Findings ID: SRG-NET-000246-IDPS-000175 Rule ID: SRG-NET-000246-IDPS-000175_rule Severity: medium CCI: CCI-001240

Discussion

If the integrity of updates downloaded directly from the vendor is not verified, then malicious code or errors may impact the ability of the IDPS to protect against harmful communication traffic. The recommended verification method depends on the update’s format, as follows: 1. For files downloaded from a Web site or FTP site, administrators should compare file checksums provided by the vendor with checksums that they compute for the downloaded files. 2. For updates downloaded automatically through the IDPS user interface, if an update is downloaded as a single file or a set of files, either checksum provided by the vendor should be compared to checksums generated by the administrator, or the IDPS user interface itself should perform some sort of integrity check. In some cases, updates are downloaded and installed as one action, precluding checksum verification. In this case, the IDPS user interface should check each update’s integrity as part of this process. 3. In the case of removable media (e.g., CD, DVD), vendors may not provide a specific method for customers to verify the legitimacy of removable media apparently sent by the vendors. If media verification is a concern, administrators should contact their vendors to determine how the media can be verified, such as comparing vendor-provided checksums to checksums computed for files on the media, or verifying digital signatures on the media’s contents to ensure they are valid. Administrators should also consider scanning the media for malware, with the caveat that false positives may be triggered by IDPS signatures for malware on the media.

Checks

Verify the IDPS verifies the integrity of updates obtained directly from the vendor. If the IDPS does not verify the integrity of updates obtained directly from the vendor, this is a finding.

Fix

Configure the IDPS to verify the integrity of updates obtained directly from the vendor.
SRG-NET-000248-IDPS-000206 Removed
Findings ID: SRG-NET-000248-IDPS-000206 Rule ID: SRG-NET-000248-IDPS-000206_rule Severity: medium CCI: CCI-001242

Discussion

Real-time monitoring of files from external sources at network entry/exit points helps to detect covert malicious code before it is downloaded to or executed by internal and external endpoints. Using malicious code, such as viruses, worms, Trojan horses, and spyware, an attacker may gain access to sensitive data and systems. IDPSs innately meet this requirement for real time scanning for malicious code when properly configured to meet the requirements of this SRG. However, most products perform communications traffic inspection at the packet level.

Checks

Verify the IDPS performs real-time monitoring of files from external sources at network entry/exit points. If the IDPS does not perform real-time monitoring of files from external sources at network entry/exit points, this is a finding.

Fix

Configure the IDPS to perform real-time monitoring of files from external sources at network entry/exit points.
SRG-NET-000249-IDPS-000176 Removed
Findings ID: SRG-NET-000249-IDPS-000176 Rule ID: SRG-NET-000249-IDPS-000176_rule Severity: medium CCI: CCI-001243

Discussion

Taking an appropriate action based on local organizational incident handling procedures minimizes the impact of this code on the network. The IDPS must be configured to block all detected malicious code. Sometimes it is necessary to generate a log event and then automatically delete the malicious code; however, for critical attacks or where forensic evidence is deemed necessary, the file should be quarantined for further investigation.

Checks

Verify the IDPS blocks and either deletes or quarantines malicious code. If the IDPS does not block and either delete or quarantine malicious code, this is a finding.

Fix

Configure the IDPS to block and either delete or quarantine malicious code.
SRG-NET-000249-IDPS-000207 Removed
Findings ID: SRG-NET-000249-IDPS-000207 Rule ID: SRG-NET-000249-IDPS-000207_rule Severity: medium CCI: CCI-001243

Discussion

Without an alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis and detect rate-based and other anomalies will be impeded. The IDPS generates an alert which notifies designated personnel of the incident. These messages should include a severity level indicator or code as an indicator of the criticality of the incident.

Checks

Verify the IDPS generates an alert, at a minimum, to the SA when malicious code is detected. If the IDPS does not generate an alert, at a minimum, to the SA when malicious code is detected, this is a finding.

Fix

Configure the IDPS to generate an alert, at a minimum, to the SA when malicious code is detected.
SRG-NET-000383-IDPS-000208 Removed
Findings ID: SRG-NET-000383-IDPS-000208 Rule ID: SRG-NET-000383-IDPS-000208_rule Severity: medium CCI: CCI-002656

Discussion

An integrated, network-wide intrusion detection capability increases the ability to detect and prevent sophisticated distributed attacks based on access patterns and characteristics of access. Integration is more than centralized logging and a centralized management console. The enclave's monitoring capability may include multiple sensors, IPS, sensor event databases, behavior-based monitoring devices, application-level content inspection systems, malicious code protection software, scanning tools, audit record monitoring software, and network monitoring software. Some tools may monitor external traffic while others monitor internal traffic at key boundaries. These capabilities may be implemented using different devices and therefore can have different security policies and severity-level schema. This is valuable because content filtering, monitoring, and prevention can become a bottleneck on the network if not carefully configured.

Checks

Verify the IDPS integrates with a network-wide monitoring capability which includes sensors, event databases, and management consoles. If the IDPS does not integrate with a network-wide monitoring capability which includes sensors, event databases, and management consoles, this is a finding.

Fix

Configure the IDPS to perform real-time monitoring of files from external sources at network entry/exit points as they are downloaded and prior to being opened or executed.
SRG-NET-000384-IDPS-000209 Removed
Findings ID: SRG-NET-000384-IDPS-000209 Rule ID: SRG-NET-000384-IDPS-000209_rule Severity: medium CCI: CCI-002683

Discussion

Unauthorized or unapproved network services lack organizational verification or validation and therefore may be unreliable or serve as malicious rogues for valid services. Examples of network services include service-oriented architectures (SOAs), cloud-based services (e.g., infrastructure as a service, platform as a service, or software as a service), cross-domain, Voice Over Internet Protocol, Instant Messaging, auto-execute, and file sharing. To comply with this requirement, the IDPS may be configured to detect services either directly or indirectly (i.e., by detecting traffic associated with a service).

Checks

Verify the IDPS detects network services that have not been authorized or approved by the IAM/IAO, at a minimum. If the IDPS does not detect network services that have not been authorized or approved by the IAM/IAO, at a minimum, this is a finding.

Fix

Configure the IDPS to detect network services that have not been authorized or approved by the IAM/IAO, at a minimum.
SRG-NET-000385-IDPS-000210 Removed
Findings ID: SRG-NET-000385-IDPS-000210 Rule ID: SRG-NET-000385-IDPS-000210_rule Severity: medium CCI: CCI-002684

Discussion

Unauthorized or unapproved network services lack organizational verification or validation and therefore may be unreliable or serve as malicious rogues for valid services. Appropriate personnel must be notified when such unauthorized services are detected. Examples of network services include service-oriented architectures (SOAs), cloud-based services (e.g., infrastructure as a service, platform as a service, or software as a service), cross-domain, Voice Over Internet Protocol, Instant Messaging, auto-execute, and file sharing.

Checks

Verify the IDPS generates a log record when unauthorized network services are detected. If the IDPS does not generate a log record when unauthorized network services are detected, this is a finding.

Fix

Configure the IDPS to generate a log record when unauthorized network services are detected.
SRG-NET-000385-IDPS-000211 Removed
Findings ID: SRG-NET-000385-IDPS-000211 Rule ID: SRG-NET-000385-IDPS-000211_rule Severity: medium CCI: CCI-002684

Discussion

Unauthorized or unapproved network services lack organizational verification or validation and therefore may be unreliable or serve as malicious rogues for valid services. Appropriate personnel must be notified when such unauthorized services are detected. Automated mechanisms can be used to send automatic alerts or notifications. Such automatic alerts or notifications can be conveyed in a variety of ways (e.g., telephonically, via electronic mail, via text message, or via websites). The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel.

Checks

Verify the IDPS generates an alert to the IAO, IAM, and other individuals designated by the local organization when unauthorized network services are detected. If the IDPS does not generate an alert to the IAO, IAM, and other individuals designated by the local organization when unauthorized network services are detected, this is a finding.

Fix

Configure the IDPS to generate an alert to the IAO, IAM, and other individuals designated by the local organization when unauthorized network services are detected.
SRG-NET-000390-IDPS-000212 Removed
Findings ID: SRG-NET-000390-IDPS-000212 Rule ID: SRG-NET-000390-IDPS-000212_rule Severity: medium CCI: CCI-002661

Discussion

If inbound communications traffic is not continuously monitored for unusual/unauthorized activities or conditions, there will be times when hostile activity may not be noticed and defended against. Although some of the components in the site's content scanning solution may be used for periodic scanning assessment, the IDPS sensors and other components must provide continuous, 24 hours a day, 7 days a week monitoring. Unusual/unauthorized activities or conditions related to information system inbound communications traffic include, for example, internal traffic that indicates the presence of malicious code within organizational information systems or propagating among system components, the unauthorized exporting of information, or signaling to external information systems. Anomalies within organizational information systems include, for example, large file transfers, long-time persistent connections, use of unusual protocols and ports, and communications with suspected or known malicious external entities.

Checks

Verify the IDPS continuously monitors inbound communications traffic for unusual/unauthorized activities or conditions. If the IDPS does not continuously monitor inbound communications traffic for unusual/unauthorized activities or conditions, this is a finding.

Fix

Configure the IDPS to continuously monitor inbound communications traffic for unusual/unauthorized activities or conditions.
SRG-NET-000391-IDPS-000213 Removed
Findings ID: SRG-NET-000391-IDPS-000213 Rule ID: SRG-NET-000391-IDPS-000213_rule Severity: medium CCI: CCI-002662

Discussion

If outbound communications traffic is not continuously monitored for unusual/unauthorized activities or conditions, there will be times when hostile activity may not be noticed and defended against. Although some of the components in the site's content scanning solution may be used for periodic scanning assessment, the IDPS sensors and other components must provide continuous, 24 hours a day, 7 days a week monitoring. Unusual/unauthorized activities or conditions related to information system outbound communications traffic include, for example, internal traffic that indicates the presence of malicious code within organizational information systems or propagating among system components, the unauthorized exporting of information, or signaling to external information systems. Anomalies within organizational information systems include, for example, large file transfers, long-time persistent connections, use of unusual protocols and ports, and communications with suspected or known malicious external entities.

Checks

Verify the IDPS continuously monitors outbound communications traffic for unusual/unauthorized activities or conditions. If the IDPS does not continuously monitor outbound communications traffic for unusual/unauthorized activities or conditions, this is a finding.

Fix

Configure the IDPS to continuously monitor outbound communications traffic for unusual/unauthorized activities or conditions.
SRG-NET-000392-IDPS-000214 Removed
Findings ID: SRG-NET-000392-IDPS-000214 Rule ID: SRG-NET-000392-IDPS-000214_rule Severity: medium CCI: CCI-002664

Discussion

Without an alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis and detect rate-based and other anomalies will be impeded. The IDPS generates an alert which notifies designated personnel of the incident. These messages should include a severity level indicator or code as an indicator of the criticality of the incident. In accordance with CCI-001242, real-time, the IDPS is a real-time intrusion detection system. These systems must generate an alert when detection events from real-time monitoring occur. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel.

Checks

Verify the IDPS generates an alert to IAO, IAM, and other individuals designated by the local organization when real-time monitoring of communications traffic from external sources occurs. If the IDPS does not generate an alert to the IAO, IAM, and other individuals designated by the local organization when real-time monitoring of communications traffic from external sources occurs, this is a finding.

Fix

Configure the IDPS to generate an alert to IAO, IAM, and other individuals designated by the local organization when real-time monitoring of communications traffic from external sources occurs.
SRG-NET-000392-IDPS-000215 Removed
Findings ID: SRG-NET-000392-IDPS-000215 Rule ID: SRG-NET-000392-IDPS-000215_rule Severity: medium CCI: CCI-002664

Discussion

Without an alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis and detect rate-based and other anomalies will be impeded. The IDPS generates an alert which notifies designated personnel of the incident. These messages should include a severity level indicator or code as an indicator of the criticality of the incident. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel.

Checks

Verify the IDPS generates an alert to IAO, IAM, and other individuals designated by the local organization when threats identified by authoritative sources (e.g., IAVMs, CTOs) are detected. If the IDPS does not generate an alert to IAO, IAM, and other individuals designated by the local organization when threats identified by authoritative sources (e.g., IAVMs, CTOs) are detected, this is a finding.

Fix

Configure the IDPS to generate an alert to IAO, IAM, and other individuals designated by the local organization when threats identified by authoritative sources (e.g., IAVMs, CTOs) are detected.
SRG-NET-000392-IDPS-000216 Removed
Findings ID: SRG-NET-000392-IDPS-000216 Rule ID: SRG-NET-000392-IDPS-000216_rule Severity: medium CCI: CCI-002664

Discussion

Without an alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis and detect rate-based and other anomalies will be impeded. The IDPS generates an alert which notifies designated personnel of the incident. These messages should include a severity level indicator or code as an indicator of the criticality of the incident. CJCSM 6510.01B, “Cyber Incident Handling Program”, lists nine Cyber Incident and Reportable Event Categories. Indications of a category 1, 2, 4, or 7 detection event. Category 1 - Root Level Intrusion (Incident) Category 2 - User Level Intrusion (Incident) Category 4 - Denial of Service (Incident) Category 7 - Malicious Logic (Incident) Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel.

Checks

Verify the IDPS generates an alert to IAO, IAM, and other individuals designated by the local organization when Category I, II, IV, and VII incidents in accordance with CJCSM 6510.01B occur. If the IDPS does not generate an alert to IAO, IAM, and other individuals designated by the local organization when Category I, II, IV, and VII incidents in accordance with CJCSM 6510.01B occur, this is a finding.

Fix

Configure the IDPS to generate an alert to IAO, IAM, and other individuals designated by the local organization when Category I, II, IV, and VII incidents in accordance with CJCSM 6510.01B occur.