knarayan/cloud_posture_checks huggingface dataset:
Azure MySQL database flexible server using insecure TLS version
This policy identifies Azure MySQL database flexible servers which are using insecure TLS version. Enforcing TLS connections between database server and client applications helps protect against 'man in the middle' attacks by encrypting the data stream between the server and application. As a security best practice, it is recommended to use the latest TLS version for Azure MySQL database flexible server.
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: 1. Log in to the Azure portal
2. Go to Azure Database for MySQL flexible servers dashboard
3. Click on the reported MySQL flexible server
4. Click on 'Server parameters' under 'Settings'
5. In the search box, type in 'require_secure_transport' and make sure VALUE is set to 'ON' if it is not already set.
6. In the search box, type in 'tls_version' and Set VALUE to TLSV1.2 or above for tls_version..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-mysql-flexible-server' AND json.rule = properties.state equal ignore case "Ready" and require_secure_transport.value equal ignore case "ON" and (tls_version.value does not equal ignore case "TLSV1.2" and tls_version.value does not equal ignore case "TLSV1.3" and tls_version.value does not equal ignore case "TLSV1.2,TLSV1.3" and tls_version.value does not equal ignore case "TLSV1.3,TLSV1.2")```
Azure PostgreSQL database flexible server configured with overly permissive network access
This policy identifies Azure PostgreSQL database flexible servers that are configured with overly permissive network access. It is highly recommended to create PostgreSQL database flexible server with private access to help secure access to server via VNet Integration or with a Firewall rule, you can restrict it further to only a set of IPv4 addresses or IPv4 address ranges.
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: If PostgreSQL database flexible server was intended to accesed by authorized public IPs. Restrict IP addresses to known list and make sure IP range '+ Add 0.0.0.0 - 255.255.255.255' is not in Firewall rules. 
To add or to remove IPs refer below URL:
https://docs.microsoft.com/en-gb/azure/postgresql/flexible-server/how-to-manage-firewall-portal#manage-existing-firewall-rules-through-the-azure-portal

To create new PostgreSQL database flexible server with Private access (VNet Integration), refer below URL:
https://docs.microsoft.com/en-gb/azure/postgresql/flexible-server/quickstart-create-server-portal

