knarayan/cloud_posture_checks huggingface dataset:
GCP PostgreSQL instance database flag log_min_error_statement is not set
This policy identifies PostgreSQL database instances in which database flag log_min_error_statement is not set. The log_min_error_statement flag defines the minimum message severity level that are considered as an error statement. Messages for error statements are logged with the SQL statement. Valid values include DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC. Each severity level includes the subsequent levels. log_min_error_statement flag value changes should only be made in accordance with the organization's logging policy. Proper auditing can help in troubleshooting operational problems and also permits forensic analysis.
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: It is recommended to set the 'log_min_error_statement' flag for PostgreSQL database as per your organization's logging policy.

To update the databse flag of GCP PostgreSQL instance, please refer to the URL given below and set log_min_error_statement flag as needed:
https://cloud.google.com/sql/docs/postgres/flags#set_a_database_flag.

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_min_error_statement')] does not exist"```
Azure Service Fabric cluster not configured with cluster protection level security
This policy identifies Service Fabric clusters that are not configured with cluster protection level security. Service Fabric provides levels of protection for node-to-node communication using a primary cluster certificate. It is recommended to set the protection level to ensure that all node-to-node messages are encrypted and digitally signed.
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 'Service Fabric cluster'
3. Click on the reported Service Fabric cluster
4. Select 'Custom fabric settings' under 'Settings' from left panel 
5. Make sure a fabric settings in 'Security' section exist with 'ClusterProtectionLevel' property is set to 'EncryptAndSign'.

Note: Service Fabric provides three levels of protection (None, Sign and EncryptAndSign) for node-to-node communication using a primary cluster certificate. Set the protection level to ensure that all node-to-node messages are encrypted and digitally signed..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-service-fabric-cluster' AND json.rule = properties.provisioningState equal ignore case Succeeded and ((properties.fabricSettings[*].name does not equal ignore case "Security" or properties.fabricSettings[*].parameters[*].name does not equal ignore case "ClusterProtectionLevel") or (properties.fabricSettings[?any(name equal ignore case "Security" and parameters[?any(name equal ignore case "ClusterProtectionLevel" and value equal ignore case "None")] exists )] exists))```
Azure AKS cluster configured with overly permissive API server access
This policy identifies AKS clusters configured with overly permissive API server access. In Kubernetes, the API server receives requests to perform actions in the cluster such as to create resources or scale the number of nodes. To enhance cluster security and minimize attacks, the API server should only be accessible from a limited set of IP address ranges. These IP ranges allow defined IP address ranges to communicate with the API server. A request made to the API server from an IP address that is not part of these authorized IP ranges is blocked. It is recommended to configure AKS cluster with defined IP address ranges to communicate with the API server.
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 AKS cluster with defined IP address ranges to communicate with the API server; refer below URL:
https://docs.microsoft.com/en-us/azure/aks/api-server-authorized-ip-ranges#update-disable-and-find-authorized-ip-ranges-using-azure-portal.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-kubernetes-cluster' AND json.rule = properties.powerState.code equal ignore case Running and properties.apiServerAccessProfile.enablePrivateCluster is false and (properties.apiServerAccessProfile.authorizedIPRanges does not exist or properties.apiServerAccessProfile.authorizedIPRanges is empty)```
GCP SQL Instance with public IP address does not have authorized network configured
This policy identifies GCP Cloud SQL instances with public IP addresses that do not have an authorized network configured.

SQL instance can be connected securely by making use of the Cloud SQL Proxy or by adding the client's public addresses as an authorized network to the SQL instance. If the client application is connecting directly to a Cloud SQL instance on its public IP address, the client's external IP address needs to be added as an Authorized network to allow the secure connection.

It is recommended to add authorized networks for your SQL instance to minimize the access vector.
This is applicable to gcp 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: If public IP is not needed for the SQL instance, it is recommeded to remove the Public IP from the instance. Any changes to the public IP should be made according to the organization needs and policies.

