knarayan/cloud_posture_checks huggingface dataset:
IBM Cloud Kubernetes clusters are accessible by using public endpoint
This policy identifies IBM Cloud kubernetes clusters which has public service endpoint enabled. If any cluster has public service endpoint enabled, cluster will be accessible on an Internet routable IP address. It is recommended that public service endpoint is disabled and use private service endpoint instead for better security.
This is applicable to ibm cloud and is considered a medium severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. Log in to the IBM Cloud Console
2. Click on 'Menu Icon' and navigate to 'Kubernetes' and then 'Clusters'
3. Select the 'Clusters' reported in the alert
4. Under 'Overview' tab and then 'Networking' section, click the 'Disable' radio button for the public service endpoint.
6. In the next screen, click 'Disable' to confirm.
7. In the next screen, click Refresh to initiate an API server refresh.
5. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-kubernetes-cluster' AND json.rule = type equal ignore case kubernetes and state equal ignore case "normal" and serviceEndpoints.publicServiceEndpointEnabled is true```
OCI users Auth Tokens have aged more than 90 days without being rotated
This policy identifies all of your IAM User Auth Tokens which have not been rotated in the past 90 days. It is recommended to verify that they are rotated on a regular basis in order to protect OCI Auth Tokens access directly or via SDKs or OCI CLI.
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. Select Identity & Security from the Services menu.
3. Select Users from the Identity menu.
4. Click on an individual user under the Name heading.
5. Click on Auth Tokens in the lower left-hand corner of the page.
6. Delete any auth token with a date of 90 days or older under the Created column of the Auth Tokens..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-iam-user' AND json.rule = 'authTokens[?any(lifecycleState equals ACTIVE and (_DateTime.ageInDays(timeCreated) > 90))] exists'```
Custom Azure Guest User with owner permissions
This policy identifies Azure Guest users with owner permissions to the subscription. Removing external users with owner permissions to your subscriptions prevents unmonitored and unwanted access to your subscription. It is recommended to remove guest users' owner permissions from the subscription.

