knarayan/cloud_posture_checks huggingface dataset:
GCP Cloud Run service is using default service account with editor role
This policy identifies GCP Cloud Run services that are utilizing the default service account with the editor role.

When you create a new Cloud Run service, the compute engine default service account is associated with the service by default if any other service account is not configured. The compute engine default service account is automatically created when the Compute Engine API is enabled and is granted the IAM basic Editor role if you have not disabled this behavior explicitly. These permissions can be exploited to get admin access to the GCP project.

To be compliant with the principle of least privileges and prevent potential privilege escalation, it is recommended that Cloud Run services are not assigned the 'Compute Engine default service account' especially when the editor role is granted to the service account.
This is applicable to gcp 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: It is not possible to change service account of an existing revision of cloud run service. To update the service account used, a new revision can be deployed.

To deploy a new service with a user-managed service account, please refer to the URLs given below:
https://cloud.google.com/run/docs/securing/service-identity#deploying_a_new_service_with_a_user-managed_service_account.

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-cloud-run-services-list' AND json.rule = spec.template.spec.serviceAccountName contains "compute@developer.gserviceaccount.com" as Y; filter ' $.X.user equals $.Y.spec.template.spec.serviceAccountName '; show Y; ```
GCP VM instance with Shielded VM Secure Boot disabled
This policy identifies GCP VM instances that have Shielded VM Secure Boot disabled.

Secure Boot is a security feature that ensures only trusted, digitally signed software runs during the boot process of a computer. Enabling it helps protect against malware and unauthorized software by verifying the integrity of the bootloader and operating system. Without Secure Boot, systems are vulnerable to rootkits, bootkits, and other malicious code that can compromise the system from the start, making it difficult to detect and remove such threats.

It is recommended to enable Shielded VM secure boot for GCP VM instances.
This is applicable to gcp 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 GCP console
2. Navigate to 'Compute Engine' and then 'VM instances'
3. Click on the reported VM name
4. Stop the VM by clicking on the 'STOP' button. Click the 'STOP' button on the confirmation dialogue
5. Once the the VM has been stopped, click on the 'EDIT' button
6. Under 'Shielded VM', enable 'Turn on Secure Boot'
7. Click on 'Save'
8. Click on 'START/RESUME' from the top menu..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-instances-list' AND json.rule = status equals RUNNING and name does not start with "gke-" and (shieldedInstanceConfig does not exist or shieldedInstanceConfig.enableSecureBoot is false )```
GCP Kubernetes cluster Shielded GKE Nodes feature disabled
This policy identifies GCP Kubernetes clusters for which the Shielded GKE Nodes feature is not enabled. Shielded GKE nodes protect clusters against boot- or kernel-level malware or rootkits
which persist beyond infected OS. It is recommended to enable Shielded GKE Nodes for all the Kubernetes clusters.

FMI: https://cloud.google.com/kubernetes-engine/docs/how-to/shielded-gke-nodes
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 Google cloud console
2. Navigate to Google Kubernetes Engine, click on 'Clusters' to get the list
3. Browse the alerted cluster
4. Click on the 'Edit' button on top
5. From the drop-down for 'Shielded GKE Nodes' select 'Enable'
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = shieldedNodes.enabled does not exist or shieldedNodes.enabled equals "false"```
Azure SQL Server ADS Vulnerability Assessment 'Also send email notifications to admins and subscription owners' is disabled
This policy identifies Azure SQL Server which has ADS Vulnerability Assessment 'Also send email notifications to admins and subscription owners' disabled. This setting enables ADS - VA scan reports being sent to admins and subscription owners. It is recommended to enable 'Also send email notifications to admins and subscription owners' setting, which would help in reducing time required for identifying risks and taking corrective measures.
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. Select 'SQL servers', and select the SQL server you need to modify
3. Click on 'Microsoft Defender for Cloud' under 'Security'
4. Click on '(Configure)' next to 'Microsoft Defender for SQL: Enabled at the server-level'
5. In 'VULNERABILITY ASSESSMENT SETTINGS' section, Ensure 'Also send email notifications to admins and subscription owners' is checked
6. 'Save' your changes.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-sql-server-list' AND json.rule = vulnerabilityAssessments[*].properties.storageContainerPath exists and vulnerabilityAssessments[*].properties.recurringScans.emailSubscriptionAdmins is false```
RomanPolicy

