config.yaml

id: 'opencspm-darkbit-enterprise-controls'
title: 'Darkbit Enterprise Controls'
description: 'This checks custom things'
controls:
  - id: darkbit-aws-4
    title: RDS Clusters Should Span Multiple Availability Zones
    description:
      All RDS Clusters that serve as a critical component of the infrastructure
      should be running in multiple availability-zones to maintain availability during
      zone failures or underlying hardware failures.
    remediation:
      Convert all critical RDS Instances to span multiple availability zones.  For
      non-SQL Server or Amazon Aurora instance types, this can be performed online without
      downtime, although performance degradation will occur during the process.
    validation: |
      Run `aws rds describe-db-clusters --region <region> --output json |
      jq -r '.DBClusters[] | select(.Engine!="docdb") | "(.DBClusterArn) (.MultiAZ)"'`
      and `aws rds describe-db-instances --region <region> --output json | jq -r '.DBInstances[]
      | select(.Engine!="docdb") | "(.DBInstanceArn) (.MultiAZ)"'` and ensure that all
      entries are `true`.
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: RDS Multiple Availability Zones
        url: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html
    tags:
    - aws-cfg:
      - aws-cfg-rds-multi-az-support
    - nist-csf:
      - nist-csf-id
      - nist-csf-id.be
      - nist-csf-id.be-5
      - nist-csf-pr
      - nist-csf-pr.ds
      - nist-csf-pr.ds-4
      - nist-csf-pr.pt
      - nist-csf-pr.pt-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-CP-10
      - nist-800-53-rev4-SC-5
      - nist-800-53-rev4-SC-36
    - nist-800-171:
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(7)(i)
    - fedramp-moderate:
      - fedramp-moderate-CP-10
      - fedramp-moderate-SC-5
    - fedramp-low:
      - fedramp-low-CP-10
    - cmmc-level5:
      - cmmc-level5-SC.3.180
      - cmmc-level5-RE.5.140
    - cmmc-level4:
      - cmmc-level4-SC.3.180
    - cmmc-level3:
      - cmmc-level3-SC.3.180
    - aws-wa-reliability:
      - aws-wa-reliability-REL-10
    - aws
  - id: darkbit-aws-7
    title: Custom IAM Policies Should Not Allow Escalation to Admin
    description:
      A custom IAM policy was created that allows administrative access or
      specific permissions that allow escalation to administrative permissions.  For
      example, `iam:*`, `sts:AssumeRole` on `*` resources, or `iam:PassRole` in combination
      with `ec2:runInstances` or `lambda:*`.  This can indicate a misconfiguration that
      accidentally overgrants highly privileged access.
    remediation:
      Review the IAM policy for accuracy and necessity.  Refactor the policy
      and avoid granting `iam:*` or `sts:AssumeRole` on `*` resources as it provides
      a "sudo"-like ability to become the account administrator.  Consider removing
      the custom IAM policy and assigning the "AdministratorAccess" policy instead if
      full permissions are absolutely necessary.
    validation: N/A
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: Administrator IAM
        url: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
      - aws
  - id: darkbit-aws-14
    title: Managed Streaming Kafka Instances Should Require Authentication
    description:
      Amazon Managed Streaming Kafka instances are not configured to require
      authentication via client certificates.  Access control is performed solely via
      network level restrictions.  In the event of a compromise, an attacker would have
      direct access to these datastores from inside the VPC to be able to exfiltrate
      sensitive contents or manipulate/disrupt their operation.
    remediation:
      Configure all Managed Streaming Kafka cluster instances with client
      certificate authentication.  Validate that all client software and libraries that
      interface with these services have support for authentication, and implement the
      necessary functionality, if possible.  Reconfigure all deployments to leverage
      these credentials.
    validation:
      Run `aws kafka list-clusters --region <region> --output json | jq -r
      '.ClusterInfoList[] | "(.ClusterArn) (.ClientAuthentication.Tls.CertificateAuthorityArnList[])"'`
      and ensure a CA ARN is listed for every cluster.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Managed Streaming Kafka Authentication
        url: https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-6
          - nist-csf-pr.ds
          - nist-csf-pr.ds-5
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
      - aws
  - id: darkbit-aws-15
    title: Users Should Not Have Unused Access Keys
    description:
      AWS Access Keys that have never been used represent an unnecessary
      exposure of valid credentials and should be removed.
    remediation:
      Remove the access keys that have never been used, and inform users
      that they can create access keys via the UI when necessary in the future.
    validation:
      Run `aws iam get-credential-report --output text | base64 -d | grep
      -v "^<root_account>" | awk -F, '{print $1 " "$11 " "$16}' | grep " N/A N/A"` and
      ensure no entries are present.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: AWS Access Keys
        url: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
          - nist-csf-pr.ac-4
      - aws
  - id: darkbit-aws-16
    title: Inline IAM Role Policies Should Not Allow Wildcard Actions
    description:
      AWS IAM Role policies attached to IAM roles should be scoped to least-privileged
      access and avoid the use of wildcards to ensure the original intention of the
      policy is not modified over time.  Should AWS add a new action to an existing
      API, the original policy will automatically grant access, and that might not be
      desired.
    remediation:
      Review the IAM Policy and replace the wildcard entry with the specific
      permissions desired.
    validation: N/A
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: IAM Access Control
        url: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html
      - text: IAM Policy Actions and Resources
        url: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
      - aws
  - id: darkbit-aws-19
    title: Users Should Have Logged in Within the Past 90 Days
    description:
      Users inactive for the past three months are often an indication that
      their account is no longer required and the risk of exposure of their credentials
      is unnecessary.
    remediation:
      Consider disabling or removing user accounts that are no longer in
      use.
    validation:
      Run `aws iam get-credential-report --output text | base64 -d | awk -F,
      '{print $2 ", "$5", "$11", "$16", "$22}'` and review the dates listed for lack
      of use in the past 90 days.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: AWS Unused Credentials
        url: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
      - aws
  - id: darkbit-aws-21
    title: Security Groups Should Not Allow All Ports From All Hosts
    description:
      Security Groups that all all ports from any CIDR range are effectively
      disabling firewall protection to the attached service or system.
    remediation:
      For each security group, review the application needs for protocols
      and ports, and reconfigure the security group to only grant access to those.
    validation:
      Run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]'
      --output json | jq -r '.[] | . as $group | .IpPermissions[] | select(.IpRanges[].CidrIp=="0.0.0.0/0"
      or .Ipv6Ranges[].CidrIpv6=="::/0") | select(.IpProtocol=="-1" or (.FromPort==null
      and (.ToPort==null or .ToPort==65535))) | "($group.GroupName)"'` and ensure no
      entries are listed.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: VPC Security Groups
        url: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
    tags:
    - aws-cfg:
      - aws-cfg-restricted-common-ports
      - aws-cfg-vpc-sg-open-only-to-authorized-ports
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.PT-4
      - nist-csf-DE.AE-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.20
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
      - nist-800-171-3.13.6
      - nist-800-171-3.4.7
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(e)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-CM-2
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.3.068
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
      - cmmc-level5-RM.4.151
      - cmmc-level5-SC.5.230
      - cmmc-level5-SC.5.208
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.3.068
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
      - cmmc-level4-RM.4.151
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.3.068
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.016
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
    - aws
  - id: darkbit-aws-22
    title: Security Groups Should Not Allow Access to Postgresql TCP/5432 From All Hosts
    description:
      Database systems commonly hold critical application data, credentials,
      and other sensitive information, and network access control is a key part of a
      defense in depth strategy.  Access to database systems over the network should
      be restricted to the application systems and a small list of administrative systems
      to increase the attack cost of accessing that data in a compromise.
    remediation:
      For each security group, review the application needs for applications
      and administrative systems that access the database, and reconfigure the security
      group to only grant access to those.
    validation:
      Run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]'
      --output json | jq -r --arg PROTO tcp --arg PORT 5432 '.[] | . as $group | .IpPermissions[]
      | select(.IpRanges[].CidrIp=="0.0.0.0/0" or .Ipv6Ranges[].CidrIpv6=="::/0" or
      .IpRanges==[] or .Ipv6Ranges==[]) | select((.IpProtocol==$PROTO or .IpProtocol=="-1")
      and ((.FromPort==null or .FromPort<=($PORT|tonumber)) and (.ToPort==null or .ToPort>=($PORT|tonumber)))
      and (.UserIdGroupPairs==[])) | "($group.GroupId) ($group.GroupName)"'` and ensure
      no entries are present.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: RDS Security Groups
        url: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html
    tags:
    - aws-cfg:
      - aws-cfg-restricted-common-ports
      - aws-cfg-vpc-sg-open-only-to-authorized-ports
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.PT-4
      - nist-csf-DE.AE-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.20
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
      - nist-800-171-3.13.6
      - nist-800-171-3.4.7
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(e)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-CM-2
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.3.068
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
      - cmmc-level5-RM.4.151
      - cmmc-level5-SC.5.230
      - cmmc-level5-SC.5.208
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.3.068
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
      - cmmc-level4-RM.4.151
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.3.068
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.016
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
    - aws
  - id: darkbit-aws-24
    title: Unused Security Groups Should Not Be Defined
    description:
      Unused security groups do not present an immediate risk, they can and
      should be removed to avoid confusion.
    remediation:
      Verify that the security groups are no longer in use and delete them
      via the AWS console or CLI.
    validation:
      'Run `for i in $(aws ec2 describe-security-groups --region <region>
      --output json | jq -r ''.SecurityGroups[].GroupId''); do echo -n "$i: "; aws ec2
      describe-network-interfaces --region <region> --filters "Name=group-id,Values=${i}"
      --query "length(NetworkInterfaces)" --output text; done` in each region and ensure
      all non-default security groups have at least one attachment.'
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: VPC Security Groups
        url: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
    tags:
    - aws-cfg:
      - aws-cfg-ec2-security-group-attached-to-eni
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-2.4
    - nist-csf:
      - nist-csf-PR.DS-3
    - nist-800-171:
      - nist-800-171-3.4.1
    - cmmc-level5:
      - cmmc-level5-CM.2.061
    - cmmc-level4:
      - cmmc-level4-CM.2.061
    - cmmc-level3:
      - cmmc-level3-CM.2.061
    - cmmc-level2:
      - cmmc-level2-CM.2.061
    - aws-wa-security:
      - aws-wa-security-SEC-5
    - aws
  - id: darkbit-aws-25
    title: Elastic Load Balancers Should Have Logging Enabled
    description:
      Enabling access logging on the Elastic Load Balancer is useful for
      detecting and investigating potential attacks, malicious activity, or misuse of
      backend resources. Both PCI and HIPAA compliance standards require network access
      logging to environments containing sensitive data.
    remediation:
      For each load balancer protecting an administrative web service or
      a service that does not have native request logging, edit the Elastic Load Balancer
      to enable access logging and point those logs to a designated S3 bucket for further
      review and/or processing.
    validation: |-
      For ELBs, run `for i in $(aws elb describe-load-balancers --region <region> --query 'LoadBalancerDescriptions[*].LoadBalancerName' --output text); do echo -n "$i: "; aws elb describe-load-balancer-attributes --region <region> --load-balancer-name $i --query 'LoadBalancerAttributes.AccessLog.Enabled'; done` for each region and ensure each returns `true`.

      For ELBv2, run `for i in $(aws elbv2 describe-load-balancers --region <region> --query 'LoadBalancerDescriptions[*].LoadBalancerArn' --output text); do echo -n "$i: "; aws elbv2 describe-load-balancer-attributes --region <region> --load-balancer-arn $i --query Attributes[*] --output text|grep "^access_logs.s3.enabled"|cut -f2; done` for each region and ensure each returns `true`.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Load Balancer Access Logging
        url: http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html
    tags:
    - aws-cfg:
      - aws-cfg-elb-logging-enabled
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-10.3.1
      - pci-dss-3.2.1-10.3.2
      - pci-dss-3.2.1-10.3.3
      - pci-dss-3.2.1-10.3.4
      - pci-dss-3.2.1-10.3.5
      - pci-dss-3.2.1-10.3.6
    - nist-csf:
      - nist-csf-ID.AM-3
      - nist-csf-PR.DS-5
      - nist-csf-PR.PT-1
      - nist-csf-DE.AE-1
      - nist-csf-DE.AE-3
      - nist-csf-DE.AE-4
      - nist-csf-DE.CM-1
      - nist-csf-DE.CM-7
    - nist-800-53-rev4:
      - nist-800-53-rev4-AU-2(a)(d)
      - nist-800-53-rev4-AU-3
      - nist-800-53-rev4-AU-12(a)(c)
    - nist-800-171:
      - nist-800-171-3.1.12
      - nist-800-171-3.13.1
      - nist-800-171-3.14.6
      - nist-800-171-3.14.7
      - nist-800-171-3.3.1
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(D)
      - hipaa-164.308(a)(3)(ii)(A)
      - hipaa-164.308(a)(6)(ii)
      - hipaa-164.312(b)
    - fedramp-moderate:
      - fedramp-moderate-AU-2(a)(d)
      - fedramp-moderate-AU-3
      - fedramp-moderate-AU-12(a)(c)
    - fedramp-low:
      - fedramp-low-AU-2
    - cmmc-level5:
      - cmmc-level5-AU.2.041
      - cmmc-level5-AU.2.042
      - cmmc-level5-SI.2.217
      - cmmc-level5-AU.5.055
      - cmmc-level5-SI.5.223
    - cmmc-level4:
      - cmmc-level4-AU.2.041
      - cmmc-level4-AU.2.042
      - cmmc-level4-SI.2.217
    - cmmc-level3:
      - cmmc-level3-AU.2.041
      - cmmc-level3-AU.2.042
      - cmmc-level3-SI.2.217
    - cmmc-level2:
      - cmmc-level2-AU.2.041
      - cmmc-level2-AU.2.042
      - cmmc-level2-SI.2.217
    - aws-wa-security:
      - aws-wa-security-SEC-4
    - aws
  - id: darkbit-aws-26
    title: Application Load Balancers Should Have Web Application Firewall (WAF) Enabled
    description:
      The AWS Web Application Firewall (WAF) service implements application-specific
      rules that block common attack patterns that can affect application availability,
      compromise security, or consume excessive resources.
    remediation:
      For each application load balancer protecting an administrative web
      service, edit the Application Load Balancer to enable the Web Application Firewall
      protection.
    validation:
      'Run `for i in $(aws wafv2 list-web-acls --region <region> --output
      json | jq -r ''.WebACLs[] | "(.WebACLId)"''); do echo -n "$i: "; aws wafv2 get-web-acl
      --region <region> --web-acl-id $i; done` in each region.  Then, run `aws wafv2
      list-resources-for-web-acl --web-acl-arn <acl_arn>` and verify it maps to an active
      load balancer.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: ALB Web Application Firewalls
        url: https://aws.amazon.com/blogs/aws/aws-web-application-firewall-waf-for-application-load-balancers/
      - text: WAF Security Automations
        url: https://aws.amazon.com/solutions/aws-waf-security-automations/
    tags:
    - aws-cfg:
      - aws-cfg-alb-waf-enabled
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SI-4(a)(b)(c)
    - nist-800-171:
      - nist-800-171-3.13.1
    - fedramp-moderate:
      - fedramp-moderate-SC-7
      - fedramp-moderate-SI-4(a)(b)(c)
    - fedramp-low:
      - fedramp-low-SC-7
    - cmmc-level2:
      - cmmc-level2-AC.1.003
      - cmmc-level2-SI.2.216
    - cmmc-level1:
      - cmmc-level1-AC.1.003
    - aws-wa-security:
      - aws-wa-security-SEC-5
    - nist-csf:
      - nist-csf-pr
      - nist-csf-pr.ds
      - nist-csf-pr.ds-2
      - nist-csf-pr.ds-5
      - nist-csf-pr.pt
      - nist-csf-pr.pt-4
      - nist-csf-pr.pt-5
    - aws
  - id: darkbit-aws-27
    title: Security Groups Should Not Allow Ingress From All Hosts
    description:
      AWS Security Groups that permit inbound/ingress access from any IP
      address (0.0.0.0/0) should be reviewed for necessity to prevent unintended exposure
      of services and systems protected by that security group.
    remediation:
      For each security group, assess whether the attached service requires
      access from any IP address.  If it doesn't, consider reducing the source IP ranges
      to a specific set of subnets.
    validation:
      Run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]'
      --output json | jq -r '.[] | . as $group | .IpPermissions[] | select(.IpRanges[].CidrIp=="0.0.0.0/0"
      or .Ipv6Ranges[].CidrIpv6=="::/0") | "($group.GroupName)"' | sort -u` and ensure
      only the desired entries are listed.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: VPC Security Groups
        url: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
    tags:
    - aws-cfg:
      - aws-cfg-restricted-common-ports
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.PT-4
      - nist-csf-DE.AE-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.20
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
      - nist-800-171-3.13.6
      - nist-800-171-3.4.7
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(e)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-CM-2
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.3.068
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
      - cmmc-level5-RM.4.151
      - cmmc-level5-SC.5.230
      - cmmc-level5-SC.5.208
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.3.068
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
      - cmmc-level4-RM.4.151
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.3.068
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.016
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
    - aws
  - id: darkbit-aws-33
    title: EC2 Instances Should Not Be Older Than 365 Days
    description:
      EC2 instances that were created over a year ago tend to be managed
      via manual processes, and that can often mean these instances have not been rebuilt
      using newer operating system base images or are in need of security updates to
      be applied.
    remediation:
      For each instance, review the operating system configuration to ensure
      it is still receiving security updates, validate that all security updates are
      applied, and consider using infrastructure-as-code practices to codify their creation
      to remove manual management practices. Further, using autoscaling groups, even
      for a single instance, can ensure that the correct number of systems are always
      available and configured from a known, trusted state.
    validation: |
      Run `if date -v-365d > /dev/null 2>&1; then OLDDATE="$(date -v-365d
      +%Y-%m-%d)"; else OLDDATE="$(date --date="-365 days" +%Y-%m-%d)"; fi; aws ec2
      describe-instances --region <region> --query "Reservations[].Instances[?LaunchTime<=$OLDDATE][].{id:
      InstanceId, launched: LaunchTime}" --output json | jq -r '.[] | "(.id) (.launched)"'`
      and ensure no instances are listed.
    impact: 5
    nodes:
      - AWS_EC2_INSTANCE
    refs:
      - text: AWS Supported Operating Systems Versions
        url: https://docs.aws.amazon.com/systems-manager/latest/userguide/prereqs-operating-systems.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-2
      - aws
  - id: darkbit-aws-36
    title: S3 Buckets Should Have Object Versioning and MFA Deletion Protection Enabled
    description:
      S3 Buckets that store sensitive data should have object versioning
      enabled to help protect against the overwriting of objects or data loss in the
      event of a compromise.  A concrete example is an S3 bucket that receives audit/access
      logs from CloudWatch or other services.  Without object versioning, an attacker
      might be able to delete evidence of their activities.  With object versioning
      enabled, they won't be able to remove the original version of the log data.  To
      add additional protection against disabling of versioning by an attacker, enable
      the `mfa_delete` setting as the `root` account.
    remediation:
      Enable S3 object versioning on all buckets that store data that requires
      integrity protection.
    validation:
      Run `for i in $(aws s3api list-buckets --query 'Buckets[*].Name' --output
      text); do aws s3api get-bucket-versioning --bucket $i; done` and ensure each bucket
      has a valid versioning configuration present.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: S3 Object Versioning
        url: https://docs.aws.amazon.com/AmazonS3/latest/dev/ObjectVersioning.html
    tags:
    - aws-cfg:
      - aws-cfg-s3-bucket-default-lock-enabled
      - aws-cfg-s3-bucket-versioning-enabled
    - nist-csf:
      - nist-csf-pr
      - nist-csf-pr.ac
      - nist-csf-pr.ac-4
      - nist-csf-pr.ds
      - nist-csf-pr.ds-1
      - nist-csf-pr.ip
      - nist-csf-pr.ip-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-28
    - nist-800-171:
      - nist-800-171-3.13.16
      - nist-800-171-3.3.8
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(c)(1)
      - hipaa-164.312(c)(2)
    - fedramp-moderate:
      - fedramp-moderate-SC-28
    - cmmc-level5:
      - cmmc-level5-AU.3.049
    - cmmc-level4:
      - cmmc-level4-AU.3.049
    - cmmc-level3:
      - cmmc-level3-AU.3.049
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-37
    title: RDS Snapshot Encryption Should Be Enabled
    description:
      AWS provides encryption for RDS snapshots which should be enabled to
      ensure that all data at-rest is encrypted.  If the RDS Instance is encrypted,
      its snapshots will be encrypted automatically.
    remediation:
      Enable RDS Instance encryption and automated backups to automatically
      create encrypted snapshots.  For manually created snapshots, ensure encryption
      is used by specifying a KMS encryption key.  For each existing unencrypted snapshot,
      create a copy of that snapshot while specifying a KMS key and then delete the
      unencrypted version.
    validation:
      Run `aws rds describe-db-snapshots --region <region> --output json |
      jq -r '.DBSnapshots[] | "(.DBSnapshotArn) (.KmsKeyId)"' | grep "null$"` and ensure
      no entries are listed.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: RDS Encryption
        url: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html
    tags:
    - aws-cfg:
      - aws-cfg-rds-snapshot-encrypted
    - nist-csf:
      - nist-csf-pr
      - nist-csf-pr.ds
      - nist-csf-pr.ds-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-28
    - nist-800-171:
      - nist-800-171-3.13.16
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(a)(2)(iv)
      - hipaa-164.312(e)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-SC-28
    - fedramp-low:
      - fedramp-low-SC-13
    - cmmc-level5:
      - cmmc-level5-IA.2.081
      - cmmc-level5-SC.3.191
    - cmmc-level4:
      - cmmc-level4-IA.2.081
      - cmmc-level4-SC.3.191
    - cmmc-level3:
      - cmmc-level3-IA.2.081
      - cmmc-level3-SC.3.191
    - cmmc-level2:
      - cmmc-level2-IA.2.081
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-38
    title: SSM Non-Securestring Parameters Should Not Be Present
    description:
      AWS Systems Manager parameters should be encrypted. This allows their
      values to be used by approved systems, while restricting access to other users
      of the account.
    remediation:
      When creating a new Parameter or Advanced Parameter, specify a symmetric
      KMS key to use to encrypt/decrypt the data stored.  Existing parameters will need
      to be recreated and an IAM Policy added to allow KMS encrypt/decrypt operations
      for all clients that need access.
    validation:
      Run `aws ssm describe-parameters --region <region> --output json | jq
      -r '.Parameters[] | select(.Type!="SecureString") | "(.Name)"'` for each region
      and ensure no entries are present.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Systems Manager Parameter Store
        url: https://docs.aws.amazon.com/kms/latest/developerguide/services-parameter-store.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-1
      - aws
  - id: darkbit-aws-39
    title: Amazon Elasticsearch Domains Should Enforce HTTPS
    description:
      By default, Amazon ES domains do not enforce HTTPS-only access to protect
      communications in transit.
    remediation:
      Amazon ES domains cannot be modified to enable HTTPS-only access and
      require being created with the feature configured on a new ES domain.  For ES
      domains that contain sensitive data, consider enabling encryption on the next
      iteration of the application architecture.
    validation:
      Run `for i in $(aws es list-domain-names --region <region> --query 'DomainNames[*].DomainName'
      --output text); do aws es describe-elasticsearch-domain --region <region> --domain-name
      $i --output json | jq -r '.DomainStatus | "(.DomainName) (.DomainEndpointOptions.EnforceHTTPS)"'
      ; done` in each region and ensure all domains are listed as `true`.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Elasticsearch Domain CLI
        url: https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-createupdatedomains.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-2
          - nist-csf-pr.pt
          - nist-csf-pr.pt-4
      - aws
  - id: darkbit-aws-40
    title: RDS Instance Storage Should Be Encrypted
    description:
      All RDS instances that store or could potentially store sensitive data
      should have at-rest encryption enabled to ensure the integrity of data stored
      within the database. When an RDS Instance is encrypted, all logs, backups, and
      snapshots are also encrypted with the same KMS key.
    remediation:
      Evaluate each RDS database without encryption enabled for its potential
      to store sensitive information, and consider rebuilding the instance to use at-rest
      encryption backed by a KMS key.  Because RDS encryption cannot be enabled on an
      existing instance, a new RDS instance is needed.  To expedite the process and
      to preserve the data, an encrypted snapshot can be created from an unencrypted
      instance, and a new instance can be started from that encrypted snapshot.
    validation:
      Run `aws rds describe-db-instances --region <region> --output json |
      jq -r '.DBInstances[] | "(.DBInstanceArn) (.KmsKeyId)"'` and ensure all instances
      have a KMS Key ID defined.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: RDS Snapshots
        url: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html
      - text: RDS Encryption
        url: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html#Overview.Encryption.Enabling
    tags:
    - aws-cfg:
      - aws-cfg-rds-storage-encrypted
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-3.4
    - nist-csf:
      - nist-csf-pr
      - nist-csf-pr.ds
      - nist-csf-pr.ds-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-13
      - nist-800-53-rev4-SC-28
    - nist-800-171:
      - nist-800-171-3.13.16
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(a)(2)(iv)
      - hipaa-164.312(e)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-SC-28
    - fedramp-low:
      - fedramp-low-SC-13
    - cmmc-level5:
      - cmmc-level5-IA.2.081
      - cmmc-level5-SC.3.191
    - cmmc-level4:
      - cmmc-level4-IA.2.081
      - cmmc-level4-SC.3.191
    - cmmc-level3:
      - cmmc-level3-IA.2.081
      - cmmc-level3-SC.3.191
    - cmmc-level2:
      - cmmc-level2-IA.2.081
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-41
    title: SQS Queues Should Have KMS Encryption Enabled
    description:
      Messages sent to SQS queues can be encrypted using KMS server-side
      encryption, and all SQS queues that handle sensitive data should have SQS encryption
      enabled.
    remediation:
      Review the usage and data transiting each SQS queue, and consider enabling
      KMS encryption on queues handling sensitive data.  Existing queues can be modified
      to add encryption with minimal overhead.
    validation: |
      'For each region, run `for i in $(aws sqs list-queues --region <region>
      --query 'QueueUrls[*]' --output text); do OUT="$(aws sqs get-queue-attributes
      --region <region> --queue-url $i --attribute-names KmsMasterKeyId --output json
      | jq -r '.Attributes.KmsMasterKeyId')"; echo "$i: $OUT"; done` and verify each
      entry lists a KMS Key Id.'
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: SQS Server Side Encryption
        url: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-server-side-encryption.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-1
      - aws
  - id: darkbit-aws-44
    title: Amazon Elasticsearch Domains Should Use Encryption at Rest
    description:
      Amazon Elasticsearch (ES) Domains do not configure at-rest encryption
      by default.  By enabling it, the indices, elasticsearch logs, swap files, data
      in the application directory, and automated snapshots are encrypted using AES-256
      via KMS keys.
    remediation:
      Amazon ES domains cannot be modified to enable encryption at rest and
      require being created with the feature configured on a new ES domain.  For ES
      domains that contain sensitive data, consider enabling encryption on the next
      iteration of the application architecture.
    validation:
      Run `for i in $(aws es list-domain-names --region <region> --query 'DomainNames[*].DomainName'
      --output text); do aws es describe-elasticsearch-domain --region <region> --domain-name
      $i --output json | jq -r '.DomainStatus | "(.DomainName) (.EncryptionAtRestOptions.Enabled)"'
      ; done` in each region and ensure all domains are listed as `true`.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Elasticsearch Domain Encryption at Rest
        url: https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/encryption-at-rest.html
    tags:
    - aws-cfg:
      - aws-cfg-elasticsearch-encrypted-at-rest
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-3.4
    - nist-csf:
      - nist-csf-pr
      - nist-csf-pr.ds
      - nist-csf-pr.ds-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-13
      - nist-800-53-rev4-SC-28
    - nist-800-171:
      - nist-800-171-3.13.16
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(a)(2)(iv)
      - hipaa-164.312(e)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-SC-28
    - fedramp-low:
      - fedramp-low-SC-13
    - cmmc-level5:
      - cmmc-level5-IA.2.081
      - cmmc-level5-SC.3.191
    - cmmc-level4:
      - cmmc-level4-IA.2.081
      - cmmc-level4-SC.3.191
    - cmmc-level3:
      - cmmc-level3-IA.2.081
      - cmmc-level3-SC.3.191
    - cmmc-level2:
      - cmmc-level2-IA.2.081
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-45
    title: Amazon Elasticsearch Domains Should Use Node-to-Node Encryption
    description:
      Each Amazon ES domain—regardless of whether the domain uses VPC access—resides
      within its own, dedicated VPC. This architecture prevents potential attackers
      from intercepting traffic between Elasticsearch nodes and keeps the cluster secure.
      By default, however, traffic within the VPC is unencrypted. Node-to-node encryption
      enables TLS 1.2 encryption for all communications within the VPC.
    remediation:
      Amazon ES domains cannot be modified to enable node-to-node encryption
      and require being created with the feature configured on a new ES domain.  For
      ES domains that contain sensitive data, consider enabling encryption on the next
      iteration of the application architecture.
    validation:
      Run `for i in $(aws es list-domain-names --region <region> --query 'DomainNames[*].DomainName'
      --output text); do aws es describe-elasticsearch-domain --region <region> --domain-name
      $i --output json | jq -r '.DomainStatus | "(.DomainName) (.NodeToNodeEncryptionOptions.Enabled)"'
      ; done` in each region and ensure all domains are listed as `true`.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Elasticsearch Domain Node to Node Encryption
        url: https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/ntn.html
    tags:
    - aws-cfg:
      - aws-cfg-elasticsearch-node-to-node-encryption-check
    - nist-csf:
      - nist-csf-pr
      - nist-csf-pr.ds
      - nist-csf-pr.ds-2
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-8
      - nist-800-53-rev4-SC-8(1)
    - nist-800-171:
      - nist-800-171-3.13.8
      - nist-800-171-3.5.10
    - fedramp-moderate:
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-8
      - fedramp-moderate-SC-8(1)
    - fedramp-low:
      - fedramp-low-SC-7
    - cmmc-level5:
      - cmmc-level5-SC.1.175
      - cmmc-level5-IA.2.081
      - cmmc-level5-AC.3.014
      - cmmc-level5-SC.3.185
    - cmmc-level4:
      - cmmc-level4-SC.1.175
      - cmmc-level4-IA.2.081
      - cmmc-level4-AC.3.014
      - cmmc-level4-SC.3.185
    - cmmc-level3:
      - cmmc-level3-SC.1.175
      - cmmc-level3-IA.2.081
      - cmmc-level3-AC.3.014
      - cmmc-level3-SC.3.185
    - cmmc-level2:
      - cmmc-level2-SC.1.175
      - cmmc-level2-IA.2.081
    - cmmc-level1:
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-9
    - aws
  - id: darkbit-aws-48
    title: Lambda Runtimes in Use Should Have Supported Versions
    description:
      Lambda runtimes should be kept current with recent versions of the
      underlying codebase. Deprecated runtimes should not be used as they no longer
      receive security patching support.
    remediation:
      Reconfigure and redeploy the Lambda function using an updated and supported
      runtime version.
    validation:
      Run `aws lambda list-functions --region <region> --output json | jq
      -r '.Functions[] | "(.FunctionArn) (.Runtime)"'` and review the versions listed
      to ensure none are obsolete.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Supported Lambda Runtime Versions
        url: https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html
      - text: Lambda Runtime Versions
        url: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html
    tags:
      - nist-csf:
          - nist-csf-id
          - nist-csf-id.am
          - nist-csf-id.am-2
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-2
      - aws
  - id: darkbit-aws-49
    title: Lambda Functions Should Be Launched Into a VPC
    description:
      Lambda functions should be created in an AWS VPC to avoid exposure
      to the Internet and to enable communication with VPC resources through NACLs and
      security groups.
    remediation:
      'Consider redeploying the Lambda functions in an AWS VPC to be able
      to take advantage of additional security controls and policies.  Consideration:
      if the Lambda function requires internet access, further steps may be needed to
      ensure the VPC in which the Lambda function is launched has a NAT gateway.'
    validation:
      Run `aws lambda list-functions --region <region> --output json | jq
      -r '.Functions[] | "(.FunctionArn) (.VpcConfig.VpcId)"' | grep -v " vpc-"` in
      each region and review each function to determine if it should be in a VPC or
      not.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Lambda VPC Configuration
        url: https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html
    tags:
    - aws-cfg:
      - aws-cfg-lambda-inside-vpc
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.PT-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
      - hipaa-164.312(e)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.016
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.016
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.016
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.016
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-50
    title: RDS Logs Should Be Sent to Cloudwatch
    description:
      RDS Instances can log database level events to CloudWatch for diagnostics
      as well as audit tracking purposes.
    remediation:
      Ensure that all RDS Instances are configured to ship logs to CloudWatch
      logs, and consider enabling audit and slow query logs to increase the usefulness
      of the information if the RDS type supports those features.  By default, CloudWatch
      log retention is indefinite, but you can configure how long to store log data
      in a log group such that any data older than the current retention setting is
      automatically deleted to save storage costs.
    validation:
      Run `aws rds describe-db-instances --region <region> --output json |
      jq -r '.DBInstances[] | "(.DBInstanceArn) (.EnabledCloudwatchLogsExports)"' |
      grep "null$"` and ensure no entries are listed.
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: RDS Logging
        url: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.html
      - text: CloudWatch Log Retention
        url: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention
    tags:
    - aws-cfg:
      - aws-cfg-rds-logging-enabled
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-2(4)
      - nist-800-53-rev4-AC-2(g)
      - nist-800-53-rev4-AU-2(a)(d)
      - nist-800-53-rev4-AU-3
      - nist-800-53-rev4-AU-12(a)(c)
    - nist-800-171:
      - nist-800-171-3.1.12
      - nist-800-171-3.13.1
      - nist-800-171-3.14.6
      - nist-800-171-3.14.7
      - nist-800-171-3.3.1
      - nist-800-171-3.3.2
    - fedramp-moderate:
      - fedramp-moderate-AC-2(4)
      - fedramp-moderate-AC-2(g)
      - fedramp-moderate-AU-2(a)(d)
      - fedramp-moderate-AU-3
      - fedramp-moderate-AU-12(a)(c)
    - fedramp-low:
      - fedramp-low-AC-2
    - cmmc-level5:
      - cmmc-level5-IA.1.076
      - cmmc-level5-AU.2.041
      - cmmc-level5-AU.2.042
      - cmmc-level5-CM.2.065
      - cmmc-level5-SI.2.217
      - cmmc-level5-AC.3.018
      - cmmc-level5-AU.5.055
      - cmmc-level5-SI.5.223
    - cmmc-level4:
      - cmmc-level4-IA.1.076
      - cmmc-level4-AU.2.041
      - cmmc-level4-AU.2.042
      - cmmc-level4-CM.2.065
      - cmmc-level4-SI.2.217
      - cmmc-level4-AC.3.018
    - cmmc-level3:
      - cmmc-level3-IA.1.076
      - cmmc-level3-AU.2.041
      - cmmc-level3-AU.2.042
      - cmmc-level3-CM.2.065
      - cmmc-level3-SI.2.217
      - cmmc-level3-AC.3.018
    - cmmc-level2:
      - cmmc-level2-IA.1.076
      - cmmc-level2-AU.2.041
      - cmmc-level2-AU.2.042
      - cmmc-level2-CM.2.065
      - cmmc-level2-SI.2.217
    - cmmc-level1:
      - cmmc-level1-IA.1.076
    - aws-wa-security:
      - aws-wa-security-SEC-4
    - nist-csf:
      - nist-csf-id
      - nist-csf-id.gv
      - nist-csf-id.gv-3
      - nist-csf-pr
      - nist-csf-pr.ip
      - nist-csf-pr.ip-6
      - nist-csf-pr.pt
      - nist-csf-pr.pt-1
    - aws
  - id: darkbit-aws-52
    title: GuardDuty Should Be Enabled in All Regions
    description:
      Amazon GuardDuty is a continuous security monitoring service that analyzes
      and processes VPC Flow Logs, AWS CloudTrail event logs, and DNS logs. It uses
      threat intelligence feeds, such as lists of malicious IPs and domains, and machine
      learning to identify unexpected and potentially unauthorized and malicious activity
      within your AWS environment. This can include issues like escalations of privileges,
      uses of exposed credentials, or communication with malicious IPs, URLs, or domains.  It
      is strongly recommended to be enabled in all AWS regions.
    remediation:
      Open the AWS Console to the GuardDuty console, choose Get Started,
      and then choose Enable GuardDuty.  Ensure that all regions are enabled.
    validation:
      Run `for i in $(aws guardduty list-detectors --region us-east-1 --output
      text --query 'DetectorIds[*]' 2> /dev/null); do aws guardduty get-detector --detector-id
      $i --region us-east-1 --query "Status" --output text; done` and ensure all detectors
      are configured to `ENABLED`.
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: AWS GuardDuty
        url: https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html
      - text: AWS GuardDuty Getting Started
        url: https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html
    tags:
    - aws-cfg:
      - aws-cfg-guardduty-enabled-centralized
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-11.4
    - nist-csf:
      - nist-csf-ID.RA-1
      - nist-csf-ID.RA-2
      - nist-csf-ID.RA-3
      - nist-csf-PR.DS-5
      - nist-csf-DE.AE-2
      - nist-csf-DE.AE-4
      - nist-csf-DE.CM-1
      - nist-csf-DE.CM-3
      - nist-csf-DE.CM-4
      - nist-csf-DE.CM-6
      - nist-csf-DE.CM-7
      - nist-csf-DE.DP-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-2(1)
      - nist-800-53-rev4-AC-2(4)
      - nist-800-53-rev4-AC-2(12)(a)
      - nist-800-53-rev4-AC-2(g)
      - nist-800-53-rev4-AC-17(1)
      - nist-800-53-rev4-AU-6(1)(3)
      - nist-800-53-rev4-CA-7(a)(b)
      - nist-800-53-rev4-RA-5
      - nist-800-53-rev4-SA-10
      - nist-800-53-rev4-SI-4(1)
      - nist-800-53-rev4-SI-4(2)
      - nist-800-53-rev4-SI-4(4)
      - nist-800-53-rev4-SI-4(5)
      - nist-800-53-rev4-SI-4(16)
      - nist-800-53-rev4-SI-4(a)(b)(c)
    - nist-800-171:
      - nist-800-171-3.1.12
      - nist-800-171-3.11.2
      - nist-800-171-3.13.1
      - nist-800-171-3.14.1
      - nist-800-171-3.14.2
      - nist-800-171-3.14.3
      - nist-800-171-3.14.4
      - nist-800-171-3.14.6
      - nist-800-171-3.14.7
      - nist-800-171-3.3.1
      - nist-800-171-3.3.4
      - nist-800-171-3.3.5
      - nist-800-171-3.6.1
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(D)
      - hipaa-164.308(a)(3)(ii)(A)
      - hipaa-164.308(a)(6)(i)
      - hipaa-164.308(a)(6)(ii)
      - hipaa-164.312(b)
      - hipaa-164.312(e)(2)(i)
    - fedramp-moderate:
      - fedramp-moderate-AC-2(1)
      - fedramp-moderate-AC-2(4)
      - fedramp-moderate-AC-2(12)(a)
      - fedramp-moderate-AC-2(g)
      - fedramp-moderate-AC-17(1)
      - fedramp-moderate-AU-6(1)(3)
      - fedramp-moderate-CA-7(a)(b)
      - fedramp-moderate-RA-5
      - fedramp-moderate-SA-10
      - fedramp-moderate-SI-4(1)
      - fedramp-moderate-SI-4(16)
      - fedramp-moderate-SI-4(2)
      - fedramp-moderate-SI-4(4)
      - fedramp-moderate-SI-4(5)
      - fedramp-moderate-SI-4(a)(b)(c)
    - fedramp-low:
      - fedramp-low-AC-2
    - cmmc-level2:
      - cmmc-level2-SC.1.175
      - cmmc-level2-SI.1.210
      - cmmc-level2-SI.1.211
      - cmmc-level2-AC.2.013
      - cmmc-level2-IR.2.092
      - cmmc-level2-IR.2.093
      - cmmc-level2-SI.2.214
      - cmmc-level2-SI.2.216
      - cmmc-level2-SI.2.217
    - cmmc-level1:
      - cmmc-level1-SC.1.175
      - cmmc-level1-SI.1.210
      - cmmc-level1-SI.1.211
    - aws-wa-security:
      - aws-wa-security-SEC-4
    - aws
  - id: darkbit-aws-53
    title: RDS Backups With Proper Retention Periods Should Be Enabled
    description:
      AWS provides a streamlined method of backing up RDS instances at a
      regular interval without incurring downtime. This should be enabled to provide
      an option for restoring data in the event of a database compromise or hardware
      failure.  The default retention period is 7 days, but it can be set as high as
      35 days.
    remediation:
      'For each RDS instance, enable automated backups and set the retention
      at or higher than the default of 7 days.  30 days is recommended.  Consideration:
      An outage occurs if you change the backup retention period from 0 to a non-zero
      value or from a non-zero value to 0.'
    validation:
      Run `aws rds describe-db-instances --region <region> --output json |
      jq -r '.DBInstances[] | select((.Engine=="postgres" and .ReadReplicaSourceDBInstanceIdentifier!=null)
      | not) | "(.DBInstanceArn) (.BackupRetentionPeriod)"'` and ensure no entries have
      `0` days retention.
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: RDS Automated Backups
        url: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html
    tags:
    - aws-cfg:
      - aws-cfg-db-instance-backup-enabled
    - nist-csf:
      - nist-csf-ID.BE-5
      - nist-csf-PR.DS-4
      - nist-csf-PR.IP-4
      - nist-csf-PR.PT-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-CP-9(b)
      - nist-800-53-rev4-CP-10
      - nist-800-53-rev4-SI-12
    - nist-800-171:
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(7)(ii)(A)
      - hipaa-164.312(a)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-CP-9(b)
      - fedramp-moderate-CP-10
      - fedramp-moderate-SI-12
    - fedramp-low:
      - fedramp-low-CP-9
    - cmmc-level5:
      - cmmc-level5-RE.2.137
      - cmmc-level5-RE.3.139
      - cmmc-level5-RE.5.140
    - cmmc-level4:
      - cmmc-level4-RE.2.137
      - cmmc-level4-RE.3.139
    - cmmc-level3:
      - cmmc-level3-RE.2.137
      - cmmc-level3-RE.3.139
    - cmmc-level2:
      - cmmc-level2-RE.2.137
    - aws-wa-reliability:
      - aws-wa-reliability-REL-9
    - aws
  - id: darkbit-aws-56
    title: Amazon Elasticsearch Domain Logging Should Be Enabled
    description:
      'Amazon ES exposes three Elasticsearch logs through Amazon CloudWatch
      Logs: error logs, search slow logs, and index slow logs. These logs are useful
      for troubleshooting performance and stability issues, but are disabled by default.'
    remediation:
      Modify the Amazon ES domain via the Logs tab to enable logging to a
      CloudWatch group, and monitor the CloudWatch group for logs of type WARN, ERROR,
      and FATAL severity.
    validation:
      Run `for i in $(aws es list-domain-names --region <region> --query 'DomainNames[*].DomainName'
      --output text); do aws es describe-elasticsearch-domain --region <region> --domain-name
      $i --output json | jq -r '.DomainStatus | "(.DomainName) (.LogPublishingOptions)"'
      ; done` for each region and ensure that each domain listed is not `null` and specifies
      a CloudWatch Group ARN as a destination.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Elasticsearch Domain Logging
        url: https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-slow-logs
    tags:
      - nist-csf:
          - nist-csf-de
          - nist-csf-de.ae
          - nist-csf-de.ae-1
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-1
      - aws
  - id: darkbit-aws-57
    title: Route53 Public Hosted Zone Logging Should Be Enabled
    description:
      Route53 allows for logging queries made to public zones for analysis
      and troubleshooting purposes.  For example, subdomain brute-forcing and reconnaissance,
      excessive lookups indicating short TTLs or misconfigured caching, and for confirming
      when a record can safely be removed.
    remediation:
      Enable CloudWatch logs for Route53 queries to a log group with a retention
      period set on all public zones.
    validation:
      'Run `for i in $(aws route53 list-hosted-zones --query ''HostedZones[*].Id''
      --output text); do OUT="$(aws route53 list-query-logging-configs --hosted-zone-id
      $i | jq -r ''.QueryLoggingConfigs[].CloudWatchLogsLogGroupArn'')"; echo "$i: $OUT";
      done` and ensure each zone has a CloudWatch LogGroup ARN configured.'
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Route53 Query Logs
        url: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html
    tags:
      - nist-csf:
          - nist-csf-de
          - nist-csf-de.ae
          - nist-csf-de.ae-1
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-1
      - aws
  - id: darkbit-aws-59
    title: Amazon ECR Registries Should Not Be Public
    description:
      By default, access to Amazon Elastic Container Registry (ECR) resources
      is denied unless explicitly granted.  For most organizations, there is no need
      to grant access their container images to anonymous users as it could potentially
      be an avenue for leaking source code and secrets baked into container images.
    remediation:
      Ensure that all ECR repositories are not granted a custom access policy
      that permits `Principal`s of `"*"` access to any aspect of the service.
    validation:
      Run `for i in $(aws ecr describe-repositories --region <region> --query
      'repositories[*].{Name:repositoryName}' --output text); do aws ecr get-repository-policy
      --repository-name $i --region <region>; done` in each region and validate that
      the `Principal` field of `"*"` is not granted access.
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: Amazon ECR Registry Policies
        url: https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
      - aws
  - id: darkbit-aws-60
    title: Amazon EKS Clusters Should Be the Latest Version
    description:
      EKS clusters should be running the latest stable version to take advantage
      of the latest features, stability, and performance fixes.
    remediation: |-
      The Kubernetes node version should ideally be identical to the control plane version, but it can trail by up to two minor versions.  This commonly happens during the process of upgrades.  If the latest available version is `1.17`, and the current cluster is running `1.16` on the control plane and `1.15` nodes, the upgrade process is as follows: First, upgrade the `1.15` nodes to `1.16`.  Once the nodes are healthy, upgrade the control plane to `1.17`.  After the control plane is running `1.17`, upgrade the nodes to match.

      Considerations: EKS does not modify any of your Kubernetes add-ons for you during updates.  Be sure to upgrade the versions of the Amazon VPC CNI plugin, DNS (CoreDNS), and KubeProxy in lock-step with the supported Kubernetes versions as per the EKS Cluster Upgrade guidance.  Upgrades of node pools should proceed one node at a time, but during that process, pods will be evicted from nodes and rescheduled/restarted on other nodes up to two times.  Ensure that your applications are configured to have at least two replicas and a pod disruption budget to make sure at least one is running at all times to avoid outages during upgrades.  Also, verify that there is enough cluster workload capacity to handle a single node being removed from the cluster at any given time.
    validation:
      To determine the current version of your cluster, run `kubectl version
      --short`.  The server version should be equivalent to the latest available EKS
      version.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: EKS Upgrades
        url: https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html
      - text: EKS Versions
        url: https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html
    tags:
      - nist-csf:
          - nist-csf-id
          - nist-csf-id.am
          - nist-csf-id.am-2
          - nist-csf-id.ra
          - nist-csf-id.ra-1
      - aws
  - id: darkbit-aws-62
    title: Amazon EKS Cluster Subnets Should Be Available, Non-Default, and Not Automatically
      Map Public IP Addresses
    description:
      In order to help maintain proper separation from other workloads in
      the account and to ensure there are enough IPs available for nodes and pods, AWS
      EKS clusters should be deployed into new Subnets created specifically for the
      cluster.
    remediation:
      Create new, dedicated subnets.  The recommended guidance is at least
      two public and two private subnets.  Redeploy the EKS cluster with these subnets
      configured.
    validation:
      Run `aws eks describe-cluster` to get the list of `subnetIds` under
      the `resourcesVpcConfig` block.  For each subnet, run `aws ec2 describe-subnets`
      and validate that `default-for-az` is `false` and that `mapPublicIpOnLaunch` is
      also `false`.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: EKS VPC Considerations
        url: https://docs.aws.amazon.com/eks/latest/userguide/network_reqs.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-3
          - nist-csf-pr.pt-4
      - aws
  - id: darkbit-aws-63
    title:
      Amazon EKS Cluster Nodegroups Should Not Allow Remote Access From All IP
      Addresses
    description:
      During EKS Nodegroup creation, remote access via SSH to the nodes can
      optionally be configured.  If enabled, it should not specify a security group
      that permits inbound access on TCP/22 from `0.0.0.0/0`.  Instead, it should be
      a known set of CIDR ranges used for administrative purposes.  Without this restriction,
      attackers that can escape pods to become root on a node may be able to add their
      credentials and SSH directly to the node from any IP.
    remediation:
      Identify the security group associated with the nodegroup for remote
      access, and modify the rules to remove `0.0.0.0/0` from the source ranges.  Replace
      it with one or more CIDR ranges used for administration.
    validation:
      Run `aws eks describe-nodegroup` and find the `remoteAccess` > `sourceSecurityGroups`.  Use
      `aws ec2 describe-security-groups` and review the `IpPermissions` for the presence
      of `0.0.0.0/0`.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: EKS Nodegroups"
        url: https://docs.aws.amazon.com/eks/latest/userguide/create-managed-node-group.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-5
          - nist-csf-pr.ma
          - nist-csf-pr.ma-2
          - nist-csf-pr.pt
          - nist-csf-pr.pt-4
      - aws
  - id: darkbit-aws-64
    title: Amazon EKS Cluster Nodegroups Should Span Multiple Availability Zones
    description:
      EKS clusters deploy nodes that follow the zonal locations of the subnets
      defined at cluster creation.  Spreading nodes across two or more subnets allows
      for continued availability of the cluster should a single AWS availability zone
      experience an outage.
    remediation:
      'During EKS cluster creation, configure two to three subnets, each
      in a different availability zone of that region.  Consideration: as traffic goes
      from node to node over zone boundaries, additional network costs will be incurred.'
    validation:
      In each region, run `for i in $(aws eks list-clusters --region <region>
      --output=json| jq -r '.clusters[]'); do aws eks describe-cluster --name $i --region
      <region> --output=json | jq -r '.cluster | "(.arn) (.resourcesVpcConfig.subnetIds
      | length)"'; done` and verify each cluster has 2 or more subnets defined from
      different zones.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Amazon EKS Resiliency
        url: https://docs.aws.amazon.com/eks/latest/userguide/disaster-recovery-resiliency.html
      - text: Amazon EKS VPC Requirements
        url: https://docs.aws.amazon.com/eks/latest/userguide/network_reqs.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - aws
  - id: darkbit-aws-65
    title: Amazon EKS Cluster Nodegroups Should Have Autoscaling Enabled
    description:
      Nodegroups with a fixed capacity running workloads that can scale their
      number of replicas on demand will eventually result in an out-of-capacity situation.  Configuring
      Nodegroups to add and remove workers in direct correlation to workload resource
      usage can save money and improve service resiliency and availability during peak
      load.
    remediation:
      Configure Nodegroups with the desired minimum and maximum worker counts.  Typically,
      the minimum is the number of nodes that can handle idle usage and the maximum
      is the number of nodes that can handle 200% of peak usage.  Deploy the cluster
      autoscaler workload per the EKS guides to handle measuring in-cluster usage and
      signalling to the EC2 APIs to add or remove nodes as needed.
    validation:
      In each region, run `for i in $(aws eks list-clusters --region <region>
      --output=json| jq -r '.clusters[]'); do for j in $(aws eks list-nodegroups --cluster-name
      $i --region <region> --output=json | jq -r '.nodegroups[]'); do echo -n "$i ";aws
      eks describe-nodegroup --cluster-name $i --nodegroup-name $j --region <region>
      | jq -r '.nodegroup | "(.scalingConfig)"'; done; done` and ensure all nodegroups
      are configured with appropriate node minimums and maximums.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Amazon EKS Cluster Autoscaler
        url: https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html
      - text: Amazon EKS NodeGroup Creation
        url: https://docs.aws.amazon.com/eks/latest/userguide/create-managed-node-group.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - aws
  - id: darkbit-aws-66
    title:
      Amazon EKS Cluster Nodegroups Should Not Have Extra Node Role IAM Permissions
      Assigned
    description:
      EKS Worker Nodes require certain IAM permissions to properly integrate
      with the AWS environment, and these are delivered to the nodes via Instance IAM
      Roles.  By default, any request to the metadata service from that node, including
      from `pods`, will provide a set of credentials with those permissions.  To avoid
      a compromised `pod` from being able to move laterally to other AWS services, these
      permissions should not include the ability to create instances or read from all
      S3 buckets, for example.
    remediation:
      Create the IAM Role according to the EKS documentation using only the
      `AmazonEKSWorkerNodePolicy`, `AmazonEKS_CNI_Policy`, and `AmazonEC2ContainerRegistryReadOnly`
      managed policies.  If additional permissions are attached, determine if the workloads
      need them to function.  Remove those permissions and use EKS Pod Identity to associate
      those permissions directly to the specific Kubernetes Service Account attached
      to those workloads.
    validation:
      Ensure that the `AmazonEKSWorkerNodePolicy`, `AmazonEKS_CNI_Policy`,
      and `AmazonEC2ContainerRegistryReadOnly` managed policies are attached to the
      Node IAM role.
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: Amazon EKS Nodegroup IAM Role
        url: https://docs.aws.amazon.com/eks/latest/userguide/worker_node_IAM_role.html
      - text: Amazon EKS Nodegroup Creation
        url: https://docs.aws.amazon.com/eks/latest/userguide/create-managed-node-group.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.pt
          - nist-csf-pr.pt-3
      - aws
  - id: darkbit-aws-68
    title: CloudFront Distributions Should Have Logging Enabled
    description:
      CloudFront Distributions can be configured to log to an S3 bucket several
      times per hour on a best-effort basis for requests to objects by users.  It can
      help with detecting and investigating potential attacks, malicious activity, or
      misuse of backend resources.
    remediation:
      'During the creation or updating of a distribution, configure the logging
      `Bucket` name, `Enabled` as `true`, `IncludeCookies` as `true`, and the `Prefix`
      string with a unique id.  Note: it may take several hours for all locations to
      reliably send all logs.'
    validation:
      In each region, run `for i in $(aws cloudfront list-distributions --region
      <region> --query 'DistributionList.Items[].Id' --output text); do aws cloudfront
      get-distribution --region <region> --id "$i" --query 'Distribution' --output json
      | jq -r '"(.ARN) (.DistributionConfig.Logging.Enabled)"'; done` and ensure all
      distributions return `true`.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Amazon CloudFront Logging
        url: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html
      - text: Amazon CloudFront Logging Options
        url: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesLoggingOnOff
    tags:
      - nist-csf:
          - nist-csf-de
          - nist-csf-de.ae
          - nist-csf-de.ae-1
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-1
      - aws
  - id: darkbit-aws-69
    title: API Gateways Should Have Logging Enabled
    description:
      API Gateway execution logs are automatically managed, and access logging
      is an optional configuration.  To gain insight into the requests to the API Gateway,
      access logging can be enabled to send detailed information about all requests
      to a CloudWatch log group.
    remediation:
      Enable CloudWatch logging of all API Gateway Requests to a CloudWatch
      log group by specifying a CloudWatch Log IAM Role ARN, an Access Log Destination
      ARN, and enabling access logging.
    validation:
      'Run `for i in $(aws apigateway get-rest-apis --region <region> --query
      ''items[*].id'' --output text); do OUT="$(aws apigateway get-stages --region <region>
      --rest-api-id $i --output json | jq -r ''.item[] | "(.stageName) (.methodSettings)"'')";
      echo "$i: $OUT"; done` in each region and ensure that the `methodSettings` indicates
      that logging is enabled.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Amazon API Gateway Logging
        url: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html
    tags:
    - aws-cfg:
      - aws-cfg-api-gw-execution-logging-enabled
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-10.2
    - nist-csf:
      - nist-csf-ID
      - nist-csf-ID.AM
      - nist-csf-ID.AM-3
      - nist-csf-PR
      - nist-csf-PR.PT
      - nist-csf-PR.PT-1
      - nist-csf-DE
      - nist-csf-DE.AE
      - nist-csf-DE.AE-1
      - nist-csf-DE.AE-3
      - nist-csf-DE
      - nist-csf-DE.CM
      - nist-csf-DE.CM-1
      - nist-csf-DE.CM-7
    - nist-800-53-rev4:
      - nist-800-53-rev4-AU-2(a)(d)
      - nist-800-53-rev4-AU-3
      - nist-800-53-rev4-AU-12(a)(c)
    - nist-800-171:
      - nist-800-171-3.1.12
      - nist-800-171-3.13.1
      - nist-800-171-3.14.6
      - nist-800-171-3.14.7
      - nist-800-171-3.3.1
      - nist-800-171-3.3.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(D)
      - hipaa-164.308(a)(3)(ii)(a)
      - hipaa-164.308(a)(6)(ii)
      - hipaa-164.312(b)
    - fedramp-moderate:
      - fedramp-moderate-AU-2(a)(d)
      - fedramp-moderate-AU-3
      - fedramp-moderate-AU-12(a)(c)
    - fedramp-low:
      - fedramp-low-AU-2
    - cmmc-level5:
      - cmmc-level5-AU.2.042
      - cmmc-level5-SI.2.217
      - cmmc-level5-AU.5.055
      - cmmc-level5-SI.5.223
    - cmmc-level4:
      - cmmc-level4-AU.2.042
      - cmmc-level4-SI.2.217
    - cmmc-level3:
      - cmmc-level3-AU.2.042
      - cmmc-level3-SI.2.217
    - cmmc-level2:
      - cmmc-level2-AU.2.042
      - cmmc-level2-SI.2.217
    - aws-wa-security:
      - aws-wa-security-SEC-4
    - aws
  - id: darkbit-aws-70
    title: ACM Certificates Should Have Certificate Transparency Logging Enabled
    description:
      To guard against SSL/TLS certificates that are issued by mistake or
      by a compromised CA, some browsers require that public certificates issued for
      domains be recorded in a certificate transparency log. By default, before the
      Amazon CA issues a publicly trusted SSL/TLS certificate for a domain, it submits
      the certificate to at least two certificate transparency log servers. These servers
      add the certificate to their public databases and return a signed certificate
      timestamp (SCT) to the Amazon CA. The CA then embeds the SCT in the certificate,
      signs the certificate, and issues it. The timestamps are included with other X.509
      extensions.  Certificate transparency logging is automatic when requesting or
      renewing a certificate unless you explicitly opt out.
    remediation: |-
      Certificate Transparency Logging is performed automatically when requesting or renewing a certificate, but opting out may be useful for situations where internal host names or product names are not intended to be made public.  However, Google Chrome no longer trusts certificates that are not registered in a certificate transparency log.

      Passing the `--options CertificateTransparencyLoggingPreference=ENABLED` option to the `aws acm request-certificate` or `aws acm update-certificate-options` calls can re-enable transparency logging.
    validation: |
      'Run `for i in $(aws acm list-certificates --region <region> --query
      'CertificateSummaryList[].CertificateArn' --output text); do OUT="$(aws acm
      describe-certificate --region <region> --certificate-arn $i --query 'Certificate.Options.CertificateTransparencyLoggingPreference')";
      echo "$i: $OUT"; done` in each region and ensure all are listed as `ENABLED` for
      all non-sensitive, external facing certificates.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: ACM Best Practices
        url: https://docs.aws.amazon.com/acm/latest/userguide/acm-bestpractices.html#best-practices-transparency
      - text: ACM Certificate Transparency
        url: https://docs.aws.amazon.com/acm/latest/userguide/acm-concepts.html#concept-transparency
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
          - nist-csf-pr.ac-6
      - aws
  - id: darkbit-aws-71
    title: SQS Queues Should Not Have Their Policy Set as Public
    description:
      The default configuration of SQS queues are to only grant access to
      the queue owner.  However, it's possible to grant access to all/anonymous users
      to an SQS queue by misconfiguring the IAM access policy to grant permissions to
      all Principals `"*"`.  As these queues tend to handle message passing between
      components, this could expose sensitive data or provide a method for tampering
      with application functionality.
    remediation:
      Review the IAM access policies associated with each SQS queue and ensure
      that no permissions are granted to the `"*"` Principal.  The default configuration
      has no custom policy which implicitly grants access only to the owner.
    validation:
      In each region, run `for i in $(aws sqs list-queues --region <region>
      --query 'QueueUrls[*]' --output text); do aws sqs get-queue-attributes --region
      <region> --queue-url $i --attribute-names Policy; done` and validate that the
      policy does not grant unconditional access to the `"*"` Principal.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: SQS Access Policies
        url: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-creating-custom-policies.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
      - aws
  - id: darkbit-aws-73
    title: ACM Certificates Should Not Be Close to Expiration
    description:
      All `ELIGIBLE` AWS Certificate Manager (ACM) Certificates should automatically
      renew near the expiration date if they are still in active use.  Typically, certificates
      that have not been renewed are no longer used.
    remediation: |-
      Review unused and/or expired ACM Certificates if they are no longer needed.  If they are needed, ensure they fit the requirements to be `ELIGIBLE`:

      * Associated with another AWS service, such as Elastic Load Balancing or CloudFront
      * Exported since being issued or last renewed
      * A private certificate issued by calling the ACM RequestCertificate API
      * A private certificate issued through the management console
    validation: |
      'In each region, run `for i in $(aws acm list-certificates --query 'CertificateSummaryList[*].CertificateArn'
      --region <region> --output text); do OUT="$(aws acm describe-certificate --region
      <region> --certificate-arn $i --query 'Certificate' --output json | jq -r '"(.NotAfter)"')";
      NOW="$(date +%s)"; echo "$i: $((($OUT-$NOW)/86400))"; done` and ensure those that
      list negative numbers are no longer needed.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: ACM Managed Renewal
        url: https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html
    tags:
    - aws-cfg:
      - aws-cfg-acm-certificate-expiration-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-3.6.4
    - nist-csf:
      - nist-csf-pr
      - nist-csf-pr.ac
      - nist-csf-pr.ac-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-17(2)
      - nist-800-53-rev4-SC-12
    - nist-800-171:
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-17(2)
      - fedramp-moderate-SC-12
    - aws-wa-security:
      - aws-wa-security-SEC-9
    - aws
  - id: darkbit-aws-74
    title: SNS Topics Should Not Have Their Policy Set as Public
    description:
      The default configuration of SNS topics are to only grant access to
      the queue owner.  However, it's possible to grant access to all/anonymous users
      to an SNS topic by misconfiguring the IAM access policy to grant permissions to
      all Principals `"*"`.  As these topics tend to handle notification messages, this
      could expose sensitive data or provide a method for tampering with messaging functionality.
    remediation:
      Review the IAM access policies associated with each SNS topic and ensure
      that no permissions are granted to the `"*"` Principal.  The default configuration
      has no custom policy which implicitly grants access only to the owner.
    validation:
      Run `for i in $(aws sns list-topics --region <region> --query 'Topics'
      --output text); do echo $i; aws sns get-topic-attributes --query 'Attributes'
      --region <region> --topic-arn $i --output json | jq -r '.Policy' |  jq -r; done`
      in each region and verify that the `Principal` is not `"*"` for any policy.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: SNS Access Policies
        url: https://docs.aws.amazon.com/sns/latest/dg/sns-access-policy-language-using.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
      - aws
  - id: darkbit-aws-76
    title: CloudFront Distributions Should Enforce HTTPS
    description:
      Enforcing HTTPS between viewers and the CloudFront CDN Distribution
      ensures that traffic between the client viewers and edge caching servers cannot
      be intercepted or tampered with.
    remediation:
      After enabling HTTPS enforcement on the CloudFront Distribution, configure
      the web distribution viewer protocol policy to redirect HTTP requests to HTTPS
      requests and/or require viewers to use only the HTTPS protocol to access your
      web content available in the CloudFront distribution cache.
    validation:
      In each region, run `for i in $(aws cloudfront list-distributions --region
      <region> --query 'DistributionList.Items[*].Id' --output text); do aws cloudfront
      get-distribution --region <region> --id $i --output json | jq -r '"(.Distribution.ARN)
      (.Distribution.DistributionConfig.DefaultCacheBehavior.ViewerProtocolPolicy)"';
      done` and verify each distribution shows as `redirect-to-https` and not `allow-all`.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: CloudFront HTTPS Enforcement
        url: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-2
      - aws
  - id: darkbit-aws-77
    title: API Gateways Should Have Client Certificate Enabled to Access the Backend Endpoint
    description:
      To verify that web requests to backend services are originating from
      the correct Amazon API Gateways, client-certificate authentication should be enabled.
    remediation:
      'For each API Gateway API, configure AWS to generate a Client Certificate
      via `aws apigateway generate-client-certificate`, fetch the certificate via `aws
      apigateway get-client-certificate`, and update the API stage to attach the generated
      certificate via `aws apigateway update-stage`.  Configure all backend services
      with a valid TLS certificate and `A` or `CNAME` DNS record, and configure the
      application to validate the client-certificate from that was just generated for
      all requests.  Note: the client certificates automatically generated expire in
      365 days.'
    validation:
      Run `for i in $(aws apigateway get-rest-apis --region <region> --query
      'items[*].id' --output text); do aws apigateway get-stages --region <region> --rest-api-id
      $i --query 'item[*]' --output json | jq -r --arg ID $i '.[] | "($ID) (.stageName)
      (.clientCertificateId)"'; done` and ensure the correct stages are not `null`.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: API Gateway Backend SSL Authentication
        url: https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-client-side-ssl-authentication.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
          - nist-csf-pr.ds
          - nist-csf-pr.ds-2
      - aws
  - id: darkbit-aws-78
    title: API Gateways Should Have a Web Application Firewall (WAF) Access Control List (ACL) Attached
    description:
      AWS WAF is a web application firewall that helps protect web applications
      and APIs from attacks.  It can help protect API Gateway APIs from common web exploits
      such as SQL injection and cross-site scripting (XSS) attacks, and rules can be
      configured to allow or block requests from specified IP address ranges, requests
      from a specific country or region, requests that contain malicious SQL code, or
      requests that contain malicious script.
    remediation:
      Create a Regional Web ACL that contains the AWS WAF managed rules and
      custom rules.  Using the ACL identifier, associate that WAF ACL to the appropriate
      API Stage using `aws waf-regional associate-web-acl`.
    validation:
      Run `for i in $(aws apigateway get-rest-apis --region <region> --query
      'items[*].id' --output text); do aws apigateway get-stages --region <region> --rest-api-id
      $i --query 'item[*]' --output json | jq -r --arg ID $i '.[] | "($ID) (.stageName)
      (.webAclArn)"'; done` and ensure the correct stages are not `null`.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: API Gateway WAF
        url: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html
    tags:
      - nist-csf:
          - nist-csf-de
          - nist-csf-de.cm
          - nist-csf-de.cm-1
          - nist-csf-de.cm-4
          - nist-csf-de.cm-7
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-2
      - aws
  - id: darkbit-aws-79
    title: API Gateways Should Have Authorizers Configured
    description:
      If the API Gateway needs to determine the caller's identity via request
      parameters or implement a custom authorization scheme that uses a bearer token
      authentication strategy such as OAuth or SAML, a Lambda Authorizer should be considered.
    remediation:
      Create a lambda function to handle authorization with customized inputs
      and outputs, configure that function to be used as an API Gateway authorizer,
      and configure an API method to require it.
    validation:
      For each region, run `for i in $(aws apigateway get-rest-apis --region
      <region> --query 'items[*].id' --output text); do aws apigateway get-authorizers
      --region <region> --query 'items[*]' --rest-api-id $i --output json | jq -r --arg
      ID $i '.[] | "($ID) (.type)"'; done` and ensure an entry is listed for each API.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: API Gateway Authorizer
        url: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
      - aws
  - id: darkbit-aws-80
    title: Security Groups Should Not Allow Ingress From All Hosts to Oracle Ports 1521 or 2483
    description:
      Oracle database servers commonly hold application data, credentials,
      and potentially other sensitive information, and network access control is a key
      part of a defense in depth strategy.  Access to Oracle database servers over the
      network should be restricted to the application systems and a small list of administrative
      systems to increase the attack cost of accessing that data in a compromise.
    remediation:
      For each security group, review the application needs for applications
      and administrative systems that access the Oracle server, and reconfigure the
      security group to only grant access to those.
    validation: |-
      Run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]' --output json | jq -r --arg PROTO tcp --arg PORT 1521 '.[] | . as $group | .IpPermissions[] | select(.IpRanges[].CidrIp=="0.0.0.0/0" or .Ipv6Ranges[].CidrIpv6=="::/0" or .IpRanges==[] or .Ipv6Ranges==[]) | select((.IpProtocol==$PROTO or .IpProtocol=="-1") and ((.FromPort==null or .FromPort<=($PORT|tonumber)) and (.ToPort==null or .ToPort>=($PORT|tonumber))) and (.UserIdGroupPairs==[])) | "($group.GroupId) ($group.GroupName)"'` and ensure no entries are present.

      Then, run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]' --output json | jq -r --arg PROTO tcp --arg PORT 2483 '.[] | . as $group | .IpPermissions[] | select(.IpRanges[].CidrIp=="0.0.0.0/0" or .Ipv6Ranges[].CidrIpv6=="::/0" or .IpRanges==[] or .Ipv6Ranges==[]) | select((.IpProtocol==$PROTO or .IpProtocol=="-1") and ((.FromPort==null or .FromPort<=($PORT|tonumber)) and (.ToPort==null or .ToPort>=($PORT|tonumber))) and (.UserIdGroupPairs==[])) | "($group.GroupId) ($group.GroupName)"'` and ensure no entries are present.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: VPC Security Groups
        url: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
    tags:
    - aws-cfg:
      - aws-cfg-restricted-common-ports
      - aws-cfg-vpc-sg-open-only-to-authorized-ports
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.PT-4
      - nist-csf-DE.AE-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.20
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
      - nist-800-171-3.13.6
      - nist-800-171-3.4.7
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(e)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-CM-2
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.3.068
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
      - cmmc-level5-RM.4.151
      - cmmc-level5-SC.5.230
      - cmmc-level5-SC.5.208
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.3.068
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
      - cmmc-level4-RM.4.151
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.3.068
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.016
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
    - aws
  - id: darkbit-aws-81
    title: Security Groups Should Not Allow Ingress From All Hosts to MySQL Port 3306
    description:
      MySQL servers commonly hold application data, credentials, and potentially
      other sensitive information, and network access control is a key part of a defense
      in depth strategy.  Access to MySQL servers over the network should be restricted
      to the application systems and a small list of administrative systems to increase
      the attack cost of accessing that data in a compromise.
    remediation:
      For each security group, review the application needs for applications
      and administrative systems that access the MySQL server, and reconfigure the security
      group to only grant access to those.
    validation:
      Run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]'
      --output json | jq -r --arg PROTO tcp --arg PORT 3306 '.[] | . as $group | .IpPermissions[]
      | select(.IpRanges[].CidrIp=="0.0.0.0/0" or .Ipv6Ranges[].CidrIpv6=="::/0" or
      .IpRanges==[] or .Ipv6Ranges==[]) | select((.IpProtocol==$PROTO or .IpProtocol=="-1")
      and ((.FromPort==null or .FromPort<=($PORT|tonumber)) and (.ToPort==null or .ToPort>=($PORT|tonumber)))
      and (.UserIdGroupPairs==[])) | "($group.GroupId) ($group.GroupName)"'` and ensure
      no entries are present.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: VPC Security Groups
        url: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
    tags:
    - aws-cfg:
      - aws-cfg-restricted-common-ports
      - aws-cfg-vpc-sg-open-only-to-authorized-ports
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.PT-4
      - nist-csf-DE.AE-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.20
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
      - nist-800-171-3.13.6
      - nist-800-171-3.4.7
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(e)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-CM-2
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.3.068
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
      - cmmc-level5-RM.4.151
      - cmmc-level5-SC.5.230
      - cmmc-level5-SC.5.208
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.3.068
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
      - cmmc-level4-RM.4.151
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.3.068
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.016
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
    - aws
  - id: darkbit-aws-82
    title: Security Groups Should Not Allow Ingress From All Hosts to Redis Port 6379
    description:
      Redis servers commonly hold application session data, credentials,
      and potentially other sensitive information, and network access control is a key
      part of a defense in depth strategy.  Access to Redis servers over the network
      should be restricted to the application systems and a small list of administrative
      systems to increase the attack cost of accessing that data in a compromise.
    remediation:
      For each security group, review the application needs for applications
      and administrative systems that access the Redis server, and reconfigure the security
      group to only grant access to those.
    validation: |
      Run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]'
      --output json | jq -r --arg PROTO tcp --arg PORT 6379 '.[] | . as $group | .IpPermissions[]
      | select(.IpRanges[].CidrIp=="0.0.0.0/0" or .Ipv6Ranges[].CidrIpv6=="::/0" or
      .IpRanges==[] or .Ipv6Ranges==[]) | select((.IpProtocol==$PROTO or .IpProtocol=="-1")
      and ((.FromPort==null or .FromPort<=($PORT|tonumber)) and (.ToPort==null or .ToPort>=($PORT|tonumber)))
      and (.UserIdGroupPairs==[])) | "($group.GroupId) ($group.GroupName)"'` and ensure
      no entries are present.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: VPC Security Groups
        url: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
    tags:
    - aws-cfg:
      - aws-cfg-restricted-common-ports
      - aws-cfg-vpc-sg-open-only-to-authorized-ports
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.PT-4
      - nist-csf-DE.AE-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.20
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
      - nist-800-171-3.13.6
      - nist-800-171-3.4.7
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(e)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-CM-2
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.3.068
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
      - cmmc-level5-RM.4.151
      - cmmc-level5-SC.5.230
      - cmmc-level5-SC.5.208
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.3.068
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
      - cmmc-level4-RM.4.151
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.3.068
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.016
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
    - aws
  - id: darkbit-aws-83
    title: Security Groups Should Not Allow Ingress From All Hosts to MongoDB Ports 27017 and 27018
    description:
      MongoDB servers commonly hold application data, credentials, and potentially
      other sensitive information, and network access control is a key part of a defense
      in depth strategy.  Access to MongoDB servers over the network should be restricted
      to the application systems and a small list of administrative systems to increase
      the attack cost of accessing that data in a compromise.
    remediation:
      For each security group, review the application needs for applications
      and administrative systems that access the MongoDB server, and reconfigure the
      security group to only grant access to those.
    validation: |-
      Run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]' --output json | jq -r --arg PROTO tcp --arg PORT 27017 '.[] | . as $group | .IpPermissions[] | select(.IpRanges[].CidrIp=="0.0.0.0/0" or .Ipv6Ranges[].CidrIpv6=="::/0" or .IpRanges==[] or .Ipv6Ranges==[]) | select((.IpProtocol==$PROTO or .IpProtocol=="-1") and ((.FromPort==null or .FromPort<=($PORT|tonumber)) and (.ToPort==null or .ToPort>=($PORT|tonumber))) and (.UserIdGroupPairs==[])) | "($group.GroupId) ($group.GroupName)"'` and ensure no entries are present.

      Then, run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]' --output json | jq -r --arg PROTO tcp --arg PORT 27018 '.[] | . as $group | .IpPermissions[] | select(.IpRanges[].CidrIp=="0.0.0.0/0" or .Ipv6Ranges[].CidrIpv6=="::/0" or .IpRanges==[] or .Ipv6Ranges==[]) | select((.IpProtocol==$PROTO or .IpProtocol=="-1") and ((.FromPort==null or .FromPort<=($PORT|tonumber)) and (.ToPort==null or .ToPort>=($PORT|tonumber))) and (.UserIdGroupPairs==[])) | "($group.GroupId) ($group.GroupName)"'` and ensure no entries are present.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: VPC Security Groups
        url: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
    tags:
    - aws-cfg:
      - aws-cfg-restricted-common-ports
      - aws-cfg-vpc-sg-open-only-to-authorized-ports
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.PT-4
      - nist-csf-DE.AE-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.20
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
      - nist-800-171-3.13.6
      - nist-800-171-3.4.7
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(e)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-CM-2
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.3.068
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
      - cmmc-level5-RM.4.151
      - cmmc-level5-SC.5.230
      - cmmc-level5-SC.5.208
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.3.068
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
      - cmmc-level4-RM.4.151
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.3.068
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.016
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
    - aws
  - id: darkbit-aws-84
    title: Security Groups Should Not Allow Ingress From All Hosts to Cassandra Ports 7199 or 9160 or 8888
    description:
      Cassandra servers commonly hold application data, credentials, and
      potentially other sensitive information, and network access control is a key part
      of a defense in depth strategy.  Access to Cassandra servers over the network
      should be restricted to the application systems and a small list of administrative
      systems to increase the attack cost of accessing that data in a compromise.
    remediation:
      For each security group, review the application needs for applications
      and administrative systems that access the Cassandra server, and reconfigure the
      security group to only grant access to those.
    validation: |-
      Run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]' --output json | jq -r --arg PROTO tcp --arg PORT 7199 '.[] | . as $group | .IpPermissions[] | select(.IpRanges[].CidrIp=="0.0.0.0/0" or .Ipv6Ranges[].CidrIpv6=="::/0" or .IpRanges==[] or .Ipv6Ranges==[]) | select((.IpProtocol==$PROTO or .IpProtocol=="-1") and ((.FromPort==null or .FromPort<=($PORT|tonumber)) and (.ToPort==null or .ToPort>=($PORT|tonumber))) and (.UserIdGroupPairs==[])) | "($group.GroupId) ($group.GroupName)"'` and ensure no entries are present.

      Then, run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]' --output json | jq -r --arg PROTO tcp --arg PORT 9160 '.[] | . as $group | .IpPermissions[] | select(.IpRanges[].CidrIp=="0.0.0.0/0" or .Ipv6Ranges[].CidrIpv6=="::/0" or .IpRanges==[] or .Ipv6Ranges==[]) | select((.IpProtocol==$PROTO or .IpProtocol=="-1") and ((.FromPort==null or .FromPort<=($PORT|tonumber)) and (.ToPort==null or .ToPort>=($PORT|tonumber))) and (.UserIdGroupPairs==[])) | "($group.GroupId) ($group.GroupName)"'` and ensure no entries are present.

      Then, run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]' --output json | jq -r --arg PROTO tcp --arg PORT 8888 '.[] | . as $group | .IpPermissions[] | select(.IpRanges[].CidrIp=="0.0.0.0/0" or .Ipv6Ranges[].CidrIpv6=="::/0" or .IpRanges==[] or .Ipv6Ranges==[]) | select((.IpProtocol==$PROTO or .IpProtocol=="-1") and ((.FromPort==null or .FromPort<=($PORT|tonumber)) and (.ToPort==null or .ToPort>=($PORT|tonumber))) and (.UserIdGroupPairs==[])) | "($group.GroupId) ($group.GroupName)"'` and ensure no entries are present.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: VPC Security Groups
        url: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
    tags:
    - aws-cfg:
      - aws-cfg-restricted-common-ports
      - aws-cfg-vpc-sg-open-only-to-authorized-ports
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.PT-4
      - nist-csf-DE.AE-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.20
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
      - nist-800-171-3.13.6
      - nist-800-171-3.4.7
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(e)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-CM-2
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.3.068
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
      - cmmc-level5-RM.4.151
      - cmmc-level5-SC.5.230
      - cmmc-level5-SC.5.208
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.3.068
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
      - cmmc-level4-RM.4.151
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.3.068
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.016
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
    - aws
  - id: darkbit-aws-85
    title: Security Groups Should Not Allow Ingress From All Hosts to Memcached Port 11211
    description:
      Memcached servers commonly hold application session data, credentials,
      and potentially other sensitive information, and network access control is a key
      part of a defense in depth strategy.  Access to Memcached servers over the network
      should be restricted to the application systems and a small list of administrative
      systems to increase the attack cost of accessing that data in a compromise.
    remediation:
      For each security group, review the application needs for applications
      and administrative systems that access the Memcached server, and reconfigure the
      security group to only grant access to those.
    validation: |
      Run `aws ec2 describe-security-groups --region <region> --query 'SecurityGroups[*]'
      --output json | jq -r --arg PROTO tcp --arg PORT 11211 '.[] | . as $group | .IpPermissions[]
      | select(.IpRanges[].CidrIp=="0.0.0.0/0" or .Ipv6Ranges[].CidrIpv6=="::/0" or
      .IpRanges==[] or .Ipv6Ranges==[]) | select((.IpProtocol==$PROTO or .IpProtocol=="-1")
      and ((.FromPort==null or .FromPort<=($PORT|tonumber)) and (.ToPort==null or .ToPort>=($PORT|tonumber)))
      and (.UserIdGroupPairs==[])) | "($group.GroupId) ($group.GroupName)"'` and ensure
      no entries are present.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: VPC Security Groups
        url: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
    tags:
    - aws-cfg:
      - aws-cfg-restricted-common-ports
      - aws-cfg-vpc-sg-open-only-to-authorized-ports
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.PT-4
      - nist-csf-DE.AE-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.20
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
      - nist-800-171-3.13.6
      - nist-800-171-3.4.7
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(e)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-CM-2
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.3.068
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
      - cmmc-level5-RM.4.151
      - cmmc-level5-SC.5.230
      - cmmc-level5-SC.5.208
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.3.068
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
      - cmmc-level4-RM.4.151
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.3.068
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.016
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
    - aws
  - id: darkbit-aws-86
    title: Amazon Elasticsearch Domains Should Have Amazon Cognito Authentication for Kibana Enabled
    description:
      Amazon Elasticsearch (ES) domains using Elasticsearch 5.1 or later
      can optionally leverage Amazon Cognito for user and password protection for Kibana
      instead of the internal user database.
    remediation:
      Create an Amazon Incognito User Pool and Identity Pool in the same
      AWS region as well as an IAM Role with the `AmazonESCognitoAccess` policy attached.  Finally,
      edit the ES Domain and configure the User Pool, Identity Pool, and specify the
      IAM Role.
    validation:
      Run `for i in $(aws es list-domain-names --region <region> --query 'DomainNames[*].DomainName'
      --output text); do aws es describe-elasticsearch-domain --region <region> --domain-name
      $i --output json | jq -r '.DomainStatus | "(.DomainName) (.CognitoOptions.Enabled)"'
      ; done` in each region and ensure all domains are listed as `true`.
    impact: 3
    nodes:
      - PLACEHOLDER
    refs:
      - text: Elasticsearch Domain Cognito Authentication for Kibana
        url: https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-cognito-auth.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
          - nist-csf-pr.ac-4
      - aws
  - id: darkbit-aws-87
    title: EC2 Instance Metadata Service Version 2 (IMDSv2) Should Be Enabled and Required
    description: |-
      A common attack vector against web applications running in AWS environments is attempting to get Server-Side Request Forgery (SSRF) abilities.  That is, manipulating the web application to retrieve a web address from the hosting server's perspective.  In EC2, accessing the instance metadata via this technique can provide live credentials to the account with the permissions associated with the attached IAM Role.

      AWS provides an improved version of the Instance Metadata API (v2) which requires fetching a short-lived session token and passing that in the header of the metadata API request.  Because most applications vulnerable to SSRF attacks don't also grant control over the request headers, this greatly limits the likelihood that instance metadata credentials can be retrieved in this manner.
    remediation:
      Ensure all SDKs, AWS CLI tools, and custom software that use Role credentials
      on EC2 instances are IMDSv2 compatible versions.  After using CloudWatch to track
      the `MetadataNoToken` metric hitting 0 to indicate the IMDSv1 API is no longer
      used, leverage `aws ec2 modify-instance-metadata-options` to require `HttpTokens`.  No
      restart of the instance is needed.  Consider enforcing all new instances to leverage
      the IMDSv2 API with an IAM condition.
    validation: |
      Run `aws ec2 describe-instances --region <region> --query 'Reservations[*].Instances[*].{HttpTokens:MetadataOptions.HttpTokens,HttpEndpoint:MetadataOptions.HttpEndpoint,InstanceId:InstanceId}'
      --output json | jq -r '.[][] | "(.InstanceId) (.HttpEndpoint) (.HttpTokens)"'`
      in each region.  Verify that if `HttpEnabled` is `enabled` then `HttpTokens` is
      set to `required`.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: Instance Metadata Service v2
        url: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
      - text: Enforcing Instance Metadata Service v2
        url: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-instance-metadata
    tags:
    - nist-csf:
      - nist-csf-pr
      - nist-csf-pr.ac
      - nist-csf-pr.ac-1
      - nist-csf-pr.ac-4
      - nist-csf-pr.ac-6
    - aws-cfg:
      - aws-cfg-ec2-imdsv2-check
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-6
    - fedramp-moderate:
      - fedramp-moderate-AC-6
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.2.007
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.2.007
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.2.007
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.2.007
    - cmmc-level1:
      - cmmc-level1-AC.1.001
    - aws-wa-security:
      - aws-wa-security-SEC-6
    - aws
  - id: darkbit-aws-88
    title: CloudFront Distributions Should Enable the Web Application Firewall (WAF)
    description:
      AWS WAF is a web application firewall that helps protect web applications
      and APIs from attacks.  It can help protect CloudFront Distributions from common
      web exploits such as SQL injection and cross-site scripting (XSS) attacks, and
      rules can be configured to allow or block requests from specified IP address ranges,
      requests from a specific country or region, requests that contain malicious SQL
      code, or requests that contain malicious script.
    remediation:
      During the creation or update of a CloudFront Distribution, associated
      the desired AWS WAF ACL ID.  Use `aws cloudfront create-distribution` or `aws
      cloudfront update-distribution --distribution-config` and specify the ACL ID in
      the `WebACLId` field.
    validation: |
      In each region, run `for i in $(aws cloudfront list-distributions --region
      <region> --query 'DistributionList.Items[*].Id' --output text); do aws cloudfront
      get-distribution --region <region> --id $i --query 'Distribution' --output json
      | jq -r '"(.ARN) (.DistributionConfig.WebACLId)"'; done` and ensure each distribution
      has an associated WAF ACL ID.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: CloudFront Distribution WAF
        url: https://docs.aws.amazon.com/waf/latest/developerguide/cloudfront-features.html
    tags:
      - nist-csf:
          - nist-csf-de
          - nist-csf-de.cm
          - nist-csf-de.cm-1
          - nist-csf-de.cm-4
          - nist-csf-de.cm-7
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-2
      - aws
  - id: darkbit-aws-89
    title: Amazon Email Domains Should Have DKIM Enabled
    description:
      Domain Keys Identified Mail (DKIM) allows senders to sign their email
      messages with a cryptographic key. Email providers then use these signatures to
      verify that the messages weren't modified by a third party while in transit.  Enabling
      DKIM on all sending domains enhances deliverability with DKIM-compliant email
      providers and can reduce the deliverability of email sent from unauthorized sources.
    remediation:
      For all domains that email is sent "From:", use the AWS console to
      visit `SES > Identity Management > Domains` and under `DKIM`, choose `Generate
      DKIM Settings`.  Add the generated CNAME records to the corresponding DNS zone.
    validation:
      Run `for i in $(aws ses list-identities --region <region> --query 'Identities[*]'
      --output text); do aws ses get-identity-dkim-attributes --region <region> --identities
      $i --query 'DkimAttributes' --output json | jq -r --arg i $i '"($i) (.[$i].DkimEnabled)
      (.[$i].DkimVerificationStatus)"'; done` in each region, and verify that all SES
      domains show `true Success`.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Amazon SES DKIM
        url: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-authentication-dkim.html
      - text: Easy Amazon SES DKIM
        url: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-authentication-dkim-easy.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
          - nist-csf-pr.ac-7
      - aws
  - id: darkbit-aws-90
    title: Route53 Domains Should Be Configured to Auto Renew
    description:
      Domain names purchased through Route53 are set to auto renew by default.
      Domains that are in use but not auto-renewed when they expire can quickly be acquired
      by a third-party and used to deny access to resources or to perform domain-takeover
      attacks.
    remediation:
      By default, auto-renewal is enabled.  If it was disabled, re-enable
      auto renewal by visiting the Route53 console's `Registered Domains` page and choosing
      `Enable`.
    validation: |
      Run `aws route53domains list-domains --query 'Domains[*]' --output json
      | jq -r '.[] | "(.DomainName) (.AutoRenew)"'` and validate that all domains in
      use are set to `true`.
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: Route53 Domain Auto Renewal
        url: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-renew.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-3
          - nist-csf-pr.ip-5
      - aws
  - id: darkbit-aws-91
    title: Route53 Domains Should Not Be Expired or Close to Expiration
    description:
      Domain names purchased through Route53 are set to auto renew by default.
      Domains that have expired or are near expiration should be manually reviewed for
      necessity.  If they are still active, verify that they are going to be auto-renewed
      or perform the renewal manually.
    remediation:
      If auto-renewal was disabled on a domain that is close to expiration,
      re-enable it by visiting the Route53 console's `Registered Domains` page and choosing
      `Enable`.
    validation:
      'Run `for i in $(aws route53domains list-domains --query ''Domains[*].DomainName''
      --output text); do OUT="$(aws route53domains list-domains --output json | jq -r
      --arg i $i ''.Domains[] | select(.DomainName==$i) | "(.Expiry)"'')"; NOW="$(date
      +%s)";echo "$i: $((($OUT-$NOW)/86400))"; done` and ensure all domains have greater
      than 30 days remaining.'
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: Route53 Domain Auto Renewal
        url: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-renew.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-3
          - nist-csf-pr.ip-5
      - aws
  - id: darkbit-aws-92
    title: Route53 Domain Transfer Lock Should Be Enabled
    description:
      Domains registered to Route53 can have a "Transfer Lock" configured
      which prevents unauthorized transfer attempts unless the lock is disabled by the
      domain owner.  This is an added protection that all domains should have enabled.
    remediation:
      If a Transfer Lock is not enabled, re-enable it by visiting the Route53
      console's `Registered Domains` page and choosing `Enable` for a domain's `Transfer
      Lock` setting.
    validation: |
      Run `aws route53domains list-domains --query 'Domains[*]' --output json
      | jq -r '.[] | "(.DomainName) (.TransferLock)"'` and validate that all domains
      in use are set to `true`.
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: Route53 Domain Transfer Lock
        url: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-lock.html
      - text: Route53 Domain that can be Registered
        url: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar-tld-list.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.at
          - nist-csf-pr.at-2
          - nist-csf-pr.ds
          - nist-csf-pr.ds-5
          - nist-csf-pr.ma
          - nist-csf-pr.ma-2
      - aws
  - id: darkbit-aws-93
    title: Amazon ECR Repositories Should Enforce Tag Immutability
    description:
      Amazon ECR Repositories can be configured to throw an `ImageTagAlreadyExistsException`
      error instead of silently overwriting an image tag when pushing container images
      to the repository.  This can help enforce consistency of images in the environment
      by downstream systems such as ECS or EKS as they will then always pull the desired
      image with that tag.
    remediation:
      When creating an ECR repository, pass the `--image-tag-mutability IMMUTABLE`
      config option.  To enable this on an existing registry, run `aws ecr put-image-tag-mutability
      --repository-name <reponame> --image-tag-mutability IMMUTABLE`.
    validation: |
      In each region, run `aws ecr describe-repositories --region <region>
      --query "repositories[]" --output json | jq -r '.[] | "(.repositoryArn) (.imageTagMutability)"'
      | grep " MUTABLE$"` and ensure no entries are present.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Amazon ECR Tag Immutability
        url: https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-tag-mutability.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-6
      - aws
  - id: darkbit-aws-94
    title: EC2 Instances Should Use SSH Key Based Login
    description:
      AWS EC2 instances can be pre-configured with a specified PEM key at
      launch to enable key-based SSH login.  This method is strongly preferred over
      traditional user/password authentication as it avoids most brute-force password
      attacks from being possible.
    remediation:
      During instance creation, specify an SSH KeyPair to enable SSH access
      at launch time.  Avoid reconfiguring the SSH daemon to accept user/password authentication.
    validation:
      In each region, run `aws ec2 describe-instances --region <region> --query
      'Reservations[*].Instances[*]' --output json | jq -r '.[][] | "(.InstanceId) (.KeyName)"'`
      and ensure an SSH Keypair name is associated with all instances.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: AWS EC2 KeyPairs
        url: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
          - nist-csf-pr.ac-3
          - nist-csf-pr.ac-6
      - aws
  - id: darkbit-aws-95
    title: AWS Shield Advanced Protections and Emergency Contacts Should Be Enabled
    description:
      '`AWS Shield Advanced` provides enhanced DDoS protection, increased
      mitigation capacity, attack notification and reporting, and DDoS response team
      support from AWS Engineers for all enrolled services within a subscribed account.
      Subscriptions should be active, and the emergency contacts should be configured.'
    remediation:
      'In the AWS Console under `AWS WAF & Shield > AWS Shield`, accounts
      that do not have it activated will be shown a screen where the `Activate AWS Shield
      Advanced` is available.  Note: an added monthly cost is incurred when enabling
      this feature.'
    validation: N/A
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: AWS Shield
        url: https://docs.aws.amazon.com/waf/latest/developerguide/ddos-overview.html#ddos-advanced
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.ip
          - nist-csf-pr.ip-7
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - aws
  - id: darkbit-aws-96
    title: AWS Systems Manager Should Be Active on All Instances
    description:
      AWS Systems Manager provides secure and auditable instance management
      in a centralized location without requiring open ports or managing SSH keys.  Systems
      Manager agents should be installed and active on all EC2 instances.
    remediation: |-
      The SSM Agent is preinstalled by default on the following AMIs:

      * Windows Server 2008-2012 R2 AMIs published in November 2016 or later
      * Windows Server 2016 and 2019
      * Amazon Linux
      * Amazon Linux 2
      * Ubuntu Server 16.04
      * Ubuntu Server 18.04
      * Amazon ECS-Optimized

      For instances built on custom AMIs, the agent can be installed manually from trusted Amazon distribution links.
    validation:
      For each instance in each region, run `aws ssm describe-instance-information
      --filters "Key=InstanceIds,Values=i-1234567890"`and ensure it shows as active.
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: AWS Systems Manager
        url: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up.html
      - text: AWS SSM Agent Linux Install
        url: https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-install-ssm-agent.html
      - text: AWS SSM Agent Windows Install
        url: https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-install-ssm-win.html
    tags:
    - nist-csf:
      - nist-csf-id
      - nist-csf-id.am
      - nist-csf-id.am-2
      - nist-csf-id.ra
      - nist-csf-id.ra-1
      - nist-csf-pr
      - nist-csf-pr.ac
      - nist-csf-pr.ac-3
      - nist-csf-pr.ip
      - nist-csf-pr.ip-2
      - nist-csf-pr.ip-3
    - aws-cfg:
      - aws-cfg-ec2-instance-managed-by-systems-manager
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-2.4
    - nist-csf:
      - nist-csf-ID.AM-2
      - nist-csf-PR.DS-3
      - nist-csf-PR.IP-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-CM-7(a)
      - nist-800-53-rev4-CM-8(1)
      - nist-800-53-rev4-CM-8(3)(a)
      - nist-800-53-rev4-SA-3(a)
      - nist-800-53-rev4-SA-10
      - nist-800-53-rev4-SI-2(2)
      - nist-800-53-rev4-SI-7(1)
    - nist-800-171:
      - nist-800-171-3.4.1
      - nist-800-171-3.4.6
      - nist-800-171-3.4.9
    - fedramp-moderate:
      - fedramp-moderate-CM-2
      - fedramp-moderate-CM-7(a)
      - fedramp-moderate-CM-8(1)
      - fedramp-moderate-CM-8(3)(a)
      - fedramp-moderate-SA-3(a)
      - fedramp-moderate-SA-10
      - fedramp-moderate-SI-2(2)
      - fedramp-moderate-SI-7(1)
    - fedramp-low:
      - fedramp-low-CM-2
    - cmmc-level5:
      - cmmc-level5-CM.2.061
      - cmmc-level5-CM.2.062
      - cmmc-level5-CM.2.063
      - cmmc-level5-CM.2.064
      - cmmc-level5-CM.2.065
      - cmmc-level5-AM.4.226
      - cmmc-level5-CM.5.074
    - cmmc-level4:
      - cmmc-level4-CM.2.061
      - cmmc-level4-CM.2.062
      - cmmc-level4-CM.2.063
      - cmmc-level4-CM.2.064
      - cmmc-level4-CM.2.065
      - cmmc-level4-AM.4.226
    - cmmc-level3:
      - cmmc-level3-CM.2.061
      - cmmc-level3-CM.2.062
      - cmmc-level3-CM.2.063
      - cmmc-level3-CM.2.064
      - cmmc-level3-CM.2.065
    - cmmc-level2:
      - cmmc-level2-CM.2.061
      - cmmc-level2-CM.2.062
      - cmmc-level2-CM.2.063
      - cmmc-level2-CM.2.064
      - cmmc-level2-CM.2.065
    - aws-wa-security:
      - aws-wa-security-SEC-6
    - aws
  - id: darkbit-aws-97
    title: AWS Load Balancers Should Prevent Request Smuggling
    description:
      HTTP request smuggling is a technique for interfering with the way
      a web site processes sequences of HTTP requests that are received from one or
      more users. Request smuggling vulnerabilities are often critical in nature, allowing
      an attacker to bypass security controls, gain unauthorized access to sensitive
      data, and directly compromise other application users.  By default, the protections
      for these attacks in AWS Application Load Balancers are not enabled.
    remediation:
      Use `aws elbv2 modify-load-balancer-attributes --load-balancer-arn
      <arn> --attributes Key=routing.http.drop_invalid_header_fields.enabled,Value=true`
      to enable the dropping of invalid header fields used in "request smuggling" attacks.
    validation: |
      'In each region, run `for i in $(aws elbv2 describe-load-balancers --region
      <region> --query 'LoadBalancers[*].LoadBalancerArn' --output text); do OUT="$(aws
      elbv2 describe-load-balancer-attributes --region <region> --load-balancer-arn
      $i --query 'Attributes[]' | jq -r '.[] | select(.Key=="routing.http.drop_invalid_header_fields.enabled")
      | "(.Value)"')"; echo "$i: $OUT"; done` and verify that all are set to `true`.'
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: ALB Attributes
        url: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#load-balancer-attributes
    tags:
    - aws-cfg:
      - aws-cfg-alb-http-drop-invalid-header-enabled
    - nist-csf:
      - nist-csf-pr
      - nist-csf-pr.ds
      - nist-csf-pr.ds-2
      - nist-csf-pr.ds-5
      - nist-csf-pr.pt
      - nist-csf-pr.pt-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-17(2)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-8
      - nist-800-53-rev4-SC-8(1)
      - nist-800-53-rev4-SC-23
    - nist-800-171:
      - nist-800-171-3.13.1
      - nist-800-171-3.13.8
      - nist-800-171-3.5.10
    - fedramp-moderate:
      - fedramp-moderate-AC-17(2)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-8
      - fedramp-moderate-SC-8(1)
      - fedramp-moderate-SC-23
    - fedramp-low:
      - fedramp-low-AC-17
    - cmmc-level5:
      - cmmc-level5-SC.1.175
      - cmmc-level5-IA.2.081
      - cmmc-level5-AC.3.014
      - cmmc-level5-SC.3.185
      - cmmc-level5-SC.3.190
    - cmmc-level4:
      - cmmc-level4-SC.1.175
      - cmmc-level4-IA.2.081
      - cmmc-level4-AC.3.014
      - cmmc-level4-SC.3.185
      - cmmc-level4-SC.3.190
    - cmmc-level3:
      - cmmc-level3-SC.1.175
      - cmmc-level3-IA.2.081
      - cmmc-level3-AC.3.014
      - cmmc-level3-SC.3.185
      - cmmc-level3-SC.3.190
    - cmmc-level2:
      - cmmc-level2-SC.1.175
      - cmmc-level2-IA.2.081
    - cmmc-level1:
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-9
    - aws
  - id: darkbit-aws-98
    title: Trusted Advisor Should Not Show Any Active Errors and Warnings
    description:
      Trusted Advisor is an AWS service that provides real-time guidance
      to help provision and manage cloud resources following AWS best practices. It
      periodically scans an AWS environment for best practices related to security,
      fault tolerance, performance, cost optimisation, and service limits) and provides
      recommended actions.
    remediation:
      Review the `Yellow (Investigation Required)` and `Red (Action Required)`
      alerts as they surface and follow the guidance provided for each recommendation.
    validation: N/A
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: AWS Trusted Advisor Best Practices
        url: https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/
    tags:
      - nist-csf:
          - nist-csf-id
          - nist-csf-id.gv
          - nist-csf-id.gv-4
          - nist-csf-id.ra
          - nist-csf-id.ra-1
      - aws
  - id: darkbit-aws-99
    title: ElastiCache Should Require Authentication
    description:
      Amazon ElastiCache instances should be configured to require authentication
      via an authentication token.  Access control is performed solely via network level
      restrictions.  In the event of a compromise, an attacker would have direct access
      to these datastores from inside the VPC to be able to exfiltrate sensitive contents
      or manipulate/disrupt their operation.
    remediation:
      Configure all ElastiCache instances with token AUTH credentials.  Validate
      that all client software and libraries that interface with these services have
      support for authentication, and implement the necessary functionality, if possible.  Reconfigure
      all deployments to leverage these credentials.
    validation: N/A
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: ElastiCache Authentication
        url: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/auth.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-6
          - nist-csf-pr.ds
          - nist-csf-pr.ds-5
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
      - aws
  - id: darkbit-aws-100
    title: Managed Streaming Kafka Instances Should Encrypt Data At Rest
    description:
      Amazon Managed Streaming Kafka instances are not configured to encrypt
      data at rest by default. By enabling it, the disk volumes are transparently encrypted
      using AES-256 via automatically-managed KMS keys.
    remediation:
      Configure all Managed Streaming Kafka cluster instances with encryption
      at rest during MSK cluster creation and specify a dedicated KMS Key Id for this
      purpose.
    validation:
      Run `aws kafka list-clusters --region <region> --output json | jq -r
      '.ClusterInfoList[] | "(.ClusterArn) (.EncryptionInfo.EncryptionAtRest.DataVolumeKMSKeyId)"'`
      and ensure a KMS Key Id is listed for every cluster.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Managed Streaming Kafka Encryption
        url: https://docs.aws.amazon.com/msk/latest/developerguide/msk-encryption.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-1
      - aws
  - id: darkbit-aws-101
    title: Managed Streaming Kafka Instances Should Encrypt Data In Transit
    description:
      By default, Amazon Managed Streaming Kafka instances are configured
      to encrypt data in transit between Kafka brokers using TLS.  While it incurs a
      performance overhead penalty, it should not be disabled.
    remediation:
      Configure all Managed Streaming Kafka cluster instances with TLS encryption
      in transit during cluster creation.
    validation:
      In each region, run `aws kafka list-clusters --region <region> --output
      json | jq -r '.ClusterInfoList[] | "(.ClusterArn) (.EncryptionInfo.EncryptionInTransit.ClientBroker)
      (.EncryptionInfo.EncryptionInTransit.InCluster)"'` and ensure that "TLS true"
      is listed for every cluster.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Managed Streaming Kafka Encryption
        url: https://docs.aws.amazon.com/msk/latest/developerguide/msk-encryption.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-1
      - aws
  - id: darkbit-aws-103
    title: IAM Policies Should Not Have Wildcard Actions On All Resources
    description:
      A number of IAM Roles/policies were found to have permissions that
      include "wildcards" (e.g. `iam:*` or `ssm:*`) against all resources (`*`) in the
      account.  In some cases, these configurations provide direct pathways to escalate
      privileges to Administrator via `iam:PassRole` and/or `iam:AttachRolePolicy`.  In
      other cases, they provide a much wider range of permissions than is likely necessary.  If
      these credentials are compromised, they could likely be used to move laterally
      to other resources or take full control of the account.
    remediation:
      Perform a thorough review of each IAM policy, and refactor areas where
      wildcards are used in the allowed `permissions` and `resources` sections.  Pay
      special attention to permissions involving `iam:`, `ssm:`, `ec2:`, and `s3:` as
      they are commonly desired permissions for privilege escalation, stealing secrets,
      running compute, and leaking sensitive data.
    validation:
      Validate that IAM Role policies define the specific actions to allow
      and/or scope the resources to which they apply by name or prefix instead of `*`.
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: Rhino Labs AWS IAM Privilege Escalation
        url: https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/
      - text: AWS IAM Best Practices
        url: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
      - aws
  - id: darkbit-aws-104
    title: EKS Node Groups Should Not Have Full Egress Network Access
    description:
      One of the mechanisms attackers can count on in most cloud environments
      is the ability to make connections externally.  Forcing an attacker to have to
      egress through a specific gateway/proxy or to a small set of external hosts while
      logging and analyzing security group deny logs can provide a better understanding
      of what applications should be talking to externally.  This can help create a
      baseline to compare activity and aid in identifying an attacker in the environment
      as they attempt to leak data or set up persistent command and control access.
    remediation:
      In a test environment, configure egress access to be denied and logged
      by default.  As applications are tested, troubleshoot their access needs.  If
      applications need access to specific URLs, consider implementing an HTTPS gateway
      or proxy solution that can implement policy based on the URL or domains, and ensure
      all external (non-AWS) traffic is forced to traverse that gateway.
    validation: Confirm that arbitrary egress network access is not possible from pods.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Working with AWS Security Groups
        url: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#WorkingWithSecurityGroups
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-5
          - nist-csf-pr.ds
          - nist-csf-pr.ds-5
      - aws
  - id: darkbit-aws-105
    title: Publicly Accessible EC2 Instance Should Not Have Direct Access To All S3 Buckets
    description:
      EC2 instances were found with an attached IAM Instance provides unscoped access to
      all S3 buckets.
    remediation:
      Modify the IAM Instance Role to restrict the resources to a limited
      set of S3 buckets by name or by prefix to avoid accidentally exposing data that
      could be used to escalate privileges in the environment.
    validation:
      After scoping down the IAM policy, confirm that the instance does not
      have full access to all S3 buckets.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: AWS IAM Restrictions for Buckets
        url: https://aws.amazon.com/premiumsupport/knowledge-center/s3-console-access-certain-bucket/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
      - aws
  - id: darkbit-aws-133
    title: DynamoDB Throughput Should Not Be Near The Account Limit
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-dynamodb-throughput-limit-check
    - nist-csf:
      - nist-csf-ID.BE-5
      - nist-csf-PR.DS-4
    - nist-800-171:
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      aws-wa-reliability:
      - aws-wa-reliability-REL-1
    - aws
  - id: darkbit-aws-134
    title: Lambda Functions Should Have Function-Level Concurrent Execution Limits Set
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-lambda-concurrency-check
    - nist-csf:
      - nist-csf-DE.AE-1
    - nist-800-171:
      - nist-800-171-3.13.2
    - aws-wa-reliability:
      - aws-wa-reliability-REL-1
    - aws
  - id: darkbit-aws-135
    title: AWS Site-to-Site VPN Tunnels Should Be Up In Both Directions
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-vpc-vpn-2-tunnels-up
    - nist-csf:
      - nist-csf-ID.BE-5
      - nist-csf-PR.DS-4
      - nist-csf-PR.PT-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-CP-10
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(7)(i)
    - fedramp-moderate:
      - fedramp-moderate-CP-10
    - fedramp-low:
      - fedramp-low-CP-10
    - cmmc-level5:
      - cmmc-level5-SC.3.180
      - cmmc-level5-RE.5.140
    - cmmc-level4:
      - cmmc-level4-SC.3.180
    - cmmc-level3:
      - cmmc-level3-SC.3.180
    - aws-wa-reliability:
      - aws-wa-reliability-REL-2
    - aws
  - id: darkbit-aws-136
    title: DynamoDB Should Have Autoscaling Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-dynamodb-autoscaling-enabled
    - nist-csf:
      - nist-csf-ID.BE-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-CP-10
      - nist-800-53-rev4-SC-5
    - nist-800-171:
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(7)(i)
    - fedramp-moderate:
      - fedramp-moderate-CP-10
      - fedramp-moderate-SC-5
    - fedramp-low:
      - fedramp-low-CP-10
    - aws-wa-reliability:
      - aws-wa-reliability-REL-7
    - aws
  - id: darkbit-aws-137
    title: Redshift Clusters Should Have Maintenance Windows Configured
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-redshift-cluster-maintenancesettings-check
    - aws-wa-reliability:
      - aws-wa-reliability-REL-8
    - aws
  - id: darkbit-aws-138
    title: Redshift Clusters Should Have Retention Policies Configured
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-redshift-cluster-maintenancesettings-check
    - aws-wa-reliability:
      - aws-wa-reliability-REL-8
    - aws
  - id: darkbit-aws-139
    title: DynamoDB Tables Should Be In An AWS Backup Plan
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-dynamodb-in-backup-plan
    - nist-csf:
      - nist-csf-PR.IP-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-CP-9(b)
      - nist-800-53-rev4-CP-10
      - nist-800-53-rev4-SI-12
    - nist-800-171:
      - nist-800-171-3.13.2
    - fedramp-moderate:
      - fedramp-moderate-CP-9(b)
      - fedramp-moderate-CP-10
      - fedramp-moderate-SI-12
    - fedramp-low:
      - fedramp-low-CP-9
    - cmmc-level2:
      - cmmc-level2-RE.2.137
    - aws-wa-reliability:
      - aws-wa-reliability-REL-9
    - aws
  - id: darkbit-aws-140
    title: DynamoDB Point-in-Time Recovery Should Be Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-dynamodb-pitr-enabled
    - nist-csf:
      - nist-csf-PR.IP-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-CP-9(b)
      - nist-800-53-rev4-CP-10
      - nist-800-53-rev4-SI-12
    - nist-800-171:
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(7)(ii)(A)
      - hipaa-164.312(a)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-CP-9(b)
      - fedramp-moderate-CP-10
      - fedramp-moderate-SI-12
    - fedramp-low:
      - fedramp-low-CP-9
    - cmmc-level5:
      - cmmc-level5-RE.2.137
      - cmmc-level5-RE.3.139
      - cmmc-level5-RE.5.140
    - cmmc-level4:
      - cmmc-level4-RE.2.137
      - cmmc-level4-RE.3.139
    - cmmc-level3:
      - cmmc-level3-RE.2.137
      - cmmc-level3-RE.3.139
    - cmmc-level2:
      - cmmc-level2-RE.2.137
    - aws-wa-reliability:
      - aws-wa-reliability-REL-9
    - aws
  - id: darkbit-aws-141
    title: EBS Volumes Should Be In An AWS Backup Plan
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-ebs-in-backup-plan
    - nist-800-53-rev4:
      - nist-800-53-rev4-CP-9(b)
      - nist-800-53-rev4-CP-10
      - nist-800-53-rev4-SI-12
    - nist-800-171:
      - nist-800-171-3.13.2
    - fedramp-moderate:
      - fedramp-moderate-CP-9(b)
      - fedramp-moderate-CP-10
      - fedramp-moderate-SI-12
    - fedramp-low:
      - fedramp-low-CP-9
    - cmmc-level2:
      - cmmc-level2-RE.2.137
    - aws-wa-reliability:
      - aws-wa-reliability-REL-9
    - aws
  - id: darkbit-aws-142
    title: EFS Volumes Should Be In An AWS Backup Plan
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-ebs-in-backup-plan
    - nist-800-53-rev4:
      - nist-800-53-rev4-CP-9(b)
      - nist-800-53-rev4-CP-10
      - nist-800-53-rev4-SI-12
    - nist-800-171:
      - nist-800-171-3.13.2
    - fedramp-moderate:
      - fedramp-moderate-CP-9(b)
      - fedramp-moderate-CP-10
      - fedramp-moderate-SI-12
    - fedramp-low:
      - fedramp-low-CP-9
    - cmmc-level2:
      - cmmc-level2-RE.2.137
    - aws-wa-reliability:
      - aws-wa-reliability-REL-9
    - aws
  - id: darkbit-aws-143
    title: Elasticache Backups With Proper Retention Periods Should Be Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-elasticache-redis-cluster-automatic-backup-check
    - nist-csf:
      - nist-csf-ID.BE-5
      - nist-csf-PR.DS-4
      - nist-csf-PR.IP-4
      - nist-csf-PR.PT-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-CP-9(b)
      - nist-800-53-rev4-CP-10
      - nist-800-53-rev4-SI-12
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(7)(ii)(A)
      - hipaa-164.312(a)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-CP-9(b)
      - fedramp-moderate-CP-10
      - fedramp-moderate-SI-12
    - fedramp-low:
      - fedramp-low-CP-9
    - cmmc-level5:
      - cmmc-level5-RE.2.137
      - cmmc-level5-RE.3.139
      - cmmc-level5-RE.5.140
    - cmmc-level4:
      - cmmc-level4-RE.2.137
      - cmmc-level4-RE.3.139
    - cmmc-level3:
      - cmmc-level3-RE.2.137
      - cmmc-level3-RE.3.139
    - cmmc-level2:
      - cmmc-level2-RE.2.137
    - aws-wa-reliability:
      - aws-wa-reliability-REL-9
    - aws
  - id: darkbit-aws-144
    title: RDS Instances Should Be In An AWS Backup Plan
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-rds-in-backup-plan
    - nist-800-53-rev4:
      - nist-800-53-rev4-CP-9(b)
      - nist-800-53-rev4-CP-10
      - nist-800-53-rev4-SI-12
    - nist-800-171:
      - nist-800-171-3.13.2
    - fedramp-moderate:
      - fedramp-moderate-CP-9(b)
      - fedramp-moderate-CP-10
      - fedramp-moderate-SI-12
    - fedramp-low:
      - fedramp-low-CP-9
    - cmmc-level2:
      - cmmc-level2-RE.2.137
    - aws-wa-reliability:
      - aws-wa-reliability-REL-9
    - aws
  - id: darkbit-aws-145
    title: Elastic Load Balancers Should Span Multiple Availability Zones
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-elb-cross-zone-load-balancing-enabled
    - nist-800-53-rev4:
      - nist-800-53-rev4-CP-10
      - nist-800-53-rev4-SC-5
    - nist-800-171:
      - nist-800-171-3.13.2
    - fedramp-moderate:
      - fedramp-moderate-CP-10
      - fedramp-moderate-SC-5
    - fedramp-low:
      - fedramp-low-CP-10
    - cmmc-level5:
      - cmmc-level5-SC.3.180
      - cmmc-level5-RE.5.140
    - cmmc-level4:
      - cmmc-level4-SC.3.180
    - cmmc-level3:
      - cmmc-level3-SC.3.180
    - aws-wa-reliability:
      - aws-wa-reliability-REL-10
    - aws
  - id: darkbit-aws-146
    title: S3 Buckets Should Have Automatic Cross-Region Replication Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-s3-bucket-replication-enabled
    - nist-csf:
      - nist-csf-ID.BE-5
      - nist-csf-PR.DS-4
      - nist-csf-PR.IP-4
      - nist-csf-PR.PT-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-AU-9(2)
      - nist-800-53-rev4-CP-9(b)
      - nist-800-53-rev4-CP-10
      - nist-800-53-rev4-SC-5
      - nist-800-53-rev4-SC-36
    - nist-800-171:
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(7)(i)
      - hipaa-164.308(a)(7)(ii)(A)
      - hipaa-164.312(a)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-AU-9(2)
      - fedramp-moderate-CP-9(b)
      - fedramp-moderate-CP-10
      - fedramp-moderate-SC-5
    - fedramp-low:
      - fedramp-low-AU-9
    - cmmc-level5:
      - cmmc-level5-RE.2.137
      - cmmc-level5-RE.3.139
      - cmmc-level5-RE.5.140
    - cmmc-level4:
      - cmmc-level4-RE.2.137
      - cmmc-level4-RE.3.139
    - cmmc-level3:
      - cmmc-level3-RE.2.137
      - cmmc-level3-RE.3.139
    - cmmc-level2:
      - cmmc-level2-RE.2.137
    - aws-wa-reliability:
      - aws-wa-reliability-REL-9
    - aws
  - id: darkbit-aws-147
    title: AWS Account Should Be Part Of An AWS Organization
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-account-part-of-organizations
    - cmmc-level5:
      - cmmc-level5-CM.2.064
      - cmmc-level5-SC.3.180
    - cmmc-level4:
      - cmmc-level4-CM.2.064
      - cmmc-level4-SC.3.180
    - cmmc-level3:
      - cmmc-level3-CM.2.064
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-CM.2.064
    - aws-wa-security:
      - aws-wa-security-SEC-1
    - aws
  - id: darkbit-aws-148
    title: Codebuild Environment Variables Should Not Contain AWS Access Credentials
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-codebuild-project-envvar-awscred-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-8.2.1
    - nist-csf:
      - nist-csf-PR.DS-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-IA-5(7)
      - nist-800-53-rev4-SA-3(a)
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
    - fedramp-moderate:
      - fedramp-moderate-AC-6
      - fedramp-moderate-IA-5(7)
      - fedramp-moderate-SA-3(a)
    - aws-wa-security:
      - aws-wa-security-SEC-1
    - aws
  - id: darkbit-aws-149
    title: EMR Clusters Should Have Kerberos Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-emr-kerberos-enabled
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-8.2.1
    - nist-csf:
      - nist-csf-PR.AC-4
      - nist-csf-PR.AC-6
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-2(j)
      - nist-800-53-rev4-AC-3
      - nist-800-53-rev4-AC-5c
      - nist-800-53-rev4-AC-6
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.2
      - nist-800-171-3.1.4
      - nist-800-171-3.1.5
      - nist-800-171-3.1.7
    - hipaa:
      - hipaa-164.308(a)(3)(ii)(A)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-2(j)
      - fedramp-moderate-AC-3
      - fedramp-moderate-AC-5c
      - fedramp-moderate-AC-6
    - fedramp-low:
      - fedramp-low-AC-2
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-IA.1.076
      - cmmc-level5-IA.1.077
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.008
      - cmmc-level5-AC.3.017
      - cmmc-level5-AC.3.018
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-IA.1.076
      - cmmc-level4-IA.1.077
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.008
      - cmmc-level4-AC.3.017
      - cmmc-level4-AC.3.018
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-IA.1.076
      - cmmc-level3-IA.1.077
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.008
      - cmmc-level3-AC.3.017
      - cmmc-level3-AC.3.018
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-IA.1.076
      - cmmc-level2-IA.1.077
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.008
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-IA.1.076
      - cmmc-level1-IA.1.077
    - aws-wa-security:
      - aws-wa-security-SEC-2
      - aws-wa-security-SEC-3
    - aws
  - id: darkbit-aws-150
    title: IAM Users Should Be Members Of At Least One Group
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-iam-user-group-membership-check
    - nist-csf:
      - nist-csf-ID
      - nist-csf-ID.AM
      - nist-csf-ID.AM-6
      - nist-csf-PR
      - nist-csf-PR.AC
      - nist-csf-PR.AC-1
      - nist-csf-PR.AC-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-2(1)
      - nist-800-53-rev4-AC-2(j)
      - nist-800-53-rev4-AC-3
      - nist-800-53-rev4-AC-6
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.2
      - nist-800-171-3.1.4
      - nist-800-171-3.1.5
      - nist-800-171-3.1.7
    - hipaa:
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.308(a)(3)(ii)(B)
      - hipaa-164.308(a)(4)(i)
      - hipaa-164.308(a)(4)(ii)(B)
      - hipaa-164.308(a)(4)(ii)(C)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-2(1)
      - fedramp-moderate-AC-2(j)
      - fedramp-moderate-AC-3
      - fedramp-moderate-AC-6
    - fedramp-low:
      - fedramp-low-AC-2
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.002
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.008
      - cmmc-level5-AC.3.017
      - cmmc-level5-AC.3.018
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.002
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.008
      - cmmc-level4-AC.3.017
      - cmmc-level4-AC.3.018
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.002
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.008
      - cmmc-level3-AC.3.017
      - cmmc-level3-AC.3.018
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.002
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.008
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.002
    - aws-wa-security:
      - aws-wa-security-SEC-2
    - aws
  - id: darkbit-aws-151
    title: AWS Secrets Manager Secrets Should Have Rotation Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-secretsmanager-rotation-enabled-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-8.2.4
    - nist-csf:
      - nist-csf-PR.AC-1
    - hipaa:
      - hipaa-164.308(a)(4)(ii)(C)
    - aws-wa-security:
      - aws-wa-security-SEC-2
    - aws
  - id: darkbit-aws-152
    title: AWS Secrets Manager Secrets Should Have Been Rotated Successfully
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-secretsmanager-scheduled-rotation-success-check
    - nist-csf:
      - nist-csf-PR.AC-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-2(1)
      - nist-800-53-rev4-AC-2(j)
    - fedramp-moderate:
      - fedramp-moderate-AC-2(1)
      - fedramp-moderate-AC-2(j)
    - fedramp-low:
      - fedramp-low-AC-2
    - aws-wa-security:
      - aws-wa-security-SEC-2
    - aws
  - id: darkbit-aws-153
    title: Elastic Load Balancers Should Have Deletion Protection Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-elb-deletion-protection-enabled
    - nist-csf:
      - nist-csf-ID.BE-5
      - nist-csf-PR.DS-4
      - nist-csf-PR.IP-3
      - nist-csf-PR.PT-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-CP-10
    - nist-800-171:
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
    - fedramp-moderate:
      - fedramp-moderate-CM-2
      - fedramp-moderate-CP-10
    - fedramp-low:
      - fedramp-low-CM-2
    - cmmc-level5:
      - cmmc-level5-SC.3.180
      - cmmc-level5-RE.5.140
    - cmmc-level4:
      - cmmc-level4-SC.3.180
    - cmmc-level3:
      - cmmc-level3-SC.3.180
    - aws-wa-security:
      - aws-wa-security-SEC-3
    - aws
  - id: darkbit-aws-154
    title: IAM Groups Should Have At Least One Member
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-iam-group-has-users-check
    - nist-csf:
      - nist-csf-PR
      - nist-csf-PR.AC
      - nist-csf-PR.AC-1
      - nist-csf-PR.AC-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-2(j)
      - nist-800-53-rev4-AC-3
      - nist-800-53-rev4-AC-5c
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-SC-2
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.2
      - nist-800-171-3.1.4
      - nist-800-171-3.1.5
      - nist-800-171-3.1.7
    - hipaa:
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.308(a)(3)(ii)(B)
      - hipaa-164.308(a)(4)(i)
      - hipaa-164.308(a)(4)(ii)(B)
      - hipaa-164.308(a)(4)(ii)(C)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-2(j)
      - fedramp-moderate-AC-3
      - fedramp-moderate-AC-5c
      - fedramp-moderate-AC-6
      - fedramp-moderate-SC-2
    - fedramp-low:
      - fedramp-low-AC-2
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.002
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.008
      - cmmc-level5-AC.3.017
      - cmmc-level5-AC.3.018
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.002
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.008
      - cmmc-level4-AC.3.017
      - cmmc-level4-AC.3.018
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.002
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.008
      - cmmc-level3-AC.3.017
      - cmmc-level3-AC.3.018
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.002
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.008
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.002
    - aws-wa-security:
      - aws-wa-security-SEC-3
    - aws
  - id: darkbit-aws-155
    title: RDS Instances Should Have Deletion Protection Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-rds-instance-deletion-protection-enabled
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-5
    - nist-800-171:
      - nist-800-171-3.13.2
    - fedramp-moderate:
      - fedramp-moderate-SC-5
    - fedramp-low:
      - fedramp-low-SC-5
    - cmmc-level5:
      - cmmc-level5-SC.3.180
      - cmmc-level5-RE.5.140
    - cmmc-level4:
      - cmmc-level4-SC.3.180
    - cmmc-level3:
      - cmmc-level3-SC.3.180
    - aws-wa-security:
      - aws-wa-security-SEC-3
    - aws
  - id: darkbit-aws-156
    title: A Security Focused CloudTrail Should Be Present
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-cloudtrail-security-trail-enabled
    - nist-800-53-rev4:
      - nist-800-53-rev4-CM-2
    - nist-800-171:
      - nist-800-171-3.13.2
    - fedramp-moderate:
      - fedramp-moderate-CM-2
    - fedramp-low:
      - fedramp-low-CM-2
    - cmmc-level5:
      - cmmc-level5-CM.2.064
      - cmmc-level5-SC.3.180
    - cmmc-level4:
      - cmmc-level4-CM.2.064
      - cmmc-level4-SC.3.180
    - cmmc-level3:
      - cmmc-level3-CM.2.064
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-CM.2.064
    - aws-wa-security:
      - aws-wa-security-SEC-4
    - aws
  - id: darkbit-aws-157
    title: CloudWatch Alarms Have At Least One Alarm Action
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-cloudwatch-alarm-action-check
    - nist-csf:
      - nist-csf-DE.AE-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-2(4)
      - nist-800-53-rev4-AU-6(1)(3)
      - nist-800-53-rev4-AU-7(1)
      - nist-800-53-rev4-CA-7(a)(b)
      - nist-800-53-rev4-IR-4(1)
      - nist-800-53-rev4-SI-4(2)
      - nist-800-53-rev4-SI-4(4)
      - nist-800-53-rev4-SI-4(5)
      - nist-800-53-rev4-SI-4(a)(b)(c)
    - nist-800-171:
      - nist-800-171-3.6.1
    - hipaa:
      - hipaa-164.308(a)(6)(i)
    - fedramp-moderate:
      - fedramp-moderate-AC-2(4)
      - fedramp-moderate-AU-6(1)(3)
      - fedramp-moderate-AU-7(1)
      - fedramp-moderate-CA-7(a)(b)
      - fedramp-moderate-IR-4(1)
      - fedramp-moderate-SI-4(2)
      - fedramp-moderate-SI-4(4)
      - fedramp-moderate-SI-4(5)
      - fedramp-moderate-SI-4(a)(b)(c)
    - fedramp-low:
      - fedramp-low-AC-2
    - cmmc-level5:
      - cmmc-level5-SC.1.175
      - cmmc-level5-SI.1.210
      - cmmc-level5-AC.2.013
      - cmmc-level5-IR.2.092
      - cmmc-level5-IR.2.093
      - cmmc-level5-SI.2.214
      - cmmc-level5-AU.3.046
      - cmmc-level5-AU.4.053
      - cmmc-level5-IR.5.102
      - cmmc-level5-SI.5.223
    - cmmc-level4:
      - cmmc-level4-SC.1.175
      - cmmc-level4-SI.1.210
      - cmmc-level4-AC.2.013
      - cmmc-level4-IR.2.092
      - cmmc-level4-IR.2.093
      - cmmc-level4-SI.2.214
      - cmmc-level4-AU.3.046
      - cmmc-level4-AU.4.053
    - cmmc-level3:
      - cmmc-level3-SC.1.175
      - cmmc-level3-SI.1.210
      - cmmc-level3-AC.2.013
      - cmmc-level3-IR.2.092
      - cmmc-level3-IR.2.093
      - cmmc-level3-SI.2.214
      - cmmc-level3-AU.3.046
    - cmmc-level2:
      - cmmc-level2-SC.1.175
      - cmmc-level2-SI.1.210
      - cmmc-level2-AC.2.013
      - cmmc-level2-IR.2.092
      - cmmc-level2-IR.2.093
      - cmmc-level2-SI.2.214
    - cmmc-level1:
      - cmmc-level1-SC.1.175
      - cmmc-level1-SI.1.210
    - aws-wa-security:
      - aws-wa-security-SEC-4
    - aws
  - id: darkbit-aws-158
    title: CloudWatch LogGroups Should Have A Retention Period Set
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-cw-loggroup-retention-period-check
    - nist-800-53-rev4:
      - nist-800-53-rev4-AU-11
      - nist-800-53-rev4-SI-12
    - nist-800-171:
      - nist-800-171-3.3.1
    - fedramp-moderate:
      - fedramp-moderate-AU-11
      - fedramp-moderate-SI-12
    - fedramp-low:
      - fedramp-low-AU-11
    - cmmc-level5:
      - cmmc-level5-AU.2.042
    - cmmc-level4:
      - cmmc-level4-AU.2.042
    - cmmc-level3:
      - cmmc-level3-AU.2.042
    - cmmc-level2:
      - cmmc-level2-AU.2.042
    - aws-wa-security:
      - aws-wa-security-SEC-4
      - aws-wa-security-SEC-7
    - aws
  - id: darkbit-aws-159
    title: Redshift Clusters Should Have Database Encryption and Audit Logging Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-redshift-cluster-configuration-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-3.4
      - pci-dss-3.2.1-10.1
      - pci-dss-3.2.1-10.2
      - pci-dss-3.2.1-10.2.1
      - pci-dss-3.2.1-10.2.2
      - pci-dss-3.2.1-10.2.4
      - pci-dss-3.2.1-10.2.5
      - pci-dss-3.2.1-10.3.1
      - pci-dss-3.2.1-10.3.2
      - pci-dss-3.2.1-10.3.3
      - pci-dss-3.2.1-10.3.4
      - pci-dss-3.2.1-10.3.5
      - pci-dss-3.2.1-10.3.6
    - nist-csf:
      - nist-csf-ID.AM-3
      - nist-csf-PR.AC-6
      - nist-csf-DE.AE-1
      - nist-csf-DE.AE-3
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-2(4)
      - nist-800-53-rev4-AC-2(g)
      - nist-800-53-rev4-AU-2(a)(d)
      - nist-800-53-rev4-AU-3
      - nist-800-53-rev4-AU-12(a)(c)
      - nist-800-53-rev4-SC-13
      - nist-800-53-rev4-SC-28
    - nist-800-171:
      - nist-800-171-3.13.16
      - nist-800-171-3.14.6
      - nist-800-171-3.14.7
      - nist-800-171-3.3.1
      - nist-800-171-3.3.2
      - nist-800-171-3.5.10
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(1)(ii)(D)
      - hipaa-164.308(a)(3)(ii)(A)
      - hipaa-164.312(a)(2)(iv)
      - hipaa-164.312(b)
    - fedramp-moderate:
      - fedramp-moderate-AC-2(4)
      - fedramp-moderate-AC-2(g)
      - fedramp-moderate-AU-2(a)(d)
      - fedramp-moderate-AU-3
      - fedramp-moderate-AU-12(a)(c)
      - fedramp-moderate-SC-28
    - fedramp-low:
      - fedramp-low-AC-2
      - fedramp-low-SC-13
    - cmmc-level5:
      - cmmc-level5-IA.1.076
      - cmmc-level5-CM.2.065
      - cmmc-level5-IA.2.081
      - cmmc-level5-SI.2.217
      - cmmc-level5-SC.3.191
      - cmmc-level5-AU.5.055
    - cmmc-level4:
      - cmmc-level4-IA.1.076
      - cmmc-level4-CM.2.065
      - cmmc-level4-IA.2.081
      - cmmc-level4-SI.2.217
      - cmmc-level4-SC.3.191
    - cmmc-level3:
      - cmmc-level3-IA.1.076
      - cmmc-level3-CM.2.065
      - cmmc-level3-IA.2.081
      - cmmc-level3-SI.2.217
      - cmmc-level3-SC.3.191
    - cmmc-level2:
      - cmmc-level2-IA.1.076
      - cmmc-level2-CM.2.065
      - cmmc-level2-IA.2.081
      - cmmc-level2-SI.2.217
    - cmmc-level1:
      - cmmc-level1-IA.1.076
    - aws-wa-security:
      - aws-wa-security-SEC-4
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-160
    title: AWS Security Hub Should Be Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-securityhub-enabled
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-10.6
      - pci-dss-3.2.1-12.5.2
    - nist-csf:
      - nist-csf-ID.RA-1
      - nist-csf-ID.RA-2
      - nist-csf-ID.RA-3
      - nist-csf-PR.DS-5
      - nist-csf-DE.AE-2
      - nist-csf-DE.AE-4
      - nist-csf-DE.CM-1
      - nist-csf-DE.CM-3
      - nist-csf-DE.CM-4
      - nist-csf-DE.CM-6
      - nist-csf-DE.CM-7
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-2(1)
      - nist-800-53-rev4-AC-2(4)
      - nist-800-53-rev4-AC-2(12)(a)
      - nist-800-53-rev4-AC-2(g)
      - nist-800-53-rev4-AC-17(1)
      - nist-800-53-rev4-AU-6(1)(3)
      - nist-800-53-rev4-CA-7(a)(b)
      - nist-800-53-rev4-SA-10
      - nist-800-53-rev4-SI-4(2)
      - nist-800-53-rev4-SI-4(4)
      - nist-800-53-rev4-SI-4(5)
      - nist-800-53-rev4-SI-4(16)
      - nist-800-53-rev4-SI-4(a)(b)(c)
    - nist-800-171:
      - nist-800-171-3.1.12
      - nist-800-171-3.11.2
      - nist-800-171-3.13.1
      - nist-800-171-3.14.1
      - nist-800-171-3.14.2
      - nist-800-171-3.14.3
      - nist-800-171-3.14.6
      - nist-800-171-3.14.7
      - nist-800-171-3.3.1
      - nist-800-171-3.3.4
      - nist-800-171-3.3.5
      - nist-800-171-3.6.1
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(D)
      - hipaa-164.308(a)(3)(ii)(A)
      - hipaa-164.308(a)(6)(i)
      - hipaa-164.308(a)(6)(ii)
      - hipaa-164.312(b)
      - hipaa-164.312(e)(2)(i)
    - fedramp-moderate:
      - fedramp-moderate-AC-2(1)
      - fedramp-moderate-AC-2(4)
      - fedramp-moderate-AC-2(12)(a)
      - fedramp-moderate-AC-2(g)
      - fedramp-moderate-AC-17(1)
      - fedramp-moderate-AU-6(1)(3)
      - fedramp-moderate-CA-7(a)(b)
      - fedramp-moderate-SA-10
      - fedramp-moderate-SI-4(16)
      - fedramp-moderate-SI-4(2)
      - fedramp-moderate-SI-4(4)
      - fedramp-moderate-SI-4(5)
      - fedramp-moderate-SI-4(a)(b)(c)
    - fedramp-low:
      - fedramp-low-AC-2
    - cmmc-level5:
      - cmmc-level5-SC.1.175
      - cmmc-level5-SI.1.210
      - cmmc-level5-SI.1.211
      - cmmc-level5-AC.2.013
      - cmmc-level5-CM.2.064
      - cmmc-level5-IR.2.092
      - cmmc-level5-IR.2.093
      - cmmc-level5-SI.2.214
      - cmmc-level5-SI.2.216
      - cmmc-level5-SI.2.217
      - cmmc-level5-AU.3.046
      - cmmc-level5-AU.3.051
      - cmmc-level5-CA.3.161
      - cmmc-level5-AU.4.053
      - cmmc-level5-AU.4.054
      - cmmc-level5-AU.5.055
      - cmmc-level5-IR.5.102
      - cmmc-level5-SI.5.223
    - cmmc-level4:
      - cmmc-level4-SC.1.175
      - cmmc-level4-SI.1.210
      - cmmc-level4-SI.1.211
      - cmmc-level4-AC.2.013
      - cmmc-level4-CM.2.064
      - cmmc-level4-IR.2.092
      - cmmc-level4-IR.2.093
      - cmmc-level4-SI.2.214
      - cmmc-level4-SI.2.216
      - cmmc-level4-SI.2.217
      - cmmc-level4-AU.3.046
      - cmmc-level4-AU.3.051
      - cmmc-level4-CA.3.161
      - cmmc-level4-AU.4.053
      - cmmc-level4-AU.4.054
    - cmmc-level3:
      - cmmc-level3-SC.1.175
      - cmmc-level3-SI.1.210
      - cmmc-level3-SI.1.211
      - cmmc-level3-AC.2.013
      - cmmc-level3-CM.2.064
      - cmmc-level3-IR.2.092
      - cmmc-level3-IR.2.093
      - cmmc-level3-SI.2.214
      - cmmc-level3-SI.2.216
      - cmmc-level3-SI.2.217
      - cmmc-level3-AU.3.046
      - cmmc-level3-AU.3.051
      - cmmc-level3-CA.3.161
    - cmmc-level2:
      - cmmc-level2-SC.1.175
      - cmmc-level2-SI.1.210
      - cmmc-level2-SI.1.211
      - cmmc-level2-AC.2.013
      - cmmc-level2-CM.2.064
      - cmmc-level2-IR.2.092
      - cmmc-level2-IR.2.093
      - cmmc-level2-SI.2.214
      - cmmc-level2-SI.2.216
      - cmmc-level2-SI.2.217
    - cmmc-level1:
      - cmmc-level1-SC.1.175
      - cmmc-level1-SI.1.210
      - cmmc-level1-SI.1.211
    - aws-wa-security:
      - aws-wa-security-SEC-4
    - aws
  - id: darkbit-aws-161
    title: Web Application Firewall V2 Should Have Logging Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-wafv2-logging-enabled
    - nist-800-53-rev4:
      - nist-800-53-rev4-AU-2(a)(d)
      - nist-800-53-rev4-AU-3
      - nist-800-53-rev4-AU-12(a)(c)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SI-4(a)(b)(c)
    - nist-800-171:
      - nist-800-171-3.1.12
      - nist-800-171-3.13.1
      - nist-800-171-3.14.6
      - nist-800-171-3.14.7
      - nist-800-171-3.3.1
    - fedramp-moderate:
      - fedramp-moderate-AU-2(a)(d)
      - fedramp-moderate-AU-3
      - fedramp-moderate-AU-12(a)(c)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SI-4(a)(b)(c)
    - fedramp-low:
      - fedramp-low-AU-2
    - cmmc-level2:
      - cmmc-level2-AU.2.042
      - cmmc-level2-SI.2.217
    - aws-wa-security:
      - aws-wa-security-SEC-4
    - aws
  - id: darkbit-aws-162
    title: AWS Database Migration Service Replication Instances Should Not Be Public
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-dms-replication-not-public
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.DS-5
      - nist-csf-PR.PT-3
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-3
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-AC-21(b)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.2
      - nist-800-171-3.4.6
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-3
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-6
      - fedramp-moderate-AC-21(b)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - fedramp-low:
      - fedramp-low-AC-3
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.2.062
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.2.062
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.2.062
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-163
    title: Amazon Elastic Block Store Snapshots Should Not Be Publicly Restorable
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-ebs-snapshot-public-restorable-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.DS-5
      - nist-csf-PR.PT-3
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-3
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-AC-21(b)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.2
      - nist-800-171-3.4.6
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-3
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-6
      - fedramp-moderate-AC-21(b)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - fedramp-low:
      - fedramp-low-AC-3
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.2.062
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.2.062
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.2.062
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-164
    title: EC2 Instances Should Not Have Public IP Addresses
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-ec2-instance-no-public-ip
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-AC-21(b)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-6
      - fedramp-moderate-AC-21(b)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.2.062
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.2.062
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.2.062
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-165
    title: Amazon Elasticsearch Domains Should Be In A VPC
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-elasticsearch-in-vpc-only
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.PT-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
      - hipaa-164.312(e)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.2.062
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.2.062
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.2.062
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-166
    title: EMR Masters Should Not Have Public IPs
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-emr-master-no-public-ip
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-21(b)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-21(b)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.2.062
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.2.062
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.2.062
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-167
    title: EC2 Instances Should Be In A VPC
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-ec2-instances-in-vpc
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.PT-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
      - hipaa-164.312(e)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.016
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.016
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.016
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.016
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-168
    title: Internet Gateways Should Be Attached To Authorized VPCs
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-internet-gateway-authorized-vpc-only
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-17(3)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.20
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-17(3)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-SC.1.176
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.2.062
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-SC.1.176
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.2.062
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-SC.1.176
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.2.062
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-SC.1.176
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
      - cmmc-level1-SC.1.176
    - aws-wa-security:
      - aws-wa-security-SEC-5
    - aws
  - id: darkbit-aws-169
    title: Auto Scaling Groups Behind Elastic Load Balancers Should Have Health Checks Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-autoscaling-group-elb-healthcheck-required
    - nist-csf:
      - nist-csf-ID.BE-5
      - nist-csf-PR.DS-4
      - nist-csf-PR.PT-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-5
    - nist-800-171:
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(7)(i)
    - fedramp-moderate:
      - fedramp-moderate-SC-5
    - fedramp-low:
      - fedramp-low-SC-5
    - aws
  - id: darkbit-aws-170
    title: Lambda Function IAM Policies Should Not Grant Public Execution Access
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-lambda-function-public-access-prohibited
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
      - pci-dss-3.2.1-7.2
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.DS-5
      - nist-csf-PR.PT-3
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-3
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-AC-21(b)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.2
      - nist-800-171-3.4.6
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-3
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-6
      - fedramp-moderate-AC-21(b)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - fedramp-low:
      - fedramp-low-AC-3
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.2.062
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.2.062
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.2.062
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-171
    title: RDS Instances Should Not Be Public
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-rds-instance-public-access-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
      - pci-dss-3.2.1-7.2
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.DS-5
      - nist-csf-PR.PT-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-AC-21(b)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-6
      - fedramp-moderate-AC-21(b)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.2.062
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.2.062
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.2.062
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-172
    title: RDS Snapshots Should Not Be Public
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-rds-snapshots-public-prohibited
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
      - pci-dss-3.2.1-7.2
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.DS-5
      - nist-csf-PR.PT-3
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-3
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-AC-21(b)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.2
      - nist-800-171-3.4.6
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-3
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-6
      - fedramp-moderate-AC-21(b)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - fedramp-low:
      - fedramp-low-AC-3
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.2.062
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.2.062
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.2.062
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-173
    title: Redshift Clusters Should Not Be Public
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-redshift-cluster-public-access-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
      - pci-dss-3.2.1-7.2
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.DS-5
      - nist-csf-PR.PT-3
      - nist-csf-PR.PT-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-3
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-AC-21(b)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.1
      - nist-800-171-3.13.2
      - nist-800-171-3.4.6
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-3
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-6
      - fedramp-moderate-AC-21(b)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - fedramp-low:
      - fedramp-low-AC-3
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.2.062
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.2.062
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.2.062
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-174
    title: Sagemaker Notebooks Should Not Have Direct Internet Access
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-sagemaker-notebook-no-direct-internet-access
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.DS-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-3
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-AC-21(b)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.14
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.2
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-3
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-6
      - fedramp-moderate-AC-21(b)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - fedramp-low:
      - fedramp-low-AC-3
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-5
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-175
    title: AWS Systems Manager EC2 Associations Should Be Compliant
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-ec2-managedinstance-association-compliance-status-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-6.1
    - nist-csf:
      - nist-csf-ID.AM-2
      - nist-csf-PR.DS-3
      - nist-csf-PR.IP-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-CM-7(a)
      - nist-800-53-rev4-CM-8(3)(a)
      - nist-800-53-rev4-SI-2(2)
    - nist-800-171:
      - nist-800-171-3.4.1
      - nist-800-171-3.4.6
      - nist-800-171-3.4.9
    - fedramp-moderate:
      - fedramp-moderate-CM-2
      - fedramp-moderate-CM-7(a)
      - fedramp-moderate-CM-8(3)(a)
      - fedramp-moderate-SI-2(2)
    - fedramp-low:
      - fedramp-low-CM-2
    - cmmc-level5:
      - cmmc-level5-CM.2.061
      - cmmc-level5-CM.2.062
      - cmmc-level5-CM.2.063
      - cmmc-level5-CM.2.064
      - cmmc-level5-CM.2.065
      - cmmc-level5-SI.2.214
      - cmmc-level5-SI.2.217
      - cmmc-level5-AM.4.226
      - cmmc-level5-CM.5.074
    - cmmc-level4:
      - cmmc-level4-CM.2.061
      - cmmc-level4-CM.2.062
      - cmmc-level4-CM.2.063
      - cmmc-level4-CM.2.064
      - cmmc-level4-CM.2.065
      - cmmc-level4-SI.2.214
      - cmmc-level4-SI.2.217
      - cmmc-level4-AM.4.226
    - cmmc-level3:
      - cmmc-level3-CM.2.061
      - cmmc-level3-CM.2.062
      - cmmc-level3-CM.2.063
      - cmmc-level3-CM.2.064
      - cmmc-level3-CM.2.065
      - cmmc-level3-SI.2.214
      - cmmc-level3-SI.2.217
    - cmmc-level2:
      - cmmc-level2-CM.2.061
      - cmmc-level2-CM.2.062
      - cmmc-level2-CM.2.063
      - cmmc-level2-CM.2.064
      - cmmc-level2-CM.2.065
      - cmmc-level2-SI.2.214
      - cmmc-level2-SI.2.217
    - aws-wa-security:
      - aws-wa-security-SEC-6
    - aws
  - id: darkbit-aws-176
    title: AWS Systems Manager EC2 Patching Status Should Be Compliant
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-ec2-managedinstance-patch-compliance-status-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-6.2
    - nist-csf:
      - nist-csf-ID.RA-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-CM-8(3)(a)
      - nist-800-53-rev4-SI-2(2)
      - nist-800-53-rev4-SI-7(1)
    - nist-800-171:
      - nist-800-171-3.14.3
    - fedramp-moderate:
      - fedramp-moderate-CM-8(3)(a)
      - fedramp-moderate-SI-2(2)
      - fedramp-moderate-SI-7(1)
    - fedramp-low:
      - fedramp-low-CM-8
    - cmmc-level5:
      - cmmc-level5-CM.2.061
      - cmmc-level5-CM.2.064
      - cmmc-level5-RM.2.142
      - cmmc-level5-AM.4.226
      - cmmc-level5-CM.5.074
    - cmmc-level4:
      - cmmc-level4-CM.2.061
      - cmmc-level4-CM.2.064
      - cmmc-level4-RM.2.142
      - cmmc-level4-AM.4.226
    - cmmc-level3:
      - cmmc-level3-CM.2.061
      - cmmc-level3-CM.2.064
      - cmmc-level3-RM.2.142
    - cmmc-level2:
      - cmmc-level2-CM.2.061
      - cmmc-level2-CM.2.064
      - cmmc-level2-RM.2.142
    - aws-wa-security:
      - aws-wa-security-SEC-6
    - aws
  - id: darkbit-aws-177
    title: AWS GuardDuty Should Not Have Active Findings
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-guardduty-non-archived-findings
    - nist-csf:
      - nist-csf-DE.AE-4
      - nist-csf-RS.AN-2
    - nist-800-53-rev4:
      - nist-800-53-rev4-IR-4(1)
      - nist-800-53-rev4-IR-6(1)
      - nist-800-53-rev4-IR-7(1)
      - nist-800-53-rev4-RA-5
      - nist-800-53-rev4-SA-10
      - nist-800-53-rev4-SI-4(a)(b)(c)
    - nist-800-171:
      - nist-800-171-3.11.3
      - nist-800-171-3.6.1
    - hipaa:
      - hipaa-164.308(a)(6)(ii)
    - fedramp-moderate:
      - fedramp-moderate-IR-4(1)
      - fedramp-moderate-IR-6(1)
      - fedramp-moderate-IR-7(1)
      - fedramp-moderate-RA-5
      - fedramp-moderate-SA-10
      - fedramp-moderate-SI-4(a)(b)(c)
    - fedramp-low:
      - fedramp-low-IR-4
    - cmmc-level2:
      - cmmc-level2-IR.2.092
    - aws-wa-security:
      - aws-wa-security-SEC-7
    - aws
  - id: darkbit-aws-178
    title: API Gateway Stages Should Have Caching and Encryption Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-api-gw-cache-enabled-and-encrypted
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-3.4
    - nist-csf:
      - nist-csf-PR.DS-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-13
      - nist-800-53-rev4-SC-28
    - nist-800-171:
      - nist-800-171-3.13.16
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(a)(2)(iv)
      - hipaa-164.312(e)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-SC-28
    - fedramp-low:
      - fedramp-low-SC-13
    - cmmc-level5:
      - cmmc-level5-IA.2.081
      - cmmc-level5-SC.3.191
    - cmmc-level4:
      - cmmc-level4-IA.2.081
      - cmmc-level4-SC.3.191
    - cmmc-level3:
      - cmmc-level3-IA.2.081
      - cmmc-level3-SC.3.191
    - cmmc-level2:
      - cmmc-level2-IA.2.081
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-179
    title: CloudWatch LogGroups Should Be Encrypted With KMS CMKs
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-cloudwatch-log-group-encrypted
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-10.5.1
    - nist-csf:
      - nist-csf-PR.DS-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-AU-9
      - nist-800-53-rev4-SC-13
      - nist-800-53-rev4-SC-28
    - nist-800-171:
      - nist-800-171-3.13.16
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(a)(2)(iv)
      - hipaa-164.312(e)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-AU-9
      - fedramp-moderate-SC-28
    - fedramp-low:
      - fedramp-low-AU-9
      - fedramp-low-SC-13
    - cmmc-level5:
      - cmmc-level5-AU.3.049
      - cmmc-level5-SC.3.191
    - cmmc-level4:
      - cmmc-level4-AU.3.049
      - cmmc-level4-SC.3.191
    - cmmc-level3:
      - cmmc-level3-AU.3.049
      - cmmc-level3-SC.3.191
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-180
    title: DynamoDB Tables Should Be Encrypted With KMS
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-dynamodb-table-encrypted-kms
      - aws-cfg-dynamodb-table-encryption-enabled
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-13
    - nist-800-171:
      - nist-800-171-3.13.16
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-3.4
    - fedramp-moderate:
      - fedramp-moderate-SC-13
    - fedramp-low:
      - fedramp-low-SC-13
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-181
    title: EFS Volumes Should Be Encrypted With KMS
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-efs-encrypted-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-3.4
    - nist-csf:
      - nist-csf-PR.DS-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-13
      - nist-800-53-rev4-SC-28
    - nist-800-171:
      - nist-800-171-3.13.16
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(a)(2)(iv)
      - hipaa-164.312(e)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-SC-28
    - fedramp-low:
      - fedramp-low-SC-13
    - cmmc-level5:
      - cmmc-level5-IA.2.081
      - cmmc-level5-SC.3.191
    - cmmc-level4:
      - cmmc-level4-IA.2.081
      - cmmc-level4-SC.3.191
    - cmmc-level3:
      - cmmc-level3-IA.2.081
      - cmmc-level3-SC.3.191
    - cmmc-level2:
      - cmmc-level2-IA.2.081
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-182
    title: AWS KMS CMKs Should Not Be Scheduled For Deletion
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-kms-cmk-not-scheduled-for-deletion
    - nist-csf:
      - nist-csf-PR.DS-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-12
      - nist-800-53-rev4-SC-28
    - nist-800-171:
      - nist-800-171-3.13.10
      - nist-800-171-3.13.16
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(a)(2)(iv)
    - fedramp-moderate:
      - fedramp-moderate-SC-12
      - fedramp-moderate-SC-28
    - fedramp-low:
      - fedramp-low-SC-12
    - cmmc-level5:
      - cmmc-level5-SC.3.187
    - cmmc-level4:
      - cmmc-level4-SC.3.187
    - cmmc-level3:
      - cmmc-level3-SC.3.187
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-183
    title: S3 Buckets Should Not Allow Public Reads
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-s3-bucket-public-read-prohibited
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
      - pci-dss-3.2.1-7.2
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.DS-5
      - nist-csf-PR.PT-3
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-3
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-AC-21(b)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.2
      - nist-800-171-3.3.8
      - nist-800-171-3.4.6
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-3
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-6
      - fedramp-moderate-AC-21(b)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - fedramp-low:
      - fedramp-low-AC-3
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.2.062
      - cmmc-level5-AU.3.049
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.2.062
      - cmmc-level4-AU.3.049
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.2.062
      - cmmc-level3-AU.3.049
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-184
    title: S3 Buckets Should Not Allow Public Writes
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-s3-bucket-public-write-prohibited
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-1.2.1
      - pci-dss-3.2.1-1.3
      - pci-dss-3.2.1-7.2
    - nist-csf:
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-5
      - nist-csf-PR.DS-5
      - nist-csf-PR.PT-3
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-3
      - nist-800-53-rev4-AC-4
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-AC-21(b)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.2
      - nist-800-171-3.1.3
      - nist-800-171-3.13.2
      - nist-800-171-3.3.8
      - nist-800-171-3.4.6
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-3
      - fedramp-moderate-AC-4
      - fedramp-moderate-AC-6
      - fedramp-moderate-AC-21(b)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - fedramp-low:
      - fedramp-low-AC-3
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.1.003
      - cmmc-level5-SC.1.175
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.2.016
      - cmmc-level5-CM.2.062
      - cmmc-level5-AU.3.049
      - cmmc-level5-SC.3.180
      - cmmc-level5-AC.4.023
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.1.003
      - cmmc-level4-SC.1.175
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.2.016
      - cmmc-level4-CM.2.062
      - cmmc-level4-AU.3.049
      - cmmc-level4-SC.3.180
      - cmmc-level4-AC.4.023
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.1.003
      - cmmc-level3-SC.1.175
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.2.016
      - cmmc-level3-CM.2.062
      - cmmc-level3-AU.3.049
      - cmmc-level3-SC.3.180
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.1.003
      - cmmc-level2-SC.1.175
      - cmmc-level2-AC.2.007
      - cmmc-level2-AC.2.016
      - cmmc-level2-CM.2.062
    - cmmc-level1:
      - cmmc-level1-AC.1.001
      - cmmc-level1-AC.1.003
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-185
    title: Amazon SageMaker Endpoints Should Have KMS Configured
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-sagemaker-endpoint-configuration-kms-key-configured
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-3.4
    - nist-csf:
      - nist-csf-PR.DS-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-13
      - nist-800-53-rev4-SC-28
    - nist-800-171:
      - nist-800-171-3.13.16
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(a)(2)(iv)
      - hipaa-164.312(e)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-SC-28
    - fedramp-low:
      - fedramp-low-SC-13
    - cmmc-level2:
      - cmmc-level2-IA.2.081
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-186
    title: Amazon SageMaker Notebook Instances Should Have KMS Configured
    description: TODO
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-sagemaker-notebook-instance-kms-key-configured
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-3.4
    - nist-csf:
      - nist-csf-PR.DS-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-13
      - nist-800-53-rev4-SC-28
    - nist-800-171:
      - nist-800-171-3.13.16
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(a)(2)(iv)
      - hipaa-164.312(e)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-SC-28
    - fedramp-low:
      - fedramp-low-SC-13
    - cmmc-level2:
      - cmmc-level2-IA.2.081
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-187
    title: SNS Topics Should Be Encrypted With KMS
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-sns-encrypted-kms
    - nist-csf:
      - nist-csf-PR.DS-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-SC-13
      - nist-800-53-rev4-SC-28
    - nist-800-171:
      - nist-800-171-3.13.16
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(a)(2)(iv)
      - hipaa-164.312(e)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-SC-28
    - fedramp-low:
      - fedramp-low-SC-13
    - cmmc-level5:
      - cmmc-level5-IA.2.081
      - cmmc-level5-SC.3.191
    - cmmc-level4:
      - cmmc-level4-IA.2.081
      - cmmc-level4-SC.3.191
    - cmmc-level3:
      - cmmc-level3-IA.2.081
      - cmmc-level3-SC.3.191
    - cmmc-level2:
      - cmmc-level2-IA.2.081
    - aws-wa-security:
      - aws-wa-security-SEC-8
    - aws
  - id: darkbit-aws-188
    title: Application Load Balancers Should Enforce HTTPS
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-alb-http-to-https-redirection-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-4.1
    - nist-csf:
      - nist-csf-PR.DS-2
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-17(2)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-8
      - nist-800-53-rev4-SC-8(1)
      - nist-800-53-rev4-SC-13
      - nist-800-53-rev4-SC-23
    - nist-800-171:
      - nist-800-171-3.1.13
      - nist-800-171-3.13.1
      - nist-800-171-3.13.8
      - nist-800-171-3.5.10
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(e)(2)(i)
      - hipaa-164.312(e)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-AC-17(2)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-8
      - fedramp-moderate-SC-8(1)
      - fedramp-moderate-SC-23
    - fedramp-low:
      - fedramp-low-AC-17
    - cmmc-level5:
      - cmmc-level5-SC.1.175
      - cmmc-level5-IA.2.081
      - cmmc-level5-AC.3.014
      - cmmc-level5-SC.3.185
      - cmmc-level5-SC.3.190
    - cmmc-level4:
      - cmmc-level4-SC.1.175
      - cmmc-level4-IA.2.081
      - cmmc-level4-AC.3.014
      - cmmc-level4-SC.3.185
      - cmmc-level4-SC.3.190
    - cmmc-level3:
      - cmmc-level3-SC.1.175
      - cmmc-level3-IA.2.081
      - cmmc-level3-AC.3.014
      - cmmc-level3-SC.3.185
      - cmmc-level3-SC.3.190
    - cmmc-level2:
      - cmmc-level2-SC.1.175
      - cmmc-level2-IA.2.081
    - cmmc-level1:
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-9
    - aws
  - id: darkbit-aws-189
    title: Classic Load Balancers Should Have ACM Certificates Configured For SSL/HTTPS Listeners
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-elb-acm-certificate-required
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-4.1
    - nist-csf:
      - nist-csf-PR.DS-2
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-17(2)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-8
      - nist-800-53-rev4-SC-8(1)
      - nist-800-53-rev4-SC-13
    - nist-800-171:
      - nist-800-171-3.1.13
      - nist-800-171-3.13.1
      - nist-800-171-3.13.8
      - nist-800-171-3.5.10
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(e)(1)
      - hipaa-164.312(e)(2)(i)
      - hipaa-164.312(e)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-AC-17(2)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-8
      - fedramp-moderate-SC-8(1)
    - fedramp-low:
      - fedramp-low-AC-17
    - cmmc-level2:
      - cmmc-level2-SC.1.175
      - cmmc-level2-IA.2.081
    - cmmc-level1:
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-9
    - aws
  - id: darkbit-aws-190
    title: Classic Load Balancers Should Only Have SSL/HTTPS Listeners Configured
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-elb-tls-https-listeners-only
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-17(2)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-8
      - nist-800-53-rev4-SC-8(1)
      - nist-800-53-rev4-SC-23
    - nist-800-171:
      - nist-800-171-3.1.13
      - nist-800-171-3.13.1
      - nist-800-171-3.5.10
    - fedramp-moderate:
      - fedramp-moderate-AC-17(2)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-8
      - fedramp-moderate-SC-8(1)
      - fedramp-moderate-SC-23
    - fedramp-low:
      - fedramp-low-AC-17
    - cmmc-level5:
      - cmmc-level5-SC.1.175
      - cmmc-level5-IA.2.081
      - cmmc-level5-AC.3.014
      - cmmc-level5-SC.3.185
      - cmmc-level5-SC.3.190
    - cmmc-level4:
      - cmmc-level4-SC.1.175
      - cmmc-level4-IA.2.081
      - cmmc-level4-AC.3.014
      - cmmc-level4-SC.3.185
      - cmmc-level4-SC.3.190
    - cmmc-level3:
      - cmmc-level3-SC.1.175
      - cmmc-level3-IA.2.081
      - cmmc-level3-AC.3.014
      - cmmc-level3-SC.3.185
      - cmmc-level3-SC.3.190
    - cmmc-level2:
      - cmmc-level2-SC.1.175
      - cmmc-level2-IA.2.081
    - cmmc-level1:
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-9
    - aws
  - id: darkbit-aws-191
    title: Redshift Clusters Should Require TLS/SSL Connections
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-redshift-require-tls-ssl
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-4.1
    - nist-csf:
      - nist-csf-PR.DS-2
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-17(2)
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-8
      - nist-800-53-rev4-SC-8(1)
      - nist-800-53-rev4-SC-13
    - nist-800-171:
      - nist-800-171-3.1.13
      - nist-800-171-3.13.1
      - nist-800-171-3.13.8
      - nist-800-171-3.5.10
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.312(a)(2)(iv)
      - hipaa-164.312(e)(1)
      - hipaa-164.312(e)(2)(i)
      - hipaa-164.312(e)(2)(ii)
    - fedramp-moderate:
      - fedramp-moderate-AC-17(2)
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-8
      - fedramp-moderate-SC-8(1)
    - fedramp-low:
      - fedramp-low-AC-17
    - cmmc-level5:
      - cmmc-level5-SC.1.175
      - cmmc-level5-IA.2.081
      - cmmc-level5-AC.3.014
      - cmmc-level5-SC.3.185
    - cmmc-level4:
      - cmmc-level4-SC.1.175
      - cmmc-level4-IA.2.081
      - cmmc-level4-AC.3.014
      - cmmc-level4-SC.3.185
    - cmmc-level3:
      - cmmc-level3-SC.1.175
      - cmmc-level3-IA.2.081
      - cmmc-level3-AC.3.014
      - cmmc-level3-SC.3.185
    - cmmc-level2:
      - cmmc-level2-SC.1.175
      - cmmc-level2-IA.2.081
    - cmmc-level1:
      - cmmc-level1-SC.1.175
    - aws-wa-security:
      - aws-wa-security-SEC-9
    - aws
  - id: darkbit-aws-192
    title: S3 Bucket Policy Should Restrict Access To Approved Identities
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-s3-bucket-policy-grantee-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-7.1
      - pci-dss-3.2.1-7.2
    - nist-csf:
      - nist-csf-PR.AC-1
      - nist-csf-PR.AC-3
      - nist-csf-PR.AC-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-AC-3
      - nist-800-53-rev4-AC-6
      - nist-800-53-rev4-SC-7
      - nist-800-53-rev4-SC-7(3)
    - nist-800-171:
      - nist-800-171-3.1.1
      - nist-800-171-3.1.2
      - nist-800-171-3.1.20
      - nist-800-171-3.1.4
      - nist-800-171-3.1.5
      - nist-800-171-3.1.7
      - nist-800-171-3.3.8
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
      - hipaa-164.308(a)(3)(i)
      - hipaa-164.308(a)(3)(ii)(B)
      - hipaa-164.308(a)(4)(ii)(B)
      - hipaa-164.308(a)(4)(ii)(C)
      - hipaa-164.312(a)(1)
    - fedramp-moderate:
      - fedramp-moderate-AC-3
      - fedramp-moderate-AC-6
      - fedramp-moderate-SC-7
      - fedramp-moderate-SC-7(3)
    - fedramp-low:
      - fedramp-low-AC-3
    - cmmc-level5:
      - cmmc-level5-AC.1.001
      - cmmc-level5-AC.2.007
      - cmmc-level5-AC.3.017
      - cmmc-level5-AC.3.018
      - cmmc-level5-AU.3.049
    - cmmc-level4:
      - cmmc-level4-AC.1.001
      - cmmc-level4-AC.2.007
      - cmmc-level4-AC.3.017
      - cmmc-level4-AC.3.018
      - cmmc-level4-AU.3.049
    - cmmc-level3:
      - cmmc-level3-AC.1.001
      - cmmc-level3-AC.2.007
      - cmmc-level3-AC.3.017
      - cmmc-level3-AC.3.018
      - cmmc-level3-AU.3.049
    - cmmc-level2:
      - cmmc-level2-AC.1.001
      - cmmc-level2-AC.2.007
    - cmmc-level1:
      - cmmc-level1-AC.1.001
    - aws
  - id: darkbit-aws-193
    title: EC2 Instances Should Not Be Stopped For 30 Days
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-ec2-stopped-instance
    - nist-csf:
      - nist-csf-PR.IP-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-CM-2
    - nist-800-171:
      - nist-800-171-3.4.1
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
    - fedramp-moderate:
      - fedramp-moderate-CM-2
    - fedramp-low:
      - fedramp-low-CM-2
    - cmmc-level5:
      - cmmc-level5-CM.2.061
    - cmmc-level4:
      - cmmc-level4-CM.2.061
    - cmmc-level3:
      - cmmc-level3-CM.2.061
    - cmmc-level2:
      - cmmc-level2-CM.2.061
    - aws
  - id: darkbit-aws-194
    title: EBS Volumes Should Be Attached To EC2 Instances
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-ec2-volume-inuse-check
    - nist-csf:
      - nist-csf-PR.IP-1
    - nist-800-53-rev4:
      - nist-800-53-rev4-CM-2
      - nist-800-53-rev4-SC-4
    - nist-800-171:
      - nist-800-171-3.4.1
      - nist-800-171-3.4.6
    - fedramp-moderate:
      - fedramp-moderate-CM-2
      - fedramp-moderate-SC-4
    - fedramp-low:
      - fedramp-low-CM-2
    - cmmc-level5:
      - cmmc-level5-CM.2.061
      - cmmc-level5-CM.2.062
      - cmmc-level5-SC.3.182
    - cmmc-level4:
      - cmmc-level4-CM.2.061
      - cmmc-level4-CM.2.062
      - cmmc-level4-SC.3.182
    - cmmc-level3:
      - cmmc-level3-CM.2.061
      - cmmc-level3-CM.2.062
      - cmmc-level3-SC.3.182
    - cmmc-level2:
      - cmmc-level2-CM.2.061
      - cmmc-level2-CM.2.062
    - aws
  - id: darkbit-aws-195
    title: Elastic IP Addresses Should Be In Use
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-eip-attached
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-2.2
    - nist-csf:
      - nist-csf-PR.DS-3
    - nist-800-171:
      - nist-800-171-3.4.1
    - cmmc-level5:
      - cmmc-level5-CM.2.061
    - cmmc-level4:
      - cmmc-level4-CM.2.061
    - cmmc-level3:
      - cmmc-level3-CM.2.061
    - cmmc-level2:
      - cmmc-level2-CM.2.061
    - aws
  - id: darkbit-aws-196
    title: Lambda Functions Should Be Configured With A Dead Letter Queue
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-lambda-dlq-check
    - nist-csf:
      - nist-csf-DE.AE-5
    - nist-800-171:
      - nist-800-171-3.6.1
    - hipaa:
      - hipaa-164.308(a)(6)(i)
    - cmmc-level5:
      - cmmc-level5-IR.2.092
      - cmmc-level5-IR.2.093
    - cmmc-level4:
      - cmmc-level4-IR.2.092
      - cmmc-level4-IR.2.093
    - cmmc-level3:
      - cmmc-level3-IR.2.092
      - cmmc-level3-IR.2.093
    - cmmc-level2:
      - cmmc-level2-IR.2.092
      - cmmc-level2-IR.2.093
    - aws
  - id: darkbit-aws-197
    title: EC2 Instances Should Enable EBS-Optimization Where Possible
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-ebs-optimized-instance
    - nist-csf:
      - nist-csf-PR.IP-7
    - nist-800-171:
      - nist-800-171-3.13.2
    - cmmc-level5:
      - cmmc-level5-SC.3.180
      - cmmc-level5-RE.5.140
    - cmmc-level4:
      - cmmc-level4-SC.3.180
    - cmmc-level3:
      - cmmc-level3-SC.3.180
    - aws
  - id: darkbit-aws-198
    title: EC2 Instances Should Have Detailed Monitoring Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-ec2-instance-detailed-monitoring-enabled
    - nist-csf:
      - nist-csf-DE.DP-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-CA-7(a)(b)
      - nist-800-53-rev4-SI-4(2)
      - nist-800-53-rev4-SI-4(a)(b)(c)
    - fedramp-moderate:
      - fedramp-moderate-CA-7(a)(b)
      - fedramp-moderate-SI-4(2)
      - fedramp-moderate-SI-4(a)(b)(c)
    - fedramp-low:
      - fedramp-low-CA-7
    - cmmc-level5:
      - cmmc-level5-AU.4.053
    - cmmc-level4:
      - cmmc-level4-AU.4.053
    - aws
  - id: darkbit-aws-199
    title: RDS Instances Should Have Enhanced Monitoring Enabled
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-rds-enhanced-monitoring-enabled
    - nist-csf:
      - nist-csf-PR.DS-4
    - nist-800-53-rev4:
      - nist-800-53-rev4-CA-7(a)(b)
    - fedramp-moderate:
      - fedramp-moderate-CA-7(a)(b)
    - fedramp-low:
      - fedramp-low-CA-7
    - aws
  - id: darkbit-aws-200
    title: CodeBuild Project Source Repository URL Should Not Contain Credentials
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
    - aws-cfg:
      - aws-cfg-codebuild-project-source-repo-url-check
    - pci-dss-3.2.1:
      - pci-dss-3.2.1-8.2.1
    - nist-csf:
      - nist-csf-DE.AE-5
    - nist-800-53-rev4:
      - nist-800-53-rev4-SA-3(a)
    - hipaa:
      - hipaa-164.308(a)(1)(ii)(B)
    - fedramp-moderate:
      - fedramp-moderate-SA-3(a)
    - fedramp-low:
      - fedramp-low-SA-3
    - aws
  - id: darkbit-gcp-11
    title: Organization Admin Should Not Be Assigned at the Folder or Project Level
    description:
      The predefined Organization Administrator IAM Role is meant to be assigned
      at the Organization level, not the Folder or Project level.  This is likely a
      misconfiguration.  However, it offers the `resourcemanager.projects.setIamPolicy`
      permission which allows modification of permissions on that Project including
      adding oneself or others as "Project Owner" and gaining full access to the Project
      and all resources contained inside it.
    remediation:
      Review the need for Organization Administrator to be assigned at the
      Folder or Project level and instead grant the desired IAM Roles for those users.
    validation:
      For each folder, run `gcloud resource-manager folders get-iam-policy
      FOLDERIDNUMBER --format=json `| jq -r 'select(.bindings) | .bindings[] | select(.role=="roles/resourcemanager.organizationAdmin")
      | .members[]'.  For each project, run `gcloud projects get-iam-policy PROJECTID
      --format=json | jq -r 'select(.bindings) | .bindings[] | select(.role=="roles/resourcemanager.organizationAdmin")
      | .members[]'` and validate that no entries are present.
    impact: 3
    nodes:
      - PLACEHOLDER
    refs:
      - text: Organization Access Control
        url: https://cloud.google.com/resource-manager/docs/access-control-org
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
      - google cloud
  - id: darkbit-gcp-12
    title: Default Firewall Rules Should Be Removed
    description:
      The default firewalls in the default VPC permit inbound access to SSH,
      RDP, and ICMP from 0.0.0.0/0 and between all instances on the local subnet.  By
      default, GCE instances and GKE workers are created in the default subnet of the
      default VPC in a project and inherit this access for ease of use, but this means
      they are exposed via SSH or RDP to the entire Internet.
    remediation:
      Delete the default firewall rules in all projects and create new firewall
      rules explicitly with the principle of least privilege/access in mind.
    validation:
      In each project, run `gcloud compute firewall-rules list --format=json
      | jq -r '.[] | select(.name | test("^default-allow-")) | .name' | grep -v 'default-allow-internal'`
      and ensure entries named `default-allow-icmp`, `default-allow-rdp`, and `default-allow-ssh`
      are not listed.
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: Default Firewall Rules
        url: https://cloud.google.com/vpc/docs/firewalls#more_rules_default_vpc
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-3
          - nist-csf-pr.ac-4
          - nist-csf-pr.ac-5
          - nist-csf-pr.ds
          - nist-csf-pr.ds-5
      - google cloud
  - id: darkbit-gcp-13
    title: Firewall Logging Should Be Enabled on All Rules
    description:
      Firewall rules do not enable logging of connections by default.  In
      regulated environments, firewall logging is a requirement in almost every situation
      to be able to understand when systems are accessed on certain ports or for evidence
      of which systems were accessed in the event of a security incident.
    remediation:
      For all TCP and UDP firewall rules, enable firewall logging on each
      rule.  Logs are sent automatically to Stackdriver for review for the default retention
      period of 30 days.
    validation:
      In each project, run `gcloud compute firewall-rules list --format=json
      | jq -r '.[] | select(.logConfig.enable==false) | "(.name)"'` and ensure no entries
      are present.
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: Firewall Rules Logging
        url: https://cloud.google.com/vpc/docs/firewall-rules-logging
    tags:
      - nist-csf:
          - nist-csf-de
          - nist-csf-de.ae
          - nist-csf-de.ae-1
          - nist-csf-de.cm
          - nist-csf-de.cm-1
          - nist-csf-de.cm-7
      - google cloud
  - id: darkbit-gcp-16
    title: Default Deny Egress Firewall Rules Should Be Configured
    description:
      There are no egress firewall rules in place, so the implicit egress
      "allow all" firewall policy is in effect.  This allows any GCP resource to connect
      to any external destination on any port or protocol.  While this default configuration
      provides ease of use, it offers no protection for exfiltration of data, lateral
      movement, or network pivoting in the event of a compromise.
    remediation:
      Configure an explicit deny egress firewall rule in each VPC of priority
      65535, and configure explicit egress firewall rules that allow external access
      on the specific ports to specific destinations as needed.  When combined with
      firewall logging, this has the added benefit of detecting when applications are
      misconfigured or when potentially malicious activity is attempting to use non-approved
      ports.
    validation:
      In each project, run `gcloud compute firewall-rules list --format=json
      | jq -r '.[] | select(.destinationRanges) | select(.denied) | select(.direction=="EGRESS")
      | select(.destinationRanges[] | contains("0.0.0.0/0")) | select(.denied[].IPProtocol=="all")
      | "(.name)"'` and ensure that an entry is present.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Default GCP Firewall Rules
        url: https://cloud.google.com/vpc/docs/firewalls#default_firewall_rules
    tags:
      - nist-csf:
          - nist-csf-de
          - nist-csf-de.ae
          - nist-csf-de.ae-1
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-5
          - nist-csf-pr.ds
          - nist-csf-pr.ds-5
      - google cloud
  - id: darkbit-gcp-21
    title: Cloud Security Command Center Should Be Enabled
    description:
      'Security Command Center helps security teams gather data, identify
      threats, and act on them before they result in business damage or loss. It offers
      deep insight into application and data risk so that organizations can quickly
      mitigate threats to your their resources across and evaluate overall health. Security
      Command Center provides a single, centralized dashboard to:  - View and monitor
      an inventory of your cloud assets. - Scan storage systems for sensitive data.
      - Detect common web vulnerabilities and anomalous behavior. - Review access rights
      to your critical resources in your organization. - Apply recommended remediations
      to resolve vulnerabilities.'
    remediation:
      Logged into GCP with roles/resourcemanager.organizationAdmin and roles/securitycenter.admin
      permissions, navigate to Security > Security Command Center in the UI and follow
      the prompts for enabling the service for all current and future projects.  Also,
      click on "Security Health Analytics" in the Dashboard and enable it.  Finally,
      navigate to Security > Threat Detection and enable Event Threat Detection to be
      able to receive events in Cloud Security Command Center.
    validation:
      Run `for project in $(gcloud projects list --filter=parent.id=ORGIDNUMBER
      --format="value(projectId)"); do gcloud services list --project=$project | grep
      securitycenter; done` and ensure at least one entry is returned.
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: Cloud Security Command Center Quickstart
        url: https://cloud.google.com/security-command-center/docs/quickstart-scc-setup
    tags:
      - nist-csf:
          - nist-csf-id
          - nist-csf-id.am
          - nist-csf-id.am-2
          - nist-csf-id.am-5
          - nist-csf-id.gv
          - nist-csf-id.gv-1
          - nist-csf-id.ra
          - nist-csf-id.ra-1
          - nist-csf-id.ra-2
          - nist-csf-id.ra-3
          - nist-csf-id.ra-4
          - nist-csf-id.ra-6
      - google cloud
  - id: darkbit-gcp-24
    title: Firewall Rules Should Not Allow Access to MySQL TCP/3306 From All Hosts
    description:
      Firewall rules that permit inbound/ingress access from any IP address
      (0.0.0.0/0) to database ports via TCP/3306 should be reviewed for necessity to
      prevent unintended exposure of services and systems protected by that security
      group.  The primary exclusion to this is a dedicated, hardened bastion host.
    remediation:
      For each firewall rule, assess whether the attached systems requires
      Database access from any IP address.  If it doesn't, consider reducing the source
      IP ranges to a specific set of subnets where the applications and administrative
      systems reside.
    validation:
      In each project, run `gcloud compute firewall-rules list --format=json
      | jq -r '.[] | select(.sourceRanges) | select(.allowed) | select(.sourceRanges[]
      | contains("0.0.0.0/0")) | "(.name) (.allowed[])"'` and ensure no entries that
      permit `IPProtocol` of `tcp` and `ports` of `3306`.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: Configuring Firewall Rules
        url: https://cloud.google.com/vpn/docs/how-to/configuring-firewall-rules
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-3
          - nist-csf-pr.ac-4
          - nist-csf-pr.ac-5
          - nist-csf-pr.ds
          - nist-csf-pr.ds-5
      - google cloud
  - id: darkbit-gcp-25
    title: Firewall Rules Should Not Allow Access to PostgreSQL TCP/5432 From All Hosts
    description:
      Firewall rules that permit inbound/ingress access from any IP address
      (0.0.0.0/0) to database ports via TCP/5432 should be reviewed for necessity to
      prevent unintended exposure of services and systems protected by that security
      group.  The primary exclusion to this is a dedicated, hardened bastion host.
    remediation:
      For each firewall rule, assess whether the attached systems requires
      Database access from any IP address.  If it doesn't, consider reducing the source
      IP ranges to a specific set of subnets where the applications and administrative
      systems reside.
    validation:
      In each project, run `gcloud compute firewall-rules list --format=json
      | jq -r '.[] | select(.sourceRanges) | select(.allowed) | select(.sourceRanges[]
      | contains("0.0.0.0/0")) | "(.name) (.allowed[])"'` and ensure no entries that
      permit `IPProtocol` of `tcp` and `ports` of `5432`.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: Configuring Firewall Rules
        url: https://cloud.google.com/vpn/docs/how-to/configuring-firewall-rules
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-3
          - nist-csf-pr.ac-4
          - nist-csf-pr.ac-5
          - nist-csf-pr.ds
          - nist-csf-pr.ds-5
      - google cloud
  - id: darkbit-gcp-27
    title: GCE Instances/GKE Nodes Should Not Be Older Than 365 Days
    description:
      GCP Compute instances defined in Google Compute Engine (GCE) or Google
      Kubernetes Engine (GKE) should be recreated at least once per year to ensure that
      the automation to create them is working and all updates are applied.  Systems
      older than one year tend to be the systems that are overlooked when it comes to
      routine maintenance and patching.
    remediation:
      Review all GCP projects for instance age, and consider rebuilding and/or
      redeploying those instances while applying upgrades.  For GKE, instances should
      automatically cycle out during node version upgrades.
    validation:
      'Run `for project in $(gcloud projects list --filter=parent.id=<parent_project_id>
      --format="value(projectId)"); do gcloud compute instances list --project $project
      --filter="creationTimestamp>P1Y" --format=json | jq -r ''.[] | "(.zone):(.name):
      (.creationTimestamp)"''; done` and ensure no instances are listed.'
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Compute Instances
        url: https://console.cloud.google.com/compute/instances
    tags:
      - nist-csf:
          - nist-csf-id
          - nist-csf-id.be
          - nist-csf-id.be-4
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-2
      - google cloud
  - id: darkbit-gcp-32
    title: Shared VPC Projects Should Not Contain Non-VPC Related Resources
    description:
      GCP Projects that contain VPCs to be "shared" with other GCP Projects
      are also known as "Host" Projects, and the GCP Projects that are associated with
      the Host Projects are known as "Resource" Projects.  This approach maintains the
      networking configuration centrally with dedicated IAM permissions, and the ability
      to "use" the network is granted to each Service Project which is typically owned
      by other teams in the organization who own the instances and clusters.  Where
      possible, the Shared VPC project should retain its single purpose configuration
      and not hold resources unrelated to the VPC networking, routing, and firewall
      settings.  Resources outside of those purposes should be held in one or more Service
      Projects instead to maintain cleaner ownership and permissions isolation.
    remediation:
      If resources exist in the Shared VPC project that are not networking
      related, they should be migrated to a dedicated Service Project.  Permissions
      to manage the VPC resources in the Shared VPC Project should be carefully reviewed
      to ensure they only grant access to perform network configuration tasks.
    validation:
      Review all Host Projects and validate that no GCE instances, GKE clusters,
      GCS buckets, etc exist and that IAM permissions for the Project are only network-focused.
    impact: 3
    nodes:
      - PLACEHOLDER
    refs:
      - text: GCP Shared VPCs
        url: https://cloud.google.com/vpc/docs/shared-vpc
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-5
          - nist-csf-pr.ip
          - nist-csf-pr.ip-5
          - nist-csf-pr.pt
          - nist-csf-pr.pt-4
      - google cloud
  - id: darkbit-gcp-34
    title: Firewall Rules Should Not Allow Access to All Ports From All Hosts
    description:
      Firewall rules that allow all ports from any CIDR range are effectively
      disabling firewall protection to the attached service or system.
    remediation:
      For each firewall rule, review the application needs for protocols
      and ports, and reconfigure the firewall rule(s) to only grant access to those.
    validation:
      In each project, run `gcloud compute firewall-rules list --format=json
      | jq -r '.[] | select(.sourceRanges) | select(.allowed) | select(.sourceRanges[]
      | contains("0.0.0.0/0")) | "(.name) (.allowed[])"'` and ensure no entries that
      permit `IPProtocol` of `all`.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Configuring Firewall Rules
        url: https://cloud.google.com/vpn/docs/how-to/configuring-firewall-rules
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-3
          - nist-csf-pr.ac-4
          - nist-csf-pr.ac-5
          - nist-csf-pr.ds
          - nist-csf-pr.ds-5
      - google cloud
  - id: darkbit-gcp-35
    title: GCS Bucket Logging Should Be Enabled on All Storage Buckets
    description:
      GCS bucket logging helps maintain an audit trail of access that can
      be used in the event of a security incident.  Bucket logging is disabled by default,
      so any unauthorized access will go untraced unless this is explicitly enabled.
    remediation:
      Enable data access audit logs on all storage buckets that store data
      that requires auditable logging.
    validation:
      In each project, run `for bucket in $(gsutil ls); do gsutil logging
      get $bucket; done | grep "has no logging"` and validate that no entries are present.
    impact: 3
    nodes:
      - PLACEHOLDER
    refs:
      - text: GCS Audit Logs
        url: https://cloud.google.com/storage/docs/audit-logs
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-1
      - google cloud
  - id: darkbit-gcp-36
    title: GCS Object Versioning Should Be Enabled on All Storage Buckets
    description:
      GCS Buckets that store sensitive data should have object versioning
      enabled to help protect against the overwriting of objects or data loss in the
      event of a compromise.  A concrete example is a bucket that receives audit/access
      logs from other services.  Without object versioning, an attacker might be able
      to delete evidence of their activities.  With object versioning enabled, they
      won't be able to remove the original version of the log data.
    remediation:
      Enable object versioning on all storage buckets that store data that
      requires integrity protection.
    validation:
      In each project, run `for bucket in $(gsutil ls); do gsutil versioning
      get $bucket; done | grep "Suspended"` and validate that no entries are present.
    impact: 3
    nodes:
      - PLACEHOLDER
    refs:
      - text: GCS Object Versioning
        url: https://cloud.google.com/storage/docs/object-versioning
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-1
      - google cloud
  - id: darkbit-gcp-37
    title: Predefined GKE IAM Roles Should Be Avoided
    description:
      Access to the GKE Cluster API Server resources is controlled by a combination
      of IAM and in-cluster RBAC permissions.  If either grants access to the resource,
      access is allowed.  When using IAM permissions, access is granted to the permitted
      resources in all namespaces.  Using RBAC policies allows for granting more granular
      access to resources on a cluster-wide or per-namespace level and follows the principle
      of least privilege.  In this case, only IAM permissions are being used for allowing
      access via the "Project Owner" IAM Role, and this effectively grants full access
      to all resources in the cluster and "root" access to all GKE worker nodes.
    remediation:
      'The recommended approach is to avoid using IAM permissions to grant
      access to GKE clusters with one exception: a custom IAM Role that only permits
      cluster users with the ability to download a kubeconfig file via the "gcloud container
      clusters get-credentials" API call.  All Kubernetes access should be granted inside
      the cluster using RBAC ClusterRoleBindings or per-namespace RoleBindings.  Create
      a custom IAM Role call "Kubernetes API Access" with the following permissions:
      - container.apiServices.get - container.apiServices.list - container.clusters.get
      - container.clusters.getCredentials  Create a security group with all members
      that need cluster access, and bind the "Kubernetes API Access" IAM Role to that
      group at the project where the cluster lives.  For each administrator, create
      a ClusterRoleBinding that grants that user the "Cluster Admin" ClusterRole.  For
      each developer/CI system, create a RoleBinding that grants that user the Role
      they need in the namespace(s) they need access to that are not kube-system.  This
      is commonly the "admin" ClusterRole bound to the namespace to delegate them full
      control over that namespace.'
    validation:
      'Run `gcloud organizations get-iam-policy ORGIDNUMBER --format=json
      | jq -r ''select(.bindings) | .bindings[] | .role as $role | select(.role=="roles/container.admin"
      or .role=="roles/container.developer" or .role=="roles/container.viewer") | "($role):
      (.members[])"''` for the organization level.  For each folder, run `gcloud resource-manager
      folders get-iam-policy FOLDERIDNUMBER --format=json | jq -r ''select(.bindings)
      | .bindings[] | .role as $role | select(.role=="roles/container.admin" or .role=="roles/container.developer"
      or .role=="roles/container.viewer") | "($role): (.members[])"''`.  For each project,
      run `gcloud projects get-iam-policy PROJECTID --format=json | jq -r ''select(.bindings)
      | .bindings[] | .role as $role | select(.role=="roles/container.admin" or .role=="roles/container.developer"
      or .role=="roles/container.viewer") | "($role): (.members[])"''` and validate
      that the minimum assignments necessary are present.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes RBAC
        url: https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control
      - text: GKE Multi-tenancy
        url: https://speakerdeck.com/alp/multi-tenancy-best-practices-for-google-kubernetes-engine?slide=3
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
      - google cloud
  - id: darkbit-gcp-43
    title: Production GKE Clusters Should Have a Highly-Available Control Plane
    description:
      By default, GKE creates a "zonal" cluster.  That is, a cluster where
      the single control plane GCE instance is deployed in one GCP availability zone.  GKE
      clusters can also be configured as "regional" clusters in which three control
      plane GCE instances can be deployed evenly across three availability zones at
      no direct, additional cost.  Having three control plane instances insulates from
      a single control plane instance failure and allows for zero-downtime API server
      upgrades.
    remediation:
      For all production GKE clusters, configure the "location" as the region
      name instead of the zone name.  This requires rebuilding the cluster if it is
      already deployed as a zonal cluster.
    validation:
      Run `gcloud container clusters describe <clustername> --format=json
      | jq -r 'select(.location | test("^[a-z]+-[a-z0-9]+$")) | "(.name)"'` and ensure
      that the cluster's name is listed.
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: GKE Regional Clusters
        url: https://cloud.google.com/kubernetes-engine/docs/concepts/regional-clusters
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - google cloud
  - id: darkbit-gcp-45
    title:
      Production GKE Cluster Nodepools Should Be Spread Across Multiple Availability
      Zones
    description:
      By default, GKE creates a "zonal" cluster.  That is, a cluster where
      the single control plane GCE instance is deployed in one GCP availability zone
      and the worker GCE instances are deployed as a node pool in that same availability
      zone.  This optimizes for cost and simplicity at the expense of redundancy and
      protection against a zone outage.  If the control plane is set to "regional",
      then the worker GCE instances are deployed evenly across the three availability
      zones with instance groups per zone.  Setting the node pool instance count to
      "1" on a regional cluster will create one GCE instance in each of the three zones
      for a total of three worker nodes.
    remediation: |-
      For all production GKE clusters, configure the "location" as the region name instead of the zone name.  This requires rebuilding the cluster if it is already deployed as a zonal cluster.  The worker nodes will automatically be spread evenly across all three availability zones.

      Consideration: as traffic goes from node to node over zone boundaries, additional network costs will be incurred.
    validation:
      Run `gcloud container clusters describe <clustername> --format=json
      | jq -r 'select(.locations | length >= 3) | "(.name)"'` and ensure that the cluster's
      name is listed.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: GKE Regional Clusters
        url: https://cloud.google.com/kubernetes-engine/docs/concepts/regional-clusters
      - text: GKE Network Pricing
        url: https://cloud.google.com/compute/network-pricing
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - google cloud
  - id: darkbit-gcp-46
    title: GKE Maintenance Window Settings Should Be Explicitly Configured
    description:
      The GKE service performs maintenance functions on the cluster control
      plane and workers automatically, and the default configuration is for the time
      to be chosen by the service.  However, an organization will often want to configure
      that time window to fall during hours when traffic levels are lowest, batch processing
      is not occurring, or when operations teams are available to troubleshoot application
      issues.
    remediation:
      'Configure either a "simple" maintenance window of 4 hours (UTC) per
      day or a more complex maintenance window with rules to define a more granular
      schedule.  Consideration: The policy must allow at least 24 hours of maintenance
      availability in a 14-day rolling window. Only contiguous availability windows
      of at least four hours are considered.'
    validation:
      Run `gcloud container clusters describe <clustername> --format=json
      | jq -r 'select(.maintenancePolicy.window | null | not) | "(.name)"'` and ensure
      that the cluster's name is listed.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: GKE Maintenance Windows
        url: https://cloud.google.com/kubernetes-engine/docs/how-to/maintenance-windows-and-exclusions
    tags:
      - nist-csf:
          - nist-csf-id
          - nist-csf-id.ra
          - nist-csf-id.ra-4
          - nist-csf-pr
          - nist-csf-pr.ma
          - nist-csf-pr.ma-1
      - google cloud
  - id: darkbit-gcp-49
    title: GKE Metrics Should Be Sent to Stackdriver/GCP Cloud Monitoring
    description:
      By default, GKE enables a Stackdriver metrics export managed add-on
      capability that ships all Host OS, Kubernetes components, and container metrics
      to the Stackdriver metrics endpoint in the current project.  This provides a detailed
      record of nearly all performance metrics in the cluster and nodes to support troubleshooting
      and auditing functions.  Even if a third party metrics solution is implemented,
      it's recommended that this add-on is enabled to ensure all Host OS and Kubernetes
      component metrics are captured off-cluster.
    remediation:
      Configure the Kubernetes Engine Monitoring for "System and workload
      logging and monitoring" via the console or by way of the `--enable-stackdriver-kubernetes`
      option to gcloud on all GKE clusters. Existing clusters can have this feature
      enabled in-place with no downtime.
    validation:
      Run `gcloud container clusters describe <clustername> --format=json
      | jq -r 'select(.monitoringService=="monitoring.googleapis.com/kubernetes") |
      "(.name)"'` and ensure that the cluster's name is listed.
    impact: 6
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Engine Monitoring
        url: https://cloud.google.com/monitoring/kubernetes-engine/installing
    tags:
      - nist-csf:
          - nist-csf-de
          - nist-csf-de.ae
          - nist-csf-de.ae-1
          - nist-csf-de.ae-2
      - google cloud
  - id: darkbit-gcp-51
    title: GCP Projects Should Have Only One GKE Cluster
    description:
      GCP Projects are typically the most granular point for IAM permissions
      to be declared, and the way GKE clusters expect to leverage the project's resources
      makes isolating multiple clusters in the same project very difficult.  Assignment
      of IAM Roles related to instance and cluster administration is typically only
      available at the Project level, so permissions apply to all clusters.  In addition,
      logs and metrics sent from GKE clusters go to the Project's shared Stackdriver
      location, and IAM Roles for logging and monitoring grant access for all logs and
      metrics for all clusters and applications--making it extremely difficult to prevent
      users of one cluster from seeing all logs from all applications and all namespaces.  Finally,
      in some cases of misconfiguration, a compromise of a GKE cluster can lead to compromise
      of all clusters in the same Project.
    remediation:
      Organize GCP Projects such that each GKE Cluster has a designated Project
      with no other resources co-located unless they directly support the cluster.  Understand
      that certain IAM Roles such as "Compute Admin" equate to "Kubernetes Engine Administrator"
      because access to the GCE Instances that make up the GKE worker nodes as "root"
      means those users can also access all data, secrets, and applications inside Kubernetes.  Therefore,
      also review the IAM permissions in the Project to ensure unintended permission
      "cross-over" is minimized.
    validation:
      For each GCP Project, run `gcloud container clusters list` and ensure
      only one cluster is listed per project.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: IAM Concepts
        url: https://cloud.google.com/iam/docs/concepts
      - text: GCP Enterprise Best Practices
        url: https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
          - nist-csf-pr.ac-5
          - nist-csf-pr.ds
          - nist-csf-pr.ds-7
      - google cloud
  - id: darkbit-gcp-54
    title: GKE Node Pools Should Use the Minimum OAuth2 Scopes
    description: |-
      GKE Nodes are fundamentally GCE instances, and GCE instances with a Service Account attached have the permissions of the IAM Roles attached.  However, those permissions can be restricted even further by defining OAuth Scopes that explicitly list the APIs the OAuth Token generated for that Service Account are valid for.  For example, a GCE instance with an attached Service Account that is assigned the IAM Role of "Project Owner" but has only the "https://www.googleapis.com/auth/devstorage" OAuth Scope will only be able to interact with GCS Buckets.  However, if that OAuth Scope was set to "https://www.googleapis.com/auth/cloud-platform" (equivalent to "any/all APIs"), that instance would have the full privileges provided by "Project Owner".  By default, GKE Node Pools should only specify the following OAuth Scopes that provide the minimum access needed:

      * https://www.googleapis.com/auth/devstorage.read_only
      * https://www.googleapis.com/auth/logging.write
      * https://www.googleapis.com/auth/monitoring
      * https://www.googleapis.com/auth/service.management.readonly
      * https://www.googleapis.com/auth/servicecontrol
      * https://www.googleapis.com/auth/trace.append
    remediation:
      Configure GKE Node Pools to explicitly set only the minimum OAuth Scopes.  For
      pods/applications that were running on these nodes and leveraging the node's Service
      Account for access to GCP APIs, understand that access is shared by all pods unless
      Workload Identity is deployed.  To map GCP Service Accounts to individual Pods/Workloads,
      create GCP Service Accounts in the Project with the necessary permissions and
      leverage Workload Identity to attach those credentials directly.
    validation: |
      Run `gcloud container clusters describe <clustername> --format=json
      | jq -r 'select(.nodePools[].config.oauthScopes[] | test("cloud-platform") | not)
      | "(.name)"'` and ensure that the cluster's name is listed.
    impact: 5
    nodes:
      - GCP_CONTAINER_CLUSTER
      - GCP_IAM_OAUTHSCOPE
    refs:
      - text: GKE NodePool OAuth Scopes
        url: https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#use_least_privilege_sa
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
          - nist-csf-pr.ac-6
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
      - google cloud
  - id: darkbit-gcp-57
    title: CloudSQL Instances Should Be Configured For High-Availability
    description:
      By default, CloudSQL instances are deployed as a single instance, and
      this means an instance failure or availability-zone outage would take the database
      offline.  Production applications should be relying on access to data stores that
      can withstand these failure conditions where possible, and the CloudSQL service
      offering provides a high-availability instance type that runs in multiple availability-zones
      in the same region for this purpose.
    remediation:
      Create or update the CloudSQL instances used in production with the
      "REGIONAL" availability type instead of the default of "ZONAL". Existing instances
      can be modified to have these settings take effect, but it requires the instance
      to be restarted.
    validation:
      'In each project, run `gcloud sql instances list --format=json | jq
      -r ''.[] | select(.settings.availabilityType=="ZONAL") | "(.name) Type: (.settings.availabilityType)"''`
      and ensure no entries are listed as "ZONAL".'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: CloudSQL MySQL High Availability
        url: https://cloud.google.com/sql/docs/mysql/high-availability
      - text: CloudSQL PostgreSQL High Availability
        url: https://cloud.google.com/sql/docs/postgres/high-availability
      - text: CloudSQL Sqlserver High Availability
        url: https://cloud.google.com/sql/docs/sqlserver/high-availability
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - google cloud
  - id: darkbit-gcp-58
    title: CloudSQL Instances Maintenance Windows Should Be Configured
    description:
      The CloudSQL service performs maintenance functions on the instances
      automatically, and the default configuration is for the time to be chosen by the
      service.  However, an organization will often want to configure that time window
      to fall during hours when traffic levels are lowest, batch processing is not occurring,
      or when operations teams are available to troubleshoot application issues.
    remediation:
      Configure the maintenance preferences on the CloudSQL instance to a
      preferred window that has the days and hours when updates should occur, and select
      the order of update to be "Any", "Earlier", or "Later" to correspond to the timing
      of when the rolling updates should include this instance.  Typically, development
      instances should be set to "Earlier" and production instances set to "Later" to
      help validate upgrades and patches on less critical databases first.  Also, opt-in
      to email notifications for maintenance on the communications page at `https://console.cloud.google.com/user-preferences/communication`.
    validation:
      'In each project, run `gcloud sql instances list --format=json | jq
      -r ''.[] | select(.settings.maintenanceWindow.day==0 and .settings.maintenanceWindow.hour==0)
      | "(.name) Type: (.settings.maintenanceWindow.day) (.settings.maintenanceWindow.hour)"''`
      and ensure no entries are listed as "0 0".'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: CloudSQL MySQL Maintenance Windows
        url: https://cloud.google.com/sql/docs/mysql/maintenance
      - text: CloudSQL PostgreSQL Maintenance Windows
        url: https://cloud.google.com/sql/docs/postgres/maintenance
      - text: CloudSQL Sqlserver Maintenance Windows
        url: https://cloud.google.com/sql/docs/sqlserver/maintenance
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ma
          - nist-csf-pr.ma-1
      - google cloud
  - id: darkbit-gcp-118
    title: GKE Clusters Should Run The Linux Auditd Logging Daemonset
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
      - cis:
          - gke-cis1.1
          - gke-cis1.1-level2
          - gke-cis1.1-not-scored
          - gke-cis1.1-5
          - gke-cis1.1-5.7
          - gke-cis1.1-5.7.2
      - nist-csf:
          - nist-csf-todo
      - google cloud
  - id: darkbit-kubernetes-4
    title: Network Policies Should Be Defined in Each Namespace
    description:
      By default in Kubernetes, all Pods can communicate with each other
      by IP and egress to any subnet (including the Internet) unless routing or firewalls
      are added to prevent that traffic.  This presents ample opportunity for lateral
      movement from the perspective of a compromised workload. One of the best ways
      to reduce the scope of that movement is to deploy NetworkPolicy resources that
      define firewall rules for pod-to-pod traffic.  All pod-to-pod and egress traffic
      is allowed, and this means that pods that handle customer data can talk directly
      to core Kubernetes system pods, the Internet, and other systems inside the VPC
      if the security groups allow.
    remediation:
      'Implement NetworkPolicy rules on the kube-system namespace to prevent
      all inbound traffic from non-kube-system namespaces to all workloads in the kube-system
      namespace with the exception of UDP/TCP 53 for DNS lookups.  Next, identify the
      network traffic patterns of externally exposed workloads and implement NetworkPolicies
      that restrict their traffic to the "next hop" service or ranges.  Finally, perform
      the same pattern to all internal workloads.  Considerations: Implementing NetworkPolicies
      should be performed in a development environment to fully understand implications
      and to avoid introducing an outage in production.'
    validation:
      Run `kubectl get networkpolicies --all-namespaces` and ensure each namespace
      has the desired policies defined.
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Network Policies
        url: https://kubernetes.io/docs/concepts/services-networking/network-policies/
      - text: NetworkPolicy Recipes
        url: https://github.com/ahmetb/kubernetes-network-policy-recipes
    tags:
      - cis:
          - gke-cis1.1
          - gke-cis1.1-level1
          - gke-cis1.1-level2
          - gke-cis1.1-not-scored
          - gke-cis1.1-4
          - gke-cis1.1-4.3
          - gke-cis1.1-4.3.2
          - gke-cis1.1-5
          - gke-cis1.1-5.6
          - gke-cis1.1-5.6.7
          - eks-cis1.0.1
          - eks-cis1.0.1-level1
          - eks-cis1.0.1-level2
          - eks-cis1.0.1-4
          - eks-cis1.0.1-4.3
          - eks-cis1.0.1-4.3.2
          - eks-cis1.0.1-5
          - eks-cis1.0.1-5.4
          - eks-cis1.0.1-5.4.4
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-5
      - kubernetes
  - id: darkbit-kubernetes-5
    title: Kubernetes Service Accounts Should Not Be Mounted by Default
    description:
      By default, the "default" Service Account in each namespace will be
      mounted inside every container in every Pod unless explicitly configured to use
      another Service Account or to not be mounted.  The Service Account token that
      is mounted for convenience inside the pod in case the container workload needs
      a valid credential to communicate with the Kubernetes API.  However, most workloads
      do not require this access, and so they should be explicitly configured not to
      mount it to minimize exposure to these credentials.
    remediation:
      'For every non-kube-system namespace, modify all Service Accounts to
      opt out of automounting API credentials by setting automountServiceAccountToken:
      false.  Ensure RBAC bindings to all "default" Service Accounts are removed, and
      use dedicated Service Accounts for each workload that needs API Access with dedicated
      RBAC Role/ClusterRoleBindings.'
    validation:
      'Run `kubectl get pods --all-namespaces -ojson | jq -r ''.items[] |
      .metadata.namespace +"/"+ .metadata.name +": "+ .spec.serviceAccount''` and review
      the listing for pods that mount service accounts where API access is not required.  Typically,
      workloads that mount the "default" service account are likely candidates as pods
      should be mounting dedicated service accounts if needed.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes ServiceAccounts
        url: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
    tags:
      - cis:
          - gke-cis1.1
          - gke-cis1.1-level1
          - gke-cis1.1-not-scored
          - gke-cis1.1-4
          - gke-cis1.1-4.1
          - gke-cis1.1-4.1.6
          - eks-cis1.0.1
          - eks-cis1.0.1-level1
          - eks-cis1.0.1-4
          - eks-cis1.0.1-4.1
          - eks-cis1.0.1-4.1.6
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
          - nist-csf-pr.ac-4
      - kubernetes
  - id: darkbit-kubernetes-6
    title: Persistent Volume Claims Should Not Be Orphaned
    description:
      Multiple persistent disk volume claims were found to be in the "Released"
      state, and they indicate a potential misconfiguration in a deployment or statefulset
      leaving them behind.
    remediation:
      Ensure the workloads that created and abandoned the affected persistent
      volume claims correctly clean up after themselves and delete the persistent volume
      claims if they are no longer needed.
    validation:
      Run `kubectl get pvc --all-namespaces` and look for items in the "Released"
      state.  Ideally, all should be in use.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Persistent Volumes
        url: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-6
      - kubernetes
  - id: darkbit-kubernetes-7
    title: CPU/RAM Requests/Limits Should Be Configured on All Pods
    description:
      By default in Kubernetes, workloads that do not specify how many resources
      they expect to use and/or a limit to their resources receive the default settings.  The
      default settings depend on a LimitRange resource in the namespace, and the default
      is to request 1/10th of a CPU core (100 millicores or "100m"), no request for
      RAM, and no CPU or RAM limits.  This means that every pod is able to burst up
      to the total physical resources of the node, and the scheduler will tightly pack
      pods on a node.  This configuration is typically no problem at low or average
      load, so it might take a while to surface and cause resource constraint problems.  But
      when those resources are exhausted, the node becomes "Unready" and all workloads
      are evicted.  When they land on the other nodes that are already heavily loaded,
      it overloads them until they evict all pods.  This can cause a cascading resource
      failure outage.
    remediation:
      For every deployment in the cluster, ensure it has the proper settings
      for CPU and Memory "Requests" and CPU and Memory "Limits".  The "Requests" settings
      are vital for the scheduler to correctly place workloads on nodes without going
      over actual capacity.  The "Limits" settings are vital for the node to ensure
      the workload does not consume all physical resources on the node.  "Requests"
      should be set at 10% above average consumption and "Limits" should be 10-20% higher
      than maximum consumption.  Use "kubectl top node" and "kubectl top pods --all-namespaces"
      to see actual usage for running workloads.
    validation:
      'Run `kubectl get pods --all-namespaces -ojson | jq -r ''.items[] |
      .metadata.namespace as $ns | .metadata.name as $name| .spec.containers[] | $ns
      +"/"+ $name +"["+ .name +"]: "+ .resources.requests.cpu +","+ .resources.limits.cpu
      +","+ .resources.requests.memory +","+ .resources.limits.memory''` to get a comma
      separated listing of "CPU Req, CPU Limits, Memory Reqs, Memory Limits" for each
      container in every pod.  All containers should specify all four values explicitly.'
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Resourcing
        url: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
      - text: Kubectl Cheat Sheet
        url: https://kubernetes.io/docs/reference/kubectl/cheatsheet/#interacting-with-running-pods
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-11
    title: Cluster Workloads Should Not Mount the Docker Socket Directly
    description:
      In Kubernetes clusters running on nodes that leverage Docker for running
      containers, providing access to the `/var/run/docker.sock` is equivalent to granting
      that container 'root' on the underlying host as it allows for running containers
      on the node with any permission.  It should not be mounted inside a container
      as it bridges two layers in the infrastructure that should be kept independent
      from each other.  With the socket mounted, cluster users do not have to have 'cluster
      admin' to be able to get 'root' on the nodes.  Instead, they only need the 'exec
      pod' permission in this namespace to be able to exec commands inside this container
      to become 'root' on the nodes and compromise the cluster.  In addition, many Kubernetes
      distributions are moving to Containerd which does not have a listening Docker
      socket and therefore a smaller attack surface.
    remediation:
      Consider modifying the workload or choosing another workload that does
      similar functionality but does not mount the Docker socket.  This will remove
      the attack surface added by this workload and also enable the migration to worker
      images that run Containerd.
    validation:
      'Run `kubectl get pods --all-namespaces -ojson | jq -r ''.items[] |
      .metadata.namespace as $ns | .metadata.name as $name| .spec.volumes[] |select(.hostPath.path|tostring|test(".sock"))
      | $ns +"/"+ $name +"["+ .name +"]: "+ .hostPath.path''` and validate that no user-defined
      pods are returned that mount "/var/run/docker.sock" or similar.'
    impact: 6
    nodes:
      - PLACEHOLDER
    refs:
      - text: Protecting the Docker Socket
        url: https://docs.docker.com/engine/security/https/
      - text: GKE Containerd
        url: https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd
      - text: EKS Containerd
        url: https://github.com/aws/containers-roadmap/issues/313
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-3
      - kubernetes
  - id: darkbit-kubernetes-12
    title: Ensure Privileged Containers Are Only in System Namespaces
    description:
      Container run in Kubernetes that require deep access to the underlying
      worker nodes are often run in a `privileged` security context.  Common examples
      are daemonsets that implement functionality for container and host logging or
      metrics export, driver installation, and container and host security detection.  Privileged
      containers are essentially "root" on the underlying node, and they should therefore
      be kept in "system" namespaces to allow for proper RBAC and admission control
      policies to be created to protect them.  If they are in namespaces with other
      normal application workloads, it becomes difficult to ensure proper separation
      and prevent host escapes.
    remediation:
      Either leverage the `kube-system` namespace or deploy privileged daemonsets
      to dedicated namespaces only used for these purposes.  Restrict RBAC permissions
      and admission control policies to only permit the required admins access to operate
      and exec into them for troubleshooting.
    validation:
      'Run `kubectl get pods --all-namespaces -ojson | jq -r ''.items[] |
      "\(.metadata.namespace)/\(.metadata.name): \(.spec.containers[].securityContext.privileged)"''
      | grep -v "null$"` and validate that all privileged pods are in namespaces named
      and dedicated for system workloads.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes port-forward
        url: https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/
    tags:
      - cis:
          - gke-cis1.1
          - gke-cis1.1-level1
          - gke-cis1.1-scored
          - gke-cis1.1-4
          - gke-cis1.1-4.2
          - gke-cis1.1-4.2.1
          - eks-cis1.0.1
          - eks-cis1.0.1-level1
          - eks-cis1.0.1-4
          - eks-cis1.0.1-4.2
          - eks-cis1.0.1-4.2.1
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
          - nist-csf-pr.at
          - nist-csf-pr.at-2
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.pt
          - nist-csf-pr.pt-3
      - kubernetes
  - id: darkbit-kubernetes-13
    title: Container Images Should Refer to the Exact Tag or Commit
    description:
      When referring to a container image stored in a registry, it's common
      practice for the owner of the image to tag the most recent image with a semver
      tag and also the `latest` tag when uploading it.  This is a convenenience for
      users wanting to work with the most up-to-date image, but it presents an opportunity
      for inconsistencies inside Kubernetes.  If a deployment with more than one replica
      references an image with the tag `latest`, the underlying node will pull and run
      that image at that time.  If the image in the registry is updated with a new `latest`
      image and the deployment scales the number of replicas such that a new worker
      node is to run it, that node will potentially pull the newer `latest` image. This
      could result in multiple pods in a single deployment running a different image
      with different functionality or even cause a difficult to trace outage.  During
      the image build process, it's common practice to tag the image with shortened
      hash from the git commit that triggered the image build to help with tracing an
      image directly back to the code and process that created it and to satisfy certain
      auditing requirements.
    remediation:
      Review all deployments and pod specifications, and modify any that
      reference the `latest` tag to use a specific version tag or even the `sha256`
      hash.  Consider enforcing this practice early with a validation step in the CI/CD
      pipeline and enforcing the policy with OPA/Gatekeeper or other policy-based admission
      controller inside the cluster.
    validation: |-
      Run `kubectl get po -A -ojsonpath='{..image}' | kubectl get pods --all-namespaces -o jsonpath='{..image}' |tr -s '[[:space:]]' '
      ' | sort | uniq -c | grep latest` and ensure no images reference the `latest` tag.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Container Image Tagging
        url: https://docs.docker.com/engine/reference/commandline/build/#tag-an-image--t
      - text: Kubectl List Images
        url: https://kubernetes.io/docs/tasks/access-application-cluster/list-all-running-container-images/
      - text: Kubernetes Configuration Best Practices
        url: https://kubernetes.io/docs/concepts/configuration/overview/#container-images
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-6
      - kubernetes
  - id: darkbit-kubernetes-14
    title: Liveness and Readiness Probes Should Be Configured on Pods Listening on a Port
    description:
      By default, pods that listen on ports do not have Liveness and Readiness
      probes configured.  These are both required for pods to be able to support zero-downtime
      deployment upgrades for services that handle continuous traffic.  Readiness probes
      are network or command checks that have to succeed before the pod goes to the
      'Ready' state.  This means traffic routed to them by a Service will not occur
      until they are 'ready' to handle that traffic successfully.  Liveness probes are
      network or command checks that have to succeed on a routine basis for the pod
      to remain in the 'Ready' state.  If the checks fail, the pod will be removed from
      the 'Ready' state, and the service will know not to route traffic to that pod.
    remediation:
      All pods that listen on ports behind services should have Liveness
      and Readiness probes configured in their pod specification to behave properly
      and reduce network-related errors.
    validation:
      'Run `kubectl get pods --all-namespaces -ojson | jq -r ''.items[] |
      .metadata.namespace as $ns | .metadata.name as $name| .spec.containers[] | select(.ports)
      | $ns +"/"+ $name + "["+ .name +"]: "+ (.readinessProbe.successThreshold|tostring)
      +" "+ (.livenessProbe.successThreshold|tostring)''` and ensure every container
      that exposes ports also has non-zero numbers representing the readiness and liveness
      probes.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Liveness and Readiness Probes
        url: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-15
    title: Apparmor Profiles Should Be Implemented
    description:
      AppArmor is a Linux kernel security module that supplements the standard
      Linux user and group based permissions to confine programs to a limited set of
      resources. AppArmor can be configured for any application to reduce its potential
      attack surface and provide greater in-depth defense. It is configured through
      profiles tuned to whitelist the access needed by a specific program or container,
      such as Linux capabilities, network access, file permissions, etc.  AppArmor can
      help you to run a more secure deployment by restricting what containers are allowed
      to do, and/or provide better auditing through system logs. It is important to
      keep in mind that AppArmor is not a full exploit prevention mechanism, but it
      can reduce the abilities of a process inside a container that can limit further
      damage.  GKE nodes running Ubuntu and COS or COS_CONTAINERD have AppArmor support
      automatically enabled, but Kubernetes deployments must opt-in to be able to use
      AppArmor pods when they are run.
    remediation:
      'For all non-kube-system deployments/statefulsets, annotate the pod
      specification with "container.apparmor.security.beta.kubernetes.io/<container_name>:
      "runtime/default" for each container in the pod specification.  This will enable
      the default AppArmor profile if the container is not running as a "privileged"
      container and afford protection against sensitive endpoints in /proc and /sys.'
    validation:
      'Run `kubectl get pods --all-namespaces -ojson | jq -r ''.items[].metadata
      | "\(.namespace)/\(.name): \(.annotations)"'' | grep -v apparmor` to find the
      pods that do not specify an apparmor profile in their annotations.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes AppArmor
        url: https://kubernetes.io/docs/tutorials/clusters/apparmor/
      - text: Docker AppArmor
        url: https://docs.docker.com/engine/security/apparmor/
      - text: Default AppArmor Profile
        url: https://github.com/moby/moby/blob/master/profiles/apparmor/template.go
    tags:
      - nist-csf:
          - nist-csf-de
          - nist-csf-de.cm
          - nist-csf-de.cm-4
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-3
      - kubernetes
  - id: darkbit-kubernetes-16
    title: Seccomp Profiles Should Be Implemented
    description:
      Seccomp profiles define which system calls should be allowed or blocked,
      and the container runtime will apply then at container start time so the kernel
      can enforce it. Once applied, you are effectively decreasing your attack surface
      and limiting the container processes from making privileged syscalls in the event
      of a container compromise.
    remediation:
      'For all non-kube-system deployments/statefulsets, annotate the pod
      specification with "container.seccomp.security.alpha.kubernetes.io/<container_name>:
      "runtime/default" for each container in the pod specification.  This will enable
      the default Seccomp profile if the container is not running as a "privileged"
      container and afford protection against dangerous syscalls.'
    validation:
      'Run `kubectl get pods --all-namespaces -ojson | jq -r ''.items[].metadata
      | "\(.namespace)/\(.name): \(.annotations)"'' | grep -v seccomp` to find the pods
      that do not specify a seccomp profile in their annotations.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes SecurityContext
        url: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
      - text: Kubernetes Seccomp
        url: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp
      - text: Seccomp Examples
        url: https://github.com/kubernetes/kubernetes/blob/release-1.4/docs/design/seccomp.md#examples
      - text: Getting Started with Seccomp and Kubernetes
        url: https://itnext.io/seccomp-in-kubernetes-part-i-7-things-you-should-know-before-you-even-start-97502ad6b6d6
    tags:
      - kubernetes
  - id: darkbit-kubernetes-17
    title: Namespaces Should Have Resourcequotas Defined
    description:
      ResourceQuotas can be applied to a Kubernetes namespace to ensure the
      resources contained inside the namespace do not exceed a desired quota.  Setting
      appropriate limits on each namespace can ensure workloads to not exhaust all available
      resources and cause an outage.
    remediation:
      In each non-kube-system namespace, define a ResourceQuota that places
      limits on the maximum number of pods, CPU, and memory that can be used.  Ensure
      that every workload running in the namespace specifies a valid CPU and RAM requests
      and limits setting.
    validation:
      Run `kubectl get resourcequotas --all-namespaces` and ensure each namespace
      has a ResourceQuota resource configured.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Resource Quotas
        url: https://kubernetes.io/docs/concepts/policy/resource-quotas/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-18
    title: Namespaces Should Have Limitranges Defined
    description:
      LimitRanges can be applied to a Kubernetes namespace to ensure that
      all pods that fail to set a CPU and RAM requests and limits setting get an appropriate
      setting.  This ensures that pods are more accurately indicating to the Kubernetes
      scheduler how many actual resources they require, and that translates to nodes
      with more balanced workloads and avoids oversubscription situations that can cause
      outages.
    remediation:
      In each non-kube-system namespace, define a LimitRange that places
      a minimum setting for CPU and RAM requests/limits on all workloads that fail to
      define their own setting.
    validation:
      Run `kubectl get limitranges --all-namespaces` and ensure each namespace
      has a LimitRange resource configured.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes LimitRanges
        url: https://kubernetes.io/docs/concepts/policy/limit-range/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-21
    title: Pod Disruption Budgets Should Be Used for All Critical Deployments
    description:
      'Deployments with more than one replica require two critical elements
      to be able to handle a node failure or upgrade gracefully: Node anti-affinity
      to keep pods from being scheduled on the same node, and PodDisruptionBudgets (PDBs)
      which prevent the cluster from evicting pods unless enough other pods in that
      same deployment are healthy.  Without a PDB in place, a single node failure can
      temporarily evict too many pods and cause a service outage.'
    remediation:
      For each workload, determine if it requires high availability for the
      overall service to function.  If so, configure the deployment to have at least
      two replicas, have node anti-affinity to tell the Kubernetes scheduler to place
      them on separate nodes, use a service in front of the deployments for a discoverable
      name to reach, and configure a PodDisruptionBudget (PDB) to ensure that either
      a certain percentage of replicas are available or a certain number are not unavailable.
    validation:
      Run `kubectl get pdb --all-namespaces` and ensure that a PDB exists
      for each `deployment` and `statefulset`.
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes PodDisruptionBudgets
        url: https://kubernetes.io/docs/tasks/run-application/configure-pdb/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-26
    title: Only a Small Number of Cluster Admins Should Be Defined
    description:
      The number of groups and/or users that have the RBAC permission "cluster-admin"
      should be limited to a small number of total users.  When the majority of users
      in a cluster are operating as administrators, it defeats the purpose for separation
      of duties, increases the chances for an error to cause an outage, and it violates
      the principle of least privilege.
    remediation:
      Reduce the number of users with "cluster-admin" privileges to the smallest
      number feasible while still maintaining operational safety.  This is typically
      3-6 users.  To ease administration, create groups and bind the permissions to
      the group.
    validation:
      Run `kubectl get clusterrolebinding -o json | jq -r '.items[] | select((.roleRef.name=="cluster-admin")
      and .roleRef.kind=="ClusterRole") | .subjects[] | "\(.kind) \(.namespace) \(.name)"'`
      and evaluate the listing to ensure it contains only the required cluster administrators.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes RBAC
        url: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
    tags:
      - cis:
          - gke-cis1.1
          - gke-cis1.1-level1
          - gke-cis1.1-not-scored
          - gke-cis1.1-4
          - gke-cis1.1-4.1
          - gke-cis1.1-4.1.1
          - eks-cis1.0.1
          - eks-cis1.0.1-level1
          - eks-cis1.0.1-4
          - eks-cis1.0.1-4.1
          - eks-cis1.0.1-4.1.1
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
          - nist-csf-pr.at
          - nist-csf-pr.at-2
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.ma
          - nist-csf-pr.ma-1
          - nist-csf-pr.pt
          - nist-csf-pr.pt-3
      - kubernetes
  - id: darkbit-kubernetes-27
    title: Ensure the Kubernetes Dashboard Is Not Deployed
    description:
      While the Kubernetes dashboard is not inherently insecure on its own,
      it is often coupled with a misconfiguration of RBAC permissions that can unintentionally
      overgrant access and is not commonly protected with `NetworkPolicies` preventing
      all pods from being able to reach it.  In increasingly rare circumstances, the
      Kubernetes dashboard is exposed publicly to the Internet.
    remediation:
      Instead of running a workload inside the cluster to display a UI, leverage
      the cloud provider's UI for listing/managing workloads or consider a tool such
      as Octant running on local systems.  Run `kubectl get pods --all-namespaces -l
      k8s-app=kubernetes-dashboard` to find pods part of deployments and use kubectl
      to delete those deployments.
    validation:
      Running `kubectl get pods --all-namespaces -l k8s-app=kubernetes-dashboard`
      should not return any pods.
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Dashboard
        url: https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/
    tags:
      - cis:
          - gke-cis1.1
          - gke-cis1.1-level1
          - gke-cis1.1-scored
          - gke-cis1.1-5
          - gke-cis1.1-5.10
          - gke-cis1.1-5.10.1
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-3
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
      - kubernetes
  - id: darkbit-kubernetes-28
    title: Ensure the Kubernetes Versions in Use Are Supported
    description:
      The Kubernetes project is fast-moving and has historically released
      a minor version 3-4 times per year, and it maintains release branches for the
      three most recent minor releases (e.g. 1.18, 1.17, 1.16).  This means that the
      "upstream" Kubernetes project maintains security and bug fixes for a given minor
      release for about nine months.  When running on managed Kubernetes offerings like
      AKS, EKS, and GKE, the support policy is slightly different as there is a delay
      in validating and testing new minor releases before making them available to customers.  While
      it might be technically possible to be running an unsupported version, it means
      an upgrade is necessary to be able to get security and bug fixes, and managed
      providers may not be able to automatically patch your cluster on your behalf.
    remediation:
      Maintain awareness of the latest releases relative to the current running
      versions.  Perform upgrade testing in a development/sandbox environment first
      to avoid API deprecation issues.  If using a cloud provider's managed offering,
      consider enabling automatic upgrades in development/sandbox environments to ease
      administration burden and to identify issues early.  Practice and perform upgrades
      routinely to ensure the process does not go stale by administrators and application
      owners.
    validation:
      Run `kubectl version --short | grep "^Server"` to identify the version
      of the control plane.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Version Support
        url: https://kubernetes.io/docs/setup/release/version-skew-policy/
      - text: GKE Versions
        url: https://cloud.google.com/kubernetes-engine/versioning-and-upgrades
      - text: EKS Versions
        url: https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html
      - text: AKS Versions
        url: https://docs.microsoft.com/en-us/azure/aks/supported-kubernetes-versions
    tags:
      - nist-csf:
          - nist-csf-id
          - nist-csf-id.am
          - nist-csf-id.am-2
          - nist-csf-id.ra
          - nist-csf-id.ra-1
          - nist-csf-id.sc
          - nist-csf-id.sc-2
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.ma
          - nist-csf-pr.ma-1
      - kubernetes
  - id: darkbit-kubernetes-30
    title: Default Namespaces Should Not Be Used
    description:
      By default, user-managed resources will be placed in the `default`
      namespace.  This makes it difficult to properly define policies for RBAC permissions,
      service account usage, network policies, and more.  Creating dedicated namespaces
      and running workloads and supporting resources in each helps support proper API
      server permissions separation and network microsegmentation.
    remediation:
      Create dedicated namespaces for each type of related workload, and
      migrate those resources into those namespaces.  Ensure that RBAC permissions are
      not granted at the cluster scope but per namespace for the application owners
      at each namespace level.
    validation:
      Run `kubectl get all` in the `default`, `kube-public`, and if present,
      `kube-node-lease` namespaces.  There should only be the `kubernetes` service.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Namespaces
        url: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
    tags:
      - cis:
          - gke-cis1.1
          - gke-cis1.1-level1
          - gke-cis1.1-not-scored
          - gke-cis1.1-4
          - gke-cis1.1-4.6
          - gke-cis1.1-4.6.1
          - gke-cis1.1-4.6.4
          - eks-cis1.0.1
          - eks-cis1.0.1-level1
          - eks-cis1.0.1-level2
          - eks-cis1.0.1-4
          - eks-cis1.0.1-4.6
          - eks-cis1.0.1-4.6.1
          - eks-cis1.0.1-4.6.3
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
          - nist-csf-pr.ac-5
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.pt
          - nist-csf-pr.pt-3
      - kubernetes
  - id: darkbit-kubernetes-31
    title: Workloads Should Have Dedicated Kubernetes Service Accounts
    description:
      By default, pods that do not specify a service account have the "default"
      service account token for that namespace automatically mounted inside them.  This,
      by definition, becomes a shared credential that multiple workloads will use.  Similarly,
      workloads that do specify the same, non-default service account are also sharing
      credentials.  Multiple workloads sharing a service account credential makes it
      difficult to properly apply RBAC permissions following least privilege and also
      more difficult to identify which pod/deployment was responsible for an API call
      when reviewing audit logs during an incident.
    remediation:
      Ensure all deployments, daemonsets, and statefulsets are only mounting
      a service account if necessary and ensure it is unique to that workload.  Typically,
      naming the deployment and the service account with the same prefix helps this
      process.  Also, consider configuring the namespace to prevent the default service
      account from being mounted.
    validation:
      'Run `kubectl get pods -o json -A | jq -r ''.items[] | select(.spec.serviceAccountName!=null)
      | "\(.metadata.namespace)/\(.metadata.name): \(.spec.serviceAccountName)"''` to
      help identify which pods are mapping service accounts and to see if any are shared
      across workloads.  For all workload namespaces, consider disabling the automounting
      of the "default" service account.  Finally, enforce the use of non-default service
      accounts via dynamic admission control (e.g. OPA/Gatekeeper).'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Default Mounting of Service Accounts
        url: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server
      - text: OPA/Gatekeeper
        url: https://github.com/open-policy-agent/gatekeeper
    tags:
      - cis:
          - gke-cis1.1
          - gke-cis1.1-level1
          - gke-cis1.1-not-scored
          - gke-cis1.1-4
          - gke-cis1.1-4.1
          - gke-cis1.1-4.1.5
          - eks-cis1.0.1
          - eks-cis1.0.1-level1
          - eks-cis1.0.1-4
          - eks-cis1.0.1-4.1
          - eks-cis1.0.1-4.1.5
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
          - nist-csf-pr.ac-4
          - nist-csf-pr.ac-6
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
      - kubernetes
  - id: darkbit-kubernetes-34
    title: Non-System RBAC Roles/Clusterroles Should Not Use Wildcards
    description:
      When defining `Roles` and `ClusterRoles` in Kubernetes RBAC, it's possible
      to specify a wildcard using a `*` for both verbs and resources to simplify the
      policy creation process.  However, the Kubernetes API can change in subtle ways
      over time, and new resources and/or verbs may be introduced.  If a policy expresses
      "all resources" using a `*` and a new version of Kubernetes exposes a sensitive
      new resource, it may now match.  The intent of the previous policy will have been
      altered and potentially to an undesired effect.
    remediation:
      Review all `ClusterRoles` and `Roles` and ensure that all resources
      and verbs do not use the `*` declaration.  If they do, modify that policy to decleare
      the explicity resources and verbs instead.
    validation:
      Run `kubectl get roles --all-namespaces -o json | jq -r '.items[] |
      . as $role | .rules[] | select(((.resources!=null) and (.resources[] | contains("*"))
      or ((.nonResourceURLs!=null) and (.nonResourceURLs[] | contains("*")))) or select(.verbs[]
      | contains("*"))) | $role.metadata.name' | sort -u` to identify all `Roles` that
      specify a `*` for either resources or verbs.  Run `kubectl get clusterroles -o
      json | jq -r '.items[] | . as $role | .rules[] | select(((.resources!=null) and
      (.resources[] | contains("*")) or ((.nonResourceURLs!=null) and (.nonResourceURLs[]
      | contains("*")))) or select(.verbs[] | contains("*"))) | $role.metadata.name'
      | sort -u` for ClusterRoles.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes RBAC
        url: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
    tags:
      - cis:
          - gke-cis1.1
          - gke-cis1.1-level1
          - gke-cis1.1-not-scored
          - gke-cis1.1-4
          - gke-cis1.1-4.1
          - gke-cis1.1-4.1.3
          - eks-cis1.0.1
          - eks-cis1.0.1-level1
          - eks-cis1.0.1-4
          - eks-cis1.0.1-4.1
          - eks-cis1.0.1-4.1.3
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-3
      - kubernetes
  - id: darkbit-kubernetes-35
    title: Pods Should Not Be in an Undesired State
    description:
      Pods were identified with a current status that indicates a failure
      condition or an incorrect deployment configuration, and they should be corrected
      or removed.
    remediation:
      For each workload, identify the underlying cause of the failure condition.  It
      may need a correction to the container image, a pod specification adjustment,
      or the presence of a dependent resource such as a ConfigMap, a Secret, or a Persistent
      Volume.  Typically, the container logs (`kubectl logs`) and pod events (`kubectl
      describe pod) will provide the information needed to address the issue.
    validation:
      'Run `kubectl get pods --all-namespaces -o json | jq -r ''.items[] |
      select((.status.phase=="Failed") or select(.status.containerStatuses[].restartCount
      > 4)) | "\(.metadata.namespace)/\(.metadata.name) -- Status: \(.status.phase),
      High Restart Count: \(.status.containerStatuses[].restartCount > 4)"''` in each
      cluster to identify pods in an undesired state.  There should be none listed.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Application Debugging
        url: https://kubernetes.io/docs/tasks/debug-application-cluster/debug-application-introspection/
      - text: Kubernets Pod Lifecycle
        url: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
    tags:
      - nist-csf:
          - nist-csf-de
          - nist-csf-de.cm
          - nist-csf-de.cm-2
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-5
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-36
    title: Replicasets Should Always Be Associated With a Deployment Resource
    description:
      In all but the most custom use cases, ReplicaSets should only be used
      indirectly via a Deployment that manages it.  "Bare" ReplicaSets should be considered
      for migration to a full Deployment resource to take advantage of useful management
      features such as rolling update strategies, rollbacks, and garbage collection.
    remediation: Consider redeploying the ReplicaSet as a Deployment resource.
    validation:
      Run `kubectl get rs --all-namespaces -o json | jq -r '.items[] | . as
      $rs | .metadata | select((.ownerReferences==null) or .ownerReferences[].kind!="Deployment")
      | "\($rs.metadata.namespace)/\($rs.metadata.name)"'` and ensure there are no items
      listed.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes ReplicaSets
        url: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
      - text: Kubernetes Deployments
        url: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-5
      - kubernetes
  - id: darkbit-kubernetes-37
    title: Pods Should Not Have Tolerations to Run on the Control Plane Nodes
    description:
      In managed Kubernetes clusters such as AKS, EKS, and GKE, it's uncommon
      that user workloads are allowed to run on the control plane nodes in the interest
      of avoiding several direct attack vectors to certificates and etcd.  In other
      Kubernetes clusters, control plane nodes might be required to run certain workloads,
      and they would need a specific configuration setting to be permitted.  Care should
      be taken to ensure only desired workloads are allowed.
    remediation:
      Review the `tolerations` settings on all Pods in the cluster to ensure
      only the desired workloads are allowed to "tolerate" the `node-role.kubernetes.io/master:NoSchedule`
      `taint`.  Reconfigure any workload that does not have to run on the control plane
      to run on the worker nodes instead.  Further, consider modifying the approach
      of the cluster to run control plane workloads outside of the management of the
      Kubernetes API to maintain even greater logical and physical separation of the
      sensitive control plane components from user workloads.
    validation:
      'Run `kubectl get pods --all-namespaces -o json | jq -r ''.items[] |
      select(.status.phase == "Running" and ([ .spec.tolerations[] | select(.key ==
      "node-role.kubernetes.io/master") ] | length ) == 1 ) | .metadata.namespace +
      "/" + .metadata.name + ": " + (.spec.tolerations[] | select(.key == "node-role.kubernetes.io/master")
      | .key + ":" + .effect + " " + .operator + " " + .value)''` and validate the explicit
      set of allowed pods are the only ones listed.'
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Taints and Tolerations
        url: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.pt
          - nist-csf-pr.pt-3
      - kubernetes
  - id: darkbit-kubernetes-38
    title: Deployments Should Have More Than One Desired Replica Configured
    description:
      Deployments with only a single desired replica cannot maintain service
      during upgrades or node failures as there will always be a delay for the system
      to notice the pod is no longer running and when it can be scheduled on another
      node.  In conjunction with having a PodDisruptionBudget configured, having multiple
      replicas allows for continued availability of the workload during scheduled or
      unscheduled outages.
    remediation:
      Configure the Deployment replica count to be 2 or greater, and ensure
      a PodDisruptionBudget is configured for that deployment that enforces an appropriate
      `minAvailable` constraint.
    validation:
      Run `kubectl get deployments --all-namespaces -o json | jq -r '.items[]
      | select(.status.replicas==1) | "\(.metadata.namespace)/\(.metadata.name)"'` and
      ensure that all deployments listed can be unavailable for up to 10 minutes without
      harming the successful operation of the cluster or dependent workloads.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes PodDisruptionBudgets
        url: https://kubernetes.io/docs/tasks/run-application/configure-pdb/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-39
    title: Pods Should Not Have a Large TerminationGracePeriodSeconds Set
    description:
      When a Pod is told to exit, Kubernetes will wait `terminationGracePeriodSeconds`
      before sending a SIGKILL signal to the container process.  The default is 30 seconds,
      but it can and should be increased if the Pod requires extra time to finish processing
      work cleanly or to execute a PreStop Hook.  However, if the timeout is extended
      too far, this can cause long delays during node upgrades and rolling deployments.
    remediation:
      Identify workloads that have `terminationGracePeriodSeconds` set to
      5 or more minutes and validate that they need that time.  If possible, engineer
      the workload to handle termination more quickly while still maintaining overall
      application state.
    validation:
      'Run `kubectl get pods --all-namespaces -o json | jq -r ''.items[] |
      select(.spec.terminationGracePeriodSeconds>299) | "\(.metadata.namespace)/\(.metadata.name):
      \(.spec.terminationGracePeriodSeconds)"''` and consider the possibilities for
      reducing that timeout safely.'
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Termination of Kubernetes Pods
        url: https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.ip-2
      - kubernetes
  - id: darkbit-kubernetes-40
    title: Critical Workloads Should Have Anti-Affinity Rules Set
    description:
      Deployments and Statefulsets that require a certain number of Pods
      running at all times to maintain service availability should be configured with
      anti-affinity rules to avoid situations where multiple replicas are scheduled
      on the same node or in a common failure zone.  Should that node or failure zone
      experience an outage, an unexpected service disruption could result.
    remediation:
      Review all Deployments and Statefulsets for criticality and determine
      if additional guidance should be given to the scheduler in the form of affinity
      and/or anti-affinity rules.  Most commonly, this is either a "hard" or "soft"
      requirement to ensure only one Pod of a Deployment lands on the same node.
    validation:
      Run `kubectl get deployments --all-namespaces -o json | jq -r '.items[]
      | select(.spec.template.spec.affinity==null) | "\(.metadata.namespace)/\(.metadata.name)"'`
      and determine if affinity or anti-affinity rules are necessary to help avoid suboptimal
      scheduling.  Run `kubectl get deployments --all-namespaces -o json | jq -r '.items[]
      | select(.spec.template.spec.affinity==null) | "\(.metadata.namespace)/\(.metadata.name)"'`
      for statefulsets.
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: Assigning Pods to Nodes
        url: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-41
    title: Deployments/Statefulsets Should Have the Minimum Desired Healthy
    description:
      In a healthy cluster, all running pods should be active, and all Deployments
      and Statefulsets should have the desired number of active pods.  There are any
      number of reasons why the number of active replicas in a Deployment or Statefulset
      is not equal to the desired number, but the result is typically that the services
      being provided by the workload are degraded or even completely unavailable.
    remediation:
      The most common cause of this issue is due to insufficient cluster
      capacity to be able to successfully run the pod(s).  They will typically appear
      in the "Pending" state, and running `kubectl describe pod` will reveal the reason
      why the pod can't be scheduled.  That root cause should be addressed to allow
      the workload to continue operating normally.  For example, if a pod is "Pending"
      because there aren't enough CPU resources to satisfy the pods "CPU request", the
      cluster either needs additional nodes or larger nodes with greater CPU capacity.
    validation:
      'Run `kubectl get deployments --all-namespaces -o json | jq -r ''.items[]
      | . as $wkl | .status.conditions[] | select((.type=="Available") and .status!="True")
      | "\($wkl.metadata.namespace)/\($wkl.metadata.name): \(.message)"''` to identify
      unhealthy workloads and investigate with `kubectl describe pod <podname>` how
      to alleviate the underlying issue. Run `kubectl get statefulsets --all-namespaces
      -o json | jq -r ''.items[] | . as $wkl | .status.conditions[] | select((.type=="Available")
      and .status!="True") | "\($wkl.metadata.namespace)/\($wkl.metadata.name): \(.message)"''`
      for statefulsets.'
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Deployments
        url: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-42
    title: Services Should Have at Least Two Healthy Endpoints
    description:
      Cluster services that refer to pods via label selectors and port mappings
      will results in having `endpoint` resources created.  A healthy `service` should
      have at least 2 valid endpoints at all times which indicates that multiple pods
      are alive and actively handling requests.  Having "none" is an indication of misconfiguraion
      or outage, and having just one endpoint indicates a potential for service disruption
      during upgrades or node failures.
    remediation:
      Review all services in all namespaces for having at least two valid
      endpoints and address the misconfiguration or number of replicas as needed to
      ensure the correct number are active.
    validation:
      Run `for ns in $(kubectl get ns -o custom-columns=NAME:.metadata.name);
      do for svc in $(kubectl get -n $ns svc -o custom-columns=NAME:.metadata.name --no-headers);
      do EP="$(kubectl get endpoints -n $ns $svc -o json 2> /dev/null)";if [[ "$?" -ne
      0 ]]; then echo "$ns/$svc has 0 endpoints"; else echo "$EP" | jq -r 'select((.subsets[].addresses
      | length) < 2) | "\(.metadata.namespace)/\(.metadata.name) has fewer than 2 endpoints"';
      fi; done; done` to identify services with fewer than 2 healthy endpoints.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Debugging Services
        url: https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/#does-the-service-have-any-endpoints
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-43
    title: Pods in the Kube-System Namespace Should Be Configured to Avoid Eviction
    description:
      Pods in the `kube-system` namespace should be assigned the "system-cluster-critical"
      or "system-node-critical" `priorityClassName` to designate that the cluster should
      evict other pods not critical to the cluster or node's operation first.  When
      a worker node runs out of resources, it evicts the lowest priority pods that would
      remedy the resource exhaustion first.  Setting a `priority` at or above 2 billion
      (2000000000) indicates that a specific workload is critical to the functionality
      of the cluster.
    remediation:
      Review the specifications for the pods in the `kube-system` namespace
      and ensure it specifies a `priorityClassName` that has a numeric priority value
      above 2 billion.
    validation:
      'Run `kubectl get pods -n kube-system -o json | jq -r ''.items[] | select(.spec.priority
      < 2000000000) | "\(.metadata.namespace)/\(.metadata.name): \(.spec.priority)"''`
      and ensure no items are listed.'
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Pod Quality of Service
        url: https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
      - text: Out of Resource Handling
        url: https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/
      - text: Guaranteed Scheduling for Critical Pods
        url: https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-44
    title: Services Port Name Specifications Should Follow a Specific Naming Convention
    description:
      For the sake of clarity and current/future support for Istio service
      mesh, all port names in `service` definitions need to follow a convention to aid
      in proper protocol identification.  For example, a service exposes TCP port 443,
      but it's not clear to the service mesh if that is passing plain TCP, HTTP, HTTPS,
      TLS, or gRPC traffic.  Naming the port `tls` or `tls-foo` makes it clear what
      protocol is intended to pass through this service.
    remediation:
      Review all the ports exposed by services and ensure they follow the
      <protocol>[-<suffix>] naming convention.
    validation:
      'Run `kubectl get svc -A -o json | jq -r ''.items[] | . as $svc | .spec.ports[]
      | select(.name | test("^grpc|^http|^mongo|^mysql|^redis|^tcp|^tls|^udp")|not)
      | "\($svc.metadata.namespace)/\($svc.metadata.name): \(.name)"''` and ensure no
      items are listed.'
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Istio Service Naming Convention
        url: https://istio.io/docs/reference/config/analysis/ist0118/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.ip-5
      - kubernetes
  - id: darkbit-kubernetes-45
    title: Containers Should Have imagePullPolicy Set to Always
    description:
      'Pod specifications should explicitly set the `imagePullPolicy` to
      `Always` to ensure the correct version of the image is always being used.  This
      helps avoid issues where container image tags were overwritten in the container
      registry but the node uses its local cached version instead.  Note that the caching
      semantics of the underlying image provider make even imagePullPolicy: Always efficient.
      With Docker, for example, if the image already exists, the pull attempt is fast
      because all image layers are cached and no image download is needed.'
    remediation:
      Review all containers in pod specifications and ensure the `imagePullPolicy`
      setting is configured to be `Always`.
    validation:
      'Run `kubectl get pods -A -o json | jq -r ''.items[] | . as $pod | .spec.containers[]
      | select(.imagePullPolicy!="Always") | "\($pod.metadata.namespace)/\($pod.metadata.name):
      \(.name) \(.name) \(.imagePullPolicy)"''` and ensure no items are listed.'
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Best Practices
        url: https://kubernetes.io/docs/concepts/configuration/overview/#container-images
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.ip-5
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-48
    title: Nodeport Services Should Not Be Directly Exposed
    description:
      While Kubernetes supports exposing pods via a port on the underlying
      node from the TCP/30000-32768 range via the `NodePort` service type, it's not
      typically the desired approach.  Typically, clusters expose a shared set of load
      balancers and ingress controllers to handle external service exposure via standard
      APIs that handle path routing, logging, access control lists, and more.  `NodePort`
      services require opening uncommon TCP ports in the firewall and typicaly require
      tight coupling of worker node IPs to be used successfully, and that becomes problematic
      when nodes fail or when a scale event occurs.
    remediation:
      Convert `NodePort` services into type `LoadBalancer` or consider leveraging
      an ingress controller to expose the service on a specific hostname and port instead.
    validation:
      'Run `kubectl get svc -A -o json | jq -r ''.items[] | select(.spec.type=="NodePort")
      | "\(.metadata.namespace)/\(.metadata.name): \(.spec.type):\(.spec.ports[].nodePort)"''`
      and ensure that no items are listed.'
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: NodePort Services
        url: https://kubernetes.io/docs/concepts/services-networking/service/#nodeport
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-5
          - nist-csf-pr.ds
          - nist-csf-pr.ds-5
          - nist-csf-pr.pt
          - nist-csf-pr.pt-4
      - kubernetes
  - id: darkbit-kubernetes-49
    title:
      Services Should Have externalTrafficPolicy Set to Local to Preserve Source
      IP Address
    description:
      In certain cloud providers, service specifications can be set to the
      default of 'Cluster' or 'Local'.  Cluster obscures the client source IP and may
      cause a second hop to another node, but should have good overall load-spreading.
      Local preserves the client source IP and avoids a second hop for `LoadBalancer`
      and `NodePort` type services, but risks potentially imbalanced traffic spreading.  Preserving
      the client source IP is critical to being able to perform attribution if an attacker
      is probing or exploiting an exposed service.
    remediation:
      In GCP/GKE, ensure IP Aliasing is enabled on the subnet where the cluster
      is created and the cluster is configured to utilize those ranges.  In AWS, using
      the "Network Load Balancer" instead of the "Elastic Load Balancer" in combination
      with this setting, the source IP can be preserved.
    validation:
      'Run `kubectl get svc -A -o json | jq -r ''.items[] | select(.spec.type!="ClusterIP")
      | "\(.metadata.namespace)/\(.metadata.name): \(.spec.externalTrafficPolicy)"''`
      and validate that no items are listed.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Preserving the Source IP
        url: https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip
    tags:
      - nist-csf:
          - nist-csf-id
          - nist-csf-id.am
          - nist-csf-id.am-3
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-3
          - nist-csf-pr.ac-5
      - kubernetes
  - id: darkbit-kubernetes-50
    title: Ingresses Should Point to Active Services With Multiple Healthy Endpoints
    description:
      Ingress resources describe how to route traffic based on hostname and/or
      URI path to a desired service, and it's very easy to misconfigure an ingress configuration
      to point to an invalid service or an "empty" service.
    remediation:
      Review all ingress resource configurations, and ensure the `backend`
      configurations that point to a `service` are pointing to a service that exists
      and one that has healthy endpoints.
    validation:
      'Run `for entry in $( kubectl get ingress -A -o json | jq -r ''.items[]
      | . as $svc | .spec | .. | .backend? | select(.!=null) | "\($svc.metadata.namespace):\(.serviceName)"'');
      do ns="$(echo $entry | awk -F: ''{print $1}'')"; svc="$(echo $entry | awk -F:
      ''{print $2}'')"; EP="$(kubectl get endpoints -n $ns $svc -o json 2> /dev/null)";
      if [[ "$?" -ne 0 ]]; then echo "$ns/$svc has 0 endpoints"; else echo "$EP" | jq
      -r ''select(.subsets) | select((.subsets[].addresses | length) < 2) | "\(.metadata.namespace)/\(.metadata.name)
      has fewer than 2 endpoints"''; fi; done` and ensure that no services are listed.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Ingress
        url: https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource
      - text: Kubernetes Services
        url: https://kubernetes.io/docs/concepts/services-networking/service/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-51
    title: All Nodes Should Be Ready and Schedulable
    description:
      Healthy clusters running at optimal efficiency have all nodes in the
      "Ready" state and are actively receiving workloads.  Nodes that are not in the
      "Ready" state or are cordoned/unschedulable are incurring costs but are not contributing
      to the cluster's capacity.
    remediation:
      Repair all unhealthy nodes, and migrate workloads off of cordoned nodes
      before removing nodes.
    validation:
      'Run `kubectl get nodes -o json | jq -r ''.items[] | . as $node | .status.conditions[]
      | select((.type=="Ready") and .status!="True") | "\($node.metadata.name): \(.message)"''`
      and ensure no nodes are listed.  Also, run `kubectl get nodes -o json | jq -r
      ''.items[] | . as $node | select(.spec.unschedulable==true) | "\($node.metadata.name):
      cordoned/unschedulable"''` and validate no nodes are listed.'
    impact: 3
    nodes:
      - PLACEHOLDER
    refs:
      - text: Node Cordoning
        url: https://kubernetes.io/docs/concepts/architecture/nodes/#manual-node-administration
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.ip-2
      - kubernetes
  - id: darkbit-kubernetes-52
    title: All Nodes in the Cluster Should Be Running the Identical OS, Image, and Version
    description:
      To ensure consistent and reliable operation of the cluster and its
      workloads, the worker nodes should be running identical versions of the operating
      system image, kernel version, kube-proxy version, and kubelet version for each
      node pool or operating system type.
    remediation:
      Upgrade all nodes of each node pool to a common version for each underlying
      component.  Mixed operating system clusters should have identical versions per
      operating system.
    validation:
      Run `kubectl get nodes -o json | jq -r '.items[] | "\(.status.nodeInfo.containerRuntimeVersion)|\(.status.nodeInfo.kernelVersion)|\(.status.nodeInfo.kubeProxyVersion)|\(.status.nodeInfo.kubeletVersion)|\(.status.nodeInfo.osImage)"'
      | sort -u | wc -l` and ensure the output equals "1" to indicate that all nodes
      are identical.  Clusters that have multiple node pools or mixed operating system
      types should have one line count per nodepool or OS type.
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Version Skew Support
        url: https://kubernetes.io/docs/setup/release/version-skew-policy/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.ip-3
          - nist-csf-pr.ma
          - nist-csf-pr.ma-1
      - kubernetes
  - id: darkbit-kubernetes-53
    title: All Nodes Should Have > 20% Capacity Allocatable
    description:
      Kubernetes can pack workloads tightly onto nodes for excellent resource
      efficiency, but overutilized nodes are more prone to exhausting available resources.
      This can cause other colocated applications to run more slowly or even cause the
      kubelet to become unhealthy and evict workloads.  In addition, clusters should
      always have at least one node's worth of excess capacity ready to gracefully handle
      workloads rescheduled due to node maintenance or evictions.
    remediation:
      Ensure allocated capacity per node remains below 80%, and ensure that
      workloads are scheduled evenly across nodes.  Consider scaling the number of nodes
      up to ensure the total workload doesn't exceed 80% of the total cluster capacity.
    validation:
      Run `echo "NodeName CPU% Memory%"; kubectl top nodes --no-headers |
      awk '{print $1" "$3" "$5}'` and ensure that CPU and Memory are below 80% for all
      nodes.
    impact: 7
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Metrics Server
        url: https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-54
    title: All Nodes Should Be Spread Evenly Across Availability Zones
    description:
      When running Kubernetes clusters on cloud providers, production clusters
      should have their nodes spread as evenly as possible across multiple availability-zones
      in a given region.  Coupled with anti-affinity rules on critical workloads and
      multi-zone aware persistent-volumes, it's possible to withstand a single availability-zone
      outage should one occur.
    remediation:
      Configure the node pool/groups to leverage multiple availability zones.  Three
      zones are recommended in most cases.  Most cloud providers have a configuration
      option for spreading nodes of the same group across multiple availability zones.
    validation:
      'Run `kubectl get nodes -ojson | jq -r ''.items[].metadata | select(.annotations."failure-domain.beta.kubernetes.io/zone")
      | "\(.name): \(.annotations."failure-domain.beta.kubernetes.io/zone")"''` or `kubectl
      get nodes -ojson | jq -r ''.items[].metadata | select(.labels."failure-domain.beta.kubernetes.io/zone")
      | "\(.name): \(.labels."failure-domain.beta.kubernetes.io/zone")"''` and validate
      there are multiple availability zones listed and an equal (or near equal) number
      of nodes in each.'
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Node Labels
        url: https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone
      - text: AKS Multiple AZ Node Groups
        url: https://docs.microsoft.com/en-us/azure/aks/availability-zones#create-an-aks-cluster-across-availability-zones
      - text: EKS Multiple AZ Node Pools
        url: https://docs.aws.amazon.com/eks/latest/userguide/create-managed-node-group.html
      - text: GKE Multiple AZ Node Pools
        url: https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-regional-cluster
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ds
          - nist-csf-pr.ds-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-55
    title: Local Disk Persistentvolumes Should Not Mount Sensitive Host Paths
    description:
      While pods can be configured to mount a directory of the underlying
      worker node's filesystem to "escape" from the container, another similar pathway
      is by manually creating a "Local/HostPath" persistent volume and mounting it into
      the pod.  PodSecurityPolicy has native controls for the former approach, but it
      cannot prevent the latter.  The approach requires RBAC permissions to either create
      or use a custom storageclass, manually create or use a custom persistent volume,
      and permissions to create pods, so it is less likely to be available to non-privileged
      users.
    remediation:
      Ensure that permissions for creating custom storage classes are only
      granted to cluster admins, and review all storage classes and currently bound
      persistent volumes do not permit mounting sensitive paths on the underlying nodes
      in pod specifications.  Consider enforcing with a dynamic admission controller
      such as OPA/Gatekeeper.
    validation:
      'Run `kubectl get pv -o json | jq -r ''.items[] | select(.spec.hostPath)
      | "\(.metadata.name): \(.spec.hostPath.path)"''` and `kubectl get pv -o json |
      jq -r ''.items[] | select(.spec.local) | "\(.metadata.name): \(.spec.local.path)"''`
      and verify that no entries are listed.'
    impact: 2
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Local Persistent Volumes
        url: https://kubernetes.io/docs/concepts/storage/volumes/#local
      - text: OPA/Gatekeeper
        url: https://github.com/open-policy-agent/gatekeeper
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
          - nist-csf-pr.pt
          - nist-csf-pr.pt-3
      - kubernetes
  - id: darkbit-kubernetes-56
    title: Only Approved Mutating/ValidatingWebhookConfigurations Should Be Used
    description:
      Mutating and Validating Webhooks (Webhooks) are powerful extensions
      to the API server request flow, and they are typically used for adding functionality
      to resources before they are persisted and for enforcing security policy by way
      of dynamic admission controllers.  Because they defer authorization to an arbitrary
      location and get a full copy of the request, they can potentially see sensitive
      information.  They also can introduce latency in the API requiest flow as the
      API server needs to get a response or wait for a timeout before allowing the request
      to proceed.  Therefore, their usage should be limited to the smallest number necessary.
    remediation:
      Review the current configuration and ensure only the desired and authorized
      Webhooks are installed and that they are only watching the specific resourcesneeded.
    validation:
      Run `kubectl get mutatingwebhookconfiguration -A -oyaml` and `kubectl
      get validatingwebhookconfiguration -A -oyaml` and ensure the listed entries are
      desired.
    impact: 9
    nodes:
      - PLACEHOLDER
    refs:
      - text: Dynamic Admission Control
        url: https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-4
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.ip-5
      - kubernetes
  - id: darkbit-kubernetes-57
    title: Persistentvolumes Should Use Cross-Zone/Regional StorageClasses
    description:
      Where possible, deployments and statefulsets that mount persistent
      volumes should be using storageclasses that support being mounted in multiple
      zones.  By default, cloud provider network attached storage disks are only available
      in a single zone.  Should a zone experience a failure or outage, that data cannot
      be remounted by a pod until a healthy node in that zone returns unless that disk
      is configured as a type that should be replicated automatically.
    remediation:
      If supported, configure the storageclass to support multiple zones
      and ensure that all critical deployments and statefulsets are configured to use
      them.
    validation:
      Run `kubectl get storageclass -o json | jq -r '.items[]'` and review
      the storage classes available inside the cluster and their settings to see if
      regional support (vs single zone) is configured.  Then run `kubectl get deployments
      -A -o json | jq -r '.items[] | .spec.template.spec.volumes'` and `kubectl get
      sts -A -o json | jq -r '.items[] | .spec.template.spec.volumes'` to see which
      types of storageclass for persistent volumes are in use.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Persistent Volumes
        url: https://kubernetes.io/docs/concepts/storage/volumes/
      - text: Kubernetes Storageclasses
        url: https://kubernetes.io/docs/concepts/storage/storage-classes/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-58
    title: Jobs Should Be Healthy
    description:
      Jobs can often become unhealthy over time and may go unnoticed unless
      manually reviewed.  A common example is that of the VMWare Valero backup job to
      backup the contents of etcd to an external location like a cloud storage bucket.  Without
      that backup running successfully at a regular interval, the ability to restore
      the cluster to a recent state in a failure situation is compromised.
    remediation:
      Manually examine all Jobs resources for a successful execution history
      and resolve any issues identified.  If the Job is no longer needed, remove it.
    validation:
      'Run `kubectl get job -A -ojson | jq -r ''.items[] | select(.status.conditions)
      | select(.status.conditions[].type=="Failed" and .status.conditions[].status=="True")
      | "\(.metadata.namespace)/\(.metadata.name) failed: \(.status.conditions[].message)"''`
      and `kubectl get cronjob -A -ojson | jq -r ''.items[] | select(.status.conditions)
      | select(.status.conditions[].type=="Failed" and .status.conditions[].status=="True")
      | "\(.metadata.namespace)/\(.metadata.name) failed: \(.status.conditions[].message)"''`
      and ensure no entries are listed.'
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes Jobs
        url: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ip
          - nist-csf-pr.ip-5
          - nist-csf-pr.pt
          - nist-csf-pr.pt-5
      - kubernetes
  - id: darkbit-kubernetes-60
    title: RBAC Roles/Clusterroles Should Not Grant Permissions to System:Anonymous
    description:
      The built-in group named `system:anonymous` includes any user, group,
      or service account without a valid credential to the API server.  In earlier versions
      of Kubernetes, this "meta" group had a small number of permissions related to
      API discovery, but it is no longer intended for direct use.  This group should
      not be used to grant permissions to cluster subjects in nearly any legitimate
      situation, but it can occur by mistake and lead to unnecessary pathways to data
      leakage and privilege escalation.
    remediation:
      Review the permissions on the `system:anonymous` group and ensure that
      it has no granted permissions.  Remove or modify any ClusterRoleBinding that grants
      additional permissions, and grant permissions directly to authenticated users,
      groups, or service accounts instead.
    validation:
      Run `kubectl get clusterrolebinding -o json | jq -r '.items[] | . as
      $crb | select(.subjects) | .subjects[] | select(.name=="system:anonymous" and
      .kind=="Group") | $crb.roleRef.name'` and `kubectl get rolebinding -A -o json
      | jq -r '.items[] | . as $crb | select(.subjects) | .subjects[] | select(.name=="system:anonymous"
      and .kind=="Group") | $crb.roleRef.name'` and validate that no entries are listed
      that would indicate non-standard permissions were granted.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes API Discovery Roles
        url: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
          - nist-csf-pr.ac-4
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
      - kubernetes
  - id: darkbit-kubernetes-61
    title: RBAC Permissions for System:Authenticated Should Not Be Elevated
    description:
      The built-in group named `system:authenticated` includes any user,
      group, or service account with a valid credential to the API server.  This "meta"
      group is useful for providing a baseline set of permissions that all cluster users,
      groups, and service accounts need for API discovery purposes.  This group should
      not be used to grant additional permissions to cluster subjects beyond the defaults,
      but it can occur by mistake and lead to unnecessary pathways to data leakage and
      privilege escalation.
    remediation:
      'Review the permissions on the `system:authenticated` group and ensure
      that it is only bound to the baseline ClusterRoles: `system:basic-user`, `system:discovery`,
      and `system:public-info-viewer`.  Remove or modify any ClusterRoleBinding that
      grants additional permissions beyond these, and grant permissions directly to
      users, groups, or service accounts instead.'
    validation:
      Run `kubectl get clusterrolebinding -o json | jq -r '.items[] | . as
      $crb | select(.subjects) | .subjects[] | select(.name=="system:authenticated"
      and .kind=="Group") | $crb.roleRef.name' | egrep -v "system:basic-user|system:discovery|system:public-info-viewer"`
      and `kubectl get rolebinding -A -o json | jq -r '.items[] | . as $crb | select(.subjects)
      | .subjects[] | select(.name=="system:authenticated" and .kind=="Group") | $crb.roleRef.name'
      | egrep -v "system:basic-user|system:discovery|system:public-info-viewer"` to
      ensure no additional ClusterRoles or Roles have been granted to `system:authenticated`.  You
      can also run `kubectl auth can-i --list --as=system:authenticated` to see the
      current list of permissions.
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: Kubernetes API Discovery Roles
        url: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
          - nist-csf-pr.ac-4
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
      - kubernetes
  - id: darkbit-kubernetes-62
    title: Tiller (Helm V2) Should Not Be Deployed
    description:
      Helm version 1.x and 2.x rely on an in-cluster deployment named `Tiller`
      to handle lifecycle management of Kubernetes application bundles called `charts`.  The
      `Tiller` deployment is commonly granted elevated privileges to be able to carry
      out creation/deletion of resources contained inside `charts`, and it exposes a
      gRPC port on TCP/44134 without authentication or authorization, by default.  This
      combination was common, and it afforded a simple and direct path to escalation
      to cluster-admin from any pod in the cluster.  Now that Helm v3 no longer relies
      on an in-cluster component, `Tiller` is a signal that the cluster administrators
      have not upgraded to the more secure version.
    remediation:
      Refer to https://helm.sh/docs/topics/v2_v3_migration/ for guidance
      on migrating away from `Tiller`.  For new cluster deployments, use Helm v3 and
      above going forward.
    validation:
      Run `kubectl get pods --all-namespaces -o name | grep tiller` and validate
      that no pods starting with the name `tiller-deploy-****` exist.
    impact: 10
    nodes:
      - PLACEHOLDER
    refs:
      - text: Helm
        url: https://helm.sh
      - text: Tiller v2
        url: https://helm.sh/docs/faq/#removal-of-tiller
      - text: Helm Migration from v2 to v3
        url: https://helm.sh/docs/topics/v2_v3_migration/
      - text: Misusing Tiller
        url: https://engineering.bitnami.com/articles/helm-security.html
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-3
          - nist-csf-pr.ac-5
          - nist-csf-pr.ds
          - nist-csf-pr.ds-2
          - nist-csf-pr.ip
          - nist-csf-pr.ip-1
          - nist-csf-pr.ip-5
      - kubernetes
  - id: darkbit-kubernetes-64
    title: RBAC Permissions Should Not Be Assigned To The Default Service Accounts
    description:
      Because the "default" Kubernetes service account in each namespace
      is automatically assigned to pods unless explicit action is taken to opt out,
      it is by definition a shared account.  Attaching RoleBindings or ClusterRoleBindings
      to default service accounts can unintentionally provide permissions to other workloads
      in the namespace that do not need them.  Should those containers become compromised,
      they will give an attacker direct access to the allowed resources in the API server.  Depending
      on the binding, these permissions may allow for further damage.
    remediation: |
      In each namespace, create dedicated service accounts for each workload
      that needs API server access.  Reconfigure workloads to mount the dedicated service
      account, and then remove the RoleBindings and ClusterRoleBindings attached to
      the default service accounts.  Ensure all future workloads do not automatically
      mount the default service account by enabling the `automountServiceAccountToken:
      false` setting on each default service account definition.
    validation:
      Run `kubectl get rolebinding -A --output json | jq -r '.items[] | .metadata.namespace
      as $ns | .metadata.name as $name | select(.subjects) | .subjects[] | select(.name=="default"
      and .kind=="ServiceAccount") | "($ns) ($name)"'` and `kubectl get clusterrolebinding
      --output json | jq -r '.items[] | .metadata.namespace as $ns | .metadata.name
      as $name | select(.subjects) | .subjects[] | select(.name=="default" and .kind=="ServiceAccount")
      | "($ns) ($name)"'` in each cluster and ensure no entries are present.
    impact: 5
    nodes:
      - PLACEHOLDER
    refs:
      - text: Service Accounts for Pods
        url: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
    tags:
      - nist-csf:
          - nist-csf-pr
          - nist-csf-pr.ac
          - nist-csf-pr.ac-1
          - nist-csf-pr.ac-4
      - kubernetes
  - id: darkbit-kubernetes-65
    title: RBAC Permissions Should Minimize Access To Secrets
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
      - cis:
          - gke-cis1.1
          - gke-cis1.1-level1
          - gke-cis1.1-not-scored
          - gke-cis1.1-4
          - gke-cis1.1-4.1
          - gke-cis1.1-4.1.2
          - eks-cis1.0.1
          - eks-cis1.0.1-level1
          - eks-cis1.0.1-4
          - eks-cis1.0.1-4.1
          - eks-cis1.0.1-4.1.2
      - nist-csf:
          - nist-csf-todo
      - kubernetes
  - id: darkbit-kubernetes-66
    title: RBAC Permissions Should Minimize Access To Create Pods
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
      - cis:
          - gke-cis1.1
          - gke-cis1.1-level1
          - gke-cis1.1-not-scored
          - gke-cis1.1-4
          - gke-cis1.1-4.1
          - gke-cis1.1-4.1.4
          - eks-cis1.0.1
          - eks-cis1.0.1-level1
          - eks-cis1.0.1-4
          - eks-cis1.0.1-4.1
          - eks-cis1.0.1-4.1.4
      - nist-csf:
          - nist-csf-todo
      - kubernetes
  - id: darkbit-kubernetes-68
    title: Kubernetes Pods Should Have Security Contexts Defined
    description: TODO
    remediation: TODO
    validation: TODO
    impact: 8
    nodes:
      - PLACEHOLDER
    refs:
      - text: TODO
        url: TODO
    tags:
      - cis:
          - gke-cis1.1
          - gke-cis1.1-level2
          - gke-cis1.1-not-scored
          - gke-cis1.1-4
          - gke-cis1.1-4.6
          - gke-cis1.1-4.6.3
          - eks-cis1.0.1
          - eks-cis1.0.1-level2
          - eks-cis1.0.1-4
          - eks-cis1.0.1-4.6
          - eks-cis1.0.1-4.6.2
      - nist-csf:
          - nist-csf-todo
      - kubernetes