knarayan/cloud_posture_checks huggingface dataset:
Patch 21.11.1 - RLP-83104 - Copy of Critical of AWS S3 bucket publicly readable
This policy identifies the S3 buckets that are publicly readable by Get/Read/List bucket operations. These permissions permit anyone, malicious or not, to Get/Read/List bucket operations on your S3 bucket if they can guess the namespace. S3 service does not protect the namespace if ACLs and Bucket policy is not handled properly, with this configuration you may be at risk of compromise of critical data by leaving S3 public.

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

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

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = ((((publicAccessBlockConfiguration.ignorePublicAcls is false and accountLevelPublicAccessBlockConfiguration does not exist) or (publicAccessBlockConfiguration does not exist and accountLevelPublicAccessBlockConfiguration.ignorePublicAcls is false) or (publicAccessBlockConfiguration.ignorePublicAcls is false and accountLevelPublicAccessBlockConfiguration.ignorePublicAcls is false)) and acl.grantsAsList[?any(grantee equals AllUsers and permission is member of (ReadAcp,Read,FullControl))] exists) or ((policyStatus.isPublic is true and ((publicAccessBlockConfiguration.restrictPublicBuckets is false and accountLevelPublicAccessBlockConfiguration does not exist) or (publicAccessBlockConfiguration does not exist and accountLevelPublicAccessBlockConfiguration.restrictPublicBuckets is false) or (publicAccessBlockConfiguration.restrictPublicBuckets is false and accountLevelPublicAccessBlockConfiguration.restrictPublicBuckets is false))) and (policy.Statement[?any(Effect equals Allow and (Principal equals * or Principal.AWS equals *) and (Action contains s3:* or Action contains s3:Get or Action contains s3:List) and (Condition does not exist))] exists))) and websiteConfiguration does not exist```
GCP Kubernetes Engine Clusters not using Container-Optimized OS for Node image
This policy identifies Kubernetes Engine Clusters which do not have a container-optimized operating system for node image. Container-Optimized OS is an operating system image for your Compute Engine VMs that is optimized for running Docker containers. By using Container-Optimized OS for node image, you can bring up your Docker containers on Google Cloud Platform quickly, efficiently, and securely. The Container-Optimized OS node image is based on a recent version of the Linux kernel and is optimized to enhance node security. It is also regularly updated with features, security fixes, and patches. The Container-Optimized OS image provides better support, security, and stability than other images.
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. Login to GCP Portal
2. Go to Kubernetes Engine (Left Panel)
3. Select Kubernetes clusters
4. From the list of clusters, choose the reported cluster
5. Under Node Pools, For Node image click on 'Change'
6. Choose 'Container-Optimized OS (cos)' 
7. Click on Change.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = 'nodeConfig.imageType does not exist or nodeConfig.imageType does not start with COS'```
GCP Kubernetes Engine cluster not using Release Channel for version management
This policy identifies GCP Kubernetes Engine clusters that are not using Release Channel for version management. Subscribing to a specific release channel reduces version management complexity. 

The Regular release channel upgrades every few weeks and is for production users who need features not yet offered in the Stable channel. These versions have passed internal validation, but don't have enough historical data to guarantee their stability. Known issues generally have known workarounds.

The Stable release channel upgrades every few months and is for production users who need stability above all else, and for whom frequent upgrades are too risky. These versions have passed internal validation and have been shown to be stable and reliable in production, based on the observed performance of those clusters.
This is applicable to gcp cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to gcloud console
2. Navigate to service 'Kubernetes Engine'
3. From the list of available clusters, select the reported cluster
4. Go to the 'Release channel' configuration
5. To edit, Click on the 'UPGRADE AVAILABLE' or 'Edit release channel'(Whichever available)
6. In the 'Edit version' pop-up, select the required release channel(Regular Channel/ Stable Channel/ Rapid Channel) from the 'Release channel' dropdown
7. Click on 'SAVE CHANGES' or 'CHANGE'.

