Impact: HIGH

Probability: LOW

Status: PASS

CVSS: Score: 8.1

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Description

The 'root' user account is the most privileged user in an AWS account. AWS Access Keys provide programmatic access to a given AWS account. It is recommended that all access keys associated with the root user account be removed. Removing access keys associated with the root user account limits vectors by which the account can be compromised. Additionally, removing the root access keys encourages the creation and use of role based accounts that are least privileged.

Remediation

Ensure no root user account access key exists

Affected

['123456789123']

Analysis

No Root Access Keys Found

Impact: HIGH

Probability: MEDIUM

Status: PASS

CVSS: Score: 9.1

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Description

The 'root' user account is the most privileged user in an AWS account. Multi-factor Authentication (MFA) adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their username and password as well as for an authentication code from their AWS MFA device. Note: When virtual MFA is used for 'root' accounts, it is recommended that the device used is NOT a personal device, but rather a dedicated mobile device (tablet or phone) that is managed to be kept charged and secured independent of any individual personal devices. non-personal virtual MFA - This lessens the risks of losing access to the MFA due to device loss, device trade-in or if the individual owning the device is no longer employed at the company. Enabling MFA provides increased security for console access as it requires the authenticating principal to possess a device that emits a time-sensitive key and have knowledge of a credential.

Remediation

Enable MFA for the root user account. Note: to manage MFA devices for the 'root' AWS account, you must use your 'root' account credentials to sign in to AWS. You cannot manage MFA devices for the 'root' account using other credentials.

Affected

['123456789123']

Analysis

Root Password Disabled

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The 'root' user account is the most privileged user in an AWS account. MFA adds an extra layer of protection on top of a user name and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their user name and password as well as for an authentication code from their AWS MFA device. For Level 2, it is recommended that the root user account be protected with a hardware MFA. A hardware MFA has a smaller attack surface than a virtual MFA. For example, a hardware MFA does not suffer the attack surface introduced by the mobile smartphone on which a virtual MFA resides. Note: Using hardware MFA for many, many AWS accounts may create a logistical device management issue. If this is the case, consider implementing this Level 2 recommendation selectively to the highest security AWS accounts and the Level 1 recommendation applied to the remaining accounts.

Remediation

Ensure hardware MFA is enabled for the root user account

Affected

['123456789123']

Analysis

Root Password Disabled

Impact: HIGH

Probability: LOW

Status: PASS

CVSS: Score: 8.1

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Description

With the creation of an AWS account, a 'root user' is created that cannot be disabled or deleted. That user has unrestricted access to and control over all resources in the AWS account. It is highly recommended that the use of this account be avoided for everyday tasks. The root user has unrestricted access to and control over all account resources. Use of it is inconsistent with the principles of least privilege and separation of duties, and can lead to unnecessary harm due to error or account compromise.

Remediation

If you find that the 'root' user account is being used for daily activity to include administrative tasks that do not require the 'root' user: 1. Change the 'root' user password. 2. Deactivate or delete any access keys associate with the 'root' user. **Remember, anyone who has 'root' user credentials for your AWS account has unrestricted access to and control of all the resources in your account, including billing information.

Affected

['123456789123']

Analysis

There is currently no information on root account usage.

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.6

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

Description

Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure password are at least a given length. It is recommended that the password policy require a minimum password length 14. Setting a password complexity policy increases account resiliency against brute force login attempts.

Remediation

Ensure IAM password policy requires minimum length of 14 or greater

Affected

['123456789123']

Analysis

Minimum Password Length = 14

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.6

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

Description

IAM password policies can prevent the reuse of a given password by the same user. It is recommended that the password policy prevent the reuse of passwords. Preventing password reuse increases account resiliency against brute force login attempts.

Remediation

Ensure IAM password policy prevents password reuse

Affected

['123456789123']

Analysis

Password Reuse Prevention = 24

Impact: HIGH

Probability: MEDIUM

Status: PASS

CVSS: Score: 9.1

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Description

Multi-Factor Authentication (MFA) adds an extra layer of authentication assurance beyond traditional credentials. With MFA enabled, when a user signs in to the AWS Console, they will be prompted for their user name and password as well as for an authentication code from their physical or virtual MFA token. It is recommended that MFA be enabled for all accounts that have a console password. Enabling MFA provides increased security for console access as it requires the authenticating principal to possess a device that displays a time-sensitive key and have knowledge of a credential.

Remediation

Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password

Affected

['123456789123']

Analysis

All users have MFA enabled.

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.6

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

Description

AWS console defaults to no check boxes selected when creating a new IAM user. When creating the IAM User credentials you have to determine what type of access they require. Programmatic access: The IAM user might need to make API calls, use the AWS CLI, or use the Tools for Windows PowerShell. In that case, create an access key (access key ID and a secret access key) for that user. AWS Management Console access: If the user needs to access the AWS Management Console, create a password for the user. Requiring the additional steps be taken by the user for programmatic access after their profile has been created will give a stronger indication of intent that access keys are [a] necessary for their work and [b] once the access key is established on an account that the keys may be in use somewhere in the organization.

Remediation

Do not setup access keys during initial user setup. Remove any access keys that are no longer required.

Affected

['123456789123']

Analysis

No unused Access Keys found.

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.6

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

Description

AWS IAM users can access AWS resources using different types of credentials, such as passwords or access keys. It is recommended that all credentials that have been unused in 45 or greater days be deactivated or removed. Disabling or removing unnecessary credentials will reduce the window of opportunity for credentials associated with a compromised or abandoned account to be used.

Remediation

Ensure credentials unused for 45 days or greater are disabled

Affected

['123456789123']

Analysis

No unused credentials found.

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.6

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

Description

Access keys are long-term credentials for an IAM user or the AWS account 'root' user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API (directly or using the AWS SDK) Access keys are long-term credentials for an IAM user or the AWS account root user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API. One of the best ways to protect your account is to not allow users to have multiple access keys.

Remediation

Ensure there is only one active access key available for any single IAM user

Affected

['123456789123']

Analysis

No users with more than one access key found.

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.6

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

Description

Access keys consist of an access key ID and secret access key, which are used to sign programmatic requests that you make to AWS. AWS users need their own access keys to make programmatic calls to AWS from the AWS Command Line Interface (AWS CLI), Tools for Windows PowerShell, the AWS SDKs, or direct HTTP calls using the APIs for individual AWS services. It is recommended that all access keys be regularly rotated. Rotating access keys will reduce the window of opportunity for an access key that is associated with a compromised or terminated account to be used. Access keys should be rotated to ensure that data cannot be accessed with an old key which might have been lost, cracked, or stolen.

Remediation

Ensure access keys are rotated every 90 days or less

Affected

['123456789123']

Analysis

No keys that have not been rotated found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

IAM users are granted access to services, functions, and data through IAM policies. There are three ways to define policies for a user: 1) Edit the user policy directly, aka an inline, or user, policy; 2) attach a policy directly to a user; 3) add the user to an IAM group that has an attached policy. Only the third implementation is recommended. Assigning IAM policy only through groups unifies permissions management to a single, flexible layer consistent with organizational functional roles. By unifying permissions management, the likelihood of excessive permissions is reduced.

Remediation

Ensure IAM Users Receive Permissions Only Through Groups

Affected

['123456789123']

Analysis

No directly attached policies found.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 8.1

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Description

IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered a standard security advice to grant least privilege -that is, granting only the permissions required to perform a task. Determine what users need to do and then craft policies for them that let the users perform only those tasks, instead of allowing full administrative privileges. It's more secure to start with a minimum set of permissions and grant additional permissions as necessary, rather than starting with permissions that are too lenient and then trying to tighten them later. Providing full administrative privileges instead of restricting to the minimum set of permissions that the user is required to do exposes the resources to potentially unwanted actions. Where Administrator access is required use the AWS Management policy instead of Customer Managed or Inline Policies.

Remediation

Customer Managed and Inline policies that grant full administrative privileges should be removed in favour of AWS Managed policies. Ensure all permissions are applied using the principle of least privilege and remove adminisrtator access from anyone that doesnt require it.

Affected

['123456789123']

Analysis

No custom policies that allow full *:* privileges found.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Description

To enable HTTPS connections to your website or application in AWS, you need an SSL/TLS server certificate. You can use ACM or IAM to store and deploy server certificates. Use IAM as a certificate manager only when you must support HTTPS connections in a region that is not supported by ACM. IAM securely encrypts your private keys and stores the encrypted version in IAM SSL certificate storage. IAM supports deploying server certificates in all regions, but you must obtain your certificate from an external provider for use with AWS. You cannot upload an ACM certificate to IAM. Additionally, you cannot manage your certificates from the IAM Console. Removing expired SSL/TLS certificates eliminates the risk that an invalid certificate will be deployed accidentally to a resource such as AWS Elastic Load Balancer (ELB), which can damage the credibility of the application/website behind the ELB. As a best practice, it is recommended to delete expired certificates.

Remediation

Ensure that all the expired SSL/TLS certificates stored in AWS IAM are removed

Affected

['123456789123']

Analysis

No server certificates found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The affected IAM groups, do not contain any users and are therefore not being used. To maintain the hygiene of the environment, make maintenance and auditing easier and reduce the risk of IAM groups erroneously being used and inadvertently granting more access than required, all old unused IAM groups should be removed.

Remediation

Ensure all IAM groups that are temporary and not being used are deleted when no longer required.

Affected

['123456789123']

Analysis

No unused IAM Groups found.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 4.6

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L

Description

The affected AWS account has a number of Cross-Account assume role policies which lack an external ID. Policies which lack an external ID are vulnerable to what is known as the Confused Deputy Problem. An assume role policy allow a trust relationship to be set up between two accounts that allows users to assume a role and inherit permissions in other accounts. This is often used to allow third party access to your account to perform specific support roles or tasks like monitoring and maintenance. When the third party requires access to your account they can assume the IAM role and its temporary security credentials without needing to configure IAM users and share long-term credentials (for example, an IAM users access key) . Configuring cross account roles with external IDs and or MFA verification can help ensure that when using the role to access resources in your account they are acting under genuine circumstances and have been confused or socially engineered by a malicious actor to escalate permissions within or perform malicious actions on in your AWS account. Let say Example Corp requires access to certain resources in your AWS account. But in addition to you, Example Corp has other customers and needs a way to access each customers AWS resources. Instead of asking its customers for their AWS account access keys, which are secrets that should never be shared, Example Corp requests a role ARN from each customer. But another Example Corp customer might be able to guess or obtain your role ARN. That customer could then use your role ARN to gain access to your AWS resources by way of Example Corp. This form of permission escalation is known as the confused deputy problem. The external ID is a piece of data that can be passed to the AssumeRole API of the Security Token Service (STS). You can then use the external ID in the condition element in a roles trust policy, allowing the role to be assumed only when a certain value is present in the external ID. The proper use of External IDs can also help protect against the "double hop problem". The "double-hop problem" occurs when you've allowed cross-account access, and a principal (user, role, or account) from another account can: Initially assume a role in your account ("first hop"). Use that assumed role in your account as a launchpoint to assume a role in yet another account ("second hop"). If not properly configured, you inadvertently allow your AWS account to serve as a "jumping-off point," allowing external actors indirect access to third-party accounts or resources. This creates potential security risks and accountability issues.

Remediation

All Cross-Account roles which provide a level of privileged access should be configured with a unique and complex external ID as well as performing re authentication via MFA. More Information https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/ https://en.wikipedia.org/wiki/Confused_deputy_problem

Affected

['123456789123']

Analysis

No failing roles found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The affected Groups grant member user full admin "*" access to the account

Remediation

ensure only users that require admin access have it.

Affected

['123456789123']

Analysis

No Admin Groups Found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

An AWS principle was found that grants admin privileges within the AWS account. The name of this group does not clearly indicate the level of privilege provided. To make maintaining the account as easy as possible and to reduce the risk of administrative privileges being granted to AWS principles that do not require them by mistake it is recommended to implement a common naming convention for all custom groups, roles and policies which indicates the level of access being granted.

Remediation

Implement a simple naming convention for all custom groups, roles and policies which clearly indicates what permissions they grant and who they should apply to.

Affected

['123456789123']

Analysis

