knarayan/cloud_posture_checks huggingface dataset:
Azure Network Security Group allows all traffic on CIFS (UDP Port 445)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on Windows SMB UDP port 445. Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict DNS 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 Udp or protocol equals *) and (destinationPortRange contains _Port.inRange(445,445) or destinationPortRanges[*] contains _Port.inRange(445,445) ))] exists```
Azure Machine Learning workspace not encrypted with Customer Managed Key (CMK)
This policy identifies Azure Machine Learning workspaces that are not encrypted with a Customer Managed Key (CMK).

Azure handles encryption using platform-managed keys by default, but customer-managed keys (CMKs) provide greater control and help meet specific security and compliance requirements. Without CMKs, organizations may not have full control over key management and rotation, increasing the risk of compliance issues and unauthorized data access. Configuring the workspace to use CMKs enhances security by allowing organizations to manage key access and rotation, ensuring stronger protection and compliance for sensitive data.

As a security best practice, it is recommended to configure the workspace to use Customer Managed Keys (CMKs).
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: Once a Azure Machine Learning workspace is deployed, you can't switch from Microsoft-managed keys to customer-managed keys. You'll need to delete and recreate the workspace with customer-managed keys enabled.

1. Log in to Azure Portal and search for 'Azure Machine Learning'
2. Select 'Azure Machine Learning'
3. Select the reported Azure Machine Learning workspace
4. Delete the workspace and then recreate it, ensuring you enable 'Encrypt data using a customer-managed key' under the 'Encryption' tab.

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-machine-learning-workspace' AND json.rule = properties.provisioningState equal ignore case Succeeded and (properties.encryption.status does not exist or properties.encryption.status equal ignore case disabled)```
AWS VPC Flow Logs not enabled
This policy identifies VPCs which have flow logs disabled. VPC Flow logs capture information about IP traffic going to and from network interfaces in your VPC. Flow logs are used as a security tool to monitor the traffic that is reaching your instances. Without the flow logs turned on, it is not possible to get any visibility into network traffic.
This is applicable to aws cloud and is considered a critical severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Sign into the AWS console
2. In the console, select the specific region from region drop down on the top right corner, for which the alert is generated
3. Navigate to VPC Dashboard
4. Click on 'Your VPCs' and Choose the reported VPC
5. Click on the 'Flow logs' tab and follow the instructions as in link below to enable Flow Logs for the VPC:
https://aws.amazon.com/blogs/aws/vpc-flow-logs-log-and-view-network-traffic-flows/.

Query:
```config from cloud.resource where api.name = 'aws-ec2-describe-flow-logs' as X; config from cloud.resource where api.name = 'aws-ec2-describe-vpcs' AND json.rule = shared is false as Y; filter 'not($.X.resourceId equals $.Y.vpcId)' ; show Y;```
GCP Storage bucket CMEK not rotated every 90 days
This policy identifies GCP Storage bucket with CMEK that are not rotated every 90 days

A CMEK (Customer-Managed Encryption Key), which is configured for a GCP bucket becomes vulnerable over time due to prolonged use. Without regular rotation, the key is at greater risk of being compromised, which could lead to unauthorized access to the encrypted data in the bucket. This can undermine the security of your data and increase the chances of a breach if the key is exposed or exploited.

It is recommended to configure rotation less than 90 days for CMEKs used for GCP buckets.
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 Cloud Storage Buckets page
3. Click on the reported bucket
4. Go to 'Configuration' tab
5. Under 'Default encryption key', click on the key name
6. Click on 'EDIT ROTATION PERIOD'
7. Select 90 days or less for 'Rotation period' dropdown
8. Click 'SAVE'.