Know more on Release Channels here: https://cloud.google.com/kubernetes-engine/docs/concepts/release-channels.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = releaseChannel.channel does not exist```
GCP SQL Instances without any Label information
This policy identifies the SQL DB instance which does not have any Labels. Labels can be used for easy identification and searches.
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. Login to GCP Console.
2. On left Navigation, Click on SQL
3. Select the reported SQL instance.
4. Click on EDIT, Add labels with the appropriate Key:Value information.
5. Click Save.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name='gcloud-sql-instances-list' and json.rule = 'settings.userLabels[*] does not exist'```
Azure Storage Account 'Trusted Microsoft Services' access not enabled
This policy identifies Storage Accounts which have 'Trusted Microsoft Services' access not enabled. Some Microsoft services that interact with storage accounts operate from networks that can't be granted access through network rules. To help this type of service work as intended, allow the set of trusted Microsoft services to bypass the network rules. These services will then use strong authentication to access the storage account. If the Allow trusted Microsoft services exception is enabled, the following services: Azure Backup, Azure Site Recovery, Azure DevTest Labs, Azure Event Grid, Azure Event Hubs, Azure Networking, Azure Monitor and Azure SQL Data Warehouse (when registered in the subscription), are granted access to the storage account. It is recommended to enable Trusted Microsoft Services on storage account instead of leveraging network rules.
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 Storage Accounts dashboard
3. Select the storage account you need to modify
4. Under 'Security + networking' section, Click on 'Networking'
5. Under 'Firewalls and virtual networks' tab, Ensure that 'Enabled from selected virtual networks and IP addresses' is selected.
6. Under 'Exceptions', Make sure that 'Allow Azure services on the trusted services list to access this storage account' is checked.
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-storage-account-list' AND json.rule = 'networkRuleSet.bypass does not contain AzureServices'```
Alibaba Cloud OSS bucket server-side encryption is disabled
This policy identifies Object Storage Service (OSS) buckets which have server-side encryption disabled. As a best practice enable the server-side encryption to improve data security without making changes to your business or applications. OSS encrypts user data when writing the data into the hard disks deployed in the data center and automatically decrypts the data when it is accessed.
This is applicable to alibaba_cloud 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: 1. Log in to Alibaba Cloud Portal
2. Go to Object Storage Service
3. In the left-side navigation pane, click on the reported bucket
4. In the 'Basic Settings' tab, In the 'Server-side Encryption' Section, Click on 'Configure'
5. For 'Bucket Encryption' field, Set either 'KMS' or 'AES256' encryption instead of 'None'
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-oss-bucket-info' AND json.rule =  'serverSideEncryptionConfiguration.applyServerSideEncryptionByDefault.ssealgorithm equals None'```
OCI File Storage File Systems are not encrypted with a Customer Managed Key (CMK)
This policy identifies the OCI File Storage File Systems that are not encrypted with a Customer Managed Key (CMK). It is recommended that File Storage File Systems should be encrypted with a Customer Managed Key (CMK), using  Customer Managed Key (CMK), provides an additional level of security on your data by allowing you to manage your own encryption key lifecycle management for the File System
This is applicable to oci 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: 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. Click Assign next to Encryption Key: Oracle managed key.
5. Select a Vault from the appropriate compartment
6. Select a Master Encryption Key
7. Click Assign.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-file-storage-file-system' AND json.rule = kmsKeyId is empty```
IBM Cloud Object Storage bucket is not restricted to Private IP ranges
This policy identifies IBM Cloud object storage buckets that are not restricted to private IP ranges or if the cloud object storage firewall is not configured.

IBM Cloud Storage Firewall enables users to control access to their stored data by setting up firewall rules and restricting access to authorised IP addresses or ranges, thereby enhancing security and compliance with regulatory standards. Not restricting access via the IBM Cloud Storage Firewall to private IPs increases the risk of unauthorised data access, breaches, and potential compliance violations.

It is recommended to add only private IPs to the list of authorised IPs / ranges in bucket firewall policies.
This is applicable to ibm 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 set a list of authorised IP addresses or remove the public IP from the IBM cloud object storage,