No Admin Groups Found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Ensure that all your IAM principals (Users, Groups, Roles) are using managed policies (AWS and customer managed policies) instead of inline policies (embedded policies) to better control and manage the access permissions to your AWS account. Defining access permissions for your IAM groups using managed policies can offer multiple benefits such as reusability, versioning and rollback, automatic updates, larger policy size and fine-grained control over your policies assignment. Although not directly a security issue having a large number of inline policies increases complexity and could result in users, groups and roles being given more permissions than required and potentially resulting in privilege escalation vectors.

Remediation

Review the affected groups and remove inline policies in favour of AWS and Customer Managed Policies. More Information https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html

Affected

['123456789123']

Analysis

No Issues Found.

Impact: HIGH

Probability: LOW

Status: PASS

CVSS: Score: 8.1

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Description

AWS had advised incorrect policies for enforcing MFA which allowed an attacker, if they compromised keys that were protected by this policy, to remove the MFA policy from themselves, or remove the existing MFA device and add their own.

Remediation

TBC

Affected

['123456789123']

Analysis

No Issues Found

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 7.1

CVSS: Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Description

The AWS managed policy AmazonEC2RoleforSSM is in use and is considered overly permissive. By default, this role grants access to all S3 buckets in the account. It is recommended that the role is adjusted by applying the principal of least privilege.

Remediation

It is recommended that the AmazonSSMManagedInstanceCore policy is used instead and privileges are added as needed. More Information: https://www.tripwire.com/state-of-security/security-data-protection/cloud/aws-system-manager-default-permissions/

Affected

['123456789123']

Analysis

No Issues Found

Impact: HIGH

Probability: HIGH

Status: PASS

CVSS: Score: 8.1

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Description

The affected role is configured to trust the GitHub OIDC Identity Provider but does not enorce any subject conditions, This means an external attacker with knowledge of the role ARN can create a GitHub action that can assume this role and access the affected account.

Remediation

Configure the role trust policy to include aditional subject conditons which only allows the role be assume by trusted gitHub repositores and branches. more information https://aws.amazon.com/blogs/security/use-iam-roles-to-connect-github-actions-to-actions-in-aws/

Affected

['123456789123']

Analysis

No failing roles found.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 4.7

CVSS: Vector: CVSS:3.1/ AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

Description

The affected Users have been granted full admin "*" access to the account via a permissions policy which directly attached to the user, IAM users are granted access to services, functions, and data through IAM policies. There are three ways to define policies for a user: 1) Edit the user policy directly, aka an inline, or user, policy. 2) attach a policy directly to a user. 3) add the user to an IAM group that has an attached policy. Only the third implementation is recommended. Assigning IAM policy only through groups unifies permissions management to a single, flexible layer consistent with organizational functional roles. By unifying permissions management, the likelihood of excessive permissions is reduced.

Remediation

Ensure only users that require admin access have it and to help maintain account hygiene and minimise the risk of users retaining permissions for longer than required, ensure users only receive permissions via group membership and do not have policies attached directly.

Affected

['123456789123']

Analysis

No Admin Users Found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

AWS CloudShell is a convenient way of running CLI commands against AWS services; a managed IAM policy ('AWSCloudShellFullAccess') provides full access to CloudShell, which allows file upload and download capability between a user's local system and the CloudShell environment. Within the CloudShell environment a user has sudo permissions, and can access the internet. So it is feasible to install file transfer software (for example) and move data from CloudShell to external internet servers. Access to this policy should be restricted as it presents a potential channel for data exfiltration by malicious cloud admins that are given full permissions to the service. AWS documentation describes how to create a more restrictive IAM policy which denies file transfer permissions.

Remediation

From Console 1. Open the IAM console at https://console.aws.amazon.com/iam/ 2. In the left pane, select Policies 3. Search for and select AWSCloudShellFullAccess 4. On the Entities attached tab, for each item, check the box and select Detach

Affected

['123456789123']

Analysis

AWSCloudShellFullAccess Policy is not attached to any entities

Impact: HIGH

Probability: HIGH

Status: PASS

CVSS: Score: 8.1

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Description

The affected role is configured to trust an OIDC Identity Provider but does not enorce any subject conditions, This means an external attacker with knowledge of the role ARN could possibly assume the role from any account at the OIDC service provider

Remediation

Configure the role trust policy to include aditional subject conditons which only allows the role be assume by trusted gitHub repositores and branches. more information https://aws.amazon.com/blogs/security/use-iam-roles-to-connect-github-actions-to-actions-in-aws/

Affected

['123456789123']

Analysis

No failing roles found.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 4.6

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L

Description

The affected AWS role held a trust policy which was overly permissive and trusted all IAM principals within the account to assume the role and access the privileges it held. The overly permissive role trust policy could be abused by malicious users to escalate privileges and access resources within the AWS Organization. When creating IAM policies, administrators should follow the standard security advice of implementing least privilege assignments, by granting principals only the permissions required to perform their tasks. It is recommended that administrators determine what users (and roles) need to do and then starting with a default deny, policies should add the individual permissions that allow them to perform only those tasks. Additional privileges that may be required in future should be implemented through a request system.

Remediation

It is recommended that you review the role trust policy to determine which entities in your account should legitimately be allowed to assume the affected role. The role trust should then be updated to trust only those principals, which would prevent unauthorised individuals from access the highly-privilege policies attached the role. More Information https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

Affected

['123456789123']

Analysis

No failing roles found.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

AWS CloudShell is a convenient way of running CLI commands against AWS services; a managed IAM policy ('AWSCloudShellFullAccess') provides full access to CloudShell, which allows file upload and download capability between a user's local system and the CloudShell environment. Within the CloudShell environment, a user has sudo permissions and can access the internet. Therefore, it is feasible to install file transfer software, for example, and move data from CloudShell to external internet servers. Access to this policy should be restricted, as it presents a potential channel for data exfiltration by malicious cloud admins who are given full permissions to the service. AWS documentation describes how to create a more restrictive IAM policy that denies file transfer permissions.

Remediation

1. Open the IAM console at https://console.aws.amazon.com/iam/ 2. In the left pane, select Policies 3. Search for and select AWSCloudShellFullAccess 4. On the Entities attached tab, for each item, check the box and select Detach

Affected

['123456789123']

Analysis

awscloudshellfullaccess policy is not attached

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.6

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

Description

AWS access from within AWS instances can be done by either encoding AWS keys into AWS API calls or by assigning the instance to a role which has an appropriate permissions policy for the required access. AWS Access means accessing the APIs of AWS in order to access AWS resources or manage AWS account resources. AWS IAM roles reduce the risks associated with sharing and rotating credentials that can be used outside of AWS itself. If credentials are compromised, they can be used from outside of the AWS account they give access to. In contrast, in order to leverage role permissions an attacker would need to gain and maintain access to a specific instance to use the privileges associated with it. Additionally, if credentials are encoded into compiled applications or other hard to change mechanisms, then they are even more unlikely to be properly rotated due to service disruption risks. As time goes on, credentials that cannot be rotated are more likely to be known by an increasing number of individuals who no longer work for the organization owning the credentials

Remediation

Discontinue the use of hard coded access keys for EC2 instance and use IAM Roles via Instance Profiles instead. IAM roles can only be associated at the launch of an instance. To remediate an instance to add it to a role you must create a new instance.

Affected

['123456789123']

Analysis

No failing instances found

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Elastic Compute Cloud (EC2) supports encryption at rest when using the Elastic Block Store (EBS) service. While disabled by default, forcing encryption at EBS volume creation is supported. Encrypting data at rest reduces the likelihood that it is unintentionally exposed and can nullify the impact of disclosure if the encryption remains unbroken.

Remediation

Ensure EBS default volume encryption is enabled in all regions

Affected

['123456789123']

Analysis

Default EBS Volume encryption is enabled in all regions

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to remote server administration ports, such as SSH to port 22 and RDP to port 3389 . Public access to remote server administration ports, such as 22 and 3389, increases resource attack surface and unnecessarily raises the risk of resource compromise.

Remediation

Apply the principle of least privilege and only allow RDP and SSH traffic from a whitelist of trusted IP addresses

Affected

['123456789123']

Analysis

No security groups that allow remote server administration ingress traffic from 0.0.0.0/0 found

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

A VPC comes with a default security group whose initial settings deny all inbound traffic, allow all outbound traffic, and allow all traffic between instances assigned to the security group. If you don't specify a security group when you launch an instance, the instance is automatically assigned to this default security group. Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. It is recommended that the default security group restrict all traffic. The default VPC in every region should have its default security group updated to comply. Any newly created VPCs will automatically contain a default security group that will need remediation to comply with this recommendation. NOTE: When implementing this recommendation, VPC flow logging is invaluable in determining the least privilege port access required by systems to work properly because it can log all packet acceptances and rejections occurring under the current security groups. This dramatically reduces the primary barrier to least privilege engineering - discovering the minimum ports required by systems in the environment. Even if the VPC flow logging recommendation in this benchmark is not adopted as a permanent security measure, it should be used during any period of discovery and engineering for least privileged security groups. Configuring all VPC default security groups to restrict all traffic will encourage least privilege security group development and mindful placement of AWS resources into security groups which will in-turn reduce the exposure of those resources.

Remediation

Configure default security groups in all VPCs to be default deny and restrict all traffic

Affected

['123456789123']

Analysis

Default security groups restrict all traffic

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Once a VPC peering connection is established, routing tables must be updated to establish any connections between the peered VPCs. These routes can be as specific as desired - even peering a VPC to only a single host on the other side of the connection. Being highly selective in peering routing tables is a very effective way of minimizing the impact of breach as resources outside of these routes are inaccessible to the peered VPC.

Remediation

Configure routing tables for VPC perring following the principle of least access

Affected

['123456789123']

Analysis

VPC Peering not in use

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Although not a security risk, Amazon Web Services enforce a small hourly charge if an Elastic IP (EIP) address within your account is not associated with a running EC2 instance or an Elastic Network Interface (ENI). To ensure account hygiene and saves costs on your month bill it is recommended to release any elastic IPs that are no longer required.

Remediation

To release an Elastic IP address using the console: 1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/. 2. In the navigation pane, choose Elastic IPs. 3. Select the Elastic IP address, choose Actions, and then select Release addresses. Choose Release when prompted. More information: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html

Affected

['123456789123']

Analysis

No unused elastic IPs found

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

EBS Snapshots that are public are accessible by all AWS principals, and therefore anyone with an AWS account. To reduce the risk of sensitive data being exposed to unauthorised bearers only share EBS snapshots with trusted accounts.

Remediation

Remove public access from your EBS snapshots and only share them with trusted accounts.

Affected

['123456789123']

Analysis

No Public EBS Snapshots found

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

The reviewed AWS account contains an AWS AMI that is publicly accessible. When you make your AMIs publicly accessible, these become available in the Community AMIs where everyone with an AWS account can use them to launch EC2 instances. AMIs can contain snapshots of your applications (including their data), therefore exposing your snapshots in this manner is not advised. Ensure that your AWS AMIs are not publicly shared with the other AWS accounts in order to avoid exposing sensitive data. If required, you can share your images with specific AWS accounts without making them public

Remediation

Remove public access from your EC2 AMIs and only share them with trusted accounts.

Affected

['123456789123']

Analysis

No Public AMIs found

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. It is recommended that no Security Groups allows unrestricted ingress access to database ports, such as MySQL to port 3306, PostgreSQL to port 5432 and MSSQL to port 1433. Public access to remote database ports increases resource attack surface and unnecessarily raises the risk of resource compromise.

Remediation

Apply the principle of least privilege and only allow direct database traffic from a whitelist of trusted IP addresses

Affected

['123456789123']

Analysis

No security groups that allow database ingress traffic from 0.0.0.0/0 found

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Network Access Control Lists (NACLs) are stateless firewalls that allow you to control traffic flow in and out of your VPCs at the subnet layer. By default, NACLs are configured to allow all inbound and outbound traffic. NACLs provide a first line of defence against malicious network traffic and can provide defence in depth when used alongside strict security groups. Configuring NACLs can minimise the risk of a misconfigured security group or weak default security group exposing sensitive or vulnerable services to the internet and can provide a separation of responsibilities between developers and architecture teams. All Network Access Control Lists within the tested account are currently configured to allow all inbound and outbound traffic on all ports.

Remediation

Configure all NACLs applying the principle of least privilege and only allows the traffic required for the application or service to function. NOTE: Because NACLs are stateless return traffic on ephemeral unprivileged ports will need to be accounted for. More Information http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html

Affected

['123456789123']

Analysis

