AWS Security Architect Level Audits on AWS Accounts

As an AWS Security Architect, one of your first tasks would be to go into your customer’s account (or multiple AWS accounts) and look around for security specific events created by services such as GuardDuty, Inspector and Macie. This is a fairly involved task in and of itself. You need to understand WHAT it is that the customer is looking to get audited (security audited) and WHERE to look for that information.

What should be audited?

(Also read, KMS based data encryption on AWS and Google Cloud)

CloudTrail logs, CloudWatch log groups, GuardDuty logs, Inspector logs, VPC Flow Logs, Trusted Advisor logs – are just some AWS native services that provide you insight into security events on your AWS account.

Each of these services requires a role with it’s own IAM policies, either custom or managed – for access. This is why a majority of AWS admins take a shortcut. They create a role (or a user) and assign a Full Administrator policy to users that need read only access to these logs.

That’s the key point — this is meant to be a read only user (or role), and granting full admin is overkill, apart from being a security risk.

So — what’s the alternative?

An Auditor Role would be cool (FullAdmin Role is a terrible idea)

Wouldn’t it be cool if you could encapsulate all the required IAM policies into a single policy?  And simply create a user (or a role) with that attached policy?

This post describes such a Security Auditor role in AWS, with the following attributes.

1. A READ ONLY (auditor) role that is able to access logs and events to investigate potential security breaches or potential malicious activity.
2. The role should have privileges to read and view ANYTHING and EVERYTHING related to security, monitoring and troubleshooting within an AWS environment.
3. This should include GuardDuty logs, CloudTrail logs, CloudWatch events, Inspector logs and more.
4. Optionally, it should also continuously check for compliance vioilations (security related compliance violations – such as open Security Groups, Public IPs etc.)

Built in Security policies in AWS IAM ?

Believe it or not, AWS has already thought through the majority of this security audit use case. They have a policy specifically designed to perform this read only auditing role. However, as this post will describe, you may still need an additional policy or two (depending on how comprehensive an auditor role you are defining is).

To that end, the policies that I recommend for a full security auditor role in AWS include:

• SecurityAudit– MUST have policy, contains all the read only permissions for cloudtrail, cloudwatch, vpc flow logs, inspector logs and more.
• AWSSecurityHubFullAccess(as opposed to AWSSecurityHubReadOnlyAccess— Wait, didn’t you say you should avoid FullAccess? This was meant to be a read only role. You are right – but the SecurityHub full access isn’t the same as Admin Full Access. In addition, what it buys you, is the ability to automatically check for any compliance violations (See the AWS managed policy AWSSecurityHubFullAccess section below).

Why do we need this AWS managed policy –  AWSSecurityHubFullAccess ?

 It is not enough to simply ‘read’ security events. Often times, the role of an AWS Security Architect includes remediation of certain security breaches as well as non compliant resources.

When you enable Security Hub, it’s assigned a service-linked role named:

AWSServiceRoleForSecurityHub

This service-linked role includes a trust policy that Security Hub requires to do the following:

1. Detect and aggregate findings from Amazon GuardDuty, Amazon Inspector, and Amazon Macie
2. Configure the requisite AWS Config infrastructure to run supported standards (in this release, CIS AWS Foundations) compliance checks.

This is why I recommend this policy for all auditor roles. The SecurityAudit policy by itself does not allow the running of supported CIS benchmarks.

What about Cross Region Security Logs and Cross Account Logs?

The SecurityAuditor role (A role with the SecurityAudit AWS policy attached), provides access to cloudwatch logs, regardless of the region in which they were created. The same applies for all other security related logs, including VPC flow logs, Inspector Logs and GuardDuty logs.

For accessing logs across AWS accounts, you have 2 options:

1. Either create the same role in each account and provide cross account ‘assume role’ access to appropriate users in each account.
2. A better solution is to use a centralized logging solution in your AWS account. This would channel all logs from all different accounts to a centralized logging account (typically to an S3 resource).

Are there any Permissions Boundaries for this role?

No permission boundaries are required for this role, since it is designed as a read only role.

Other Public Clouds? Azure and Google Cloud Security Auditor Roles

This post focuses on your role as an AWS Security Architect.

• In GCP, the equivalent is the IAM Security Reviewer role (roles/iam.securityReviewer).
• In Azure, the closest is the Security Reader Role.

The following table displays roles and allowed actions in Azure Security Center (source Azure docs).

Summary

 Auditing all security related events and logs across an AWS account means auditing multiple logs. Each of these logs can be streamed to a variety of destinations. This makes it challenging to assign IAM policies for accessing each service’s log, especially since it could be going to an S3 bucket today and to an event streaming service tomorrow.

 This post details creating a SINGLE role that provides READ ONLY access across all security events and logs – regardless of their source (GuardDuty, VPC Flow Logs, Inspector, Trusted Advisor Logs) or their destination. Also see, Azure Identity 

Looking for a consultant to assist with a Cloud Security Review on AWS, Azure or Google Cloud?

Set up a 1 on 1 appointment with Anuj to assist with your AWS security architecture and cloud journey.