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.
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 tools like AWS CloudFormation and Terraform 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.
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.
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
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.
Identify, prioritize and remediate the most important cloud security risks.
Correlate findings across your existing tools: CSPM + Infrastructure + App Vulnerabilities
Reduce alert fatigue by up to 50% and lower your overall risk profile by up to 25%
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.
Chapter 4: AWS Firewall vs. Security Group
AWS firewall and security groups are not mutually exclusive. They can be used together to provide flexibility in managing access controls for instances, subnets, and virtual private clouds (VPCs). Explore key differences and use cases for each service.
Chapter 5: AWS GuardDuty
AWS GuardDuty plays an active role in near real-time monitoring of your account security. Deep dive into GuardDuty data sources, the protection provided by it , the findings types, and remediation actions.
Chapter 6: Key Rotation with AWS Key Management Service
Just like regularly changing passwords, regular key rotation is an essential security best practice for any organization. Explore AWS KMS key rotation in detail, including the problems it solves, methods, costs, and best practices.
Chapter 7: AWS Secrets Manager
Amazon EKS pods use AWS Secrets Manager as a secrets management module. Explore how to successfully integrate with your Amazon EKS as well as some advantages and limitations of using a secrets management solution.
Chapter 8: AWS Security Automation
AWS offers an impressive variety of services that boost your cloud security. Learning to use these tools with automation allows you to get the most out of AWS’s security offerings.
Chapter 9: AWS Container Security
AWS provides a variety of services and tools for securing containers. This article provides an overview of tools that AWS offers for keeping your containerized workloads safe.
Chapter 10: KMS vs SSE
AWS KMS is an encryption management service that lets you secure data using tactics like client-side encryption as well as server-side encryption (SSE). This article explores when each is appropriate and what they mean in the context of KMS.
Chapter 11:AWS IAM Best Practices
AWS IAM is a powerful tool for securing your cloud infrastructure. However, if you want to use this service optimally, you need to learn some core best practices that will help you keep your infrastructure safe.