knarayan/cloud_posture_checks huggingface dataset:
AWS EC2 Client VPN endpoints client connection logging disabled
This policy identifies AWS EC2 client VPN endpoints with client connection logging disabled.

AWS Client VPN endpoints enable remote clients to securely connect to resources in the Virtual Private Cloud (VPC). Connection logs enable you to track user behaviour on the VPN endpoint and gain visibility.

It is recommended to enable connection logging for AWS EC2 client VPN endpoints.
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 enable connection logging for a new Client VPN endpoint, follow these steps:

1. Sign into the AWS console and navigate to the Amazon VPC console
2. In the navigation pane, choose 'Client VPN Endpoints'
3. Select the 'Client VPN endpoint', choose 'Actions', and then choose 'Modify Client VPN endpoint'
4. Under 'Connection logging', turn on 'Enable log details on client connections'
5. For 'CloudWatch Logs log group name', choose the name of the CloudWatch Logs log group
6. (Optional) For 'CloudWatch Logs log stream name', choose the name of the CloudWatch Logs log stream
7. Choose 'Modify Client VPN endpoint'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-client-vpn-endpoint' AND json.rule = status.code equal ignore case available and connectionLogOptions.Enabled is false```
bobby 3/28

This is applicable to alibaba_cloud 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 = 'alibaba-cloud-ecs-disk' AND json.rule = category contains "foo" ```
IBM Cloud Virtual Private Cloud (VPC) security group contains outbound rules that specify source IP 8.8.8.8/32 to DNS port
This policy identifies IBM Virtual Private Cloud (VPC) security groups that contain outbound rules that specify a source IP 8.8.8.8/32 to DNS port. Doing so, may allow sensitive data from the protected resource being leaked to Google, which uses data for indexing and monetizing. As a best practice, restrict DNS port (53) solely to known static IP addresses. Limit the access list to include known hosts, services, or specific employees only.
This is applicable to ibm cloud and is considered a low severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: Before making any changes, please check the impact to your applications/services. If the Security Groups reported indeed need to restrict all traffic, follow the instructions below:
1. Log in to the IBM Cloud Console
2. Click on 'Menu Icon' and navigate to 'VPC Infrastructure' and then 'Security Groups'
3. Select the 'Security Groups' reported in the alert
4. Go to 'Outbound rules' under 'Rules' tab
5. Click on three dots on the right corner of a row containing rule that has 'Destination type' as 'Any' and 'Value' as 53 (or range containing 53)
6. Click on 'Delete'.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-network-security-group' AND json.rule = rules[?any( remote.cidr_block equals "8.8.8.8/32" and direction equals "outbound" and ( protocol equals "all" or ( protocol equals "tcp" and ( port_max greater than 53 and port_min less than 53 ) or ( port_max equals 53 and port_min equals 53 ))))] exists```
AWS CloudFront web distribution with default SSL certificate
This policy identifies CloudFront web distributions which have a default SSL certificate to access CloudFront content. It is a best practice to use custom SSL Certificate to access CloudFront content. It gives you full control over the content data. custom SSL certificates also allow your users to access your content by using an alternate domain name. You can use a certificate stored in AWS Certificate Manager (ACM) or you can use a certificate stored in IAM.
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 in to the AWS console
2. Select the region, from the region drop-down, in which the alert is generated
3. Navigate to CloudFront Distributions Dashboard
4. Click on the reported distribution
5. On the 'General' tab, Click on the 'Edit' button
6. On 'Edit Distribution' page set 'SSL Certificate' to 'Custom SSL Certificate (example.com):', Select a certificate or type your certificate ARN in the field and other parameters as per your requirement.
7. Click on 'Yes, Edit'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = 'viewerCertificate.certificateSource contains cloudfront'```
Azure Network Security Group allows all traffic on MySQL (TCP Port 3306)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on MySQL (TCP Port 3306). Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict MySQL 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(3306,3306) or destinationPortRanges[*] contains _Port.inRange(3306,3306) ))] exists```
AWS Certificate Manager (ACM) has expired certificates
This policy identifies expired certificates which are in AWS Certificate Manager. AWS Certificate Manager (ACM) is the preferred tool to provision, manage, and deploy your server certificates. With ACM you can request a certificate or deploy an existing ACM or external certificate to AWS resources. This policy generates alerts if there are any expired ACM managed certificates. As a best practice, it is recommended to delete expired certificates.
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. Go to Certificate Manager(ACM) service
4. Choose the reported certificate
5. Verify that the 'Status' column shows 'Expired' for the reported certificate
6. Under 'Actions' drop-down click on 'Delete'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-acm-describe-certificate' AND json.rule = '(_DateTime.ageInDays($.notAfter) > -1) and status equals EXPIRED'```
GCP Kubernetes Engine Clusters have Alias IP disabled
This policy identifies Kubernetes Engine Clusters which have disabled Alias IP. Alias IP allows the networking layer to perform anti-spoofing checks to ensure that egress traffic is not sent with arbitrary source IPs. By enabling Alias IPs, Kubernetes Engine clusters can allocate IP addresses from a CIDR block known to Google Cloud Platform. This makes your cluster more scalable and allows your cluster to better interact with other GCP products and entities.
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 Alias IP can be enabled only at the time of creation of clusters. So to fix this alert, create a new cluster with Alias IP enabled and then migrate all required cluster data or containers from the reported cluster to this new cluster.
To create the cluster with Alias IP enabled, perform following steps:
1. Login to GCP Portal
2. Go to Kubernetes Engine (Left Panel)
3. Select Kubernetes clusters
5. Click on 'CREATE CLUSTER' button
6. Configure your cluster and click on 'More'
7. From the 'VPC-native (using alias IP)' drop-down menu, select 'Enabled'. New menu items appear
8. From 'Automatically create secondary ranges' drop-down menu, select 'Enabled' 
9. Configure the 'Network', 'Node subnet', 'Node address range', 'Container address range', and 'Service address range' as needed
10. Click on Create.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = 'ipAllocationPolicy.useIpAliases does not exist or ipAllocationPolicy.useIpAliases equals false'```
AWS SNS topic policy overly permissive for subscription
This policy identifies AWS SNS topics that have SNS policy overly permissive for the subscription. When you subscribe an endpoint to a topic, the endpoint begins to receive messages published to the associated topic. To protect these messages from attackers and unauthorized accesses, permissions should be given to only authorized users.

For more details:
https://docs.aws.amazon.com/sns/latest/dg/sns-security-best-practices.html#implement-least-privilege-access
This is applicable to aws cloud and is considered a low 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 the region drop-down on the top right corner, for which the alert is generated.
3. Navigate to the 'Simple Notification Service' dashboard
4. Go to 'Topics', from the left panel
5. Select the reported SNS topic
6. Click on the 'Edit' button from the top options bar
7. On the edit page go to the 'Access Policy - optional' section
8. Add the restrictive 'Condition' statement to the JSON editor to specify who can subscribe to this topic.
9. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-sns-get-topic-attributes' AND json.rule = Policy.Statement[?any(Effect equals Allow and (Principal.AWS equals * or Principal equals *) and (Action contains SNS:Subscribe or Action contains sns:Subscribe or Action contains SNS:Receive or Action contains sns:Receive) and Condition does not exist)] exists```
AWS VPC gateway endpoint policy is overly permissive
This policy identifies AWS VPC gateway endpoints that have a VPC endpoint (VPCE) policy that is overly permissive. When the Principal element value is set to '*' within the access policy, the VPC gateway endpoint allows full access to any IAM user or service within the VPC using credentials from any AWS accounts. It is highly recommended to have the least privileged VPCE policy to protect the data leakage and unauthorized access.