No Custom Network ACLs found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The affected Network Interfaces, are not attached to any instances and therefore are not being used. To maintain the hygiene of the environment, make maintenance and auditing easier and reduce cost, all old and temporary network interfaces should be removed.

Remediation

remove network interfaces that are not in use and no longer required.

Affected

['123456789123']

Analysis

No unused Network Interfaces found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The account under review contains running EC2 instances that were launched more than 180 days ago. One of the biggest benefits of cloud based infrastructure is to have mutable and short lived infrastructure that can scale and shrink with demand. Instances should be reprovisioned and rebooted periodically to ensure software and hardware resources are up to date and subject to the latest security patches. Additionally, long lived instances may no longer be adequately sized or no longer required, consuming resources and generating a cost to the company.

Remediation

Review the list of instances and ensure they subject to a regular patching policy and lifecycle management.

Affected

['123456789123']

Analysis

No instances older than 365 days found.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

The account under review contains EC2 instances that do not enforce the use of IMDSv2. To help protect against Server Side Request Forgery (SSRF) and related vulnerabilities, which could be leveraged by an attacker to query the metadata service to steal the AWS API credentials associated with the instance profile for the running EC2 instance, AWS introduced IMDSv2 which now protects all requests with additional session authentication.

Remediation

Configure IMDSv2 on all affected EC2 instances. See the following link for more information on how to transition to version 2 of the metadata service. More Information https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/configuring-instance-metadata-service.html

Affected

['123456789123']

Analysis

No failing instances found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The account under review contains running EC2 instances that are not managed by AWS Systems Manager. Systems Manager simplifies resource and application management, shortens the time to detect and resolve operational problems, and makes it easier to operate and manage your infrastructure at scale. AWS Systems Manager helps maintain security and compliance by scanning your instances against your patch, configuration, and custom policies. You can define patch baselines, maintain up-to-date anti-virus definitions, and enforce firewall policies. You can also remotely manage your servers at scale without manually logging in to each server. Systems Manager also provides a centralized store to manage your configuration data, whether it's plain text, such as database strings, or secrets, such as passwords. This allows you to separate your secrets and configuration data from code.

Remediation

It is recommended to configure all EC2 instances to be monitored by Systems Manager by installing and registering the SSM agent on the affected hosts. More Information https://docs.aws.amazon.com/systems-manager/latest/userguide/getting-started.html

Affected

['123456789123']

Analysis

No failing instances found.

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

To ensure the privacy of any data stored and processed by your EC2 instances it is recommended to enable encryption on EBS volumes. When you create an encrypted EBS volume and attach it to a supported instance type, the following types of data are encrypted: - Data at rest inside the volume - All data moving between the volume and the instance - All snapshots created from the volume - All volumes created from those snapshots

Remediation

There is no direct way to encrypt an existing unencrypted volume, or to remove encryption from an encrypted volume. However, you can migrate data between encrypted and unencrypted volumes. You can also apply a new encryption status while copying a snapshot: More information https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html

Affected

['123456789123']

Analysis

All EBS Volumes are encrypted.

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

To ensure the privacy of any data stored and processed by your EC2 instances it is recommended to enable encryption on EBS volumes. When you create an encrypted EBS volume and attach it to a supported instance type, the following types of data are encrypted: - Data at rest inside the volume - All data moving between the volume and the instance - All snapshots created from the volume - All volumes created from those snapshots

Remediation

There is no direct way to encrypt an existing unencrypted volume, or to remove encryption from an encrypted volume. However, you can migrate data between encrypted and unencrypted volumes. You can also apply a new encryption status while copying a snapshot: More information https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html

Affected

['123456789123']

Analysis

All EBS Snapshots are encrypted.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

With an active EBS backup strategy that takes volume snapshots daily or weekly, your data can grow rapidly and add unexpected charges to your bill. Since AWS EBS volumes snapshots are incremental, deleting previous (older) snapshots do not affect the ability to restore the volume data from later snapshots which allows you keep just the necessary backup data and lower your AWS monthly costs.

Remediation

Delete snapshots that are older than 30 days and consider implementing snapshot lifecycle management in AWS DLM

Affected

['123456789123']

Analysis

No EBS snapshots older than 30 days found

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Default VPCs created by AWS can be considered overly permissive and it is recommended to create your own VPCs instead. Default VPCs include an internet gateway, default security groups and default allow all NACLs which could result in accidental exposure of EC2 instances and data to the internet.

Remediation

Create your own VPCs as required applying the principle of least privilege to network access controls

Affected

['123456789123']

Analysis

No Default VPCs in use

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to remote server administration ports, such as SSH to port 22 and RDP to port 3389 . Public access to remote server administration ports, such as 22 and 3389, increases resource attack surface and unnecessarily raises the risk of resource compromise.

Remediation

Apply the principle of least privilege and only allow RDP and SSH traffic from a whitelist of trusted IPv6 addresses

Affected

['123456789123']

Analysis

No security groups that allow remote server administration ingress traffic from 0.0.0.0/0 found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

User Data can be specified when launching an ec2 instance. Examples include specifying parameters for configuring the instance or including a simple script. The user data is not protected by authentication or cryptographic methods. Therefore, sensitive data, such as passwords or long-lived encryption keys should not be stored as user data.

Remediation

From the Console 1. Login to AWS Console using https://console.aws.amazon.com 2. Click All services and click EC2 under Compute. 3. Click on Instances. 4. If the instance is currently running, stop the instance first. Note: ensure there is no negative impact from stopping the instance prior to stopping the instance. 5. For each instance, click Actions -> Instance Settings -> Edit user data 6. For each instance, edit the user data to ensure there are no secrets or sensitive data stored. A Secret Management solution such as AWS Secrets Manager can be used here as a more secure mechanism of storing necessary sensitive data. 7. Repeat this remediation for all the other AWS regions. Note: If the ec2 instances are created via automation or infrastructure-as-code, edit the user data in those pipelines and code.

Affected

['123456789123']

Analysis

No user data found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Enabling detailed monitoring provides enhanced monitoring and granular insights into EC2 instance metrics. Not having detailed monitoring enabled may limit the ability to troubleshoot performance and security related issues effectively. Data is available in 1-minute periods. For the instances where you've enabled detailed monitoring, you can also get aggregated data across groups of similar instances. You are charged per metric that is sent to CloudWatch. You are not charged for data storage. Due to this added cost it is recommended that you only enable this on critical instances.

Remediation

Enable detailed monitoring for appropriate instances. NOTE: Additional costs are incurred when detailed monitoring is enabled.

Affected

['123456789123']

Analysis

No failing instances found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Affected Instances have a Public IP Address Attached

Remediation

Review Public IPs to ensure an appropriate Security Group has been applied applying the principle of least privilege.

Affected

['123456789123']

Analysis

No Public IPs found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The affected EC2 Instances are currently in a stopped state. To maintain account hygiene and reduce potential storage and Elastic IP costs is recommended to terminate all stopped instances that are no longer required. the CIS benchmark recommends that all instances stopped for 90 days are deleted.

Remediation

Terminate the affected instances if no longer requried.

Affected

['123456789123']

Analysis

No stopped instances found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The naming convention for AMI (Amazon Machine Images) should be documented and followed for any AMI's created. The majority of AWS resources can be named and tagged. Most organizations have already created standardize naming conventions, and have existing rules in effect. They simply need to extend that for all AWS cloud resources to include Amazon Machine Images (AMI)

Remediation

If the AMI Name for an AMI doesn't follow Organization policy Perform the following to copy and rename the AMI: From the Console: 1. Login to the EC2 console at https://console.aws.amazon.com/ec2/. 2. In the left pane click Images, click AMIs. 3. Select the AMI that does not comply to the naming policy. 4. Click on Actions. 5. Click on Copy AMI

Affected

['123456789123']

Analysis

No AMI images found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Amazon Machine Images should utilize EBS Encrypted snapshots AMIs backed by EBS snapshots should use EBS encryption. Snapshot volumes can be encrypted and attached to an AMI.

Remediation

Perform the following to encrypt AMI EBS Snapshots: From the Console: 1. Login to the EC2 console at https://console.aws.amazon.com/ec2/. 2. In the left pane click on AMIs. 3. Select the AMI that does not comply to the encryption policy. 4. Click on Actions. 5. Click on Copy AMI.

Affected

['123456789123']

Analysis

No unencrpyted AMI image snapshots found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Identify any unused Elastic Block Store (EBS) volumes in your AWS account and remove them. Any Elastic Block Store volume created in your AWS account contains data, regardless of being used or not. If you have EBS volumes (other than root volumes) that are unattached to an EC2 instance they should be removed to prevent unauthorized access or data leak to any sensitive data on these volumes. Once a EBS volume is deleted, the data will be lost. If this is data that you need to archive, create an encrypted EBS snapshot before deleting them.

Remediation

From Console: 1. Login to the EC2 console using https://console.aws.amazon.com/ec2/ 2. Under Elastic Block Store, click Volumes. 3. Find the State column 4. Sort by Available 5. Select the Volume that you want to delete. 6. Click Actions, Delete volume, Yes, Delete Note: EBS volumes can be in different regions. Make sure to review all the regions being utilized.

Affected

['123456789123']

Analysis

No unused volumes found

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

When an EC2 instance is launched a specified custom security group should be assigned to the instance. When an EC2 Instance is launched the default security group is automatically assigned. In error a lot of instances are launched in this way, and if the default security group is configured to allow unrestricted access, it will increase the attack footprint allowing the opportunity for malicious activity.

Remediation

From the Console: 1. Login to EC2 using https://console.aws.amazon.com/ec2/ 2. On the left Click Network & Security, click Security Groups. 3. Select Security Groups 4. Click on the default Security Group you want to review. 5. Click Actions, View details. 6. Select the Inbound rules tab 7. Click on Edit inbound rules 8. Click on Delete for all the rules listed 9. Once there are no rules listed click on 'Save rules` 10. Repeat steps no. 3 – 8 for any other default security groups listed.

Affected

['123456789123']

Analysis

Default security groups are not in use

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This rule ensures that Amazon Elastic Block Store volumes that are attached to Amazon Elastic Compute Cloud (Amazon EC2) instances are marked for deletion when an instance is terminated. If an Amazon EBS volume isn’t deleted when the instance that it’s attached to is terminated, it may violate the concept of least functionality.

Remediation

From the CLI 1. Run the modify-instance-attribute command using the list of instances collected in the audit. <code>aws ec2 modify-instance-attribute --instance-id i-123456abcdefghi0 --block-device-mappings "[{"DeviceName":"/dev/sda","Ebs":{"DeleteOnTermination":true}}]"</code> 2. Repeat steps no. 1 with the other instances discovered in all AWS regions.

Affected

['123456789123']

Analysis

No EBS volumes without Delete on termination enabled found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks whether the assignment of public IPs in Amazon Virtual Private Cloud (Amazon VPC) subnets have MapPublicIpOnLaunch set to FALSE. The control passes if the flag is set to FALSE. All subnets have an attribute that determines whether a network interface created in the subnet automatically receives a public IPv4 address. Instances that are launched into subnets that have this attribute enabled have a public IP address assigned to their primary network interface

Remediation

To configure a subnet to not assign public IP addresses, see Modify the public IPv4 addressing attribute for your subnet in the Amazon VPC User Guide. Clear the check box for Enable auto-assign public IPv4 address. More Information https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html#subnet-public-ip

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks whether there are any unused network access control lists (network ACLs) in your virtual private cloud (VPC). The control fails if the network ACL isn't associated with a subnet. The control doesn't generate findings for an unused default network ACL. The control checks the item configuration of the resource AWS::EC2::NetworkAcl and determines the relationships of the network ACL. If the only relationship is the VPC of the network ACL, the control fails. If other relationships are listed, then the control passes.

Remediation

For instructions on deleting an unused network ACL, see Deleting a network ACL in the Amazon VPC User Guide. You can't delete the default network ACL or an ACL that is associated with subnets. More Information https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#DeleteNetworkACL

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks if EC2 transit gateways are automatically accepting shared VPC attachments. This control fails for a transit gateway that automatically accepts shared VPC attachment requests. Turning on AutoAcceptSharedAttachments configures a transit gateway to automatically accept any cross-account VPC attachment requests without verifying the request or the account the attachment is originating from. To follow the best practices of authorization and authentication, we recommended turning off this feature to ensure that only authorized VPC attachment requests are accepted.

Remediation

