knarayan/cloud_posture_checks huggingface dataset:
GCP Cloud Run function is using default service account with editor role
This policy identifies GCP Cloud Run functions that are using the default service account with the editor role. 

GCP Compute Engine Default service account is automatically created upon enabling the Compute Engine API. This service account is granted the IAM basic Editor role by default, unless explicitly disabled. Assigning default service account with the editor role to cloud run functions could lead to privilege escalation. Granting minimal access rights helps in promoting a better security posture.

Following the principle of least privileges, it is recommended to avoid assigning default service account with the editor role to cloud run functions.
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: 1. Login to the GCP console
2. Navigate to the 'Cloud Run functions' service
3. Click on the name of the cloud run function on which alert is generated
4. Click 'EDIT' at top
5. Expand 'Runtime, build, connections and security settings' and select 'RUNTIME' tab
6. Under 'Runtime service account', select an appropriate 'Service account' using the dropdown
7. Click 'NEXT' at bottom
8. Click 'DEPLOY' at bottom.

Query:
```config from cloud.resource where cloud.type = 'gcp' and api.name = 'gcloud-projects-get-iam-user' AND json.rule = user contains "compute@developer.gserviceaccount.com" and roles[*] contains "roles/editor" as X; config from cloud.resource where api.name = 'gcloud-cloud-function-v2' AND json.rule = status equals ACTIVE and serviceConfig.serviceAccountEmail contains "compute@developer.gserviceaccount.com" as Y; filter ' $.X.user equals $.Y.serviceConfig.serviceAccountEmail '; show Y;```
IBM Cloud Virtual Servers for VPC instance has interface with IP-spoofing enabled
This policy identifies IBM Cloud Virtual Servers for VPC instances which has any interfaces with IP-spoofing enabled. If any interface has IP-spoofing enabled, there is a chance of bad actors trying to modify the source address in IP packets to invoke a DDoS attack. It is recommended that IP-spoofing is disabled for all interfaces of a virtual server for VPC
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 'VPC Infrastructure' and then 'Virtual server instances'
3. Select the 'Virtual server instance' reported in the alert 
4. Under 'Network interfaces' tab, click on edit icon and set 'Allow IP spoofing' to disabled for each network interface. 
5. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-virtual-server-instance' AND json.rule = status equal ignore case "running" AND network_interfaces[?any( allow_ip_spoofing is true )] exists```
Critical - AWS S3 Object Versioning is disabled
This policy identifies the S3 buckets which have Object Versioning disabled. S3 Object Versioning is an important capability in protecting your data within a bucket. Once you enable Object Versioning, you cannot remove it; you can suspend Object Versioning at any time on a bucket if you do not wish for it to persist. It is recommended to enable Object Versioning on S3.
This is applicable to aws cloud and is considered a critical severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. Log into your AWS Console and select the S3 service.
2. Choose the reported S3 bucket and click the Properties tab in the upper right frame.
3. Expand the Versioning option
4. Click Enable Versioning
5. Click Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = 'versioningConfiguration.status!=Enabled'```
Critical - AWS access keys not used for more than 90 days
This policy identifies IAM users for which access keys are not used for more than 90 days. Access keys allow users programmatic access to resources. However, if any access key has not been used in the past 90 days, then that access key needs to be deleted (even though the access key is inactive).
This is applicable to aws cloud and is considered a critical severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: To delete the reported AWS User access key follow below mentioned URL:
https://aws.amazon.com/premiumsupport/knowledge-center/delete-access-key/.

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_1_last_used_date != N/A and _DateTime.ageInDays(access_key_1_last_used_date) > 90) or (access_key_1_last_used_date == N/A and access_key_1_last_rotated != N/A and _DateTime.ageInDays(access_key_1_last_rotated) > 90))) or (access_key_2_active is true and ((access_key_2_last_used_date != N/A and _DateTime.ageInDays(access_key_2_last_used_date) > 90) or (access_key_2_last_used_date == N/A and access_key_2_last_rotated != N/A and _DateTime.ageInDays(access_key_2_last_rotated) > 90)))'```
rgade-config-policy-01-28-2025
rgade-config-policy-01-28-2025
This is applicable to gcp 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.type = 'gcp' AND api.name = 'gcloud-redis-instances-list' AND json.rule = state equal ignore case ready and not(customerManagedKey contains cryptoKeys)```
AWS SageMaker notebook instance IAM policy overly permissive to all traffic
This policy identifies SageMaker notebook instances IAM policies that are overly permissive to all traffic. It is recommended that the SageMaker notebook instances should be granted access restrictions so that only authorized users and applications have access to the service.

For more details:
https://docs.aws.amazon.com/sagemaker/latest/dg/security_iam_id-based-policy-examples.html
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. Login to AWS console
2. Goto IAM Services
3. Click on 'Policies' in left hand panel
4. Search for the Policy for which the Alert is generated and click on it
5. Under Permissions tab, click on Edit policy
6. Under the Visual editor, for each of the 'SageMaker' Service, click to expand and perform following.
6.a. Click to expand 'Request conditions'
6.b. Under the 'Source IP', remove the row with the entry '0.0.0.0/0' or '::/0'. Add condition with restrictive IP ranges.
7. Click on Review policy and Save changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-policy-version' AND json.rule = document.Statement[?any((Condition.IpAddress.aws:SourceIp contains 0.0.0.0/0 or Condition.IpAddress.aws:SourceIp contains ::/0) and Effect equals Allow and Action anyStartWith sagemaker:)] exists```
IBM Cloud Event Stream is not encrypted with customer-managed key
This policy identifies IBM Cloud Event streams that are not encrypted with a customer-managed key. The customer-managed key allows customers to ensure no one outside their organization has access to the key. And customers will have control over the lifecycle of their customer root keys where they can create, rotate, and delete those keys. As a security best practice, it is recommended to use a customer-managed key, which provides a significant level of control over the keys when used for encryption. 