For more details:
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.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: 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 the VPC dashboard
4. Go to 'Endpoints', from the left panel VIRTUAL PRIVATE CLOUD section
5. Select the reported VPC endpoint
6. On the 'Actions' drop-down button, click on the 'Manage policy'
8. On the 'Edit Policy' page, Choose 'Custom' policy
a. Then add policy, without the 'Everyone' grantee (i.e. '*' or 'AWS': '*') from the Principal element value with an AWS account ID (e.g. '123456789'), an AWS account ARN (e.g. 'arn:aws:iam::123456789:root') or an IAM user ARN (e.g. 'arn:aws:iam::123456789:user/vpce-admin').
b. Add a Condition clause to the policy statement to filter the endpoint access to specific entities.
9. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-describe-vpc-endpoints' AND json.rule = vpcEndpointType equals Gateway and policyDocument.Statement[?any(Effect equals Allow and (Principal.AWS equals * or Principal equals *) and Action contains * and Condition does not exist)] exists```
IBM Cloud Secrets Manager arbitrary secrets have aged more than 90 days without being rotated
This policy identifies IBM Cloud Secrets Manager arbitrary secrets that have aged more than 90 days without being rotated. Arbitrary secrets should be rotated to ensure that data cannot be accessed with an old secret which might have been lost, cracked, or stolen. It is recommended that all arbitrary secrets are regularly rotated.
This is applicable to ibm cloud and is considered a informational severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. Log in to the IBM Cloud Console
2. Click on Menu Icon and navigate to 'Resource list'. From the list of resources, select the secret manager instance in which the reported secret resides, under security section.
3. Select the secret and click on 'Actions' dropdown.
4. Select 'Rotate' from the dropdown.
5. In the 'Rotate secret' screen, provide data as required.
6. Click on 'Rotate'..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-secret-manager-secret' AND json.rule = 'secret_type equals arbitrary and state_description equal ignore case active and (_DateTime.ageInDays(last_update_date) > 90)'```
Azure Cosmos DB allows traffic from public Azure datacenters
This policy identifies Cosmos DBs that allow traffic from public Azure datacenters. If you enable this option, the IP address 0.0.0.0 is added to the list of allowed IP addresses. The list of IPs allowed by this option is wide, so it limits the effectiveness of a firewall policy. So it is recommended not to select the ‘Accept connections from within public Azure datacenters’ option for your Cosmos DB. 
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 the Azure Portal
2. Go to Azure Cosmos DB service
3. Select the reported Azure Cosmos DB account
4. Click on 'Firewall and virtual networks' under 'Settings'
5. Unselect 'Accept connections from within public Azure datacenters' option under 'Exceptions'
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cosmos-db' AND json.rule = properties.provisioningState equals Succeeded and properties.ipRangeFilter is not empty and properties.ipRangeFilter startsWith 0.0.0.0 or properties.ipRangeFilter endsWith 0.0.0.0```
Azure Storage account key expiration policy is not configured
This policy identifies Azure Storage accounts for which key expiration policy is not configured.

