knarayan/cloud_posture_checks huggingface dataset:
Copy of AWS IAM Password policy is unsecure
Checks to ensure that IAM password policy is in place for the cloud accounts. As a security best practice, customers must have strong password policies in place. This policy ensures password policies are set with all following options:
- Minimum Password Length
- At least one Uppercase letter
- At least one Lowercase letter
- At least one Number
- At least one Symbol/non-alphanumeric character
- Users have permission to change their own password
- Password expiration period
- Password reuse
- Password expiration requires administrator reset
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. Login to AWS Console and navigate to the 'IAM' Service
2. Click on 'Account Settings'
3. Under 'Password Policy', select and set all the options
4. Click on 'Apply password policy'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-account-password-policy' AND json.rule =  'requireNumbers contains false and requireSymbols contains false and expirePasswords contains false and allowUsersToChangePassword contains false and requireLowercaseCharacters contains false and requireUppercaseCharacters contains false and maxPasswordAge does not exist and passwordReusePrevention does not exist and minimumPasswordLength==6'```
GCP Kubernetes Engine Clusters using the default network
This policy identifies Google Kubernetes Engine (GKE) clusters that are configured to use the default network. Because GKE uses this network when creating routes and firewalls for the cluster, as a best practice define a network configuration that meets your security and networking requirements for ingress and egress traffic, instead of using the default network.
This is applicable to gcp cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: You cannot change the network attached to an existing GKE cluster. To resolve this alert, create a new cluster with a custom network that meets your requirements, then migrate the cluster data from the reported cluster to this newly created GKE cluster and delete the reported GKE cluster.

To create new Kubernetes engine cluster with the custom network, perform the following:
1. Login to GCP Portal
2. Go to Kubernetes Engine (Left Panel)
3. Select Kubernetes clusters 
4. Click on CREATE CLUSTER button
5. Set new cluster parameters as per your requirement and make sure 'Network' is set to other than 'default' under Networking section.
6. Click on Save

To delete reported Kubernetes engine cluster, perform the following:
1. Login to GCP Portal
2. Go to Kubernetes Engine (Left Panel)
3. Select Kubernetes clusters 
4. Click on reported Kubernetes cluster
5. Click on the DELETE button
6. On 'Delete a cluster' popup dialog, Click on DELETE to confirm the deletion of the cluster..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = 'network equals default'```
Azure SQL Database server not configured with private endpoint
This policy identifies Azure SQL database servers that are not configured with private endpoint. Private endpoint connections enforce secure communication by enabling private connectivity to Azure Database for SQL. Configuring a private endpoint enables access to traffic coming from only known networks and prevents access from malicious or unknown IP addresses which includes IP addresses within Azure. It is recommended to create private endpoint for secure communication for your Azure SQL database.
This is applicable to azure cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Login to Azure Portal 
2. Navigate to 'SQL Servers' and select the reported server
3. Open the Private endpoint settings
4. Click on Add Private endpoint to create and add a private endpoint

Refer to below link for step by step process:
https://learn.microsoft.com/en-us/azure/private-link/tutorial-private-endpoint-sql-portal.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-sql-server-list' AND json.rule = ['sqlServer'].['properties.state'] equal ignore case Ready and ['sqlServer'].['properties.privateEndpointConnections'] is empty```
GCP IAM Users have overly permissive service account privileges
This policy identifies IAM users which have overly permissive service account privileges. Any user should not have Service Account Admin and Service Account User, both roles assigned at a time. Built-in/Predefined IAM role Service Account admin allows the user to create, delete, manage service accounts. Built-in/Predefined IAM role Service Account User allows the user to assign service accounts to Apps/Compute Instances. It is recommended to follow the principle of 'Separation of Duties' ensuring that one individual does not have all the necessary permissions to be able to complete a malicious action or meant to help avoid security or privacy incidents and errors.
This is applicable to gcp cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: 1. Login to GCP Portal
2. Go to IAM & Admin (Left Panel)
3. Select IAM
4. From the list of users, choose the reported IAM user
5. Click on Edit permissions pencil icon
6. For member having 'Service Account admin' and 'Service Account User' roles granted/assigned, Click on the Delete Bin icon to remove the role from a member.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-projects-get-iam-user' AND json.rule = '(roles[*] contains roles/iam.serviceAccountAdmin) and (roles[*] contains roles/iam.serviceAccountUser)'```
Azure Key vault Private endpoint connection is not configured
This policy identifies Key vaults that are not configured with a private endpoint connection. Azure Key vault private endpoints can be configured using Azure Private Link. Private Link allows users to access an Azure Key vault from within the virtual network or from any peered virtual network. When Private Link is combined with restricted NSG policies, it helps reduce the risk of data exfiltration. It is recommended to configure a Private endpoint connection to Key vaults.

