KSI-CNA-RNT—Restricting Network Traffic
Formerly KSI-CNA-01
>Control Description
>NIST 800-53 Controls
>Trust Center Components3
Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.
From the field: Mature implementations express network resilience through redundancy metrics and chaos engineering results — not just network architecture diagrams. Automated failure injection testing validates redundant paths, and network monitoring dashboards show real-time availability across all network segments.
Network Architecture Diagram
Network topology expressing segmentation, redundancy, and traffic flow patterns
Network Availability Metrics
Dashboard expressing network health — uptime, latency, throughput, and redundancy status across all segments
Network Resilience Testing
Chaos engineering or failure injection test results — evidence that resilience is tested, not just designed
>Programmatic Queries
CLI Commands
aws ec2 describe-security-group-rules --filter "Name=group-id,Values=<sg-id>" --query "SecurityGroupRules[].{Direction:IsEgress,Protocol:IpProtocol,FromPort:FromPort,ToPort:ToPort,CIDR:CidrIpv4}" --output tableaws ec2 describe-network-acls --query "NetworkAcls[].{Id:NetworkAclId,VPC:VpcId,Rules:Entries | length(@)}" --output table>20x Assessment Focus Areas
Aligned with FedRAMP 20x Phase Two assessment methodology
Completeness & Coverage:
- •Do network traffic restrictions apply to all machine-based resources — including containers, serverless functions, managed services, and CI/CD build agents?
- •Are both inbound and outbound traffic restrictions defined and enforced, or is outbound traffic less restricted than inbound?
- •How do you ensure resources in all environments (production, staging, development) have appropriate traffic restrictions, not just production?
- •Are there resources with overly permissive network rules (e.g., 0.0.0.0/0 ingress or egress) that are documented as exceptions?
Automation & Validation:
- •What automated policy checks prevent deployment of resources with overly permissive network configurations (e.g., open security groups, unrestricted NACLs)?
- •How do you detect when a network rule is modified to be more permissive than intended — is the change automatically reverted or flagged?
- •What happens when a legitimate application needs network access that current restrictions block — how do you handle the exception without weakening the overall posture?
- •Do you run automated network reachability analysis to verify that resources can only communicate with their intended destinations?
Inventory & Integration:
- •What tools enforce network restrictions (security groups, network policies, firewall rules, service mesh), and how do they coordinate across your architecture?
- •How do you maintain an inventory of all network rules and their justifications, and is this inventory programmatically generated from IaC?
- •How do network restriction configurations integrate with your CMDB to ensure every resource has an associated network policy?
- •Are network flow logs analyzed to identify traffic patterns that should be restricted but are not?
Continuous Evidence & Schedules:
- •How do you demonstrate that network traffic restrictions have been consistently enforced over the past 90 days?
- •Is network compliance data (rule sets, violation counts, flow log analysis) available via API or dashboard for ongoing assessment?
- •How do you detect network restriction drift — rules that were tightened but later loosened — between review cycles?
- •What evidence shows network flow logs have been analyzed for unauthorized traffic patterns and anomalies?
Update History
Ask AI
Configure your API key to use AI features.