knarayan/cloud_posture_checks huggingface dataset:
Azure DNS Zone having dangling DNS Record vulnerable to subdomain takeover associated with Web App Service
This policy identifies DNS records within an Azure DNS zone that point to Azure Web App Services that no longer exist.

A dangling DNS attack happens when a DNS record points to a cloud resource that has been deleted or is inactive, making the subdomain vulnerable to takeover. An attacker can exploit this by creating a new resource with the same name and taking control of the subdomain to serve malicious content. This allows attackers to host harmful content under your subdomain, which could lead to phishing attacks, data breaches, and damage to your reputation. The risk arises because the DNS record still references a non-existent resource, which unauthorized individuals can re-associate with their own resources.

As a security best practice, it is recommended to routinely audit DNS zones and remove or update DNS records pointing to non-existing Web App Services.
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: 1. Log in to the Azure Portal and search for 'DNS zones'
2. Select 'DNS zones' from the search results
3. Select the DNS zone associated with the reported DNS record
4. On the left-hand menu, under 'DNS Management,' select 'Recordsets'
5. Locate and select the reported DNS record
6. Update or remove the DNS Record if no longer necessary.

Query:
```config from cloud.resource where api.name = 'azure-dns-recordsets' AND json.rule = type contains CNAME and properties.CNAMERecord.cname contains "azurewebsites.net" as X; config from cloud.resource where api.name = 'azure-app-service' as Y; filter 'not ($.Y.properties.hostNames contains $.X.properties.CNAMERecord.cname) '; show X;```
GCP Kubernetes Engine Cluster Client Certificate is not disabled
This policy identifies Kubernetes Engine clusters that have enabled Client Certificate authentication. A client certificate is a base64-encoded public certificate used by clients to authenticate to the cluster endpoint. GKE manages authentication via gcloud using the OpenID Connect token method, setting up the Kubernetes configuration, getting an access token, and keeping it up to date. So it is recommended not to enable Client Certificate authentication, to avoid additional management overhead of key management and rotation.

Note: For GKE Autopilot clusters, legacy authentication methods cannot be used. Basic authentication is deprecated and has been removed in GKE 1.19 and later.

Reference: https://cloud.google.com/kubernetes-engine/docs/how-to/api-server-authentication#legacy-auth
This is applicable to gcp cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: GCP Kubernetes Clusters Client Certificate can be disabled only at the time of the creation of clusters. So to fix this alert, create a new cluster with Client Certificate disabled and then migrate all required cluster data or containers from the reported cluster to this new cluster.

