Benchmark: 3.13.4e Employ [Selection: (one or more): [Assignment: organization-defined physical isolation techniques]; [Assignment: organization-defined logical isolation techniques]] in organizational systems and system components
Description
A mix of physical and logical isolation techniques (described below) implemented as part of the system architecture can limit the unauthorized flow of CUI, reduce the system attack surface, constrain the number of system components that must be secure, and impede the movement of an adversary. When implemented with a set of managed interfaces, physical and logical isolation techniques for organizational systems and components can isolate CUI into separate security domains where additional protections can be implemented. Any communications across the managed interfaces (i.e., across security domains), including for management or administrative purposes, constitutes remote access even if the communications remain within the organization. Separating system components with boundary protection mechanisms allows for the increased protection of individual components and more effective control of information flows between those components. This enhanced protection limits the potential harm from and susceptibility to hostile cyber-attacks and errors. The degree of isolation can vary depending on the boundary protection mechanisms selected. Boundary protection mechanisms include routers, gateways, and firewalls separating system components into physically separate networks or subnetworks; virtualization and micro-virtualization techniques; encrypting information flows among system components using distinct encryption keys; cross-domain devices separating subnetworks; and complete physical separation (i.e., air gaps).
Usage
Install the mod:
mkdir dashboardscd dashboardspowerpipe mod initpowerpipe mod install github.com/turbot/steampipe-mod-aws-compliance
Start the Powerpipe server:
steampipe service startpowerpipe server
Open http://localhost:9033 in your browser and select 3.13.4e Employ [Selection: (one or more): [Assignment: organization-defined physical isolation techniques]; [Assignment: organization-defined logical isolation techniques]] in organizational systems and system components.
Run this benchmark in your terminal:
powerpipe benchmark run aws_compliance.benchmark.nist_800_172_3_13_4_e
Snapshot and share results via Turbot Pipes:
powerpipe benchmark run aws_compliance.benchmark.nist_800_172_3_13_4_e --share
Controls
- Auto Scaling launch config public IP should be disabled
- 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
- 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
- OpenSearch domains should be in a VPC
- RDS DB instances should prohibit public access
- RDS snapshots should prohibit public access
- AWS Redshift enhanced VPC routing should be enabled
- Redshift clusters should prohibit public access
- S3 buckets should prohibit public read access
- S3 buckets should prohibit public write access
- S3 public access should be blocked at account level
- S3 public access should be blocked at bucket levels
- SageMaker notebook instances should not have direct internet access
- SSM documents should not be public
- VPC default security group should not allow inbound and outbound traffic
- VPC route table should restrict public access to IGW
- VPC Security groups should only allow unrestricted incoming traffic for authorized ports
- VPC security groups should restrict ingress access on ports 20, 21, 22, 3306, 3389, 4333 from 0.0.0.0/0
- VPC security groups should restrict ingress SSH access from 0.0.0.0/0
- VPC subnet auto assign public IP should be disabled
- Network ACLs should not allow ingress from 0.0.0.0/0 to port 22 or port 3389