knarayan/cloud_posture_checks huggingface dataset:
Alibaba Cloud Security group allow internet traffic to MySQL port (3306)
This policy identifies Security groups that allow inbound traffic on MySQL port (3306) 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 having 'Action' as Allow, 'Authorization Object' as 0.0.0.0/0 and 'Port Range' value as 3306, 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(3306,3306)"```
jScheel AWS Route53 domain configured without DNSSEC
List of AWS Route53 domains configured without DNSSEC.
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: https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/.

Query:
```config from cloud.resource where cloud.type = 'aws' AND cloud.account = 'jScheel AWS Account' AND api.name = 'aws-route53-domain' AND json.rule = dnssecKeys[*] is empty```
GCP VM instance template with IP forwarding enabled
This policy identifies VM instance templates 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 source and destination IP match check, disable the 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 instance templates are used to create VM instances based on a preexisting configuration. GCP VM instance templates IP forwarding feature cannot be updated. After an instance template is created, the IP forwarding field becomes read-only. So to fix this alert, Create a new VM instance template with IP forwarding disabled, migrate all required data from the reported template to the newly created one, and delete the reported VM instance template.

To create a new VM Instance template with IP forwarding disabled:
1. Login to GCP Portal
2. Go to 'Computer Engine' (Left Panel)
3. Go to 'Instance templates'
4. Click on 'CREATE INSTANCE TEMPLATE'
5. Specify the mandatory parameters as required
6. Click 'Management, security, disk, networking, sole tenancy'
7. Click 'Networking'
8. Click on the specific Network interfaces
9. Set 'IP forwarding' to 'Off'
10. Click on 'Create' button

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

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-instance-template' AND json.rule = properties.canIpForward is true and (name does not start with "gke-" or (name starts with "gke-" and properties.disks[*].initializeParams.labels does not exist) )```
Azure Function App doesn't use HTTP 2.0
This policy identifies Azure Function App which 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 prioritisation 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 Function App
3. Click on the reported Function App
4. Under Setting section, Click on 'Configuration'
5. Under 'General Settings' tab, In 'Platform settings', Set 'HTTP version' to '2.0'
6. Click on 'Save'

If Function App Hosted in Linux using Consumption (Serverless) Plan follow below steps
Azure CLI Command - \"az functionapp config set --http20-enable true --name MyFunctionApp --resource-group MyResourceGroup\".

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = properties.state equal ignore case "Running" AND kind contains "functionapp" AND kind does not contain "workflowapp" AND kind does not equal "app" AND config.http20Enabled is false```
bobby gcp policy

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-compute-backend-bucket' as X; config from cloud.resource where api.name = 'gcloud-storage-buckets-list' as Y; filter ' not (Y.name intersects X.bucketName) '; show X;```
Azure Container Registry with exports enabled
This policy identifies Azure Container Registries with exports enabled.

Azure Container Registries with exports enabled allows data in the registry to be moved out using commands like acr import or acr transfer. Export functionality can expose registry data, increasing the risk of unauthorized data movement. Disabling exports ensures that data in a registry is accessed only via the dataplane (e.g., docker pull) and cannot be moved out using other methods.

As a security best practice, it is recommended to disable export configuration for Azure Container Registries.
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: Note: To remediate the alert, ensure the registry is on the Premium service tier, disable public network access to turn off exports (supported only for managed registries in Premium SKU), and use the provided az command as this setting cannot be changed through the UI.

CLI command: az acr update --name ${registryName} --allow-exports false --public-network-enabled false.

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-container-registry' AND json.rule = properties.provisioningState equal ignore case Succeeded and (properties.policies.exportPolicy.status contains enabled or properties.publicNetworkAccess contains enabled)```
GCP Log metric filter and alert does not exist for VPC network route changes
This policy identifies the GCP account which does not have a log metric filter and alert for VPC network route changes. Monitoring network routes deletion and insertion activities will help in identifying VPC traffic flows through an expected path. It is recommended to create a metric filter and alarm to detect activities related to the deletion and insertion of VPC network routes.
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. Sign in to GCP Console
2. Navigate to 'Logs-based metrics' under the 'Logging' section.
3. Click on 'CREATE METRIC'.
4. Provide 'Metric Type' and 'Details'.
5. In 'Filter selection', add filter as 
resource.type="gce_route" AND jsonPayload.event_subtype="compute.routes.delete" OR jsonPayload.event_subtype="compute.routes.insert"
6. Click on 'CREATE METRIC'.
7. Under 'User-defined metrics' section, choose the metric you created in step 6 and click on the kebab menu (Vertical 3 dots) on the right side of the metrics
8. Click on 'Create alert from metric'; it will navigate to 'Create alerting policy' under the section 'Monitoring'.
9. Add the metric name created above if not auto-filled in the Monitoring filter. Choose an appropriate value for other alert condition parameters as desired. Then Click on 'NEXT'
10. Configure all alert trigger settings as desired. Then Click on 'NEXT'
11. Configure notifications as desired and provide an appropriate name for the alert policy. Then Click on 'NEXT'
12. Click on 'CREATE POLICY'..

