knarayan/cloud_posture_checks huggingface dataset:
GCP Firewall rule allows all traffic on POP3 port (110)
This policy identifies GCP Firewall rules which allow all inbound traffic on POP3 port (110). Allowing access from arbitrary IP addresses to this port increases the attack surface of your network. It is recommended that the POP3 port (110) 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(110,110) or (ports does not exist and (IPProtocol contains tcp or IPProtocol contains udp)))] exists```
AWS OpenSearch Fine-grained access control is disabled
This policy identifies AWS OpenSearch which has Fine-grained access control disabled. Fine-grained access control offers additional ways of controlling access to your data on AWS OpenSearch Service. It is highly recommended enabling fine-grained access control to protect the data on your domain.

For more information, please follow the URL given below,
https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.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: Refer the following URL for configuring Fine-grained access control on your AWS OpenSearch:
https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html#fgac-forget

Notes: 
1. You can't enable fine-grained access control on existing domains, only new ones. After you enable fine-grained access control, you can't disable it.
2. Fine-grained access control is supported only from ElasticSearch 6.7 or later. To upgrade older versions of AWS OpenSearch please refer to the URL given below,
https://docs.aws.amazon.com/opensearch-service/latest/developerguide/version-migration.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-es-describe-elasticsearch-domain' AND json.rule = advancedSecurityOptions.enabled is false and advancedSecurityOptions.internalUserDatabaseEnabled is false```
Azure Cognitive Services account not configured with private endpoint
This policy identifies Azure Cognitive Services accounts that are not configured with private endpoint. Private endpoints in Azure AI service 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 Cognitive Services account.
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 AI services'
3. Click on the reported Azure AI service
4. Configure Private endpoint connections under 'Networking' from left panel.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cognitive-services-account' AND json.rule = properties.provisioningState equal ignore case Succeeded and properties.privateEndpointConnections[*] is empty```
AWS API Gateway REST API execution logging disabled
This policy identifies AWS API Gateway REST API's that have disabled execution logging in their stages.

AWS API Gateway REST API is a service for creating and managing RESTful APIs integrated with backend services like Lambda and HTTP endpoints. Execution logs log all the API activity logs to CloudWatch, which helps in incident response, security and compliance, troubleshooting, and monitoring.

It is recommended to enable logging on the API Gateway REST API to track API activity.
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 enable execution logging on API Gateway Rest API, follow the below steps:

1. Sign in to the AWS console. Navigate to the API Gateway dashboard
2. Under the navigation page, select the 'APIs'
3. Select the REST API reported; under the navigation page, select 'Stages'
4. Select a stage and click on 'Edit' under the 'Logs and tracing' section
5. Under the 'Edit logs and tracing' page, select a value other than 'Off' under the 'CloudWatch logs' dropdown.
6. Click on 'Save'.
7. Repeat this process for all the stages of the reported REST API..

