knarayan/cloud_posture_checks huggingface dataset:
GCP public-facing (external) regional load balancer using HTTP protocol
This policy identifies GCP public-facing (external) regional load balancers that are using HTTP protocol.

Using the HTTP protocol with a GCP external load balancer transmits data in plaintext, making it vulnerable to eavesdropping, interception, and modification by malicious actors. This lack of encryption exposes sensitive information, increases the risk of man-in-the-middle attacks, and compromises the overall security and privacy of the data exchanged between clients and servers.

It is recommended to use HTTPS protocol with external-facing load balancers.
This is applicable to gcp 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. Login to the GCP console
2. Navigate to 'Network Service' and then 'Load Balancing'
3. Click on the 'FRONTENDS' tab
4. Identify the frontend that is using the reported forwarding rule.
5. Click on the load balancer name associated with the frontend identified above
6. Click 'Edit'
7. Go to 'Frontend configuration'
8. Delete the frontend rule that allows HTTP protocol.
9. Add new frontend rule(s) as required. Make sure to use HTTPS protocol instead of HTTP for new rules.
10. Click 'Update'
11. Click 'UPDATE LOAD BALANCER' in the pop-up..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-regional-forwarding-rule' AND json.rule = target contains "/targetHttpProxies/" and loadBalancingScheme contains "EXTERNAL"```
AWS Application Load Balancer (ALB) not configured with AWS Web Application Firewall v2 (AWS WAFv2)
This policy identifies AWS Application Load Balancers (ALBs) that are not configured with AWS Web Application Firewall v2 (AWS WAFv2). As a best practice, configure the AWS WAFv2 service on the application load balancers to protect against application-layer attacks. To block malicious requests to your application load balancers, define the block criteria in the WAFv2 web access control list (web ACL).
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. Make sure your the reported Application Load Balancer requires WAF based on your requirement and Note down the load balancer name.
3. Navigate to WAF & Shield dashboard
4. Click on Web ACLs, under AWS WAF section from left panel
5. If Web ACL is not created; create a new Web ACL and add reported Application Load Balancer to Associated AWS resources.
6. If you have Web ACL already created; Click on Web ACL and add your reported Application Load Balancer to Associated AWS resources..

Query:
```config from cloud.resource where api.name = 'aws-waf-v2-web-acl-resource' AND json.rule = resources.applicationLoadBalancer[*] exists as X; config from cloud.resource where api.name = 'aws-elbv2-describe-load-balancers' AND json.rule = scheme equals internet-facing and type equals application as Y; filter 'not($.X.resources.applicationLoadBalancer[*] contains $.Y.loadBalancerArn)'; show Y;```
Azure Network Security Group allows all traffic on PostgreSQL (TCP Port 5432)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on PostgreSQL (TCP Port 5432). Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict PostgreSQL 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 Tcp or protocol equals *) and (destinationPortRange contains _Port.inRange(5432,5432) or destinationPortRanges[*] contains _Port.inRange(5432,5432) ))] exists```
GCP VM instances have IP Forwarding enabled
This policy identifies VM instances that have IP Forwarding enabled. IP Forwarding could open unintended and undesirable communication paths and allows VM instances to send and receive packets with the non-matching destination or source IPs. To enable the source and destination IP match check, disable IP Forwarding.
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: GCP VM instances IP forwarding feature cannot be updated. After an instance is created, the IP forwarding field becomes read-only. So to fix this alert, Create a new VM instance with IP forwarding disabled, migrate all required data from reported VM to newly created and delete the VM instance reported.

To create a new VM Instance with IP forwarding disabled:
1. Login to GCP Portal
2. Go to Computer Engine (Left Panel)
3. Go to VM instances
4. Click the CREATE INSTANCE button
5. Specify other instance parameters as you desire
6. Click Management, disk, networking, SSH keys
7. Click Networking
8. Click on the specific Network interfaces
9. Set IP forwarding to Off
10. Click on Done
11. Click on Create button

To Delete VM instance which has IP forwarding enabled:
1. Login to GCP Portal
2. Go to Computer Engine (Left Panel)
3. Go to VM instances
4. From the list of VMs, choose the reported VM
5. Click on Delete button.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-instances-list' AND json.rule = status equals RUNNING and canIpForward is true and name does not start with "gke-"```
GCP Log Entries without sinks configured