Note: This policy applies to Enterprise plan Event streams only.
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: An Event stream can be encrypted with customer-managed keys only at the time of creation. Please follow the below instructions to encrypt an event stream with customer-managed keys while creating a new event stream.

1. Log in to the IBM Cloud Console.
2. Click on 'Catalog' on the title bar.
3. Select 'Event Streams' from the list of products, and in the create page select the pricing plan as 'Enterprise'.
4. Under the 'Encryption' section, select a key protect instance under the 'Select a Key Management Service instance' dropdown.
5. Under the 'Select a disk encryption key' dropdown, select a key other than the Automatic disk encryption key.
6. Select other configurations as per the requirements.
7. Click on 'Create'.

Make sure to transfer all the configurations/connections to the newly created Event stream before deleting the non-encrypted Event stream. Delete the vulnerable Event stream using the below instructions:

1. Log in to the IBM Cloud Console.
2. Go to Menu > 'Resource List', From the 'Integration' section, select the reported event stream.
3. Click on 'Actions' button, then click on 'Delete service'.
4. Click on 'OK' to confirm..

Query:
```config from cloud.resource where api.name = 'ibm-event-streams-instance' AND json.rule = resource_plan_id is not member of ('ibm.eventstreams.lite', 'ibm.eventstreams.standard' ) as X; config from cloud.resource where api.name = 'ibm-key-protect-registration' as Y;filter 'not($.Y.resourceCrn equals $.X.crn)' ; show X;```
GCP Cloud Function with overly permissive network ingress settings
This policy identifies GCP Cloud Functions that have overly permissive network ingress settings. This includes both Cloud Functions v1 and Cloud Functions v2.

Ingress settings control whether resources outside of your Google Cloud project or VPC Service Controls perimeter can invoke a function.  With overly permissive ingress setting, all inbound requests to invoke function are allowed, both from the public and from resources within the same project. Restrictive network ingress settings for cloud functions in GCP minimize the risk of unauthorized access and attacks by limiting inbound traffic to trusted sources. This approach enhances security, prevents malicious activities, and ensures only legitimate traffic reaches your applications.