This is applicable to azure cloud and is considered a informational 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 cloud.type = 'azure' AND cloud.accountgroup NOT IN ( 'PCF Azure') AND api.name = 'azure-vm-list' AND json.rule = ['properties.storageProfile'].['osDisk'].['vhd'].['uri'] exists```
GCP VM instance using a default service account with Cloud Platform access scope
This policy identifies the GCP VM instances that are using a default service account with cloud-platform access scope. To compliant with the principle of least privileges and prevent potential privilege escalation it is recommended that instances are not assigned to default service account 'Compute Engine default service account' with scope 'cloud-platform'.
This is applicable to gcp 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 GCP portal
2. Go to Compute Engine
3. Choose VM instances
4. Click on the reported VM instance for which you want to change the service account
5. If the instance is not stopped, click the 'Stop' button. Wait for the instance to be stopped
6. Next, click the 'Edit' button
7. Scroll down to the 'Service Account' section, From the drop-down menu, select the desired service account.
8. Ensure 'Allow full access to all Cloud APIs' is not selected or 'Cloud Platform' under 'Set access for each API' is not enabled
9. Click the 'Save' button and then click 'START' to start the VM instance..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-instances-list' AND json.rule = (status equals RUNNING and name does not start with "gke-") and serviceAccounts[*].email contains "-compute@developer.gserviceaccount.com" and serviceAccounts[*].scopes[*] any equal "https://www.googleapis.com/auth/cloud-platform"```
Azure Machine Learning compute instance not configured inside virtual network
This policy identifies Azure Machine Learning compute instances that are not configured within a virtual network.

Azure Machine Learning compute instances outside a Virtual Network are exposed to external threats, as they may be publicly accessible. Placing the instance within a Virtual Network improves security by limiting access to trusted virtual machines and services within the same network. This ensures secure communication and blocks unauthorized public access.

As a security best practice, it is recommended to deploy the Azure Machine Learning compute instances inside a virtual network.
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: Note: Configuring an existing Azure Machine Learning compute instance inside a Virtual Network without deleting and recreating it is not supported. To ensure security, it is recommended to set up the compute instance within a Virtual Network from the start.

To create a new compute instance inside a Virtual Network:
1. Log in to Azure Portal and search for 'Azure Machine Learning'
2. Select 'Azure Machine Learning'
3. Select the Azure Machine Learning Workspace that the reported compute instance is associated with
4. On the 'Overview' page, click the 'Studio web URL' link to log in to Azure ML Studio
5. A new tab will open for Azure ML Studio
6. In the left panel, under 'Manage' section, click on the 'Compute'
7. Click 'New' to create a new compute instance
8. In the 'Security' tab, under the 'Virtual network' section, enable the 'Enable virtual network' to configure it within a Virtual network
9. Select 'Review + Create' to create the compute instance.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-machine-learning-compute' AND json.rule = properties.provisioningState equal ignore case Succeeded and properties.properties.subnet.id does not exist```
AWS CloudFront not configured with AWS Web Application Firewall v2 (AWS WAFv2)
This policy identifies AWS CloudFront which is not configured with AWS Web Application Firewall v2 (AWS WAFv2). As a best practice, configure the AWS WAFv2 service on the CloudFront to protect against application-layer attacks. To block malicious requests to your CloudFront, define the block criteria in the WAFv2 web access control list (web ACL).
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: 1. Sign in to the AWS console
2. Go to the CloudFront Distributions Dashboard
3. Click on the reported web distribution
4. On 'General' tab, Click on 'Edit' button under 'Settings'
5. On 'Edit Distribution' page, from 'AWS WAF Web ACL' dropdown select WAFv2 ACL which you want to apply
Note: In case no WAFv2 ACL found from 'AWS WAF Web ACL' dropdown list, Please follow below URL to create WAFv2 ACL:
https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-creating.html
6. Click on 'Save changes'.

Query:
```config from cloud.resource where api.name = 'aws-waf-classic-global-web-acl-resource' as X; config from cloud.resource where api.name = 'aws-cloudfront-list-distributions' AND json.rule = webACLId is not empty as Y; filter '$.X.webACL.webACLId equals $.Y.webACLId'; show Y;```
AWS S3 bucket encrypted with Customer Managed Key (CMK) is not enabled for regular rotation
This policy identifies Amazon S3 buckets that use Customer Managed Keys (CMKs) for encryption but are not enabled with key rotation. Amazon S3 bucket encryption key rotation failure can result in prolonged exposure of sensitive data and potential compliance violations. As a security best practice, it is important to rotate these keys periodically. This ensures that if the keys are compromised, the data in the underlying service remains secure with the new keys.
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: Recommendation:

The following steps are recommended to enable the automatic rotation of the KMS key used by the S3 bucket