To create the cluster with Client Certificate disabled, perform the following steps:
1. Login to GCP Portal
2. Go to Kubernetes Engine (Left Panel)
3. Click on 'Clusters' (Left Panel)
4. On page 'Kubernetes clusters', click on 'CREATE'
5. Select the type of cluster by clicking on the 'CONFIGURE' button
6. Select ‘Security’ tab (Left Panel)
7. Under the 'Legacy security options' section, ensure 'Issue a client certificate' is not set
8. Provide all required cluster data or containers from the reported cluster to this new cluster
9. Click on 'CREATE' to create a new cluster
10. Once the cluster is created, delete the alerted cluster to resolve the alert.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = status equals RUNNING and (masterAuth.clientKey exists or masterAuth.clientCertificate exists)```
Azure Storage account diagnostic setting for file is disabled
This policy identifies Azure Storage account files that have diagnostic logging disabled.

By enabling diagnostic settings, you can capture various types of activities and events occurring within these storage account files. These logs provide valuable insights into the operations, performance, and security of the storage account files.

As a best practice, it is recommended to enable diagnostic logs on all storage account files.
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 the Storage Accounts dashboard
3. Click on the reported Storage account
4. Under the 'Monitoring' menu, click on 'Diagnostic settings'
5. Select the file resource
6. Under 'Diagnostic settings', click on 'Add diagnostic setting'
7. At the top, enter the 'Diagnostic setting name'
8. Under 'Logs', select all the checkboxes under 'Categories'
9. Under 'Destination details', select the destination for logging
10. Click on 'Save'.

Query:
```config from cloud.resource where api.name = 'azure-storage-account-list' AND json.rule = properties.provisioningState equal ignore case Succeeded as X; config from cloud.resource where api.name = 'azure-storage-account-file-diagnostic-settings' AND json.rule = properties.logs[*].enabled all true as Y; filter 'not($.X.name equal ignore case $.Y.StorageAccountName)'; show X;```
Copy of Sol-test  config policy

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 cloud.accountgroup = 'Flowlog-sol' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = bucketName contains "sol-test" ```
OCI Object Storage bucket does not emit object events
This policy identifies the OCI Object Storage buckets that are disabled with object events emission. Monitoring and alerting on object events of bucket objects will help in identifying changes bucket objects. It is recommended that buckets should be enabled to emit object events.
This is applicable to oci 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. 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. Next to Emit Object Events, click Edit.
5. In the dialog box, select  EMIT OBJECT EVENTS (to enable).
6. Click Save Changes..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-object-storage-bucket' AND json.rule = objectEventsEnabled is false```
Azure Activity Log Alert does not exist for Delete Public IP Address rule

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 cloud.type = 'azure' AND api.name = 'azure-activity-log-alerts' AND json.rule = "location equal ignore case Global and properties.enabled equals true and properties.scopes[*] does not contain resourceGroups and properties.condition.allOf[?(@.field=='operationName')].equals does not equal Microsoft.Network/publicIPAddresses/delete and properties.condition.allOf[?(@.field=='category')].['equals'] contains Administrative" as X; count(X) less than 1```
AWS Elastic Load Balancer (ELB) has security group with no inbound rules
This policy identifies Elastic Load Balancers (ELB) which have security group with no inbound rules. A security group with no inbound rule will deny all incoming requests. ELB security groups should have at least one inbound rule, ELB with no inbound permissions will deny all traffic incoming to ELB; in other words, the ELB is useless without inbound permissions.
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', choose the reported load balancer
5. Click on the 'Description' tab, click on the security group, it will open Security Group properties in a new tab in your browser
6. Click on the 'Inbound Rules'
7. If there are no rules, click on 'Edit rules', add an inbound rule according to your ELB functional requirement
8. Click on 'Save'.

Query:
```config from cloud.resource where api.name = 'aws-elb-describe-load-balancers' as X; config from cloud.resource where api.name = 'aws-ec2-describe-security-groups' as Y; filter '$.X.description.securityGroups[*] contains $.Y.groupId and $.Y.ipPermissions[*] is empty'; show X;```
Azure Virtual Machine vTPM feature is disabled
This policy identifies Virtual Machines that have Virtual Trusted Platform Module (vTPM) feature disabled. Virtual Trusted Platform Module (vTPM) provide enhanced security to the guest operating system. It is recommended to enable virtual TPM device on supported virtual machines to facilitate measured Boot and other OS security features that require a TPM.

NOTE: This assessment only applies to trusted launch enabled virtual machines. You can't enable trusted launch on existing virtual machines that were initially created without it. 
To know more, refer https://docs.microsoft.com/azure/virtual-machines/trusted-launch?WT.mc_id=Portal-Microsoft_Azure_Security
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 Virtual machines dashboard
3. Click on the reported Virtual machine
4. Select 'Configuration' under 'Settings' from left panel 
NOTE: Enabling vTPM will trigger an immediate SYSTEM REBOOT.
5. On the 'Configuration' page, check 'vTPM' under 'Security type' section
6. Click 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-vm-list' AND json.rule = powerState equal ignore case "PowerState/running" and ['properties.securityProfile'].['securityType'] equal ignore case "TrustedLaunch" and ['properties.securityProfile'].['uefiSettings'].['vTpmEnabled'] is false```
OCI IAM password policy for local (non-federated) users does not have minimum 14 characters
This policy identifies Oracle Cloud Infrastructure(OCI) accounts that do not have a minimum of 14 characters in the password policy for local (non-federated) users. As a security best practice, configure a strong password policy for secure access to the OCI console.
This is applicable to oci cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['WEAK_PASSWORD'].
Mitigation of this issue can be done as follows: 1. Login to the OCI Console Page: https://console.ap-mumbai-1.oraclecloud.com/
2. Go to Identity in the Services menu.
3. Select Authentication Settings from the Identity menu.
4. Click Edit Authentication Settings in the middle of the page.
5. Type the number in range 14-100 into the box below the text: MINIMUM PASSWORD LENGTH (IN CHARACTERS).

