knarayan/cloud_posture_checks huggingface dataset:
GCP Firewall rule allows all traffic on Telnet port (23)
This policy identifies GCP Firewall rules which allow all inbound traffic on Telnet port (23). Allowing access from arbitrary IP addresses to this port increases the attack surface of your network. It is recommended that the Telnet port (23) should be allowed to specific IP addresses.
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: If the Firewall rule reported indeed needs to restrict all traffic, follow the instructions below:
1. Login to GCP Console
2. Go to 'VPC Network'
3. Go to the 'Firewall'
4. Click on the reported Firewall rule
5. Click on 'EDIT'
6. Modify Source IP ranges to specific IP
7. Click on 'SAVE'..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-firewall-rules-list' AND json.rule = disabled is false and direction equals INGRESS and (sourceRanges[*] equals ::0 or sourceRanges[*] equals 0.0.0.0 or sourceRanges[*] equals 0.0.0.0/0 or sourceRanges[*] equals ::/0 or sourceRanges[*] equals ::) and allowed[?any(ports contains _Port.inRange(23,23) or (ports does not exist and (IPProtocol contains tcp or IPProtocol contains udp)))] exists```
AWS ECR Repository not configured with a lifecycle policy
This policy identifies AWS ECR Repositories that are not configured with a lifecycle policy. Amazon ECR lifecycle policies enable you to specify the lifecycle management of images in a repository. This helps to automate the cleanup of unused images and the expiration of images based on age or count. As best practice, it is recommended to configure ECR repository with lifecycle policy which helps to avoid unintentionally using outdated images in your repository.

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 AWS ECR Repository with a lifecycle policy follow the steps mentioned in below URL:

https://docs.aws.amazon.com/AmazonECR/latest/userguide/lpp_creation.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ecr-get-repository-policy' AND json.rule = lifecyclePolicy does not exist```
vv15_2

This is applicable to aws 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 api.name = 'aws-ec2-describe-instances' AND json.rule = clientToken is not empty AND monitoring.state contains "running"```
OCI Oracle Analytics Cloud (OAC) access is not restricted to allowed sources or deployed within a Virtual Cloud Network
This policy identifies Oracle Analytics Cloud (OAC) instances that are not restricted to specific sources or not deployed within a Virtual Cloud Network (VCN). 

OAC is a scalable service for enterprise analytics, and restricting its access to corporate IP addresses or VCNs enhances security by reducing exposure to unauthorized access. Deploying OAC instances within a VCN and implementing access control rules is essential for protecting sensitive data. This ensures that only authorized sources can connect to OAC, mitigating risks and maintaining data integrity.

As best practice, it is recommended to have new OAC instances deployed within a VCN, and existing instances should have access control rules configured to allow only approved sources.
This is applicable to oci 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: To configure the OCI Oracle Analytics Cloud (OAC) access, refer to the following documentation:
https://docs.oracle.com/en-us/iaas/analytics-cloud/doc/manage-service-access-and-security.html#ACOCI-GUID-08739F8B-13EC-4194-8EEF-58664F2C1178.

Query:
```config from cloud.resource where api.name = 'oci-analytics-instance' AND json.rule = lifecycleState equal ignore case ACTIVE AND networkEndpointDetails.networkEndpointType equal ignore case PUBLIC AND (networkEndpointDetails.whitelistedServices is empty AND networkEndpointDetails.whitelistedIps is empty AND networkEndpointDetails.whitelistedVcns is empty)```
GCP SQL Instance not encrypted with CMEK
This policy identifies GCP SQL Instances that are not encrypted with Customer Managed Encryption Keys (CMEK).

Using CMEK for SQL Instances provides greater control over data at rest encryption by allowing key rotation and revocation, which enhances security and helps meet compliance requirements. Encrypting SQL Instances with CMEK ensures better data privacy management.

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

To create a new SQL Instance with CMEK, please follow the steps below:
1. Login to the GCP console
2. Navigate to the 'SQL' service
3. Click 'CREATE INSTANCE'
4. Select the database engine
5. Under 'Customize your instance', expand 'SHOW CONFIGURATION OPTIONS'
6. Expand 'STORAGE'
7. Expand 'ADVANCED ENCRYPTION OPTIONS'
8. Select 'Cloud KMS key'
9. Select the appropriate 'Key type' and then select the required CMEK
10. Configure the rest of the SQL instance as required
11. Click 'CREATE INSTANCE' at the bottom of the page.

Query:
```config from cloud.resource where cloud.type = 'gcp' and api.name = 'gcloud-sql-instances-list' AND json.rule = state equals "RUNNABLE" and diskEncryptionConfiguration.kmsKeyName does not exist```
AWS S3 bucket has global view ACL permissions enabled
This policy determines if any S3 bucket(s) has Global View ACL permissions enabled for the All Users group. These permissions allow external resources to see the permission settings associated to the object.
This is applicable to aws 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: 1. Go to the AWS console S3 dashboard.
2. Select your bucket by clicking on the bucket name.
3. Select the Permissions tab and 'Access Control List.'
4. Under Public Access, select Everyone.
5. In the popup window, under Access to this bucket's ACL, uncheck 'Read bucket permissions' and Save..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = "acl.grantsAsList[?(@.grantee=='AllUsers')].permission contains ReadAcp or acl.grantsAsList[?(@.grantee=='AllUsers')].permission contains FullControl"```
AWS RDS instance not in private subnet
This policy identifies AWS RDS instance which are not in a private subnet. RDS should not be deployed in a public subnet, production databases should be located behind a DMZ in a private subnet with limited access in most scenarios.
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 resolve this alert, you should redeploy RDS into a private RDS Subnet group.

