As a seasoned cloud security engineer, I’ve witnessed the crucial role of thoroughly testing AWS environments in identifying and fixing vulnerabilities before attackers can exploit them.

I’ve been in two types of engagements – external cloud pentests and external cloud security assessments for regulatory compliance reasons.

Regardless of the type of engagement, choosing the appropriate IAM policy for these activities can be a challenging task.

Should you opt for SecurityAudit, ReadOnly, or ViewOnly?

I’ve faced this situation often, and I’d like to share my perspective.

The Big Three Policies: An Overview

For those new to this, here’s a quick overview of the key pre-defined IAM policies frequently considered for pentesting:

SecurityAudit (Version 42): Grants permissions to assess the configuration of AWS resources for adherence to security best practices, including access to potentially sensitive information needed for auditing. It also grants permission to access the findings from AWS Security services like Inspector, GuardDuty, etc.

ReadOnly (Version 113): As the name suggests, this policy allows read-only access to resources across most AWS services. A user/role with this policy can view and read data but not modify configurations. You must also note that this policy grants read-only access to both resource configurations and stored data.

ViewOnly (Version 18): A more restrictive version of ReadOnly that removes access to some services/actions considered higher-risk.

Please note that AWS manages the versions of these managed policies, and the information provided here is based on the versions mentioned above, which may change in the future.

Recommended Solution: SecurityAudit

After careful consideration, my recommended solution for most pentesting scenarios is the SecurityAudit policy. This policy balances sufficient access for comprehensive testing and minimizing the risk of unintended data exposure or resource tampering.

SecurityAudit grants access to vital security findings from services like Inspector, GuardDuty, and Macie, essential for identifying potential issues. It also allows access to network security configurations in Network Firewall, Shield, and WAF (v1, v2, and regional), enabling a thorough evaluation of your security posture.

Additionally, SecurityAudit provides access to Resource Access Manager and SSM available patch status that are crucial for understanding the overall access control and system configurations across your AWS environment.

ReadOnly policy is even more permissive than SecurityAudit. It grants almost all permissions of the SecurityAudit policy along with the permissions to do the following:

• Fetch data from S3, DynamoDB, etc

• List and read Cognito users

• Clone repositories from CodeCommit

• Read from SQS queues

• Read (any secrets) stored in the SSM Parameter Store

• Get Lambda function code

This level of access may not be necessary for most pentests and could introduce unnecessary risks.

ViewOnly, on the other hand, is more restrictive and may not provide sufficient visibility into key security configurations and findings. It doesn’t allow users to get the findings from AWS Security services like Inspector, GuardDuty, etc.

Best Possible Solution: Least Privileged Access Based on Scope

Every external pentest and cloud security assessment has its scope.

The best possible solution is to grant access only to the specific services and actions required for the pentest. This approach minimizes the potential blast radius and ensures that the pentester has the minimum necessary permissions to conduct their assessment effectively.

To achieve this, consider creating a custom IAM policy with specific permissions needed for your pentest scope. A custom policy allows you to fine-tune access and align it precisely with your testing requirements.

Conclusion

Choosing the right IAM policy for your AWS pentesting requires careful consideration of your testing requirements and risk tolerance. While SecurityAudit provides a solid foundation for most assessments, the best approach is to adhere to the principle of least privilege and grant access only to the specific services and actions necessary for your pentest.

Avoid granting Get* and Describe* permissions without careful consideration, as it may unintentionally allow access to sensitive data that should be restricted.

FAQs

1. I’m still not convinced. Why should I not give ReadOnly policy access?

Let me put it another way. The risk of the ReadOnly policy is granting access to data. Despite your engagement under NDA, external pentesters/consultants are “technically capable” of copying your data. Do you have the technical capabilities to analyze their actions in your account? (On both management and data events.)

2. Are there any situations when ReadOnly access is needed?

It depends. ReadOnly access grants access to data in S3 and DynamoDB. It lets you download Lambda code, clone images from ECR, clone repositories from CodeCommit, etc. Suppose your pentest includes scanning data (maybe as part of data security assessments) or finding security issues in Lambda code, ECR repos, etc.. In that case, it might make sense to grant ReadOnly.

3. My external pentest company has given me a custom policy, which I suspect is just a copy of the ReadOnly policy. How can I quickly find the access granted?

Post the policy in the Permissions.Cloud’s Policy Evaluator. It flags any IAM permissions that leads to data access and credentials exposure.