Juniper SRX SG IDPS Security Technical Implementation Guide

V1R2 2017-07-07       U_Juniper_SRX_SG_IDPS_STIG_V1R2_Manual-xccdf.xml
V1R1 2016-03-30       U_Juniper_SRX_SG_IDPS_STIG_V1R1_Manual-xccdf.xml
This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: [email protected]
Comparison
All 28
No Change 27
Updated 1
Added 0
Removed 0
V-66009 No Change
Findings ID: JUSX-IP-000010 Rule ID: SV-80499r1_rule Severity: high 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 predefined signature objects, applications signatures, IDPS policy templates, and device software 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

To check the version of the security package installed, enter the following command from the root on the device:

show security idp security-package-version

Compare the installed release with the latest available and approved release.

If a new release is available and not installed, this is a finding.

Fix

Since DoD does not allow the management port of security devices to be connected directly to the Internet, the required security package must be uploaded using the Juniper SRX offline process.

Directions are available in the document “How to perform offline IDP and Application signature database update in SRX” on the Juniper Networks support site. DoD network policy requires a local file repository be used to automate the update for network devices.

Before uploading updates, the IDP administrator must verify the updates are approved by the site's CCB procedures and are authorized for installation. Once all files have been downloaded and approved, install the security package on SRX from root.

Request security idp security-package install source-path /var/db/idpd/sec-download
V-66377 No Change
Findings ID: JUSX-IP-000001 Rule ID: SV-80867r1_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 Juniper SRX with IDP-enabled policies has the capability to capture and log detected security violations and potential security violations.

Checks

To verify that the configuration is working properly, use the following command:

[edit]
show security alarms

View the configured alarms to verify at least one option for potential-violation is set to “idp”.

If a potential-violation alarm is not defined for “idp”, this is a finding.

Fix

A Routing Engine configuration option allows the enabling and disabling of IDP alarms.

By default, the IDP attack event triggers the current logs without raising any alarms. When the option is set and the system is configured appropriately, the IDP logs on the Packet Forwarding Engine will be forwarded to Routing Engine, which then parses the IDP attack logs and raises IDP alarms as necessary.

To enable an IDP alarm, use the set security alarms potential-violation idp command.

To turn on logging, you must first turn on notification to log attacks:
set security idp idp-policy recommended rulebase-ips rule-1 then notification log-attacks