Query:
```config from cloud.resource where api.name = 'aws-apigateway-get-stages' AND json.rule = methodSettings.[*].loggingLevel does not exist or methodSettings.[*].loggingLevel equal ignore case off as X; config from cloud.resource where api.name = 'aws-apigateway-get-rest-apis' as Y; filter ' $.X.restApi equal ignore case $.Y.id '; show Y;```
AWS Elastic Load Balancer v2 (ELBv2) with access log disabled
This policy identifies Elastic Load Balancers v2 (ELBv2) which have access log disabled. Access logs capture detailed information about requests sent to your load balancer and each log contains information such as the time the request was received, the client's IP address, latencies, request paths, and server responses. You can use these access logs to analyze traffic patterns and troubleshoot issues.
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 EC2 dashboard
4. Click on 'Load Balancers' (Left Panel)
5. Select the reported ELB
6. Click on 'Actions' drop-down
7. Click on 'Edit attributes'
8. In the 'Edit load balancer attributes' popup box, Choose 'Enable' for 'Access logs' and configure S3 location where you want to store ELB logs.
9. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elbv2-describe-load-balancers' AND json.rule = "state.code contains active and ['attributes'].['access_logs.s3.enabled'] contains false"```
AWS MFA not enabled for IAM users
This policy identifies AWS IAM users for whom MFA is not enabled. AWS Multi-Factor Authentication (MFA) is a simple best practice that adds an extra layer of protection on top of your user name and password. Multiple factors provide increased security for your AWS account settings and resources.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MFA'].
Mitigation of this issue can be done as follows: 1. Sign in to the AWS and navigate to the 'IAM' service.
2. Navigate to the user that was reported in the alert.
3. Under 'Security Credentials', check "Assigned MFA Device" and follow the instructions to enable MFA for the user..

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name='aws-iam-get-credential-report' AND json.rule='user does not equal "<root_account>" and password_enabled equals true and mfa_active is false'```
GCP Firewall rule allows all traffic on Oracle DB port (1521)
This policy identifies GCP Firewall rules which allow all inbound traffic on DB port (1521). Allowing access from arbitrary IP addresses to this port increases the attack surface of your network. It is recommended that the DB port (1521) 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(1521,1521) or (ports does not exist and (IPProtocol contains tcp or IPProtocol contains udp)))] exists```
GCP Kubernetes Engine Clusters have Legacy Authorization enabled
This policy identifies GCP Kubernetes Engine Clusters which have enabled legacy authorizer. The legacy authorizer in Kubernetes Engine grants broad and statically defined permissions to all cluster users. After legacy authorizer setting is disabled, RBAC can limit permissions for authorized users based on need.
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 Kubernetes clusters
4. From the list of clusters, choose the reported cluster
5. Under 'Security', click on edit button (Pencil Icon) for Legacy authorization
6. Uncheck 'Enable legacy authorization' checkbox
7. Click on Save Changes.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = 'legacyAbac.enabled equals true'```
AWS CloudFront distributions does not have a default root object configured
This policy identifies list of CloudFront distributions which does not have default root object configured. If a CloudFront distribution does not have a default root object configured, requests for the root of your distribution pass to your origin server which might return a list of the private contents of your origin. To avoid exposing the contents of your distribution or returning an error it is recommended to specify a default root object.
This is applicable to aws 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: To configure a default root object for your distribution  follow the steps mentioned in below URL:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DefaultRootObject.html#DefaultRootObjectHowToDefine.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = defaultRootObject is empty```
Azure SQL Server ADS Vulnerability Assessment Periodic recurring scans is disabled
This policy identifies Azure SQL Server which has ADS Vulnerability Assessment Periodic recurring scans disabled. Advanced Data Security - Vulnerability Assessment 'Periodic recurring scans' schedules periodic vulnerability scanning for the SQL server and Databases. It is recommended to enable ADS - VA Periodic recurring scans which provides risk visibility based on updated known vulnerability signatures and best practices.
This is applicable to azure cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to the Azure portal
2. Select 'SQL servers', and select the SQL server you need to modify
3. Click on 'Microsoft Defender for Cloud' under 'Security'
4. Click on '(Configure)' next to 'Microsoft Defender for SQL: Enabled at the server-level'
5. Set 'Periodic recurring scans' to 'ON' under 'VULNERABILITY ASSESSMENT SETTINGS'
6. 'Save' your changes.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-sql-server-list' AND json.rule = vulnerabilityAssessments[*].properties.storageContainerPath exists and vulnerabilityAssessments[*].properties.recurringScans.isEnabled is false```
cloneAWS CloudFront attached WAFv2 WebACL is not configured with AMR for Log4j Vulnerability
This policy identifies AWS CloudFront attached with WAFv2 WebACL which is not configured with AWS Managed Rules (AMR) for Log4j Vulnerability. As per the guidelines given by AWS, CloudFront attached with WAFv2 WebACL should be configured with AWS Managed Rules (AMR) AWSManagedRulesKnownBadInputsRuleSet and AWSManagedRulesAnonymousIpList to protect from Log4j Vulnerability (CVE-2021-44228).