A key expiration policy enables you to set a reminder for the rotation of the account access keys, so that you can monitor your storage accounts for compliance to ensure that the account access keys are rotated regularly.

As a best practice, it is recommended to set key expiration policy for Azure Storage account keys.
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 the Storage Accounts dashboard
3. Click on the reported Storage account
4. Under the 'Security + networking', select 'Access keys'
5. Select the 'Set rotation reminder' button. If the Set rotation reminder button is grayed out, you will need to rotate each of your keys manually.
6. In Set a reminder to rotate access keys, select the 'Enable key rotation reminders' checkbox and set a frequency for the reminder.
7. Click on 'Save'

NOTE: Before you can create a key expiration policy, you may need to rotate each of your account access keys at least once..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-storage-account-list' AND json.rule = properties.provisioningState equal ignore case Succeeded and properties.keyPolicy.keyExpirationPeriodInDays does not exist```
GCP backend bucket having dangling GCP Storage bucket
This policy identifies the GCP backend buckets having dangling GCP Storage bucket.

A GCP backend bucket is usually used by GCP Load Balancers for serving static content. Such setups can also have DNS pointing to the load balancer's IP for easy human access. A GCP backend bucket pointing to a GCP storage bucket that doesn't exist in the same project is a potential risk of bucket takeover as well as at risk of subdomain takeover. An attacker can exploit such a setup by creating a GCP Storage bucket with the same name in their own GCP project, thus receiving all requests redirected to this backend bucket from the load balancer to an attacker-controlled GCP Storage bucket. This attacker-controlled bucket can be used to serve malicious content to perform phishing attacks, spread malware, or engage in other illegal activities.