Note: You can not move an existing RDS instance from one subnet to another.

Create a RDS Subnet group:

A DB subnet group is a collection of subnets (typically private) that you create for a VPC and that you then designate for your DB instances.

1. Open the Amazon RDS console
2. In the navigation pane, choose 'Subnet groups'
3. Choose 'Create DB Subnet Group'
4. Type the 'Name' of your DB subnet group
5. Add a 'Description' for your DB subnet group
6. Choose your 'VPC'
7. Choose 'Availability Zones'
8. In the Add subnets section, add your Private subnets related to this VPC
9. Choose Create

When creating your RDS DB, under Configure advanced settings, choose the Subnet group created above..

Query:
```config from cloud.resource where api.name = 'aws-rds-describe-db-instances' as X; config from cloud.resource where api.name = 'aws-ec2-describe-route-tables' AND json.rule = associations[*].subnetId exists and routes[?any( state equals active and gatewayId starts with igw- and (destinationCidrBlock equals "0.0.0.0/0" or destinationIpv6CidrBlock equals "::/0"))] exists as Y; filter '$.X.dbsubnetGroup.subnets[*].subnetIdentifier intersects $.Y.associations[*].subnetId'; show X;```
AWS ElastiCache Redis cluster is not configured with automatic backup
This policy identifies Amazon ElastiCache Redis clusters where automatic backup is disabled by checking if SnapshotRetentionLimit is less than 1.

Amazon ElastiCache for Redis clusters can back up their data. Automatic backups in ElastiCache Redis clusters ensure data durability and enable point-in-time recovery, protecting against data loss or corruption. Without backups, data loss from breaches or corruption could be irreversible, compromising data integrity and availability.

It is recommended to enable automatic backups to adhere to compliance requirements and enhance security measures, ensuring data integrity and resilience against potential threats.
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 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 ElastiCache Dashboard
4. Click on 'Redis caches' under the 'Resources' section
5. Select reported Redis cluster
6. Click on 'Modify' button
7. In the 'Modify Cluster' dialog box, Under the 'Backup' section 
a. Select 'Enable automatic backups'
b. Select the 'Backup node ID' that is used as the daily backup source for the cluster
c. Select the 'Backup retention period' number of days according to your buissness requirements for which automated backups are retained before they're automatically deleted
d. select the 'Backup start time' and 'Backup duration' according to your requirements

