AWS Security Risks: Best Practices & Instructions

Amazon Web Services (AWS) is the largest and most popular hyper-scale public cloud provider. AWS provides over 200 services from 38 worldwide data centers, offering infrastructure, platform, and software as service solutions. 

The breadth and flexibility of AWS services add a high degree of complexity to the AWS cloud. At the same time, AWS aims to make its platform accessible to everyone, from startups and small businesses to the largest enterprises. 

This combination of complexity and accessibility can, in turn, lead to security risks in AWS deployments. If left unmitigated, threat actors can take advantage of these vulnerabilities, potentially resulting in data compromise, service disruption, and reputation damage.

This article will review seven of the most common AWS security risks and how organizations can mitigate them. 

AWS Security Risk #1: Misconfigurations

From accidentally allowing all Internet traffic to an EC2 instance to making an S3 bucket with confidential information publicly accessible, misconfigurations are the most common reason for AWS security breaches.

Items in this category of AWS security risks occur because of accidental misconfigurations or incorrect settings due to a lack of knowledge. For example, AWS novices often configure overly permissive IAM permissions for users, roles, and policies applied directly to resources such as S3 buckets.

Warnings in the AWS console of some potential misconfigurations, such as publicly accessible S3 buckets.

Warnings in the AWS console of some potential misconfigurations, such as publicly accessible S3 buckets.

The mitigations for this AWS security risk are tools and processes to detect, prevent, and remediate misconfigurations. Specifically, here are three steps organizations can take to reduce their risk:

  • Use Infrastructure as Code for consistent, secure AWS configurations 
  • Leverage compliance tools that continually monitor and alert for insecure configurations. 
  • Use the AWS Well-Architected Framework to evaluate your application and infrastructure for security, performance, resilience, and efficiency.

AWS Security Risk #2: Credential leaks

Credential leaks have caused several large-scale AWS breaches. Usernames and passwords are sometimes exposed, but programmatic AWS access key IDs and secret access keys are often what threat actors compromise. 

These sensitive keys are often long strings of numbers and letters, and it may not be immediately apparent to some people the access they provide. Users may unwittingly commit them into a public code repository or place them in a public document or a shared storage area such as an S3 bucket. From there, they can be retrieved by hackers to access or modify AWS resources in the compromised AWS account.

 

Credentials stored in publicly accessible data repositories can be stolen and used.

Credentials stored in publicly accessible data repositories can be stolen and used.

Fortunately, there are several effective mitigations for this AWS security risk. 

  • Enforce strong passwords and password management practices. Organizations should implement secure password management practices, such as requiring a minimum length password, disallowing password sharing, and using a secure password management solution. 
  • Enable multi-factor authentication (MFA)– MFA doesn’t directly prevent credential leakage. However, MFA does help prevent leaked credentials from being used. 
  • Follow the principle of least privilege– Minimize the use of permissive AWS access keys where possible (e.g., through the use of assuming IAM roles)
  • Rotate keys regularly– Regular rotation of sensitive keys helps limit the amount of time an attacker could use them to breach a system. 
  • Use proactive monitoring tools– Protective monitoring solutions help ensure keys are not committed into code repositories or placed in public shared storage. For example, Amazon Macie can monitor S3 buckets for this and other personally identifiable identification data.

AWS Security Risk #3: Data encryption

It is widely known and accepted that data must be encrypted while in transit across public networks such as the Internet. VPNs and protocols such as HTTPS are now the norm for these purposes. However, encryption is just as crucial within private networks.  

There are many examples of hackers stealing millions of unencrypted records containing customer data. If the businesses encrypted the data, it would have been much harder for anyone to use it.

To help mitigate this risk, AWS provides the ability to encrypt data at rest within their services and in transit across their network. AWS Key Management Service (KMS) offers seamless, built-in encryption for most AWS services. It allows customers to create their key data and import it into the service for added security. Access to these keys can be assigned to users or roles, ensuring decryption is restricted only to authorized users and applications.

Encryption options available for data stored in S3 buckets.

Encryption options available for data stored in S3 buckets.

AWS CloudHSM provides a fully managed FIPS 140-2 Level 3 validated service to automate secure encryption keys and operations for those with even higher security requirements.

AWS Security Risk #4: Insufficient logging

Effective logging is an essential aspect of observability and overall security posture. Logs enable both threat detection and post-attack analysis. Unfortunately, many organizations have insufficient AWS logging practices in place. 