To remove the public IP for from a SQL instance, please refer to the URLs given below:
For MySQL: https://cloud.google.com/sql/docs/mysql/configure-ip#disable-public
For PostgreSQL: https://cloud.google.com/sql/docs/postgres/configure-ip#disable-public
For SQL Server: https://cloud.google.com/sql/docs/sqlserver/configure-ip#disable-public

If it is deemed that instance needs public IP, it is recommended to add restrictive Authorized Networks to limit allowed public connections to the instance.

To configure authorized networks for a SQL instance, please refer to the URLs given below:
For MySQL: https://cloud.google.com/sql/docs/mysql/authorize-networks
For PostgreSQL: https://cloud.google.com/sql/docs/postgres/authorize-networks
For SQL Server: https://cloud.google.com/sql/docs/sqlserver/authorize-networks.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = state equals "RUNNABLE" and ipAddresses[?any( type equal ignore case "PRIMARY" )] exists and settings.ipConfiguration.authorizedNetworks is empty```
GCP OS Image is publicly accessible
This policy identifies GCP OS Images that are publicly accessible.

Custom GCP OS images are user-created operating system images tailored to specific needs and configurations. Making these images public can expose sensitive data, proprietary software, and security vulnerabilities. This can lead to unauthorized access, data breaches, and system exploitation, compromising your infrastructure's security and integrity.

It is recommended to keep OS images private unless required for organizational needs.
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: It is recommended to review and add appropriate, but restrictive roles before revoking access.

To revoke access from 'allAuthenticatedUsers', follow the below mentioned steps:
1. Login to the GCP console
2. Navigate to 'Compute Engine' and then 'Images'
4. Select the reported image using the check box
5. Click on the 'PERMISSIONS' tab in the right bar
6. Filter for 'allAuthenticatedUsers'
7. Click on the 'Remove principal' button (bin icon)
8. Select 'Remove allAuthenticatedUsers from all roles on this resource. They may still have access via inherited roles.'
9. Click 'Remove'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-image' AND json.rule = iamPolicy.bindings[?any( members contains "allAuthenticatedUsers" )] exists```
Azure PostgreSQL Database Server Firewall rule allow access to all IPV4 address
This policy identifies Azure PostgreSQL Database Server which has Firewall rule that allow access to all IPV4 address. Having a firewall rule with start IP being 0.0.0.0 and end IP being 255.255.255.255 would allow access to SQL server from any host on the internet. It is highly recommended not to use this type of firewall rule in any PostgreSQL Database Server.
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.Click on 'All services' on left Navigation
3.Click on 'Azure Database for PostgreSQL servers' under Databases
4.Click on reported server instance
5.Click on 'Connection security' under Settings
6.Delete the rule which has 'Start IP' as 0.0.0.0 and 'End IP' as 255.255.255.255 under 'Firewall rule name' section
7.Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-postgresql-server' AND json.rule = properties.publicNetworkAccess equal ignore case Enabled and firewallRules.value[?any(properties.startIpAddress equals 0.0.0.0 and properties.endIpAddress equals 255.255.255.255)] exists```
AWS EMR cluster is not enabled with local disk encryption using Custom key provider
This policy identifies AWS EMR clusters that are not enabled with local disk encryption using Custom key provider. Applications using the local file system on each cluster instance for intermediate data throughout workloads, where data could be spilled to disk when it overflows memory. With Local disk encryption at place, data at rest can be protected.
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. Login 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 'EMR' dashboard from 'Services' dropdown.
4. Go to 'Security configurations', click 'Create'.
5. On the Create security configuration window,
6. In 'Name' box, provide a name for the new EMR security configuration.
7. Under 'Local disk encryption', check the box 'Enable at-rest encryption for local disks'.
8. Select 'Custom' Key provider type from the 'Key provider type' dropdown list.
9. Follow the below link for creating the custom key,