For more information please refer below URL,
https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
This is applicable to aws 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. Sign in to the AWS console
2. Go to the CloudFront Distributions Dashboard
3. Click on the reported web distribution
4. On 'General' tab, Click on 'Edit' button under 'Settings'
5. Note down the associated AWS WAF web ACL
6. Go to the noted WAF web ACL in AWS WAF & Shield Service
7. Under 'Rules' tab click on 'Add rules' and select 'Add managed rule groups'
8. Under 'AWS managed rule groups' enable 'Anonymous IP list' and 'Known bad inputs'
9. Click on 'Add rules'.

Query:
```config from cloud.resource where api.name = 'aws-cloudfront-list-distributions' AND json.rule = webACLId is not empty as X; config from cloud.resource where api.name = 'aws-waf-v2-global-web-acl-resource' AND json.rule =(webACL.postProcessFirewallManagerRuleGroups.firewallManagerStatement.name does not contain AWSManagedRulesAnonymousIpList or webACL.postProcessFirewallManagerRuleGroups.firewallManagerStatement.name does not contain AWSManagedRulesKnownBadInputsRuleSet) and NOT ( webACL.rules[*].statement.managedRuleGroupStatement.name contains AWSManagedRulesAnonymousIpList and webACL.rules[*].statement.managedRuleGroupStatement.name contains AWSManagedRulesKnownBadInputsRuleSet ) as Y; filter '$.Y.webACL.arn equals $.X.webACLId'; show X;```
AWS RDS instance without Automatic Backup setting
This policy identifies RDS instances which are not set with the Automatic Backup setting. If Automatic Backup is set, RDS creates a storage volume snapshot of your DB instance, backing up the entire DB instance and not just individual databases which provide for point-in-time recovery. The automatic backup will happen during the specified backup window time and keeps the backups for a limited period of time as defined in the retention period. It is recommended to set Automatic backups for your critical RDS servers that will help in the data restoration process.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Sign 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 Amazon RDS console
4. Choose Instances, and then select the reported DB instance
5. On 'Instance Actions' drop-down list, choose 'Modify'
6. In 'Backup' section,
a. From the 'Backup Retention Period' drop-down list, select the number of days you want RDS should retain automatic backups of this DB instance
b. Choose 'Start Time' and 'Duration' in 'Backup window' which is the daily time range (in UTC) during which automated backups created
7. Click on 'Continue'
8. On the confirmation page, choose 'Modify DB Instance' to save your changes.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-rds-describe-db-instances' AND json.rule = 'backupRetentionPeriod equals 0 or backupRetentionPeriod does not exist'```
API automation policy wvpvq

This is applicable to aws cloud and is considered a medium 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 = architecture contains "foo"```
Azure App Service Web app doesn't use HTTP 2.0
HTTP 2.0 has additional performance improvements on the head-of-line blocking problem of old HTTP version, header compression, and prioritization of requests. HTTP 2.0 no longer supports HTTP 1.1's chunked transfer encoding mechanism, as it provides its own, more efficient, mechanisms for data streaming.
This is applicable to azure 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. Log in to the Azure portal
2. Navigate to App Services
3. Click on the reported App
4. Under Setting section, Click on 'Configuration'
5. Under 'General Settings' tab, In 'Platform settings', Set 'HTTP version' to '2.0'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = 'kind starts with app and config.http20Enabled equals false'```
AWS Config must record all possible resources
This policy identifies resources for which AWS Config recording is enabled but recording for all possible resources are disabled. AWS Config provides an inventory of your AWS resources and a history of configuration changes to these resources. You can use AWS Config to define rules that evaluate these configurations for compliance. Hence, it is important to enable this feature.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Login to the AWS and navigate to the 'Config' service
2. Change to the respective region and in the navigation pane, click on 'Settings'
3. Review the 'All resources' and Check the 2 options (3.a and 3.b)
3.a Record all resources supported in this region
3.b Include global resources (e.g., AWS IAM resources).

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-configservice-describe-configuration-recorders' AND json.rule = '(status.recording is true and status.lastStatus equals SUCCESS) and (recordingGroup.allSupported is false or recordingGroup.includeGlobalResourceTypes is false)'```
OCI Compute Instance has monitoring disabled
This policy identifies the OCI Compute Instances that are configured with Monitoring disabled. It is recommended that Compute Instances should be configured with monitoring is enabled following security best practices.
This is applicable to oci 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 the OCI Console
2. Type the resource reported in the alert into the Search box at the top of the Console.
3. Click the resource reported in the alert from the Resources submenu
4. Under Resources, click Metrics.
5. Click Enable monitoring. (If monitoring is not enabled (and the instance uses a supported image), then a button is available to enable monitoring.)