Note : The console URL is region specific, your tenancy might have a different home region and thus console URL..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-iam-authentication-policy' AND json.rule = 'passwordPolicy.minimumPasswordLength less than 14'```
Azure Network Security Group allows all traffic on FTP-Data (TCP Port 20)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on FTP-Data (TCP Port 20). Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict FTP-Data 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(20,20) or destinationPortRanges[*] contains _Port.inRange(20,20) ))] exists```
GCP Log metric filter and alert does not exist for VPC network route patch and insert
This policy identifies GCP accounts which do not have a log metric filter and alert for VPC network route patch and insert events. Monitoring network routes patching 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 patch 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 protoPayload.methodName="beta.compute.routes.patch" OR protoPayload.methodName="beta.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 "protoPayload.methodName=" or $.X.filter contains "protoPayload.methodName =" ) and ( $.X.filter does not contain "protoPayload.methodName!=" and $.X.filter does not contain "protoPayload.methodName !=" ) and $.X.filter contains "beta.compute.routes.patch" and $.X.filter contains "beta.compute.routes.insert"'; show X; count(X) less than 1```
Azure Storage account Encryption Customer Managed Keys Disabled
This policy identifies Azure Storage account which has Encryption with Customer Managed Keys Disabled. By default all data at rest in Azure Storage account is encrypted using Microsoft Managed Keys. It is recommended to use Customer Managed Keys to encrypt data in Azure Storage accounts for better control on Storage account data.
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 Azure Portal
2. Go to Storage accounts dashboard and Click on reported storage account
3. Under the Settings menu, click on Encryption
4. Select Customer Managed Keys
- Choose 'Enter key URI' and Enter 'Key URI'
OR
- Choose 'Select from Key Vault', Enter 'Key Vault' and 'Encryption Key'
5. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-storage-account-list' AND json.rule = properties.encryption.keySource equals "Microsoft.Storage"```
AWS RDS minor upgrades not enabled
When Amazon Relational Database Service (Amazon RDS) supports a new version of a database engine, you can upgrade your DB instances to the new version. There are two kinds of upgrades: major version upgrades and minor version upgrades. Minor upgrades helps maintain a secure and stable RDS with minimal impact on the application. For this reason, we recommend that your automatic minor upgrade is enabled. Minor version upgrades only occur automatically if a minor upgrade replaces an unsafe version, such as a minor upgrade that contains bug fixes for a previous version.
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: Enable RDS auto minor version upgrades.

1. Go to the AWS console RDS dashboard.
2. In the navigation pane, choose Instances.
3. Select the database instance you wish to configure.
4. From the 'Instance actions' menu, select Modify.
5. Under the Maintenance section, choose Yes for Auto minor version upgrade.
6. Select Continue and then Modify DB Instance..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-rds-describe-db-instances' AND json.rule = dbinstanceStatus equals available and autoMinorVersionUpgrade is false and engine does not contain docdb and engine does not contain neptune```
AWS EventBridge event bus with no resource-based policy attached
This policy identifies AWS EventBridge event buses with no resource-based policy attached.

AWS EventBridge is a serverless event bus service that enables businesses to quickly and easily integrate applications, services, and data across multiple cloud environments. By default, an EventBridge custom event bus lacks a resource-based policy associated with it, which allows principals in the account to access the event bus. 

It is recommended to attach a resource based policy to the event bus to limit access scope to fewer entities.
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 attach a resource based policy to the event bus, please follow the below steps:

1. Log into the AWS console and navigate to the EventBridge dashboard
2. In the left navigation pane, choose 'Event buses'
3. Select the event bus reported
4. Under the 'Permissions' tab, click on 'Manage permissions'
5. Add the resource based policy JSON with permissions to grant on the event bus
6. Click on 'Update'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-events-eventbus' AND json.rule = Policy does not exist```
bboiko test 03 - policy

This is applicable to azure 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 cloud.type = 'azure' AND api.name = 'azure-key-vault-list' AND json.rule = properties.provisioningState equals Succeeded and diagnosticSettings.value[*].properties.workspaceId does not equal ignore case "/subscriptions/8dff688e-d9b0-477c-b2b0-b0e729fb06bd/resourceGroups/rg-analytics-sh-prd-scus/providers/Microsoft.OperationalInsights/workspaces/log-sh-workspace"```
Azure Event Hub Instance not defined with authorization rule
This policy identifies Azure Event Hub Instances that are not defined with authorization rules.

If the Azure Event Hub Instance authorization rule is not defined, there is a heightened risk of unauthorized access to the event hub data and resources. This could potentially lead to unauthorized data retrieval, tampering, or disruption of the event hub operations. Defining proper authorization rules helps mitigate these risks by controlling and restricting access to the event hub resources.

As a best practice, it is recommended to define the least privilege security model access policies at Event Hub Instance.
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. Navigate to 'Event Hubs'
3. Select the Event Hubs Namespace from the list which has the reported Event Hub instance.
4. Click on 'Event Hubs' under 'Entities' section
5. Click on the reported Event Hub instance
6. Select 'Shared access policies' under 'Settings' section
7. Click on '+Add'
8. Enter 'Policy name' and the required access
9. Click on 'Create'.

Query:
```config from cloud.resource where api.name = 'azure-event-hub-namespace' AND json.rule = properties.disableLocalAuth is false as X; config from cloud.resource where api.name = 'azure-event-hub' AND json.rule = properties.status equal ignore case ACTIVE and authorizationRules[*] is empty as Y; filter '$.Y.id contains $.X.name'; show Y;```