Note: Once PostgreSQL database flexible server is created; You can't change the connectivity method after. For example, if you select Public access (allowed IP addresses) when you create the server, you can't change to Private access (VNet Integration) after the server is created..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-postgresql-flexible-server' AND json.rule = properties.state equal ignore case Ready and properties.network.publicNetworkAccess equal ignore case Enabled and firewallRules[?any(properties.startIpAddress equals 0.0.0.0 and properties.endIpAddress equals 255.255.255.255)] exists```
Azure Network Security Group allows all traffic on ports which are not commonly used
This policy identifies Azure Network Security Group which allow all traffic on ports which are not commonly used. Ports excluded from this policy are 20, 21, 22, 23, 25, 53, 80, 135, 137, 138, 443, 445, 1433, 1434, 3306, 3389, 4333, 5432, 5500 and 5900. As a best practice, restrict ports 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 Udp or protocol equals Icmp or protocol equals *) and ((destinationPortRange exists and destinationPortRange is not member of (20, 21, 22, 23, 25, 53, 80, 135, 137, 138, 443, 445, 1433, 1434, 3306, 3389, 4333, 5432, 5500, 5900, *)) or (destinationPortRanges is not empty and destinationPortRanges[*] is not member of (20, 21, 22, 23, 25, 53, 80, 135, 137, 138, 443, 445, 1433, 1434, 3306, 3389, 4333, 5432, 5500, 5900, *))) )] exists```
AWS EKS cluster does not have secrets encryption enabled
This policy identifies AWS EKS clusters that do not have secrets encryption enabled.

AWS EKS cluster secrets are, by default, stored unencrypted in the API server's underlying data store (etcd). Anyone with direct access to etcd or with API access can retrieve or modify the secrets. Using secrets encryption for your Amazon EKS cluster allows you to protect sensitive information such as passwords and API keys using Kubernetes-native APIs.

It is recommended to enable secrets encryption to ensure its security and reduce the risk of unauthorized access or data breaches.
This is applicable to aws 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: To enable secrets encryption on existing Azure EKS clusters, follow the below URL:
https://docs.aws.amazon.com/eks/latest/userguide/enable-kms.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-eks-describe-cluster' AND json.rule = encryptionConfig does not exist or (encryptionConfig exists and encryptionConfig[*].provider.keyArn does not exist and encryptionConfig[*].resources[*] does not contain secrets)```
GCP Kubernetes Engine Clusters have Cloud Monitoring disabled
This policy identifies Kubernetes Engine Clusters which have disabled Cloud monitoring. Enabling Cloud monitoring will let the Kubernetes Engine to monitor signals and build operations in the clusters.
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. Login to GCP Portal
2. Go to 'Kubernetes Engine' (Left Panel)
3. Select 'Clusters'
4. From the list of clusters, click on the reported cluster
5. Under 'Features', click on the edit button (pencil icon) in front of 'Cloud Monitoring'
6. In the 'Edit Cloud Monitoring' dialog, enable the 'Enable Cloud Monitoring' checkbox
7. Click on 'Save Changes'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = 'monitoringService does not exist or monitoringService equals none'```
Chaitu EC2 instance policy

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: N/A.

Query:
```config from cloud.resource where api.name = 'aws-ec2-describe-instances' AND json.rule = instanceId contains "[RantiAWS" ```
GCP VM instance configured with default service account
This policy identifies GCP VM instances configured with the default service account. To defend against privilege escalations if your VM is compromised and prevent an attacker from gaining access to all of your project, it is recommended to not use the default Compute Engine service account because it has the Editor role on the project.
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: Log in to GCP Console
2. Navigate to 'Compute Engine' and click on 'VM instances'
3. Search for the alerted instance and click on the instance name
4. To make a change first we have to stop the instance; click on 'STOP' from the top menu
5. Click on 'EDIT' and Go to section 'Service account' 
6. From the dropdown select a non-default service account 
7. Click on 'Save'
8. Click on 'START/RESUME' from the top menu.

Query:
```config from cloud.resource where api.name = 'gcloud-projects-get-iam-user' AND json.rule = user contains "compute@developer.gserviceaccount.com" and roles[*] contains "roles/editor" as X; config from cloud.resource where api.name = 'gcloud-compute-instances-list' AND json.rule = (status equals RUNNING and name does not start with "gke-") and serviceAccounts[?any( email contains "compute@developer.gserviceaccount.com")] exists as Y; filter '$.Y.serviceAccounts[*].email contains $.X.user'; show Y;```
Alibaba Cloud data disk is configured with release disk with instance feature
This policy identifies data disks which are configured with release disk with instance feature. As a best practice, disable release disk with instance feature to prevent irreversible data loss from accidental or malicious operations.
Note: This attribute applies to data disks only. However, it can only restrict the manual release operation, not the release operation by Alibaba Cloud.
This is applicable to alibaba_cloud 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 Alibaba Cloud Portal
2. Go to Elastic Compute Service
3. In the left-side navigation pane, click on 'Disks' which is under 'Storage & Snapshots'
4. Select the reported data disk
5. Select More and click on Modify Disk Property
6. On Modify Disk Property popup window, Uncheck 'Release Disk with Instance' checkbox
7. Click on 'OK'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ecs-disk' AND json.rule = 'type equals data and deleteWithInstance is true'```
Info of AWS S3 bucket publicly readable
This policy identifies the S3 buckets that are publicly readable by Get/Read/List bucket operations. These permissions permit anyone, malicious or not, to Get/Read/List bucket operations on your S3 bucket if they can guess the namespace. S3 service does not protect the namespace if ACLs and Bucket policy is not handled properly, with this configuration you may be at risk of compromise of critical data by leaving S3 public.

For more details:
https://docs.aws.amazon.com/AmazonS3/latest/user-guide/set-permissions.html
https://docs.aws.amazon.com/AmazonS3/latest/dev/about-object-ownership.html#ensure-object-ownership 
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. Log in to the AWS Console
2. Navigate to the 'S3' service
3. Click on the S3 resource reported in the alert
4. Click on the 'Permissions' tab
5. If Access Control List is set to 'Public' follow the below steps
a. Under 'Access Control List', Click on 'Everyone' and uncheck all items
b. Click on Save changes
6. If 'Bucket Policy' is set to public follow the below steps
a. Under 'Bucket Policy', Select 'Edit Bucket Policy' and consider defining what explicit 'Principal' should have the ability to GET/LIST objects in your S3 bucket. You may also want to specifically limit the 'Principal' ability to perform specific GET/LIST functions, without the wild card.
If 'Bucket Policy' is not required delete the existing 'Bucket Policy'.
b. Click on Save changes