It is recommended to restrict the public traffic and allow traffic from VPC networks in the same project or traffic through the Cloud Load Balancer.
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: 1. Login to GCP console
2. Navigate to 'Cloud Functions' service
3. Click on the alerting function
4. Click on 'EDIT'
5. Click on 'Runtime, build, connections and security settings' drop-down to get the detailed view
6. Click on the 'CONNECTIONS' tab
7. In 'Ingress settings', select either 'Allow internal traffic only' or 'Allow internal traffic and traffic from Cloud Load Balancing'
8. Click on 'NEXT'
9. Click on 'DEPLOY'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-cloud-function-v2' AND json.rule = state equals ACTIVE and serviceConfig.ingressSettings equals ALLOW_ALL```
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 ['MISCONFIGURATION'].
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```
AWS MSK cluster encryption in transit is not enabled
This policy identifies AWS Managed Streaming for Apache Kafka clusters having in-transit encryption in a disabled state.

In-transit encryption secures data while it's being transferred between brokers. Without it, there's a risk of data interception during transit.

It is recommended to enable in-transit encryption among brokers within the cluster. This ensures that all data exchanged within the cluster is encrypted, effectively protecting it from potential eavesdropping and unauthorized access.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To enable in-transit encryption both within the cluster and client broker communication has to be configured with TLS.

To enable TLS encryption for client-broker communication, follow the below steps:
1. Sign in to the AWS Management Console and open the Amazon MSK console at https://console.aws.amazon.com/msk/.
2. On the navigation menu, choose 'Clusters', and select the MSK cluster for which you want to enable or edit in-transit encryption.
3. Under the 'Actions' dropdown, select 'Edit security settings'. 
4. Under 'Encryption', please uncheck the 'Plaintext' option and make sure the 'TLS encryption' option is selected for  'Between clients and brokers' encryption configuration.
5. Click on 'Update' to save changes.

Enabling TLS encryption for within-cluster communication involves creating a new cluster. To create a new cluster, please follow the below steps:
1. Sign in to the AWS Management Console and open the Amazon MSK console at https://console.aws.amazon.com/msk/.
2. On the navigation menu, choose 'Clusters', then select 'Create cluster'.
3. Under the 'Create Cluster' page, please configure the cluster as per the requirements.
4. At Step 3, under 'Encryption', select 'TLS encryption' for the 'Between clients and brokers' checkbox.
5. Select 'TLS encryption' for the 'Within the cluster' checkbox.
6. After providing the required configuration in the remaining steps, Under step 5, click on 'Create cluster'..

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name = 'aws-msk-cluster' AND json.rule = state equal ignore case active and encryptionInfo.encryptionInTransit.clientBroker contains PLAINTEXT or encryptionInfo.encryptionInTransit.inCluster is false```
AWS RDS instance delete protection is disabled
This policy identifies RDS instances for which delete protection is disabled. Enabling delete protection for these RDS instances prevents irreversible data loss resulting from accidental or malicious operations.
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 the Amazon RDS dashboard 
4. Click on the DB instances
5. Select the reported DB instance
6. Click on the 'Modify' button
7. In Modify DB instance page, In the 'Additional configuration' section, Check the box 'Enable deletion protection' for Deletion protection..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-rds-describe-db-instances' AND json.rule = dbinstanceStatus contains available and dbclusterIdentifier does not exist and deletionProtection is false```
AWS IAM user has both Console access and Access Keys
This policy identifies IAM users who have both Console access and Access Keys. When an IAM user is created, the Administrator can assign either Console access or Access Keys or both. Ideally the Console access should be assigned to Users and Access Keys for system / API applications, but not both to the same IAM user.
This is applicable to aws cloud and is considered a low 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. Identify the reported IAM user.
3. In 'Security credentials' tab check for presence of Access Keys.
4. Based on the requirement and company policy, either delete the Access Keys or remove the Console access for this IAM user..

Query:
```config from cloud.resource where cloud.type ='aws' and api.name = 'aws-iam-get-credential-report' AND json.rule = 'password_enabled is true and (access_key_1_active is true or access_key_2_active is true)'```
AWS CloudWatch Log groups not encrypted by Customer Managed Key (CMK)
This policy identifies AWS CloudWatch Log groups that are encrypted using the default KMS key instead of CMK (Customer Managed Key) or using a CMK that is disabled.

A CloudWatch Log Group is a collection of log streams that share the same retention, monitoring, and access control settings. Encrypting with a Customer Managed Key (CMK) provides additional control over key rotation, management, and access policies compared to the default encryption.

As a security best practice, using CMK to encrypt your CloudWatch Log Groups is advisable as it gives you full control over the encrypted data.
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 change the encryption key for a AWS CloudWatch Log groups:

Use the associate-kms-key command as follows:

aws logs associate-kms-key --log-group-name <Loggroup name that is reported> --kms-key-id <KMS CMK KEY ARN>

