knarayan/cloud_posture_checks huggingface dataset:
AWS Transit Gateway auto accept vpc attachment is enabled
This policy identifies if Transit Gateways are automatically accepting shared VPC attachments. When this feature is enabled, the Transit Gateway automatically accepts any VPC attachment requests from other AWS accounts without requiring explicit authorization or verification. This can be a security risk, as it may allow unauthorized VPC attachments to connect to the Transit Gateway. As per the best practices for authorization and authentication, it is recommended to turn off the AutoAcceptSharedAttachments feature.
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 transit gateway Auto accept shared attachments:

   1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
   2. On the navigation pane, choose Transit Gateways.
   3. Choose the transit gateway to modify.
   4. Under the ‘Actions' dropdown, choose the ‘Modify transit gateway’ option.
   5. On the 'Modify transit gateway' page, uncheck the 'Auto accept shared attachments' checkbox under the 'Configure cross-account sharing options' section.
   6. Click 'Modify transit gateway' to update the changes..

Query:
```config from cloud.resource where api.name = 'aws-vpc-transit-gateway' AND json.rule = isShared is false and options.autoAcceptSharedAttachments exists and options.autoAcceptSharedAttachments equal ignore case "enable"```
AWS ACM Certificate with wildcard domain name
This policy identifies ACM Certificates which are using wildcard certificates for wildcard domain name instead of single domain name certificates. ACM allows you to use an asterisk (*) in the domain name to create an ACM Certificate containing a wildcard name that can protect several sites in the same domain. For example, a wildcard certificate issued for *.prismacloud.io can match both www.prismacloud.io and images.prismacloud.io. When you use wildcard certificates, if the private key of a certificate is compromised, then all domain and subdomains that use the compromised certificate are potentially impacted. So it is recommended to use single domain name certificates instead of wildcard certificates to reduce the associated risks with a compromised domain or subdomain.
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: To resolve this alert, you have to replace the reported wildcard certificate with single domain name certificate for all the first-level subdomains resulted from the domain name of the website secured with the wildcard certificate and delete the reported wildcard domain certificate.

To create a new certificate with a single domain:
1. Sign into the AWS console
2. In the console, select the specific region from region drop down on the top right corner, for which the alert is generated
3. Navigate to Certificate Manager
4. In 'Request a certificate' page,
a. On Step 1: 'Add domain names' page, in the 'Domain name' box, type the fully qualified domain name. Click on 'Next'
b. On Step 2: 'Select validation method' page, Select the validation method. Click on 'Review'
c. On Step 3: 'Review' page, review the domain name and validation method details. click on 'Confirm'
d. On Step 4: 'Validation' page, validate the certificate request based on the validation method selected. then click on 'Continue'
The certificate status should change from 'Pending validation' to 'Issued'. Now access your application's web server configuration and replace the wildcard certificate with the newly issued single domain name certificate.

To delete wildcard certificate:
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. Under 'Actions' drop-down click on 'Delete'
6. On 'Delete certificate' popup windows, Click on 'Delete' button.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-acm-describe-certificate' AND json.rule = 'domainValidationOptions[*].domainName contains *'```
GCP GKE cluster node boot disk not encrypted with CMEK
This policy identifies GCP GKE clusters that do not have their node boot disk encrypted with CMEK.

The GKE node boot disk is the persistent disk that houses the Kubernetes node file system. By default, this disk is encrypted by a GCP managed key but users can specify customer managed encryption key to get enhanced security, control over the encryption key, and also comply with any regulatory requirements.

It is recommended to use CMEK to encrypt the boot disk of GKE cluster nodes as it gives you full control over the encrypted data.
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: The KMS key used for node boot disk encryption for existing GKE clusters/cluster nodes cannot be changed. 

For standard clusters:
Either create a new standard cluster with node boot disk encryption using CMEK or add new node pools with disk encryption using CMEK to an existing standard cluster while removing older node pools which do not have node boot disk CMEK configured. To encrypt GKE standard cluster node boot disks using CMEK, please refer to the URLs given below:
https://cloud.google.com/kubernetes-engine/docs/how-to/using-cmek#boot-disks

