Ensuring a solid security posture of an organisation’s AWS accounts can be quite challenging nowadays due to the numerous service options and configurations, as well as the added burden of complying with business requirements and incumbent infrastructure. As AWS services grow in scope and complexity, organisations must adopt a systematic approach to configuring their cloud environments in line with business needs, while making sure their environments are well secured, adhering to industry best practices where applicable.
In this post, I will be discussing key methodologies for performing a holistic security review of an AWS account, as well as noting points that we believe to be key, based on years of experience of reviewing various client AWS environments at Dionach.
While I intend for the guide to be easy to follow, I have made the assumption that the reader is reasonably familiar with the AWS cloud and its concepts.
Scoping and Preparing an AWS Security Assessment
When it comes to scoping an AWS security review, the Dionach scoping team will initially discuss the proposal with the client organisation so that we can first get an understanding of the size and purpose of the AWS environment, as well as the client requirements. As part of this phase, the scoping team will also request any design documentation and diagrams that are available, which will help the consultant undertaking the review to better understand the current architecture.
Nowadays, companies design AWS environments using multiple AWS accounts, which follows the recommended approach from a security point of view, as it helps enforce better segregation and access control, and enables easier management of the cloud infrastructure. The AWS Well-Architected Framework is an invaluable resource that helps organisations with decision-making when designing their cloud.
It is therefore important for security reviewers to be made aware of how many AWS accounts are involved in the scope in question, which regions are in use, and what are the key AWS services that are in use. For example, in some cases, organisations will setup an AWS account for operating the production version of their software, but at the same time, they may have more AWS accounts used as part of the software’s setup, such as a development and a logging account. Since those accounts might leverage cross-account access for principals, it is important for them to be included as part of the review one.
The First Steps in an AWS Security Review
When the security review commences, one of the first things any consultant should do is to leverage the AWS Tag Editor tool. AWS organisations frequently manage resources across multiple regions. Even if an organisation primarily operates in a single region, leftover testing resources or resources automatically created during provisioning in other regions could pose a significant security risk. Tag Editor enables a consultant to create an initial report of all services and resources in use under an AWS account. This can be achieved by choosing “All Regions” and “All supported resource types”, searching for them and then exporting the CSV report.
It is important to ensure that the user account provided for testing purposes has the “SecurityAudit” and “ReadOnlyAccess” AWS managed policies attached, and that there’s no deny policies attached to the testing account, or boundaries or service control policies (SCPs) that might deny specific actions during the assessment.
This enables the consultant to ensure that every resource will be scanned and manually reviewed, even if the customer is not aware of some of them.
Combining Scanners and Manual Audits
While cloud scanning tools provide an efficient means to quickly gather data, as with any automated tool, they have their limits and are certainly not foolproof. They also do not or cannot implement checks for all services and security scenarios. A balanced approach combining automated scans with manual audits, while focusing on key services and the primary regions allows the consultant to provide a holistic security review.
Depending on the AWS services exposed, numerous tools can be used. For example, if the AWS account has been provisioned using infrastructure as code (IaC), one of the tools that we will use is checkov. At the same time, the whole environment will be scanned with well-known scanning tools such as Tenable Nessus and ScoutSuite. Additionally, AWS’s own security services will be reviewed if they are in use, such as AWS Config, GuardDuty and ECR’s vulnerability scanner to name but a few.
When it comes to reviewing the IAM permissions, a wealth of both open source and Dionach in-house tools, such as Cloudsplaining and aws_escalate.py, will be used. It is vital that all results from automated tools are verified, and that IAM users, roles and custom policies, as well as resource-based policies, are manually reviewed by the consultant.
Although using automated tools is crucial in order to provide a holistic AWS security review, the majority of the consultant’s testing time will be spent reviewing the in-scope services on the AWS console with the help of the AWS API. Very often while we are trying to verify whether a security setting, such as server-side encryption, has been enabled, the answer may not be visible on the console but it is more easily verified by leveraging the AWS API.
Focusing on IAM and Resource-Based Policies
AWS IAM is one of the most important services. Due to how many options AWS offers for access control, including cross-account resource access, resource-based policies, inline policies, SCPs, conditions and boundaries, it is important that the consultant gains a good understanding of the environment and manually assesses every aspect of IAM. Tools are helpful but they cannot be aware of the context. For example, if there’s a privileged IAM user account with API access and console access disabled for the purposes of provisioning the AWS account in question, the consultant should review the security controls around it (e.g. MFA enforced, IP whitelist) and liaise with the customer to ensure that this user account is safely handled.
Reviewing all the resource-based policies is very important as cloud developers will sometimes copy and paste example policies from the Internet without further hardening them, and end up introducing a relaxed “Principal” in the policy without enforcing further conditions that block access to the resource. This sometimes results in anonymous cross-account access, as anyone can interact with these resources. Historically, S3 buckets’ access control was often misconfigured in the past, but nowadays we see misconfigurations with various other services such as SQS, SNS, and ECS.
When reviewing IAM roles, one should always verify the trusted entities, which shows which principal can assume the role in question. For example, if the role is privileged and the EC2 service is the trusted entity, verifying the security of the EC2 instances that are assuming this role is critical, because if they were to become compromised, an attacker could use the assumed privileged role to further compromise the AWS account. MFA and external IDs should be used when a role allows cross-account access to avoid a confused deputy attack scenario.
Final Thoughts
There are more than 200 services on the AWS cloud and it would be impossible to discuss all of them in a single blog post. Final key thoughts are below:
- Reviewing logs under AWS CloudTrail helps highlight potential security gaps
- Discussing potential IAM misconfigurations with the client, while verifying whether they are exploitable with the use of a secondary testing account allows us to provide an objective assessment
- Leveraging multiple tools, the console, and the API to verify security misconfigurations helps remove false positives
- Approaching the security review in an audit-fashion allows consultants to ensure that supplementary compensating controls are in place for any missing security settings and enables us to provide a tailor made report to the organisation, designed to increase their cloud security configuration
I hope this blog highlights the need for following a holistic methodology that ensures reviewing all the resources and checking every resource’s security settings, both automatically and manually, is necessary in order to provide a valuable assessment to customers. At all stages of the assessment though, communication between the lead consultant and the customer is vital to ensure a successful security review.