OpenControls Logo

STIG Viewer

STIGViewer Support

The Juniper Networks SRX Series Gateway IDPS must block any prohibited mobile code at the enclave boundary when it is detected.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-214618JUSX-IP-000009SV-214618r383104_ruleCCI-001662medium
Description
Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations, Shockwave videos, and macros embedded within Microsoft Office documents. Mobile code can be exploited to attack a host. It can be sent as an 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.
STIGDate
Juniper SRX Services Gateway IDPS Security Technical Implementation Guide2024-06-10

Related Frameworks

1 mapping across 4 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (3) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

END-10Mobile Code
0.50
VPM-02Vulnerability Remediation Process
0.50
VPM-04Continuous Vulnerability Remediation Activities
0.50
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (4) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

CM-7Least Functionality
1.00
SC-18(1)Identify Unacceptable Code and Take Corrective Actions
1.00
SC-18(3)Prevent Downloading and Execution
1.00
SC-18(4)Prevent Automatic Execution
1.00
CCI1 mapping
CCI-001662
1.00
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 4 hops (2) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

ID.RA-08
0.50
PR.PS-02
0.50

Details

Check Text (C-214618r383104_chk)

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 Text (F-15820r297419_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