Benchmark: 1.3 Examine firewall and router configurations—including but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment—and perform the following to determine that there is no direct access between the Internet and system components in the internal cardholder network segment
Description
While there may be legitimate reasons for untrusted connections to be permitted to DMZ systems (e.g., to allow public access to a web server), such connections should never be granted to systems in the internal network. A firewall's intent is to manage and control all connections between public systems and internal systems, especially those that store, process or transmit cardholder data. If direct access is allowed between public systems and the CDE, the protections offered by the firewall are bypassed, and system components storing cardholder data may be exposed to compromise.
Usage
Install the mod:
mkdir dashboardscd dashboardspowerpipe mod initpowerpipe mod install github.com/turbot/steampipe-mod-aws-complianceStart the Powerpipe server:
steampipe service startpowerpipe serverOpen http://localhost:9033 in your browser and select 1.3 Examine firewall and router configurations—including but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment—and perform the following to determine that there is no direct access between the Internet and system components in the internal cardholder network segment.
Run this benchmark in your terminal:
powerpipe benchmark run aws_compliance.benchmark.pci_dss_v321_requirement_1_3Snapshot and share results via Turbot Pipes:
powerpipe benchmark run aws_compliance.benchmark.pci_dss_v321_requirement_1_3 --shareBenchmarks
- 1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports
- 1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ
- 1.3.3 Examine firewall and router configurations to verify that anti-spoofing measures are implemented, for example internal addresses cannot pass from the Internet into the DMZ
- 1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet
- 1.3.5 Examine firewall and router configurations to verify that the firewall permits only established connections into the internal network and denies any inbound connections not associated with a previously established session
- 1.3.6 Examine firewall and router configurations to verify that system components that store cardholder data are on an internal network zone, segregated from the DMZ and other untrusted networks
Controls
- DMS replication instances should not be publicly accessible
- EBS snapshots should not be publicly restorable
- EC2 instances should be in a VPC
- EC2 instances should not have a public IP address
- EKS clusters endpoint should restrict public access
- EMR cluster master nodes should not have public IP addresses
- ES domains should be in a VPC
- Lambda functions should be in a VPC
- Lambda functions should restrict public access
- RDS DB instances should prohibit public access
- RDS snapshots should prohibit public access
- Redshift clusters should prohibit public access
- S3 buckets should prohibit public read access
- S3 public access should be blocked at account level
- SageMaker notebook instances should not have direct internet access
- VPC should be configured to use VPC endpoints
- VPC internet gateways should be attached to authorized vpc