Configure Syslog (adding to the firewall stanza).
syslog {
file IDP_Log {
any any;
match RT_IDP;
V-66383 No Change
Findings ID: JUSX-IP-000002 Rule ID: SV-80873r1_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.

The PPSM CAL addresses internal network boundaries restrictions based on traffic type and content such as ports, protocols and services. The Juniper SRX denies all traffic.

IDPS inspection will only be performed on the traffic matching the security policies where IDPS is enabled.

Checks

Review the list of authorized Junos applications, endpoints, services, and protocols that are installed on the PPSM CAL.

Use the following command to show the IDP-specific policies:

[edit]
show security idp

Next, use the show security policies command to display a summary of all the security policies.

[edit]
show security policies

Note: Also inspect the organization's central events log server (e.g., syslog server) for Deny events that match the restrictions in the PPSM CAL.

If security policies do not exist to block or restrict communications traffic that is identified as harmful or suspicious by the PPSM and vulnerability assessment, this is a finding.

Fix

Specify an active IDP policy prior to enabling IDP within a security policy. To configure the active IDP policy, execute the following command in configuration mode:

[edit]
set security idp active-policy <policy name>

Configure Security Policies for IDP inspection. Once the IDP policy is configured, IDP must be enabled on a security policy in order for IDP inspection to be performed. IDP inspection will only be performed on the traffic matching the security policies where IDP is enabled.

To enable IDP on a security policy, enter the following command:

[edit]
set security policies from-zone <FROM ZONE NAME> to-zone <TO ZONE NAME> policy <POLICY
NAME> then permit application-services idp
V-66385 No Change
Findings ID: JUSX-IP-000003 Rule ID: SV-80875r1_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.

Once an attack object in the IPS policy is matched, the SRX can execute an action on that specific session, along with actions on future sessions. The ability to execute an action on that particular session is known as an IDPS action. IDPS actions can be one of the following: No-Action, Drop-Packet, Drop-Connection, Close-Client, Close-Server, Close-Client-and-Server, DSCP-Marking, Recommended, or Ignore. IP actions are actions that can be enforced on future sessions. These actions include IP-Close, IP-Block, and IP-Notify

This includes traffic between interfaces that are associated within the same security zone (intra-zone traffic). Traffic is permitted between security zones by configuring security policies from a source security zone to the destination security zone. IDPS inspection will only be performed on the traffic matching the security policies where IDPS is enabled.

Checks

Verify custom rules exist to drop packets or terminate sessions upon detection of malicious code.

[edit]
show security idp policy

View the rulebase action option for the IDP policies. View the action options of the zone configurations with the IDP option.

If rulebases in active policies are configured for No-Action or Ignore when harmful or suspicious content is detected by signatures, rules, or policies, this is a finding.

Fix

Specify an active IDP policy prior to enabling IDP within a security policy. To configure the active IDP policy, execute the following command in configuration mode:

[edit]
set security idp active-policy <policy name>

Configure Security Policies for IDP inspection. Once the IDP policy is configured, IDP must be enabled on a security policy in order for IDP inspection to be performed. IDP inspection will only be performed on the traffic matching the security policies where IDP is enabled.

To enable IDP on a security policy, enter the following command:

[edit]
set security policies from-zone <FROM ZONE NAME> to-zone <TO ZONE NAME> policy <POLICY NAME> then permit application-services idp
V-66387 No Change
Findings ID: JUSX-IP-000004 Rule ID: SV-80877r1_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

Use the following command to view the IDP rules:

[edit]
show security idp status

The IDP traffic log can also be inspected to verify that IDP detection events contain a severity level in the log record.

If active IDP rules exist that do not include a severity level, this is a finding.

Fix

Example configuration to set the severity level on the IDP rules:

Define an attack as match criteria.
[edit security idp idp-policy base-policy rulebase-ips rule R1]
set match attacks predefined-attack-groups "TELNET-Critical"

Specify an action for the rule.
[edit security idp idp-policy base-policy rulebase-ips rule R1]
set then action drop-connection

Specify notification and logging options for the rule.
[edit security idp idp-policy base-policy rulebase-ips rule R1]
set then notification log-attacks alert

Set the severity level for the rule.

[edit security idp idp-policy base-policy rulebase-ips rule R1]

set then severity critical
V-66395 No Change
Findings ID: JUSX-IP-000005 Rule ID: SV-80885r1_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

Determine the names of the IDP policies by asking the site representative. From operational mode, enter the following command to verify outbound zones are configured with an IDP policy.

show security policies

If zones bound to the outbound interfaces, including VPN zones, are not configured with an IDP policy, this is a finding.

Fix

To enable IDP services on outbound traffic on the device, first create a security policy for the traffic flowing in one direction, then specify the action to be taken on traffic that matches conditions specified in the policy.

[edit security policies from-zone <trusted-zone1-name> to-zone <untrusted-zone-name> policy idp-app-policy-1]
set match source-address any destination-address any application any

[edit security policies from-zone <trusted-zone-name> to-zone untrusted-zone-name> policy <idp-app-policy-name>]
set then permit application-services idp
V-66399 No Change
Findings ID: JUSX-IP-000006 Rule ID: SV-80889r1_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.

To perform signature-based attacks on the Juniper SRX IDPS device, create a signature-based attack object.

Checks

From operational mode, enter the following command to verify that the signature-based attack object was created:

show security idp policies

If signature-based attack objects are not created, bound to a zone, and active, this is a finding.

Fix

Specify a name for the attack. Specify common properties for the attack. Specify the attack type and context. Specify the attack direction and the shellcode flag. Set the protocol and its fields. Specify the protocol binding and ports. Specify the direction.

[edit]
edit security idp custom-attack sig1
set severity major
set recommended-action drop-packet
set time-binding scope source count 10
set attack-type signature context packet
set attack-type signature <signature object name>
set attack-type signature protocol ip ttl value 128 match equal
set attack-type signature protocol-binding tcp minimum-port 50 maximum-port 100
set attack-type signature direction any
V-66401 No Change
Findings ID: JUSX-IP-000007 Rule ID: SV-80891r1_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.

To perform anomaly-based attacks on the Juniper SRX IDPS device, create an anomaly-based attack object.

Checks

From operational mode, enter the following command to verify that the anomaly-based attack object was created.

show idp security policies

If anomaly-based attack objects are not created, bound to a zone, and active, this is a finding.

Fix

Create a protocol anomaly-based attack object:

Specify a name for the attack.
[edit]
security idp custom-attack anomaly1

Specify common properties for the attack.
[edit security idp custom-attack anomaly1]
set severity info
set time-binding scope peer count 2

Specify the attack type and test condition.
[edit]
security idp custom-attack anomaly1
set attack-type anomaly test OPTIONS_UNSUPPORTED

Specify other properties for the anomaly attack.
[edit]
security idp custom-attack anomaly1
set attack-type anomaly service TCP
u set attack-type anomaly direction any
attack-type anomaly shellcode spark
V-66403 No Change
Findings ID: JUSX-IP-000008 Rule ID: SV-80893r1_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 email 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

From operational mode, enter the following command to verify that the signature-based attack object was created:

show security idp policies

If signature-based attack objects are not created and used, this is a finding.

Fix

Specify a name for the attack. Specify common properties for the attack. Specify the attack type and context. Specify the attack direction and the shellcode flag. Set the protocol and its fields. Specify the protocol binding and ports. Specify the direction.

[edit]
edit security idp custom-attack <signature-name>
set severity major
set recommended-action drop-packet
set time-binding scope source count 10
set attack-type signature context packet
set attack-type signature shellcode intel
set attack-type signature protocol ip ttl value 128 match equal
set attack-type signature protocol-binding tcp minimum-port 50 maximum-port 100
set attack-type signature direction any
V-66405 No Change
Findings ID: JUSX-IP-000009 Rule ID: SV-80895r1_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 email 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

From operational mode, enter the following command to verify outbound zones are configured with an IDP policy:

show security idp policies

If zones bound to the outbound interfaces, including VPN zones, are not configured with policy filters, rules, signatures, and anomaly analysis, this is a finding.

Fix

To enable IDP services to drop traffic when there is a detection event on a zone based on the IDP policy:

Once the IDP policy is configured, IDP must be enabled on a security policy in order for IDP inspection to be performed.

Keep in mind that IDP inspection will only be performed on the traffic matching the security policies where IDP is enabled.

To enable IDP on a security policy, enter the following command:

set security policies from-zone <FROM ZONE NAME> to-zone <TO ZONE NAME> policy <POLICY
NAME> then permit application-services idp
V-66407 No Change
Findings ID: JUSX-IP-000011 Rule ID: SV-80897r1_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 attack group is configured.

[edit]
show security idp policies

If an attack group or rule(s) is not implemented to block the packets or terminate the session associated with code injection attacks that could be launched against databases, this is a finding.

Fix

Configure an attack group for "INJ" and "CMDEXEC" attacks in the signature database which are recommended. Consult the Junos Security Intelligence Center IDP signatures website for a list and details of each attack, along with recommended action upon detection. Then add the attack group to a policy.

Specify the attack group as match criteria in an IDP policy rule. Specify a match criteria and IDP action to block the IP packet or terminate the connection.
V-66409 No Change
Findings ID: JUSX-IP-000012 Rule ID: SV-80899r1_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 attack group is configured.

[edit]
show security idp policies

If an attack group or rule(s) is not implemented to block the packets or terminate the session associated with code injection attacks that could be launched against applications, this is a finding.

Fix

Configure an attack group for "INJ" and "CMDEXEC" attacks in the signature database which are recommended. Consult the Junos Security Intelligence Center IDP signatures website for a list and details of each attack, along with recommended action upon detection. Then add the attack group to a policy.

Specify the attack group as match criteria in an IDP policy rule. Specify a match criteria and IDP action to block the IP packet or terminate the connection.
V-66411 No Change
Findings ID: JUSX-IP-000013 Rule ID: SV-80901r1_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 an attack group is configured.

[edit]
show security idp policies

If an attack group or rule(s) is not implemented to block the packets or terminate the session associated with SQL injection attacks that could be launched against data storage objects, this is a finding.

Fix

Configure an attack group for "SQL" attacks in the signature database which are recommended. Consult the Junos Security Intelligence Center IDP signatures website for a list and details of each attack, along with recommended action upon detection. Then add the attack group to a policy.

Specify the attack group as match criteria in an IDP policy rule. Specify a match criteria and IDP action to block the IP packet or terminate the connection.
V-66413 No Change
Findings ID: JUSX-IP-000014 Rule ID: SV-80903r1_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 an attack group is configured.

[edit]
show security idp policies

If an attack group or rule(s) is not implemented to monitor for code injection attacks that could be launched against data storage objects, this is a finding.

Fix

Configure an attack group for "INJ" and "CMDEXEC" attacks in the signature database which are recommended. Consult the Junos Security Intelligence Center IDP signatures website for a list and details of each attack, along with recommended action upon detection. Then add the attack group to a policy.

Specify the attack group as match criteria in an IDP policy rule.
V-66415 No Change
Findings ID: JUSX-IP-000015 Rule ID: SV-80905r1_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 an attack group or rule is configured.

[edit]
show security idp policies

If an attack group or rule(s) is not implemented to monitor for code injection attacks that could be launched against application objects, this is a finding.

Fix

Configure an attack group for "INJ", "SQL", and "CMDEXEC" attacks in the signature database which are recommended. Consult the Junos Security Intelligence Center IDP signatures website for a list and details of each attack, along with recommended action upon detection. Then add the attack group to a policy.

Specify the attack group as match criteria in an IDP policy rule.
V-66417 No Change
Findings ID: JUSX-IP-000016 Rule ID: SV-80907r1_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 an attack group or rule is configured.

[edit]
show security idp policies

If an attack group or rule(s) is not implemented to monitor for SQL injection attacks that could be launched against data storage objects, this is a finding.

Fix

Configure an attack group for "SQL" attacks in the signature database which are recommended. Consult the Junos Security Intelligence Center IDP signatures website for a list and details of each attack, along with recommended action upon detection. Then add the attack group to a policy.

Specify the attack group as match criteria in an IDP policy rule.
V-66419 No Change
Findings ID: JUSX-IP-000017 Rule ID: SV-80909r1_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.

The Juniper SRX must be configured with screens using the Firewall STIG, but must also be configured for anomaly-based protection using various locally developed anomaly-based attack objects.

Checks

From operational mode, enter the following command to verify that the anomaly-based attack object was created:

show idp security policies

If anomaly-based attack objects are not created, bound to a zone, and active, this is a finding.

Fix

Create a protocol anomaly-based attack object:

Specify a name for the attack.
[edit]
security idp custom-attack anomaly1

Specify common properties for the attack.
[edit security idp custom-attack anomaly1]
set severity info
set time-binding scope peer count 2

Specify the attack type and test condition.
[edit]
security idp custom-attack anomaly1set attack-type anomaly test OPTIONS_UNSUPPORTED

Specify other properties for the anomaly attack.
[edit]
security idp custom-attack anomaly1]
set attack-type anomaly service TCP
u set attack-type anomaly direction any
attack-type anomaly shellcode spark
V-66421 Updated
Findings ID: JUSX-IP-000018 Rule ID: SV-80911r12_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. The Juniper SRX must be configured with screens using the Firewall STIG, but must also be configured for anomaly-based protection using various locally developed anomaly-based attack objects.

Checks

Verify that the anomaly-based attack object was created.

[edit]
show idp security policies

If anomaly-based attack objects are not created, bound to a zone, and active, this is a finding.

Fix

Create a protocol anomaly-based attack object:

Specify a name for the attack.
[edit]
security idp custom-attack anomaly1

Specify common properties for the attack.
[edit security idp custom-attack anomaly1]
set severity info
set time-binding scope peer count 2

Specify the attack type and test condition.
[edit]
security idp custom-attack anomaly1set attack-type anomaly test OPTIONS_UNSUPPORTED

Specify other properties for the anomaly attack.
[edit]
security idp custom-attack anomaly1]
set attack-type anomaly service TCP
u set attack-type anomaly direction any
attack-type anomaly shellcode spark
V-66423 No Change
Findings ID: JUSX-IP-000019 Rule ID: SV-80913r1_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. The Juniper SRX must be configured with screens using the Firewall STIG to protect against flood and DOS attacks type attacks, but must also be configured for anomaly-based protection