As a best practice, it is recommended to review and protect GCP storage buckets bound to a GCP backend bucket from accidental deletion. Delete the GCP backend bucket if it points to a non-existent GCP storage bucket.
This is applicable to gcp cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To mitigate the risk, either delete the GCP backend bucket or create a GCP Storage bucket with the name in your account to which the GCP backend bucket points.


# Delete GCP backend bucket
To delete a GCP backend bucket, it should be disassociated from all GCL Load balancers first. The following steps might be followed:

1. Identify the backend bucket pointing to a non-existing GCP Storage bucket.
2. Login to GCP Portal
3. Go to Network services -> Load Balancing
4. Click on "Backends"
5. Note the names of load balancers that are using the GCP backend bucket. Names are shown under the "Load balancer" column
6. Click on the "LOAD BALANCERS" tab
7. Click on the load balancer name for each load balancer identified in step 4 and repeat the following steps:
 i. After opening the load balancer page, click on "EDIT"
  ii. Go to Backend configuration
 iii. Under the "Backend buckets" section, remove the GCP backend bucket by clicking "cross" icon in front of it
 iv. Go to Routing rules. Edit the rules as desired. Remove any rules pointing to the reported backend bucket.
 v. Click Update
8. Click and switch back to the "Backends" tab
9. Select the GCP backend bucket, the option to delete now should be available.
10. Click "Delete" -> "DELETE"


# Create a new GCP Storage bucket
Refer to the following link on how to create a new GCP Storage bucket and create a new bucket with the same name as the one the GCP backend bucket is pointing to:

https://cloud.google.com/storage/docs/creating-buckets#create_a_new_bucket.

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;```
IBM Cloud Block Storage Snapshot for VPC is not encrypted with customer managed keys
This policy identifies IBM Cloud Block Storage Snapshots for VPC, which are not encrypted with customer managed keys. Using customer managed keys will increase significant control where keys are managed by customers. As a best practice, use customer managed keys to encrypt the data and maintain control of your keys and sensitive data.
This is applicable to ibm cloud and is considered a informational severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: A Block storage snapshot can be encrypted with customer managed keys only at the time of creation of a virtual server instance. 
Please create a virtual service instance with boot/data disk from the reported snapshot using below URL. Please make sure to select customer managed encryption for data/boot storage volume:
https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-restore&interface=ui#snapshots-vpc-restore-vol-ui

Create a snapshot for above created storage disk volume following below URL:
https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-create&interface=ui#snapshots-vpc-create-from-vol-details

Once a  new snapshot got created, delete the virtual server instance to which the created storage volume/snapshot got attached:
https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-remove_vs#delete_vs.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-block-storage-snapshot' AND json.rule = encryption equal ignore case provider_managed```
Azure VM data disk is not configured with any encryption
This policy identifies VM data disks that are not configured with any encryption. Azure encrypts data disks that are not configured with any encryption. Azure offers Server-Side Encryption (SSE) with platform-managed keys [SSE with PMK] by default for managed disks. It is recommended to enable default encryption or you may optionally choose to use a customer-managed key to protect from malicious activity.
This is applicable to azure 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. Log in to the Azure Portal
2. Navigate to 'Disks'
3. Select the reported OS disk you want to modify
4. Select 'Encryption' under 'Settings'
5. Select 'Encryption Type' according to your encryption requirement.
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-disk-list' AND json.rule = osType does not exist and managedBy exists and (encryptionSettings does not exist or encryptionSettings.enabled is false) and encryption.type is not member of ("EncryptionAtRestWithCustomerKey", "EncryptionAtRestWithPlatformAndCustomerKeys","EncryptionAtRestWithPlatformKey")```