To modify a transit gateway, see Modify a transit gateway in the Amazon VPC Developer Guide.

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks whether the virtualization type of an EC2 instance is paravirtual. The control fails if the virtualizationType of the EC2 instance is set to paravirtual. Linux Amazon Machine Images (AMIs) use one of two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM). The main differences between PV and HVM AMIs are the way in which they boot and whether they can take advantage of special hardware extensions (CPU, network, and storage) for better performance. Historically, PV guests had better performance than HVM guests in many cases, but because of enhancements in HVM virtualization and the availability of PV drivers for HVM AMIs, this is no longer true. For more information, see Linux AMI virtualization types in the Amazon EC2 User Guide.

Remediation

To update an EC2 instance to a new instance type, see Change the instance type in the Amazon EC2 User Guide. More Information https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks whether an Amazon EC2 transit gateway attachment has tags. The control fails if the transit gateway attachment doesn’t have any tag keys. If the parameter requiredTagKeys isn't provided, the control only checks for the existence of a tag key and fails if the transit gateway attachment isn't tagged with any key. System tags, which are automatically applied and begin with aws:, are ignored. A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.

Remediation

To add tags to an EC2 transit gateway attachment, see Tag your Amazon EC2 resources in the Amazon EC2 User Guide. More Information https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks whether an Amazon EC2 transit gateway route table has tags with the specific keys defined in the parameter requiredTagKeys. The control fails if the transit gateway route table doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter requiredTagKeys. If the parameter requiredTagKeys isn't provided, the control only checks for the existence of a tag key and fails if the transit gateway route table isn't tagged with any key. System tags, which are automatically applied and begin with aws:, are ignored. A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.

Remediation

To add tags to an EC2 transit gateway route table, see Tag your Amazon EC2 resources in the Amazon EC2 User Guide. More Information https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console

Affected

['123456789123']

Analysis

No issues found

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Common Internet File System (CIFS) is a network file-sharing protocol that allows systems to share files over a network. However, unrestricted CIFS access can expose your data to unauthorized users, leading to potential security risks. It is important to restrict CIFS access to only trusted networks and users to prevent unauthorized access and data breaches. Allowing unrestricted CIFS access can lead to significant security vulnerabilities, as it may allow unauthorized users to access sensitive files and data. By restricting CIFS access to known and trusted networks, you can minimize the risk of unauthorized access and protect sensitive data from exposure to potential attackers. Implementing proper network access controls and permissions is essential for maintaining the security and integrity of your file-sharing systems. Restricting CIFS access may require additional configuration and management effort. However, the benefits of enhanced security and reduced risk of unauthorized access to sensitive data far outweigh the potential challenges.

Remediation

Apply the principle of least privilege and only allow RDP and SSH traffic from a whitelist of trusted IPv6 addresses

Affected

['123456789123']

Analysis

No security groups that allow remote CIFS ingress traffic from 0.0.0.0/0 or ::/0 found

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Ensure that your AMIs are not older than 90 days. Using up-to-date AMIs will provide many benefits from OS updates and security patches helping to ensure reliability, security and compliance.

Remediation

Remove and replace AMI images that are older than 90 days.

Affected

['123456789123']

Analysis

No AMIs older than 90 days found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Ensure that all base AMIs utilized are approved for use by your organization. An approved AMI is a base EC2 machine image that is a pre-configured OS configured to run your application. Using approved AMIs helps enforce consistency and security.

Remediation

Review the list of Images and remove any that are not approved

Affected

['123456789123']

Analysis

No AMIs older than 90 days found

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Amazon S3 provides a variety of no, or low, cost encryption options to protect data at rest. Encrypting data at rest reduces the likelihood that it is unintentionally exposed and can nullify the impact of disclosure if the encryption remains unbroken.

Remediation

Ensure all S3 buckets employ encryption-at-rest. S3 bucket encryption only applies to objects as they are placed in the bucket. Enabling S3 bucket encryption does not encrypt objects previously stored within the bucket.

Affected

['123456789123']

Analysis

All buckets have server side encryption enabled.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Amazon S3 provides Block public access (bucket settings) and Block public access (account settings) to help you manage public access to Amazon S3 resources. By default, S3 buckets and objects are created with public access disabled. However, an IAM principal with sufficient S3 permissions can enable public access at the bucket and/or object level. While enabled, Block public access (bucket settings) prevents an individual bucket, and its contained objects, from becoming publicly accessible. Similarly, Block public access (account settings) prevents all buckets, and contained objects, from becoming publicly accessible across the entire account. Amazon S3 Block public access (bucket settings) prevents the accidental or malicious public exposure of data contained within the respective bucket(s). Amazon S3 Block public access (account settings) prevents the accidental or malicious public exposure of data contained within all buckets of the respective AWS account. Whether blocking public access to all or some buckets is an organizational decision that should be based on data sensitivity, least privilege, and use case.

Remediation

Ensure that S3 Buckets are configured with Block public access

Affected

['123456789123']

Analysis

All Buckets block public access.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

The affected S3 buckets have an Access Control List (ACL) configured which grant public acces to objects. Either list or read access. Public S3 buckets can be accessed without authentication and increase teh risk of senstivie data being exposed to unauthorised network bearers.

Remediation

Review the affected buckets and confirm that public access to objects is required.

Affected

['123456789123']

Analysis

No buckets were found which grant public access via an ACL.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

The affected S3 buckets have a bucket policy configured which grants public acces to objects, possibly for S3 static website hosting. Public S3 buckets can be accessed without authentication and increase teh risk of senstivie data being exposed to unauthorised network bearers.

Remediation

Review the affected buckets and confirm that public access to objects is required. and update the bucket policy accordingly

Affected

['123456789123']

Analysis

No buckets were found which grant public access via an ACL.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.5

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:L

Description

S3 bucket policies allow AWS services to access the bucket without adequate conditional context restrictions. Without any conditional restrictions, buckets are vulnerable to the confused deputy problem which could allow unauthorised services in other AWS accounts indirect access to the affected bucket. When an AWS service principal from a calling service (CloudTrail for example) is accessing a resource in S3, the bucket’s resource policy is only authorizing the AWS service principal, and not the actor who configured the calling service. For example, an S3 bucket that trusts the CloudTrail service principal with no conditions could receive CloudTrail logs from the AWS accounts that a trusted admin configures, but also CloudTrail logs from an unauthorized actor in their AWS account, if they know the name of the S3 bucket.

Remediation

it is recommended that S3 bucket policies that allows access to other AWS services contain conditional access statements. Using conditions and specifying the full ARN of the allowed resources would restrict access to only legitimate resources and reduce the potential for abuse. Specifying the full ARN, including region and resource name, will prevent attackers from leveraging other AWS services to access potentially sensitive data within your S3 buckets. Where appropriate use the following conditional contexts following the principal of least privilege to effectively limit the scope of bucket policies and prevent unintended access opportunities: - aws:SourceArn - aws:SourceAccount - aws:SourceOrgID - aws:SourceOrgPaths More Information https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html#cross-service-confused-deputy-prevention

Affected

['123456789123']

Analysis

No failing buckets found.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 8.1

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Description

Ensure that your Amazon Lambda functions don't have administrative permissions potentially giving the function access to all AWS cloud services and resources. In order to promote the Principle of Least Privilege (POLP) and provide your functions the minimal amount of access required to perform their tasks the right IAM execution role associated with the function should be used. Instead of providing administrative permissions you should grant the role the necessary permissions that the function really needs.

Remediation

From the Console 1. Login in to the AWS Console using https://console.aws.amazon.com/lambda/ 2. In the left column, under AWS Lambda, click Functions. 3. Under Function name click on the name of the function that you want to remediate 4. Click the Configuration tab 5. Click on Permissions in the left column. 6. In the Execution role section, click the Edit 7. Edit basic settings configuration page: - associate the function with an existing, compliant IAM role - click Use an existing role from the Execution role - select the required role from the Existing role dropdown - click Save OR - apply a new execution role to your Lambda function - click Create a new role from AWS policy templates - Provide a name for the new role based on org policy - select only the necessary permission set(s) from the Policy templates - optional dropdown list. - click Save 8. Repeat steps for each Lambda function within the current region that failed the Audit.

Affected

['123456789123']

Analysis

No Admin Lambda Functions Found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Every Lambda function should have a one to one IAM execution role and the roles should not be shared between functions. The Principle of Least Privilege means that any Lambda function should have the minimal amount of access required to perform its tasks. In order to accomplish this Lambda functions should not share IAM Execution roles.

Remediation

From the Console 1. Login to the AWS console using https://console.aws.amazon.com/lambda/ 2. In the left column, under AWS Lambda, click Functions. 3. Under Function name click on the name of the function that you want to change/update. 4. Click the Configuration tab 5. Under General configuration on the left column, click Permissions. 6. Under the Execution role section, click Edit. 7. Scroll down to Execution role To use an existing IAM role

Affected

['123456789123']

Analysis

No issues found

Impact: HIGH

Probability: HIGH

Status: PASS

CVSS: Score: 8.1

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Description

A publicly accessible Amazon Lambda function is open to the public and can be reviewed by anyone. To protect against unauthorized users that are sending requests to invoke these functions they need to be changed so they are not exposed to the public. Allowing anyone to invoke and run your Amazon Lambda functions can lead to data exposure, data loss, and unexpected charges on your AWS bill.

Remediation

From the Console 1. Login to the AWS Console using https://console.aws.amazon.com/lambda/. 2. In the left column, under AWS Lambda, click Functions. 3. Under Function name click on the name of the function that you want to review 4. Click the Configuration tab 5. In the left column, click Permissions. 6. In the Resource-based policy section, perform the following actions: • Under Policy statements • Select the policy statement that allows anonymous access • Click Delete to remove the non-compliant statement from the resource-based policy attached • Within the Delete statement confirmation box, click Remove • Click Add permissions to add a new policy statement that grants permissions to a trusted entity only. • On the Add permissions page configure the new policy statement to grant access to another AWS account, IAM user, IAM role, or to another AWS service. • Click Save 7. Repeat steps no. 2 – 6 for each Lambda function that fails the Audit above, within the current region. 8. Repeat this Audit for all the other AWS regions.

Affected

['123456789123']

Analysis

No issues found

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.5

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:L

Description

Lambda policies allow AWS services to access the function without adequate conditional context restrictions. Without any conditional restrictions, functions are vulnerable to the confused deputy problem which could allow unauthorised services in other AWS accounts indirect access to the affected function. When an AWS service principal from a calling service (CloudWatch for example) is accessing a resource in AWS Lambda, the function’s resource policy is only authorizing the AWS service principal, and not the actor who configured the calling service. For example, an Lambda function that trusts the CloudTrail service principal with no conditions could receive CloudTrail logs from the AWS accounts that a trusted admin configures, but also CloudTrail logs from an unauthorized actor in their AWS account, if they know the name of the Lambda function.

Remediation

It is recommended that Lambda function policies that allows access to other AWS services contain conditional access statements. Using conditions and specifying the full ARN of the allowed resources would restrict access to only legitimate resources and reduce the potential for abuse. Specifying the full ARN, including region and resource name, will prevent attackers from leveraging other AWS services to access potentially sensitive data within your Lambda functions. Where appropriate use the following conditional contexts following the principal of least privilege to effectively limit the scope of function policies and prevent unintended access opportunities: - aws:SourceArn - aws:SourceAccount - aws:SourceOrgID - aws:SourceOrgPaths More Information https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html#cross-service-confused-deputy-prevention

Affected

['123456789123']

Analysis

No failing functions found.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 4.6

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L

Description

Ensure that all your Amazon Lambda functions are configured to allow access only to trusted AWS accounts in order to protect against unauthorized cross-account access. Allowing unknown (unauthorized) AWS accounts to invoke your Amazon Lambda functions can lead to data exposure and data loss. To prevent any unauthorized invocation requests for your Lambda functions, restrict access only to trusted AWS accounts

Remediation

From the Console 1. Login to the AWS Console using https://console.aws.amazon.com/lambda/. 2. In the left column, under AWS Lambda, click Functions. 3. Under Function name click on the name of the function that you want to review 4. Click the Configuration tab 5. In the left column, click Permissions. 6. In the Resource-based policy statements section, select the policy statement that allows the unknown AWS Account cross-account access 7. Click Edit 8. On the Edit permissions page, replace or remove the AWS Account(s) ARN of the unauthorized principal in the Principal box 9. Click Save 10. Repeat steps for each Lambda function that failed the Audit

Affected

['123456789123']

Analysis