Query:
```config from cloud.resource where api.name = 'gcloud-logging-metric' as X; config from cloud.resource where api.name = 'gcloud-monitoring-policies-list' as Y; filter '$.Y.conditions[*].metricThresholdFilter contains $.X.name and ($.X.filter contains "resource.type =" or $.X.filter contains "resource.type=") and ($.X.filter does not contain "resource.type !=" and $.X.filter does not contain "resource.type!=") and $.X.filter contains "gce_route" and ($.X.filter contains "jsonPayload.event_subtype=" or $.X.filter contains "jsonPayload.event_subtype =") and ($.X.filter does not contain "jsonPayload.event_subtype!=" and $.X.filter does not contain "jsonPayload.event_subtype !=") and $.X.filter contains "compute.routes.delete" and $.X.filter contains "compute.routes.insert"'; show X; count(X) less than 1```
AWS S3 bucket accessible to unmonitored cloud accounts
This policy identifies those S3 buckets which have either the read/write permission opened up for Cloud Accounts which are NOT part of Cloud Accounts monitored by Prisma Cloud. These accounts with read/write privileges should be reviewed and confirmed that these are valid accounts of your organization (or authorised by your organization) and are not active under Prisma Cloud monitoring.
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. Navigate to the 'S3' service
3. Click on the reported S3 bucket
4. Click on the 'Permissions' tab
5. Navigate to the 'Access control list (ACL)' section and Click on the 'Edit'
6. Under 'Access for other AWS accounts', Add the Cloud Accounts that are monitored by Prisma Cloud
7. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = "acl.grants[?(@.grantee.typeIdentifier=='id')].grantee.identifier size > 0 and acl.grants[?(@.grantee.typeIdentifier=='id')].grantee.identifier does not contain c4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0 and _AWSCloudAccount.isRedLockMonitored(acl.grants[?(@.grantee.typeIdentifier=='id')].grantee.identifier) is false"```
Azure PostgreSQL database server deny public network access setting is not set
This policy identifies Azure PostgreSQL database servers that have Deny public network access setting is not set. When 'Deny public network access' is set to yes, only private endpoint connections will be allowed to access this resource. It is highly recommended to set Deny public network access setting to Yes, which would allow PostgreSQL database server to be accessed only through private endpoints.

Note: This feature is available in all Azure regions where Azure Database for PostgreSQL - Single server supports General Purpose and Memory Optimized pricing tiers.
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 Database for PostgreSQL servers'
3. Click on the reported PostgreSQL server instance you want to modify 
4. Select 'Connection security' under 'Settings' from left panel 
5. For 'Deny public network access' ensure 'Deny public network access' is set to 'Yes'
6. Click on 'Save'

Note: When 'Deny public network access' is set to yes, only private endpoint connections will be allowed to access this resource..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-postgresql-server' AND json.rule = properties.userVisibleState equal ignore case Ready and sku.tier does not equal ignore case Basic and properties.publicNetworkAccess equal ignore case Enabled```
AWS ALB attached WAFv2 WebACL is not configured with AMR for Log4j Vulnerability
This policy identifies AWS Application Load Balancer (ALB) attached with WAFv2 WebACL which is not configured with AWS Managed Rules (AMR) for Log4j Vulnerability. As per the guidelines given by AWS, Application Load Balancer (ALB) 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 ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to the AWS console
2. Navigate to EC2 Dashboard, and select 'Load Balancers'
3. Make sure your reported Application Load Balancer requires WAF based on your requirement and Note down the load balancer name
4. Navigate to WAF & Shield Service
5. Go to the Web ACL associated to the reported Application Load Balancer
6. Under 'Rules' tab click on 'Add rules' and select 'Add managed rule groups'
7. Under 'AWS managed rule groups' enable 'Anonymous IP list' and 'Known bad inputs'
8. Click on 'Add rules'.

Query:
```config from cloud.resource where api.name = 'aws-elbv2-describe-load-balancers' AND json.rule = scheme equals internet-facing and type equals application as X; config from cloud.resource where api.name = 'aws-waf-v2-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.resources.applicationLoadBalancer[*] contains $.X.loadBalancerArn'; show X;```
Azure 'Cross Tenant Replication' is enabled

This is applicable to azure 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 = 'azure-storage-account-list' AND json.rule = properties.allowCrossTenantReplication exists and properties.allowCrossTenantReplication is true```
Azure Microsoft Defender for Cloud WDATP integration Disabled
This policy identifies Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) which has Microsoft Defender for Endpoint (WDATP) integration disabled. Enabling Microsoft Defender for Cloud provides the tools needed to harden your resources, track your security posture, protect against cyberattacks, and streamline security management. It is highly recommended to enable Microsoft Defender for WDATP.
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. Go to 'Microsoft Defender for Cloud'
3. Select 'Environment Settings'
4. Click on the subscription name
5. Select the 'Integrations'
6. Check/Enable option 'Allow Microsoft Defender for Endpoint to access my data'
7. Select 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = settings[?any( name equals WDATP and properties.enabled is false )] exists```
RomanTest - Ensure SQS service is encrypted at-rest

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-sqs-get-queue-attributes' AND json.rule = attributes.SqsManagedSseEnabled equals "false" and attributes.KmsMasterKeyId does not exist```
AWS CloudFront viewer protocol policy is not configured with HTTPS
For web distributions, you can configure CloudFront to require that viewers use HTTPS to request your objects, so connections are encrypted when CloudFront communicates with viewers.
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: Configure CloudFront to require HTTPS between viewers and CloudFront.

