knarayan/cloud_posture_checks huggingface dataset:
AWS Certificate Manager (ACM) has certificates expiring in 30 days or less
This policy identifies ACM certificates expiring in 30 days or less, which are in the AWS Certificate Manager. If SSL/TLS certificates are not renewed prior to their expiration date, they will become invalid and the communication between the client and the AWS resource that implements the certificates is no longer secure. As a best practice, it is recommended to renew certificates before their validity period ends. AWS Certificate Manager automatically renews certificates issued by the service that is used with other AWS resources. However, the ACM service does not renew automatically certificates that are not in use or not associated anymore with other AWS resources. So the renewal process must be done manually before these certificates become invalid.

NOTE: If you wanted to be notified other than before or less than 30 days; you can clone this policy and replace '30' in RQL with your desired days value. For example, 15 days OR 7 days which will alert certificates expiring in 15 days or less OR 7 days or less respectively.
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 region drop down on the top right corner, for which the alert is generated
3. Go to the Certificate Manager(ACM) service
4. Choose the reported certificate
5. Verify that the 'Status' column shows 'Issued' for the reported certificate
6. Under 'Actions' drop-down select 'Reimport certificate' option
7. On the Import a certificate page, perform the following actions:
7a. In 'Certificate body*' box, paste the PEM-encoded certificate to import, purchased from your SSL certificate provider.
7b. In 'Certificate private key*' box, paste the PEM-encoded, unencrypted private key that matches the SSL/TLS certificate public key.
7c.(Optional) In 'Certificate chain' box, paste the PEM-encoded certificate chain delivered with the certificate body specified at step 7a.
8. Click on 'Review and import' button
9. On the Review and import page, review the imported certificate details then click on 'Import'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-acm-describe-certificate' AND json.rule = 'status equals ISSUED and (_DateTime.ageInDays($.notAfter) > -31)'```
Azure Container Instance environment variable with regular value type
This policy identifies Azure Container Instances (ACI) in which the environment variables with regular value type instead of the secure values property. Objects with secure values are intended to hold sensitive information like passwords or keys for your application. Using secure values for environment variables is both safer and more flexible than including them in your container's image. So it is recommended to secure the environment variable by specifying the 'secureValue' property instead of the regular 'value' for the variable's type.
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: Environment variables can only be configured with secure values at the time of container instance creation. It is not possible to modify environment variables once instance is created. Hence, it is suggested to delete an existing container instance having not configured with secure values and create a new container instance having required environment variables configured with secure values.
Note: Backup or migrate data from the container instance before deleting it.

To create a container instance with environment variables with secure value property; follow below URL:
https://docs.microsoft.com/en-us/azure/container-instances/container-instances-environment-variables#secure-values

To delete a reported container instance; follow below URL:
https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-portal#clean-up-resources.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-container-instances-container-group' AND json.rule = properties.provisioningState equals Succeeded and properties.containers[*].properties.environmentVariables[*] exists and properties.containers[*].properties.environmentVariables[*].value exists```
Azure Microsoft Entra ID users can consent to apps accessing company data on their behalf not set to verified publishers
This policy identifies instances in the Microsoft Entra ID configuration where users in your Azure Microsoft Entra ID (formerly Azure Active Directory) can consent to applications accessing company data on their behalf, even if the applications are not from verified publishers.

Allowing unverified applications to access company data increases the likelihood of data breaches and unauthorized access, which could lead to the exposure of confidential information. Using unverified applications can lead to non-compliance with data protection regulations and undermine trust in the organization's data handling practices.

As a best practice, it is recommended to configure the user consent settings to restrict access only to applications from verified publishers.
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 and search for 'Microsoft Entra ID'
2. Select 'Microsoft Entra ID'
3. Select 'Enterprise Applications'
4. Select 'Consent and permissions'
5. Select 'User consent settings'
6. Under User consent for applications, select 'Allow user consent for apps from verified publishers, for selected permissions (Recommended)'
7. Select Save.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-active-directory-authorization-policy' AND json.rule = defaultUserRolePermissions.permissionGrantPoliciesAssigned[*] does not contain "ManagePermissionGrantsForSelf.microsoft-user-default-low"```
AWS ECS services have automatic public IP address assignment enabled
This policy identifies whether Amazon ECS services are configured to assign public IP addresses automatically. Assigning public IP addresses to ECS services may expose them to the internet. If the services are not adequately secured or have vulnerabilities, they could be susceptible to unauthorized access, DDoS attacks, or other malicious activities. It is recommended that the Amazon ECS environment not have an associated public IP address except for limited edge cases.
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 modify a disable auto-assign public IP for an ECS Service:

