Skip to content
This repository was archived by the owner on Sep 16, 2026. It is now read-only.

Latest commit

 

History

History
653 lines (587 loc) · 67.4 KB

File metadata and controls

653 lines (587 loc) · 67.4 KB

AWS ACM

  • AWS ACM Certificate Expiration
    • When a certificate is 60 days away from expiration, ACM automatically attempts to renew it every hour.
  • AWS ACM Certificate Status
    • This policy checks if an ACM certificate renewal is pending or has failed and is in use by any other resources within the account.
  • AWS ACM Secure Algorithms
    • This policy validates that all ACM certificates are using secure key and signature algorithms.

AWS CloudFormation

AWS CloudTrail

AWS CloudWatch

  • AWS CloudWatch Log Encryption
    • AWS automatically performs server-side encryption of logs, but you can encrypt with your own CMK to protect extra sensitive log data.
  • AWS CloudWatch Logs Data Retention
    • By default, logs are kept indefinitely and never expire. You can adjust the retention policy for each log group, keeping the indefinite retention, or choosing a specific retention period.
  • Sensitive AWS CloudWatch Log Encryption
    • AWS automatically performs server-side encryption of logs, but you can encrypt with your own CMK to protect extra sensitive log data.

AWS Config

  • AWS Config Global Resources
    • You can have AWS Config record supported types of global resources, such as IAM users, groups, roles, and customer managed policies.
  • AWS Config Recording Status
    • This policy ensures that the config recorder is operational and capturing changes to your account without error.
  • AWS Config Records All Resource Types
    • This policy ensurers that you have a comprehensive configuration audit in place for all resource types in AWS.
  • AWS Config Status
    • This policy ensures that the config recorder is operational and capturing changes to your account.

AWS DynamoDB

  • AWS DynamoDB Table Autoscaling
    • DynamoDB Auto Scaling can dynamically adjust provisioned throughput capacity in response to traffic patterns. This enables a table to increase its provisioned read and write capacity to handle sudden increases in traffic
  • AWS DynamoDB Table Autoscaling Configuration
    • DynamoDB Auto Scaling can dynamically adjust provisioned throughput capacity in response to traffic patterns. This enables a table to increase its provisioned read and write capacity to handle sudden increases in traffic
  • AWS DynamoDB Table TTL
    • This policy validates that all DynamoDB tables have a TTL field configured.

AWS EC2

AWS EKS

  • EKS Anonymous API Access Detected
    • This rule detects anonymous API requests made to the Kubernetes API server. In production environments, anonymous access should be disabled to prevent unauthorized access to the API server.
  • EKS Audit Log based single sourceIP is generating multiple 403s
    • This detection identifies if a public sourceIP is generating multiple 403s with the Kubernetes API server.
  • EKS Audit Log Reporting system Namespace is Used From A Public IP
    • This detection identifies if an activity is recorded in the Kubernetes audit log where the user:username attribute begins with "system:" or "eks:" and the requests originating IP Address is a Public IP Address
  • IOC Activity in K8 Control Plane
    • This detection monitors for any kubernetes API Request originating from an Indicator of Compromise.
  • Kubernetes Cron Job Created or Modified
    • This detection monitor for any modifications or creations of a cron job. Attackers may create or modify an existing scheduled job in order to achieve cluster persistence.
  • Kubernetes Pod Created in Pre-Configured or Default Name Spaces
    • This detection monitors for any pod created in pre-configured or default namespaces. Only Cluster Admins should be creating pods in the kube-system namespace, and it is best practice not to run any cluster critical infrastructure here. The kube-public namespace is intended to be readable by unauthenticated users. The default namespace is shipped with the cluster and it is best practice not to deploy production workloads here. These namespaces may be used to evade defenses or hide attacker infrastructure.
  • New Admission Controller Created
    • This detection monitors for a new admission controller being created in the cluster. Admission controllers allows an attack to intercept all API requests made within a cluster, allowing for enumeration of resources and common actions. This can be a very powerful tool to understand where to pivot to next.
  • New DaemonSet Deployed to Kubernetes
    • This detection monitors for a new DaemonSet deployed to a kubernetes cluster. A daemonset is a workload that guarantees the presence of exactly one instance of a specific pod on every node in the cluster. This can be a very powerful tool for establishing peristence.
  • Pod attached to the Node Host Network
    • This detection monitor for the creation of pods which are attached to the host's network. This allows a pod to listen to all network traffic for all deployed computer on that particular node and communicate with other compute on the network namespace. Attackers can use this to capture secrets passed in arguments or connections.
  • Pod Created or Modified Using the Host IPC Namespace
    • This detection monitors for any pod creation or modification using the host IPC Namespace. Deploying pods in the Host IPC Namespace, breaks isolation between the pod and the underlying host meaning the pod has direct access to the same IPC objects and communications channels as the host system.
  • Pod Created or Modified Using the Host PID Namespace
    • This detection monitors for any pod creation or modification using the host PID namespace. The Host PID namespace enables a pod and its containers to have direct access and share the same view as of the host���s processes. This can offer a powerful escape hatch to the underlying host.
  • Pod Created with Overly Permissive Linux Capabilities
    • This detection monitors for a pod created with overly permissive linux capabilities. Excessive pod permissions and capabilities can be a launch point for privilege escalation or container breakout.
  • Pod creation or modification to a Host Path Volume Mount
    • This detection monitors for pod creation with a hostPath volume mount. The attachment to a node's volume can allow for privilege escalation through underlying vulnerabilities or it can open up possibilities for data exfiltration or unauthorized file access. It is very rare to see this being a pod requirement.
  • Privileged Pod Created
    • This detection monitors for a privileged pod is created either by default or with permissions to run as root. These particular pods have full access to the hosts namespace and devices, ability to exploit the kernel, have dangerous linux capabilities, and can be a powerful launching point for further attacks.
  • Secret Enumeration by a User
    • This detection monitors for a large number of secrets requests by a single user. This could potentially indicate secret enumeration, which can potentially enable lateral or vertical movement and unauthorized access to critical resources.
  • Unauthenticated Kubernetes API Request
    • This detection monitors for any unauthenticated kubernetes api request. Unauthenticated Requests are performed by the anonymous user and have unfederated access to the cluster.
  • Unauthorized Kubernetes Pod Execution
    • This detection monitors for any pod execution in a kubernetes cluster. Pod execution should never be done in a production cluster, and can indicate a user performing unauthorized actions.

