6 Tips for Successfully Securing Your AWS Environment

Top six actions and practices you can take to protect your AWS environment today.

Even if you have many years of AWS experience under your belt, securing an AWS environment can be complicated. In this article, we’ve compiled six key use cases that many security researchers, IT managers and DevSecOps deal with on a daily basis — from third-party risk to policy management to excessive permissions. For each, we offer a different way to crack the nut, so you can keep your environment secure and your leadership team happy.

Tip 1: Manage third party risk

Third parties make your environment vulnerable since they do not abide by the same security controls as you, and are harder to monitor and track. The widely covered SolarWinds attack is one of the most known (and destructive) third-party attacks in recent history — but by no means the only one. U.S. President Biden’s CyberSecurity Executive Order dedicated an entire section to hardening the supply chain and reducing the risk of vendor attacks.

Since there is no way around working with third-party vendors, following the steps below will help minimize third-party risk in your AWS environment while still enabling your organization to continue operations.

Build in least privilege

Configure policies with caution and while ensuring you understand the extent of permissions granted. Work according to the principle of least privilege by granting your vendors only the permissions that are absolutely necessary for them to perform their job — and do not blindly grant permissions that vendors recommend you give them. Otherwise, your vendor may have access to sensitive information or the ability to perform a broad set of risky actions.

Use permission boundaries

A permission boundary is a set of permissions defined for a principal — like an identity and access management (IAM) user or role — that sets a boundary on the actions that principal can perform. Add permissions boundaries to third-party roles to limit the actions they are able to perform beyond what the policy permissions dictate.

Require external IDs for third-party roles

Setting an AWS external ID string for a third-party role enables dealing with attacks that leverage reused, non-secret values like account IDs (the AWS “confused deputy” problem). Using an external ID with third-party roles ensures values will not be reused, preventing attackers from posing as them and therefore protecting your environments. According to AWS security recommendations, it is important to properly configure the external ID.

Track third-party activity

Monitor all vendors and parties that have access to your AWS environment. Be sure to close permissions for inactive parties and ensure all active parties have access to only the resources they need (see above - the principle of least privilege). Finally, track and audit the actions your vendors are taking to identify any anomalous and unwanted behaviors.

Rotate keys every 3 months

Regularly rotate access keys and secrets for IAM users to add an extra layer of security, and to help prevent and limit reconnaissance.

Read more about third-party security here.

Tip 2 - Don’t take IAM role management for granted

As you know, configuring IAM policies for AWS services is very difficult. The configuration process is complex and — since it's often not possible to know at the time which permissions are required for which user and service — often impossible to complete.

On top of this, there are not many solutions that enable analyzing the permissions granted, comparing them to the ones that have actually been used and then right-sizing roles accordingly to achieve least privilege.

Instead of letting cloud administrators and DevSecOps take the time to properly manage, build and configure IAM roles, you are often expected to hit the ground running. As a result, you might resort to quick fixes for role and permissions management.

Educate management and other security generalists about the need to give administrators time and resources to manage IAM roles in the cloud. Otherwise, they will be vulnerable to security risks like data breaches.

Tip 3 - Escape the AWS managed policies trap

As mentioned in tip 2, when configuring IAM policies, it is usually not known which permissions are required for which user and service. This is where AWS managed policies come in handy. AWS managed policies are IAM policies that are managed, controlled and maintained by AWS. They provide a sort of template policy, administered by AWS, based on common use cases.

This solution saves administrators and DevSecOps the time and effort of creating, managing and maintaining permission policies; however, using only AWS managed policies is, in the long run, dangerous. These policies usually provide permissions that are too excessive and could put your cloud environment at risk. In addition, it takes the control out of your hands and gives it to AWS.

As soon as you can, you should build customized permissions based on the principle of least privilege (see tip 4 and your specific needs).

Until you do, automating policy management and gaining visibility and context into which users and services have permissions, significantly reduces the risks of managed policies (including AWS managed policies). An automated analysis shows toxic permissions and anomalous behaviors while prioritizing and mitigating risky permissions. Read more about the AWS Managed Policies trap here.

Tip 4 - Aspire to achieve a least privilege policy

Implementing the principle of least privilege is imperative to minimizing cloud security risk. However, actually achieving least privilege in AWS is challenging because configuration is itself complex, and environments are highly dynamic. Here are some AWS tools that can help:

• AWS IAM policies - A mechanism that lets users attach policies to identities while defining which resource the identity can access and the actions the identity can perform on the resource
• AWS permission boundary - A mechanism for limiting role actions in a policy (see tip 1 for more information)
• Service control policies - A permission boundary at the account level
• Policy simulator - A tool for simulating the effectiveness of policies applied in the context of an AWS identity, service and resource
• Access advisor - A tool for viewing the “last accessed” information for each AWS service on each identity
• Access analyzer - A tool for analyzing access to resources in your account; enables detecting access granted to external identities through resource-based policies.

An automated analysis solution complements these AWS tools by providing visibility into policy combinations to reduce the risk of excessive IAM permissions in AWS.

Read more about least privilege here.

Tip 5 - Govern cloud identities by unifying misconfiguration and entitlement management

There are often two main reasons enterprises make the decision to govern their cloud identities: to get compliant and to mitigate security risks. Today, many organizations see these tasks as separate: they need to take adequate steps to meet compliance regulations and they need to find solutions that will secure their cloud.

However, separating compliance and security often means choosing two separate vendors and neglecting to meet real cloud security requirements. By viewing compliance and security as two sides of the same coin, a single solution can offer compliance alongside identity management, which provides identification, visibility, reporting and remediation of risky entitlements, plus mitigation actions and the ability to create customized policies. This is the best solution for robust cloud security.

Read more about cloud compliance here.

Tip 6 - Manage excessive permissions

Excessive permissions put organizations at risk, since they increase the chances of a malicious or accidental data breach. By limiting permissions according to the principle of least privilege, you can identify and mitigate risks.

What kinds of risks should be reviewed?

• Inactive permissions, i.e. access to resources has not been used for a long period of time
• Widespread access to sensitive information
• Third party permissions (see tip 1)
• Service identities access
• And more

Governing these and other permissions helps identify risks, prioritize them according to their severity and automatically remediate them.

Conclusion

Being able to manage roles and permissions securely is the foundation of AWS cloud protection. The list above covers tools, practices and recommendations for ensuring your IAM management doesn’t put you at risk. By implementing some or all of these six tips, your organization can significantly improve its security stance by mitigating the urgent risks and protecting your organization.