Refer to below link for more details:
https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/users-restrict-guest-permissions
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: To restirct Azure Guest user access follow below URL:
https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/users-restrict-guest-permissions.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-active-directory-user' AND json.rule = userType equals Guest as X; config from cloud.resource where api.name = 'azure-role-assignment' AND json.rule = properties.principalType contains User and properties.roleDefinition.properties.roleName is member of ("Owner") as Y; filter '$.X.id equals $.Y.properties.principalId'; show X;```
AWS IAM user has two active Access Keys
This policy identifies IAM users who have two active Access Keys. Each IAM user can have up to two Access Keys, having two Keys instead of one can lead to increased chances of accidental exposure. So it needs to be ensured that unused Access Keys are deleted.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['KEYS_AND_SECRETS'].
Mitigation of this issue can be done as follows: 1. Sign in to the AWS Console and navigate to the 'IAM' service.
2. Click on Users in the navigation pane.
3. For the identified IAM user which has two active Access Keys, based on policies of your company, take appropriate action.
4. Create another IAM user with the specific objective performed by the 2nd Access Key.
5. Delete one of the unused Access Keys..

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name = 'aws-iam-get-credential-report' AND json.rule = 'access_key_1_active is true and access_key_2_active is true'```
Copy of a Copy Maybe GCP cloud storage bucket with uniform bucket-level access disabled
This policy identifies GCP storage buckets for which the uniform bucket-level access is disabled. Enabling uniform bucket-level access guarantees that if a Storage bucket is not publicly accessible, no object in the bucket is publicly accessible either. It is recommended that uniform bucket-level access is enabled on Cloud Storage buckets.
This is applicable to gcp cloud and is considered a medium severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. log in to GCP Console
2. Navigate to 'Storage'
3. Click on 'Browser' to get the list of storage buckets
4. Search for the alerted bucket and click on the bucket name
5. From the top menu go to 'PERMISSION' tab
6. Under the section 'Access control' click on 'SWITCH TO UNIFORM'
7. On the pop-up window select 'uniform'
8. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-storage-buckets-list' AND json.rule = iamConfiguration.uniformBucketLevelAccess.enabled contains false```
GCP Kubernetes Engine Cluster Nodes have default Service account for Project access
This policy identifies Kubernetes Engine Cluster Nodes which have default Service account for Project access. By default, Kubernetes Engine nodes are given the Compute Engine default service account. This account has broad access and more permissions than are required to run your Kubernetes Engine cluster. You should create and use a least privileged service account to run your Kubernetes Engine cluster instead of using the Compute Engine default service account. If you are not creating a separate service account for your nodes, you should limit the scopes of the node service account to reduce the possibility of a privilege escalation in an attack.
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 Service account can be chosen only at the time of creation of clusters. So to fix this alert, create a new cluster with the least privileged Service account and then migrate all required cluster node data from the reported cluster to this new cluster.
To create the cluster with new Service account which has privileges as you needed, perform following steps:
1. Login to GCP Portal
2. Click on 'CREATE CLUSTER'
3. Choose required name/value for cluster fields
4. Click on 'More'
5. Choose 'Service account' which has the least privilege under Project access section, Instead of default 'Compute Engine default service account'
NOTE: The Compute Engine default service account by default, has devstorage.read_only, logging.write, monitoring, service.management.readonly, servicecontrol, and trace.append privileges/scopes.
You can configure a service account with more restrictive privileges and assign the same.
6. Click on 'Create'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = 'nodePools[*].config.serviceAccount contains default'```
AWS ECR private repository with cross-account access
This policy identifies AWS ECR private repository that are configured with cross-account access. 

An ECR repository is a storage location within Amazon Elastic Container Registry (ECR) where Docker container images are stored and managed. Granting cross-account access to an ECR repository risks unauthorized access and data exposure, requiring strict policy controls and monitoring.

It is recommended to implement strict access controls and allow only trusted entities to access to an ECR repository to mitigate security risks.
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 restrict the access to AWS ECR private repository policy, perform the following actions:
 
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 'ECR' dashboard from the 'Services' dropdown
4. In the navigation pane, choose 'Repositories'
5. On the Repositories page, Select the repository for which the alert is being generated
6. From the repository image list view, in the navigation pane, choose 'Permissions' from 'Actions' dropdown, and Edit.
7. On the Edit permissions page, Click on 'Edit policy JSON' to modify the JSON so that Principal is restrictive
7a. Remove the statements that grant access to actions to other AWS accounts
    or
    7b. Remove the permitted actions from the statements
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(Effect equals Allow and (Principal.AWS does not equal * and Principal does not equal * and Principal.AWS contains arn and Principal.AWS does not contain $.registryId))] exists```
Azure Microsoft Defender for Cloud is set to Off for Key Vault
This policy identifies Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) which has defender setting for Key Vault is set to Off. 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 Key Vault.
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 'Defender plans'
6. Select 'Enable all Microsoft Defender for Cloud plans' if not already enabled
7. On the line in the table for 'Key Vault' Select 'On' under Plan.
8. Select 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = pricings[?any( name equals KeyVaults and properties.pricingTier does not equal Standard)] exists```
GCP Log metric filter and alert does not exist for VPC Network Firewall rule changes
This policy identifies the GCP accounts which do not have a log metric filter and alert for VPC Network Firewall rule changes. Monitoring for Create or Update firewall rule events gives insight network access changes and may reduce the time it takes to detect suspicious activity. It is recommended to create a metric filter and alarm to detect VPC Network Firewall rule changes.
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_firewall_rule" AND jsonPayload.event_subtype="compute.firewalls.patch" OR jsonPayload.event_subtype="compute.firewalls.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_firewall_rule" 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.firewalls.patch" and $.X.filter contains "compute.firewalls.insert"'; show X; count(X) less than 1```
AWS Elastic Load Balancer v2 (ELBv2) load balancer with invalid security groups
This policy identifies Elastic Load Balancer v2 (ELBv2) load balancers that do not have security groups with a valid inbound or outbound rule. A security group with no inbound/outbound rule will deny all incoming/outgoing requests. ELBv2 security groups should have at least one inbound and outbound rule, ELBv2 with no inbound/outbound permissions will deny all traffic incoming/outgoing to/from any resources configured behind that ELBv2; in other words, the ELBv2 is useless without inbound and outbound 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. 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 EC2 Dashboard
4. Click on 'Load Balancers', choose the reported load balancer
5. Click on the 'Description' tab, click on each security group, it will open Security Group properties in a new tab in your browser.
6. For to check the Inbound rule, Click on the 'Inbound Rules'
7. If there are no rules, click on 'Edit rules', add an inbound rule according to your ELBv2 functional requirement.
8. For to check the Outbound rule, Click on the 'Outbound Rules'
9. If there are no rules, click on 'Edit rules', add an outbound rule according to your ELBv2 functional requirement.
10. Click on 'Save'.

Query:
```config from cloud.resource where api.name = 'aws-elbv2-describe-load-balancers' as X; config from cloud.resource where api.name = 'aws-ec2-describe-security-groups' AND json.rule = ipPermissions[*] is empty or ipPermissionsEgress[*] is empty as Y; filter '$.X.securityGroups[*] contains $.Y.groupId'; show X;```
nsk_config_ec2