AWS ELBV2

AWS GuardDuty

AWS IAM

  • AWS Access Key Rotation
    • This policy validates that AWS IAM account access keys are rotated every 90 days. Rotating access keys will reduce the window of opportunity for an access key that is associated with a compromised or terminated account to be used.
  • AWS Access Keys At Account Creation
    • This policy validates that AWS IAM user accounts do not have access keys that were created during account creation. This results in excess keys being generated, and unnecessary management work in auditing and rotating these keys.
  • AWS CloudTrail Least Privilege Access
    • Users with permissions to disable or reconfigure CloudTrail should be limited.
  • AWS IAM Group Users
    • This Policy ensures that all IAM groups have at least one IAM user. If they are vacant, they should be deleted.
  • AWS IAM Password Unused
    • This policy validates IAM users with console passwords have logged in within the past 90 days.
  • AWS IAM Policy Administrative Privileges
    • This policy validates that there are no IAM policies that grant full administrative privileges to IAM users or groups.
  • AWS IAM Policy Assigned to User
    • This policy validates that there are no IAM policies assigned directly to users. Best practice suggests assigning to an IAM group and placing users within that group.
  • AWS IAM Policy Blocklist
    • This detects the usage of highly permissive IAM Policies that should only be assigned to a small number of users, roles, or groups.
  • AWS IAM Policy Does Not Grant Any Administrative Access
    • This policy validates that no IAM policies grant admin access. This should be combined with suppressions on the legitimate IAM admin policies in your account so that it only fires when new and unexpected policies granting admin access are created.
  • AWS IAM Policy Does Not Grant Network Admin Access
    • This policy validates that no IAM policies grant admin privileges on network resources. This should be used in conjunction with suppressions for the legitimate network admin policies in your account.
  • AWS IAM Policy Role Mapping
    • This policy validates that policies that have been explicitly configured to be set to certain roles are still attached to those roles.
  • AWS IAM Resource Does Not Have Inline Policy
    • This policy validates that no IAM entities have inline policies assigned. Inline policies are more difficult to administer and audit, and may lead to access that lasts longer than intended.
  • AWS IAM Role Grants (permission) to Non-organizational Account
    • This policy validates that IAM roles that grant the (specified) permission do not allow accounts outside the organization to assume them.
  • AWS IAM Role Restricts Usage
    • This policy validates that IAM roles in the account are restrictive in what entities may assume them. This can help prevent malicious actors from assuming roles they should not be assuming.
  • AWS IAM Role Trust Relationship for GitHub Actions
    • This policy ensures that IAM roles used with GitHub Actions are securely configured to prevent unauthorized access to AWS resources. It validates trust relationships by checking for proper audience (aud) restrictions, ensuring it is set to sts.amazonaws.com, and subject (sub) conditions, confirming they are scoped to specific repositories or environments. Misconfigurations, such as overly permissive wildcards or missing conditions, can allow unauthorized repositories to assume roles, leading to potential data breaches or compliance violations. By enforcing these checks, the policy mitigates risks of exploitation, enhances security posture, and protects critical AWS resources from external threats.
  • AWS IAM User MFA
    • This policy validates that all AWS IAM users with access to the AWS Console have Multi-Factor Authentication (MFA) enabled.
  • AWS IAM User Not In Conflicting Groups
    • This policy validates that IAM users are not in IAM groups that are considered mutually exclusive. For example, in some workflows developers are responsible for dev environments and sysadmins are responsible for prod environments. In this situation no (or very few) users should be in both sysadmin and developer groups. This is in following with the principle of least privilege.
  • AWS Resource Minimum Tags
    • This policy ensures that applicable resources have a minimum number of tags set.
  • AWS Resource Required Tags
    • This policy ensures that AWS resources have specific tags, dependent on their resource type.
  • AWS Root Account Access Keys
    • This policy validates that no programmatic access keys exist for the root account.
  • AWS Root Account Hardware MFA
    • This policy validates that a hardware MFA device is in use for access to the root account.
  • AWS Root Account MFA
    • This policy validates that Multi Factor Authentication (MFA) is required for access to the root account.
  • AWS Unused Access Key
    • This policy validates that IAM user access keys are used at least once every 90 days.
  • IAM Inline Policy Network Admin
    • This policy validates that IAM entities (Groups, Roles, and Users) do not have inline policies attached that grant network admin privileges. Inline policies are more difficult to track and audit than managed policies, and can lead to persistent unexpected access.

