VPCs without Private Zones
VPCs should utilise a private hosted zone for each VPC to allow for contextual DNS for ease of use and standardized addressing across environments.
EC2 instances form the backbone of many workloads. Risks arise from misconfigured networking, outdated systems, and poor access controls. Hardening, patching, and limiting exposure are critical to maintaining secure operations.
VPCs should utilise a private hosted zone for each VPC to allow for contextual DNS for ease of use and standardized addressing across environments.
AWS VPCs do not require multiple NATs unless the marginal gains from cross-AZ resiliency are worth the increased cost and maintence burden. In such cases, it may be better to consider multi-region …
Virtual Private Clouds (VPCs) should utilise private network ranges for their address space to avoid conflicts with external connections.
Organisations should avoid using the default address space provided by AWS Virtual Private Clouds (VPCs), as this limits connectivity options such as VPC Peering in the future.
VPCs should not use the range 172.17.0.0/16, as it is used by some AWS services when configured in your network.
VPC Peering is a complex solution for inter-network connectivity that may be better replaced with VPC Private Links or other alternatives.
Elastic IP addresses are requisitioned by the account but not in current use
Unecrypted EBS Snapshots contain all data on the original EBS volume in an unencrypted format, failing to protect this data from unauthorised decryption
Subnets should be explicitly associated with a route table to ensure route updates are explicit and controlled.
Subnets should utilise a single exit route for outbound traffic, such as an Internet Gateway or a NAT, and not multiple external routes.
SSH Keys that are available in an AWS account allow for provisioning of OpenSSH server and provide metadata information that can be utilised for research
Public EBS Snapshots mean that any AWS customer can create a volume in the same AWS Region from the EBS snapshot effectively making the data public
Outside of entirely open-source resources, AMIs should never be shared publicly.
Fully open security groups are wholly open to all of the internet including from geographic locations with no business benefits
VPC Flow Logs provide forensic logs utilised for tracking breach origins and lateral movement. Missing or unconfigured flow logs deny access to vital forensic data
Instances using SSH Keys are configured to run OpenSSH server leaving them exposed to OpenSSH attacks, lacking the features of other access methods and reinforcing the use of pet style infrastructure.
Instances not running inside a VPC are unsupported
Instances in public subnets without routes to a NAT require an Elastic IP to communicate externally exposing them directly to internet traffic. This is a diminished security posture compared to …
An EC2 instance that utilising a public IP address directly connects the instance to the internet leading to a vastly diminished security posture compared to available architectures utilising …
EC2 instances that do not exclusively utilise the IMDSv2 endpoints utilise a weaker version of IMDS issued credentials that lack a number of protections against theft and misuse.
EC2 Instances without an IAM Role attached either do not have permissions to securely interact with AWS Services or they host long term credentials that are prone to compromise
Instances do not have monitoring enabled, causing a large amount of data loss that can indicate compromiseand breaches
DNS resolution should be shared across peered VPCs to ensure that each VPC routes privately to endpoints in the peered VPC network.
Virtual Private Clouds (VPCs) should be designed with standardized subnet spaces to facilitate maintenance and optimise address space utilization.
Default VPCs are often insecure cloud environments providing ease of access rather than a secure posture, enabling implicit configurations with insecure defaults