There are a lot of benefits that come with having Amazon Web Services (AWS) as your cloud platform, alone or as part of a hybrid or multi-cloud environment. The agility and flexibility of AWS’s platform as a service (PaaS) and infrastructure as a service (IaaS) make it possible for your organization’s network to be responsive, innovative, and ready for change. But there are security considerations. Outlined below are these considerations, along with security best practices to help keep your AWS environment properly configured and secure.
Cloud resources are ephemeral, which makes it difficult to keep track of assets. According to our research, the average lifespan of a cloud resource is two hours and seven minutes. And many companies have environments that involve multiple cloud accounts and regions. This leads to decentralized visibility, and since you can’t secure what you can’t see, this makes it difficult to detect risks.
Best practice: Use a cloud security solution that provides visibility into the volume and types of resources (virtual machines, load balancers, security groups, users, etc.) across multiple cloud accounts and regions in a single pane of glass. Having visibility and an understanding of your environment enables you to implement more granular policies and reduce risk.
- Exposed root accounts
Your root accounts can do the most harm when unauthorized parties acquire access to them. Administrators often forget to disable root API access.
Best practice: Root accounts must be protected by multi-factor authentication and used sparingly. Not even your top admins should have access to your AWS root account the vast majority of the time, and never share them across users and applications.
- IAM access keys
IAM access keys are often not rotated. This weakens IAM’s ability to secure your user accounts and groups, giving cyber attackers a longer time window to acquire them.
Best practice: Rotate or change your access keys at least once every 90 days. If you have given the users the necessary permissions, then they can rotate their own access keys. Plus, it ensures that old keys aren’t being used to access critical services.
- Authentication practices
According to Verizon’s annual Data Breach Investigations Report, lost or stolen credentials are a leading cause of cloud security incidents. It is not uncommon to find access credentials to public cloud environments exposed on the internet. Organizations need a way to detect account compromises.
Best practice: Strong password policies and multi-factor authentication (MFA) should be enforced in AWS environments. Amazon recommends enabling MFA for all accounts that have console passwords. First, determine which accounts already have MFA. Then, go into IAM and select “MFA device” for each user. Smartphones and other devices can be used for an extra factor of authentication.
- Access privileges
AWS IAM can be deployed to manage all of your user accounts and groups, with policies and detailed permission options. Unfortunately, admins often assign overly permissive access to AWS resources. Not only does that enable users to make changes and have access they shouldn’t be allowed to have, but if a cyber attacker acquires their account, more harm can be done.
Best practice: Your configuration of IAM, like any user permission system, should comply with the principle of “least privilege.” That means any user or group should only have the permissions required to perform their job, and no more.
- Broad IP ranges for security groups and unrestricted outbound traffic
Security groups are like a firewall that controls traffic to the AWS environment. Unfortunately, admins often assign security groups IP ranges that are broader than necessary. Research from Unit 42’s cloud research team found that 85% of resources associated with security groups don’t restrict outbound traffic at all.
Adding to the concern, increasing numbers of organizations were not following network security best practices and had misconfigurations or risky configurations. Industry best practices call for restricting outbound access to prevent accidental data loss or data exfiltration in the event of a breach.
Best practice: Limit the IP ranges you assign to each security group in such a way that everything networks properly, but you aren’t leaving a lot more open than you’ll need.
- Audit history
Organizations need oversight into user activities to reveal account compromises, insider threats, and other risks. The virtualization that’s the backbone of cloud networks and the ability to use the infrastructure of a very large and experienced third-party vendor afford agility as privileged users can make changes to the environment as needed. The downside is the potential for insufficient security oversight. To avoid this risk, user activities must be tracked to identify account compromises and insider threats as well as assure that a malicious outsider hasn’t hijacked those accounts. Fortunately, businesses can effectively monitor users when the right technologies are deployed.
Best Practice: AWS CloudTrail is a web service that provides event history of your AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command line tools, and other AWS services. It must be used. Enabling CloudTrail simplifies security analysis, resource change tracking, and troubleshooting.
- Unpatched hosts
It is your responsibility to ensure the latest security patches have been applied to hosts within your AWS environment. Unit 42 provides insight into a related problem. Traditional network vulnerability scanners are most effective for on-premises networks but miss crucial vulnerabilities when they’re used to test cloud networks.
Best practice: Make sure hosts are frequently patched and apply any necessary hotfixes that are released by your OEM vendors. To do so, you need third-party tools that can map the data from your host vulnerability feeds, such as Amazon Inspector, to gain cloud-specific context.