For more details: 
https://docs.microsoft.com/en-us/azure/key-vault/general/private-link-service 
This is applicable to azure cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: Refer following URL for configuring Private endpoints on your Key vaults:
https://docs.microsoft.com/en-us/azure/key-vault/general/private-link-service

NOTE: The Key vault associated with private endpoints should not be allowing access from all networks in Firewalls and virtual networks section, make sure the Selected networks are configured with restrictive Virtual networks access. Otherwise the security provided by private endpoints will not be satisfied..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-key-vault-list' AND json.rule = properties.provisioningState equals Succeeded and properties.privateEndpointConnections[*] does not exist```
AWS EKS cluster security group overly permissive to all traffic
This policy identifies EKS cluster Security groups that are overly permissive to all traffic. Doing so, may allow a bad actor to brute force their way into the system and potentially get access to the entire network. Review your list of security group rules to ensure that your resources are not exposed. As a best practice, restrict traffic solely from known static IP addresses. Limit the access list to include known hosts, services, or specific employees only.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: Before making any changes, please check the impact on your applications/services. If the Security Group reported indeed need to restrict all traffic, follow the instructions below:
1. Log in to the AWS console
2. Navigate to the 'VPC' service
3. Select the 'Security Group' reported in the alert
4. Click on 'Inbound Rules'
5. Remove the rule which has the 'Source' value as 0.0.0.0/0 or ::/0.

Query:
```config from cloud.resource where api.name = 'aws-eks-describe-cluster' as X; config from cloud.resource where api.name = 'aws-ec2-describe-security-groups' AND json.rule = isShared is false and (ipPermissions[*].ipv4Ranges[*] contains 0.0.0.0/0 or ipPermissions[*].ipv6Ranges[*] contains ::/0) as Y; filter '$.X.resourcesVpcConfig.securityGroupIds contains $.Y.groupId or $.X.resourcesVpcConfig.clusterSecurityGroupId contains $.Y.groupId'; show Y;```
Azure Network Security Group with overly permissive outbound rule
This policy identifies NSGs with overly permissive outbound rules allowing outgoing traffic from source type any or source with public IP range. A network security group contains a list of security rules that allow or deny inbound or outbound network traffic based on source or destination IP address, port, and protocol. As a best practice, it is recommended to configure NSGs to restrict traffic to known sources on authorized protocols and ports.
This is applicable to azure cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Sign in to the Azure Portal
2. On left Navigation, Click on All services
3. Under NETWORKING, click on Network security groups
4. Choose the reported resource
5. Under SETTINGS, Click on Outbound security rules
6. Identify the row which matches conditions mentioned below:
a) Source: Any, public IPs
b) Destination: Any
c) Action: Allow
7. Select the rule you need to modify, and edit it to allow specific IP addresses OR set the 'Action' to 'Deny' OR 'Delete' the rule based on your requirement..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name= 'azure-network-nsg-list' AND json.rule = securityRules[?any(access equals Allow and direction equals Outbound and (sourceAddressPrefix equals * or sourceAddressPrefix equals 0.0.0.0/0 or sourceAddressPrefix equals ::/0) and (destinationAddressPrefix equals * or destinationAddressPrefix equals Internet))] exists```
Azure Recovery Services vault is not configured with managed identity
This policy identifies Recovery Services vaults that are not configured with managed identity. Managed identity can be used to authenticate to any service that supports Azure AD authentication, without having credentials in your code. Storing credentials in a code increases the threat surface in case of exploitation and also managed identities eliminate the need for developers to manage credentials. So as a security best practice, it is recommended to have the managed identity to your Recovery Services vault.
This is applicable to azure cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to the Azure portal
2. Navigate to Recovery Services vaults dashboard
3. Click on the reported Recovery Services vault
4. Under Setting section, Click on 'Identity'
5. Configure either 'System assigned' or 'User assigned' managed identity based on your requirement.
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-recovery-service-vault' AND json.rule = properties.provisioningState equals Succeeded and (identity does not exist or identity.type equal ignore case "None")```
AWS ECS Cluster instance volume encryption for data at rest is disabled
This policy identifies the ECS Cluster instance volumes for which encryption for data at rest is disabled. Encrypting data at rest reduces unintentional exposure of data and prevents unauthorized users from accessing sensitive data on your AWS ECS clusters. It is recommended to configure encryption for your ECS cluster instance volumes using an encryption key.