1. Log in to the AWS Console and navigate to the 'S3' service.
2. Click on the S3 bucket reported in the alert.
3. Click on the 'Properties' tab.
4. Under the 'Default encryption' section, click on the KMS key link in 'Encryption key ARN'.
5. Under the 'Key rotation' tab on the navigated KMS key window, Enable 'Automatically rotate this CMK every year'.
6. Click on Save..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name= 'aws-s3api-get-bucket-acl' AND json.rule = (sseAlgorithm contains "aws:kms" or sseAlgorithm contains "aws:kms:dsse") and kmsMasterKeyID exists as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' AND json.rule = keyMetadata.keyState equals Enabled and keyMetadata.keyManager equal ignore case CUSTOMER and keyMetadata.origin equals AWS_KMS and (rotation_status.keyRotationEnabled is false or rotation_status.keyRotationEnabled equals "null")as Y; filter '$.X.kmsMasterKeyID contains $.Y.key.keyArn'; show X;```
Azure Network Security Group allows all traffic on MSQL (TCP Port 4333)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on MSQL (TCP Port 4333). Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict MSQL 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(4333,4333) or destinationPortRanges[*] contains _Port.inRange(4333,4333) ))] exists```
Azure Network Security Group allows all traffic on VNC Server (TCP Port 5900)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on VNC Server (TCP Port 5900). Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict VNC Server 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(5900,5900) or destinationPortRanges[*] contains _Port.inRange(5900,5900) ))] exists```
GCP PostgreSQL instance database flag log_statement_stats is not set to off
This policy identifies PostgreSQL database instances in which database flag log_statement_stats is not set to off. The log_statement_stats flag enables a crude profiling method for logging end-to-end performance statistics of a SQL query. This can be useful for troubleshooting but may increase the number of logs significantly and have performance overhead. It is recommended to set log_statement_stats as off.

Note:  The flag 'log_statement_stats' cannot be enabled with other
module statistics (log_parser_stats, log_planner_stats, log_executor_stats).
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 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 'Flags' section, choose the flag 'log_statement_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_statement_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_statement_stats or settings.databaseFlags[?any(name contains log_statement_stats and value contains on)] exists)"```
Azure Activity log alert for Create or update public IP address rule does not exist
This policy identifies the Azure accounts in which activity log alert for Create or update public IP address rule does not exist.

Creating an activity log alert for create or update public IP address rule gives insight into network rule access changes and may reduce the time it takes to detect suspicious activity. By enabling this monitoring, you get alerts whenever any changes are made to public IP address rules.

As a best practice, it is recommended to have a activity log alert for create or update public IP address rule to enhance network security monitoring and detect suspicious activities.
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 Public Ip Address (Public Ip Address)' 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.Network/publicIPAddresses/write" as X; count(X) less than 1```
Enforce EBS Volume Encryption in EC2 Auto Scaling Configurations
This policy helps ensure that your AWS EC2 Auto Scaling Launch Configurations are using encrypted EBS volumes, which is a crucial security measure to protect sensitive data. By checking for the presence of the Encrypted field and verifying that it is set to false, the policy alerts you to any instances where encryption is not enabled, allowing you to take corrective action and maintain a secure cloud environment. Adhering to this policy helps you comply with best practices and regulatory requirements for data protection in your public cloud deployment.
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: N/A.

Query:
```config from cloud.resource where api.name = 'aws-ec2-autoscaling-launch-configuration' and json.rule = blockDeviceMappings[*].ebs.encrypted exists and blockDeviceMappings[*].ebs.encrypted is false```
Azure AKS cluster HTTP application routing enabled
HTTP application routing configures an Ingress controller in your AKS cluster. As applications are deployed, the solution also creates publicly accessible DNS names for application endpoints. While this makes it easy to access applications that are deployed to your Azure AKS cluster, this add-on is not recommended for production use.

This policy checks your AKS cluster HTTP application routing add-on setting and alerts if enabled.
This is applicable to azure 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 disable HTTP application routing for your AKS cluster, follow the below URL:
https://learn.microsoft.com/en-us/azure/aks/http-application-routing#remove-http-routing.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-kubernetes-cluster' AND json.rule =  properties.addonProfiles.httpapplicationrouting.enabled is true or properties.addonProfiles.httpApplicationRouting.enabled is true```
Azure Microsoft Entra ID account lockout threshold greater than 10
This policy identifies if the account lockout threshold for Microsoft Entra ID (formerly Azure AD) accounts is configured to allow more than 10 failed login attempts before the account is locked out.

A high lockout threshold (greater than 10) increases the risk of brute-force or password spray attacks, where attackers can attempt multiple passwords over time without triggering account lockouts, leaving accounts vulnerable to unauthorized access. Setting the lockout threshold to a reasonable value (e.g., less than or equal to 10) balances usability and security by limiting the number of login attempts before an account is locked, reducing exposure to attacks while preventing frequent unnecessary lockouts for legitimate users.

As a security best practice, it is recommended to configure the account lockout threshold to less than or equal to 10.
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: 1. Log in to Azure Portal and search for 'Microsoft Entra ID'
2. Select 'Microsoft Entra ID'
3. Under Manage, select Security
4. Under Manage, select Authentication methods
5. Under Manage, select Password protection
6. Set the 'Lockout threshold' to 10 or fewer
7. Click 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-active-directory-group-settings' and json.rule = values[?any( name equals LockoutThreshold and (value greater than 10 or value does not exist))] exists```