8. Click on 'Preview Changes'
9. Select Yes checkbox under 'Apply Immediately' , to apply the configuration changes immediately. If Apply Immediately is not selected, the changes will be processed during the next maintenance window.
10. Click on 'Modify'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elasticache-describe-replication-groups' AND json.rule = status equal ignore case "available" and snapshotRetentionLimit does not exist or snapshotRetentionLimit < 1```
AWS Elastic Load Balancer v2 (ELBv2) SSL negotiation policy configured with weak ciphers
This policy identifies Elastic Load Balancers v2 (ELBv2) which are configured with SSL negotiation policy containing weak ciphers. An SSL cipher is an encryption algorithm that uses encryption keys to create a coded message. SSL protocols use several SSL ciphers to encrypt data over the Internet. As many of the other ciphers are not secure/weak, it is recommended to use only the ciphers recommended in the following AWS link: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.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: 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. Go to the EC2 Dashboard, and select 'Load Balancers'
4. Click on the reported Load Balancer
5. On the 'Listeners' tab, Choose the 'HTTPS' or 'SSL' rule; Click on 'Edit', Change 'Security policy' to other than 'ELBSecurityPolicy-TLS-1-0-2015-04' as it contains DES-CBC3-SHA cipher, which is a weak cipher.
6. Click on 'Update' to save your changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elbv2-describe-load-balancers' AND json.rule = listeners[?any(sslPolicy contains ELBSecurityPolicy-TLS-1-0-2015-04)] exists```
liron's policy #4

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 api.name = 'azure-mysql-server' AND json.rule = properties.sslEnforcement equals Enabled and properties.minimalTlsVersion does not equal TLS1_2```
AWS Kinesis streams encryption using default KMS keys instead of Customer's Managed Master Keys
This policy identifies the AWS Kinesis streams which are encrypted with default KMS keys and not with Master Keys managed by Customer. It is a best practice to use customer managed Master Keys to encrypt your Amazon Kinesis streams data. It gives you full control over the encrypted 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: 1. Sign in to the AWS Console
2. Go to Kinesis Service
3. Select the reported Kinesis data stream for the corresponding region
4. Under Server-side encryption, Click on Edit
5. Choose Enabled
6. Under KMS master key, You can choose any KMS other than the default (Default) aws/kinesis
7. Click Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-kinesis-list-streams' as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' as Y; filter '$.Y.keyMetadata.keyManager == AWS and $.Y.key.keyArn == $.X.keyId and $.X.encryptionType equals KMS'; show X;```
GCP Kubernetes Engine Clusters have Cloud Logging disabled
This policy identifies Kubernetes Engine Clusters which have disabled Cloud Logging. Enabling Cloud Logging will let the Kubernetes Engine to collect, process, and store your container and system logs in a dedicated persistent data store.
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. Login to GCP Portal
2. Go to 'Kubernetes Engine' (Left Panel)
3. Select 'Clusters'
4. From the list of clusters, click on the reported cluster
5. Under 'Features', click on the edit button (pencil icon) in front of 'Cloud Logging'
6. In the 'Edit Cloud Logging' dialog, enable the 'Enable Cloud Logging' checkbox
7. Select components to be logged
8. Click on 'Save Changes'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = 'loggingService does not exist or loggingService equals none'```
GCP BigQuery Table not encrypted with CMEK
This policy identifies GCP BigQuery tables that are not encrypted with Customer Managed Encryption Keys (CMEK).

CMEK for BigQuery tables provides control over the encryption of data at rest. Encrypting BigQuery tables 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 BigQuery table 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: To configure a Customer-managed encryption key (CMEK) for BigQuery Table, use following command for "bq" utility
bq cp -f --destination_kms_key <CMEK> <DATASET_ID.TABLE_ID DATASET_ID.TABLE_ID>

Please refer to URL mentioned below for more details on how to change table from default encryption to CMEK encryption:
https://cloud.google.com/bigquery/docs/customer-managed-encryption#change_to_kms

Please refer to URL mentioned below for more details on the bq update command:
https://cloud.google.com/bigquery/docs/reference/bq-cli-reference#bq_cp.

Query:
```config from cloud.resource where api.name = 'gcloud-bigquery-table' AND json.rule = encryptionConfiguration.kmsKeyName does not exist```
Azure SQL server Transparent Data Encryption (TDE) encryption disabled
This policy identifies SQL servers in which Transparent Data Encryption (TDE) is disabled. TDE encryption performs real-time encryption and decryption of the server, related reinforcements, and exchange log records without requiring any changes to the application. It is recommended to have TDE encryption on your SQL servers to protect the server from malicious activity.
This is applicable to azure cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: 1. Log in to the Azure Portal
2. Select 'SQL servers'
3. Select the reported SQL server instance you want to modify
4. Select 'Transparent data encryption' under 'Security'
5. Select 'Select a key'
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-sql-server-list' AND json.rule = ['sqlServer'].['properties.state'] equal ignore case Ready and sqlEncryptionProtectors[*].kind does not exist```
Alibaba Cloud Security group allow internet traffic to FTP port (21)
This policy identifies Security groups that allow inbound traffic on FTP port (21) 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 21, 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(21,21)"```
AWS Kinesis streams are not encrypted using Server Side Encryption
This Policy identifies the AWS Kinesis streams which are not encrypted using Server Side Encryption. Server Side Encryption is used to encrypt your sensitive data before it is written to the Kinesis stream storage layer and decrypted after it is retrieved from storage.
This is applicable to aws 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. Sign in to the AWS Console
2. Go to Kinesis Service
3. Select the reported Kinesis data stream for the corresponding region
4. Under Server-side encryption, Click on Edit
5. Choose Enabled
6. Under KMS master key, You can choose any KMS other than the default (Default) aws/kinesis
7. Click Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-kinesis-list-streams' AND json.rule = 'encryptionType equals NONE or encryptionType does not exist'```
AWS EC2 instance is assigned with public IP
This policy identifies the AWS EC2 instance having a public IP address assigned.

AWS EC2 instances with public IPs are virtual servers hosted in the Amazon Web Services (AWS) cloud that can be accessed over the internet. Public IPs increase an EC2 instance's attack surface, necessitating robust security configurations to prevent unauthorized access and attacks.

It is recommended to use private IPv4 addresses for communication between EC2 instances and disassociate the public IP address from an instance or disable auto-assign public IP addresses in the subnet.
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: In a default VPC, instances get a public IP address. In a non-default VPC, the subnet configuration determines this.

You can't manually change an automatically-assigned public IP. To control public IP assignment:

To unassign the IP addresses associated with a network interface, follow the instructions here: 

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#managing-network-interface-ip-addresses

Note: If you specify an existing network interface for eth0 (the primary network interface), you can't change its public IP address settings using the auto-assign public IP feature; the subnet settings will take precedence.

Modify the subnet's public IP addressing attribute by following these actions: 

 https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip

If you are using an Elastic IP, the instance is internet-reachable. To disassociate an Elastic IP, follow these actions: 

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-instance-addressing-eips-associating-different.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-instances' AND json.rule = networkInterfaces[*].association.publicIp exists```