For autopilot clusters:
Autopilot cluster node boot disk encryption cannot be updated for existing autopilot clusters. To create a new autopilot cluster with CMEK protected node boot disk, please refer to the URLs given below:
https://cloud.google.com/kubernetes-engine/docs/how-to/using-cmek#create_a_cluster_with_a_cmek-protected_node_boot_disk.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = status equals "RUNNING" and nodePools[?any(config.bootDiskKmsKey does not exist)] exists```
Azure Monitor log profile does not capture all activities
This policy identifies the Monitor log profiles which are not configured to capture all activities. A log profile controls how the activity log is exported. Configuring the log profile to collect logs for the categories 'Write', 'Delete' and 'Action' ensures that all the control/management plane activities performed on the subscription are exported.
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: On the Azure Portal, there is no provision to check or set categories. However, when a log profile is created using the Azure Portal, Write, Delete and Action categories are set by default.

Log profile activities can be set only through CLI using REST API and CLI is:
1. To list the Log profile run,
az monitor log-profiles list

2. Note the name of reported log profile and replace it with <LOG_PROFILE_NAME> in below command:
az account get-access-token --query "{subscription:subscription,accessToken:accessToken}" --out tsv | xargs -L1 bash -c 'curl -X GET -H "Authorization: Bearer $1" -H "Content-Type: application/json" https://management.azure.com/subscriptions/$0/providers/microsoft.insights/logprofiles/<LOG_PROFILE_NAME>?api-version=2016-03-01' | jq
Copy the JSON output and save it as 'input.json' file.

3. Edit the saved 'input.json' file to add all activities 'Write', 'Delete' and 'Action' in categories JSON array section.

4. Run below command taking 'input.json' as input file,
az account get-access-token --query "{subscription:subscription,accessToken:accessToken}" --out tsv | xargs -L1 bash -c 'curl -X PUT -H "Authorization: Bearer $1" -H "Content-Type: application/json" https://management.azure.com/subscriptions/$0/providers/microsoft.insights/logprofiles/<LOG_PROFILE_NAME>?api-version=2016-03-01 -d@"input.json"'

NOTE: To run all above CLIs you have to be configured with Azure subscription and accessToken locally. And these CLI commands require 'microsoft.insights/logprofiles/*' permission..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-monitor-log-profiles-list' AND json.rule = 'isLegacy is true and (properties.categories[*] does not contain Write or properties.categories[*] does not contain Delete or properties.categories[*] does not contain Action)'```
AWS IAM policy allows assume role permission across all services
This policy identifies AWS IAM policy which allows assume role permission across all services. Typically, AssumeRole is used if you have multiple accounts and need to access resources from each account then you can create long term credentials in one account and then use temporary security credentials to access all the other accounts by assuming roles in those accounts.
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. Navigate to the 'IAM' service.
3. Identify the reported policy
4. Change the Service element of the policy document to be more restrictive so that it only allows AssumeRole permission on select services..

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name = 'aws-iam-get-policy-version' AND json.rule = isAttached is true and document.Statement[?any(Effect equals Allow and Action contains sts:AssumeRole and Resource anyStartWith * and Condition does not exist)] exists and policyArn does not contain iam::aws```
AWS RDS Snapshot with access for unmonitored cloud accounts
This policy identifies RDS snapshots with access for unmonitored cloud accounts. The RDS Snapshot which have either the read / write permission opened up for Cloud Accounts which are NOT part of Cloud Accounts monitored by Prisma Cloud. These accounts with read / write privileges should be reviewed and confirmed that these are valid accounts of your organisation (or authorised by your organisation) and are not active under Prisma Cloud monitoring.
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. Navigate to the RDS service.
4. Select the identified 'RDS Snapshot' under the 'Snapshots' in the left hand menu.
5. Under the tab 'Snapshot Actions', selection the option 'Share Snapshot'.
6. Review and delete the AWS Accounts which should not have read access..

Query:
```config from cloud.resource where cloud.type ='aws' and api.name = 'aws-rds-describe-db-snapshots' AND json.rule = "attributes[?(@.attributeName=='restore')].attributeValues[*] size != 0 and _AWSCloudAccount.isRedLockMonitored(attributes[?(@.attributeName=='restore')].attributeValues) is false"```
Azure VM data disk is encrypted with the default encryption key instead of ADE/CMK
This policy identifies the data disks which are encrypted with the default encryption key instead of ADE/CMK. Azure encrypts data disks by default Server-Side Encryption (SSE) with platform-managed keys [SSE with PMK]. It is recommended to use either SSE with Azure Disk Encryption [SSE with PMK+ADE] or Customer Managed Key [SSE with CMK] which improves on platform-managed keys by giving you control of the encryption keys to meet your compliance need.
This is applicable to azure cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: To enable SSE with Azure Disk Encryption [SSE with PMK+ADE],
Follow https://docs.microsoft.com/en-us/azure/security/azure-security-disk-encryption-prerequisites based VM the data disk is assigned.

To enable SSE with Customer Managed Key [SSE with CMK],
Follow https://docs.microsoft.com/en-us/azure/virtual-machines/disks-enable-customer-managed-keys-portal.

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")'```
Azure Storage account encryption key configured by access policy with privileged operations
This policy identifies Azure Storage accounts which are encrypted by an encryption key configured access policy with privileged operations. Encryption keys should be kept confidential and only accessible to authorized entity with limited operation access. Allowing privileged access to an encryption key also allows to alter/delete the data that is encrypted by it, making the data more easily accessible. It is recommended to have restricted access policies to an encryption key so that only authorized entities can access it with limited operation access. 
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. Navigate to your Storage account and display the Encryption settings
3. Keep note of the Key vault and Key used
4. Navigate to the Key Vault resource noted
5. Select Access policies, select the key noted
6. Click on Edit and make sure only required permissions are checked instead of Select all and only required operations are selected instead of privileged operations as per business requirement..

