Cloud computing is booming. Amazon Web Services, or AWS, is a godsend for non-techies. Subscribers of AWS account has the ease of implementing and using many clouds computing programs, skipping all the complex software designs of the past.

It also brings with itself a bunch of security, cost and governance issues. That's where AWS security audit comes in to secure your AWS infrastructure from any risks or vulnerabilities with a risk-based approach.

Also Read: The Ultimate Guide to Optimize AWS Cost: Best Tools & Tips

What is AWS Security Audit?

Security audit is the evaluation of a network's security infrastructure by assessing its configurations, permissions, and many other features. It makes sure that the network is not vulnerable and meets up to its security standards. Hence, auditing these AWS instances for identifying security flaws, loopholes and vulnerabilities is known as AWS security audit.

AWS security audit is further divided into two types of security such as security of cloud and security in cloud.

1. Security of Cloud

Security of cloud involves identifying logic flaws that may make the cloud infrastructure and environment vulnerable.

2. Security in Cloud

Whereas security in the cloud involves controlling the security by implementing instances of your choice, so that no unnecessary instance can be exploited by the hackers.

AWS security audit guidelines

An organization should periodically audit their security configurations in order to make sure that all their current business needs are met. Audit helps you figure out the optimum conditions for your workflows and removes any unnecessary or unneeded IAM users, IAM roles, groups & policies so that your software & users do not have any unnecessary permissions that are not required.

Guidelines for auditing

For further evaluation of your AWS account security configuration some things must be kept in mind.

• Implement in-depth security audit configuration.
• Don't overlook your infrastructure's security take relevant precautions.
• Make auditing management easier by implementing straightforward policies, consistent naming schemes and using IAM groups.

Why perform an AWS security audit?

The worst thing that can ever happen to an organization is its data breach. It completely deteriorates the customers trust in an organization. There are many examples where such circumstances became the sole reason for the downfall of the businesses.

According to Thales Global Cloud Security, "In 2021, 40% of organizations experienced a cloud-based data breach." Hackers can easily exploit security in the cloud and leak sensitive information regarding business which thus damaging its reputation, revenue, customer's trust and much more. With the drastic advancements nowadays, this number is likely to grow.

Hence it is becoming necessary for businesses to implement AWS security audit.

In fact, for continued security, you should carry out the AWS security audits regularly. The recommended time is as follows:

• Reviewing System logs on a monthly basis.
• Checking the behavior of the hosted service for abnormalities or something suspicious every 4 to 6 months.
• Running a full scan to ensure no breach occurred any year.

For continued security auditing purpose there are many AWS services and tools out there which support automation and also requires some sort of manual supervision. The upcoming sections will elaborate more on these tools and how to integrate them into your workflow.

Identity and Access Management (IAM)

Whenever we think of performing a Security audit IAM comes to mind, as using it you can specify, manage, and analyze who or what software can access AWS services and resources.

When implementing IAM in your auditing strategy you should first be familiar with its basics, below is a brief overview:

IAM basics

Just as over-privileged users, resources and roles. You should implement some basic things to make vulnerability to a bare minimum.

• Configure password requirements for your AWS accounts,
• Implement multi-factor authentication for your root accounts,
• Try to limit your root account usage only use it when necessary, such as setting billing plan and changing its own address as these functions are not available with an actual IAM user or role,
• Utilize Access Analyzer to identify unintended access which could be used by unauthorized entities,
• IAM roles and users should be limited as they bring extra risk with them,
• Disable roles that are not active in the past 90 days or more,
• Always utilize open-source tools for IAM analysis access management.

Review your IAM users

When auditing existing IAM users make sure to keep in mind:

1. Always make a list of users that are active and delete those that are inactive.
2. Take users out from the group which they don't need to be part of.
3. Analyse the policies of the groups that users are part of.
4. Remove security credentials that the user doesn't need or might have been exposed, and if the user does not require access keys there's no reason for the user to have one.
5. Rotate your IAM users' security account credentials regularly.

Review your AWS account credentials

Evaluate your AWS account credentials when auditing by taking these steps:

1. Take these steps when you audit your AWS account credentials:
   It's recommended not to use root access keys for your AWS account instead, you should use accounts with temporary credentials such as users in AWS SSO or IAM Identity Center.
2. It's a good practice to rotate your account access keys regularly.

Implementing Logical Access Control

After identifying all the assets on the cloud comes the task to manage the access control over it. Access to the AWS resources can be controlled via individual identity and access management of your user account.

Logical Access Control involves process which assigns what type of actions can be performed on resource and by whom. The major step of this process involves controlling access to AWS resources, processes, & users.

Main objective of this tool is to focus and identify how users & permissions are set up for the service in AWS and to ensure that the credentials associated with the accounts is well secured.

Implementing S3

Simply put, S3 is basically a cloud folder commonly called a "bucket". It is a storage server that provides you with powerful features such as regional exceptions, logging, access control, encryption, and versioning.

Factors affecting AWS security of S3 buckets

The factors that determine the safety of the S3 bucket are: -