This is applicable to gcp 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 api.name = 'gcloud-logging-sinks-list' AND json.rule = "filter exists" as X; count(X) less than 1```
Alibaba Cloud RAM password policy does not have a number
This policy identifies Alibaba Cloud accounts that do not have a number in the password policy. As a security best practice, configure a strong password policy for secure access to the Alibaba Cloud console.
This is applicable to alibaba_cloud cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['WEAK_PASSWORD'].
Mitigation of this issue can be done as follows: 1. Log in to Alibaba Cloud Portal
2. Go to Resource Access Management (RAM) service
3. In the left-side navigation pane, click on 'Settings'
4. In the 'Security Settings' tab, In the 'Password Strength Settings' Section, Click on 'Edit Password Rule'
5. In the 'Required Elements in Password' field, select 'Numbers'
6. Click on 'OK'
7. Click on 'Close'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ram-password-policy' AND json.rule =  'requireNumbers does not exist or requireNumbers is false'```
Azure Machine learning workspace is not configured with private endpoint
This policy identifies Azure Machine learning workspaces that are not configured with private endpoint. Private endpoints in workspace resources allow clients on a virtual network to securely access data over Azure Private Link. Configuring a private endpoint enables access to traffic coming from only known networks and prevents access from malicious or unknown IP addresses which includes IP addresses within Azure. It is recommended to create private endpoint for secure communication for your Machine learning workspaces.
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. Login to Azure portal
2. Navigate to 'Azure Machine Learning' dashboard
3. Click on the reported Azure Machine learning workspace
4. Configure Private endpoint connections under 'Networking' from left panel.

For information refer:
https://learn.microsoft.com/en-us/azure/machine-learning/how-to-configure-private-link.

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.privateEndpointConnections[*] does not exist or properties.privateEndpointConnections[*] is empty or (properties.privateEndpointConnections[*] exists and properties.privateEndpointConnections[*].properties.privateLinkServiceConnectionState.status does not equal ignore case Approved))```
Azure Data Factory (V2) is not configured with managed identity
This policy identifies Data Factories (V2) that are not configured with managed identity. Managed identity can be used to authenticate to any service that supports Azure AD authentication, without having credentials in your code. Storing credentials in a code increases the threat surface in case of exploitation and also managed identities eliminate the need for developers to manage credentials. So as a security best practice, it is recommended to have the managed identity to your Data Factory.
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. Login to Azure portal.
2. Navigate to 'Data factories'
3. Click on the reported Data factory
4. Select 'Managed identities' under 'Settings' from left panel 
5. Configure either 'System assigned' or 'User assigned' identity
For more on Data factories managed identities refer https://docs.microsoft.com/en-gb/azure/data-factory/data-factory-service-identity?tabs=data-factory
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-data-factory-v2' AND json.rule = properties.provisioningState equal ignore case Succeeded and identity does not exist or identity.type equal ignore case "None"```
gfssrguptn_ui_auto_policies_tests_name
njfeujtwmv_ui_auto_policies_tests_descr
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-iam-list-users' AND json.rule = createDate contains 2018```
AWS CloudTrail S3 bucket encrypted with Customer Managed Key (CMK) that is scheduled for deletion
This policy identifies AWS CloudTrail S3 buckets encrypted with Customer Managed Key (CMK) that is scheduled for deletion.

CloudTrail logs contain account activity related to actions across your AWS infrastructure. These log files stored in Amazon S3 are encrypted by AWS KMS keys. Deleting keys in AWS KMS that are used by CloudTrail is a common defense evasion technique and could be a potential ransomware attacker activity. After a key is deleted, you can no longer decrypt the data that was encrypted under that key, which helps the attacker to hide their malicious activities.

It is recommended to regularly monitor the key used for encryption to prevent accidental deletion.
This is applicable to aws cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: The following steps are recommended to cancel KMS CMKs which are scheduled for deletion used by the S3 bucket

1. Log in to the AWS Console and navigate to the 'S3' service.
2. Click on the S3 bucket reported in the alert.
3. Click on the 'Properties' tab.
4. Under the 'Default encryption' section, click on the KMS key link in 'Encryption key ARN'.
5. Navigate to Key Management Service (KMS).
6. Click on 'Key actions' dropdown.
7. Click on 'Cancel key deletion'.
8. Click on 'Enable'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name= 'aws-s3api-get-bucket-acl' AND json.rule = (sseAlgorithm contains "aws:kms" or sseAlgorithm contains "aws:kms:dsse") and kmsMasterKeyID exists as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' AND json.rule = keyMetadata.keyManager equal ignore case CUSTOMER and keyMetadata.keyState contains PendingDeletion as Y; config from cloud.resource where api.name = 'aws-cloudtrail-describe-trails' as Z; filter '$.X.kmsMasterKeyID contains $.Y.key.keyArn and $.Z.s3BucketName equals $.X.bucketName'; show X;```
AWS CloudFront distribution is using insecure SSL protocols for HTTPS communication
CloudFront, a content delivery network (CDN) offered by AWS, is not using a secure cipher for distribution. It is a best security practice to enforce the use of secure ciphers TLSv1.0, TLSv1.1, and/or TLSv1.2 in a CloudFront Distribution's certificate configuration. This policy scans for any deviations from this practice and returns the results.
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: Communication between CloudFront and your Custom Origin should enforce the use of secure ciphers. Modify the CloudFront Origin's Origin SSL Protocol to include TLSv1.0, TLSv1.1, and/or TLSv1.2.