Query:
```config from cloud.resource where api.name = 'azure-storage-account-list' AND json.rule = properties.encryption.keySource equal ignore case "Microsoft.Keyvault" as X; config from cloud.resource where api.name = 'azure-key-vault-list' and json.rule = properties.enableRbacAuthorization is false and properties.accessPolicies[*].permissions exists and (properties.accessPolicies[*].permissions.keys[*] intersects ('Decrypt', 'Encrypt', 'Release', 'Purge', 'all') or properties.accessPolicies[*].permissions.secrets[*] intersects ('Purge', 'all') or properties.accessPolicies[*].permissions.certificates[*] intersects ('Purge', 'all'))  as Y; filter '$.Y.properties.vaultUri contains $.X.properties.encryption.keyvaultproperties.keyvaulturi'; show X;```
GCP Kubernetes cluster node auto-upgrade configuration disabled
This policy identifies GCP Kubernetes cluster nodes with auto-upgrade configuration disabled. Node auto-upgrades help you keep the nodes in your cluster up to date with the cluster master version when your master is updated on your behalf. When you create a new cluster using Google Cloud Platform Console, node auto-upgrade is enabled by default.

FMI: https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-upgrades
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 Google cloud console
2. Navigate to Google Kubernetes Engine, click on 'Clusters' to get the list
3. Click on the alerted cluster and go to section 'Node pools'
4. Click on a node pool to ensure 'Auto-upgrade' is enabled in the 'Management' section
5. To modify click on the 'Edit' button at the top
6. To enable the configuration click on the check box against 'Enable auto-upgrade'
7. Click on 'Save'
8. Repeat Step 4-7 for each node pool associated with the reported cluster.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = nodePools[?any(management.autoUpgrade does not exist or management.autoUpgrade is false)] exists```
GCP BigQuery dataset is publicly accessible
This policy identifies BigQuery datasets that are anonymously or publicly accessible. Granting permissions to allUsers or allAuthenticatedUsers allows anyone to access the dataset. Such access might not be desirable if sensitive data is being stored in the dataset. So it is recommended to not allow anonymous and/or public access to BigQuery datasets.
This is applicable to gcp cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: 1. Log in to GCP console
2. Navigate to service 'BigQuery'(Left Panel)
3. Under the 'Explorer' section, search for the reported BigQuery dataset and select 'Open' from the kebab menu
4. Click on dropdown 'SHARING' and select 'Permissions'
5. In 'Filter', search for 'allUsers' or 'allAuthenticatedUsers', review each attached role and click the delete icon
6. On the popup 'Remove role from principal?', select the checkbox and click on 'REMOVE'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-bigquery-dataset-list' AND json.rule = iamPolicy.bindings[?any(members[*] equals "allUsers" or members[*] equals "allAuthenticatedUsers")] exists```
GCP Vertex AI Workbench Instance has root access enabled
This policy identifies GCP Vertex AI Workbench Instances that have root access enabled.

Enabling root access on a GCP Vertex AI Workbench instance increases the risk of unauthorized system changes, privilege escalation, and data exposure. It can also make the instance more vulnerable to attacks if not properly secured. Limiting root access and applying strict access controls are essential to reduce these risks.

