STIGViewer Support

The Cisco perimeter switch must be configured to enforce approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-221088CISC-RT-000250SV-221088r1137907_ruleCCI-001414medium
Description
Information flow control regulates authorized information to travel within a network and between interconnected networks. Controlling the flow of network traffic is critical so it does not introduce any unacceptable risk to the network infrastructure or data. An example of a flow control restriction is blocking outside traffic claiming to be from within the organization. For most switches, internal information flow control is a product of system design.
STIGDate
Cisco NX OS Switch RTR Security Technical Implementation Guide2026-03-04

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-221088r1137907_chk)

Review the switch configuration to verify that ACLs are configured to allow or deny traffic for specific destination addresses as well as ports and protocols. In the example below, the switch is peering BGP with DISN. ICMP echo and echo-reply packets are allowed for troubleshooting connectivity. WWW traffic is permitted inbound to the NIPRNet host-facing web server (x.11.2.3). Step 1: Verify that an inbound ACL is applied to all external interfaces as shown in the example below: interface Ethernet2/2 description link to DISN no switchport ip access-group EXTERNAL_ACL in ip address x.11.1.2 255.255.255.254 Step 2: Review inbound ACL to verify that it is configured to deny all other traffic that is not explicitly allowed. ip access-list EXTERNAL_ACL 10 permit tcp any any established 20 permit tcp x.11.1.1/32 eq bgp x.11.1.2/32 30 permit tcp x.11.1.1/32 x.11.1.2/32 eq bgp 40 permit icmp x.11.1.1/32 x.11.1.2/32 echo 50 permit icmp x.11.1.1/32 x.11.1.2/32 echo-reply 60 permit tcp any x.11.2.3/32 eq www 70 permit … … … … 90 deny ip any any log If the switch is not configured to enforce approved authorizations for controlling the flow of information between interconnected networks, this is a finding.

Fix Text (F-22792r409754_fix)

Step 1: Configure an ACL to allow or deny traffic as shown in the example below: SW2(config)# ip access-list EXTERNAL_ACL SW2(config-acl)# permit tcp any any established SW2(config-acl)# permit tcp x.11.1.1/32 eq bgp x.11.1.2/32 SW2(config-acl)# permit tcp x.11.1.1/32 x.11.1.2/32 eq bgp SW2(config-acl)# permit icmp x.11.1.1/32 x.11.1.2/32 echo SW2(config-acl)# permit icmp x.11.1.1/32 x.11.1.2/32 echo-reply SW2(config-acl)# permit tcp any x.11.2.3/32 eq www SW2(config-acl)# deny ip any any log SW2(config-acl)# exit Step 2: Apply the ACL inbound on all applicable interfaces. SW1(config)#int e2/2 SW1(config-if)# ip access-group EXTERNAL_ACL in