AWS cloud security best practices

As the leading public cloud provider, AWS is integral in software development. Organizations using AWS must prioritize security during development to avoid potential financial and reputation damages from security incidents and data breaches.

Integrating security from the start helps harden cloud accounts against misconfigurations and vulnerabilities. With AWS’s 300+ services, tracking secure configurations can be overwhelming, hence the need for security tools.

Most companies, however, use a core set of foundational AWS services. Let’s examine these services.

Protecting the core of your AWS infrastructure ​

Among the 300+ AWS services, the following five services are the most critical to understand when implementing a cloud security strategy:

• Elastic Compute Cloud (EC2): Virtual, resizable compute instances in the cloud.
• Relational Database Service (RDS): Web service that makes it easier to set up, operate, and scale relational databases, such as MySQL, PostgreSQL, or MariaDB.
• Simple Storage Service (S3): Object storage used for data lakes, backups, and static content.
• Lambda: Compute service that permits you to run code without provisioning or managing servers.
• Virtual Private Cloud (VPC): Secure, isolated virtual network for customers to launch AWS resources in.

Each one of these services represent a potential entry point for malicious actors. The classic example is the unsecured S3 bucket that exposes sensitive data. Other examples include vulnerabilities in EC2 instances that allow unauthorized access to the system, or snapshots from instances that accidentally were made public, making a previous state of your data publicly available.

Shared responsibility model ​

The shared responsibility model is a foundational principle of AWS security. In this model, AWS is responsible for the security of the cloud, and customers are responsible for security in the cloud.

The model delineates that AWS secures the cloud infrastructure such as access to physical data centers and their managed services, while customers are expected to secure their resources and data and manage access controls, also defined as “security posture”.

The shared responsibility model only works when an organization knows its assigned tasks well. By following this model, businesses can help keep their cloud environment safe.

Security building blocks ​

AWS provides tools and services to help customers secure their cloud environment, but they require a strategy and processes to implement them. Here are the five generic building blocks to achieve good cloud security posture.

• Access: AWS’s Identity Access Management (IAM) lets organizations configure detailed access controls. Handling these roles, ensuring the principle of least privilege, and auditing them often can be tricky.
• Inventory: Over time, infrastructure and the number of resources in the inventory always grows, and with automated deployments also frequently changes. It becomes challenging to maintain a full picture of all resources and their security posture. A good cloud asset inventory is the foundation of good cloud security.
• Configuration: Every resource in your inventory ships with default configurations. While well-intended, developers change these settings, accidentally leading to misconfigurations that can be an entry point for breaches. That implies continuous monitoring of all configurations in your inventory.
• Exposure: Incorrect settings can unintentionally make resources public. Finding all these exposed resources can be tricky. It’s vital to always have tools and strategies to regularly check, spot, and fix these exposures.
• Encryption: AWS offers encryption solutions for data at rest and in transit, but you need to know how to use those services. Another challenge is knowing the location of sensitive data to encrypt and protect it.

Compliance benchmarks ​

Compliance frameworks and security benchmarks provide standardized configuration guidelines that improve your security posture. There is no shortage of frameworks, and to make sense of them, it’s helpful to think of them in three categories..

• Provider benchmarks: These are cloud provider-specific benchmarks that define best practices for configuring your cloud environment. For AWS, examples are the CIS Benchmark or the Well-Architected Benchmarks.
• Industry benchmarks: Different industries and regions have different regulations and compliance requirements that also apply to cloud infrastructure. Examples are HIPAA (for health-related information) or GDPR in Europe for data protection.
• Company benchmarks: Every company usually has company-specific rules and policies that need to be monitored and enforced. Example are the lifetime of resources in development environments, or mandatory resource tags.

There is a checkbox aspect to meeting these benchmarks. The benchmarks comprise checks, and a resource either passes or fails a test. But there’s more to compliance than passing checks. By being compliant, businesses avoid possible legal issues and make sure they’re using tested security methods.

Best practices ​

1. Educate your team about cloud security.

   Good security starts with educating your developers about what defines good security, and providing them with continuous learning opportunities. The security landscape changes all the time - AWS constantly launches new services, cyber threats evolve and security bechmarks are frequently updated. AWS offers educational resources such as AWS Security Workshops and AWS Skill Builder that equip your engineers with the knowledge to stay secure and prepare for the AWS Security Specialty.

2. Embed security into your architecture.

   It’s not uncommon for an AWS setup to start small and “organically” grow over time. Companies often prioritize development velocity over architecture. Eventually that leads to an architectural mess. Bad architecture results in bad security. Bad security is often not as obvious as other more immediate symptoms of bad architecture, such as performance and reliability issues, and of course high cloud spend.

   This is where the AWS Well-Architected Framework comes in. It’s a set of best practices to architect your AWS stack and services and consists of six pillars, Security being one of them. The security pillar focuses on protecting information and systems. AWS Well-Architected Labs offers online workshops for all pillars, including a Security Workshop.

3. Separate concerns in your organization.

   As businesses grow, things can get complex. AWS Organizations makes managing resources and access easier. With it, businesses can control policies across multiple AWS accounts from one place. This makes admin tasks simpler and boosts security by ensuring only the right people can access specific resources, even as the business expands.

   The great thing about AWS Organizations is that it helps split up duties. By creating separate areas for business teams and resources, it allows for detailed access controls. Keeping teams and roles separate lowers the chance of unwanted access. A good organizational structure is key to a safe and effective AWS setup. The AWS Organizations page consolidates links to documentation, blog posts and videos.

