knarayan/cloud_posture_checks huggingface dataset:
IBM Cloud Virtual Servers for VPC instance have floating IP address
This policy identifies IBM Cloud Virtual Servers for VPC instances which have floating IP assigned. If any virtual server instance has floating IP address attached, it can be reachable from public internet independent of whether its subnet is attached to a public gateway. It is recommended to not attach any floating IP to virtual server instances.
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 'VPC Infrastructure' and then 'Virtual server instances'
3. Select the 'Virtual server instances' reported in the alert
4. Under 'Network Interfaces' tab, click on edit icon 
5. Under 'Floating IP' dropdown, select 'Unbind current floating IP'
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-virtual-server-instance' AND json.rule = status equal ignore case "running" AND network_interfaces[?any( floating_ips is not empty)] exists```
dnd_test_create_hyperion_policy_ss_finding_2
Description-abe3365a-9395-4eb7-8d0f-9b3ea0735c7b
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: N/A.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = defaultRootObject is empty```
AWS Redshift database does not have audit logging enabled
Audit logging is not enabled by default in Amazon Redshift. When you enable logging on your cluster, Amazon Redshift creates and uploads logs to Amazon S3 that capture data from the creation of the cluster to the present time.
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: 1. Login to AWS Console.
2. Goto Amazon Redshift service
3. On left navigation panel, click on Clusters
4. Click on the reported cluster
5. Click on Database tab and choose 'Configure Audit Logging'
6. On Enable Audit Logging, choose 'Yes'
7. Create a new s3 bucket or use an existing bucket
8. click Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-redshift-describe-clusters' AND json.rule ='loggingStatus.loggingEnabled is false'```
Azure Application gateways listener that allow connection requests over HTTP
This policy identifies Azure Application gateways that are configured to accept connection requests over HTTP. As a best practice, use the HTTPS protocol to encrypt the communication between the application clients and the application gateways.
This is applicable to azure cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: 1. Log in to the Azure Portal
2. Select 'All services'
3. Select 'Application gateways', under NETWORKING
4. Select the Application gateways needed to be modified
5. Select 'Listeners' under Settings
6. To add HTTPS listener follow below step, if already HTTPS listener present jump to point 10
7. Click on 'Add listener', enter 'Listener name', 'Frontend IP'
8. Select 'Protocol' as HTTPS and fill in 'Https Settings' and 'Additional settings' and click on 'Add'
9. Click on 'Rules' in the left pane and click on 'Request routing rule' and associate HTTPS listener to a rule 
10. Click on three dots on the right corner of a row containing 'Protocol' as HTTP
11. Click on 'Delete'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-application-gateway' AND json.rule = ['properties.httpListeners'][*].['properties.protocol'] equals Http```
Alibaba Cloud Security group allow internet traffic to Oracle DB port (1521)
This policy identifies Security groups that allow inbound traffic on Oracle DB port (1521) from the public internet. As a best practice, restrict security groups to only allow permitted traffic and limit brute force attacks on your network.
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, choose Network & Security > Security Groups
4. Select the reported security group and then click Add Rules in the Actions column
5. In Inbound tab, Select the rule with 'Action' as Allow, 'Authorization Object' as 0.0.0.0/0 and 'Port Range' value as 1521, Click Modify in the Actions column
6. Replace the value 0.0.0.0/0 with specific IP address range
7. Click on 'OK'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ecs-security-group' AND json.rule = "permissions is not empty and permissions[?(@.policy=='Accept' && @.direction=='ingress' && @.sourceCidrIp=='0.0.0.0/0')].portRange contains _Port.inRange(1521,1521)"```
AWS NAT Gateways are not being utilized for the default route
This policy identifies Route Tables which have NAT instances for the default route instead of NAT gateways. It is recommended to use NAT gateways as the AWS managed NAT Gateway provides a scalable and resilient method for allowing outbound internet traffic from your private VPC subnets.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['UNUSED_PRIVILEGES'].
Mitigation of this issue can be done as follows: To create a NAT gateway:
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. In the navigation pane, choose 'NAT Gateways'
5. Click on 'Create NAT Gateway', Specify the subnet in which to create the NAT gateway, and select the allocation ID of an Elastic IP address to associate with the NAT gateway. When you're done, Click on 'Create a NAT Gateway'. The NAT gateway displays in the console. After a few moments, its status changes to Available, after which it's ready for you to use.