Query:
```config from cloud.resource where api.name = 'gcloud-kms-crypto-keys-list' AND json.rule = primary.state equals "ENABLED" and (rotationPeriod does not exist or rotationPeriod greater than 7776000) as X; config from cloud.resource where api.name = 'gcloud-storage-buckets-list' as Y; filter ' $.X.name equals $.Y.encryption.defaultKmsKeyName'; show Y;```
Azure Microsoft Defender for Cloud is set to Off for App Service
This policy identifies Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) which has defender setting for App Service is set to Off. Enabling Microsoft Defender for Cloud provides the tools needed to harden your resources, track your security posture, protect against cyberattacks, and streamline security management. It is highly recommended to enable Microsoft Defender for App Service.
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. Go to 'Microsoft Defender for Cloud'
3. Select 'Environment Settings'
4. Click on the subscription name
5. Select the 'Defender plans'
6. Select 'Enable all Microsoft Defender for Cloud plans' if not already enabled
7. On the line in the table for 'App Service' Select 'On' under Plan.
8. Select 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = pricings[?any( name equals AppServices and properties.pricingTier does not equal Standard)] exists```
GCP Vertex AI Workbench user-managed notebook is using default service account with the editor role
This policy identifies GCP Vertex AI Workbench user-managed notebooks that are using the default service account with the editor role.

When you create a new Vertex AI Workbench user-managed notebook, the compute engine default service account is associated with the notebook 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 Vertex AI Workbench user-managed notebooks 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: 1. Login to the GCP console
2. Navigate to the 'Vertex AI' service (Left Panel)
3. Under 'Notebooks', go to 'Workbench'
4. Open the 'USER-MANAGED NOTEBOOKS' tab
5. Click on the alerting notebook
6. Under the 'SYSTEM' tab, in front of 'VM details', click on the 'View in Compute Engine' link
7. Stop the VM by clicking on the 'STOP' button. Click the 'STOP' button on the confirmation dialogue.
8. Once the the VM has been stopped, click on the 'EDIT' button
9. Under 'Identity and API access', use the dropdown to select a non-default service account as per needs
10. Click on 'Save'
11. Click on 'START/RESUME' from the top menu.

Query:
```config from cloud.resource where api.name = 'gcloud-vertex-ai-notebook-instance' AND json.rule = state equals "ACTIVE" and serviceAccount contains "compute@developer.gserviceaccount.com" as X; 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 Y; filter ' $.X.serviceAccount equals $.Y.user'; show X;```
Azure Network Watcher is not enabled

This is applicable to azure 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 cloud.type = 'azure' AND cloud.service = 'Azure Network Watcher' AND api.name = 'azure-network-watcher-list' AND json.rule = ' provisioningState !exists  or provisioningState != Succeeded'```
dnd-azure-disk-flip-flop-policy

This is applicable to azure cloud and is considered a high 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.account = 'Azure_Redlock_QA_BVT_25FE' AND api.name = 'azure-disk-list' AND json.rule = id exists ```
OCI Load Balancer not configured with inbound rules or listeners
This policy identifies Load Balancers that are not configured with inbound rules or listeners.

A Load Balancer's subnet security lists should include ingress rules, and the Load Balancer should have at least one listener to handle incoming traffic. Without these configurations, the load balancer cannot receive and route incoming traffic, rendering it ineffective. 

As best practice, it is recommended to configure Load Balancers with proper inbound rules and listeners.
This is applicable to oci 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 configure the OCI Load Balancers with inbound rules and listeners, refer to the following documentation:
https://docs.cloud.oracle.com/iaas/Content/Security/Reference/configuration_tasks.htm#lb-enable-traffic.

Query:
```config from cloud.resource where api.name = 'oci-networking-loadbalancer' and json.rule = lifecycleState equal ignore case "ACTIVE" as X; config from cloud.resource where api.name = 'oci-networking-subnet' and json.rule = lifecycleState equal ignore case "AVAILABLE" as Y; config from cloud.resource where api.name = 'oci-networking-security-list' AND json.rule = lifecycleState equal ignore case AVAILABLE as Z; filter 'not ($.X.listeners does not equal "{}" and ($.X.subnetIds contains $.Y.id and $.Y.securityListIds contains $.Z.id and $.Z.ingressSecurityRules is not empty))'; show X;```
IBM Cloud MySQL Database network access is not restricted to a specific IP range
This policy identifies IBM Cloud MySQL Databases with no specified IP range for network access. To restrict access to your databases, you can allowlist specific IP addresses or ranges of IP addresses on your deployment. When no IP addresses are in the allowlist, the allowlist is disabled and the deployment accepts connections from any IP address. It is recommended to create an allowlist, only IP addresses that match the allowlist or are in the range of IP addresses in the allowlist can connect to your deployment

This is applicable to ibm cloud and is considered a medium severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. Log in to the IBM Cloud Console
2. Click on 'Menu Icon' and navigate to 'Resource list', from the list of resources select MySQL database reported in the alert.
3. Refer below URL for setting allowlist IP addresses : https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-allowlisting&interface=ui#set-allowlist-ui
4. Please remove IP address starting with '0.0.0.0' if any added already in the allow list and make sure to add IP address other than '0.0.0.0'..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-mysql-deployment-info' AND json.rule = allowedListIPAddresses[*] size equals 0 or allowedListIPAddresses[?any( address equals 0.0.0.0/0 )] exists```
AWS EC2 Auto Scaling Launch Configuration is not using encrypted EBS volumes
This policy identifies AWS EC2 Auto Scaling Launch Configurations that are not using encrypted EBS volumes.