https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-data-encryption-options.html
10. Click on 'Create' button.
11. On the left menu of EMR dashboard Click 'Clusters'.
12. Select the EMR cluster for which the alert has been generated and click on the 'Clone' button from the top menu.
13. In the Cloning popup, choose 'Yes' and Click 'Clone'.
14. On the Create Cluster page, in the Security Options section, click on 'security configuration'.
15. From the 'Security configuration' drop down select the name of the security configuration created at step 4 to step 8, click 'Create Cluster'.
16. Once the new cluster is set up verify its working and terminate the source cluster.
17. On the left menu of EMR dashboard Click 'Clusters', from the list of clusters select the source cluster which is alerted.
18. Click on the 'Terminate' button from the top menu.
19. On the 'Terminate clusters' pop-up, click 'Terminate'..

Query:
```config from cloud.resource where api.name = 'aws-emr-describe-cluster' as X; config from cloud.resource where api.name = 'aws-emr-security-configuration' as Y; filter '($.X.status.state does not contain TERMINATING and  $.X.status.state does not contain TERMINATED and $.X.status.state does not contain TERMINATED_WITH_ERRORS) and ($.X.securityConfiguration equals $.Y.name) and ($.Y.EncryptionConfiguration.AtRestEncryptionConfiguration.LocalDiskEncryptionConfiguration exists and $.Y.EncryptionConfiguration.AtRestEncryptionConfiguration.LocalDiskEncryptionConfiguration.EncryptionKeyProviderType does not equal Custom)'; show X;```
IBM Cloud Application Load Balancer for VPC uses HTTP backend pool instead of HTTPS (SSL & TLS)
This policy identifies IBM Cloud Application Load Balancer for VPC, which has been using http backend pools instead of HTTPS. HTTPS pool uses TLS(SSL) to encrypt normal HTTP requests and responses. It is highly recommended to use application load balancers with HTTPS backend pools 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 balancer' reported in the alert
4. Under 'Back-end pools' tab, click on three dots on the right corner of a row containing back-end pool with protocol besides HTTPS.
5. In the 'Edit back-end pool' screen, under 'Protocol' dropdown, select 'HTTPS'.
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-loadbalancer' AND json.rule = profile.family equal ignore case "application" and operating_status equal ignore case "online" and pools[?any( protocol does not equal ignore case "https" )] exists```
AWS S3 Buckets with Object-level logging for read events not enabled

This is applicable to aws 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= 'aws-cloudtrail-describe-trails' AND json.rule = 'isMultiRegionTrail is true and includeGlobalServiceEvents is true' as X; config from cloud.resource where api.name= 'aws-cloudtrail-get-trail-status' AND json.rule = 'status.isLogging equals true' as Y; config from cloud.resource where api.name= 'aws-cloudtrail-get-event-selectors' AND json.rule = eventSelectors[?any( dataResources[?any( type contains "AWS::S3::Object" and values contains "arn:aws:s3")] exists and readWriteType is member of ("All","ReadOnly") and includeManagementEvents is true)] exists as Z; filter '($.X.trailARN equals $.Z.trailARN) and ($.X.name equals $.Y.trail)'; show X; count(X) less than 1```
AWS API Gateway endpoints without client certificate authentication
API Gateway can generate an SSL certificate and use its public key in the backend to verify that HTTP requests to your backend system are from API Gateway. This allows your HTTP backend to control and accept only requests originating from Amazon API Gateway, even if the backend is publicly accessible.

Note: Some backend servers may not support SSL client authentication as API Gateway does and could return an SSL certificate error. For a list of incompatible backend servers, see Known Issues. https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.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: These instructions assume you already completed Generate a Client Certificate Using the API Gateway Console. If not please generate a client certificate by following below steps and then Configure an API to Use SSL Certificates.
Steps to Generate a Client Certificate Using the API Gateway Console:
1. Login to AWS Console
2. Go to API Gateway console
3. In the main navigation pane (Left Panel), choose Client Certificates.
4. From the Client Certificates pane, choose Generate Client Certificate.
5. Optionally, for Edit, choose to add a descriptive title for the generated certificate and choose Save to save the description. API Gateway generates a new certificate and returns the new certificate GUID, along with the PEM-encoded public key.

Steps to Configure an API to Use SSL Certificates:
1. Login to AWS Console
2. Go to API Gateway console
3. In the API Gateway console, create or open an API for which you want to use the client certificate. Make sure the API has been deployed to a stage (Left Panel).
4. Choose Stages under the selected API and then choose a stage (Left Panel).
5. In the Stage Editor panel, select a certificate under the Client Certificate section.
6. Click Save Changes.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-apigateway-get-stages' AND json.rule = 'clientCertificateId does not exist or clientCertificateId equals None'```
IBM Cloud user with IAM policies provide administrative privileges for all Identity and Access enabled services
This policy identifies IBM Cloud Users, where policy with administrator role permission across all Identity and Access enabled services. Users with administrator role on All Identity and Access enabled services can access all services or resources in the account. If a user with administrator privilege becomes compromised, it may result in compromised resources in the account. As a security best practice, granting the least privilege access, such as granting only the permissions required to perform a task, instead of providing excessive permissions is recommended.
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. In the IBM Cloud console, click 'Manage' on the title bar > 'Access (IAM)', click on 'Users' in the left panel.
3. Select the user which is reported and you want to edit access for.
4. Go to 'Access' tab and under the 'Access policies' section> Click on three dots on the right corner of a row for the policy which is having Administrator permission on 'All Identity and Access enabled services' 
5. Click on Remove OR Edit to assign limited permission to the policy.
6. Review the policy details that you're about to Edit/Remove, and confirm by clicking Save/Remove..