To update Route Table:
After you've created your NAT gateway, you must update your route tables for your private subnets to point internet traffic to the NAT gateway. We use the most specific route that matches the traffic to determine how to route the traffic.
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. In the navigation pane, choose 'Route Tables'
5. Select the reported route table associated with your private subnet 
6. Choose 'Routes' and Click on 'Edit routes'
7. Replace the current route that points to the NAT instance with a route to the NAT gateway
8. Click on 'Save routes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-route-tables' AND json.rule = "routes[?(@.state == 'active' && @.instanceId)].destinationCidrBlock contains 0.0.0.0/0"```
Alibaba Cloud Security group allow internet traffic to Telnet port (23)
This policy identifies Security groups that allow inbound traffic on Telnet port (23) from the public internet. As a best practice, restrict security groups to only allow permitted traffic and limit brute force attacks on your network.
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, choose Network & Security > Security Groups
4. Select the reported security group and then click Add Rules in the Actions column
5. In Inbound tab, Select the rule with 'Action' as Allow, 'Authorization Object' as 0.0.0.0/0 and 'Port Range' value as 23, Click Modify in the Actions column
6. Replace the value 0.0.0.0/0 with specific IP address range
7. Click on 'OK'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ecs-security-group' AND json.rule = "permissions is not empty and permissions[?(@.policy=='Accept' && @.direction=='ingress' && @.sourceCidrIp=='0.0.0.0/0')].portRange contains _Port.inRange(23,23)"```
GCP Storage Bucket storing GCP Vertex AI training pipeline output model
This policy identifies publicly exposed GCS buckets that are used to store the GCP Vertex AI training pipeline output model.

GCP Vertex AI training pipeline output models are stored in the Storage bucket. Vertex AI training pipeline output model is considered sensitive and confidential intellectual property and its storage location should be checked regularly. The storage location should be as per your organization's security and compliance requirements.

It is recommended to monitor, identify, and evaluate storage location for the GCP Vertex AI training pipeline output model regularly to prevent unauthorized access and AI model thefts.
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: Review and validate the Vertex AI training pipeline output models are stored in the right Storage buckets. Move and/or delete the model and other related artifacts if they are found in an unexpected location. Review how the Vertex AI training pipeline was configured to output to an unauthorised/unapproved storage bucket..

Query:
```config from cloud.resource where api.name = 'gcloud-storage-buckets-list' as X; config from cloud.resource where api.name = 'gcloud-vertex-ai-aiplatform-training-pipeline' as Y; filter ' $.Y.trainingTaskOutputDirectory contains $.X.id '; show X;```
Edited_ayiumvbvgu_ui_auto_policies_tests_name
lvcskhftle_ui_auto_policies_tests_descr
This is applicable to aws cloud and is considered a critical 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-iam-list-users' AND json.rule = createDate contains 2018```
OCI Security List allows all traffic on SSH port (22)
This policy identifies OCI Security lists that allow unrestricted ingress access to port 22. It is recommended that no security list allows unrestricted ingress access to port 22. As a best practice, remove unfettered connectivity to remote console services, such as Secure Shell (SSH),  to reduce server's exposure to risk.
This is applicable to oci cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: 1. Login to the OCI Console
2. Type the resource reported in the alert into the Search box at the top of the Console.3. Click the resource reported in the alert from the Resources submenu
4. Under Resources, click Ingress Rules.
5. If you want to add a rule, click Add Ingress Rules
6. If you want to delete an existing rule, click the Actions icon (three dots), and then click Remove.
7. If you wanted to edit an existing rule, click the Actions icon (three dots), and then click Edit..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-networking-security-list' AND json.rule = (ingressSecurityRules[?any((source equals 0.0.0.0/0) and (((*.destinationPortRange.min == 22 or *.destinationPortRange.max == 22) or (*.destinationPortRange.min < 22 and *.destinationPortRange.max > 22)) or (protocol equals "all") or ((tcpOptions does not exist) and (udpOptions does not exist) and (protocol does not equal 1))))] exists)```
Azure Container Registry with local admin account enabled
This policy identifies Azure Container Registries having local admin account enabled.

