Checks

GuardDuty detectors are evaluated for EKS Runtime Monitoring being enabled for Amazon EKS. The configuration is at the detector level and relates to visibility into process, file, and network activity on EKS nodes and containers.

Amazon GuardDuty detector existence and health are evaluated per Region. It identifies where GuardDuty isn't enabled for the account, where a detector has no status, or where a detector is configured but suspended.

Amazon GuardDuty detectors with Lambda Protection enabled analyze Lambda invocation network activity logs across your account.

Evaluation determines whether the detector has Lambda Protection turned on.

GuardDuty detectors are evaluated for the presence of High-severity findings. This surfaces whether any detector currently has findings labeled High by GuardDuty.

Active Amazon GuardDuty detectors are assessed for RDS Protection being enabled, allowing analysis of RDS and Aurora login activity to profile and flag anomalous access patterns.

GuardDuty detectors are evaluated for unified Runtime Monitoring being enabled. The configuration is at the detector level and relates to visibility into process execution, file access, and network connections on Amazon EC2 instances, Amazon ECS on AWS Fargate tasks, and Amazon EKS nodes and containers. The legacy EKS-only feature covers Amazon EKS alone and does not satisfy this check.

Amazon GuardDuty detectors are evaluated for S3 Protection, which analyzes CloudTrail S3 data events to monitor object-level API activity (GetObject, PutObject, DeleteObject) across S3 buckets in the account and Region.

Security groups should not allow unrestricted access to all ports from the public internet (0.0.0.0/0 or ::/0). This includes rules with no port range specified or rules covering the full port range (0-65535 or 1-65535). Allowing all ports exposes every service running on the instances to potential attacks.

Security groups should not allow unrestricted access to database ports from the public internet (0.0.0.0/0 or ::/0). This includes MySQL (3306), PostgreSQL (5432), MongoDB (27017), Redis (6379), SQL Server (1433), and CouchDB (5984). Unrestricted database access can lead to data breaches and unauthorized access.

Security groups should not allow unrestricted RDP access (port 3389) from the public internet (0.0.0.0/0 or ::/0). Unrestricted RDP access increases the attack surface and can lead to unauthorized access, brute force attacks, and potential system compromise.

Security groups should not allow unrestricted SSH access (port 22) from the public internet (0.0.0.0/0 or ::/0). Unrestricted SSH access increases the attack surface and can lead to unauthorized access, brute force attacks, and potential system compromise.

Servers should not have public IP addresses directly attached to their network interfaces unless strictly required. A public IP exposes the server to inbound traffic from the internet on all ports not blocked by a security group, increasing the attack surface.

GCP project has Access Approval configured at the project level, requiring explicit customer authorization before Google personnel can access project data. The evaluation looks for Access Approval settings associated with the project.

Huawei Cloud IAM password policies can be used to enforce password complexity requirements. It is recommended that the password policy require a minimum of 14 or greater characters for any password. Longer passwords provide exponentially more security against automated password cracking, as the keyspace increases dramatically with each additional character.

IAM groups with the AdministratorAccess managed policy are assessed to ensure all member users have active MFA.

The finding highlights any administrator group that includes a user without MFA enrollment or activation.

Scaleway API keys are checked to ensure none is bound to the account root user. The account root user is the original Scaleway account owner; its credentials bypass IAM policies and grant unrestricted access to the entire organization.

GCP project has Cloud Audit Logs configured to capture administrative operations and data access events for services and principals (per IAM Audit Logs, including ADMIN_READ, DATA_READ, DATA_WRITE).

AWS IAM root user activity is assessed by inspecting last-used timestamps for the root password and access keys. The finding indicates when the root identity has been used recently for console or programmatic access.

IAM AWS-managed policies attached to identities are inspected for statements that allow Action:'*' on Resource:'*'-i.e., full administrative *:* permissions

IAM SAML providers enable federated role assumption via STS AssumeRoleWithSAML.

This evaluates whether such providers exist in the account.

Project service usage includes the Cloud Asset Inventory API (cloudasset.googleapis.com), enabling resource and IAM policy inventory with time-series metadata and change history.

Attached customer-managed IAM policies are evaluated for statements granting full admin access via Action: "*", Resource: "*", i.e., *:*. Only policies you created and attached to identities are considered.

Customer-managed IAM policies that are unattached are evaluated for statements granting full administrative access using *:* wildcards.

The focus is on policies whose documents include unrestricted actions on all resources.

Azure custom RBAC roles include the Microsoft.Authorization/locks/* action, indicating permission to administer management locks at subscription, resource group, or resource scope.