1. Go to the AWS console CloudFront dashboard.
2. Select your distribution Id.
3. Select the 'Origins' tab.
4. Check the origin you want to modify then select Edit.
5. Remove (uncheck) 'SSLv3' from Origin SSL Protocols.
6. Select 'Yes, Edit.'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = (origins.items[*] contains "customOriginConfig") and (origins.items[?(@.customOriginConfig.originSslProtocols.items)] contains "SSLv3")```
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```
Azure Batch Account configured with overly permissive network access
This policy identifies Batch Accounts configured with overly permissive network access. By default, Batch accounts are accessible from all the networks. With an Account access IP firewall, you can restrict it further to only a set of IPv4 addresses or IPv4 address ranges. With Private access Virtual Networks, the network traffic path is secured on both ends. It is recommended to configure the Batch account with an IP firewall or by Virtual Network, so that the Batch account is accessible only to restricted entities.
This is applicable to azure cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To configure private access private endpoint, follow below URL:
https://docs.microsoft.com/en-gb/azure/batch/private-connectivity#azure-portal

To disable public network, follow below URL:
https://docs.microsoft.com/en-gb/azure/batch/public-network-access#disable-public-network-access

If Batch account is intended access from public network, restrict it to specific IP ranges. To allow public network access with specific network rules, follow below URL:
https://docs.microsoft.com/en-gb/azure/batch/public-network-access#access-from-selected-public-networks.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-batch-account' AND json.rule = properties.provisioningState equal ignore case Succeeded and properties.networkProfile.accountAccess.defaultAction equal ignore case Allow and properties.publicNetworkAccess equal ignore case Enabled```
IBM Cloud Application Load Balancer for VPC not configured with HTTPS Listeners
This policy identifies IBM Cloud Application Load Balancers for VPC that has different listener protocol instead of HTTPS. HTTPS listeners uses TLS(SSL) to encrypt normal HTTP requests and responses. It is highly recommended to use application load balancers with HTTPS listeners for additional security.
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 'Load balancers'
3. Select the 'Load balancers' reported in the alert
4. Under 'Front-end listeners' tab, click on three dots on the right corner of a row containing listener with protocol other than HTTPS. Then click on 'Edit'.
5. If the protocol is 'TCP', please delete the listener by clicking on three dots on the right corner. Then click on 'Delete'.
6. Click on 'Create listener'.
7. In the 'Edit front-end listener' screen, select 'HTTPS' from the 'Protocol' dropdown.
8. Under 'Secrets Manager' please select an instance and select an SSL 'Certificate'. Make sure that the load balancer is authorised to access the SSL certificate.
9. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-loadbalancer' AND json.rule = listeners[?any( protocol does not equal ignore case https AND https_redirect does not exist )] exists```
Alibaba Cloud ApsaraDB RDS instance is using the default VPC
This policy identifies ApsaraDB RDS instances which are configured with the default VPC. It is recommended to use a VPC configuration based on your security and networking requirements. You should create your own RDS instance VPC instead of using the default so that you can have full control over the RDS 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: NOTE: The VPC switching process will interrupt the availability of your instance for 30 seconds. Make sure that your application is configured with automatic reconnection policies.

1. Log in to Alibaba Cloud Portal
2. Go to ApsaraDB for RDS
3. In the left navigation pane, click on 'Instances'
4. Click on the reported instance
5. In the left navigation pane, click on 'Database Connection'
6. In the 'Database Connection' section, click on 'Switch VSwitch'
7. On the 'Switch VSwitch' popup window, Choose custom VPC and Virtual Switch instead of default VPC from the 'Switch To' dropdown list.
8. Click on OK
9. Read the Notes properly and make sure all necessary actions are taken and then Click on 'Switch'.

Query:
```config from cloud.resource where api.name = 'alibaba-cloud-rds-instance' as X; config from cloud.resource where api.name = 'alibaba-cloud-vpc' as Y; filter '$.X.vpcId equals $.Y.vpcId and $.Y.isDefault is true'; show X;```
Azure Log analytics linked storage account is not configured with CMK encryption
This policy identifies Azure Log analytics linked Storage accounts which are not encrypted with CMK. By default Azure Storage account is encrypted using Microsoft Managed Keys. It is recommended to use Customer Managed Keys to encrypt data in Azure Storage accounts linked Log analytics for better control on the data.
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: To configure encryption using CMK for existing Azure Log analytics linked storage account, follow below URL:
https://learn.microsoft.com/en-us/azure/azure-monitor/logs/private-storage#customer-managed-key-data-encryption.

Query:
```config from cloud.resource where api.name = 'azure-storage-account-list' AND json.rule = properties.encryption.keySource does not equal ignore case "Microsoft.Keyvault" as X; config from cloud.resource where api.name = 'azure-log-analytics-linked-storage-accounts' AND json.rule = properties.dataSourceType equal ignore case Query as Y; filter '$.X.id contains $.Y.properties.storageAccountIds'; show X;```