No issues found

Impact: LOW

Probability: MEDIUM

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Always using a recent version of the execution environment configured for your Amazon Lambda functions adheres to best practices for the newest software features, the latest security patches and bug fixes, and performance and reliability. When you execute your Lambda functions using recent versions of the implemented runtime environment, you should benefit from new features and enhancements, better security, along with performance and reliability.

Remediation

From the Console 1. Login to the AWS Console using https://console.aws.amazon.com/lambda/. 2. In the left column, under AWS Lambda, click Functions. 3. Under Function name click on the name of the function that you want to review 4. Click Code tab 5. Go to the Runtime settings section. 6. Click Edit 7. On the Edit runtime settings page, select the latest supported version of the runtime environment from the dropdown list. **Note - make sure the correct architecture is also selected. 8. Click Save 9. Select the Code tab 10. Click Test from the Code source section. 11. Once the testing is completed, the execution result of your Lambda function will be listed 12. Repeat steps for each Lambda function that failed the Audit within the current region.

Affected

['123456789123']

Analysis

No issues found

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Description

The account under review contains SSL/TLS certificates that do not have Transparency logging enabled. Disabling Transparency Logging may result in browsers not trusting your certificate. As of April 30 2018, Google Chrome no longer trusts public SSL/TLS certificates that are not recorded in a certificate transparency log. Transparency Logging should be enabled as a best practice.

Remediation

Enable Certificate Transparancy Logging on all certificates.

Affected

['123456789123']

Analysis

No issues found.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Description

The account under review contains SSL/TLS certificates that have expired. Expired certificates will often result in users not being able to connect to your service resulting in loss of availability.

Remediation

Monitor certificate expiration and take action to renew; replace or remove expired certificates as requried. AWS Config can be used to monitor your account for expired certificates with the managed rule acm-certificate-expiration-check.

Affected

['123456789123']

Analysis

No expired certificates found.

Impact: HIGH

Probability: LOW

Status: PASS

CVSS: Score: 7.4

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Description

This control checks whether RSA certificates managed by AWS Certificate Manager use a key length of at least 2,048 bits. The control fails if the key length is smaller than 2,048 bits. The strength of encryption directly correlates with key size. We recommend key lengths of at least 2,048 bits to protect your AWS resources as computing power becomes less expensive and servers become more advanced.

Remediation

The minimum key length for RSA certificates issued by ACM is already 2,048 bits. For instructions on issuing new RSA certificates with ACM, see Issuing and managing certificates in the AWS Certificate Manager User Guide. While ACM allows you to import certificates with shorter key lengths, you must use keys of at least 2,048 bits to pass this control. You can't change the key length after importing a certificate. Instead, you must delete certificates with a key length smaller than 2,048 bits. For more information about importing certificates into ACM, see Prerequisites for importing certificates in the AWS Certificate Manager User Guide.

Affected

['123456789123']

Analysis

No vulnerable certificates found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks whether an AWS Certificate Manager (ACM) certificate has tags with the specific keys defined in the parameter requiredTagKeys. The control fails if the certificate doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter requiredTagKeys. If the parameter requiredTagKeys isn't provided, the control only checks for the existence of a tag key and fails if the certificate isn't tagged with any key. System tags, which are automatically applied and begin with aws:, are ignored. A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.

Remediation

To add tags to an ACM certificate, see Tagging AWS Certificate Manager certificates in the AWS Certificate Manager User Guide. More Information: https://docs.aws.amazon.com/acm/latest/userguide/tags.html

Affected

['123456789123']

Analysis

No vulnerable certificates found.

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Ensure that encryption at rest is enabled for Amazon Athena query results stored in Amazon S3 in order to secure data and meet compliance requirements for data-at-rest encryption. If not enabled sensitive information at rest is not protected.

Remediation

Enable Encryption for the affected Work Groups

Affected

['123456789123']

Analysis

No Athena Work Groups found that do not utilise encryption

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Remediation

Affected

['123456789123']

Analysis

Indexes are enabled in all regions

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The affected CloudFormation stacks do not have termination protection enabled. Without termination protection critical cloudformation stacks can be accidently deleted resulting in potential loss of data integrity and availability

Remediation

Ensure termination protection is enabled for the CloudFormation stacks. More Information https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-protect-stacks.html

Affected

['123456789123']

Analysis

All Stacks have termination protection enabled

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Passing a role to CloudFormation stacks may result in privilege escalation because IAM users with privileges within the CloudFormation scope implicitly inherit the stack's role's permissions. Consequently, it should be ensured that the IAM privileges assigned to the stack's role follow the principle of least privilege.

Remediation

Review the affected roles and ensure the principal of least privilege has been applied

Affected

['123456789123']

Analysis

All Stacks have termination protection enabled

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Description

AWS CloudTrail is a web service that records AWS API calls for your account and delivers log files to you. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Console, SDKs, command line tools, and higher-level AWS services (such as CloudFormation).

Remediation

Enable CloudTrail in all regions

Affected

['management-events']

Analysis

The affected trails are multi region enabled.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

CloudTrail log file validation creates a digitally signed digest file containing a hash of each log that CloudTrail writes to S3. These digest files can be used to determine whether a log file was changed, deleted, or unchanged after CloudTrail delivered the log. It is recommended that file validation be enabled on all CloudTrails. Enabling log file validation will provide additional integrity checking of CloudTrail logs.

Remediation

Enabled log file validation on all your trails

Affected

['123456789123']

Analysis

Log file validation is enabled on all trails.

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

CloudTrail logs a record of every API call made in your AWS account. These logs file are stored in an S3 bucket. It is recommended that the bucket policy or access control list (ACL) applied to the S3 bucket that CloudTrail logs to prevent public access to the CloudTrail logs. Allowing public access to CloudTrail log content may aid an adversary in identifying weaknesses in the affected account's use or configuration.

Remediation

Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible

Affected

['123456789123']

Analysis

No public cloud trail buckets found.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Description

AWS CloudTrail is a web service that records AWS API calls made in a given AWS account. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. CloudTrail uses Amazon S3 for log file storage and delivery, so log files are stored durably. In addition to capturing CloudTrail logs within a specified S3 bucket for long term analysis, realtime analysis can be performed by configuring CloudTrail to send logs to CloudWatch Logs. For a trail that is enabled in all regions in an account, CloudTrail sends log files from all those regions to a CloudWatch Logs log group. It is recommended that CloudTrail logs be sent to CloudWatch Logs. Note: The intent of this recommendation is to ensure AWS account activity is being captured, monitored, and appropriately alarmed on. CloudWatch Logs is a native way to accomplish this using AWS services but does not preclude the use of an alternate solution. Sending CloudTrail logs to CloudWatch Logs will facilitate real-time and historic activity logging based on user, API, resource, and IP address, and provides opportunity to establish alarms and notifications for anomalous or sensitivity account activity.

Remediation

Ensure CloudTrail trails are integrated with CloudWatch Logs

Affected

['123456789123']

Analysis

All trails are integrated with CloudWatch Logs.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

S3 Bucket Access Logging generates a log that contains access records for each request made to your S3 bucket. An access log record contains details about the request, such as the request type, the resources specified in the request worked, and the time and date the request was processed. It is recommended that bucket access logging be enabled on the CloudTrail S3 bucket. By enabling S3 bucket logging on target S3 buckets, it is possible to capture all events which may affect objects within any target buckets. Configuring logs to be placed in a separate bucket allows access to log information which can be useful in security and incident response workflows.

Remediation

Ensure the CloudTrail S3 bucket has access logging is enabled

Affected

['123456789123']

Analysis

S3 bucket access logging is enabled.

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

AWS CloudTrail is a web service that records AWS API calls for an account and makes those logs available to users and resources in accordance with IAM policies. AWS Key Management Service (KMS) is a managed service that helps create and control the encryption keys used to encrypt account data, and uses Hardware Security Modules (HSMs) to protect the security of encryption keys. CloudTrail logs can be configured to leverage server side encryption (SSE) and KMS customer created master keys (CMK) to further protect CloudTrail logs. It is recommended that CloudTrail be configured to use SSE-KMS. Configuring CloudTrail to use SSE-KMS provides additional confidentiality controls on log data as a given user must have S3 read permission on the corresponding log bucket and must be granted decrypt permission by the CMK policy.

Remediation

Configure CloudTrail to use SSE-KMS for encryption at rest.

Affected

['123456789123']

Analysis

CloudTrail logs are encrypted at rest with KMS CMKs.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The account under review contains CloudWatch alarms that have not been configured with any actions. To enable effective active monitoring of the account for suspicious activities all alarms should be configured with at least one action, normally raising a notification via the AWS SNS.

Remediation

Ensure all CloudWatch alarms are configured with at least one action. More Information: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html

Affected

['123456789123']

Analysis

All CloudWatch alarms have actions configured.

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 4.0

CVSS: Vector: AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Description

Deletion protection can keep your table from being accidentally deleted. For all active production tables, the best practice is to turn on the deletion protection setting and protect these tables from accidental deletion. This also applies to global replicas. When serving application development use cases, if the table management workflow includes frequently deleting and recreating development and staging tables then the deletion protection setting can be turned off. This will allow intentional deletion of such tables by authorized IAM principals.

Remediation

You can protect a table from accidental deletion with the deletion protection property. Enabling this property for tables helps ensure that tables do not get accidentally deleted during regular table management operations by your administrators. This will help prevent disruption to your normal business operations. More Information https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.Basics.html#WorkingWithTables.Basics.DeletionProtection

Affected

['123456789123']

Analysis

All Tables have Deletion Protection Enabled

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Remediation

Delete any unysed Dynamo DB tables.

Affected

['123456789123']

Analysis

No unused dynamo DB tables found.

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 4.0

CVSS: Vector: AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Description

Point-in-time recovery helps protect your DynamoDB tables from accidental write or delete operations. With point-in-time recovery, you don't have to worry about creating, maintaining, or scheduling on-demand backups. For example, suppose that a test script writes accidentally to a production DynamoDB table. With point-in-time recovery, you can restore that table to any point in time during the last 35 days. DynamoDB maintains incremental backups of your table.

Remediation

Consider enabled Point In Time Recovery for important Tables. More Informaiton https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html

Affected

['123456789123']

Analysis

No unused dynamo DB tables found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Amazon ECR image scanning helps in identifying software vulnerabilities in your container images. Amazon ECR uses the Common Vulnerabilities and Exposures (CVEs) database from the open source CoreOS Clair project and provides you with a list of scan findings. You can review the scan findings for information about the security of the container images that are being deployed. You can manually scan container images stored in Amazon ECR, or you can configure your repositories to scan images when you push them to a repository. The last completed image scan findings can be retrieved for each image. Amazon ECR sends an event to Amazon EventBridge (formerly called CloudWatch Events) When a new repository is configured to scan on push, all new images pushed to the repository will be scanned. Results from the last completed image scan can then be retrieved.

Remediation

Enable scan on push for all repositories in the affected account. More Information: https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html#scanning-repository

Affected

['123456789123']

Analysis

No failing repositories found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The affected Repositories do not have a Lifecycle policy, Amazon ECR repositories run the risk of retaining a larfe number of container images, resulting in unnecessary cost.

Remediation

It is recomended to review the affected repositories and apply a suitable lifecycle policy to minimise storage requirements and costs More Information https://docs.aws.amazon.com/AmazonECR/latest/userguide/LifecyclePolicies.html

Affected

['123456789123']

Analysis

No failing repositories found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks whether a private ECR repository has tag immutability enabled. This control fails if a private ECR repository has tag immutability disabled. This rule passes if tag immutability is enabled and has the value IMMUTABLE. Amazon ECR Tag Immutability enables customers to rely on the descriptive tags of an image as a reliable mechanism to track and uniquely identify images. An immutable tag is static, which means each tag refers to a unique image. This improves reliability and scalability as the use of a static tag will always result in the same image being deployed. When configured, tag immutability prevents the tags from being overridden, which reduces the attack surface.

Remediation

To create a repository with immutable tags configured or to update the image tag mutability settings for an existing repository, see Image tag mutability in the Amazon Elastic Container Registry User Guide. More Information https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-tag-mutability.html

Affected

['123456789123']

Analysis

No failing repositories found

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

EFS data should be encrypted at rest using AWS KMS (Key Management Service). Data should be encrypted at rest to reduce the risk of a data breach via direct access to the storage device.

Remediation

Enable AWS KMS encryption for all Elastic File Systems.