1. Log in to the IBM Cloud Console
2. Click on the menu icon and navigate to 'Resource list'. From the list of resources, select the object storage instance in which the reported bucket resides
3. Select the bucket to which you want to limit access to authorised IP addresses
4. Select the 'Firewall (legacy)' dropdown under the 'Permissions' tab
6. Click on 'Edit' and Click on 'Add' and specify a list of IP addresses from the IBM cloud private IP range in CIDR notation, for example.
192.168.0.0/16, fe80:021b::0/64. Addresses can follow either IPv4 or IPv6 standards
7. Click 'Add', or click on the public IP address presented in the IP address tab, and then click 'Delete'
8. Click 'Save All' to enforce the firewall.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-object-storage-bucket' AND json.rule = (firewall does not exist or (firewall exists and _IPAddress.areAnyOutsideCIDRRange(firewall.allowed_ip,192.168.0.0/16,172.16.0.0/12,10.0.0.0/8) is true))```
Azure Application Gateway Web application firewall (WAF) policy rule for Remote Command Execution is disabled
This policy identifies Azure Application Gateway Web application firewall (WAF) policies that have the Remote Command Execution rule disabled. It is recommended to define the criteria in the WAF policy with the rule ‘Remote Command Execution (944240)’ under managed rules to help in detecting and mitigating Log4j vulnerability. 

For details:
https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/ 
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. Select 'All services' > 'Web Application Firewall policies (WAF)'
3. Click on the reported Web Application Firewall policies (WAF) policy
4. Click on the 'Managed rules' from the left panel
5. Search for '944240' in Managed rule sets  and Select rule
6. Click on the 'Enable' to enable rule
7. Click on 'Save' to save your changes.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-application-gateway-waf-policy' AND json.rule = properties.policySettings.state equals Enabled and properties.managedRules.managedRuleSets is not empty and properties.managedRules.managedRuleSets[*].ruleGroupOverrides[*].rules[?any(ruleId equals 944240 and state equals Disabled)] exists and properties.applicationGateways[*] is not empty```
AWS regions nearing VPC Private Gateway limit
This policy identifies if your account is near the private gateway limitation per VPC per Region. AWS provides a reasonable starting limitation for the maximum number of Virtual private gateways you can assign in each VPC. If you approach the limit in a particular VPC, this alert indicates that you have nearly exhausted your allocation.
NOTE: As per http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html Virtual private gateway per region limit is 5. This policy will trigger an alert if Virtual private gateway per region reached 80% (i.e. 4) of resource availability limit allocated.
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. Sign in to 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 'Virtual Private Gateways' (Left Panel)
5. Choose the Virtual Private Gateway you want to delete, which is not used or required
6. Click on 'Actions' dropdown
7. Click on 'Delete Virtual Private Gateway'NOTE: If Virtual Private Gateway is already in use it can not be deleted. Make sure gateways unassociated before going to deleting it.
8. On 'Delete Virtual Private Gateway' popup dialog, Click on 'Yes, Delete'NOTE: If existing Virtual Private Gateways are properly associated and exhausted your VPC Virtual Private Gateway limit allocation, you can contact AWS for a service limit increase..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-vpn-gateways-summary' AND json.rule = 'TotalVPNGateways greater than 3'```
AWS Secrets Manager secret configured with automatic rotation not rotated as scheduled
This policy identifies the AWS Secrets Manager secret not rotated successfully based on the rotation schedule.

Secrets Manager stores secrets centrally, encrypts them automatically, controls access, and rotates secrets safely. By rotating secrets, you replace long-term secrets with short-term ones, limiting the risk of unauthorized use. If secrets fail to rotate in Secrets Manager, long-term secrets remain in use, increasing the risk of unauthorized access and potential data breaches.

It is recommended that proper configuration and monitoring of the rotation process be ensured to mitigate these risks.
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: For help diagnosing and fixing common errors related to secrets rotation, refer to the URL:

