How To Secure Your AWS Environment: Six Best Practices

Originally published by Tenable Cloud Security.

Even for those experienced with AWS, securing your AWS environment can be a difficult process. In this article, we outline six best practices that can help those involved with protecting your AWS environment keep it secure.

Recommendation #1 - Manage Third-Party Risk

Because they don’t follow your organization’s security controls and are harder to track and monitor, third parties make your environment vulnerable. The notorious SolarWinds incident is one of the best known and most devastating third-party attacks in recent history – and by no means the only one. The White House’s “Executive Order 14028: Improving the Nation's Cybersecurity” devoted an entire section to protecting the supply chain and lowering the risk of vendor attacks.

Since working with third-party vendors is essential to today’s business reality, taking the different actions below will help minimize third-party risk in your AWS environment while keeping business needs on track.

Build in Least Privilege

Be careful when configuring policies while ensuring you understand the extent of permissions granted. Work according to the principle of least privilege. That means granting your vendors only the permissions that are absolutely necessary for them to perform their job. Do not blindly grant permissions that vendors recommend you give them. Doing so may, intentionally or not, grant your vendor 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 IAM user or role, that establishes a boundary on the actions that principal can perform. Add permissions boundaries to third-party roles. In this way, you 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 helps avoid attacks that seek to leverage re-used, non-secret values like account IDs. Using an external ID with third-party roles ensures that such values will not be reused, preventing attackers from posing as the role and therefore protecting your environment.

Track Third-Party Activity

Monitor all vendors and parties that have access to your AWS environment. Make sure you close permissions for inactive parties. You should also ensure that all active parties have access to only the resources they need. Finally, track and audit the actions your vendors are taking to identify any anomalous and unwanted behaviors.

Rotate Access Keys Every 3 Months

Regularly rotate your AWS access keys and secrets for IAM users – doing so adds an extra layer of security, helping prevent and limit reconnaissance.

Tip 2 - Don’t Take IAM Role Management for Granted

Configuring IAM policies for AWS services is complicated. The configuration process is extremely complex and often impossible to complete, because you can’t always know at the time which permissions are required for which user and service.

On top of this, few tools enable you to analyze permissions such that you can compare permissions granted versus those actually used, and rightsize roles accordingly to achieve least privilege.

In the cloud, instead of letting cloud administrators and DevSecOps teams take the time to properly manage, build and configure IAM roles, the expectation is often to hit the ground running. As a result, you might open the aperture on access that is greater than needed and resort to quick fixes for managing roles and permissions.

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

Tip 3 - Escape the “AWS Managed Policies Trap”

When configuring IAM policies, it is often impossible to know 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.

The managed policies provide a sort of template policy, administered by AWS, based on common use cases. This AWS capability saves administrators and DevSecOps teams the time and effort of creating, managing and maintaining permission policies – a complex and difficult task.

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, these policies take the control out of your hands and give it to AWS.

We recommend that, as soon as possible, you build customized permissions based on the principle of least privilege.

In the meanwhile, you can significantly reduce the risks of managed policies – including AWS managed policies – by automating policy management, and gaining visibility and context into which users and services have permissions. An automated analysis shows toxic permissions and anomalous behaviors while prioritizing and mitigating risky permissions.

Tip 4 - Aspire to Achieve Least Privilege Access

To minimize cloud security risk, you must implement the principle of least privilege. However, actually achieving least privilege in AWS is challenging. Why? 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.
• 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; it 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.

Tip 5 - Govern Cloud Identities by Unifying Misconfigurations and Entitlements Management

Enterprises often decide to govern their cloud identities for two main reasons: to be 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 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 risk management. This provides identification, visibility, reporting and remediation of risky entitlements, plus mitigation actions and the ability to create customized policies. This combined approach is optimal for robust cloud security.

Tip 6 - Manage Excessive Permissions

Excessive permissions put organizations at risk by increasing 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, for example, access to resources that has not been used for a long period of time
• Widespread access to sensitive information
• Third-party permissions
• Service identities access

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

In Closing

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, you will significantly improve your security stance by mitigating the urgent risks and protecting your organization.

For more information read the cloud security eBook “Deconstructing the shared responsibility model: How to avoid coverage gaps and confusion to better protect your business” or check out the white paper “Why Managing Cloud Entitlements is Nearly Impossible – and How to Do It”.