Affected

['123456789123']

Analysis

All file are encrypted.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

internet facing Elastic Load Balancers expose additional attack surface to potentiall malicious actors.

Remediation

Apply Security Groups to your load balancers using the principle of least privilege by only allowing access to services from a white list of trusted IP addresses.

Affected

['123456789123']

Analysis

No internet facing load balancers found

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.4

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N

Description

The account under review contains Elastic Load Balancers (ELBs) that accept connection over unencrypted HTTP listeners To protect the Privacy and Integrity of data in transit between end users and your AWS hosted services it is recommended to use encrypted HTTPS listeners.

Remediation

Disable existing HTTP listeners and replace them with HTTPS listeners as required. You can also configure HTTP listeners to redirect to HTTPS if preferred. More information,nhttps://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html

Affected

['123456789123']

Analysis

No HTTP listeners found.

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 7.4

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Description

The affected ALBs have an SSL/TLS protected listeners which are insufficiently protected against known cryptographic attacks which could allow a Man in the Middle (MitM) attacker to recover plain text from an encrypted SSL/TLS connection. To exploit this vulnerability, an attacker must be suitably positioned to intercept and modify the victims network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defences such as switched networks are not sufficient to prevent this. An attacker situated in the users ISP or the applications hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internets core infrastructure. Data submitted over an unencrypted connection is vulnerable to interception and can be tampered with. This could result in users sessions being compromised, credentials being captured, and sensitive and/or personal information being exposed.

Remediation

In short, the following summarises SSL/TLS hardening options that should be considered: - Use 2048-bit RSA private keys and 256bit ECDSA private keys - Renew certificates on an annual basis - Use strong certificate signature algorithms (sha256) - Disable SSL v2, SSL v3,TLS v1.0 and TLS v1.1 - support TLS 1.2 and 1.3. - Disable insecure cipher suites (ADH, Null, Export, RC4 and 3DES) - Support Forward Secrecy (ECDHE) - Use strong key exchange algorithms (ECDHE and DHE > 2048-bit) - Ensure the underlying software is patched and up to date - Encrypt everything and eliminate mixed HTTP/HTTPS content - Implement HTTP Strict Transport Security (HSTS) to ensure secure connections cannot be downgraded to an insecure connection. - Support TLS_FALLBACK_SCSV to prevent protocol downgrade attacks - Disable SSL/TLS Compression. Note: Implementing a strong SSL/TLS configuration can result in user agents no longer being able to connect to your site due to lack of compatible cipher suites.

Affected

['123456789123']

Analysis

No TLS issues found.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The AWS account under review is using Application Load Balancers (ALBs) that do not have protection against HTTP Request Smuggling attacks enabled. HTTP request smuggling is a technique for interfering with the way a web site processes sequences of HTTP requests that are received from one or more users. Request smuggling vulnerabilities are often critical in nature, allowing an attacker to bypass security controls, gain unauthorized access to sensitive data, and directly compromise other application users. Due to the highly distributed and segmented nature of cloud-based applications HTTP request smuggling vulnerabilities have been discovered in AWS services. Although AWS CloudFront will protect against HTTP request Smuggling by default, protection in ALBs is not enabled by default and has to be configured. More information https://portswigger.net/web-security/request-smuggling

Remediation

To help protection against HTTP Request Smuggling attacks enable the "Drop Invalid Header Fields" attribute for all affected ALBs. Note: If your application is using nonstandard headers this may break your applications, It seems AWS considers standard headers to only include alphanumeric characters and hyphens, but it is hard to find exactly what AWS considers to be a standard header as documentation is lacking.

Affected

['123456789123']

Analysis

All Application Load Balancers are configured to drop invalid HTTP headers.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The account under review contains classic load balancers that do not have Desync Mitigation mode enabled. To help protect against HTTP Desync attacks it is recommended to enable Desync Mitigation mode and set it to “strictest”. Desync mitigation mode protects your application from issues due to HTTP Desync. The load balancer classifies each request based on its threat level, allows safe requests, and then mitigates risk as specified by the mitigation mode that you specify. The desync mitigation modes are monitor, defensive, and strictest. The default is the defensive mode, which provides durable mitigation against HTTP desync while maintaining the availability of your application. You can switch to strictest mode to ensure that your application receives only requests that comply with RFC 7230.

Remediation

Configured Desync Mitigation Mode to "Strictest" or "Defensive" for all affected ELBs. More Information https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/config-desync-mitigation-mode.html

Affected

['123456789123']

Analysis

All Application Load Balancers have HTTP desync mitigation mode enabled.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The AWS account under review has Elastic Load Balancers (ELB) in use that do not have deletion protection enabled. For an extra layer of protection against human error by preventing your load balancers from being deleted accidentally, you can enable deletion protection. By default, deletion protection is disabled.

Remediation

To enable deletion protection using the console 1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/. 2. On the navigation pane, under LOAD BALANCING, choose Load Balancers. 3. Select the load balancer. 4. On the Description tab, choose Edit attributes. 5. On the Edit load balancer attributes page, select Enable for Delete Protection, and then choose Save. 6. Choose Save. To disable deletion protection using the console 1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/. 2. On the navigation pane, under LOAD BALANCING, choose Load Balancers. 3. Select the load balancer. 4. On the Description tab, choose Edit attributes. 5. On the Edit load balancer attributes page, clear Enable for Delete Protection, and then choose Save. 6. Choose Save. NOTE: If you enable deletion protection for your load balancer, you must disable it before you can delete the load balancer. More Information https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#deletion-protection

Affected

['123456789123']

Analysis

All Application Load Balancers have Deletion Protection enabled.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

High Risk Guardduty findings have been found within your AWS account. GuardDuty is an AWS threat detection service that detects compromised access keys, EC2 instances, and more, allowing you to identify malicious activity and unauthorised behaviour within your account.

Remediation

Review all outstanding Guardduty findins and investigate, respond and remediate as required. It is reccomended to review findings on a regular basis.

Affected

['123456789123']

Analysis

No issues found

Impact: HIGH

Probability: LOW

Status: PASS

CVSS: Score: 5.9

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Description

The affected KMS keys allow access to all resources and are therefore public.

Remediation

Configure the KMS key policy following the principle of least privilege to ensure only the specific principals that require access are granted.

Affected

['123456789123']

Analysis

No issues found

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 5.5

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:L

Description

KMS Key policies allow AWS services to access the key without adequate conditional context restrictions. Without any conditional restrictions, keys are vulnerable to the confused deputy problem which could allow unauthorised services in other AWS accounts indirect access to the affected key. When an AWS service principal from a calling service (CloudTrail for example) is accessing a resource in KMS, the key’s resource policy is only authorizing the AWS service principal, and not the actor who configured the calling service. For example, an KMS Key that trusts the CloudTrail service principal with no conditions could receive CloudTrail logs from the AWS accounts that a trusted admin configures, but also CloudTrail logs from an unauthorized actor in their AWS account, if they know the name of the KMS Key.

Remediation

it is recommended that KMS Key policies that allows access to other AWS services contain conditional access statements. Using conditions and specifying the full ARN of the allowed resources would restrict access to only legitimate resources and reduce the potential for abuse. Specifying the full ARN, including region and resource name, will prevent attackers from leveraging other AWS services to access potentially sensitive data within your KMS Keys. Where appropriate use the following conditional contexts following the principal of least privilege to effectively limit the scope of key policies and prevent unintended access opportunities: - aws:SourceArn - aws:SourceAccount - aws:SourceOrgID - aws:SourceOrgPaths More Information https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html#cross-service-confused-deputy-prevention

Affected

['123456789123']

Analysis

No issues found

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Amazon RDS encrypted DB instances use the industry standard AES-256 encryption algorithm to encrypt your data on the server that hosts your Amazon RDS DB instances. After your data is encrypted, Amazon RDS handles authentication of access and decryption of your data transparently with a minimal impact on performance. Databases are likely to hold sensitive and critical data, it is highly recommended to implement encryption in order to protect your data from unauthorized access or disclosure. With RDS encryption enabled, the data stored on the instance's underlying storage, the automated backups, read replicas, and snapshots, are all encrypted.

Remediation

Ensure that encryption is enabled for all RDS Instances

Affected

['123456789123']

Analysis

All RDS instances have encryption enabled.

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

Ensure that RDS database instances have the Auto Minor Version Upgrade flag enabled in order to receive automatically minor engine upgrades during the specified maintenance window. So, RDS instances can get the new features, bug fixes, and security patches for their database engines. AWS RDS will occasionally deprecate minor engine versions and provide new ones for an upgrade. When the last version number within the release is replaced, the version changed is considered minor. With Auto Minor Version Upgrade feature enabled, the version upgrades will occur automatically during the specified maintenance window so your RDS instances can get the new features, bug fixes, and security patches for their database engines.

Remediation

Ensure that Auto Minor Version Upgrade feature is enabled for all RDS Instances

Affected

['123456789123']

Analysis

All RDS instances have Auto Minor Version Upgrade enabled.

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 6.5

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Description

Ensure and verify that RDS database instances provisioned in your AWS account do restrict unauthorized access in order to minimize security risks. To restrict access to any publicly accessible RDS database instance, you must disable the database Publicly Accessible flag and update the VPC security group associated with the instance. Ensure that no public-facing RDS database instances are provisioned in your AWS account and restrict unauthorized access in order to minimize security risks. When the RDS instance allows unrestricted access (0.0.0.0/0), everyone and everything on the Internet can establish a connection to your database and this can increase the opportunity for malicious activities such as brute force attacks, PostgreSQL injections, or DoS/DDoS attacks.

Remediation

Ensure that no public-facing RDS database instances are provisioned in your AWS account and restrict unauthorized access in order to minimize security risks

Affected

['123456789123']

Analysis

All RDS instances are private.

Impact: HIGH

Probability: MEDIUM

Status: PASS

CVSS: Score: 7.5

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Description

This control checks whether Amazon RDS snapshots are public. The control fails if RDS snapshots are public. This control evaluates RDS instances, Aurora DB instances, Neptune DB instances, and Amazon DocumentDB clusters. RDS snapshots are used to back up the data on your RDS instances at a specific point in time. They can be used to restore previous states of RDS instances. An RDS snapshot must not be public unless intended. If you share an unencrypted manual snapshot as public, this makes the snapshot available to all AWS accounts. This may result in unintended data exposure of your RDS instance. Note that if the configuration is changed to allow public access, the AWS Config rule may not be able to detect the change for up to 12 hours. Until the AWS Config rule detects the change, the check passes even though the configuration violates the rule.

Remediation

Set all DB snapshots to Private under visibility settings More Information - https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html

Affected

['123456789123']

Analysis

All RDS snapshots are private.

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 6.5

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Description

This control checks whether an RDS DB snapshot is encrypted. The control fails if an RDS DB snapshot isn't encrypted. This control is intended for RDS DB instances. However, it can also generate findings for snapshots of Aurora DB instances, Neptune DB instances, and Amazon DocumentDB clusters. If these findings are not useful, then you can suppress them. Encrypting data at rest reduces the risk that an unauthenticated user gets access to data that is stored on disk. Data in RDS snapshots should be encrypted at rest for an added layer of security.

Remediation

To encrypt an RDS snapshot, see Encrypting Amazon RDS resources in the Amazon RDS User Guide. When you encrypt an RDS DB instance, the encrypted data includes the underlying storage for the instance, its automated backups, read replicas, and snapshots. You can only encrypt an RDS DB instance when you create it, not after the DB instance is created. However, because you can encrypt a copy of an unencrypted snapshot, you can effectively add encryption to an unencrypted DB instance. That is, you can create a snapshot of your DB instance, and then create an encrypted copy of that snapshot. You can then restore a DB instance from the encrypted snapshot, and thus you have an encrypted copy of your original DB instance. More Information: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html

Affected

['123456789123']

Analysis

All RDS instance and cluster snapshots are encrypted .

Impact: HIGH

Probability: MEDIUM

Status: PASS

CVSS: Score: 7.5

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Description

This control checks whether Amazon RDS cluster snapshots are public. The control fails if RDS snapshots are public. This control evaluates RDS instances, Aurora DB instances, Neptune DB instances, and Amazon DocumentDB clusters. RDS snapshots are used to back up the data on your RDS instances at a specific point in time. They can be used to restore previous states of RDS instances. An RDS snapshot must not be public unless intended. If you share an unencrypted manual snapshot as public, this makes the snapshot available to all AWS accounts. This may result in unintended data exposure of your RDS instance. Note that if the configuration is changed to allow public access, the AWS Config rule may not be able to detect the change for up to 12 hours. Until the AWS Config rule detects the change, the check passes even though the configuration violates the rule.

