STIGViewer Support

The Juniper perimeter router must be configured to protect an enclave connected to an approved gateway by using an inbound filter that only permits packets with destination addresses within the site's address space.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-217033JUNI-RT-000280SV-217033r1050846_ruleCCI-001414high
Description
Enclaves with approved gateway connections must take additional steps to ensure there is no compromise on the enclave network or NIPRNet. Without verifying the destination address of traffic coming from the site's alternate gateway, the perimeter router could be routing transit data from the internet into the NIPRNet. This could also make the perimeter router vulnerable to a denial-of-service (DoS) attack and provide a back door into the NIPRNet. The DOD enclave must ensure the ingress filter applied to external interfaces on a perimeter router connecting to an approved gateway is secure through filters permitting packets with a destination address belonging to the DOD enclave's address block.
STIGDate
Juniper Router RTR Security Technical Implementation Guide2024-12-05

Related Frameworks

1 mapping across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (17) 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.

AST-04Network Diagrams & Data Flow Diagrams (DFDs)
1.00
AST-04.2Control Applicability Boundary Graphical Representation
1.00
CFG-02Secure Baseline Configurations
1.00
CRY-01Use of Cryptographic Controls
1.00
DCH-01Data Protection
1.00
DCH-19Geographic Location of Data
1.00
END-01Endpoint Device Management (EDM)
1.00
END-04Malicious Code Protection (Anti-Malware)
1.00
END-06Endpoint File Integrity Monitoring (FIM)
1.00
IAC-21Least Privilege
1.00

+7 more (top 10 by confidence shown)

NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (7) 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.

AC-3Access Enforcement
1.00
AC-4Information Flow Enforcement
1.00
AC-6(9)Log Use of Privileged Functions
1.00
AU-12Audit Record Generation
1.00
CM-7Least Functionality
1.00
SC-5Denial-of-service Protection
1.00
SC-7(5)Deny by Default — Allow by Exception
1.00
NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (1) 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.

3.1.3
1.00
CCI1 mapping
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 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.

Who does this work

18 NICE work roles and 10 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-217033r1050846_chk)

This requirement is not applicable for the DODIN backbone. Verify the interface connecting to the ISP has an inbound filter as shown in the example below. interfaces { ge-0/0/0 { description "Verizon ISP link"; unit 0 { family inet { filter { input ISP_FILTER; } address 11.1.12.2/24; } } } Verify that the filter only allows traffic to specific destination addresses (i.e., enclave’s NIPRNet address space) as shown in the example below. firewall { family inet { filter ISP_FILTER { term RESTRICT_DESTINATION { from { destination-address { 0.0.0.0/0; 11.1.0.0/16 except; } } then { syslog; discard; } } term ALLOW_XYZ { from { protocol xyz; } then accept; } … … … term DENY_ALL_OTHER { then { syslog; reject; } } } If the ingress filter bound to the interface connecting to an approved gateway permits packets with addresses other than those specified, such as destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the approved gateway network service provider, this is a finding.

Fix Text (F-18260r1050845_fix)

This requirement is not applicable for the DODIN backbone. Configure the ingress filter of the perimeter router connected to an approved gateway to only permit packets with destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the approved gateway network service provider as shown in the example below. [edit firewall family inet filter ISP_FILTER] set term RESTRICT_DESTINATION from destination-address 0.0.0.0/0 set term RESTRICT_DESTINATION from destination-address 11.1.0.0/16 except set term RESTRICT_DESTINATION then syslog discard insert term RESTRICT_DESTINATION before term ALLOW_XYZ