Note: Make sure updating 'Access Control List' or 'Bucket Policy' does not affect S3 bucket data access..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = ((((publicAccessBlockConfiguration.ignorePublicAcls is false and accountLevelPublicAccessBlockConfiguration does not exist) or (publicAccessBlockConfiguration does not exist and accountLevelPublicAccessBlockConfiguration.ignorePublicAcls is false) or (publicAccessBlockConfiguration.ignorePublicAcls is false and accountLevelPublicAccessBlockConfiguration.ignorePublicAcls is false)) and acl.grantsAsList[?any(grantee equals AllUsers and permission is member of (ReadAcp,Read,FullControl))] exists) or ((policyStatus.isPublic is true and ((publicAccessBlockConfiguration.restrictPublicBuckets is false and accountLevelPublicAccessBlockConfiguration does not exist) or (publicAccessBlockConfiguration does not exist and accountLevelPublicAccessBlockConfiguration.restrictPublicBuckets is false) or (publicAccessBlockConfiguration.restrictPublicBuckets is false and accountLevelPublicAccessBlockConfiguration.restrictPublicBuckets is false))) and (policy.Statement[?any(Effect equals Allow and (Principal equals * or Principal.AWS equals *) and (Action contains s3:* or Action contains s3:Get or Action contains s3:List) and (Condition does not exist))] exists))) and websiteConfiguration does not exist```
Azure Container Registry not encrypted with Customer Managed Key (CMK)
This policy identifies Azure Container Registries that are not encrypted with Customer-Managed Keys (CMK).

By default, Azure Container Registry encrypts data at rest with Microsoft-managed keys. However, for enhanced control, regulatory compliance, and improved security, customer-managed keys enable organizations to encrypt Azure Container Registry data using Azure Key Vault keys that they create, own, and manage. Using CMK ensures that the encryption process aligns with organizational policies, allowing complete control over key lifecycle management, including rotation, access management, and retirement.

As a security best practice, it is recommended to encrypt Azure Container Registries with Customer-Managed Keys (CMK).
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: Note: CMK can only be enabled during the creation of a new Container Registry. Ensure the registry is on the Premium service tier, as CMK is only supported at this level.

1. Create a new Container Registry
2. Navigate to the Encryption tab during the creation process
3. Select the option to enable Customer-Managed Key
4. Fill in all other required details to complete the registry setup.

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-container-registry' AND json.rule = properties.provisioningState equal ignore case Succeeded and properties.encryption.status equal ignore case disabled```
API automation policy akceq

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

Query:
```config from cloud.resource where api.name = "aws-ec2-describe-instances" AND json.rule = architecture contains "foo"```
GCP GCR Container Vulnerability Scanning is disabled
This policy identifies GCP accounts where GCR Container Vulnerability Scanning is not enabled. GCR Container Analysis and other third party products allow images stored in GCR to be scanned for known vulnerabilities. Vulnerabilities in software packages can be exploited by hackers or malicious users to obtain unauthorized access to local cloud resources. It is recommended to enable vulnerability scanning for images stored in Google Container Registry. 
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. Login to the GCP console
2. For the reported account, navigate to the GCP service 'Container Registry'(Left Panel)
3. Select the tab 'Settings'
4. To enable the vulnerability scanning, click on the 'TURN ON' button..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-services-list' AND json.rule = services[?any(name contains containerscanning.googleapis.com and state contains ENABLED)] does not exist```
IBM Cloud Secrets Manager user credentials with rotation policy more than 90 days
This policy identifies IBM Cloud Secrets Manager user credentials with a rotation policy of more than 90 days.

IBM Cloud Secrets Manager allows you to securely store and manage user credentials (username and password) for accessing external services or applications. It provides a centralised way to store secrets, control their lifecycle, set expiration dates, and implement rotation policies. User credentials should be rotated to ensure that data cannot be accessed with an old password, which might have been lost, cracked, or stolen.