4. Enforce the principle of least privilege.

   The principle of least privilege is a foundational concept in security. The flip side is overly permissive access, often again granted for development velocity. Least privilege means users only get the access they need.

   Least privilege balances between security and usefulness. Users shouldn’t have too much access, but they should have enough to do their tasks well. Regularly checking and updating IAM policies helps keep this balance. Granting least privilege access is also part of the AWS Well-Architected Framework Security Pillar (SEC03-BP02).

   AWS Identity and Access Management Access Analyzer uses provable security to guide towards least privilege by enabling setting, verifying, and refining permissions. It analyzes external access and ensures policies match corporate security standards.

5. Track your inventory and its configurations.

   When managing your AWS security, it’s important to have an understanding of all the resources running in your AWS accounts. You can’t secure what you don’t know exists. Most cloud providers offer a native cloud asset inventory that provides that visibility. For AWS, that asset inventory is AWS Config, which discovers all your running AWS resources, their configuration history and their resource relationships. An asset inventory is the foundational part to identify resource misconfigurations.

6. Introduce a tagging system.

   Tagging means classifying and grouping AWS resources in your inventory based on cost center, security needs, user, workload, etc. Tags can be used to to identify and filter resources that require additional monitoring.

   For workloads that contain sensitive data and are subject to regulations such as HIPAA or GDPR, the security of the deployment matters. Security tags help identify these resources that require additional monitoring.

   Security tags can also be used to allow or deny access to specific resources by using conditions within the AWS Identity and Access Management (IAM) policies. These allow users to employ tag-based conditions to regulate permissions based on specific tags and values.

7. Log resource interactions.

   An asset inventory provides a list of all resources, but does not monitor the ongoing interactions between those resources. AWS CloudTrail is a logging service that helps you enable operational and risk auditing, governance, and compliance of your AWS account. Actions taken by a user, role, or an AWS service are recorded as events in CloudTrail. Events include actions taken in the AWS Management Console, AWS Command Line Interface, and AWS SDKs and APIs.

8. Protect your cloud accounts with threat detection.

   AWS GuardDuty is a threat detection service that continuously monitors your AWS workloads for compromised accounts, anomalous behavior, and malware. GuardDuty specifically supports the most popular AWS services referenced above, e.g. S3, RDS and Lambda.

9. Classify and protect your data.

   The two steps for data security are data classification and data encryption.

   Data classification identifies the types of data processed and stored in AWS, usually determined by a compliance framework. For example, the The U.S. government uses a three-tier classification scheme (confidential, secret, top secret) for national security information. A data catalogue like AWS Glue connects to over 70 data sources in AWS and offers pre-built and custom classifiers. Amazon Macie discovers sensitive data, provides visibility into data security risks, and enables automated protection against those risks.

   AWS Key Management Service (KMS) is a managed service that makes it easy for you to create and control the cryptographic keys that are used to protect your data. KMS encrypts data across your AWS workloads and digitally signs data.

10. Automate security actions.

    Automation reduces repetitive tasks and alert fatigue, which can cause errors or oversight of serious alerts. By automating, analysts can focus on other important areas. Two aspects of automation are updating of findings and remediation.

    AWS Security Hub is a cloud security posture management (CSPM) service that performs security best practice checks and aggregates findings from other AWS security services, including Amazon GuardDuty, Amazon Inspector, Amazon Macie, and AWS Config.

    Security Hub’s rules allow automatic updates of findings based on criteria, including suppressing findings, adjusting severities, changing workflow status, and note-adding. For instance, a rule can set a finding’s severity to “Critical” for a critical business account or suppress findings for a control where the risk is accepted.

    We already covered how AWS Config records changes. Config also allows automated evaluations against desired configurations. AWS Config can detect deviations and, with AWS Systems Manager, can automatically correct them. This makes AWS Config not just a detection tool, but also an automated response mechanism.

11. Limit and manage external exposure.

    Exposure of services to the public Internet can be beneficial (you have to do business obviously), but also increases the attack surface. With tools such as AWS Security Groups and network access control lists (ACLs), organizations can manage which resources can be accessed from the internet.

Upleveling your security with Fix

Fix helps cloud security engineers identify and remediate misconfigurations in their cloud. With coverage of over 120 AWS services, Fix provides complete visibility into your cloud inventory, and provides remediation recommendations and links to the AWS docs for proper configurations.

Here’s how Fix and AWS work together:

• Visibility and context: Fix collects metadata and configuration data from your AWS resources, and runs standard and custom compliance checks to spot misconfigurations.
• Remediation suggestions: Once Fix finds a risk, it gives advice on how to address it. The advice could be specific, like “change this user’s password” or “turn on two-factor authentication for this resource.”
• Automated remediation: In combination with our open-source product Fix Inventory, Fix can automatically correct some issues, like updating tags or outright delete non-compliant resources. This helps organizations save time and effort in keeping their AWS infrastructure secure.

By integrating with AWS services, Fix can identify and remediate critical risks that are often missed by traditional security tools.

Begin securing your cloud infrastructure today with Fix. Start your 14-day free trial and discover how easy it is to manage your cloud’s security posture. Continue for free on a single cloud account and take the first step towards cloud compliance and security.