knarayan/cloud_posture_checks huggingface dataset:
Azure Database for MySQL flexible server firewall rule allow access to all IPv4 address
This policy identifies Azure Database for MySQL flexible servers which have firewall rule allowing access to all IPV4 address.

MySQL server having a firewall rule with start IP being 0.0.0.0 and end IP being 255.255.255.255 (i.e. all IPv4 addresses) would allow access to server from any host on the internet. Allowing access to all IPv4 addresses expands the potential attack surface and exposes the MySQL server to increased threats.

As a best security practice, it is recommended to configure the MySQL servers with restricted IP-based server-level firewall rules so that servers are accessible only to restricted entities.
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 Azure Portal
2. Navigate to Azure Database for MySQL flexible servers dashboard
3. Click on reported MySQL server
4. Under 'Settings', click on 'Networking'.
5. Under 'Firewall rules' section, delete the rule which has 'Start IP' as 0.0.0.0 and 'End IP' as 255.255.255.255. Add specific IPs as per your business requirement.
6. Click on 'Save'

NOTE: These settings take effect immediately after they're applied. You might experience connection loss if you don't meet the requirements for each setting..

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 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```
IBM Cloud Kubernetes cluster has Image pull secrets disabled
This policy identifies IBM Cloud Kubernetes Clusters with Image pull secrets disabled. If Image pull secrets feature Is disabled, it stores registry credentials to connect to container registry. It is recommended to enable image pull secrets feature for proper protection of personal information
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: To enable image pull secrets feature on a Kubernetes cluster, refer following URLs:
https://cloud.ibm.com/docs/containers?topic=containers-registry#imagePullSecret_migrate_api_key
https://cloud.ibm.com/docs/containers?topic=containers-registry#update-pull-secret.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-kubernetes-cluster' AND json.rule = type equal ignore case kubernetes and state equal ignore case normal and features.pullSecretApplied is false```
AWS RDS cluster not configured with IAM authentication
This policy identifies RDS clusters that are not configured with IAM authentication. If you enable IAM authentication you don't need to store user credentials in the database, because authentication is managed externally using IAM. IAM database authentication provides the network traffic to and from database clusters is encrypted using Secure Sockets Layer (SSL), Centrally manage access to your database resources and Profile credentials instead of a password, for greater security.

For details:
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.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 IAM authentication on your RDS cluster follow the below mentioned URL:
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Enabling.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name= 'aws-rds-db-cluster' AND json.rule = status contains available and (engine contains postgres or engine contains mysql) and iamdatabaseAuthenticationEnabled is false```
Azure Cosmos DB Private Endpoint Connection is not configured
This policy identifies Cosmos DBs that are not configured with a private endpoint connection. Azure Cosmos DB private endpoints can be configured using Azure Private Link. Private Link allows users to access an Azure Cosmos account 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 Private Endpoint Connection to Cosmos DB.
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 to the following URL to configure Private endpoints on your Cosmos DB:
https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-configure-private-endpoints.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cosmos-db' AND json.rule = properties.provisioningState equals Succeeded and properties.privateEndpointConnections[*] does not exist```
Azure Active Directory Guest users found
This policy identifies Azure Active Directory Guest users. Azure Active Directory allows B2B collaboration which lets you invite people from outside your organisation to be guest users in your cloud account. Avoid creating guest user in your cloud account unless you have business need. Guest users are usually added for users outside your employee on-boarding/off-boarding process and could potentially be overlooked leading to a potential vulnerability.
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 Active Directory' (Left Panel)
3. Click on 'Users' under 'Manage'
4. Search for reported user in search pane
5. Select on check box for the reported user
6. Click on 'Delete user' in top pane
7. Select 'OK' to confirm

Note: Verify impact caused by deleting Guest user.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-active-directory-user' AND json.rule = userType equals Guest```
GCP VM instances with excessive service account permissions
This policy identifies VM instances with service account which have excessive permissions other than viewer/reader access. It is recommended that each instance that needs to call a Google API should run as a service account with the minimum permissions necessary for that instance to do its job. In practice, this means you should configure service accounts for your instances with the following process:
	- Create a new service account rather than using the Compute Engine default service account.
	- Grant IAM roles to that service account for only the resources that it needs.
	- Configure the instance to run as that service account.
	- Configure VM instance least permissive service account with only viewer/reader role until it is necessary to have more access.
Avoid granting more access than necessary and regularly check your service account permissions to make sure they are up-to-date.
This is applicable to gcp cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: Note: To change an instance's service account and access scopes, the instance must be temporarily stopped. To stop your instance, read the documentation for Stopping an instance. After changing the service account or access scopes, remember to restart the instance.

To change service account of the stopped instance:
1. Login to 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
Note: To fix this alert either you have to associate service account which has only viewer access or if VM has desired service account and access then dismiss the alert for particular VM instance.
8. Click the Save button.