This is applicable to aws cloud and is considered a informational 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.account = 'AWS Account' AND api.name = 'aws-ec2-describe-instances' AND json.rule = instanceId exists```
AWS RDS retention policy less than 7 days
RDS Retention Policies for Backups are an important part of your DR/BCP strategy. Recovering data from catastrophic failures, malicious attacks, or corruption often requires a several day window of potentially good backup material to leverage. As such, the best practice is to ensure your RDS clusters are retaining at least 7 days of backups, if not more (up to a maximum of 35).
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: Configure your RDS backup retention policy to at least 7 days.

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. Click on  'Modify'.
5. Scroll down to Additional Configuration and set the retention period to at least 7 days under 'Backup retention period'.
6. Click Continue.
7. Under 'Scheduling of modifications' choose 'When to apply modifications'
8. On the confirmation page, Review the changes and Click on 'Modify DB Instance' to save your changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-rds-describe-db-instances' AND json.rule = dbinstanceStatus equals available and (backupRetentionPeriod does not exist or backupRetentionPeriod less than 7)```
GCP Load balancer HTTPS target proxy configured with default SSL policy instead of custom SSL policy
This policy identifies Load balancer HTTPS target proxies which are configured with default SSL Policy instead of custom SSL policy. It is a best practice to use custom SSL policy to access load balancers. It gives you closer control over SSL/TLS versions and ciphers.
This is applicable to gcp 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. Login to GCP Portal
2. Go to Network services (Left Panel)
3. Select Load balancing
4. Click on 'advanced menu' hyperlink to view target proxies
5. Click on 'Target proxies' tab
6. Click on the reported HTTPS target proxy
7. Click on the hyperlink under 'URL map'
8. Click on the 'EDIT' button
9. Select 'Frontend configuration', Click on HTTPS protocol rule
10. For 'SSL policy', choose any custom SSL policy other than 'GCP default'
11. Click on 'Done'
12. Click on 'Update'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-target-https-proxies' AND json.rule = 'sslPolicy does not exist or sslPolicy is empty'```
Azure Automation account configured with overly permissive network access
This policy identifies Automation accounts configured with overly permissive network access. It is recommended to configure the Automation account with private endpoints so that the Automation account is 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: 1. Log in to Azure Portal
2. Go to Automation Account dashboard 
3. Click on the reported Automation account
4. Under the 'Account Settings' menu, click on 'Networking'
5. In 'Public access' tab, select 'Disable' for 'Public network access' 
6. In 'Private access' tab, Create a private endpoint with required parameters 
7. Click on 'Apply'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-automation-account' AND json.rule = properties.publicNetworkAccess does not exist or properties.publicNetworkAccess is true```
GCP Cloud Function HTTP trigger is not secured
This policy identifies GCP Cloud Functions for which the HTTP trigger is not secured. When you configure HTTP functions to be triggered only with HTTPS, user requests will be redirected to use the HTTPS protocol, which is more secure. It is recommended to set the 'Require HTTPS' for configuring HTTP triggers while deploying your function.
This is applicable to gcp 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: 1. Login to GCP console
2. Navigate to 'Cloud Functions' service (Left Panel)
3. Click on the alerting function
4. Click on 'EDIT'
5. Under section 'Trigger', click on 'EDIT'
6. Select the checkbox against the field 'Require HTTPS'
7. Click on 'SAVE'
8. Click on 'NEXT'
9. Click on 'DEPLOY'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-cloud-function' AND json.rule = status equals ACTIVE and httpsTrigger exists and httpsTrigger.securityLevel does not equal SECURE_ALWAYS```
Azure Network Security Group having Inbound rule overly permissive to all traffic on UDP protocol
This policy identifies Azure Network Security Groups (NSGs) which are overly permissive to all traffic on UDP protocol. A network security group contains a list of security rules that allow or deny inbound or outbound network traffic based on source or destination IP address, port, and protocol. As a best practice, it is recommended to configure NSGs to restrict traffic from known sources, allowing only authorized protocols and ports.
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: 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 and Port ranges 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((sourceAddressPrefix equals Internet or sourceAddressPrefix equals * or sourceAddressPrefix equals 0.0.0.0/0 or sourceAddressPrefix equals ::/0) and protocol equals Udp and access equals Allow and direction equals Inbound and destinationPortRange contains *)] exists```
GCP VM instance serial port output logging is enabled
This policy identifies GCP VM instances that have serial port output logging enabled.

The serial console feature in the VM instance does not support IP-based access restrictions such as IP allowlists. If you enable the interactive serial console on an instance, clients can attempt to connect to that instance from any IP address. When the serial port output logging feature is enabled, the serial port output is retained even after an instance is stopped or deleted.

It is recommended to disable serial port access and serial port output logging for all VM instances to avoid leakage of potentially sensitive data.
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: To disable serial port output logging on existing GCP VM instance, follow the below URL:
https://cloud.google.com/compute/docs/troubleshooting/viewing-serial-port-output#enable-stackdriver.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-instances-list' AND json.rule = (status equals RUNNING and name does not start with "gke-") and metadata.items[?any(key contains "serial-port-logging-enable" and value equals "true")] exists```