1. Use the AWS CLI console or AWS API, as you cannot update network configurations for an ECS Service using the AWS Management Console.

2. Run update-service command in AWS CLI to disable auto-assign public IP for an ECS Service
 aws ecs update-service --cluster <ECS Cluster Name> --service <ECS Service Name> --network-configuration "awsvpcConfiguration={subnets=[string, string],securityGroups=[string, string],assignPublicIp=DISABLED}"
Please Refer to the below URL:
https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html.

Query:
```config from cloud.resource where api.name = 'aws-ecs-service' AND json.rule = networkConfiguration.awsvpcConfiguration.assignPublicIp exists and networkConfiguration.awsvpcConfiguration.assignPublicIp equal ignore case "ENABLED"```
dnd_test_validate_compliance_hyperion_policy_ss_finding_2
Description-0b771ac4-26e0-4857-8391-b8e39e24555b
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['HIGH_PRIVILEGED_ROLE'].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = defaultRootObject is empty```
GCP Kubernetes Engine Clusters not configured with private nodes feature
This policy identifies Google Kubernetes Engine (GKE) Clusters which are not configured with the private nodes feature. Private nodes feature makes your master inaccessible from the public internet and nodes do not have public IP addresses, so your workloads run in an environment that is isolated from the internet.
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 private node feature can be enabled at the time of cluster creation. So to fix this alert, Create a new cluster with a private node feature enabled on it and migrate all required data from reported cluster to the newly created cluster and delete reported Kubernetes engine cluster.

To create new Kubernetes engine cluster with private node feature enabled, perform the following: 
1. Login to GCP Portal
2. Go to Kubernetes Engine (Left Panel)
3. Select Kubernetes clusters
4. Click on CREATE CLUSTER button
5. Click on 'Advanced options'
6. Under the Networking section, Check the 'Enable VPC-native (using alias IP)' option
7. Choose the required Network, Node subnet parameters
8. From Network security, select the Private cluster check box.
9. To create a master that is accessible from authorized external IP ranges, keep the 'Access master using its external IP address' checkbox selected.
9. Set 'Master IP range' to as per your required IP range
10. Click on 'Create'
NOTE: When you create a private cluster, you must specify a /28 CIDR range for the VMs that run the Kubernetes master components.

To delete reported Kubernetes engine cluster, perform the following:
1. Login to GCP Portal
2. Go to Kubernetes Engine (Left Panel)
3. Select Kubernetes clusters 
4. Click on reported Kubernetes cluster
5. Click on the DELETE button
6. On 'Delete a cluster' popup dialog, Click on DELETE to confirm the deletion of the cluster..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = 'privateClusterConfig.enablePrivateNodes does not exist or privateClusterConfig.enablePrivateNodes is false'```
AWS Application Load Balancer (ALB) is not configured to drop HTTP headers
This policy identifies AWS Application Load Balancers that are not configured to drop HTTP headers.

AWS Application Load Balancers distribute incoming HTTP/HTTPS traffic across multiple targets such as EC2 instances, containers, and Lambda functions, based on routing rules and health checks. By default, ALBs are not configured to drop invalid HTTP header values, which can leave the load balancer vulnerable to HTTP desync attacks. HTTP desync attacks manipulate request headers to exploit inconsistencies between servers, potentially leading to security vulnerabilities and unauthorized access.