Query:
```config from cloud.resource where api.name = 'gcloud-compute-instances-list' AND json.rule = name does not start with "gke-" and status equals RUNNING as X; config from cloud.resource where api.name = 'gcloud-projects-get-iam-user' as Y; filter '($.X.serviceAccounts[*].email equals $.Y.user) and not($.Y.roles[*] contains projects or $.Y.roles[*] all equal roles/viewer)'; show X;```
dnd_test_create_hyperion_policy_ss_update_child_policy_finding_1
Description-81f1240b-8ec0-4626-86af-79a0b93913f4
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = defaultRootObject is empty```
Azure Storage account diagnostic setting for queue is disabled
This policy identifies Azure Storage account queues that have diagnostic logging disabled.

By enabling diagnostic settings, you can capture various types of activities and events occurring within these storage account queues. These logs provide valuable insights into the operations, performance, and security of the storage account queues.

As a best practice, it is recommended to enable diagnostic logs on all storage account queues.
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 Azure Portal
2. Navigate to the Storage Accounts dashboard
3. Click on the reported Storage account
4. Under the 'Monitoring' menu, click on 'Diagnostic settings'
5. Select the queue resource
6. Under 'Diagnostic settings', click on 'Add diagnostic setting'
7. At the top, enter the 'Diagnostic setting name'
8. Under 'Logs', select all the checkboxes under 'Categories'
9. Under 'Destination details', select the destination for logging
10. Click on 'Save'.

Query:
```config from cloud.resource where api.name = 'azure-storage-account-list' AND json.rule = properties.provisioningState equal ignore case Succeeded as X; config from cloud.resource where api.name = 'azure-storage-account-queue-diagnostic-settings' AND json.rule = properties.logs[*].enabled all true as Y; filter 'not($.X.name equal ignore case $.Y.StorageAccountName)'; show X;```
OCI IAM password policy for local (non-federated) users does not have a symbol
This policy identifies Oracle Cloud Infrastructure(OCI) accounts that do not have a symbol in the password policy for local (non-federated) users. As a security best practice, configure a strong password policy for secure access to the OCI console.
This is applicable to oci cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['WEAK_PASSWORD'].
Mitigation of this issue can be done as follows: 1. Login to the OCI Console Page: https://console.ap-mumbai-1.oraclecloud.com/
2. Go to Identity in the Services menu.
3. Select Authentication Settings from the Identity menu.
4. Click Edit Authentication Settings in the middle of the page.
5. Ensure the checkbox is selected next to MUST CONTAIN AT LEAST 1 SPECIAL CHARACTER.

Note : The console URL is region specific, your tenancy might have a different home region and thus console URL..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-iam-authentication-policy' AND json.rule = 'passwordPolicy.isSpecialCharactersRequired isFalse'```
GCP Identity-Aware Proxy (IAP) not enabled for External HTTP(s) Load Balancer
This policy identifies GCP External HTTP(s) Load Balancers for which Identity-Aware Proxy(IAP) is disabled.  IAP is used to enforce access control policies for applications and resources. It works with signed headers or the App Engine standard environment Users API to secure connections to External HTTP(s) Load Balancers. It is recommended to enable Identity-Aware Proxy for securing the External HTTP(s) Load Balancers.

Reference: https://cloud.google.com/iap/docs/concepts-overview
This is applicable to gcp cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: Follow the below mentioned URL to enable IAP on the external HTTP(S) load balancer:

https://cloud.google.com/iap/docs/load-balancer-howto#enable-iap.