NOTE: ECS can be launched using ECS Fargate launch type or EC2 Instance. ECS Fargate launch type pulls images from the Elastic Container Registry, which are transmitted over HTTPS and are automatically encrypted at rest using S3 server-side encryption. So this policy is only applicable to ECS launched using EC2 Instances.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: To enable encryption to your ECS Cluster instance volumes, follow below URL:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html

NOTE: The existing EBS volumes or snapshots cannot be encrypted, but when you copy unencrypted snapshots, or restore unencrypted volumes, the resulting snapshots or volumes are encrypted..

Query:
```config from cloud.resource where api.name = 'aws-ecs-container-instance' AND json.rule = status equals ACTIVE as X; config from cloud.resource where api.name = 'aws-ec2-describe-volumes' AND json.rule = state contains in-use and encrypted is false as Y; filter '$.Y.attachments[*].instanceId contains $.X.ec2InstanceId'; show Y;```
GCP PostgreSQL instance database flag log_executor_stats is not set to off
This policy identifies PostgreSQL database instances in which database flag log_executor_stats is not set to off. The log_executor_stats flag enables a crude profiling method for logging PostgreSQL executor performance statistics. Even though it can be useful for troubleshooting, it may increase the number of logs significantly and have performance overhead. It is recommended to set log_executor_stats off.
This is applicable to gcp cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to the GCP console
2. Navigate SQL Instances page
3. Click on reported PostgreSQL instance
4. Click EDIT
5. If the flag has not been set on the instance, 
Under 'Customize your instance', click on 'ADD FLAG' in the 'Flags' section, choose the flag 'log_executor_stats' from the drop-down menu, and set the value as 'off'
OR
If the flag has been set to other than off, Under 'Customize your instance', In 'Flags' section choose the flag 'log_executor_stats' and set the  value as 'off'
6. Click on 'DONE' and then 'SAVE'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = "state equals RUNNABLE and databaseVersion contains POSTGRES and (settings.databaseFlags[*].name does not contain log_executor_stats or settings.databaseFlags[?any(name contains log_executor_stats and value contains on)] exists)"```
haridemo

This is applicable to aws cloud and is considered a critical severity issue.
Sample categories of findings relevant here are [None].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where api.name = 'aws-ec2-describe-images' AND json.rule = image.blockDeviceMappings[*].deviceName exists```
Azure App Services Remote debugging is enabled
This policy identifies Azure App Services which has Remote debugging enabled. Enabling Remote debugging feature opens up inbound ports on App Services. It is recommended to disabled Azure App Services Remote debugging.
This is applicable to azure cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to the Azure Portal
2. Select 'App Services' from the left pane
3. Select the reported App Services
4. Go to 'Configurations' under 'Settings'
5. Click on 'General settings'
6. Select 'Off' for 'Remote debugging' under 'Debugging section
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = config.remoteDebuggingEnabled is true```
Azure Network Security Group allows all traffic on Windows RPC (TCP Port 135)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on Windows RPC (TCP Port 135). Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict Windows RPC solely to known static IP addresses. Limit the access list to include known hosts, services, or specific employees only.
This is applicable to azure cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: Before making any changes, please check the impact to your applications/services. Evaluate whether you want to edit the rule and limit access to specific users, hosts, and services only, deny access, or delete the rule completely.

1. Log in to the Azure Portal.
2. Select 'All services'.
3. Select 'Network security groups', under NETWORKING.
4. Select the Network security group you need to modify.
5. Select 'Inbound security rules' under Settings.
6. Select the rule you need to modify, and edit it to allow specific IP addresses OR set the 'Action' to 'Deny' OR 'Delete' the rule based on your requirement.
7. 'Save' your changes..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name= 'azure-network-nsg-list' AND json.rule = securityRules[?any(access equals Allow and direction equals Inbound and (sourceAddressPrefix equals Internet or sourceAddressPrefix equals * or sourceAddressPrefix equals 0.0.0.0/0 or sourceAddressPrefix equals ::/0) and (protocol equals Tcp or protocol equals *) and (destinationPortRange contains _Port.inRange(135,135) or destinationPortRanges[*] contains _Port.inRange(135,135) ))] exists```
AWS DMS replication task for the source database have logging not set to the minimum severity level
This policy identifies AWS DMS replication task where logging is either not enabled or set below the minimum severity level, such as LOGGER_SEVERITY_DEFAULT, for SOURCE_CAPTURE and SOURCE_UNLOAD.