FMI : https://docs.cloud.oracle.com/en-us/iaas/Content/Compute/Tasks/enablingmonitoring.htm#ExistingEnabling.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-compute-instance' AND json.rule = agentConfig.isMonitoringDisabled is true```
IBM Cloud Activity Tracker Event Routing is not configured to collect global events
This policy identifies IBM Cloud Accounts which does not have at-least one Activity tracker event route defined to collect global event's data. Activity tracker event route configured with global events collects all the global services' event data and will be sent to the target configured, which can be used for access pattern analysis from security perspective. It is recommended to define at-least one route with location set to global.
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: To configure an Activity tracker route to collect global events, please follow the below URL. Please make sure to provide location value either as 'global' or '*' to make the route collect global service events.:

https://cloud.ibm.com/docs/atracker?topic=atracker-route_v2&interface=cli#route-create-cli.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-activity-tracker-route' AND json.rule = rules[?any( (locations[*] equal ignore case "global") or (locations[*] equals "*") )] exists as X; count(X) less than 1```
cloned copy - RLP-93423 - 1
Audit logging is not enabled by default in Amazon Redshift. When you enable logging on your cluster, Amazon Redshift creates and uploads logs to Amazon S3 that capture data from the creation of the cluster to the present time.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Login to AWS Console.
2. Goto Amazon Redshift service
3. On left navigation panel, click on Clusters
4. Click on the reported cluster
5. Click on Database tab and choose 'Configure Audit Logging'
6. On Enable Audit Logging, choose 'Yes'
7. Create a new s3 bucket or use an existing bucket
8. click Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-redshift-describe-clusters' AND json.rule ='loggingStatus.loggingEnabled is false'```
AWS RDS DB snapshot is not encrypted
This policy identifies AWS RDS DB (Relational Database Service Database) cluster snapshots which are not encrypted. It is highly recommended to implement encryption at rest when you are working with production data that have sensitive information, to protect from unauthorized access.
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: You can encrypt a copy of an unencrypted snapshot. This way, you can quickly add encryption to a previously unencrypted DB instance.
Follow below steps to encrypt a copy of an unencrypted snapshot:
1. Log 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 'RDS' dashboard from 'Services' dropdown.
4. Click on 'Snapshot' from left menu.
5. Select the alerted snapshot
6. From 'Action' dropdown, select 'Copy Snapshot'
7. In 'Settings' section, from 'Destination Region' select a region,
8. Provide an identifier for the new snapshot in field 'New DB Snapshot Identifier'
9.In 'Encryption' section, select 'Enable Encryption'
10. Select a master key for encryption from the dropdown 'Master key'.
11. Click on 'Copy Snapshot'.

The source snapshot needs to be removed once the copy is available.
Note: If you delete a source snapshot before the target snapshot becomes available, the snapshot copy may fail. Verify that the target snapshot has a status of AVAILABLE before you delete a source snapshot..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-rds-describe-db-snapshots' AND json.rule = 'snapshot.status equals available and snapshot.encrypted is false'```