Checks

Verify an attack group or rule is configured.

[edit]
show security idp policies

If an attack group(s) or rules are not implemented to detect flood and DOS attacks, this is a finding.

Fix

Configure an attack group for "FLOOD" and "DOS" attacks in the signature database which are recommended. Consult the Junos Security Intelligence Center IDP signatures website for a list and details of each attack, along with recommended action upon detection. Then add the attack group to a policy.

Specify the attack group as match criteria in an IDP policy rule.
V-66425 No Change
Findings ID: JUSX-IP-000023 Rule ID: SV-80915r1_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 Juniper SRX IDPS can be configured for email alerts.

Checks

Verify an attack group or rule is configured.

[edit]
show security idp policies

If an attack group or rule is not implemented to detect root-level intrusion attacks or the match condition is not configured for an alert, this is a finding.

Fix

Create a custom rule that identifies the Junos application which is prohibited on the network.

Add the option "alert" onto the rule to send an alert when that rule is invoked. Alerts should be sent only on critical and other site-selected items to prevent an excess of alerts.

[edit]
set security idp idp-policy recommended rulebase-ips rule-1 then notification log-attacks alert
V-66427 No Change
Findings ID: JUSX-IP-000024 Rule ID: SV-80917r1_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 Juniper SRX IDPS can be configured for email alerts.