It is recommended to establish a rotation policy for user credentials, ensuring that they are regularly rotated within a period of less than 90 days.
This is applicable to ibm 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 set a rotation policy for user credentials, follow the below steps:

1. Log in to the IBM Cloud Console
2. Click on the menu icon and navigate to 'Resource list'. From the list of resources, select the secret manager instance in which the reported secret resides under the security section.
3. Select the secret.
4. Under the 'Rotation' tab, enable 'Automatic secret rotation'.
5. Set 'Rotation Interval' to less than 90 days.
6. Set 'General password settings' according to the requirements.
6. Click on 'Update'..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-secret-manager-secret' AND json.rule = state_description equal ignore case active and secret_type equal ignore case username_password and ( rotation.auto_rotate is false or (rotation.unit equal ignore case month and rotation.interval > 3) or (rotation.unit equal ignore case day and rotation.interval > 90))```
AWS IAM password policy does not expire in 90 days
This policy identifies the IAM policies which does not have password expiration set to 90 days. AWS IAM (Identity & Access Management) allows customers to secure AWS console access. As a security best practice, customers must have strong password policies in place.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['WEAK_PASSWORD'].
Mitigation of this issue can be done as follows: 1. Login to the AWS console and navigate to the 'IAM' service.
2. On the left navigation panel, Click on 'Account Settings'
3. check 'Enable password expiration' and enter a password expiration period.
4. Click on 'Apply password policy'.

Query:
```config from cloud.resource where api.name='aws-iam-get-account-password-policy' AND json.rule='isDefaultPolicy is true or maxPasswordAge !isType Integer or $.maxPasswordAge > 90 or maxPasswordAge equals 0'```
Azure Storage Account storing Machine Learning workspace high business impact data is publicly accessible
This policy identifies Azure Storage Accounts storing Machine Learning workspace high business impact data that are publicly accessible. Azure Storage account stores machine learning artifacts such as job logs. By default, this storage account is used when you upload data to the workspace. The attacker could exploit publicly accessible storage account to get machine learning workspace high business impact data logs and could breach in to the system by leveraging data exposed. It is recommended to restrict storage account access to only to the machine learning services as per business requirement.
This is applicable to azure cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To restirct Storage account access, refer the below URL:
https://learn.microsoft.com/en-gb/azure/storage/blobs/anonymous-read-access-configure?tabs=portal.

Query:
```config from cloud.resource where api.name = 'azure-machine-learning-workspace' AND json.rule = 'properties.provisioningState equal ignore case Succeeded and properties.hbiWorkspace is true and properties.storageAccount exists' as X; config from cloud.resource where api.name = 'azure-storage-account-list' AND json.rule = 'totalPublicContainers > 0 and (properties.allowBlobPublicAccess is true or properties.allowBlobPublicAccess does not exist) and properties.publicNetworkAccess equal ignore case Enabled and networkRuleSet.virtualNetworkRules is empty and (properties.privateEndpointConnections is empty or properties.privateEndpointConnections does not exist)' as Y; filter '$.X.properties.storageAccount contains $.Y.id'; show Y;```
AWS IAM Groups with administrator access permissions
This policy identifies AWS IAM groups which has administrator access permission set. This would allow all users under this group to have administrative privileges. As a security best practice, it is recommended to grant least privilege access like granting only the permissions required to perform a task, instead of providing excessive permissions.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['HIGH_PRIVILEGED_ROLE'].
Mitigation of this issue can be done as follows: 1. Log in to AWS console
2. Navigate to IAM service
3. Click on Groups
4. Click on reported IAM group
5. Under 'Managed Policies' click on 'Detach Policy' which is having excessive permissions and assign a limited permission policy as required for a particular group
OR
6. Under 'Inline Policies' click on 'Edit Policy' or 'Remove Policy' and assign a limited permission as required for a particular group.

Query:
```config from cloud.resource where api.name = 'aws-iam-list-groups' as X; config from cloud.resource where api.name = 'aws-iam-get-policy-version' AND json.rule = document.Statement[?any(Effect equals Allow and Action equals * and Resource equals * )] exists as Y; filter "($.X.inlinePolicies[*].policyDocument.Statement[?(@.Effect=='Allow' && @.Resource=='*')].Action any equal * ) or ($.X.attachedPolicies[*].policyArn intersects $.Y.policyArn)"; show X;```