AWS provides a default set of logging activities with their CloudTrail service, but it is limited to management events and retained for only 90 days. These logs are helpful in some circumstances, but it may be necessary to trace some activity further back than this. Furthermore, the default logs exclude events, such as data access information and logs that help trace unusual activity. 

Other logging systems to investigate when using AWS services are S3 access logging, VPC flow logs, and integration of services into Amazon CloudWatch. Without configuring additional logging, it may be impossible to trace a security incident back to its origin and take the necessary corrective action to prevent it from re-occurring. It is essential, therefore, to configure adequate logging in the AWS account and then archive these logs and retain them into S3 to allow future analysis if required.

Additionally, when an application is developed or installed (e.g., within an EC2 instance), it should contain its own logging parameters and integrate these logs into a central repository (e.g., within Amazon CloudWatch). Finally, organizations should set proactive alerts and take action if suspicious activity is detected.

AWS Security Risk #5: Inadequate monitoring and reporting

Logging is crucial, but it is only a first step. Organizations need to analyze log data to detect threats and draw insights from their logs. 

Many companies perform operational monitoring so they can try to rectify issues with their operations before they impact customers. Unfortunately, robust security monitoring isn’t as widespread. Consequently, any malicious activity may go undetected, and breaches are undetected for months or years.

To help analyze log data from a security perspective, AWS offers services such as Security Hub, GuardDuty, Inspector, and Macie. Together these tools provide threat reporting, analysis, and issue remediation for applications and data.

Amazon Macie findings after a scan of S3 buckets

Amazon Macie findings after a scan of S3 buckets

AWS Security Risk #6: No strategy or recovery plans

Organizations often neglect to create a cloud-specific security strategy. This is a mistake since cloud security needs to address different challenges than on-premise security. It is arguably easier to achieve greater IT security within the cloud than on-premises, but it requires knowledge and effort. 

Public cloud services are often accessible from the internet by default. Safeguards to protect data and applications stored within AWS are essential. AWS provides tools to enhance traditional security, such as built-in operational and protective monitoring solutions and the potential to develop automation to remediate issues.

A plan of action is also crucial for handling different situations. Key questions to consider include: what is the process to follow if a system is compromised? Or if a user leaks their access credentials?

Asking these questions after an incident means asking them too late. Document and test your processes to ensure fast remediation as soon as possible – this will limit or prevent data loss and reputational damage. AWS provides a Security Incident Response Guide to assist you with creating and developing a robust process.

AWS Security Risk #7: Shadow IT

Public cloud platforms are dynamic, allowing quick and easy deployment of resources. It is simple, therefore, for employees or even departments to build or install applications, store data and communicate internally using AWS cloud services, potentially with no security overview or controls.

The nature of the public cloud means advanced IT services are accessible to all. Without the necessary strategy and oversight, security controls are easy to bypass. Alongside clear company policy, cloud management and governance tools are required to give visibility and control over deployed resources. AWS provides tools such as Control Tower, Organizations, and Service Catalog to assist with this governance process. 

By definition, cloud-native tools only apply to a single cloud provider, leaving security professionals to their devices for securing multi-cloud and hybrid cloud environments. The features provided by the native tools are also basic, especially since they offer relatively basic functionality. This shortcoming gave rise to Cloud Security Posture Management (CSPM) open source tools such as Paladin Cloud’s Open Source Community Edition. This free tool comes pre-configured with policies for monitoring common vulnerabilities across multiple cloud providers and data center infrastructure. It also offers visualization via a modern user interface and takes predefined remedial actions once it detects a security exposure.

Open Source, Security-as-Code platform
for developers and security teams

Visit Github

Reduce risks in your cloud environments, improve cloud security posture

Reduce risks in your cloud environments, improve cloud security posture

Identify and eliminate cloud misconfigurations with pre-built policies and connectors

Identify and eliminate cloud misconfigurations with pre-built policies and connectors

Prioritize violations & automate remediation with auto-fixes

Prioritize violations & automate remediation with auto-fixes

Next steps with AWS security 

AWS uses a Shared Responsibility Model for security, meaning customers are responsible for protecting any applications and data they deploy in the cloud. This series of articles will highlight some primary security risks when using the AWS platform.

Chapter 1: AWS VPC: Security Best Practices

Learn about the ways to ensure the security of AWS VPC networks. Start with a crash course on the AWS VPC concept and go through its security best practices.

Chapter 2: AWS Security Group Naming Convention: Best Practices

Learn the conventions for naming AWS security groups and the methodologies to automate and audit the naming convention

Chapter 3: Cloud Security Configuration Management

Learn the best practices for managing configuration security for cloud services such as using infrastructure as code, version control, and performing regular audits.