It is recommended to enable this feature, to prevent the load balancer from forwarding requests with invalid HTTP headers to mitigate potential security vulnerabilities.
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 configure the application load balancer to drop invalid HTTP header fields, perform the following actions:

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/
2. In the navigation pane, choose 'Load balancers'
3. Choose the reported Application Load Balancer 
4. From 'Actions', choose 'Edit load balancer attributes' 
5. Enable the 'Drop invalid header fields’ option
6. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elbv2-describe-load-balancers' AND json.rule = type equals application and ['attributes'].['routing.http.drop_invalid_header_fields.enabled'] is false```
AWS GuardDuty detector is not enabled
This policy identifies the AWS GuardDuty detector that is not enabled in specific regions.

GuardDuty identifies potential security threats in the AWS environment by analyzing data collected from various sources. The GuardDuty detector is the entity within the GuardDuty service that does this analysis. Failure to enable GuardDuty increases the risk of undetected threats and vulnerabilities which could lead to compromises in the AWS environment.

It is recommended to enable GuardDuty detectors in all regions to reduce the risk of security breaches.
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 Amazon GuardDuty in the region,
1. Log in to the AWS console.
2. In the console, select the specific region from the region drop-down menu located at the top right corner for which the alert has been generated.
3. Navigate to service 'Amazon Gaurdduty' from the 'Services' Menu.
4. Choose 'Get Started'.
5. Choose 'Enable GuardDuty' to enable on a specific region.

To re-enable Amazon GuardDuty after suspending,
1. Log in to the AWS console.
2. In the console, select the specific region from the region drop-down menu located at the top right corner for which the alert has been generated.
3. Navigate to service 'Amazon Gaurdduty' from the 'Services' Menu.
4. In the navigation pane, choose 'Settings'.
5. Choose 'Re-enable GuardDuty' to re-enable on a specific region..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-guardduty-detector' AND json.rule = status does not equal ENABLED```
Alibaba Cloud ECS instance RAM role not enabled
This policy identifies ECS instances for which the Resource Access Management (RAM) role is not enabled. Alibaba Cloud provides RAM roles to securely access Alibaba Cloud services and resources. As a best practice, create RAM roles and attach the role to manage ECS instance permissions securely instead of distributing or sharing keys or passwords.
This is applicable to alibaba_cloud cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
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, click 'Instances'
4. Select the reported ECS instance
5. Select More > Instance Settings > Bind/Unbind RAM Role
6. Select a required RAM Role
NOTE: If already RAM role is not created create new RAM role and follow the same procedure to attach.
7. Click on 'OK'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ecs-instance' AND json.rule = 'ramRoleName is empty'```
AWS Private ECR repository policy is overly permissive
This policy identifies AWS Private ECR repositories that have overly permissive registry policies. An ECR(Elastic Container Registry) repository is a collection of Docker images available on the AWS cloud. These images might contain sensitive information which should be restricted to unauthorized users.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
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 region drop down on the top right corner, for which the alert is generated.
3. Navigate to 'ECR' dashboard from 'Services' dropdown
4. Go to 'Repository', from the left panel
5. Select the repository for which alert is being generated
6. Select the 'Permissions' option from left menu below 'repositores'
7. Click on 'Edit policy JSON' to modify the JSON so that Principal is restrictive
8. After modifications, click on 'Save'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ecr-get-repository-policy' AND json.rule = policy.Statement[?any((Principal equals * or Principal.AWS contains *) and Effect equals Allow and Condition does not exist)] exists```
Azure App Service basic authentication enabled
This policy identifies Azure App Services which have basic authentication enabled.

Basic Authentication allows local identity management for App Services without using a centralized identity provider like Azure Entra ID, posing a security risk by creating isolated identity systems that lack centralized control and are vulnerable to credential compromise and unauthorized access. Disabling Basic Authentication and integrating with a centralized solution like Azure Entra ID enhances security with stronger authentication, improved access management, and reduced attack risks.

As a security best practice, it is recommended to disable basic authentication for Azure App Services.
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. Log in to the Azure portal
2. Navigate to App Services
3. Click on the reported App Service
4. Under 'Settings' section, Click on 'Configuration'
5. Under the 'General settings' tab, scroll down to locate the two Basic Auth settings:
   - Set the 'SCM Basic Auth Publishing Credentials' radio button to Off
   - Set the 'FTP Basic Auth Publishing Credentials' radio button to Off
6. At the top, click on 'Save'
7. Click 'Continue' to save the changes.

