Stand Your Cloud #3: AWS Provisioning and Access Requests

This blog post is the closing chapter in a series about AWS security best practices. Read the first post and second post in this series for context. 

In cloud environments, policies, processes, and procedures take on a special significance because these environments are more susceptible to high-impact misconfigurations than traditional infrastructures. Where you would need to misconfigure multiple firewalls and maybe reroute some cables to accidentally expose a physical server to the internet, all it takes for an EC2 instance is the application of an incorrect security group. This is why our past topics were so important. IAM, security group management, monitoring; those are the controls that support a secure cloud environment. But how do you prevent the deterioration of AWS security through unmanaged instances, permission creep, and ad-hoc security groups?

The answer relates directly to that age-old refrain of “policies, processes, and procedures.” The answer can especially be found in the processes that surround provisioning and access requests.   

Provisioning

One of the best processes to start with is to standardize provisioning for new EC2 instances. Make sure that your Amazon Machine Images (AMIs) conform to existing hardening standards. For instance, disable unneeded services, enable firewalls, and enforce strong password policies. Use hardening standards such as those provided by the Center for Internet Security (CIS) as a first step. AWS also provides a service – Amazon Inspector – that can verify compliance with CIS standards and report on possible insecure configurations.

Next, make your life easier by introducing organization into your cloud environment. Amazon auto-generates names for new EC2 instances, and the names aren’t exactly useful (i-03bbe75265d11832b … what does that even mean?!). From here, name or tag your instances in a manner that tells you the instance’s role (e.g., web-appname-prod-1). Naming conventions should be consistent with any existing conventions that your organization already has defined for on-premise servers. Don’t forget to also include each instance in your asset inventory.

Remember: visibility makes everyone happy.

Document Your Procedures

Once provisioning steps and naming conventions have been standardized, document them. Make these procedures available to anyone who needs them to do their job. Employees leave, new employees join, and before you know it, nobody is following the ad-hoc provisioning procedures anymore. Documented policies and procedures keep actions standardized and ensure that knowledge is retained over time.

Once this is complete, you can focus on other areas, such as access requests. But don’t rush this step – neglecting it can make your life miserable in a heartbeat.

Access Requests

In Part 1, we provided recommendations for hardening Identity and Access Management (IAM) for AWS. However, we didn’t provide anything beyond the assignment of roles and groups (sorry, guys!)

In some cases, there will be a requirement for an employee to gain elevated privileges or for a new access account to be established. Rather than performing these as the need arises, there should be a documented procedure instructing users on how they can gain the required access. At the least, they should be required to obtain manager approval. Ideally though, loop the security team into the approval process to double-check that the requested access is legitimate.

The most important reason to document procedures for access requests is to enforce the requirement of an audit trail. When shit hits the fan (and it will), you need to know who had what access as well as when it was granted. Elevated privileges are one of the most common ways that servers become compromised.

An example that we saw in a client environment was an IAM role for which the policy allowed the “sts:AssumeRole” action. This action is typically used to allow a third party to assume the IAM role and perform certain tasks in the AWS environment. For obvious reasons, the permissions of any IAM role that allows the “sts:AssumeRole” action need to be tightly restricted. However, we discovered two problems with this particular IAM role. First, the role did not specify the AWS account it allowed to assume it, so all existing AWS accounts could do so. Second, the role allowed a wildcard action on any EC2 resource. Combine these problems and you have a role that allows anyone to do anything with your EC2 instances, including deleting them, moving them, applying different security groups to them, etc. The lesson here is that you must enforce a formal IAM process with approval and verification procedures, or risk potential chaos.

As for the “Everyone” and “Authenticated Users” groups that AWS conveniently provides as options for resource permission, without expounding too much, do not use either of them unless you want your resources to be accessible to the public. Everyone truly means everyone.

Once the access approval process has been documented, the next step is to … (drumroll please) …

Perform Access Reviews

We’ve previously discussed the principle of least privilege. This idea is the foundation for why we perform access reviews. Nobody should have more access than they require, and for no longer than necessary. Regular access reviews can provide a clean-up process to make sure that this principle remains intact. Aim to do them annually, but perform them quarterly if possible. Also, set a requirement that every user’s manager can vouch for all their subordinates’ access levels. As a bonus, erroneous accounts that are no longer in use are disabled or removed, which leaves one less attack vector for hackers.

Apply the principle of least privilege to all aspects of AWS. Security groups should not specify that a service is accessible to 0.0.0.0/0 unless it’s a public website or a VPN gateway. Other services can be restricted to IP addresses, both for internal and external servers. And keep in mind our previous example: All it takes to expose a server is the application of an incorrect security group. To prevent this situation, it’s imperative that there are no overly permissive security groups available to apply.

Prioritize regularly reviewing EC2 instances as well. Due to the scalable “elastic” nature of AWS, some instances that were once required may no longer be needed. If they’re left as is, they’re costing you more money in addition to increasing your attack surface. By regularly reviewing instances and the asset inventory, you can eliminate any orphaned or legacy EC2 instances from being left behind and serving as landmines.

Conclusion

These three recommendations are only the surface of operational policies and procedures to be documented in your organization. But for cloud environments, they are a solid foundation.

The key thing is extending organizational policies and procedures to your cloud environments. Treat assets and services in AWS as if they were on your premises. If you have policies concerning access management, then those same policies must be adhered to when migrating servers and services to the cloud. And if you don’t have those policies, then you have some work in front of you.

Fortunately, there are numerous security frameworks that you can use as a template. If you’re a health care organization, you are probably using HIPAA (hopefully) as a set of guidelines. If your cloud infrastructure processes credit card information, then make sure the environment complies with PCI requirements. If no formal compliance frameworks apply to your organization, consult the Cloud Controls Matrix. This matrix provides an overview of security principles as applied to cloud environments and is a great place to start for locking down your cloud environment.

CloudFormation templates are another option. While CloudFormation takes time to learn and customize, it provides a central point of reference to maintain all deployed services in your environment. Amazon offers CloudFormer to start; third-party tools (such as sceptre) can help you create base templates.

So, there you have it. Our series on AWS has come to its conclusion (finally!) Feel free to reach out to our team with any questions you may have that were not covered in our content.

Until then, happy migrating and remember; in the end, there is really no cloud – only someone else’s computer.    

SOURCE

Our recommendations should not be considered comprehensive; rather, they are meant to address common mistakes that system administrators need to avoid when deploying infrastructure to AWS. For a comprehensive list of security best practices, check out this Amazon whitepaper.

Gerben Kleijn is a Senior Security Analyst at Bishop Fox, a security consulting firm providing IT security services to the Fortune 500, global financial institutions, and high-tech startups. In this role, he focuses on compliance gap assessments and cloud deployment reviews in addition to firewall and VPN reviews.

Special thanks to Trevor Lawrence and Ruihai Fang for their contributions to this series.