A launch configuration defines an instance configuration template that an Auto Scaling group uses to launch EC2 instances. Amazon Elastic Block Store (EBS) volumes allow you to create encrypted launch configurations when creating EC2 instances and auto scaling groups. When the entire EBS volume is encrypted, data stored at rest, in-transit, and snapshots are encrypted. This protects the data from unauthorized access.

As a security best practice for data protection, enable encryption for all EBS volumes at auto scaling launch configuration.
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: Once Auto Scaling Launch Configuration is created you can not modify the encryption for the EBS volumes. To reslove this alert you need copy the reported launch configuration, create new launch template using copied launch configuration data and select the encryption option for EBS vloumes. Later delete the reported launch configuration.

To create a new launch template,
1. Log in to AWS console
2. Navigate to the Amazon EC2 dashboard
3. Under 'Auto Scaling' section, select the 'Auto Scaling groups'
4. Click on 'Launch Templates'
5. On 'Launch Templates' page, click on 'Create launch template'
6. Create new lauch template by mentioning all data same as reported launch configuration.
7. Under 'Storage (volumes)', make sure 'Encrypted' set for all EBS volumes you added..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-autoscaling-launch-configuration' AND json.rule = blockDeviceMappings[*].ebs exists AND blockDeviceMappings[?any(ebs.encrypted is false)] exists```
AWS Secret Manager Automatic Key Rotation is not enabled
This policy identifies AWS Secret Manager that are not enabled with key rotation. As a security best practice, it is important to rotate the keys periodically so that if the keys are compromised, the data in the underlying service is still secure with the new keys.

NOTE: This policy does not include secret manager which are managed by some of the AWS services that store AWS Secrets Manager secrets on your behalf. Refer: https://docs.aws.amazon.com/secretsmanager/latest/userguide/service-linked-secrets.html
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 enable Automatic Key Rotation for AWS Secret Manager follow the steps mentioned in below URL:

https://aws.amazon.com/blogs/security/how-to-configure-rotation-windows-for-secrets-stored-in-aws-secrets-manager/#:~:text=Use%20Case%203.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-secretsmanager-describe-secret' AND json.rule = rotationEnabled is false and owningService is not member of (appflow, databrew, datasync, directconnect, events, opsworks-cm, rds, sqlworkbench)```
Azure Microsoft Defender for Cloud set to Off for Agentless container vulnerability assessment
This policy identifies Azure Microsoft Defender for Cloud where the Agentless container vulnerability assessment is set to Off.