Enabling the admin account allows access to the registry through username and password, bypassing Microsoft Entra ID authentication. Disabling the local admin account improves security by enforcing exclusive use of Microsoft Entra ID identities, which provide centralized management, enhanced auditing, and better control over permissions. By relying solely on Microsoft Entra ID for authentication, the risk of unauthorized access through local credentials is mitigated, ensuring stronger protection for your container registry.

As a security best practice, it is recommended to disable local admin account for Azure Container Registries.
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 your Azure portal
2. Navigate to 'Container registries'
3. Select the reported Container Registry
4. Under 'Settings' select 'Access Keys'
5. Ensure that the 'Admin user' box is unchecked.

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.adminUserEnabled is true```
AWS CloudFront web distribution using insecure TLS version
This policy identifies AWS CloudFront web distributions which are configured with TLS versions for HTTPS communication between viewers and CloudFront. As a best practice, use recommended TLSv1.2_2021 as the minimum protocol version in your CloudFront distribution security policies.
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. Navigate to CloudFront Distributions Dashboard
3. Click on the reported distribution
4. On 'General' tab, Click on 'Edit' button under 'Settings'
5. On 'Edit Distribution' page, Set 'Security Policy' to TLSv1.2_2021
6. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = viewerCertificate.certificateSource does not contain cloudfront and viewerCertificate.minimumProtocolVersion does not equal TLSv1.2_2021```
AWS Elasticsearch domain is not configured with HTTPS
This policy identifies Elasticsearch domains that are not configured with HTTPS. Amazon Elasticsearch domains allow all traffic to be submitted over HTTPS, ensuring all communications between application and domain are encrypted. It is recommended to enable HTTPS so that all communication between the application and all data access goes across an encrypted communication channel to eliminate man-in-the-middle attacks.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: 1. Log in to the AWS Console
2. In the console, select the specific region from the region drop-down on the top right corner, for which the alert is generated.
3. Navigate to the Elasticsearch dashboard
4. Click on reported Elasticsearch domain
5. Click on 'Actions', from drop-down choose 'Modify encryptions'
6. In 'Modify encryptions' page, Select 'Require HTTPS for all traffic to the domain'
7. Click on Submit.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-es-describe-elasticsearch-domain' AND json.rule = processing is false and domainEndpointOptions.enforceHTTPS is false```
Azure Key vaults diagnostics logs are disabled
This policy identifies Azure Key vaults which has diagnostics logs disabled. Enabling Diagnostic Logs gives visibility into the data plane thus gives organisation ability to detect reconnaissance, authorization attempts or other malicious activity. It is recommended to enable diagnostics logs settings for Azure Key vaults.
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. Navigate to 'Key vaults', and select the reported key vault from the list
3. Select 'Diagnostic settings' under 'Monitoring' section
4. Click on '+Add diagnostic setting'
5. Specify a 'Diagnostic settings name',
6. Under 'Category details' section, select the type of 'Log' that you want to enable
7. Under section 'Destination details',
a. If you select 'Send to Log Analytics', select the 'Subscription' and 'Log Analytics workspace'
b. If you set 'Archive to storage account', select the 'Subscription', 'Storage account' and set the 'Retention (days)'
c. If you set 'Stream to an event hub', select the 'Subscription', 'Event hub namespace', 'Event hub name' and set the 'Event hub policy name'
8. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-key-vault-list' AND json.rule = diagnosticSettings.value[*] size equals 0```
GCP PostgreSQL instance database flag log_lock_waits is disabled
This policy identifies PostgreSQL database instances in which database flag log_lock_waits is not set. Enabling the log_lock_waits flag can be used to identify poor performance due to locking delays or if a specially-crafted SQL is attempting to starve resources through holding locks for excessive amounts of time.
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
NOTE: If the instance is stopped, You need to START instance first to edit the configurations, then Click on EDIT.
5. If the flag has not been set on the instance, 
Under 'Configuration options', click on 'Add item' in 'Flags' section, choose the flag 'log_lock_waits' from the drop-down menu and set the value as 'On'
OR
If the flag has been set to off, Under 'Configuration options', In 'Flags' section choose the flag 'log_lock_waits' and set the value as 'On'
6. Click Save.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = "databaseVersion contains POSTGRES and (settings.databaseFlags[?(@.name=='log_lock_waits')] does not exist or settings.databaseFlags[?(@.name=='log_lock_waits')].value equals off)"```
AWS S3 bucket used for storing AWS Sagemaker training job output
This policy identifies the AWS S3 bucket used for storing AWS Sagemaker training job output. 

S3 buckets hold the results and artifacts generated from training machine learning models in Sagemaker. Ensuring proper configuration and access control is crucial to maintaining the security and integrity of the training output. Improperly secured S3 buckets used for storing AWS Sagemaker training output can lead to unauthorized access, data breaches, and potential exposure of sensitive model information.

It is recommended to implement strict access controls, enable encryption, and audit permissions to secure AWS S3 buckets for AWS Sagemaker training job output and ensure compliance.
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 protect the S3 buckets utilized by the Sagemaker training job, please refer to the following link for recommended best practices
https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html.

Query:
```config from cloud.resource where api.name = 'aws-s3api-get-bucket-acl' as X; config from cloud.resource where api.name = 'aws-sagemaker-training-job' as Y; filter '$.Y.OutputDataConfig.bucketName equals $.X.bucketName'; show X;```
Azure PostgreSQL database server with SSL connection disabled
This policy identifies PostgreSQL database servers for which SSL enforce status is disabled. SSL connectivity helps to provide a new layer of security, by connecting database server to client applications using Secure Sockets Layer (SSL). Enforcing SSL 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.
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. Login to Azure console
2. Navigate to 'Azure Database for PostgreSQL servers' dashboard
3. Click on the alerted database name
4. Go to 'Connection security' under 'Settings' block.
5. In 'SSL settings' block, for 'Enforce SSL connection' field, click on 'Enabled’ on the toggle button
6. Click on 'Save' button from top menu to save the change..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-postgresql-server' AND json.rule = 'properties.sslEnforcement contains Disabled'```
GCP Kubernetes cluster shielded GKE node with integrity monitoring disabled
This policy identifies GCP Kubernetes cluster shielded GKE nodes that are not enabled with Integrity Monitoring. Integrity Monitoring provides active alerting for Shielded GKE nodes which allows administrators to respond to integrity failures and prevent compromised nodes from being deployed into the cluster.
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: Note: Once a Node pool is provisioned, it cannot be updated to enable Integrity monitoring. You must create new Node pools within the cluster with Integrity monitoring enabled. You will also need to migrate workloads from existing non-conforming Node pools to the newly created Node pool, then delete the non-conforming pools.

To create a node pool with Integrity monitoring enabled follow the below steps,

1. Log in to gcloud console
2. Navigate to service 'Kubernetes Engine'
3. Select the alerted cluster and click 'ADD NODE POOL'
4. Ensure that the 'Enable integrity monitoring' checkbox is checked under the 'Shielded options' in section 'Security'
5. Click on 'CREATE'..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = nodePools[?any(config.shieldedInstanceConfig.enableIntegrityMonitoring does not exist or config.shieldedInstanceConfig.enableIntegrityMonitoring is false)] exists```