Checks

Verify an attack group or rule is configured.

[edit]
show security idp policies

If an attack group or rules are not configured to detect root-level intrusion attacks or the match condition is not configured for an alert, this is a finding.

Fix

Configure an attack group for "ROOT" attacks in the signature database which are recommended. Consult the Junos Security Intelligence Center IDP signatures website for a list and details of each attack, along with recommended action upon detection. Then add the attack group to a policy.

Specify the attack group as match criteria in an IDP policy rule.
V-66429 No Change
Findings ID: JUSX-IP-000025 Rule ID: SV-80919r1_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 Juniper SRX IDPS can be configured for email alerts.

Checks

Verify alerts are configured to implement this requirement.

[edit]
show security alarms potential-violation

If alerts are not configured to notify the ISSO and ISSM of potential-violation IDP events, this is a finding.

Fix

Configure alerts for IDP attack by using the [edit security alarms potential-violation] command.

Add the option "alert" onto the rule to send an alert when that rule is invoked. Alerts should be sent only on critical and other site-selected items to prevent an excess of alerts.

[edit]
set security idp idp-policy recommended rulebase-ips rule-1 then notification log-attacks alert
V-66431 No Change
Findings ID: JUSX-IP-000026 Rule ID: SV-80921r1_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 Security Control Auditor (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 automatic updates are configured.

[edit]
show security idp

If updates are not automatically installed, this is a finding.

Fix

The following example configures automatic updates of the IDP signature database:

Specify the URL to use.

[edit]
set security idp security-package url <DoD repository>

Create a schedule for the automatic downloads.

set security idp security-package automatic interval <interval>
set security idp security-package automatic enable

Also, recommend a local log be created to track when automated updates are performed for troubleshooting purposes.

set system syslog file IDP_OPERATIONS any any match IDP_SCHEDULE
V-66433 No Change
Findings ID: JUSX-IP-000027 Rule ID: SV-80923r1_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 STIG. However, most products perform communications traffic inspection at the packet level.

Checks

Verify a dynamic custom attack group which includes attack objects for malicious code monitoring of files.

show security idp dynamic-attack-group

If a custom attack group exists containing members which include malicious code attack categories, this is a finding.

Fix

Configure a dynamic custom attack group which includes attack objects for malicious code monitoring of files. There are many ways to accomplish this; thus, the following is only an example:

[edit]
security idp dynamic-attack-group Malicious-Activity
set category values [ SHELLCODE VIRUS WORMS SPYWARE TROJAN]
V-66435 No Change
Findings ID: JUSX-IP-000028 Rule ID: SV-80925r1_rule Severity: medium CCI: CCI-001243

Discussion

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

Once an attack object in the IPS policy is matched, the SRX can execute an action on that specific session, along with actions on future sessions. The ability to execute an action on that particular session is known as an IDPS action. IDPS actions can be one of the following: No-Action, Drop-Packet, Drop-Connection, Close-Client, Close-Server, Close-Client-and-Server, DSCP-Marking, Recommended, or Ignore. IP actions are actions that can be enforced on future sessions. These actions include IP-Close, IP-Block, and IP-Notify

Checks

Verify custom rules exist to drop packets or terminate sessions upon detection of malicious code.

[edit]
show security idp policy

View the rulebase action option for the IDP policies.

If rulebases for IDP policies which detect malicious code are not configured with an action of Drop-Packet, Drop-Connection, or some form of session termination, this is a finding.

Fix

This requirement can be met through a custom rule within a policy or drop action option on the zone configuration to which the policy is applied. The following is an example of the command that can be added to the IDP policy. The policy is called Malicious-Activity and the rule is called R1 in this example.

[edit]
set security idp idp-policy Malicious-Activity rulebase-ips rule R1 then action drop-connection
V-66437 No Change
Findings ID: JUSX-IP-000029 Rule ID: SV-80927r1_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 an alert is sent when malicious code is detected.

[edit]
show security idp policy

View the rulebase options for the IDP policies.

If the rulebase options for the IDP policies that detect malicious code do not contain the "alert" option, this is a finding.

Fix

This requirement can be met using an alert. Alerts must be enabled and configured and then added to the IDP policy rulebase command as an option. The following is an example of the command that can be added to the IDP policy. The policy is called Malicious-Activity and the rule is called R1 in this example.

[edit]
set security idp idp-policy Malicious-Activity rulebase-ips rule R1 then notification log-attacks alert
V-66439 No Change
Findings ID: JUSX-IP-000030 Rule ID: SV-80929r1_rule Severity: medium CCI: CCI-000366

Discussion

If the IDP or UTM licenses are allowed to lapse, the Juniper SRX IDPS can still inspect traffic and continue to use the outdated signature database for rules, objects, and dynamic groups. However, updates to the signature database cannot be downloaded from Juniper Networks. This puts the network at risk since the updates are used to addresses new CERT and IAVM vulnerabilities.

Checks

In operational mode, enter show system license.

If the license expiration for idp-sig and all other licenses installed are past today's date, this is a finding.

Fix

Update the expired licenses immediately following the procedures on the vendor website.
V-66441 No Change
Findings ID: JUSX-IP-000031 Rule ID: SV-80931r1_rule Severity: medium CCI: CCI-000366

Discussion

UTM is an industry term that was coined to define Layer 7 protection against client-side threats. This does not include IPS (which also has protection against server-to-client attacks) but rather technologies such as network-based antivirus protection, URL filtering, antispam solutions, and content filtering. IPS is primarily focused on network-based attacks on protocols, and is stream based, meaning that it processes traffic inline without modifying it as a stream. This works great from a performance perspective to detect attacks against services and applications. UTM, on the other hand, is meant more for protecting against files that are transmitted on top of the network streams. Although IPS might be more geared for detecting an overflow of the parser of the network stream, it isn’t as well geared for detecting threats within files. That is, it certainly can detect such file-based attacks, but attackers can go to great lengths to encode, encrypt, and obfuscate files to perform some malicious action—and it is very difficult to detect these attacks in Stream mode.

Checks

Verify UTM and AV policies are configured.

[edit]
show security utm

If a stanza does not exist for at least one UTM and one AV policy, this is a finding.

If the IDPS does not have UTM and AV capabilities and traffic is not forwarded to be inspected for AV and UTM threats, this is a finding.

Fix

Configure at least one policy for the UTM and AV policy using the commands and options for the [edit security utm] hierarchy.

If the UTM and AV licenses are not installed, IDPS must be installed in the architecture so that traffic is forwarded for deeper AV and UTM inspection. This can be accomplished by using a zone stanza to direct the traffic to an interface or IP destination address.