Note: When using customer-managed CMKs to encrypt AWS CloudWatch Log groups, Ensure authorized entities have access to the key and its associated operations..

Query:
```config from cloud.resource where api.name = 'aws-cloudwatch-log-group' as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' AND json.rule = keyMetadata.keyManager does not equal CUSTOMER or (keyMetadata.keyManager equals CUSTOMER and keyMetadata.keyState equals Disabled) as Y; filter '($.X.kmsKeyId does not exist ) or ($.X.kmsKeyId exists and $.X.kmsKeyId equals $.Y.keyMetadata.arn)'; show X;```
Azure Virtual machine configured with public IP and serial console access
This policy identifies Azure Virtual machines with public IP configured with serial console access (via Boot diagnostic setting).

The Microsoft Azure serial console feature provides access to a text-based console for virtual machines (VMs) running either Linux or Windows. Serial Console connects to the ttyS0 or COM1 serial port of the VM instance, providing access independent of the network or operating system state. Attacker can leverage public IP assigned Serial console enabled virtual machine for remote code execution and privilege escalation. It is recommended to restrict public access to the reported virtual machine and disable/restrict serial console access.

NOTE: Serial Console can be disabled for an individual Virtual machine instance by boot diagnostics only.
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: To disable/restrict serial console access on the reported VM instance, follow bellow URL:
https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-enable-disable.

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name= 'azure-vm-list' AND json.rule = powerState contains "PowerState/running" and ['properties.networkProfile'].['networkInterfaces'][*].['publicIpAddressId'] exists and ['properties.diagnosticsProfile'].['bootDiagnostics'].['enabled'] is true```
GCP IAM Service account has admin privileges
This policy identifies service accounts which have admin privileges. Application uses the service account to make requests to the Google API of a service so that the users aren't directly involved. It is recommended not to use admin access for ServiceAccount.
This is applicable to gcp 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: 1.Login to GCP Portal
2.Goto IAM & admin (Left panel)
3.Choose the reported member and click on the edit icon
4.Delete the Admin role and provide appropriate role according to requirement.
5.Click Save.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-projects-get-iam-user' AND json.rule = user contains iam.gserviceaccount.com AND (roles[*] contains admin or roles[*] contains Admin or roles[*] contains roles/editor or roles[*] contains roles/owner)```
GCP PostgreSQL instance database flag log_statement is not set appropriately
This policy identifies PostgreSQL database instances in which database flag log_statement is not set appropriately. If log_statement is not set to a correct value may lead to too many statements or too few statements. Setting log_statement to align with your organization's security and logging policies facilitates later auditing and review of database activities. It is recommended to choose an appropriate value (ddl or mod) for the flag log_statement.
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. Log in to GCP console
2. Navigate SQL Instances page
3. Click on reported PostgreSQL instance
4. Click EDIT
5. If the flag has not been set on the instance, 
Under 'Customize your instance', click on 'ADD FLAG' in 'Flags' section, choose the flag 'log_statement' from the drop-down menu and set the value as ddl or mod
OR
If the flag has been set to other than ddl or mod, Under 'Customize your instance', In 'Flags' section choose the flag 'log_statement' and set the value as ddl or mod
6. Click on 'DONE' and then 'SAVE'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = state equals RUNNABLE and databaseVersion contains POSTGRES and ( settings.databaseFlags[?any( name equals "log_statement" )] does not exist or settings.databaseFlags[?any( name equals "log_statement" and value equals "all" or value equals "none" )] exists)```
GCP IAM user with service account privileges
Checks to ensure that IAM users don't have service account privileges. Adding any user as service account actor will enable these users to have service account privileges. Adding only authorized corporate IAM users as service account actors will make sure that your information is secure.
This is applicable to gcp cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['HIGH_PRIVILEGED_ROLE'].
Mitigation of this issue can be done as follows: 1. Login to GCP Portal
2. Go to IAM & Admin (Left Panel)
3. Select IAM 
4. From the list of users, identify the users with Service Account Actor, Service Account User or Service Account Token Creator roles
5. Remove these user roles by clicking on Delete icon for any unauthorized user.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-projects-get-iam-user' AND json.rule = '(roles[*] contains roles/iam.serviceAccountActor) or (roles[*] contains roles/iam.serviceAccountUser) or (roles[*] contains roles/iam.serviceAccountTokenCreator)'```