It is recommended to disable root access for GCP Vertex AI Workbench Instances.
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. Login to the GCP console
2. Navigate to the 'Vertex AI' service
3. In side panel, under 'Notebooks', go to 'Workbench'
4. Under 'INSTANCES' tab, select 'VIEW' as 'INSTANCES'
5. Click on the alerting instance
6. Go to the 'SOFTWARE AND SECURITY' tab
7. Under 'Modify software and security configuration', disable (uncheck) 'Root access to the instance' checkbox
8. At the bottom of the page, click 'SUBMIT'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-vertex-ai-workbench-instance' AND json.rule = state equals "ACTIVE" AND gceSetup.metadata.notebook-disable-root is false```
AWS Redshift cluster instance with public access setting enabled
This policy identifies AWS Redshift clusters with public access setting enabled.

AWS Redshift, a managed data warehousing service typically stores sensitive and critical data. Allowing public access increases the risk of unauthorized access, data breaches, and potential malicious activities.

As a recommended security measure, it is advised to disable public access for the Redshift cluster.
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 modify the publicly accessible setting of the Redshift cluster,
1. Sign 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 'Redshift' service.
4. Click on the checkbox for the identified Redshift cluster name.
5. In the top menu options, click on 'Actions' and select 'Modify publicly accessible setting' as the option.
6. Uncheck the checkbox 'Turn on Publicly accessible' in the 'Publicly accessible' section and click on 'Save Changes' button..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-redshift-describe-clusters' AND json.rule = publiclyAccessible is true```
Azure PostgreSQL database server with log duration parameter disabled
This policy identifies PostgreSQL database servers for which server parameter is not set for log duration. Enabling log_duration helps the PostgreSQL Database to Logs the duration of each completed SQL statement which in turn generates query and error logs. Query and error logs can be used to identify, troubleshoot, and repair configuration errors and sub-optimal performance.
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. Login to Azure console.
2. Navigate to 'Azure Database for PostgreSQL servers' dashboard
3. Click on the alerted database name
4. Go to 'Server parameters' under 'Settings' block
5. From the list of parameters find 'log_duration' and set it to on
6. Click on 'Save' button from top menu to save the change..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-postgresql-server' AND json.rule = "configurations.value[?(@.name=='log_duration')].properties.value equals OFF or configurations.value[?(@.name=='log_duration')].properties.value equals off"```
Azure Storage account containing VHD OS disk is not encrypted with CMK
This policy identifies Azure Storage account containing VHD OS disk which are not encrypted with CMK. VHD's attached to Virtual Machines are stored in Azure storage. By default Azure Storage account is encrypted using Microsoft Managed Keys. It is recommended to use Customer Managed Keys to encrypt data in Azure Storage accounts for better control on the data.
This is applicable to azure cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: 1. Log in to Azure Portal
2. Go to Storage accounts dashboard and Click on the reported storage account
3. Under the Settings menu, click on Encryption
4. Select Customer Managed Keys
- Choose 'Enter key URI' and Enter 'Key URI'
OR
- Choose 'Select from Key Vault', Enter 'Key Vault' and 'Encryption Key'
5. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-vm-list' AND json.rule = ['properties.storageProfile'].osDisk.vhd.uri exists as X; config from cloud.resource where api.name = 'azure-storage-account-list' AND json.rule = properties.encryption.keySource equals "Microsoft.Storage" as Y; filter "$.['X'].['properties.storageProfile'].['osDisk'].['vhd'].['uri'] contains $.Y.name"; show Y;```
GCP Log bucket retention policy not enabled
This policy identifies GCP log buckets for which retention policy is not enabled. Enabling retention policies on log buckets will protect logs stored in cloud storage buckets from being overwritten or accidentally deleted. It is recommended to configure a data retention policy for these cloud storage buckets to store the activity logs for forensics and security investigations.
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. Log in to google cloud console 
2. Navigate to section 'Browser', Under 'Storage' 
3. Select the alerted log bucket
4. In tab ''RETENTION', click on '+SET RETENTION POLICY' to set a retention policy
5. Set a value for 'Retention period' in pop-up 'Set a retention policy'
6. Click on 'SAVE'..

Query:
```config from cloud.resource where api.name = 'gcloud-logging-sinks-list' AND json.rule = 'destination.bucket exists' as X; config from cloud.resource where api.name = 'gcloud-storage-buckets-list' AND json.rule = (retentionPolicy does not exist ) as Y; filter '($.X.destination.bucket contains $.Y.name)'; show Y;```