Logging is indispensable in DMS replication for various purposes, including monitoring, troubleshooting, auditing, performance analysis, error detection, recovery, and historical reporting. SOURCE_CAPTURE captures ongoing replication or CDC data from the source database, while SOURCE_UNLOAD unloads data during full load. Logging these tasks is crucial for ensuring data integrity, compliance, and accountability during migration.

It is recommended to enable logging for AWS DMS replication tasks and set a minimal logging level of DEFAULT for SOURCE_CAPTURE and SOURCE_UNLOAD to ensure that essential messages are logged, facilitating effective monitoring, troubleshooting, and compliance efforts.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To enable logging for  Source capture and  Source Unload DMS replicatation tasks log components during migration:

1. Log in to the AWS Management Console
2. In the console, select the specific region from the region drop-down in the top right corner, for which the alert is generated
3. Navigate to 'Migration & Transfer' from the 'Services' dropdown and select 'Database Migration Service'
4. In the navigation panel, under 'Migrate data', click on 'Database migration tasks'
5. Select the reported replication task and choose 'Modify' from the 'Actions' dropdown on the right
6. Under the 'Task settings' section, enable 'Turn on CloudWatch logs' under 'Task logs'
7. Set the log component severity for both 'Source capture' and 'Source Unload' components to 'Default' or greater according to your business requirements
8. Click 'Save' to save the changes.

Query:
```config from cloud.resource where api.name = 'aws-dms-replication-task' AND json.rule = ReplicationTaskSettings.Logging.EnableLogging is false or  ReplicationTaskSettings.Logging.LogComponents[?any( Id is member of ("SOURCE_CAPTURE","SOURCE_UNLOAD") and Severity is not member of ("LOGGER_SEVERITY_DEFAULT","LOGGER_SEVERITY_DEBUG","LOGGER_SEVERITY_DETAILED_DEBUG") )] exists```
Azure Activity log alert for Create or update security solution does not exist
This policy identifies the Azure accounts in which activity log alert for Create or update security solution does not exist. Creating an activity log alert for Create or update security solution gives insight into changes to the active security solutions and may reduce the time it takes to detect suspicious activity.
This is applicable to azure cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to Azure Portal
2. Click on Monitor (Left Panel)
3. Select 'Alerts'
4. Click on Create > Alert rule
5. In 'Create an alert rule' page, choose the Scope as your Subscription and under the CONDITION section, choose 'Create or Update Security Solutions (Microsoft.Security/securitySolutions)' and Other fields you can set based on your custom settings.
6. Click on Create.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-activity-log-alerts' AND json.rule = "location equal ignore case Global and properties.enabled equals true and properties.scopes[*] does not contain resourceGroups and properties.condition.allOf[?(@.field=='operationName')].equals equals Microsoft.Security/securitySolutions/write" as X; count(X) less than 1```
AWS CodeBuild project environment variables contain plaintext AWS credentials
This policy identifies the AWS CodeBuild project that contains the environment variables AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY  and Password in plaintext.

AWS CodeBuild environment variables configure build settings, pass contextual information, and manage sensitive data during the build process. Authentication credentials like AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY should never be stored in clear text, as this could lead to unintended data exposure and unauthorized access.

It is recommended that AWS CodeBuild environment variables be securely managed using AWS Secrets Manager or AWS Systems Manager Parameter Store to store sensitive data and remove plaintext credentials.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To remove environment variables from a AWS CodeBuild project,

1. Log in to the AWS Management Console.
2. In the console, select the specific region from the region drop-down in the top right corner, for which the alert is generated.
3. Navigate to 'Developer Tools' from the 'Services' dropdown and select the 'CodeBuild'.
4. In the navigation pane, choose 'Build projects'.
5. Select the reported Build project and choose Edit, then click 'Environment' and Expand 'Additional configuration'.
6. Choose 'Remove' next to the environment variables that contain plaintext credentials.
7. When you have finished changing your CodeBuild environment configuration, click ‘Update environment’.

You can store environment variables with sensitive values in the AWS Systems Manager Parameter Store or AWS Secrets Manager and then retrieve them from your build spec according to your business requirements..

Query:
```config from cloud.resource where api.name = 'aws-code-build-project' AND json.rule = environment.environmentVariables[*].name exists and environment.environmentVariables[?any( (name contains "AWS_ACCESS_KEY_ID" or name contains "AWS_SECRET_ACCESS_KEY" or name contains "PASSWORD" ) and type equals "PLAINTEXT")] exists```