Introduction to cloud misconfigurations

Misconfiguration is one of the common threats to cloud environments.

It can happen due to a lack of knowledge using cloud services, manual configuration, failing to understand the consequences of our actions, and more.

Deviation from vendor or security best practices may lead to exposure of our cloud environment, allowing potential attackers unauthorized access to data and resources.

In this post, we will review common misconfigurations, based on the AWS environment.

Identity and access management (Root account take over)

The AWS root account is the initial account created while we provision a new AWS account.

This account has full access to all resources in our AWS environment, including:

• Ability to grant access to additional identities (privileged identity and access management)

• Create new resources (extra charges)

• Access to data (data confidentiality)

• Delete existing resources (data availability)

• Closing the entire AWS account (data and resource availability)

To protect the AWS Root account, it is recommended to take the following actions:

• Use a strong and complex password

• Enable multi-factor authentication (MFA)

• Disable and delete all access keys

• Create an AWS IAM user with admin rights, and avoid using the AWS Root account

• Enable auditing using AWS CloudTrail for the AWS Root account activities

For more information, see:

https://docs.aws.amazon.com/accounts/latest/reference/best-practices-root-user.html

Compute

Deploying a new EC2 instance is a fairly common and easy task.

Some of the common misconfiguration's organizations make in the process of deploying and managing EC2 instances are:

• Creating new EBS volumes and leaving them unencrypted

• Creating snapshots of EBS volumes and leaving them publicly accessible

• Allowing Internet inbound access to EC2 instances using SSH/RDP protocols

• Forgetting to patch the operating system and application layers

To protect EC2 instances, it is recommended to take the following actions:

• Deploy all EC2 instances inside private subnets

• Restrict access to EC2 instances using security groups

• Manage EC2 instances using AWS Systems Manager Session Manager

• Encrypt all EBS volumes and their snapshots during creating time

• Keep all snapshots private

• Keep all EC2 instances and AMI's up-to-date with the latest security updates

For more information, see:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html

Storage (Public S3 buckets)

Amazon S3 is the most widely used object storage service.

Perhaps the most common misconfiguration around cloud services is leaving the S3 bucket publicly available from the Internet.

Leaving S3 buckets open, may lead to:

• Unauthorized access to data (data exfiltration)

• Data deletion (for buckets with write access permissions)

• Malware infection (for buckets with write access permissions)

To protect S3 buckets, it is recommended to take the following actions:

• Enable S3 block public access feature at the organizational level

• Avoid using wildcard identities using bucket policies – grant access bucket to specific identities/groups of identities

• Encrypt all S3 buckets using customer-managed keys

• Enable CloudTrail and S3 server access logging

• Use Amazon GuardDuty to detect suspicious activities (such as access from unusual countries, attempt to detect misconfiguration, and more)

• Use S3 object lock and S3 versioning to avoid accidental object deletion

For more information, see:

https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-data-in-amazon-s3/

Network misconfiguration

Resources in the cloud are prune to access from the Internet.

Failing to restrict access to cloud resources may lead to:

• Access by unauthorized identities

• Resource take-over (such as EC2 or database)

• Attackers' ability to exploit vulnerabilities due to opened ports (services)

To protect your network, it is recommended to take the following actions:

• Restrict access at the subnet layer using network ACLs

• Restrict access to resources using security groups

• Avoid using 0.0.0.0/0 when creating security groups

• Unless you create a security group for a public load-balancer in front of a public web server, limit both source and destination to specific IP/CIDR

• Block inbound Internet access to EC2 instances on protocols such as SSH, RDP, CIFS

• Block inbound Internet access to RDS servers using DB security groups

• Use AWS Security Hub to detect opened ports

For more information, see:

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html

Detecting misconfiguration

Use the following services to detect misconfiguration:

• Amazon GuardDuty – detect security incidents such as port scanning, unauthorized access, or open access to the S3 bucket, which indicates a misconfiguration

• Amazon Inspector – detect EC2 network exposure, missing patches, etc.

• AWS Config – detect misconfiguration such as unencrypted volumes, Root account with access keys enabled, logging for various services not enabled, etc.

Guardrails

The idea behind guardrails is to allow your employees to continue their daily work in the cloud, while certain settings (from volume encryption, enforcing the use of MFA, disallowing public S3 buckets, etc.) are always enforced and users cannot take actions that violate the organizational security standard.

AWS Control Tower comes with built-in guardrails to detect and enforce common security settings, using service control policies on the entire AWS organization.

For more information, see:

https://docs.aws.amazon.com/prescriptive-guidance/latest/designing-control-tower-landing-zone/strongly-recommended-elective-guardrails.html

Summary

In this post, we have reviewed common misconfigurations while managing AWS environments.

Most of the misconfigurations or sometimes deviations from security standards or best practices can be detected and mitigated, allowing you to keep your AWS environment secure.