Remediation

Set all DB snapshots to Private under visibility settings More Information - https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html

Affected

['123456789123']

Analysis

All RDS cluster snapshots are private.

Impact: MEDIUM

Probability: MEDIUM

Status: PASS

CVSS: Score: 6.5

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Description

Ensure and verify that RDS database instances provisioned in your AWS account do restrict unauthorized access in order to minimize security risks. To restrict access to any publicly accessible RDS database instance, you must disable the database Publicly Accessible flag and update the VPC security group associated with the instance. Ensure that no public-facing RDS database instances are provisioned in your AWS account and restrict unauthorized access in order to minimize security risks. When the RDS instance allows unrestricted access (0.0.0.0/0), everyone and everything on the Internet can establish a connection to your database and this can increase the opportunity for malicious activities such as brute force attacks, PostgreSQL injections, or DoS/DDoS attacks.

Remediation

Ensure that no public-facing RDS database clusters are provisioned in your AWS account and restrict unauthorized access in order to minimize security risks

Affected

['123456789123']

Analysis

All RDS clusters are private.

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 4.3

CVSS: Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

Description

This control checks whether an RDS DB cluster has deletion protection enabled. The control fails if an RDS DB cluster doesn't have deletion protection enabled. This control is intended for RDS DB instances. However, it can also generate findings for Aurora DB instances, Neptune DB instances, and Amazon DocumentDB clusters. If these findings are not useful, then you can suppress them. Enabling cluster deletion protection is an additional layer of protection against accidental database deletion or deletion by an unauthorized entity. When deletion protection is enabled, an RDS cluster cannot be deleted. Before a deletion request can succeed, deletion protection must be disabled.

Remediation

To enable deletion protection for an RDS DB cluster, see Modifying the DB cluster by using the console, CLI, and API in the Amazon RDS User Guide. For Deletion protection, choose Enable deletion protection. More Information: - https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html#Aurora.Modifying.Cluster

Affected

['123456789123']

Analysis

All RDS clusters have deletion protection enabled.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The AWS account under review contains Route53 domains that do not have Transfer Lock enabled. To avoid having a domain maliciously or erroneously transferred to a third-party, all domains should enable the transfer lock unless actively being transferred. The domain registries for all generic TLDs and many geographic TLDs let you lock a domain to prevent someone from transferring the domain to another registrar without your permission. To determine whether the registry for your domain lets you lock the domain, see Domains That You Can Register with Amazon Route 53.

Remediation

if locking is supported and you want to lock your domain, perform the following procedure. Sign in to the AWS Management Console and open the Route 53 console at https://console.aws.amazon.com/route53/. In the navigation pane, choose Registered Domains. Choose the name of the domain that you want to update. Choose Enable (to lock the domain) or Disable (to unlock the domain)., Choose Save.

Affected

['123456789123']

Analysis

No failing domains found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

The AWS account under review contains Route53 domains that do not have Auto Renew enabled. To ensure you retain control of your domains and associated services including email is recommended that auto renew is enabled for all critical domains.

Remediation

Affected

['123456789123']

Analysis

No failing domains found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Security Hub collects security data from across AWS accounts, services, and supported third-party partner products and helps you analyze your security trends and identify the highest priority security issues. When you enable Security Hub, it begins to consume, aggregate, organize, and prioritize findings from AWS services that you have enabled, such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie. You can also enable integrations with AWS partner security products. AWS Security Hub provides you with a comprehensive view of your security state in AWS and helps you check your environment against security industry standards and best practices - enabling you to quickly assess the security posture across your AWS accounts.

Remediation

Consider maintaining a Security Hub subscription to help identify security vulnerabilities within your account, ensure AWS config is enabled in all regions to allow Security hub to audit account configuration.

Affected

['eu-west-2', 'eu-west-1']

Analysis

Security Hub Enabled with active Standards Subscripts in the affected regions.

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

AWS Security Hub provides you with a comprehensive view of your security state in AWS and helps you check your environment against security industry standards and best practices. Security Hub collects security data from across AWS accounts, services, and supported third-party partner products and helps you analyse your security trends and identify the highest priority security issues.

Remediation

It is recommended to auto enable new Security Hub controls as they are added to compliance standards

Affected

['123456789123']

Analysis

All Security Hubs have AutoEnableControls enabled.

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 6.5

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

Description

The AWS account under review contains an AWS Simple Notification Service (SNS) which is configured to allow access from all principals AKA Everybody (*). When an SNS topic policy grants permission to Everyone by using a wildcard, i.e. *, as the Principal value, the topic security can be at risk as any unauthenticated entity can subscribe and receive messages from the topic publishers, update the topic, Publish messages to the topic and even delete topics resulting in potential loss of data availability, privacy and additional account costs.

Remediation

Ensure that your AWS Simple Notification Service (SNS) topics do not allow Everyone to subscribe. The entities that can subscribe to your SNS topics can be: Everyone (anonymous access), users whose endpoint URL, protocol, email address or ARN from a Subscribe request match a certain value, specific AWS users or resources and the topic owner. From this list of topic subscribers, you should make sure that the Everyone entity is not used with any SNS topics created within your AWS account in order to protect the messages published to your topics against attackers or unauthorized personnel.

Affected

['123456789123']

Analysis

No public SNS Topics found.

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

The AWS account under review contains an AWS SNS Topic which is not configured to use server side data encryption. When you are using AWS SNS Topics to send and receive messages that contain sensitive data, it is highly recommended to implement encryption to add an additional layer of data confidentiality by making the contents of these messages unavailable to unauthorized users. The encryption and decryption is handled transparently by SQS SSE and does not require any additional action from you or your application

Remediation

Configure the affected SNS Topics to use server side encryption using the Amazon KMS service.

Affected

['123456789123']

Analysis

No unencrypted SNS Topics found.

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

This control checks whether an Amazon CloudFront distribution is configured to return a specific object that is the default root object. The control fails if the CloudFront distribution does not have a default root object configured. A user might sometimes request the distribution's root URL instead of an object in the distribution. When this happens, specifying a default root object can help you to avoid exposing the contents of your web distribution.

Remediation

To configure a default root object for a CloudFront distribution, see How to specify a default root object in the Amazon CloudFront Developer Guide. More Information https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DefaultRootObject.html#DefaultRootObjectHowToDefine

Affected

['123456789123']

Analysis

no issues found

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

This control checks whether an Amazon CloudFront distribution requires viewers to use HTTPS directly or whether it uses redirection. The control fails if ViewerProtocolPolicy is set to allow-all for defaultCacheBehavior or for cacheBehaviors. HTTPS (TLS) can be used to help prevent potential attackers from using person-in-the-middle or similar attacks to eavesdrop on or manipulate network traffic. Only encrypted connections over HTTPS (TLS) should be allowed. Encrypting data in transit can affect performance. You should test your application with this feature to understand the performance profile and the impact of TLS.

Remediation

To encrypt a CloudFront distribution in transit, see Requiring HTTPS for communication between viewers and CloudFront in the Amazon CloudFront Developer Guide. More Information https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html

Affected

['123456789123']

Analysis

No issues found

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

Description

This control checks whether an Amazon CloudFront distribution is configured with an origin group that has two or more origins. CloudFront origin failover can increase availability. Origin failover automatically redirects traffic to a secondary origin if the primary origin is unavailable or if it returns specific HTTP response status codes.

Remediation

To configure origin failover for a CloudFront distribution, see Creating an origin group in the Amazon CloudFront Developer Guide. More Information https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html#concept_origin_groups.creating

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks whether server access logging is enabled on CloudFront distributions. The control fails if access logging is not enabled for a distribution. CloudFront access logs provide detailed information about every user request that CloudFront receives. Each log contains information such as the date and time the request was received, the IP address of the viewer that made the request, the source of the request, and the port number of the request from the viewer. These logs are useful for applications such as security and access audits and forensics investigation. For additional guidance on how to analyze access logs, see Querying Amazon CloudFront logs in the Amazon Athena User Guide.

Remediation

To configure access logging for a CloudFront distribution, see Configuring and using standard logs (access logs) in the Amazon CloudFront Developer Guide. More Information https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks whether CloudFront distributions are associated with either AWS WAF Classic or AWS WAF web ACLs. The control fails if the distribution is not associated with a web ACL. AWS WAF is a web application firewall that helps protect web applications and APIs from attacks. It allows you to configure a set of rules, called a web access control list (web ACL), that allow, block, or count web requests based on customizable web security rules and conditions that you define. Ensure your CloudFront distribution is associated with an AWS WAF web ACL to help protect it from malicious attacks.

Remediation

To associate an AWS WAF web ACL with a CloudFront distribution, see Using AWS WAF to control access to your content in the Amazon CloudFront Developer Guide. More Information https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks whether CloudFront distributions are using the default SSL/TLS certificate CloudFront provides. This control passes if the CloudFront distribution uses a custom SSL/TLS certificate. This control fails if the CloudFront distribution uses the default SSL/TLS certificate. Custom SSL/TLS allow your users to access content by using alternate domain names. You can store custom certificates in AWS Certificate Manager (recommended), or in IAM.

Remediation

To add an alternate domain name for a CloudFront distribution using a custom SSL/TLS certificate, see Adding an alternate domain name in the Amazon CloudFront Developer Guide. More Information https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#CreatingCNAME

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks if Amazon CloudFront distributions are using a custom SSL/TLS certificate and are configured to use SNI to serve HTTPS requests. This control fails if a custom SSL/TLS certificate is associated but the SSL/TLS support method is a dedicated IP address. Server Name Indication (SNI) is an extension to the TLS protocol that is supported by browsers and clients released after 2010. If you configure CloudFront to serve HTTPS requests using SNI, CloudFront associates your alternate domain name with an IP address for each edge location. When a viewer submits an HTTPS request for your content, DNS routes the request to the IP address for the correct edge location. The IP address to your domain name is determined during the SSL/TLS handshake negotiation; the IP address isn't dedicated to your distribution.

Remediation

To configure a CloudFront distribution to use SNI to serve HTTPS requests, see Using SNI to Serve HTTPS Requests (works for Most Clients) in the CloudFront Developer Guide. More Information https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-https-dedicated-ip-or-sni.html#cnames-https-sni

Affected

['123456789123']

Analysis

No issues found

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

This control checks if Amazon CloudFront distributions are encrypting traffic to custom origins. This control fails for a CloudFront distribution whose origin protocol policy allows 'http-only'. This control also fails if the distribution's origin protocol policy is 'match-viewer' while the viewer protocol policy is 'allow-all'. HTTPS (TLS) can be used to help prevent eavesdropping or manipulation of network traffic. Only encrypted connections over HTTPS (TLS) should be allowed.

Remediation

To update the Origin Protocol Policy to require encryption for a CloudFront connection, see Requiring HTTPS for communication between CloudFront and your custom origin in the Amazon CloudFront Developer Guide. More Information https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html

Affected

['123456789123']

Analysis

No issues found

Impact: LOW

Probability: LOW

Status: PASS

CVSS: Score: 3.7

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

This control checks if Amazon CloudFront distributions are using deprecated SSL protocols for HTTPS communication between CloudFront edge locations and your custom origins. This control fails if a CloudFront distribution has a CustomOriginConfig where OriginSslProtocols includes SSLv3. In 2015, the Internet Engineering Task Force (IETF) officially announced that SSL 3.0 should be deprecated due to the protocol being insufficiently secure. It is recommended that you use TLSv1.2 or later for HTTPS communication to your custom origins.

Remediation

To update the Origin SSL Protocols for a CloudFront distribution, see Requiring HTTPS for communication between CloudFront and your custom origin in the Amazon CloudFront Developer Guide. More Information https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html

Affected

['123456789123']

Analysis

No issues found

Impact: HIGH

Probability: LOW

Status: PASS

CVSS: Score: 7.4

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Description

This control checks whether Amazon CloudFront distributions are pointing to non-existent Amazon S3 origins. The control fails for a CloudFront distribution if the origin is configured to point to a non-existent bucket. This control only applies to CloudFront distributions where an S3 bucket without static website hosting is the S3 origin. When a CloudFront distribution in your account is configured to point to a non-existent bucket, a malicious third party can create the referenced bucket and serve their own content through your distribution. We recommend checking all origins regardless of routing behavior to ensure that your distributions are pointing to appropriate origins.