AWS KMS

  • AWS KMS CMK Key Rotation
    • This policy validates that customer master keys (CMKs) have automatic key rotation enabled.
  • AWS KMS Key Restricts Usage
    • This policy validates that KMS Keys restrict what entities can use them and how. This is to ensure that encryption keys are limited in who can use them in order to prevent unapproved decryption.

AWS Lambda

  • AWS Lambda Public Access
    • This policy ensures that the function policy attached to the Lambda resource prohibits public access

AWS PasswordPolicy

AWS RDS

  • AWS RDS Instance Backup
    • This Policy ensures that RDS Instances have Backups enabled. Backups are an important aspect of disaster recovery that can protect sensitive data from destruction.
  • AWS RDS Instance Encryption
    • This policy validates that RDS instances have encryption enabled.
  • AWS RDS Instance Has Acceptable Backup Retention Period
    • This policy validates that RDS instances are configured with a backup retention period that is acceptable to company policy. This ensures for both compliance and security reasons that records are kept for a minimum period of time, and for compliance and performance reasons that records are not kept indefinitely.
  • AWS RDS Instance High Availability
    • This Policy ensures that RDS Instances have are running in High Availability mode to provide redundancy in the event of an operational failure. For Aurora, storage is replicated across all the Availability Zones and doesn't require this setting.
  • AWS RDS Instance Minor Version Upgrades
    • If you want Amazon RDS to upgrade the DB engine version of a database automatically, you can enable auto minor version upgrades for the database.
  • AWS RDS Instance Public Access
    • This Policy checks that an RDS Instance is not accessible from the public internet.
  • AWS RDS Instance Snapshot Public Access
    • This policy validates that RDS Instance snapshots are not publicly restorable. This would allow anyone to restore an old version of your database and have full access to its contents.

AWS Redshift

AWS S3

AWS S3ServerAccess

  • AWS S3 Access Error
    • Checks for errors during S3 Object access. This could be due to insufficient access permissions, non-existent buckets, or other reasons.
  • AWS S3 Access IP Allowlist
    • Checks that the remote IP accessing the S3 bucket is in the IP allowlist.
  • AWS S3 Insecure Access
    • Checks if HTTP (unencrypted) was used to access objects in an S3 bucket, as opposed to HTTPS (encrypted).
  • AWS S3 Unauthenticated Access
    • Checks for S3 access attempts where the requester is not an authenticated AWS user.
  • AWS S3 Unknown Requester
    • Validates that proper IAM entities are accessing sensitive data buckets.

AWS SecurityFindingFormat

AWS VPCDns

  • AWS DNS Crypto Domain
    • Identifies clients that may be performing DNS lookups associated with common currency mining pools.
  • DNS Base64 Encoded Query
    • Detects DNS queries with Base64 encoded subdomains, which could indicate an attempt to obfuscate data exfil.
  • VPC DNS Tunneling
    • Detect dns tunneling traffic using a scheduled query

AWS VPCFlow

AWS WAF

  • AWS WAF Has XSS Predicate
    • This policy validates that all WAF's have at least one rule with a predicate matching on and blocking XSS attacks.
  • AWS WAF Logging Configured
    • Ensures that AWS WAF logging is enabled and that the logs are being sent to a valid destination (S3, CloudWatch, or Kinesis Firehose). Without logging, visibility into WAF activity is severely limited, increasing the risk of undetected attacks.
  • AWS WAF Rule Ordering
    • This policy validates that all WAF's have the correct rule ordering. Incorrect rule ordering could lead to less restrictive rules being matched and allowing traffic through before more restrictive rules that should have blocked the traffic.
  • AWS WAF WebACL Has Associated Resources
    • This policy ensures that AWS WAF WebACLs are associated with at least one resource (ALB, CloudFront Distribution, or API Gateway). If a WebACL is not associated with any resources, it is inactive and not providing any protection.