Agentless container vulnerability assessment enables automatic scanning for vulnerabilities in container images stored in Azure Container Registry or running in Azure Kubernetes Service without additional agents. Disabling it exposes container images to unpatched security issues and misconfigurations, risking exploitation and data breaches. Enabling agentless container vulnerability assessment ensures continuous scanning for known vulnerabilities, enhancing security by proactively identifying risks and providing remediation suggestions to maintain compliance with industry standards.

As a security best practice, it is recommended to enable Agentless container vulnerability assessment in Azure Microsoft Defender for Cloud.
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 'Microsoft Defender for Cloud'
3. Under 'Management', select 'Environment Settings'
4. Click on the subscription name
5. Select the 'Defender plans'
6. Click on 'Settings & monitoring' at the top
7. In the table, find 'Agentless container vulnerability assessment' and select 'On' under Plan
8. Click 'Continue' in the top left
9. Click 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = not (pricings[?any(properties.extensions[?any(name equal ignore case ContainerRegistriesVulnerabilityAssessments AND isEnabled is true)] exists AND properties.pricingTier equal ignore case Standard )] exists)```
pcsup-26179-policy

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 cloud.type = 'azure' AND api.name = 'azure-active-directory-admin-consent-request-policy' AND json.rule = ['@odata.context'] exists```
AWS MSK clusters not configured with enhanced monitoring
This policy identifies MSK clusters that are not configured with enhanced monitoring.

Amazon MSK is a fully managed Apache Kafka service on AWS that handles the provisioning, setup, and maintenance of Kafka clusters. Amazon MSK's PER_TOPIC_PER_BROKER monitoring level provides granular insights into the audit, performance and resource utilization of individual topics and brokers, enabling you to identify and optimize bottlenecks in your Kafka cluster.

It is recommended to enable at least PER_TOPIC_PER_BROKER monitoring on the MSK cluster to get enhanced monitoring capabilities.
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 configure MSK clusters with enhanced monitoring:

1. Sign in to the AWS console. Navigate to the Amazon MSK console.
2. In the navigation pane, choose 'Clusters'. Then, select the reported cluster.
3. For 'Action', select 'Edit monitoring'.
4. Select either 'Enhanced partition-level monitoring' or  'Enhanced topic-level monitoring' option.
5. Choose 'Save changes'..

Query:
```config from cloud.resource where api.name = 'aws-msk-cluster' AND json.rule = state equal ignore case active and enhancedMonitoring is member of (DEFAULT, PER_BROKER)```
Azure Custom subscription administrator roles found

This is applicable to azure 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 cloud.type = 'azure' AND api.name = 'azure-role-definition' AND json.rule = properties.permissions[*].actions any start with "*" and properties.permissions[*].actions any end with "*" and properties.type equal ignore case "CustomRole" and properties.assignableScopes starts with "/subscriptions" and properties.assignableScopes does not contain "resourceGroups"```
GCP GKE unsupported node version
This policy identifies the GKE node version and generates an alert if the version running is unsupported.

Using an unsupported version of Google Kubernetes Engine (GKE) on Google Cloud Platform (GCP) can lead to several potential issues and risks, such as security vulnerabilities, compatibility issues, performance and stability problems, and compliance concerns. To mitigate these risks, it's crucial to regularly update the GKE clusters to supported versions recommended by Google Cloud.

As a security best practice, it is always recommended to use the latest version of GKE.

Note: The Policy updates will be made as per the release schedule https://cloud.google.com/kubernetes-engine/docs/release-schedule#schedule-for-release-channels
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: Manually upgrading your nodes:

1. Visit the Google Kubernetes Engine Clusters menu in GCP Console.
2. Next to the cluster you want to edit, Click the Edit button which looks like a pencil under Actions.
3. On the Cluster details page, click the Nodes tab.
4. In the Node Pools section, click the name of the node pool that you want to upgrade.
5. Click the Edit button which looks like a pencil.
6. Click "Change" under Node version.
7. Select the desired version from the Node version drop-down list, then click "Upgrade"..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = isNodeVersionSupported exists AND isNodeVersionSupported does not equal "true"```