Remediation

To modify a CloudFront distribution to point to a new origin, see Updating a distribution in the Amazon CloudFront Developer Guide. More Information https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowToUpdateDistribution.html

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks whether an Amazon CloudFront distribution with an Amazon S3 origin has origin access control (OAC) configured. The control fails if OAC isn't configured for the CloudFront distribution. When using an S3 bucket as an origin for your CloudFront distribution, you can enable OAC. This permits access to the content in the bucket only through the specified CloudFront distribution, and prohibits access directly from the bucket or another distribution. Although CloudFront supports Origin Access Identity (OAI), OAC offers additional functionality, and distributions using OAI can migrate to OAC. While OAI provides a secure way to access S3 origins, it has limitations, such as lack of support for granular policy configurations and for HTTP/HTTPS requests that use the POST method in AWS Regions that require AWS Signature Version 4 (SigV4). OAI also doesn't support encryption with AWS Key Management Service. OAC is based on an AWS best practice of using IAM service principals to authenticate with S3 origins.

Remediation

To configure OAC for a CloudFront distribution with S3 origins, see Restricting access to an Amazon S3 origin in the Amazon CloudFront Developer Guide. More Information https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

This control checks whether an Amazon CloudFront distribution has tags with the specific keys defined in the parameter requiredTagKeys. The control fails if the distribution doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter requiredTagKeys. If the parameter requiredTagKeys isn't provided, the control only checks for the existence of a tag key and fails if the distribution isn't tagged with any key. System tags, which are automatically applied and begin with aws:, are ignored. A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.

Remediation

To add tags to a CloudFront distribution, see Tagging Amazon CloudFront distributions in the Amazon CloudFront Developer Guide. More Information https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/tagging.html

Affected

['123456789123']

Analysis

No issues found

Impact: HIGH

Probability: LOW

Status: PASS

CVSS: Score: 6.3

CVSS: Vector: CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

Description

Ensure that Amazon ECS task definitions do not grant privileged access to the host container instance. Note: This recommendation assumes that only the latest active revision of a task definition is in use. If older revisions are in use, apply the audit and remediation procedures to those revisions as needed. Restricting privileged access enhances security of the host container instance by maintaining isolation and reducing the risk of privilege escalation.There may be some administrative effort required to ensure Amazon ECS applications function as expected without privileged access.

Remediation

From Console: 1. Login to the ECS console using https://console.aws.amazon.com/ecs/. 2. In the left panel, click Task definitions. 3. Click the name of a task definition. 4. Click on the latest active revision of the task definition. 5. Click Create new revision. 6. Click Create new revision with JSON. 7. For each element under containerDefinitions, set privileged to false, or remove "privileged": true. 8. Click Create. 9. Repeat steps 1-8 for each task definition requiring remediation. Note: When a task definition is updated, running tasks launched from the previous task definition remain unchanged. Updating a running task requires redeploying it with the new task definition. Default Value: By default, privileged is set to false.

Affected

['123456789123']

Analysis

No failing containers found

Impact: HIGH

Probability: LOW

Status: PASS

CVSS: Score: 6.3

CVSS: Vector: CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

Description

Ensure that Amazon ECS task definitions using host network mode do not allow privileged or root user access. This protects the host container instance from unauthorized access and privilege escalation.Note: This recommendation assumes that only the latest active revision of a task definition is in use. If older revisions are in use, apply the audit and remediation procedures to those revisions as needed.Combining host networking mode with privileged or root user access significantly increases the risk of container breakout, where a compromised container can gain control of the host system.

Remediation

From Console: 1. Login to the ECS console using https://console.aws.amazon.com/ecs/. 2. In the left panel, click Task definitions. 3. Click the name of a task definition. 4. Click on the latest active revision of the task definition. 5. Click Create new revision. 6. Click Create new revision with JSON. 7. For each element under containerDefinitions, set privileged to false, or remove "privileged": true. 8. For each element under containerDefinitions, set user to an appropriate non-root user, or remove "user": "root". 9. Click Create. 10.Repeat steps 1-9 for each task definition requiring remediation. Note: When a task definition is updated, running tasks launched from the previous task definition remain unchanged. Updating a running task requires redeploying it with the new task definition.

Affected

['123456789123']

Analysis

No failing containers found

Impact: N/A

Probability: N/A

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Ensure that assignPublicIp is set to DISABLED for Amazon ECS services, to restrict direct exposure of containers to the public internet.Enabling public IP assignment could expose container application servers to unintended or unauthorized access.Disabling assignPublicIp introduces administrative, operational, and potential cost overhead due to the need to configure and maintain private networking and associated resources.

Remediation

For each service requiring remediation, run the following command to set assignPublicIp to DISABLED: aws ecs update-service --cluster <cluster-arn> --service <service-arn> --network-configuration '{"awsvpcConfiguration":{"subnets":["<subnet␂id>"],"securityGroups":["<security-group-id>"],"assignPublicIp":"DISABLED"}}

Affected

['123456789123']

Analysis

No failing services found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

A process ID (PID) namespace isolates processes, preventing system processes from being visible to containers and allowing for PID reuse. Ensure that Amazon ECS task definitions are not configured to share a host's process namespace with their containers. Note: This recommendation assumes that only the latest active revision of a task definition is in use. If older revisions are in use, apply the audit and remediation procedures to those revisions as needed. Setting the pidMode parameter to host shares the host's PID namespace with containers, allowing them to view and interact with all host processes. This reduces isolation and may lead to unauthorized access and manipulation of host processes by malicious or compromised containers.

Remediation

From Console: 1. Login to the ECS console using https://console.aws.amazon.com/ecs/. 2. In the left panel, click Task definitions. 3. Click the name of a task definition. 4. Click on the latest active revision of the task definition. 5. Click Create new revision. 6. Click Create new revision with JSON. 7. Set pidMode to task, or remove the pidMode parameter as appropriate. 8. Click Create. 9. Repeat steps 1-8 for each task definition requiring remediation. Note: When a task definition is updated, running tasks launched from the previous task definition remain unchanged. Updating a running task requires redeploying it with the new task definition.

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Ensure the readonlyRootFilesystem parameter is enabled in Amazon ECS task definitions to restrict write access to the filesystem. Note: This recommendation assumes that only the latest active revision of a task definition is in use. If older revisions are in use, apply the audit and remediation procedures to those revisions as needed. Enabling readonlyRootFilesystem minimizes security risks by ensuring the container's filesystem cannot be altered unless specific read-write permissions are granted.

Remediation

From Console: 1. Login to the ECS console using https://console.aws.amazon.com/ecs/. 2. In the left panel, click Task definitions. 3. Click the name of a task definition. 4. Click on the latest active revision of the task definition. 5. Click Create new revision. 6. Click Create new revision with JSON. 7. For each element under containerDefinitions, set readonlyRootFilesystem to true. 8. Click Create. 9. Repeat steps 1-8 for each task definition requiring remediation. Note: When a task definition is updated, running tasks launched from the previous task definition remain unchanged. Updating a running task requires redeploying it with the new task definition. Default Value: By default, readonlyRootFilesystem is set to false.

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Configure logging for Amazon ECS task definitions to capture detailed application and container activity. Logging facilitates effective monitoring, troubleshooting, and incident response, improving security and enabling rapid threat detection.Logging can incur costs for storage and processing, along with initial configuration and ongoing management.

Remediation

From Console: 1. Login to the ECS console using https://console.aws.amazon.com/ecs/. 2. In the left panel, click Task definitions. 3. Click the name of a task definition. 4. Click on the latest active revision of the task definition. 5. Click JSON. 6. Ensure that at least one element under containerDefinitions has a logConfiguration property defined, and that the value for logDriver is not null. 7. Repeat steps 1-6 for each task definition.

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Ensure that Amazon ECS Fargate services use the latest Fargate platform version to benefit from the latest security enhancements, performance improvements, and feature updates. Using the latest Fargate platform version ensures services benefit from up-to-date security patches and features. Updating to the latest Fargate platform version may require minor operational effort

Remediation

From Console: 1. Login to the ECS console using https://console.aws.amazon.com/ecs/. 2. In the left panel, click Clusters. 3. Click the name of a cluster. 4. Under Services, from the Filter launch type drop-down menu, select FARGATE. 5. Click the name of a service. 6. Click Update service. 7. Expand the Compute configuration (advanced) section. 8. Under Platform version, select LATEST from the drop-down menu. 9. Click Update. 10.Repeat steps 1-9 for each ECS cluster and Fargate service requiring remediation

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Ensure all Amazon ECS services have resource tags to facilitate asset management, tracking, and compliance. Consistent tagging supports compliance and helps identify unauthorized or misconfigured resources. There is minimal administrative overhead associated with implementing and maintaining resource tags.

Remediation

From Console: 1. Login to the ECS console using https://console.aws.amazon.com/ecs/. 2. In the left panel, click Clusters. 3. Click the name of a cluster. 4. Under Services, click the name of a service. 5. Click Tags. 6. Click Manage tags. 7. Click Add tag. 8. Provide a Key and optional Value for the tag. 9. Click Save. 10.Repeat steps 1-9 for each ECS cluster and service requiring remediation. Default Value: By default, Amazon ECS services are not tagged.

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Ensure all Amazon ECS clusters have resource tags to facilitate asset management, tracking, and compliance. Consistent tagging supports compliance and helps identify unauthorized or misconfigured resources. There is minimal administrative overhead associated with implementing and maintaining resource tags.

Remediation

From Console: 1. Login to the ECS console using https://console.aws.amazon.com/ecs/. 2. In the left panel, click Clusters. 3. Click the name of a cluster. 4. Under Services, click the name of a cluster. 5. Click Tags. 6. Click Manage tags. 7. Click Add tag. 8. Provide a Key and optional Value for the tag. 9. Click Save. 10.Repeat steps 1-9 for each ECS cluster and cluster requiring remediation. Default Value: By default, Amazon ECS clusters are not tagged.

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Ensure that assignPublicIp is set to DISABLED for Amazon ECS task sets, to prevent task sets from being publicly accessible. Enabling public IP assignment could expose task sets to unintended or unauthorized access. Disabling assignPublicIp introduces administrative, operational, and potential cost overhead due to the need to configure and maintain private networking and associated resources.

Remediation

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

Use customer-managed AWS KMS keys to encrypt AWS Fargate ephemeral storage data for on Amazon ECS, ensuring that sensitive data remains protected during task execution. Customer-managed KMS keys offer enhanced control over encryption, including key rotation, access policies, and audit trails. There are costs and configuration overhead associated with setting up and managing customer-managed keys.

Remediation

From Console: 1. Login to the ECS console using https://console.aws.amazon.com/ecs/. 2. In the left panel, click Clusters. 3. Click the name of a cluster. 4. Click Update cluster. 5. Expand the Encryption section. 6. Under Fargate ephemeral storage, select a customer-managed KMS key. Note: Ensure the KMS key has appropriate Fargate service permissions. 7. Click Update. 8. Repeat steps 1-7 for each ECS cluster requiring remediation.

Affected

['123456789123']

Analysis

No issues found

Impact: INFO

Probability: INFO

Status: PASS

CVSS: Score: N/A

CVSS: Vector: N/A

Description

WAFv2 Web ACLs do not have logging enabled. Logging is an important part of maintaining the reliability, availability, and performance of AWS WAF globally. It is a business and compliance requirement in many organizations, and allows you to troubleshoot application behavior. It also provides detailed information about the traffic that is analyzed by the web ACL that is attached to AWS WAF.

Remediation

Enable logging on the affected Web ACLs. More Information https://docs.aws.amazon.com/waf/latest/APIReference/API_LoggingConfiguration.html

Affected

[]

Analysis

All Web ACLs have logging enabled

Impact: MEDIUM

Probability: LOW

Status: PASS

CVSS: Score: 5.9

CVSS: Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Description

An AWS Cognito Identity Pool allows guest/anonymous access. This means any AWS user can authenticate to the pool and gain access to any privileges assigned to the role. An attacker that knows an identity ID can gain unauthenticated access to the account and potentially access account resources, sensitive data, launch elevation of privilege attacks and impose unnecessary costs.

Remediation

Disable Guest access if it is not required and ensure any roles assigned to unauthenticated users only holds minimal privileges.

Affected

['123456789123']

Analysis

No failing issues found