Query:
```config from cloud.resource where api.name = 'gcloud-compute-external-backend-service' AND json.rule = iap does not exist or iap.enabled equals "false"```
Azure Key Vault audit logging is disabled
This policy identifies Azure Key Vault instances for which audit logging is disabled. As a best practice, enable audit event logging for Key Vault instances to monitor how and when your key vaults are accessed, and by whom.
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. Select 'Key vaults'
3. Select the key vault instance to modify
4. Select 'Diagnostic settings' under 'Monitoring'
5. Click on '+Add diagnostic setting'
6. Specify a 'Diagnostic settings name',
7. Under 'Category details' section, Under Log, select 'AuditEvent'
8. Under section 'Destination details',
a. If you select 'Send to Log Analytics workspace', set the 'Subscription' and 'Log Analytics workspace'
b. If you select 'Archive to storage account', set the 'Subscription', 'Storage account' and 'Retention (days)'
c. If you select 'Stream to an event hub', set the 'Subscription', 'Event hub namespace', 'Event hub name' and 'Event hub policy name'
d. If you select 'Send to partner solution', set the 'Subscription' and 'Destination'
9. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND  api.name = 'azure-key-vault-list' AND json.rule =  "not ( diagnosticSettings.value[*].properties.logs[*].enabled any equal true and diagnosticSettings.value[*].properties.logs[*].enabled size greater than 0 )"```
GCP Vertex AI Endpoint not encrypted with CMEK
This policy identifies GCP Vertex AI Endpoints that are not encrypted with CMEK.

Customer Managed Encryption Keys (CMEK) for a Vertex AI Endpoint provide control over the encryption of data at rest. Encrypting GCP Vertex AI Endpoints with CMEK enhances security by giving you full control over encryption keys. This ensures data protection, especially for sensitive models and predictions. CMEK allows key rotation and revocation, aligning with compliance requirements and offering better data privacy management.

It is recommended to use CMEK for Vertex AI Endpoint encryption.
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: GCP Vertex AI Endpoint encryption cannot be changed after creation. To make use of CMEK a new Endpoint can be created.

To create a new Vertex AI Endpoint, please follow the steps below:
1. Login to the GCP console
2. Navigate to the 'Vertex AI' service
3. In side panel, under 'DEPLOY AND USE', go to 'Online prediction'
4. Select 'ENDPOINTS' tab
5. Click 'CREATE'
6. Configure the endpoint name and access as required
7. Click on 'ADVANCED OPTIONS', and then select 'Cloud KMS key'
8. Select the appropriate 'Key type' and then select the required CMEK
9. Click 'CONTINUE'
10. Configure the Model settings as required, click 'CONTINUE'
11. Configure the Model monitoring as required, click 'CONTINUE'
12. Click 'CREATE'

To delete an existing Vertex AI Endpoint, please follow the steps below:

1. Login to the GCP console
2. Navigate to the 'Vertex AI' service
3. In side panel, under 'DEPLOY AND USE', go to 'Online prediction'
4. Select 'ENDPOINTS' tab
5. Click on the alerting endpoint
6. Click on 'View More' bottom (three dots) for any model from the list.
7. Click 'Undeploy model from endpoint'
8. In the Undeploy model from endpoint dialog, click 'Undeploy'
9. Repeat step 6-8 for all models listed
10. Go back to 'Online prediction' page
11. Select the alerting endpoint checkbox
12. Click 'DELETE'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-vertex-ai-aiplatform-endpoint' AND json.rule = encryptionSpec.kmsKeyName does not exist```
Azure Machine Learning compute instance with local authentication enabled
This policy identifies Azure Machine Learning compute instances that are using local authentication.

Disabling local authentication improves security by mandating the use of Microsoft Entra ID for authentication. Local authentication can lead to security risks and unauthorized access. Using Microsoft Entra ID ensures a more secure and compliant authentication process.

As a security best practice, it is recommended to disable local authentication and use Microsoft Entra ID for authentication.
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: Disabling local authentication on an existing Azure Machine Learning compute instance without deleting and recreating it is not supported. The recommended approach to secure your compute instance is to set it up without local authentication from the beginning.

To create a new compute instance without local authentication:
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 'Enable SSH access' section, leave the option disabled to turn off local authentication
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.properties.state equal ignore case running and (properties.computeType equal ignore case ComputeInstance or properties.computeType equal ignore case AmlCompute ) and properties.disableLocalAuth is false```
OCI Network Load Balancer not configured with backend set
This policy identifies OCI Network Load Balancers that have no backend set configured. 

A backend set is a crucial component of a Network Load Balancer, comprising a load balancing policy, a health check policy, and a list of backend servers. Without a backend set, the Network Load Balancer lacks the necessary configuration to distribute incoming traffic and monitor the health of backend servers. 

As best practice, it is recommended to properly configure the backend set for the Network Load Balancer to function effectively, distribute incoming data, and maintain the reliability of backend services.
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 Network Load Balancers with backend sets, refer to the following documentation:
https://docs.oracle.com/en-us/iaas/Content/Balance/Tasks/managingbackendsets_topic-Creating_Backend_Sets.htm#top.

Query:
```config from cloud.resource where api.name = 'oci-networking-networkloadbalancer' AND json.rule = lifecycleState equal ignore case "ACTIVE" and backendSets.*.backends is empty OR backendSets.*.backends equals "[]"```
AWS Redshift Cluster not encrypted using Customer Managed Key
This policy identifies Redshift Clusters which are encrypted with default KMS keys and not with Keys managed by Customer. It is a best practice to use customer managed KMS Keys to encrypt your Redshift databases data. Customer-managed CMKs give you more flexibility, including the ability to create, rotate, disable, define access control for, and audit the encryption keys used to help protect your data.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: To enable encryption with Customer Managed Key on your Redshift cluster follow the steps mentioned in below URL:
https://docs.aws.amazon.com/redshift/latest/mgmt/changing-cluster-encryption.html.

Query:
```config from cloud.resource where api.name = 'aws-redshift-describe-clusters' as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' as Y; filter '$.X.encrypted is true and $.X.kmsKeyId equals $.Y.key.keyArn and $.Y.keyMetadata.keyManager contains AWS'; show X;```
GCP Storage Bucket does not have Access and Storage Logging enabled
This policy identifies storage buckets that do not have Access and Storage Logging enabled. By enabling access and storage logs on target Storage buckets, it is possible to capture all events which may affect objects within target buckets. It is recommended that storage Access Logs and Storage logs are enabled for every Storage Bucket.
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: Follow the steps mentioned in the below link to enable Access and Storage logs using GSUTIL or JSON API.
Reference : https://cloud.google.com/storage/docs/access-logs.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name= 'gcloud-storage-buckets-list' AND json.rule = logging does not exist```