• The S3 bucket should have logging enabled.
• The S3 bucket should have versioning enabled.
• Permissions for HTTP methods such as LIST, GET, PUT, DELETE, etc. should only be allowed for specified users.

Implementing AWS Database Service

Database is the main component and mainly used in amazon web services. Therefore, business must make sure that their database is up to the security standards. One single loophole can cause a breach in your cloud environment.

With Amazon Relational Database Service or RDS it has never been easier. You can easily set up databases on aws cloud with a number of clicks or even use pre-existing AWS cloudformation templates. Even after making the databases with amazon RDS make sure to follow the steps below while performing AWS security audit:

• Sensitive data should not be accessible by public,
• Backup your crucial data on a regular basis,
• Only a few IP addresses should be given access,
• Multi-AZ deployment method is recommended for database deployment,
• Retention time for backups should be set to more than a week,
• Instances storage should have some sort of encryption enabled.

Ensure audit logs are enabled for security controls

Other than that, we need audit logs. Audit logs are essential to help you detect critical incidents and understand what happened after the incident.

CloudTrail is essentially an automated log of every action that happens most often in AWS. But there are other services - depending on your workload - that you might consider, including VPC streaming logs if you're using servers or S3 bucket access logs if you're using public repositories.

Review your Amazon EC2 security configuration

AWS config rules change with respect to different regions. Make sure that you follow the following steps for your region:

1. Delete Amazon EC2 key pairs that are not in use or that are known to people outside your network, to eliminate any security vulnerabilities.
2. Review your Amazon EC2 security groups:
3. Remove rules from security groups that no longer meet your needs. Make sure you know why ports, protocols, and IP addresses ranges are allowed as is.
4. Remove security groups that don't meet your needs.
5. Terminate cases that do not meet the business need or that are initiated by someone outside your network for unauthorized purposes. Note that if an instance is launched with a role, applications running on that instance can access AWS resources using the permissions granted by that role.
6. Cancel Spot Instance requests that currently are not serving any business needs or service accounts as they may have been made by someone outside your network.
7. Review automation groups and configurations on a regular basis. Close those groups that no longer meet your needs or that were set up by someone outside your network.

Review AWS policies in other services

Always make sure to check the permissions that are given to the services which use resource-based policies which directly affects security mechanisms. Whatever the case maybe makes sure that only users and roles who are active have access to the service's resource and try to limit the permissions as much as you can to secure your business's cloud environment.

There are a lot of AWS policies that needs to be reviewed such as Amazon SQS queue, Amazon S3 bucket and ACLs, Amazon SNS topic, AWS OpsWorks permissions, and AWS KMS key policies.

Guideline for reviewing IAM policies

As discussed earlier, policies are very powerful but minute and can directly affect a business security. That is why understanding the permissions granted by each policy is an important part of security best practices. Below are some tips on reviewing these policies:

• It is better to impose policies on groups instead of individual users,
• Make sure to understand the policy which are assigned to an individual user,
• Test policies which are imposed on users or groups beforehand via IAM Policy Simulator,
• Keep in mind that permissions a user has are the result of all policies which are attached with him (Amazon S3 buckets, Amazon SQS queues, Amazon SNS topics, and AWS KMS keys) that is why it is very important to look into all the policies in order to understand the permissions that are given to an individual user,
• Do not give IAM permissions to users who you do not trust with full access to resources as they will be allowed to create policies and also attach user, group, or role to grant them any permissions. Below are some IAM policies that you should be closely focus:
• iam:PutGroupPolicy
• iam:PutRolePolicy
• iam:PutUserPolicy
• iam:CreatePolicy
• iam:CreatePolicyVersion
• iam:AttachGroupPolicy
• iam:AttachRolePolicy
• iam:AttachUserPolicy
• Examine clearly that policies are not giving permissions for services that are not in use. You can check which policies are active in your account by using AWS CLI command to run aws iam get-account-authorization-details (IAM GetAccountAuthorizationDetails API).
• Make sure that no policy is allowing a user to launch an EC2 instance as it may allow the user to run iam:PassRole action.
• If need be, to allow access to individual actions and resources that users need try to implement it by using a policy. Below are some reasons why it is one of the best practices to secure your cloud environments:
• The policy is designed to grant administrative-level privileges.
• Most of the time policies are designed keeping in mind administrative-level permission,
• The wildcard character can be used to show a complete list of class of resources or resources path and make sure that you are comfortable granting access to these resources in that specific class or path. You can do this by running arn:aws:iam::account-id:users/division abc/ in your aws environments,
• Wildcard characters can be used for convenience to execute similar action or a list of actions.
• Review the policy names to ensure they reflect the function of the policy. For example, although a policy may have a name that includes "read-only", the policy may allow writing or editing.

Develop Data Flow diagrams and Network maps to assist in aws config if none exist

An organization must have a data flow diagram of their workflows so that they know which users or accounts are utilizing which resources and get better view of their AWS security. If you don't know how the developer uses the system, you don't know what you can do. This in result can help with decisions such as blocking S3 public access.

‍

‍