https://docs.aws.amazon.com/secretsmanager/latest/userguide/troubleshoot_rotation.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-secretsmanager-describe-secret' AND json.rule = 'lastRotatedDate exists and rotationEnabled is true and _DateTime.daysBetween($.lastRotatedDate,today()) > $.rotationRules.automaticallyAfterDays'```
IBM Cloud VPC ACL allow ingress rule from 0.0.0.0/0 to RDP port
This policy identifies IBM Cloud VPC Access Control List which are having ingress rule that allows traffic from 0.0.0.0/0 to RDP port. Doing so, may allow a bad actor to brute force their way into the system and potentially get access to the entire network. It is recommended to review VPC ACL rules to ensure that your resources are not exposed. As a best practice, restrict RDP solely to known static IP addresses.
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: Before making any changes, please check the impact to your applications/services. If the VPC ACL reported indeed need to restrict all traffic, follow the instructions below:
1. Log in to the IBM Cloud Console
2. Click on 'Menu Icon' and navigate to 'VPC Infrastructure' and then 'Access Control Lists'
3. Select the 'Access Control Lists' reported in the alert
4. Under 'Inbound rules'
5. Click on three dots on the right corner of a row containing rule that has a port range value of ALL or a port range that includes port 3389 and has a Source of 0.0.0.0/0
6. Click on 'Delete'.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-network-acl' AND json.rule = rules[?any( source equals "0.0.0.0/0" and direction equals "inbound" and action equals "allow" and ( (protocol equals "tcp" and (( destination_port_max greater than 3389 and destination_port_min less than 3389 ) or ( destination_port_max equals 3389 and destination_port_min equals 3389 ))) or protocol equals "all" ))] exists```
AWS S3 Object Versioning is disabled
This policy identifies the S3 buckets which have Object Versioning disabled. S3 Object Versioning is an important capability in protecting your data within a bucket. Once you enable Object Versioning, you cannot remove it; you can suspend Object Versioning at any time on a bucket if you do not wish for it to persist. It is recommended to enable Object Versioning on S3.
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. Log into your AWS Console and select the S3 service.
2. Choose the reported S3 bucket and click the Properties tab in the upper right frame.
3. Expand the Versioning option
4. Click Enable Versioning
5. Click Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = 'versioningConfiguration.status!=Enabled'```
Alibaba Cloud Security group allow internet traffic to VNC Listener port (5500)
This policy identifies Security groups that allow inbound traffic on VNC Listener port (5500) 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 5500, 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(5500,5500)"```
Azure Machine Learning workspace not configured with user-assigned managed identity
This policy identifies Azure Machine Learning workspaces that are not configured with a user-assigned managed identity.

By default, Azure Machine Learning workspaces use system-assigned managed identities to access resources like Azure Container Registry, Key Vault, Storage, and Application Insights. However, user-assigned managed identities offer better control over the identity's lifecycle and consistent access management across multiple resources. Since system-assigned identities are tied to the workspace and deleted if the workspace is removed, using a user-assigned identity allows access management independently, enhancing security and compliance.

As a security best practice, it is recommended to configure the Azure Machine Learning workspace with a user-assigned managed identity.
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: Method 1: Updating an Existing Workspace
1. Once an Azure Machine Learning workspace is created with a System-Managed Identity, you cannot change it to use only a User-Assigned Managed Identity. You can update the workspace to use both System-Managed and User-Assigned Managed Identities.
2. For detailed instructions on how to configure this, visit the following URL: https://learn.microsoft.com/en-us/azure/machine-learning/how-to-identity-based-service-authentication?view=azureml-api-2&tabs=cli#add-a-user-assigned-managed-identity-to-a-workspace-in-addition-to-a-system-assigned-identity

or

Method 2: Deleting the Existing Workspace and Creating a New Workspace
1. To use only a User-Assigned Managed Identity, delete the existing workspace.  
2. Create a new Azure Machine Learning workspace. During the setup, select 'User Assigned Identity' under the 'Identity' tab to ensure it exclusively uses a User-Assigned Managed Identity from the start..

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 identity.type does not contain UserAssigned```