mondoo-aws-security.mql.yaml

# Copyright (c) Mondoo, Inc.
# SPDX-License-Identifier: BUSL-1.1

policies:
  - uid: mondoo-aws-security
    name: Mondoo AWS Security
    version: 3.1.0
    license: BUSL-1.1
    tags:
      mondoo.com/category: security
      mondoo.com/platform: aws,cloud
    authors:
      - name: Mondoo, Inc
        email: hello@mondoo.com
    docs:
      desc: |
        The Mondoo AWS Security policy provides guidance for establishing minimum recommended security and operational best practices for Amazon Web Services (AWS). The checks in this policy bundle are based on AWS's Operational Best Practices recommendations as part of the [AWS Config conformance packs](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html).

        ## Remote scan

        Remote scans use cnspec providers to retrieve on-demand scan results without having to install any agents.

        For a complete list of providers, run:

        ```bash
        cnspec scan --help
        ```

        ### Prerequisites

        Remote scanning of AWS accounts with cnspec relies on the access key ID and secret access key configured for the AWS CLI. To learn how to configure these keys in the AWS CLI, read [Configuring the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html).

        ### Scan an AWS account

        This command scans all enabled regions in an AWS account:

        ```bash
        cnspec scan aws
        ```

        ### Scan a single AWS region

        To specify a single region to scan with cnspec, use the `--region` flag with the AWS region code:

        ```bash
        cnspec scan aws --region us-west-2
        ```

        For a complete list of AWS region codes, read [Regions and Zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html).

        ### Scan an AWS account using a specific profile

        If multiple AWS profiles are configured for the AWS CLI, you can target a specific profile by setting the `AWS_PROFILE` environment variable or the `--profile` command line flag.

        ```bash
        export AWS_PROFILE=my-profile
        cnspec scan aws
        ```

        ```bash
        cnspec scan aws --profile my-profile
        ```

        ## Join the community!

        Our goal is to build policies that are simple to deploy, accurate, and actionable.

        If you have any suggestions for how to improve this policy or need support, [join the community](https://github.com/orgs/mondoohq/discussions) in GitHub Discussions.
    groups:
      - title: AWS IAM
        filters: asset.platform == "aws"
        checks:
          - uid: mondoo-aws-security-access-keys-rotated
          - uid: mondoo-aws-security-mfa-enabled-for-iam-console-access
          - uid: mondoo-aws-security-root-account-mfa-enabled
          - uid: mondoo-aws-security-iam-password-policy
          - uid: mondoo-aws-security-iam-root-access-key-check
          - uid: mondoo-aws-security-iam-users-only-one-access-key
          - uid: mondoo-aws-security-iam-group-has-users-check
          - uid: mondoo-aws-security-iam-user-no-inline-policies-check
      - title: AWS Lambda Function
        filters: asset.platform == "aws" || asset.platform == "aws-lambda-function"
        checks:
          - uid: mondoo-aws-security-lambda-concurrency-check
      - title: AWS S3 Bucket
        filters: asset.platform == "aws" || asset.platform == "aws-s3-bucket"
        checks:
          - uid: mondoo-aws-security-s3-bucket-level-public-access-prohibited
          - uid: mondoo-aws-security-s3-buckets-account-level-block-public-access
      - title: AWS Security Group
        filters: asset.platform == "aws"
        checks:
          - uid: mondoo-aws-security-secgroup-restricted-ssh
          - uid: mondoo-aws-security-secgroup-restricted-vnc
          - uid: mondoo-aws-security-secgroup-restricted-rdp
      - title: AWS VPC
        filters: asset.platform == "aws"
        checks:
          - uid: mondoo-aws-security-vpc-default-security-group-closed
          - uid: mondoo-aws-security-vpc-flow-logs-enabled
      - title: AWS DynamoDB Table
        filters: asset.platform == "aws"
        checks:
          - uid: mondoo-aws-security-dynamodb-table-encrypted-kms
      - title: AWS RDS DB Instance
        filters: asset.platform == "aws" || asset.platform == "aws-rds-dbinstance"
        checks:
          - uid: mondoo-aws-security-rds-instance-public-access-check
      - title: AWS Redshift Cluster
        filters: asset.platform == "aws" || asset.platform == "aws-redshift-cluster"
        checks:
          - uid: mondoo-aws-security-redshift-cluster-public-access-check
      - title: AWS EC2
        filters: asset.platform == "aws"
        checks:
          - uid: mondoo-aws-security-ec2-ebs-encryption-by-default
          - uid: mondoo-aws-security-ec2-imdsv2-check
          - uid: mondoo-aws-security-ec2-instance-no-public-ip
          - uid: mondoo-aws-security-ec2-volume-inuse-check
          - uid: mondoo-aws-security-ebs-snapshot-public-restorable-check
      - title: AWS EFS Filesystem
        filters: asset.platform == "aws" || asset.platform == "aws-efs-filesystem"
        checks:
          - uid: mondoo-aws-security-efs-encrypted-check
      - title: AWS CloudWatch LogGroup
        filters: asset.platform == "aws"
        checks:
          - uid: mondoo-aws-security-cloudwatch-log-group-encrypted
      - title: AWS ELB LoadBalancer
        filters: asset.platform == "aws"
        checks:
          - uid: mondoo-aws-security-elb-deletion-protection-enabled
      - title: AWS ES Domain
        filters: asset.platform == "aws"
        checks:
          - uid: mondoo-aws-security-elasticsearch-encrypted-at-rest
      - title: AWS KMS Key
        filters: asset.platform == "aws"
        checks:
          - uid: mondoo-aws-security-rotation-customer-created-cmks-enabled
      - title: AWS SageMaker NotebookInstance
        filters: asset.platform == "aws"
        checks:
          - uid: mondoo-aws-security-sagemaker-notebook-instance-kms-key-configured
      - title: AWS CloudTrail Trail
        filters: asset.platform == "aws"
        checks:
          - uid: mondoo-aws-security-cloud-trail-encryption-enabled
    scoring_system: highest impact
queries:
  - uid: mondoo-aws-security-iam-root-access-key-check
    title: Ensure no root user account access key exists
    impact: 85
    mql: |
      aws.iam.credentialReport.where(properties.user == "<root_account>").all(accessKey1Active == false)
      aws.iam.credentialReport.where(properties.user == "<root_account>").all(accessKey2Active == false)
    docs:
      desc: |
        AWS strongly recommends that you not use the root user for your everyday tasks, even administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. Anyone with root user credentials for your AWS account has unrestricted access to all the resources in your account, including billing information.
      audit: |
        __cnspec shell__

        1. Open a terminal
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

          ```mql
          aws.iam.credentialReport.where( properties["user"] == "<root_account>") { accessKey1Active accessKey2Active }
          ```

          Example output:

          ```mql
          aws.iam.credentialReport.where: [
            0: {
              accessKey1Active: false
              accessKey2Active: false
            }
          ]
          ```
      remediation: |
        If any access keys exist for the root user, read [Delete access keys for the root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user_manage_delete-key.html) in the AWS documentation.
    refs:
      - url: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html
        title: AWS Documentation - AWS account root user
      - url: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user_manage_delete-key.html
        title: AWS Documentation - Delete access keys for the root user
  - uid: mondoo-aws-security-root-account-mfa-enabled
    title: Ensure MFA is enabled for the "root user" account
    impact: 95
    mql: aws.iam.credentialReport.where(properties.user == "<root_account>").all(mfaActive == true)
    docs:
      desc: |
        AWS highly recommends that you follow the security best practice to enable multi-factor authentication (MFA) for your root account. Because your root user can perform sensitive operations in your account, adding an additional layer of authentication helps you to better secure your account. Multiple types of MFA are available.
      audit: |
        __cnspec shell__

        1. Open a terminal
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

           ```mql
           aws.iam.credentialReport.where( properties["user"] == "<root_account>") { mfaActive passwordLastChanged passwordLastUsed }
           ```

          Example output:

          ```mql
          aws.iam.credentialReport.where: [
            0: {
              mfaActive: true
            }
          ]
          ```
      remediation: |
        Note: This check uses the AWS Credential Report, which has a grace period of 4 hours before changes to credentials take effect.

        __Terraform__

        The following snippet demonstrates creating a virtual device for the root user and returning the QRCode.
        After creating the virtual MFA device, the root user can follow the procedure described under the AWS Console section.

        ```hcl
        resource "aws_iam_virtual_mfa_device" "root_mfa" {
          virtual_mfa_device_name = "root"
        }
        output "root_qr_code" {
          value = tomap({
            (aws_iam_virtual_mfa_device.root_mfa.virtual_mfa_device_name) = aws_iam_virtual_mfa_device.root_mfa.qr_code_png
          })
        }
        ```

        __AWS Console__

        MFA devices in AWS can be either hardware-based or virtual. To enable an MFA device for the root user, either:
        - [Enable a virtual MFA device for your AWS account root user (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html)
        or:
        - [Enable a hardware TOTP token for the root user (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-hw-mfa-for-root.html)

        __AWS CLI__

        Similarly to non-root users, you can use the AWS CLI to:

        Create a virtual MFA device:

        ```bash
        aws iam create-virtual-mfa-device \
          --virtual-mfa-device-name "root" \
          --outfile ./QRCode.png \
          --bootstrap-method QRCodePNG
        ```

        Activate an MFA device:

        ```bash
        aws iam enable-mfa-device \
          --user-name "root" \
          --serial-number "arn:aws:iam::123456976749:mfa/root" \
          --authentication-code1 123456 \
          --authentication-code2 654321
        ```
    refs:
      - url: https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html
        title: Enable a virtual MFA device for the root user (console)
  - uid: mondoo-aws-security-iam-password-policy
    title: Ensure strong account password policy requirements are used
    impact: 60
    props:
      - uid: mondooAWSSecurityIamPasswordPolicyMaxPasswordAge
        title: Define the maximum number of days a password is allowed to exist before being rotated
        mql: "90"
      - uid: mondooAWSSecurityIamPasswordPolicyMinimumPasswordLength
        title: Minimum password length
        mql: "14"
      - uid: mondooAWSSecurityIamPasswordPolicyPasswordReusePrevention
        title: Number of passwords before allowing reuse
        mql: "24"
      - uid: mondooAWSSecurityIamPasswordPolicyRequireLowercaseCharacters
        title: Denotes whether lowercase characters are required for passwords
        mql: "true"
      - uid: mondooAWSSecurityIamPasswordPolicyRequireNumbers
        title: Denotes whether numbers are required for passwords
        mql: "true"
      - uid: mondooAWSSecurityIamPasswordPolicyRequireSymbols
        title: Denotes whether symbols are required for passwords
        mql: "true"
      - uid: mondooAWSSecurityIamPasswordPolicyRequireUppercaseCharacters
        title: Denotes whether uppercase characters are required for passwords
        mql: "true"
    mql: |
      // Ensure properties do exist.
      aws.iam.accountPasswordPolicy.RequireUppercaseCharacters != empty
      aws.iam.accountPasswordPolicy.RequireLowercaseCharacters != empty
      aws.iam.accountPasswordPolicy.RequireSymbols != empty
      aws.iam.accountPasswordPolicy.RequireNumbers != empty
      aws.iam.accountPasswordPolicy.MinimumPasswordLength != empty
      aws.iam.accountPasswordPolicy.PasswordReusePrevention != empty
      aws.iam.accountPasswordPolicy.MaxPasswordAge != empty
      // Validate each policy setting against props
      aws.iam.accountPasswordPolicy.where(RequireUppercaseCharacters != empty).all(RequireUppercaseCharacters == props.mondooAWSSecurityIamPasswordPolicyRequireUppercaseCharacters)
      aws.iam.accountPasswordPolicy.where(RequireLowercaseCharacters != empty).all(RequireLowercaseCharacters == props.mondooAWSSecurityIamPasswordPolicyRequireLowercaseCharacters)
      aws.iam.accountPasswordPolicy.where(RequireSymbols != empty).all(RequireSymbols == props.mondooAWSSecurityIamPasswordPolicyRequireSymbols)
      aws.iam.accountPasswordPolicy.where(RequireNumbers != empty).all(RequireNumbers == props.mondooAWSSecurityIamPasswordPolicyRequireNumbers)
      aws.iam.accountPasswordPolicy.where(MinimumPasswordLength != empty).all(MinimumPasswordLength >= props.mondooAWSSecurityIamPasswordPolicyMinimumPasswordLength)
      aws.iam.accountPasswordPolicy.where(PasswordReusePrevention != empty).all(PasswordReusePrevention >= props.mondooAWSSecurityIamPasswordPolicyPasswordReusePrevention)
      aws.iam.accountPasswordPolicy.where(MaxPasswordAge != empty).all(MaxPasswordAge <= props.mondooAWSSecurityIamPasswordPolicyMaxPasswordAge)
    docs:
      desc: |
        AWS allows custom password policies on your AWS account to specify complexity requirements and mandatory rotation periods for your IAM users' passwords. IAM user passwords must meet the default AWS password policy if you don't set a custom password policy. AWS security best practices recommend these password complexity requirements:

        - Require at least one uppercase character in passwords.
        - Require at least one lowercase character in passwords.
        - Require at least one symbol in passwords.
        - Require at least one number in passwords.
        - Require a minimum password length of at least 14 characters.
        - Require at least 24 passwords before allowing reuse.
        - Require at least 90 before password expiration.

        This check ensures all of the specified password policy requirements are in place.
      audit: |
        __cnspec shell__

        1. Open a terminal.
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

           ```mql
           aws.iam.accountPasswordPolicy
           ```

          Example output:

          ```mql
          aws.iam.accountPasswordPolicy: {
            AllowUsersToChangePassword: true
            ExpirePasswords: true
            HardExpiry: false
            MaxPasswordAge: "180"
            MinimumPasswordLength: "14"
            PasswordReusePrevention: "24"
            RequireLowercaseCharacters: true
            RequireNumbers: true
            RequireSymbols: true
            RequireUppercaseCharacters: true
          }
          ```
      remediation: |
        __Terraform__

        ```hcl
        resource "aws_iam_account_password_policy" "strict" {
          allow_users_to_change_password = true
          require_uppercase_characters   = true
          require_lowercase_characters   = true
          require_symbols                = true
          require_numbers                = true
          minimum_password_length        = 14
          password_reuse_prevention      = 24
          max_password_age               = 90
        }
        ```

        __AWS Console__

        To create a custom password policy:

        1. Sign into the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
        2. In the navigation pane, select **Account settings**.
        3. In the Password policy section, select **Change password policy**.
        4. Select the options you want to apply to your password policy and select **Save changes**.

        To change a custom password policy:

        1. Sign into the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
        2. In the navigation pane, select **Account settings**.
        3. In the **Password policy** section, select **Change**.
        4. Select the options you want to apply to your password policy and select **Save changes**.

        __AWS CLI__

        ```bash
        aws iam update-account-password-policy \
        --allow-users-to-change-password \
        --require-uppercase-characters \
        --require-lowercase-characters \
        --require-symbols \
        --require-numbers \
        --minimum-password-length 14 \
        --password-reuse-prevention 24 \
        --max-password-age 90
        ```
    refs:
      - url: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords.html
        title: User passwords in AWS
      - url: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html
        title: Set an account password policy for IAM users
  - uid: mondoo-aws-security-access-keys-rotated
    title: Ensure IAM user access keys are rotated
    impact: 70
    props:
      - uid: mondooAWSSecurityMaxAccessKeyAge
        title: Define the maximum number of days an IAM key is allowed to exist before rotation
        mql: "90"
    mql: |
      aws.iam.credentialReport.where(accessKey1Active == true && time.now - userCreationTime > props.mondooAWSSecurityMaxAccessKeyAge * time.day).all(time.now - accessKey1LastRotated < props.mondooAWSSecurityMaxAccessKeyAge * time.day)
      aws.iam.credentialReport.where(accessKey2Active == true && time.now - userCreationTime > props.mondooAWSSecurityMaxAccessKeyAge * time.day).all(time.now - accessKey2LastRotated < props.mondooAWSSecurityMaxAccessKeyAge * time.day)
    docs:
      desc: |
        It is highly recommended that AWS IAM user access keys be rotated regularly to minimize the risk of unauthorized access and credential compromise. Access keys that remain active for extended periods increase the likelihood of exposure through accidental leaks, insider threats, or malicious attacks. Regular rotation ensures that, even if a key is compromised, its window of usefulness is limited. This reduces the impact of potential security breaches.

        By default this check enforces a 90 day rotation period. To change this value, modify the `mondooAWSSecurityMaxAccessKeyAge` property.
      audit: |
        __cnspec shell__

        1. Open a terminal.
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

        ```mql
        aws.iam.credentialReport.where( accessKey1Active == true || accessKey2Active == true ) { properties['user'] accessKey1Active accessKey2Active accessKey1LastRotated accessKey2LastRotated }
        ```

        Example output:

        ```mql
        aws.iam.credentialReport.where: [
          0: {
            accessKey1LastRotated: 2024-09-01 01:32:29 +0000 +0000
            accessKey2LastRotated: Never
            accessKey1Active: true
            accessKey2Active: false
            properties[user]: "jimmy"
          }
          1: {
            accessKey1LastRotated: 2024-09-09 19:16:35 +0000 +0000
            accessKey2LastRotated: Never
            accessKey1Active: true
            accessKey2Active: false
            properties[user]: "robert"
          }
          2: {
            accessKey1LastRotated: 2024-06-15 07:18:34 +0000 +0000
            accessKey2LastRotated: Never
            accessKey1Active: true
            accessKey2Active: false
            properties[user]: "johnpaul"
          }
          3: {
            accessKey1LastRotated: 2024-09-29 21:53:04 +0000 +0000
            accessKey2LastRotated: Never
            accessKey1Active: true
            accessKey2Active: false
            properties[user]: "bonzo"
          }
        ]
        ```
      remediation: |
        To learn how to rotate AWS access keys, read [Rotating access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) in the AWS documentation.
    refs:
      - url: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
        title: AWS Documentation - Manage access keys for IAM users
  - uid: mondoo-aws-security-mfa-enabled-for-iam-console-access
    title: Ensure Multi-Factor Authentication is Enabled for All IAM users with console access
    impact: 90
    mql: |
      aws.iam.credentialReport.where(passwordEnabled == true).all(mfaActive == true)
    docs:
      desc: |
        Multi-factor authentication (MFA) is a best practice that adds an extra layer of protection on top of user names and passwords. With MFA, when a user signs in to the AWS Management Console, they are required to provide a time-sensitive authentication code provided by a registered virtual or physical device.
      audit: |
        __cnspec shell__

        1. Open a terminal.
        2. Run this command: `cnspec shell aws`
        3. Run this query:

        ```mql
        aws.iam.credentialReport.where(
          mfaActive != true
        ) {arn properties["user"]}
        ```
        Example output:

        ```mql
        aws.iam.credentialReport.where: [
          0: {
            properties[user]: "test-iam-user"
            arn: "arn:aws:iam::053121068929:user/users/test-iam-user"
          }
        ]
        ```
      remediation: |
        Note: This check uses the AWS Credential Report, which has a grace period of 4 hours before changes to credentials take effect.

        __Terraform__

        When it comes to Terraform, there are a few options to remediate the absence of MFA devices. You probably already have a sensible structure for organizing your users into groups and restrictive policies.

        The following example shows how to:
        1. Create users.
        2. Create users' login profiles with a PGP public key.
        3. Create a group and group policy that allows self-management of IAM profiles.
        4. Attach users to a group.
        5. Create Virtual MFA devices for users.
        6. Provide each user with the output QR Code and password.

        ```hcl
        variable "users" {
          type = set(string)
          default = [
            "mondoo-test@mondoo.com",
            "mondoo-test2@mondoo.com"
          ]
        }

        resource "aws_iam_user" "mondoo_test_users" {
          for_each = toset(var.users)
          name     = each.key
        }

        resource "aws_iam_user_login_profile" "mondoo_test_users_profile" {
          for_each                = var.users
          user                    = each.key
          # Key pair created using GnuPG. This is the public key
          pgp_key = file("path/to/gpg_pub_key_base64.pem")
          password_reset_required = true
          lifecycle {
            ignore_changes = [
              password_length,
              password_reset_required,
              pgp_key,
            ]
          }
        }

        resource "aws_iam_virtual_mfa_device" "mondoo_test_mfa" {
          for_each                = toset(var.users)
          virtual_mfa_device_name = each.key
        }

        resource "aws_iam_group" "enforce_mfa_group" {
          name = "EnforceMFAGroup"
        }

        resource "aws_iam_group_membership" "enforce_mfa_group_membership" {
          name  = "EnforceMFAGroupMembership"
          group = aws_iam_group.enforce_mfa_group.name
          users = [for k in aws_iam_user.mondoo_test_users : k.name]
        }

        resource "aws_iam_group_policy" "enforce_mfa_policy" {
          name   = "EnforceMFAGroupPolicy"
          group  = aws_iam_group.enforce_mfa_group.id
          policy = <<POLICY
        {
          "Version": "2012-10-17",
          "Statement": [
            {
                "Sid": "AllowViewAccountInfo",
                "Effect": "Allow",
                "Action": [
                    "iam:GetAccountPasswordPolicy",
                    "iam:ListVirtualMFADevices"
                ],
                "Resource": "*"
            },
            {
                "Sid": "AllowManageOwnPasswords",
                "Effect": "Allow",
                "Action": [
                    "iam:ChangePassword",
                    "iam:GetUser"
                ],
                "Resource": "arn:aws:iam::*:user/$${aws:username}"
            },
            {
                "Sid": "AllowManageOwnAccessKeys",
                "Effect": "Allow",
                "Action": [
                    "iam:CreateAccessKey",
                    "iam:DeleteAccessKey",
                    "iam:ListAccessKeys",
                    "iam:UpdateAccessKey"
                ],
                "Resource": "arn:aws:iam::*:user/$${aws:username}"
            },
            {
                "Sid": "AllowManageOwnSigningCertificates",
                "Effect": "Allow",
                "Action": [
                    "iam:DeleteSigningCertificate",
                    "iam:ListSigningCertificates",
                    "iam:UpdateSigningCertificate",
                    "iam:UploadSigningCertificate"
                ],
                "Resource": "arn:aws:iam::*:user/$${aws:username}"
            },
            {
                "Sid": "AllowManageOwnSSHPublicKeys",
                "Effect": "Allow",
                "Action": [
                    "iam:DeleteSSHPublicKey",
                    "iam:GetSSHPublicKey",
                    "iam:ListSSHPublicKeys",
                    "iam:UpdateSSHPublicKey",
                    "iam:UploadSSHPublicKey"
                ],
                "Resource": "arn:aws:iam::*:user/$${aws:username}"
            },
            {
                "Sid": "AllowManageOwnGitCredentials",
                "Effect": "Allow",
                "Action": [
                    "iam:CreateServiceSpecificCredential",
                    "iam:DeleteServiceSpecificCredential",
                    "iam:ListServiceSpecificCredentials",
                    "iam:ResetServiceSpecificCredential",
                    "iam:UpdateServiceSpecificCredential"
                ],
                "Resource": "arn:aws:iam::*:user/$${aws:username}"
            },
            {
                "Sid": "AllowManageOwnVirtualMFADevice",
                "Effect": "Allow",
                "Action": [
                    "iam:CreateVirtualMFADevice",
                    "iam:DeleteVirtualMFADevice"
                ],
                "Resource": "arn:aws:iam::*:mfa/$${aws:username}"
            },
            {
                "Sid": "AllowManageOwnUserMFA",
                "Effect": "Allow",
                "Action": [
                    "iam:DeactivateMFADevice",
                    "iam:EnableMFADevice",
                    "iam:ListMFADevices",
                    "iam:ResyncMFADevice"
                ],
                "Resource": "arn:aws:iam::*:user/$${aws:username}"
            },
            {
                "Sid": "DenyAllExceptListedIfNoMFA",
                "Effect": "Deny",
                "NotAction": [
                    "iam:CreateVirtualMFADevice",
                    "iam:EnableMFADevice",
                    "iam:GetUser",
                    "iam:ListMFADevices",
                    "iam:ListVirtualMFADevices",
                    "iam:ResyncMFADevice",
                    "sts:GetSessionToken"
                ],
                "Resource": "*",
                "Condition": {
                    "BoolIfExists": {
                        "aws:MultiFactorAuthPresent": "false"
                    }
                }
            }
          ]
        }
        POLICY
        }

        output "user_password_map" {
          # Outputs a map in the format {"mondoo-test@mondoo.com": <PGPEncryptedPassword>, "mondoo-test2@mondoo.com": <PGPEncryptedPassword>}
          value = { for k, v in aws_iam_user_login_profile.mondoo_test_users_profile : k => v.password }
        }

        output "user_qr_map" {
          # Outputs a map in the format {"mondoo-test@mondoo.com": <QRCode>, "mondoo-test2@mondoo.com": <QRCode>}
          value = { for k, v in aws_iam_virtual_mfa_device.mondoo_test_mfa : k => v.qr_code_png }
        }
        ```

        __AWS Console__

        To learn how to enable MFA for any user accounts with AWS console access, read [Enabling a virtual multi-factor authentication (MFA) device (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html) in the AWS documentation.

        Enable a virtual MFA device for an IAM user:

        1. Sign into the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
        2. In the navigation pane, select **Users**.
        3. In the **User Name** list, select the name of the intended MFA user.
        4. select the **Security credentials** tab. Next to Assigned MFA device, select **Manage**.
        5. In the Manage MFA Device wizard, select **Virtual MFA device** and then select **Continue**.
        6. IAM generates and displays configuration information for the virtual MFA device, including a QR code graphic. The graphic represents the "secret configuration key" available for manual entry on devices that do not support QR codes.
        7. Open your virtual MFA app. For a list of apps you can use to host virtual MFA devices, read [Multi-Factor Authentication](https://aws.amazon.com/iam/features/mfa/).
        8. If the virtual MFA app supports multiple virtual MFA devices or accounts, select the option to create a new virtual MFA device or account.
        9. Determine whether the MFA app supports QR codes, and then either:
          - From the wizard, select **Show QR code**, and then use the app to scan the QR code. For example, you might select the camera icon or select an option similar to Scan code, and then use the device's camera to scan the code.
          or:
          - In the Manage MFA Device wizard, select **Show secret key** and type the secret key into your MFA app.
        10. When you finish, the virtual MFA device generates one-time passwords.
        11. In the Manage MFA Device wizard, in the **MFA code 1** box, type the one-time password that currently appears in the virtual MFA device. Wait up to 30 seconds for the device to generate a new one-time password, then type the second one-time password into the **MFA code 2 box**.
        12. select **Assign MFA**.

        __AWS CLI__

        Create an MFA device:

        ```bash
        aws iam create-virtual-mfa-device \
          --virtual-mfa-device-name "mondoo.test@mondoo.com" \
          --outfile ./QRCode.png \
          --bootstrap-method QRCodePNG
        ```

        Enable MFA device for existing user:

        ```bash
        aws iam enable-mfa-device \
          --user-name "mondoo.test@mondoo.com" \
          --serial-number "arn:aws:iam::123456976749:mfa/mondoo.test@mondoo.com" \
          --authentication-code1 123456 \
          --authentication-code2 654321
        ```
    refs:
      - url: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html
        title: AWS Multi-factor authentication in IAM
      - url: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html
        title: Assign a virtual MFA device in the AWS Management Console
      - url: https://registry.terraform.io/providers/hashicorp/aws/latest/docs
        title: Terraform Documentation - AWS Provider
  - uid: mondoo-aws-security-iam-group-has-users-check
    title: Ensure IAM Groups are utilized by Assigning at Least One user
    impact: 30
    docs:
      desc: |
        AWS Identity and Access Management (IAM) can help you incorporate the principles of least privilege and separation of duties with access permissions and authorizations by ensuring that IAM groups have at least one IAM user. Placing IAM users in groups based on their associated permissions or job function is one way to incorporate least privilege.
      audit: |
        __cnspec shell__

        1. Open a terminal.
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

        ```mql
        aws.iam.groups.where( usernames.length == 0 ) {*}
        ```

        Example output:

        ```mql
        aws.iam.groups.where: [
          0: {
            name: "MyUserGroup"
            id: "AGPASSOFBMF7OMHVGHACB"
            createDate: 2022-01-11 18:19:26 +0000 UTC
            createAt: 2022-01-11 18:19:26 +0000 UTC
            usernames: []
            arn: "arn:aws:iam::12345678910:group/MyUserGroup"
          }
        ]
        ```
      remediation: |
        To delete empty IAM groups, read [Delete an IAM group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html) in the AWS documentation.
    refs:
      - url: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage.html
        title: AWS Documentation - IAM user groups
    variants:
      - uid: mondoo-aws-security-iam-group-has-users-check-account
      - uid: mondoo-aws-security-iam-group-has-users-check-single-group
  - uid: mondoo-aws-security-iam-group-has-users-check-account
    filters: asset.platform == "aws"
    mql: aws.iam.groups.all(usernames != empty)
  - uid: mondoo-aws-security-iam-group-has-users-check-single-group
    filters: asset.platform == "aws-iam-group"
    mql: aws.iam.group.usernames != empty
  - uid: mondoo-aws-security-iam-users-only-one-access-key
    title: Ensure there is only one active access key available for any single IAM user
    impact: 70
    mql: |
      aws.iam.users.where(accessKeys.flat.where(Status == "Active")).all(accessKeys[0].length <= 1)
    docs:
      desc: |
        This check ensures for the existence of more than one access key for each user within an AWS account. Each AWS key within an account must be protected and rotated regularly. Because AWS access keys are long-term credentials, one of the best ways to protect your account is to not allow users to have multiple access keys, which reduces the overall number of keys and the risk of exposure.
      audit: |
        __cnspec shell__

        1. Open a terminal.
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

        ```mql
        aws.iam.users.where(accessKeys[0].length >= 1)
        ```
      remediation: |
        __AWS Console:__

        1. Sign into the AWS Management Console and navigate to IAM dashboard at https://console.aws.amazon.com/iam/.
        2. In the left navigation panel, select **Users**.
        3. Select the IAM user you want to examine.
        4. On the IAM user configuration page, select the **Security Credentials** tab.
        5. In the **Access Keys** section, select an access key that is fewer than 90 days old. This should be the only active key used by this IAM user to access AWS resources programmatically. Test your application(s) to make sure that the chosen access key is working.
        6. In the same **Access Keys** section, identify your non-operational access keys (other than the chosen one) and deactivate them by selecting the **Make Inactive** link.

        If the Change Key Status confirmation displays, select **Deactivate** to turn off the selected key.

        Repeat steps 3 - 7 for each IAM user in your AWS account.

        __AWS CLI:__

        Using the IAM user and access key information provided in the Audit CLI, select an access key that is fewer than 90 days old. This should be the only active key used by this IAM user to access AWS resources programmatically. Test your application(s) to make sure that the chosen access key is working.

        Run the `update-access-key` command (shown below) using the IAM user name and the non-operational access key IDs to deactivate the unnecessary key(s). To learn how to identify the unnecessary access key ID for the selected IAM user, read the _Audit_ section above.

        Note: This command does not return any output:

        ```bash
        aws iam update-access-key --access-key-id <access-key-id> --status Inactive --user-name <user-name>
        ```

        To confirm that the selected access key pair has been successfully deactivated, run the `list-access-keys`` audit command again for the IAM User:

        ```bash
        aws iam list-access-keys --user-name <user-name>
        ```

        The command output exposes the metadata for each access key associated with the IAM user. If the non-operational key pair(s) Status is set to Inactive, the key has been successfully deactivated and the IAM user access configuration adheres now to this recommendation.

        Repeat steps 1 - 3 for each IAM user in your AWS account.
  - uid: mondoo-aws-security-iam-user-no-inline-policies-check
    title: Ensure IAM users receive permissions only through groups
    impact: 70
    docs:
      desc: |
        AWS recommends that IAM users must inherit permissions from IAM groups or roles. This policy checks that none of your IAM users have policies attached directly to the user. The rule is NONCOMPLIANT if there is at least one IAM user with policies attached.
      audit: |
        __cnspec shell__

        1. Open a terminal.
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

        ```mql
        aws.iam.users.where( policies.length != 0 || attachedPolicies.length != 0 ) { name arn policies attachedPolicies }
        ```

        Example output:

        ```mql
        aws.iam.users.where: [
          0: {
            arn: "arn:aws:iam::1234567890987:user/1234567890987-alice"
            name: "1234567890987-alice"
            attachedPolicies: []
            policies: [
              0: "excess_policy"
            ]
          }
          1: {
            arn: "arn:aws:iam::1234567890987:user/maria"
            name: "maria"
            attachedPolicies: [
              0: aws.iam.policy id = arn:aws:iam::1234567890987:policy/ec2-instance-connect-sendssh
            ]
            policies: []
          }
          2: {
            arn: "arn:aws:iam::1234567890987:user/bobby"
            name: "bobby"
            attachedPolicies: [
              0: aws.iam.policy id = arn:aws:iam::1234567890987:policy/terraform20210901011436036200000004
            ]
            policies: []
          }
        ]
        ```
      remediation: |
        To learn how to remove inline policies from IAM users, read [Removing a permissions policy from a user (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-remove-policy-console) in the AWS documentation.
    refs:
      - url: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html
        title: Managed policies and inline policies
    variants:
      - uid: mondoo-aws-security-iam-user-no-inline-policies-check-account
      - uid: mondoo-aws-security-iam-user-no-inline-policies-check-single-user
  - uid: mondoo-aws-security-iam-user-no-inline-policies-check-account
    filters: asset.platform == "aws"
    mql: |
      aws.iam.users.all(policies == empty)
      aws.iam.users.all(attachedPolicies == empty)
  - uid: mondoo-aws-security-iam-user-no-inline-policies-check-single-user
    filters: asset.platform == "aws-iam-user"
    mql: |
      aws.iam.user.policies == empty
      aws.iam.user.attachedPolicies == empty
  - uid: mondoo-aws-security-vpc-default-security-group-closed
    title: Ensure the default security group of every VPC restricts all traffic
    impact: 80
    docs:
      desc: |
        The rules for a default security group allow all ingress and egress traffic. To keep users from using the default security group (which cannot be deleted) of a VPC, delete all ingress and egress rules to block all traffic.
      audit: |
        __cnspec shell__

        1. Open a terminal.
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

        ```mql
        aws.ec2.securityGroups.where(
          name == "default"
        ).where(
          ipPermissions.length != 0
          || ipPermissionsEgress.length != 0
        ){id name region ipPermissions{*} ipPermissionsEgress{*}}
        ```

        Example output:

        ```mql
        aws.ec2.securityGroups.where.where: [
          0: {
            ipPermissions: [
              0: {
                id: "sg-0bd4b1ef47132d3de-0"
                fromPort: 0
                toPort: 0
                ipProtocol: "-1"
                ipv6Ranges: []
                ipRanges: []
              }
            ]
            ipPermissionsEgress: []
            name: "default"
            region: "eu-north-1"
            id: "sg-0bd4b1ef47132d3de"
          }
        ]
        ```
      remediation: |
        __Terraform__

        Terraform provides the resource `aws_default_security_group` which, unlike other Terraform resources, has these effects in the state of the infrastructure:

        - "Adopts" the default security group for the provided `vpc_id`.
        - Removes all inbound (ingress) and outbound (egress) rules for the security group.

        To remediate this check using Terraform, apply the following logic for every region the account has access to by aliasing the providers.

        Note: You must create a new security group for all VPCs in order to reassign any resources that previously used (or were created with) the default security groups.

        ```hcl
        provider "aws" {
          alias  = "us_east_1"
          region = "us-east-1"
        }

        data "aws_vpcs" "us_east_1" {
          provider = aws.us_east_1
        }

        resource "aws_security_group" "replacement_for_default" {
          name     = "AllowOrDenySomething"
          for_each = toset(data.aws_vpcs.us_east_1.ids)
          vpc_id   = each.value
          ingress {
            # ... other configuration ...
          }
          egress {
            # ... other configuration ...
          }
        }

        resource "aws_default_security_group" "us_east_1" {
          for_each = toset(data.aws_vpcs.us_east_1.ids)
          vpc_id   = each.value
          provider = aws.us_east_1
        }
        ```

        __AWS Console__

        To remediate this issue, create new security groups and assign those security groups to your resources (if needed). To prevent the default security groups from being used, remove their inbound and outbound rules.
        To create new security groups and assign them to your resources:

        1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
        2. In the navigation pane, select **Security groups**. View the default security groups details to see the resources that are assigned to them.
        3. Create a set of least-privilege security groups for the resources. To learn how to create security groups, read [Creating a security group](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#CreatingSecurityGroups) in the Amazon VPC User Guide.
        4. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
        5. On the Amazon EC2 console, change the security group for the resources that use the default security groups to the least-privilege security group you created. To learn how, read [Changing an instance's security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SG_Changing_Group_Membership) in the Amazon VPC User Guide.

        After you assign the new security groups to the resources, remove the inbound and outbound rules from the default security groups. This ensures that the default security groups are not used.

        To remove the rules from the default security group:

        1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
        2. In the navigation pane, select **Security groups**.
        3. Select a default security group and select the **Inbound rules** tab. select Edit inbound rules. Delete all inbound rules and select **Save rules**.
        4. Repeat the previous step for each default security group.
        5. Select a default security group and select the Outbound rule tab. Select **Edit outbound rules**. Delete all outbound rules and select **Save rules**.
        6. Repeat the previous step for each default security group.
        To learn more, read [Working with security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#WorkingWithSecurityGroups) in the Amazon VPC User Guide.

        __AWS CLI__

        Apply the same logic to the AWS CLI to remediate this check.

        Note: Perform these tasks for all regions your account has access to.

        1. Get the security groups in the region.

        ```bash
        aws ec2 describe-security-groups
        ```

        2. Create a new security group to replace the default in every VPC (if needed):

        ```bash
        aws ec2 create-security-group \
          --description "AllowOrDenySomething" \
          --group-name "AllowOrDenySomething" \
          --vpc-id <value>
        ```

        3. Modify the security group to provide inbound and outbound rules:

        ```bash
        aws ec2 modify-security-group-rules \
          --group-id <value> \
          --security-group-rules <rules>
        ```

        4. Revoke security group rules from the default security groups:

        ```bash
        aws ec2 revoke-security-group-egress \
          --group-id <id_default_sg>
        aws ec2 revoke-security-group-ingress \
          --group-id <id_default_sg>
        ```
    refs:
      - url: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html
        title: AWS Documentation - Security Hub controls reference
      - url: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/index.html
        title: AWS Documentation - AWS CLI Reference - EC2
      - url: https://registry.terraform.io/providers/hashicorp/aws/latest/docs
        title: Terraform Documentation - AWS Provider
    variants:
      - uid: mondoo-aws-security-vpc-default-security-group-closed-account
      - uid: mondoo-aws-security-vpc-default-security-group-closed-secgroup
  - uid: mondoo-aws-security-vpc-default-security-group-closed-account
    title: Ensure the default security group of every VPC restricts all traffic
    filters: asset.platform == "aws"
    mql: |
      aws.ec2.securityGroups.where(name == "default").all(
        ipPermissions == empty
      )
      aws.ec2.securityGroups.where(name == "default").all(
        ipPermissionsEgress == empty
      )
  - uid: mondoo-aws-security-vpc-default-security-group-closed-secgroup
    title: Ensure the default security group of every VPC restricts all traffic
    filters: asset.platform == "aws-security-group" && aws.ec2.securitygroup.name == "default"
    mql: |
      aws.ec2.securitygroup.ipPermissions == empty
      aws.ec2.securitygroup.ipPermissionsEgress == empty
  - uid: mondoo-aws-security-ec2-ebs-encryption-by-default
    title: Ensure EBS volume encryption is enabled by default
    impact: 90
    mql: aws.ec2.ebsEncryptionByDefault.values.all(_ == true)
    docs:
      desc: |
        New Amazon EBS volumes aren't encrypted by default. However, there is a setting in the Amazon Elastic Compute Cloud (Amazon EC2) console that turns on encryption by default for all new Amazon EBS volumes and snapshot copies created within a specified Region.
      audit: |
        __cnspec shell__

        1. Open a terminal.
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

          ```mql
          aws.ec2.ebsEncryptionByDefault
          ```

          Example output:

          ```mql
          aws.ec2.ebsEncryptionByDefault
            aws.ec2.ebsEncryptionByDefault: {
              ap-northeast-1: false
              ap-northeast-2: false
              ap-northeast-3: false
              ap-south-1: false
              ap-southeast-1: false
              ap-southeast-2: false
              ca-central-1: false
              eu-central-1: false
              eu-north-1: false
              eu-west-1: false
              eu-west-2: false
              eu-west-3: false
              sa-east-1: false
              us-east-1: true
              us-east-2: true
              us-west-1: false
              us-west-2: false
            }
          ```
      remediation: |
        __Terraform__

        The `aws_ebs_encryption_by_default` resource can be used to enable EBS encryption by default. This must be applied to each region.

        ```hcl
        provider "aws" {
          region = var.region
        }

        resource "aws_ebs_encryption_by_default" "example" {
          enabled = true
        }
        ```
        __AWS Console__

        1. Open the [Amazon EC2 console](https://console.aws.amazon.com/ec2/).
        2. Select the **Region** from the drop-down menu.
        3. On the **EC2 Dashboard**, under **Account Attributes**, select **Settings**.
        4. Under **EBS Storage**, select **Always encrypt new EBS volumes**.
        5. Select **Change the default key** and select any of your keys ([default/KMS Keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys)) as the **Default encryption key**.
        6. Select **Save Settings**.

        __AWS CLI__

        The following `enable-ebs-encryption-by-default` example enables EBS encryption for your AWS account in the current region by default.

        ```bash
        aws ec2 enable-ebs-encryption-by-default
        ```
    refs:
      - url: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default
        title: AWS Documentation - Encryption by default
  - uid: mondoo-aws-security-s3-buckets-account-level-block-public-access
    title: Ensure public access to S3 buckets is blocked at the account level
    impact: 95
    mql: |
      aws.s3control.accountPublicAccessBlock != empty
      aws.s3control.accountPublicAccessBlock.values.all(_ == true)
    docs:
      desc: |
        Amazon S3 Block Public Access provides settings for access points, buckets, and accounts to help you manage public access to Amazon S3 resources. By default, new buckets, access points, and objects do not allow public access.
      audit: |
        __cnspec shell__

        1. Open a terminal
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

        ```mql
        aws.s3control.accountPublicAccessBlock
        ```

        Example output:

        ```mql
        aws.s3control.accountPublicAccessBlock: null
        ```
      remediation: |
        __Terraform__

        The following Terraform resource configures account level access to S3:

        ```hcl
        resource "aws_s3_account_public_access_block" "s3_control" {
          block_public_acls       = true
          block_public_policy     = true
          ignore_public_acls      = true
          restrict_public_buckets = true
        }
        ```

        __AWS Console__

        To edit block public access settings for all the S3 buckets in an AWS account.

        1. Sign into the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.
        2. Select **Block Public Access settings for this account**.
        3. Select **Edit** to change the block public access settings for all the buckets in your AWS account.
        4. Select the settings you want to change, then select **Save changes**.
        5. When you're asked for confirmation, enter `confirm`. Then select **Confirm** to save your changes.

        __AWS CLI__

        ```bash
        aws s3control put-public-access-block \
        --account-id <value> \
        --public-access-block-configuration '{"BlockPublicAcls": true, "BlockPublicPolicy": true, "IgnorePublicAcls": true, "RestrictPublicBuckets": true}'
        ```
    refs:
      - url: https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
        title: Blocking public access to your Amazon S3 storage
      - url: https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-block-public-access-account.html
        title: Configuring block public access settings for your account
  - uid: mondoo-aws-security-s3-bucket-level-public-access-prohibited
    title: Verify Bucket-Level Public Access restrictions for Amazon S3 Buckets
    impact: 100
    docs:
      desc: |
        This check ensures S3 buckets have bucket-level public access blocks applied. This check fails if any of these settings are set to false:

        - ignorePublicAcls
        - blockPublicPolicy
        - blockPublicAcls
        - restrictPublicBuckets

        Block Public Access at the S3 bucket level provides controls to ensure that objects never have public access. Public access is granted to buckets and objects through access control lists (ACLs), bucket policies, or both.
        Unless you intend to have your S3 buckets publicly accessible, you should configure the bucket-level Amazon S3 Block Public Access feature.
      audit: |
        __cnspec shell__

        1. Open a terminal.
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

        ```mql
          aws.s3.buckets.all(
            publicAccessBlock != empty && publicAccessBlock.values.all(_ == true)
          )
        ```

        Example output:

        ```mql
          [failed] [].all()
            actual:   [
              0: aws.s3.bucket id = arn:aws:s3:::mondoo-test2.policies.test-ui
            ]
        ```
      remediation: |
        __Terraform__

        This resource creates a Public Access Block resource and applies it to the specific bucket:

        ```hcl
        resource "aws_s3_bucket_public_access_block" "example" {
          bucket   = aws_s3.bucket.example.id
          block_public_acls       = true
          block_public_policy     = true
          ignore_public_acls      = true
          restrict_public_buckets = true
        }
        ```

        __AWS Console__

        To learn how to use the AWS Console to block public access on a bucket level, read [Blocking public access to your Amazon S3 storage](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html).

        __AWS CLI__

        ```bash
        aws s3api put-public-access-block \
          --bucket <value>
          --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
        ```
    refs:
      - url: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html
        title: AWS Documentation - Security Hub controls reference
      - url: https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
        title: AWS Documentation - Blocking public access to your Amazon S3 storage
      - url: https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
        title: AWS CLI Command Reference - aws s3api put-public-access-block
      - url: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket_public_access_block
        title: Terraform Documentation - AWS Provider - aws_s3_bucket_public_access_block
    variants:
      - uid: mondoo-aws-security-s3-bucket-level-public-access-prohibited-account
      - uid: mondoo-aws-security-s3-bucket-level-public-access-prohibited-bucket
  - uid: mondoo-aws-security-s3-bucket-level-public-access-prohibited-account
    filters: asset.platform == "aws"
    mql: |
      aws.s3.buckets.all(publicAccessBlock != empty)
      aws.s3.buckets.all(publicAccessBlock.BlockPublicAcls == true)
      aws.s3.buckets.all(publicAccessBlock.BlockPublicPolicy == true)
      aws.s3.buckets.all(publicAccessBlock.IgnorePublicAcls == true)
      aws.s3.buckets.all(publicAccessBlock.RestrictPublicBuckets == true)
  - uid: mondoo-aws-security-s3-bucket-level-public-access-prohibited-bucket
    filters: asset.platform == "aws-s3-bucket"
    mql: |
      aws.s3.bucket.publicAccessBlock != empty
      aws.s3.bucket.publicAccessBlock.BlockPublicAcls == true
      aws.s3.bucket.publicAccessBlock.BlockPublicPolicy == true
      aws.s3.bucket.publicAccessBlock.IgnorePublicAcls == true
      aws.s3.bucket.publicAccessBlock.RestrictPublicBuckets == true
  - uid: mondoo-aws-security-ec2-instance-no-public-ip-all
    filters: |
      asset.platform == "aws"
    mql: |
      aws.ec2.instances.all(publicIp == empty)
  - uid: mondoo-aws-security-ec2-instance-no-public-ip-single
    filters: |
      asset.platform == "aws-ec2-instance"
    mql: |
      aws.ec2.instance.publicIp == empty
  - uid: mondoo-aws-security-ec2-instance-no-public-ip
    title: Ensure No Public IP associated with EC2 Instances
    impact: 80
    variants:
      - uid: mondoo-aws-security-ec2-instance-no-public-ip-all
      - uid: mondoo-aws-security-ec2-instance-no-public-ip-single
    docs:
      desc: |
        It is highly recommended that AWS EC2 instances not have Elastic IPs (EIPs) attached unless absolutely necessary. Public IP exposure increases the attack surface and potential security risks. Instances with public IP addresses are directly accessible from the internet, making them vulnerable to brute-force attacks, exploitation of software vulnerabilities, and denial-of-service (DoS) attacks.
      audit: |
        __cnspec shell__

        1. Open a terminal.
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query to return a list of all running EC2 instances across all enabled regions that along with the `instanceId`, `region`, and the configured `publicIp`:

        ```mql
        aws.ec2.instances.where( state = "running" && publicIp != "" ) { instanceId region tags publicIp }
        ```

        Example output:

        ```mql
        aws.ec2.instances.where: [
          0: {
            instanceId: "i-0070af411a515f14a"
            tags: {
              Environment: "windows-development-vpc"
              Name: "win19-dev-workstation-106e1f1c"
              Terraform: "true"
            }
            publicIp: "54.55.222.9"
            region: "us-east-1"
          }
        ]
        ```
      remediation: |
        __Terraform__

        Use the `associate_public_ip_address = false` argument with the `aws_instance` resource to ensure EC2 instances are provisioned without a public IP address:

        ```hcl
        resource "aws_instance" "no_public_ip" {
          ...
          associate_public_ip_address = false
        }
        ```
        __AWS Console__

        By default, non-default subnets have the IPv4 public addressing attribute set to false, and default subnets have this attribute set to true. An exception is a non-default subnet created by the Amazon EC2 launch instance wizard. The wizard sets the attribute to true. You can modify this attribute using the Amazon VPC console.

        To modify your subnet's public IPv4 addressing behavior:

        1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
        2. In the navigation pane, select **Subnets**.
        3. Select your subnet and select **Actions, Edit subnet settings**.
        4. The **Enable auto-assign public IPv4 address** check box, if selected, requests a public IPv4 address for all instances launched into the selected subnet. Select or clear the check box as required, and then select **Save**.

        __AWS CLI__

        this command runs an EC2 Instance in a default subnet without associating a public IP address to it.

        ```bash
        aws ec2 run-instances \
        --image-id <ami_id> \
        --instance-type <instance_flavor> \
        --no-associate-public-ip-address \
        --key-name MyKeyPair
        ```
    refs:
      - url: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html
        title: AWS Documentation - IP addressing for your VPCs and subnets
      - url: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance
        title: Terraform Registry - aws_instance
  - uid: mondoo-aws-security-ec2-imdsv2-check-all
    filters: asset.platform == "aws"
    mql: |
      aws.ec2.instances.where(state != /terminated|shutting-down/ && httpEndpoint == "enabled").all(httpTokens == "required")
  - uid: mondoo-aws-security-ec2-imdsv2-check-single
    filters: |
      asset.platform == "aws-ec2-instance"
      aws.ec2.instance.state != /terminated|shutting-down/
      aws.ec2.instance.httpEndpoint == "enabled"
    mql: |
      aws.ec2.instance.httpTokens == "required"
  - uid: mondoo-aws-security-ec2-imdsv2-check
    title: Ensure EC2 instances use IMDSv2
    impact: 90
    variants:
      - uid: mondoo-aws-security-ec2-imdsv2-check-all
      - uid: mondoo-aws-security-ec2-imdsv2-check-single
    docs:
      desc: |
        EC2 instances should be configured to use IMDSv2 to prevent unauthorized access to instance metadata from application vulnerabilities such as Server Side Request Forgery (SSRF). IMDSv1 has been involved in security exploits.

        By default, you can use IMDSv1, IMDSv2, or both. The instance metadata service distinguishes between IMDSv1 and IMDSv2 requests based on whether, for any given request, either the PUT or GET headers, which are unique to IMDSv2, are present. To learn more, read [Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/).
      audit: |
        __cnspec shell__

        1. Open a terminal.
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

          ```bash
          aws.ec2.instances.where( httpTokens != "required" ) { arn instanceId region tags httpTokens }
          ```

          Example output:

          ```mql
          aws.ec2.instances.where: [
            0: {
              instanceId: "i-0070af411a515f14a"
              region: "us-east-1"
              arn: "arn:aws:ec2:us-east-1:1234375555:instance/i-0070af411a515f14a"
              httpTokens: "optional"
              tags: {
                Environment: "windows-development-vpc"
                Name: "win19-dev-workstation-106e1f1c"
                Terraform: "true"
              }
            }
          ]
          ```
      remediation: |
        To remediate this check, there are a series of steps necessary to transition to IMDSv2. The steps include both configuring existing instances (such as changing your Terraform EC2 resources), and updating CLIs, SDKs, and software that uses role credentials.

        If your existing EC2 instance uses IMDSv1, you can reconfigure it to use IMDSv2. To learn how, read [Transition to using Instance Metadata Service Version 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html#instance-metadata-transition-to-version-2).

        __Terraform__

        Use the `metadata_options` block to configure `http_tokens = "required"`.

        ```hcl
        resource "aws_instance" "web_host" {
          metadata_options {
            http_tokens   = "required"
          }
        }
        ```

        __AWS Console__

        To configure your new EC2 instance with IMDSv2 from the console:
        1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
        2. Select **Launch instance** and then select **Launch instance**.
        3. In the **Configure Instance Details** step, under **Advanced Details**, for Metadata version, select **V2 (token required)**.
        4. Select **Review and Launch**.

        __AWS CLI__

        To modify a running instance:

        ```bash
        aws ec2 modify-instance-metadata-options \
        --instance-id <value>
        --http-tokens required \
        --http-endpoint enabled
        ```

        To create a new instance:

        ```bash
        aws ec2 run-instances \
        --image-id <ami_id> \
        --instance-type <instance_flavor> \
        --metadata-options "HttpEndpoint=enabled,HttpTokens=required"
        ```
  - uid: mondoo-aws-security-vpc-flow-logs-enabled
    title: Ensure VPC flow logging is enabled in all VPCs
    impact: 70
    docs:
      desc: |
        This check ensures Amazon VPC Flow Logs are found and enabled for all VPCs. Default VPCs should always fail this check because they do not come with flow logs activated.
      audit: |
        __cnspec Shell__

        1. Open a terminal.
        2. Connect cnspec shell to your AWS environment: `cnspec shell aws`
        3. Run this query:

          ```mql
          aws.vpcs.where(
            flowLogs.length == 0
          ){id arn region state isDefault flowLogs tags}
          ```

          This example output shows only one VPC, but default VPCs in all regions fail this check.

          ```mql
          aws.vpcs.where: [
            0: {
              arn: "arn:aws:vpc:eu-north-1:053121068929:id/vpc-0c3955e3d04d2e09a"
              flowLogs: []
              id: "vpc-0c3955e3d04d2e09a"
              isDefault: true
              region: "eu-north-1"
              state: "available"
              tags: {}
            }
            ...
          ]
          ```
      remediation: |
        There are a few considerations while remediating this check:

        - Default VPCs should not be used. Delete them to avoid enabling flow logs for them.
        - Any default or non-default VPC must have flow logs activated.
        - The best way to remediate this check is to:

          1. Migrate resources from default to non-default VPCs.
          2. Delete default VPCs.
          3. Enable flow logs for the non-default VPCs.

        We recommend using either Terraform or the AWS Management Console because they have automation to delete a VPC and its dependencies.

        __Terraform__

        Open source Terraform modules can help us obtain this result by providing ways to delete VPCs and children dependencies.

        Warning: This example is destructive and irreversible. It destroys all child dependencies of default VPCs, including:

        - Subnets
        - Route tables
        - NACLs
        - Internet Gateways

        This module execution fails for VPCs containing resources attached to the network interfaces. In this case, review the resources and redeploy them to non-default VPCs.

        ```hcl
        terraform {
          required_providers {
            awsutils = {
              source = "cloudposse/awsutils"
            }
          }
        }

        # Create one for each region
        provider "awsutils" {
          alias  = "ap_northeast_1"
          region = "ap-northeast-1"
        }

        # Create one for each region - the creation of this resource will delete the default resources
        resource "awsutils_default_vpc_deletion" "us_east_1" {
          provider = awsutils.us_east_1
        }
        ```

        To enable flow logs for VPCs with customer-managed KMS keys:

        ```hcl
        data "aws_caller_identity" "current" {}

        resource "aws_kms_key" "vpc_flowlog" {
          description         = "Key to provide encryption to VPC Flow Logs"
          enable_key_rotation = true
          policy = jsonencode({
            Version = "2012-10-17"
            Statement = [
              {
                Effect = "Allow"
                Action = [
                  "kms:Encrypt*",
                  "kms:Decrypt*",
                  "kms:ReEncrypt*",
                  "kms:GenerateDataKey*",
                  "kms:Describe*"
                ]
                Principal = {
                  Service = "logs.<region>.amazonaws.com"
                }
                Resource = "arn:aws:kms:*:${data.aws_caller_identity.current.account_id}:key/*"
              },
              {
                Sid    = "Enable IAM User Permissions"
                Effect = "Allow"
                Principal = {
                  "AWS" : "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"
                }
                Action   = "kms:*"
                Resource = "*"
              }
            ]
          })
        }

        resource "aws_cloudwatch_log_group" "vpc_flowlog" {
          name              = "VPCFlowLog"
          kms_key_id        = aws_kms_key.vpc_flowlog.arn
          retention_in_days = <value>
        }

        resource "aws_iam_role" "vpc_flowlog" {
          name = "VPCFlowLog"

          assume_role_policy = jsonencode({
            Version = "2012-10-17"
            Statement = [
              {
                Sid    = "VPCFlowLog"
                Effect = "Allow"
                Principal = {
                  Service = "vpc-flow-logs.amazonaws.com"
                }
                Action = "sts:AssumeRole"
              }
            ]
          })
        }

        resource "aws_iam_policy" "vpc_flowlog" {
          name = "VpcFlowLog"
          policy = jsonencode({
            Version = "2012-10-17"
            Statement = [
              {
                Action = [
                  "logs:CreateLogGroup",
                  "logs:CreateLogStream",
                  "logs:PutLogEvents",
                  "logs:DescribeLogGroups",
                  "logs:DescribeLogStreams",
                ],
                Effect   = "Allow",
                Resource = "*"
              }
            ]
          })
        }

        resource "aws_iam_policy_attachment" "vpc_flowlog" {
          name       = "${aws_iam_policy.vpc_flowlog.name}Attachment"
          roles      = [aws_iam_role.vpc_flowlog.id]
          policy_arn = aws_iam_policy.vpc_flowlog.arn
        }

        resource "aws_flow_log" "example" {
          iam_role_arn    = aws_iam_role.vpc_flowlog.arn
          log_destination = aws_cloudwatch_log_group.vpc_flowlog.arn
          traffic_type    = "ALL"
          vpc_id          = aws_vpc.example.id
        }
        ```

        __AWS Console__

        To delete the default VPCs:

        1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
        2. Under Resources by Region, VPCs, select **See all regions**.
        3. For each region with a default VPC, select the region to open the VPC home page for that region in another tab.
        4. Under Your VPCs, check the default VPC.
        5. Under Actions, select **Delete VPC**.
        6. In the Delete VPC form, acknowledge that you want to delete the default VPC.
        7. Select **Delete VPC**.
        8. If there are resources deployed to that VPC, an error displays. In that case:

          a. Create a VPC to hold the resources in the default VPC.
          b. Redeploy your resources to the non-default VPC.
          c. Try deleting the VPC again.

        To enable VPC flow logging:

        1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
        2. Under **Virtual Private Cloud**, select **Your VPCs**.
        3. Select a VPC to update.
        4. At the bottom of the page, select **Flow Logs**.
        5. Select **Create flow log**.
        6. For **Filter**, select **Reject**.
        7. For **Destination log group**, select the log group to use.
        8. For IAM role, select the IAM role to use.
        9. Select **Create**.

        __AWS CLI__

        Deleting default VPCs using the CLI is discouraged. To maintain the idempotency of commands, there is no automated deletion of children resources in place.

        We advise that AWS customers delete default VPCs using either Terraform or the AWS Console (see above).

        To create flow logs for non-default VPCs and send them to CloudWatch (recommended):

        1. Create a policy (`key-policy.json`) to allow the CloudWatch principal access to KMS keys, replace `<account_id>`:

        ```javascript
        {
          "Version": "2012-10-17"
          "Statement": [
            {
              "Effect": "Allow"
              "Action": [
                "kms:Encrypt*",
                "kms:Decrypt*",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:Describe*"
              ]
              "Principal": {
                "Service": "logs.us-east-1.amazonaws.com"
              }
              "Resource": "arn:aws:kms:*:<account_id>:key/*"
            },
            {
              "Sid": "Enable IAM User Permissions"
              "Effect": "Allow"
              "Principal": {
                "AWS": "arn:aws:iam::<account_id>:root"
              }
              "Action": "kms:*"
              "Resource": "*"
            }
          ]
        }
        ```

        ```bash
        aws kms create-key \
          --description "Key to provide encryption to VPC Flow Logs" \
          --policy file://key-policy.json
        ```

        2. Enable key rotation:

        ```bash
        aws kms enable-key-rotation \
          --key-id <value>
        ```

        3. Create a policy (`role-policy.json`) to allow CloudWatch to manage log groups:

        ```javascript
        {
          "Version": "2012-10-17"
          "Statement": [
            {
              "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:DescribeLogGroups",
                "logs:DescribeLogStreams"
              ],
              "Effect": "Allow",
              "Resource": "*"
            }
          ]
        }
        ```

        4. Create a role:

        ```bash
        aws iam create-role \
          --path "/" \
          --role-name "VPCFlowLog"
        ```

        5. Attach the policy to the role:

        ```bash
        aws iam attach-role-policy \
          --role-name <value> \
          --policy-arn <value>
        ```

        6. Create a CloudWatch log group:

        ```bash
        aws logs create-log-group \
          --log-group-name <value> \
          --kms-key-id <value>
        ```

        7. Create a CloudWatch log flow:

        ```bash
        aws ec2 create-flow-logs \
          --deliver-logs-permission-arn <iam_role_arn> \
          --traffic-type "ALL" \
          --resource-ids "<list>" "<vpcs>" "<ids>" \
          --resource-type "VPC" \
          --log-destination-type "cloud-watch-logs" \
          --log-destination <arn_cloudwatch_log_group>
        ```
    refs:
      - url: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html
        title: AWS Documentation - Security Hub controls reference
      - url: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/index.html
        title: AWS Documentation - AWS CLI Command Reference - logs
      - url: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/index.html
        title: AWS Documentation - AWS CLI Command Reference - ec2
      - url: https://registry.terraform.io/providers/cloudposse/awsutils/latest/docs
        title: Terraform registry - Cloud Posse AWS Utils Provider
      - url: https://registry.terraform.io/providers/hashicorp/aws/latest/docs
        title: Terraform Documentation - AWS Provider
    variants:
      - uid: mondoo-aws-security-vpc-flow-logs-enabled-account
      - uid: mondoo-aws-security-vpc-flow-logs-enabled-single-vpc
  - uid: mondoo-aws-security-vpc-flow-logs-enabled-account
    filters: asset.platform == "aws"
    mql: |
      aws.vpcs.all(
        flowLogs.any(
          status == "ACTIVE" &&
          destination != empty &&
          destinationType == "cloud-watch-logs" &&
          deliverLogsStatus == "SUCCESS" &&
          trafficType == "REJECT" ||
          trafficType == "ALL"
          )
      )
  - uid: mondoo-aws-security-vpc-flow-logs-enabled-single-vpc
    filters: asset.platform == "aws-vpc"
    mql: |
      aws.vpc.flowLogs.any(
        status == "ACTIVE" &&
        destination != empty &&
        destinationType == "cloud-watch-logs" &&
        deliverLogsStatus == "SUCCESS" &&
        trafficType == "REJECT" ||
        trafficType == "ALL"
        )
  - uid: mondoo-aws-security-dynamodb-table-encrypted-kms-all
    filters: asset.platform == "aws"
    mql: |
      aws.dynamodb.tables.all(sseDescription.SSEType == "KMS")
      aws.dynamodb.tables.all(sseDescription.Status == "ENABLED")
  - uid: mondoo-aws-security-dynamodb-table-encrypted-kms-single
    filters: |
      asset.platform == "aws-dynamodb-table"
    mql: |
      aws.dynamodb.table.sseDescription.SSEType == "KMS"
      aws.dynamodb.table.sseDescription.Status == "ENABLED"
  - uid: mondoo-aws-security-dynamodb-table-encrypted-kms
    title: Ensure DynamoDB tables are encrypted with AWS Key Management Service (KMS)
    impact: 30
    variants:
      - uid: mondoo-aws-security-dynamodb-table-encrypted-kms-all
      - uid: mondoo-aws-security-dynamodb-table-encrypted-kms-single
    docs:
      desc: |
        Checks whether all DynamoDB tables are encrypted with a customer managed KMS key (non-default).
      audit: |
        __cnspec Shell__

        1. Open a terminal.
        2. Connect to your AWS environment with cnspec shell: `cnspec shell aws`
        3. Run this query:

          ```mql
          aws.dynamodb.tables.where(
            sseDescription.length == 0
          ){*}
          ```

          Example output:

          ```mql
          aws.dynamodb.tables.where: [
            0: {
              tags: {}
              backups: []
              arn: "arn:aws:dynamodb:us-east-1:053121068929:table/GameScoresAutoscale"
              region: "us-east-1"
              continuousBackups: {
                ContinuousBackupsStatus: "ENABLED"
                PointInTimeRecoveryDescription: {
                  EarliestRestorableDateTime: "2022-08-02T18:54:51Z"
                  LatestRestorableDateTime: "2022-08-03T15:38:43.954Z"
                  PointInTimeRecoveryStatus: "ENABLED"
                }
              }
              sseDescription: {}
              name: "GameScoresAutoscale"
              provisionedThroughput: {
                LastDecreaseDateTime: null
                LastIncreaseDateTime: null
                NumberOfDecreasesToday: 0.000000
                ReadCapacityUnits: 1.000000
                WriteCapacityUnits: 1.000000
              }
            }
          ]
          ```
      remediation: |
        __Terraform__

        To remediate this check, create an AWS KMS Key and use it to encrypt the violating DynamoDB resource:

        ```hcl
        resource "aws_kms_key" "dynamodb_encryption" {
          description         = "Used for DynamoDB encryption configuration"
          enable_key_rotation = true
        }

        resource "aws_dynamodb_table" "example" {
          # ... other configuration ...
          server_side_encryption {
            enabled     = true
            kms_key_arn = aws_kms_key.dynamodb_encryption.arn
          }
        }
        ```

        __AWS Console__

        Assuming there is an existing AWS KMS key available to encrypt DynamoDB, change a DynamoDB table encryption to a customer managed and owned KMS key:

        1. Open the DynamoDB console at https://console.aws.amazon.com/dynamodb/.
        2. Select the table that you want to work with, and then select **Additional settings**.
        3. Under **Encryption**, select **Manage encryption**.
        4. For **Encryption at rest**, select **Stored in your account, and owned and managed by you**.
        5. Select the AWS Key to use. Save changes.

        __AWS CLI__

        ```bash
        aws dynamodb update-table \
          --table-name <value> \
          --sse-specification "Enabled=true,SSEType=KMS,KMSMasterKeyId=<kms_key_arn>"
        ```
    refs:
      - url: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html
        title: AWS Documentation - Security Hub controls reference
      - url: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/dynamodb/index.html
        title: AWS Documentation - AWS CLI Command Reference - DynamoDB
      - url: https://registry.terraform.io/providers/hashicorp/aws/latest/docs
        title: Terraform Documentation - AWS Provider
      - url: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html
        title: AWS Documentation - DynamoDB encryption at rest
  - uid: mondoo-aws-security-lambda-concurrency-check
    title: Ensure Lambda functions are configured with function-level concurrent execution limits
    impact: 60
    variants:
      - uid: mondoo-aws-security-lambda-concurrency-check-single
      - uid: mondoo-aws-security-lambda-concurrency-check-all
  - uid: mondoo-aws-security-lambda-concurrency-check-single
    filters: |
      asset.platform == "aws-lambda-function"
    mql: |
      aws.lambda.function.concurrency > 0
      aws.lambda.function.concurrency <= 100
  - uid: mondoo-aws-security-lambda-concurrency-check-all
    filters: |
      asset.platform == "aws"
    mql: |
      aws.lambda.functions.all(concurrency > 0)
      aws.lambda.functions.all(concurrency <= 100)
  - uid: mondoo-aws-security-rds-instance-public-access-check-all
    filters: |
      asset.platform == "aws"
    mql: |
      aws.rds.instances.all(publiclyAccessible == false)
      aws.rds.instances
        .where(publiclyAccessible != false)
        .none(securityGroups.where(
          vpc.routeTables.where(
            routes.any(GatewayId == /igw-/ && DestinationCidrBlock == "0.0.0.0/0")
          )
        )
      )
  - uid: mondoo-aws-security-rds-instance-public-access-check-single
    filters: |
      asset.platform == "aws-rds-dbinstance"
    mql: |
      aws.rds.dbinstance.publiclyAccessible == false
      aws.rds.dbinstance.securityGroups.none(
        vpc.routeTables.where(
          routes.any(GatewayId == /igw-/ && DestinationCidrBlock == "0.0.0.0/0")
        )
      )
  - uid: mondoo-aws-security-rds-instance-public-access-check
    title: Ensure all RDS instances are not publicly accessible
    impact: 100
    variants:
      - uid: mondoo-aws-security-rds-instance-public-access-check-all
      - uid: mondoo-aws-security-rds-instance-public-access-check-single
    docs:
      desc: |
        Ensure the Amazon Relational Database Service instances are not publicly accessible. The rule is NON_COMPLIANT if the publiclyAccessible field is true in the instance configuration item.

        The default behavior varies depending on whether `DBSubnetGroupName` is specified.
      audit: |
        __cnspec Shell__

        1. Open a terminal.
        2. Connect to your AWS environment with cnspec shell: `cnspec shell aws`
        3. Run this query:

        ```mql
        aws.rds.instances.where(publiclyAccessible == true) {arn name region dbInstanceIdentifier tags}
        ```

        Example output:

        ```mql
        aws.rds.instances.where: [
          0: {
            arn: "arn:aws:rds:us-moonbase-2:12345:db:rds-12345-mondoo-demo"
            tags: {
              Environment: "12345-mondoo-demo"
              Name: "12345-mondoo-demo-rds"
              git_file: "terraform/aws/db-app.tf"
              git_repo: "mondoo-demo-environment"
            }
            region: "us-moonbase-2"
            dbInstanceIdentifier: "rds-12345-mondoo-demo"
            name: "db1"
          }
        ]
        ```
      remediation: |
        __Terraform__

        Use the `aws_db_instance` resource to explicitly state that `publicly_accessible = false`:

        ```hcl
        resource "aws_db_instance" "pass_public_accessible" {
          allocated_storage    = 10
          engine               = "mysql"
          engine_version       = "5.7"
          instance_class       = "db.t3.micro"
          name                 = "mydb"
          username             = "foo"
          password             = "foobarbaz"
          parameter_group_name = "default.mysql5.7"
          skip_final_snapshot  = true
          publicly_accessible  = false
        }
        ```

        __AWS Console__

        To remediate this issue, update your RDS DB instances to remove public access:

        1. Open the Amazon RDS console at https://console.aws.amazon.com/rds/.
        2. Navigate to Databases and then select your public database.
        3. Select **Modify**.
        4. Under Connectivity, expand **Additional connectivity configuration**.
        5. Under Public access, select **Not publicly accessible**.
        6. Select **Continue**.
        7. Under Scheduling of modifications, select **Apply immediately**.
        8. Select **Modify DB Instance**.

        __AWS CLI__

        This example demonstrates how to remediate publicly accessible RDS instances. Running this command can render your instance inaccessible if you rely on the public access for your operations. Make sure you review your architecture before applying this remediation.

        Modify an existing RDS instance:

        ```bash
        aws rds modify-db-instance \
          --db-instance-identifier <rds_instance_id> \
          --no-publicly-accessible
        ```

        Create a new RDS instance without public access:

        ```bash
        aws rds create-db-instance \
          --db-name "production" \
          --db-instance-identifier "production-mysql-5-7" \
          --db-instance-class "db.t3.micro" \
          --db-parameter-group-name "default.mysql5.7" \
          --engine "mysql" \
          --engine-version "5.7" \
          --allocated-storage 10 \
          --master-username "mymasteruser" \
          --master-user-password "mysupersecretpasswordforthemasteruser"
        ```
    refs:
      - url: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-db-instance.html
        title: AWS CLI Command Reference - create-db-instance
      - url: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/modify-db-instance.html
        title: AWS CLI Command Reference - modify-db-instance
      - url: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance#publicly_accessible-1
        title: Terraform Registry - aws_db_instance
      - url: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html
        title: AWS Documentation - Security Hub controls reference
  - uid: mondoo-aws-security-redshift-cluster-public-access-check
    title: Ensure Redshift clusters are not publicly accessible
    impact: 95
    variants:
      - uid: mondoo-aws-security-redshift-cluster-public-access-check-all
      - uid: mondoo-aws-security-redshift-cluster-public-access-check-single
    docs:
      desc: |
        The PubliclyAccessible attribute of the Amazon Redshift cluster configuration indicates whether the cluster is publicly accessible. When the cluster is configured with PubliclyAccessible set to true, it is an Internet-facing instance that has a publicly resolvable DNS name, which resolves to a public IP address.

        When the cluster is not publicly accessible, it is an internal instance with a DNS name that resolves to a private IP address. Unless you intend for your cluster to be publicly accessible, the cluster should not be configured with PubliclyAccessible set to true.
      audit: |
        __cnspec Shell__

        1. Open a terminal.
        2. Connect to your AWS environment with cnspec shell: `cnspec shell aws`
        3. Run this query:

          ```mql
          aws.redshift.clusters.where(
            publiclyAccessible != false
          ){name arn region publiclyAccessible}
          ```

          Example output:

          ```mql
          aws.redshift.clusters.where: [
            0: {
              region: "us-east-1"
              publiclyAccessible: true
              name: "test-redshift-cluster"
              arn: "arn:aws:redshift:us-east-1:053121068929:cluster/test-redshift-cluster"
            }
          ]
          ```
      remediation: |
        __Terraform__

        To remediate this check, you must modify the Redshift cluster resource and set `publicly_accessible` to `false`. The default value is `true`.

        ```hcl
        resource "aws_redshift_cluster" "example" {
          # ... other configuration ...
          publicly_accessible = false
        }
        ```

        __AWS Console__

        Disable public access to an Amazon Redshift cluster:

        1. Open the Amazon Redshift console at https://console.aws.amazon.com/redshift/.
        2. In the navigation menu, select **Clusters**, then select the name of the cluster with the security group to modify.
        3. Select **Actions**, then select **Modify publicly accessible setting**.
        4. Under **Allow instances and devices outside the VPC to connect to your database through the cluster endpoint**, select **No**.
        5. Select **Confirm**.

        __AWS CLI__

        Use the `modify-cluster` command to set `--no-publicly-accessible`.

        ```bash
        aws redshift modify-cluster \
          --cluster-identifier "test-redshift-cluster" \
          --no-publicly-accessible
        ```
    refs:
      - url: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html
        title: AWS Documentation - Security Hub controls reference
      - url: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/redshift/index.html
        title: AWS Documentation - AWS CLI Command Reference - Redshift
      - url: https://registry.terraform.io/providers/hashicorp/aws/latest/docs
        title: Terraform Documentation - AWS Provider
  - uid: mondoo-aws-security-redshift-cluster-public-access-check-all
    filters: |
      asset.platform == "aws"
    mql: |
      aws.redshift.clusters.all(publiclyAccessible == false)
  - uid: mondoo-aws-security-redshift-cluster-public-access-check-single
    filters: |
      asset.platform == "aws-redshift-cluster"
    mql: |
      aws.redshift.cluster.publiclyAccessible == false
  - uid: mondoo-aws-security-ec2-volume-inuse-check
    title: Ensure EBS volumes attached to EC2 instances are configured for deletion on instance termination
    impact: 60
    props:
      - uid: mondooAWSSecurityEbsVolumeDeleteOnTermination
        title: Defines whether instances should be configured to delete volumes on termination
        mql: "true"
    variants:
      - uid: mondoo-aws-security-ec2-volume-inuse-check-all
      - uid: mondoo-aws-security-ec2-volume-inuse-check-single
    docs:
      desc: |
        Identifying and removing unattached (unused) Elastic Block Store (EBS) volumes in your AWS account can lower the cost of your monthly AWS bill. Deleting unused EBS volumes also reduces the risk of confidential or sensitive data leaving your premises. This check ensures there are no EBS volumes that are not attached to an instance. Additionally, it checks whether archived EC2 instances are configured to delete volumes on termination.
        By default, EC2 instances are configured to delete the data in any EBS volumes associated with the instance, and to delete the root EBS volume of the instance. However, any non-root EBS volumes attached to the instance, at launch or during execution, persist after termination by default.
      audit: |
        __cnspec Shell__

        1. Open a terminal.
        2. Connect to your AWS environment with cnspec shell: `cnspec shell aws`
        3. Run this query:

        ```mql
        aws.ec2.volumes.where( attachments.length == 0 ) {*}
        ```

        Example output:

        ```mql
        mondoo> aws.ec2.volumes.where( attachments.length == 0 ) {*}
        aws.ec2.volumes.where: [
          0: {
            volumeType: "gp2"
            attachments: []
            availabilityZone: "us-west-2a"
            encrypted: false
            id: "vol-0f5661d9f9db6dd3a"
            arn: "arn:aws:ec2:us-west-2:187043755555:volume/vol-0f5661d9f9db6dd3a"
            state: "available"
            tags: {
              Name: "Unattached Test"
            }
          }
        ]
        ```
      remediation: |
        __Terraform__

        In order to prevent this scenario using Terraform, create EC2 instances with embedded EBS blocks. This ensures that any EBS blocks associated with the instance (not only the root) will be deleted on instance termination by having the attribute `ebs_block_device.delete_on_termination` defaulted to `true`.

        ```hcl
        resource "aws_instance" "web" {
            ami                    = <ami_id>
            instance_type          = <instance_flavor>
            ebs_block_device {
              delete_on_termination = true # Default
              device_name           = "/dev/sdh"
            }
        ```

        __AWS Console__

        Delete an EBS volume using the console:

        1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
        2. In the navigation pane, select **Volumes**.
        3. Select the volume to delete and select **Actions, Delete volume**.
        4. Note: If Delete volume is greyed out, the volume is attached to an instance. You must detach the volume from the instance before it can be deleted.
        5. In the confirmation dialog box, select **Delete**.

        __AWS CLI__

        This example command deletes an available volume with the volume ID of vol-049df61146c4d7901. If the command succeeds, it returns no output.

        ```bash
        aws ec2 delete-volume --volume-id vol-049df61146c4d7901
        ```
    refs:
      - url: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-deleting-volume.html
        title: AWS Documentation - Delete an Amazon EBS volume
  - uid: mondoo-aws-security-ec2-volume-inuse-check-all
    filters: asset.platform == "aws"
    mql: |
      aws.ec2.volumes.where(attachments != empty).all(attachments.any(DeleteOnTermination == props.mondooAWSSecurityEbsVolumeDeleteOnTermination))
  - uid: mondoo-aws-security-ec2-volume-inuse-check-single
    filters: asset.platform == "aws-ec2-volume" && aws.ec2.volume.attachments != empty
    mql: |
      aws.ec2.volume.attachments.any(DeleteOnTermination == true)
  - uid: mondoo-aws-security-ebs-snapshot-public-restorable-check
    title: Ensure EBS snapshots are not publicly restorable
    impact: 80
    variants:
      - uid: mondoo-aws-security-ebs-snapshot-public-restorable-check-all
      - uid: mondoo-aws-security-ebs-snapshot-public-restorable-check-single
  - uid: mondoo-aws-security-ebs-snapshot-public-restorable-check-all
    filters: asset.platform == "aws"
    mql: |
      aws.ec2.snapshots.all(createVolumePermission.none(Group == "all"))
  - uid: mondoo-aws-security-ebs-snapshot-public-restorable-check-single
    filters: asset.platform == "aws-ec2-snapshot" || asset.platform == "aws-ebs-snapshot"
    mql: |
      aws.ec2.snapshot.createVolumePermission.none(Group == "all")
  - uid: mondoo-aws-security-efs-encrypted-check
    title: Ensure EFS is configured to encrypt file data using KMS
    impact: 75
    variants:
      - uid: mondoo-aws-security-efs-encrypted-check-all
      - uid: mondoo-aws-security-efs-encrypted-check-single
    docs:
      desc: |
        Amazon EFS supports two forms of encryption for file systems, encryption of data in transit and encryption at rest. This check ensures that all EFS file systems are configured with encryption at rest across all enabled regions in the account.
      audit: |
        __cnspec Shell__

        1. Open a terminal.
        2. Connect to your AWS environment with cnspec shell: `cnspec shell aws`
        3. Run this query:

        ```mql
        aws.efs.filesystems.where( encrypted == false ) {*}
        ```

        Example output:

        ```mql
        aws.efs.filesystems.where: [
          0: {
            tags: {
              Name: "12344375555-mondoo-demo-efs"
              git_file: "terraform/aws/efs.tf"
              git_org: "mondoolabs"
              git_repo: "mondoo-demo-environment"
            }
            id: "fs-0a73947e541509f0e"
            region: "us-west-2"
            name: "12344375555-mondoo-demo-efs"
            kmsKey: null
            encrypted: false
            arn: "arn:aws:elasticfilesystem:us-west-2:12344375555:file-system/fs-0a73947e541509f0e"
          }
        ]
        ```
      remediation: |
        __Terraform__

        You can use this code snippet to create a KMS encrypted EFS.

        Note: `kms_key_id` attribute is optional, and a key will be created if you don't pass a KMS key ID.

        ```hcl
        resource "aws_efs_file_system" "encrypted-efs" {
          creation_token = "my-kms-encrypted-efs"
          encrypted      = true
          kms_key_id     = "arn:aws:kms:us-west-2:12344375555:key/16393ebd-3348-483f-b162-99b6648azz23"
          tags = {
            Name = "MyProduct"
          }
        }
        ```

        __AWS Console__

        To learn how to configure EFS with encryption using the AWS console, read [Encrypting a file system at rest using the console](https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html).

        __AWS CLI__

        Note: Creating EFS from the console enables encryption at rest by default. EFS created using the CLI, API or SDK do not have encryption at rest by default. This example lets you create an encrypted file system in your infrastructure:

        ```bash
        aws efs create-file-system \
        --backup \
        --encrypted \
        --region us-east-1 \
        ```
    refs:
      - url: https://docs.aws.amazon.com/efs/latest/ug/security-considerations.html
        title: AWS Documentation - Security in Amazon EFS
      - url: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/efs_file_system
        title: Terraform Registry - aws_efs_file_system resource
      - url: https://docs.aws.amazon.com/efs/latest/ug/creating-using-create-fs.html#creating-using-fs-part1-cli
        title: AWS Documentation - Creating a file system using the AWS CLI
  - uid: mondoo-aws-security-efs-encrypted-check-all
    filters: |
      asset.platform == "aws"
    mql: |
      aws.efs.filesystems.all(encrypted == true)
      aws.efs.filesystems.all(kmsKey != empty)
  - uid: mondoo-aws-security-efs-encrypted-check-single
    filters: |
      asset.platform == "aws-efs-filesystem"
    mql: |
      aws.efs.filesystem.encrypted == true
      aws.efs.filesystem.kmsKey != empty
  - uid: mondoo-aws-security-cloudwatch-log-group-encrypted
    title: Ensure CloudWatch logs are encrypted at rest using KMS CMKs
    impact: 70
    mql: |
      aws.cloudwatch.logGroups.all(kmsKey != empty)
  - uid: mondoo-aws-security-elb-deletion-protection-enabled
    title: Ensure Application Load Balancers are Configured with deletion protection enabled
    impact: 70
    mql: |
      aws.elb.loadBalancers.all(attributes.any(Key == "deletion_protection.enabled"))
      aws.elb.loadBalancers.all(attributes.where(Key == "deletion_protection.enabled").all(Value == true))
  - uid: mondoo-aws-security-elasticsearch-encrypted-at-rest
    title: Ensure Amazon OpenSearch Service Domains are Configured with Encryption-at-Rest
    impact: 70
    mql: |
      aws.es.domains.all(encryptionAtRestEnabled == true)
  - uid: mondoo-aws-security-rotation-customer-created-cmks-enabled
    title: Ensure rotation for customer-managed keys (CMKs) is enabled
    impact: 80
    mql: |
      aws.kms.keys
        .where(metadata.KeyState == "Enabled")
        .where(metadata.KeySpec == "SYMMETRIC_DEFAULT")
        .all(keyRotationEnabled == true)
  - uid: mondoo-aws-security-sagemaker-notebook-instance-kms-key-configured
    title: Ensure SageMaker notebook instances are configured to use KMS
    impact: 50
    mql: |
      aws.sagemaker.notebookInstances.all(details.kmsKey != empty)
    docs:
      desc: |
        It is highly recommended that AWS SageMaker notebooks be configured to use AWS Key Management Service (KMS) keys to encrypt data at rest. By enabling KMS encryption, you can ensure that sensitive data, including machine learning models, datasets, and notebook outputs, are protected from unauthorized access. Without KMS encryption, data stored in SageMaker could be vulnerable to potential breaches or insider threats.
  - uid: mondoo-aws-security-cloud-trail-encryption-enabled
    title: Ensure CloudTrail trails are configured to use the server-side encryption KMS
    impact: 70
    mql: |
      aws.cloudtrail.trails.all(kmsKey != empty)
    docs:
      desc: |
        This check ensures CloudTrail is configured to use the server-side encryption (SSE) AWS KMS key encryption. The check passes if the KmsKeyId is defined.

        To learn more about CloudTrail encryption at rest, read:

          - [Server Side Encryption with AWS KMS-managed key (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html)
          - [Amazon Server Side Encryption with Amazon S3-managed encryption keys (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html)
      audit: |
        __cnspec Shell__

        1. Open a terminal.
        2. Connect to your AWS environment with cnspec shell: `cnspec shell aws`
        3. Run this query:

        ```mql
        aws.cloudtrail.trails.all(
          kmsKey != empty
        )
        ```

        Example output:

        ```mql
        [failed] [].all()
          actual:   [
            0: aws.cloudtrail.trail id = arn:aws:cloudtrail:us-east-1:053121068929:trail/s3-data-events
          ]
        ```
      remediation: |
        __AWS Console__
        Enable encryption for CloudTrail logs:

        1. Open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/.
        2. Select **Trails**.
        3. Select the trail to update.
        4. Under **General details**, select **Edit**.
        5. For **Log file SSE-KMS encryption**, select **Enabled**.
        6. For Create a new KMS key, either:

          - To create a key, select **New**. Then in **AWS KMS alias**, enter an alias for the key. The key is created in the same Region as the S3 bucket.
          or:
          * To use an existing key, select **Existing** and from **AWS KMS alias**, select the key.

          Note: The AWS KMS key and S3 bucket must be in the same Region.
        7. Select **Save**.
  - uid: mondoo-aws-security-secgroup-restricted-ssh
    title: Ensure security groups restrict incoming SSH traffic
    impact: 90
    mql: |
      aws.ec2.securityGroups.where(ipPermissions.any(
        ipRanges.contains('0.0.0.0/0'))).all(
          ipPermissions.none(fromPort <= 22 && toPort >= 22 && toPort != 0)
       )
    docs:
      desc: |
        It is highly recommended that AWS security groups not permit access to SSH (port 22) from the internet (0.0.0.0/0) due to the significant security risks associated with unrestricted remote host management. Allowing open SSH access exposes instances to brute force attacks, credential stuffing, and exploitation of vulnerabilities in the RDP protocol. Attackers frequently scan for open RDP ports, making publicly accessible instances prime targets for unauthorized access attempts.

        Instead, you should restrict access to only known and trusted IP addresses or secure access using a bastion host, a VPN, or the AWS Systems Manager Session Manager.
  - uid: mondoo-aws-security-secgroup-restricted-vnc
    title: Ensure security groups restrict incoming VNC traffic
    impact: 90
    mql: |
      aws.ec2.securityGroups.where(ipPermissions.any(
        ipRanges.contains('0.0.0.0/0'))).all(
          ipPermissions.none(fromPort <= 5900 && toPort >= 5900 && toPort != 0)
       )
    docs:
      desc: |
        It is highly recommended that AWS security groups not permit access to VNC (port 5900) from the internet (0.0.0.0/0) due to the significant security risks associated with unrestricted remote host management. Allowing open VNC access exposes instances to brute force attacks, credential stuffing, and exploitation of vulnerabilities in the RDP protocol. Attackers frequently scan for open RDP ports, making publicly accessible instances prime targets for unauthorized access attempts.

        You should restrict access to only known and trusted IP addresses  or secure access using a bastion host, a VPN, or the AWS Systems Manager Session Manager.
  - uid: mondoo-aws-security-secgroup-restricted-rdp
    title: Ensure security groups restrict incoming RDP traffic
    impact: 90
    mql: |
      aws.ec2.securityGroups.where(ipPermissions.any(
        ipRanges.contains('0.0.0.0/0'))).all(
          ipPermissions.none(fromPort <= 3389 && toPort >= 3389 && toPort != 0)
       )
    docs:
      desc: |
        It is highly recommended that AWS security groups not permit access to RDP (port 3389) from the internet (0.0.0.0/0) due to the significant security risks associated with unrestricted remote desktop access. Allowing open RDP access exposes instances to brute force attacks, credential stuffing, and exploitation of vulnerabilities in the RDP protocol. Attackers frequently scan for open RDP ports, making publicly accessible instances prime targets for unauthorized access attempts.

        You should restrict access to only known and trusted IP addresses  or secure access using a bastion host, a VPN, or the AWS Systems Manager Session Manager.