Query:
```config from cloud.resource where api.name = 'azure-app-service-basic-publishing-credentials-policies' AND json.rule = properties.allow is true as X; config from cloud.resource where api.name = 'azure-app-service' AND json.rule = properties.state equal ignore case Running as Y; filter '$.X.id contains $.Y.id'; show Y;```
AWS EKS cluster control plane assigned multiple security groups
Amazon EKS strongly recommends that you use a dedicated security group for each cluster control plane (one per cluster). This policy checks the number of security groups assigned to your cluster's control plane and alerts if there are more than one.
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: Create a single dedicated VPC security group for your EKS cluster control plane.

From the AWS console a security group cannot be added to, nor removed from, a Kubernetes cluster once it is created. To resolve this alert, create a new cluster with a single dedicated security group as per your requirements, then migrate all required cluster data from the reported cluster to this newly created cluster and delete the reported Kubernetes cluster.

1. Open the Amazon EKS dashboard.
2. Choose Create cluster.
3. On the Create cluster page, fill in the following fields:

- Cluster name
- Kubernetes version
- Role name
- VPC
- Subnets
- Security Groups - Choose your new dedicated control plane security group.
- Endpoint private access
- Endpoint public access
- Logging

4. Choose Create..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-eks-describe-cluster' AND json.rule =  resourcesVpcConfig.securityGroupIds[*] size greater than 1```
test-p3

This is applicable to azure 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.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 subscription permission for Microsoft Entra tenant is set to 'Allow everyone'
This policy identifies Microsoft Entra tenant that are not configured with restrictions for 'Subscription entering Microsoft Entra tenant' and 'Subscription leaving Microsoft Entra tenant'.

Users who are set as subscription owners can make administrative changes to the subscriptions and move them into and out of the Microsoft Entra tenant. Allowing subscriptions to enter or leave the Microsoft Entra tenant without restrictions can expose the organization to unauthorized access and potential security breaches.

As best practice, it is recommended to configure the settings for 'Subscription entering Microsoft Entra tenant' and 'Subscription leaving Microsoft Entra tenant' to 'Permit no one' to ensure only authorized subscriptions can interact with the tenant, thus enhancing the security of your Azure environment.
This is applicable to azure cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To configure policy settings to control the movement of Azure subscriptions from and into Microsoft Entra tenant follow the below URL:
https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/manage-azure-subscription-policy#setting-subscription-policy.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-subscription-tenantpolicy' AND json.rule = properties.blockSubscriptionsIntoTenant is false or properties.blockSubscriptionsLeavingTenant is false```
GCP Kubernetes Engine private cluster has private endpoint disabled
This policy identifies GCP Kubernetes Engine private clusters with private endpoint disabled. A public endpoint might expose the current cluster and Kubernetes API version and an attacker may be able to determine whether it is vulnerable to an attack. Unless required, disabling the public endpoint will help prevent such threats, and require the attacker to be on the master's VPC network to perform any attack on the Kubernetes API. It is recommended to enable the private endpoint and disable public access on Kubernetes clusters.
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: Once a cluster is created without enabling Private Endpoint, it cannot be remediated. Rather, the cluster must be recreated. 
To create the private cluster with public access disabled, refer to the below link,
https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#private_cp

To resolve the alert, ensure deletion of the old cluster after the new private cluster is created and is in running state and once all the data has been migrated..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = status equals RUNNING and privateClusterConfig exists and privateClusterConfig.enablePrivateEndpoint does not exist```
AWS SSM Parameter is not encrypted
This policy identifies the AWS SSM Parameters which are not encrypted. AWS Systems Manager (SSM) parameters that store sensitive data, for example, passwords, database strings, and permit codes are encrypted so as to meet security and compliance prerequisites. An encrypted SSM parameter is any sensitive information that should be kept and referenced in a protected way.
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. Sign in to the AWS Console
2. Go to System Manager
3. In the navigation panel, Click on 'Parameter Store'
4. Choose the reported parameter and port it to a new parameter with Type 'SecureString'
5. Delete the reported parameter by clicking on 'Delete'
6. Click on 'Delete parameters'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ssm-parameter' AND json.rule = 'type does not contain SecureString'```