1. Go to the AWS console CloudFront dashboard.
2. Select your distribution Id.
3. Select the 'Behaviors' tab.
4. Check the behavior you want to modify then select Edit.
5. Choose 'HTTPS Only' or 'Redirect HTTP to HTTPS' for Viewer Protocol Policy.
6. Select 'Yes, Edit.'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = defaultCacheBehavior.viewerProtocolPolicy contains "allow-all" or cacheBehaviors.items[?any( viewerProtocolPolicy contains "allow-all" )] exists```
AWS Glue connection do not have SSL configured
This policy identifies the Glue connections that are not configured with SSL to encrypt connections. It is recommended to use an SSL connection with hostname matching is enforced for the DB connection on the client; enforcing SSL connections help protect against 'man in the middle' attacks by encrypting the data stream between connections.
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. Navigate to AWS Glue service
4. Click on 'Connections', Click on the reported Connection
5. Click on 'Edit'
6. On the 'Edit connection' page, Select 'Require SSL connection'
7. Click on 'Next'
8. Click on 'Finish'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-glue-connection' AND json.rule = ((connectionType equals KAFKA and connectionProperties.KAFKA_SSL_ENABLED is false) or (connectionType does not equal KAFKA and connectionProperties.JDBC_ENFORCE_SSL is false)) and connectionType does not equal "NETWORK"```
AWS Network ACLs allow ingress traffic on Admin ports 22/3389
This policy identifies the AWS Network Access Control List (NACL) which has a rule to allow ingress traffic to server administration ports.

AWS NACL provides filtering of ingress and egress network traffic to AWS resources. Allowing ingress traffic on admin ports 22 (SSH) and 3389 (RDP) via AWS Network ACLs increases the vulnerability of EC2 instances and other network resources to unauthorized access and cyberattacks.

It is recommended that no NACL allows unrestricted ingress access to server administration ports, such as SSH port 22 and RDP port 3389.

NOTE: This policy may report NACLs, which include the deny policy in the rule set. Make sure while remediating the rule set does not consist of the Allow and Deny rule set together; which leads to overlap on each ruleset.
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 update the AWS Network Access Control List perform the following actions:
1. Sign into the AWS console and navigate to the Amazon VPC console. 
2. In the navigation pane, choose 'Network ACLs' under the 'Security' section.
3. Select the reported Network ACL
4. Click on 'Actions' and select 'Edit inbound rules'
5. Click on Delete towards the right of rule which has source '0.0.0.0/0' or '::/0' and shows 'ALLOW and 'Port Range' which includes port 22 or 3389 or 'Port Range' shows 'ALL'
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-network-acls' AND json.rule = "entries[?any(egress equals false and ((protocol equals 6 and ((portRange.to equals 22 or portRange.to equals 3389 or portRange.from equals 22 or portRange.from equals 3389) or (portRange.to > 22 and portRange.from < 22) or (portRange.to > 3389 and portRange.from < 3389))) or protocol equals -1) and (cidrBlock equals 0.0.0.0/0 or ipv6CidrBlock equals ::/0) and ruleAction equals allow)] exists"```
Azure App Service web apps with public network access
This policy identifies Azure App Service web apps that are configured with public network access. Publicly accessible web apps could allow malicious actors to remotely exploit if any vulnerabilities and could. It is recommended to configure the App Service web apps with private endpoints so that the web apps hosted are accessible only to restricted entities.
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: To restrict App Service network access, follow below URL:
https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = 'kind starts with app and properties.state equal ignore case running and properties.publicNetworkAccess exists and properties.publicNetworkAccess equal ignore case Enabled and config.ipSecurityRestrictions[?any(action equals Allow and ipAddress equals Any)] exists'```
Azure Monitor Diagnostic Setting does not captures appropriate categories
This policy identifies Azure Monitor Diagnostic Setting which does not captures appropriate categories. Capturing appropriate diagnostic setting categories allows proper alerting. It is recommended to select Administrative, Alert, Policy, and Security diagnostic setting categories.
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 Azure Portal
2. Navigate to 'Monitor' and select 'Activity log'
3. Click on 'Diagnostic settings' in top pane
4. Select 'Add diagnostic setting' if no 'Diagnostic settings' present
OR
Click on 'Edit setting' for the existing 'Diagnostic settings'
5. Under 'Category details', select 'Administrative', 'Alert', 'Policy', and 'Security' for 'log'
6. Add 'Destination details' and other required fields
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-monitor-log-profiles-list' AND json.rule = properties.logs[?any((enabled is true and category equals Administrative))] exists and properties.logs[?any((enabled is true and category equals Alert))] exists and properties.logs[?any((enabled is true and category equals Policy))] exists and properties.logs[?any((enabled is true and category equals Security))] exists as X; count(X) less than 1```