Query:
```config from cloud.resource where api.name = 'ibm-iam-policy' AND json.rule = type equal ignore case "access" and roles[?any( role_id contains "crn:v1:bluemix:public:iam::::role:Administrator" )] exists and resources[?any(tags does not exist and attributes[?any( value equal ignore case "service" and name equal ignore case "serviceType" and operator is member of ("stringEquals", "stringMatch"))] exists and attributes[?any( name equal ignore case "region")] does not exist )] exists and subjects[?any( attributes[?any( name contains "iam_id" and value contains "IBMid")] exists )] exists as X;config from cloud.resource where api.name = 'ibm-iam-user' as Y; filter '$.X.subjects[*].attributes[*].value contains $.Y.iam_id'; show Y;```
Alibaba Cloud RAM password policy does not have a symbol
This policy identifies Alibaba Cloud accounts that do not have a symbol 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 informational 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 'Symbols'
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 = 'requireSymbols does not exist or requireSymbols is false'```
GCP API key is created for a project
This policy identifies GCP projects where API keys are created. Keys are insecure because they can be viewed publicly, such as from within a browser, or they can be accessed on a device where the key resides. To avoid the security risk in using API keys, it is recommended to use standard authentication flow instead.

Note: There are limited cases where API keys are more appropriate. For example, if there is a mobile application that needs to use the Google Cloud Translation API, but doesn't otherwise need a backend server, API keys are the simplest way to authenticate to that API. If a business requires API keys to be used, then the API keys should be secured using appropriate IAM policies.
This is applicable to gcp 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: Use of API keys is generally considered as less secure authentication mechanism and should be avoided. A secure authentication mechanism should be used. Follow the below mentioned URL to evaluate an alternate, suitable authentication mechanism:
https://cloud.google.com/endpoints/docs/openapi/authentication-method

To delete an API Key:
1. Log in to google cloud console
2. Navigate to section 'Credentials', under 'APIs & Services'.
3. To delete API Key, go to 'API Keys' section, click the Actions button (three dots) in front of key name.
4. Click on ‘Delete API key’ button.
5. In the 'Delete credential' dialog, click 'DELETE' button.

Note: Deleting API keys might break dependent applications. It is recommended to thoroughly review and evaluate the impact of API key before deletion..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-api-key' as X; count(X) greater than 0```