knarayan/cloud_posture_checks huggingface dataset:
Azure subscriptions with custom roles are overly permissive
This policy identifies azure subscriptions with custom roles are overly permissive. Least privilege access rule should be followed and only necessary privileges should be assigned instead of allowing full administrative access.
This is applicable to azure cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: Check the usage of the role identified. Verify impact caused by Updating/deleting the role. Then follow below URL for updating or deleting custom role:
https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles-portal#update-a-custom-role.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-role-definition' AND json.rule = properties.type equals "CustomRole" and properties.assignableScopes[*] contains "/" and properties.permissions[*].actions[*] starts with "*"```
Alibaba Cloud ActionTrail logging is disabled
This policy identifies ActionTrails which have logging disabled. As a best security practice, it is recommended to enable logging, as ActionTrail logs can be used in scenarios as security analysis, resource change tracking, and compliance audit.
This is applicable to alibaba_cloud 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 Alibaba Cloud Portal
2. Go to ActionTrail
3. In the left navigation pane, click on 'Trail List'
4. Click on reported trail
5. In the upper right corner of the configuration page, move the slider to the right to start logging for the trail.
6. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-action-trail' AND json.rule =  'status equals Disable and isLogging is false'```
OCI IAM local (non-federated) user account does not have a valid and current email address
This policy identifies the OCI Iam local (non-federated) users that do not have valid and current email address configured. It is recommended that OCI Iam local (non-federated) users are configured with valid and current email address to tie the account to identity in your organization. It also allows that user to reset their password if it is forgotten or lost.
This is applicable to oci 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 into OCI Console
2. Select Identity from Services menu
3. Select Users from Identity menu
4. Click on the local (non-federated) user reported in the alert
5. Click on Edit User
6. Enter a valid and current email address in the EMAIL text box
7. Click Save Changes.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-iam-user' AND json.rule = externalIdentifier contains null and (email does not exist or emailVerified is false)```
GCP storage bucket is logging to itself
This policy identifies GCP storage buckets that are sending logs to themselves. When storage buckets use the same bucket to send their access logs, a loop of logs will be created, which is not a security best practice. It is recommended to spin up new and different log buckets for storage bucket logging.
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 resolve the alert, a new bucket should be created or an existing bucket other than the alerting bucket itself should be set for logging by following steps in the below-mentioned link.

https://cloud.google.com/storage/docs/access-logs#delivery.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name= 'gcloud-storage-buckets-list' AND json.rule = logging.logBucket equals $.name```
Azure Network Watcher Network Security Group (NSG) flow logs are disabled
This policy identifies Azure Network Security Groups (NSG) for which flow logs are disabled. To perform this check, enable this action on the Azure Service Principal: 'Microsoft.Network/networkWatchers/queryFlowLogStatus/action'.

NSG flow logs, a feature of the Network Watcher app, enable you to view information about ingress and egress IP traffic through an NSG. The flow logs include information such as:
- Outbound and inbound flows on a per-rule basis.
- Network interface to which the flow applies.
- 5-tuple information about the flow (source/destination IP, source/destination port, protocol).
- Whether the traffic was allowed or denied.

As a best practice, enable NSG flow logs to improve network visibility.
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: To configure Network Watcher Network Security Group (NSG) flow log, follow below URL:
https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-nsg-flow-logging-portal#enable-nsg-flow-log.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-network-nsg-list' AND json.rule = flowLogsSettings does not exist or flowLogsSettings.enabled is false```
GCP Vertex AI Workbench Instance has Integrity monitoring disabled
This policy identifies GCP Vertex AI Workbench Instances that have Integrity monitoring disabled.

Integrity Monitoring continuously monitors the boot integrity, kernel integrity, and persistent data integrity of the underlying VM of the shielded workbench instances. It detects unauthorized modifications or tampering, enhancing security by verifying the trusted state of VM components throughout their lifecycle. Integrity monitoring provides active alerts, enabling administrators to respond to integrity failures and prevent compromised nodes from being deployed into the cluster.

It is recommended to enable Integrity Monitoring for Workbench instances to detect and mitigate advanced threat, such as rootkits and bootkit malware.
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 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. Under the 'SYSTEM' tab, in front of 'VM details', click on the 'View in Compute Engine' link
7. Stop the VM by clicking on the 'STOP' button. Click the 'STOP' button on the confirmation dialogue.
8. Once the the VM has been stopped, click on the 'EDIT' button
9. Under 'Shielded VM', enable 'Turn on vTPM'
10. Enable 'Turn on Integrity Monitoring'
11. Click on 'Save'
12. Click on 'START/RESUME' from the top menu.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-vertex-ai-workbench-instance' AND json.rule = state equals "ACTIVE" AND shieldedInstanceConfig.enableIntegrityMonitoring is false```
VenuTestPolicyRem

This is applicable to azure cloud and is considered a low severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-storage-account-list' AND json.rule = properties.supportsHttpsTrafficOnly !exists```
AWS API gateway request parameter is not validated
This policy identifies the AWS API gateways for which the request parameters are not validated. When the validation fails, API Gateway fails the request, returns a 400 error response to the caller, and publishes the validation results in CloudWatch Logs. It is recommended to perform basic validation of an API request before proceeding with the integration request to block unvalidated calls to the backend.
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. Login to AWS management console
2. Navigate to 'API Gateway' service
3. Select the region for which the API gateway is reported.
4. Find the alerted API by the API gateway ID which is the first part of reported resource and click on it
5. Navigate to the reported method
6. Click on the clickable link of 'Method Request'
7. Under section ‘Settings' ,click on the pencil symbol for 'Request Validator' field
8. From the dropdown, Select the type of Request Validator as per the requirement
9. Click on the tick symbol next to it to save the changes
.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-apigateway-method' AND json.rule = requestValidatorId does not exist ```
Azure Microsoft Defender for Cloud automatic provisioning of log Analytics agent for Azure VMs is set to Off
This policy identifies the Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) which has automatic provisioning of log Analytics agent for Azure VMs is set to Off. Microsoft Defender for Cloud provisions the Microsoft Monitoring Agent on all existing supported Azure virtual machines and any new ones that are created. The Microsoft Monitoring Agent scans for various security-related configurations and events such as system updates, OS vulnerabilities, endpoint protection, and provides alerts.
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' dashboard
3. Select 'Environment Settings'
4. Click on the reported subscription name
5. Select the 'Settings & monitoring'
6. Set Status 'On' for 'Log Analytics agent/Azure Monitor agent' component
7. Click on 'Continue'
8. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = 'autoProvisioningSettings[*].name equals default and (autoProvisioningSettings[*].properties.autoProvision equals Off or autoProvisioningSettings[*] does not exist)'```
Azure SQL server using insecure TLS version
This policy identifies Azure SQL servers which use insecure TLS version.

Enforcing TLS connections between database server and client applications helps protect against 'man in the middle' attacks by encrypting the data stream between the server and application.

As a security best practice, it is recommended to use the latest TLS version for Azure SQL server.
This is applicable to azure cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to the Azure Portal
2. Select 'SQL servers'
3. Click on the reported SQL server instance you wanted to modify
4. Navigate to Security -> Networking -> Connectivity
5. Under 'Encryption in transit' section, Set 'Minimum TLS Version' to 'TLS 1.2' or higher.
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-sql-server-list' AND json.rule = ['sqlServer'].['properties.state'] equal ignore case "Ready" and (['sqlServer'].['properties.minimalTlsVersion'] equal ignore case "None" or ['sqlServer'].['properties.minimalTlsVersion'] equals "1.0" or ['sqlServer'].['properties.minimalTlsVersion'] equals "1.1")```
AWS KMS Customer Managed Key (CMK) is disabled
This policy identifies the AWS KMS Customer Managed Key (CMK) that is disabled.

Ensuring that your Amazon Key Management Service (AWS KMS) key is enabled is important because it determines whether the key can be used to perform cryptographic operations.  If an AWS KMS Key is disabled, any operations dependent on that key, such as encryption or decryption of data, will fail. This can lead to application downtime, data access issues, and potential data loss if not addressed promptly.

It is recommended to enable the AWS KMS Customer Managed Key (CMK) if it is used in the application, to restore cryptographic operations and ensure your applications and services can access encrypted data.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To enable the AWS KMS customer managed keys.

1. Sign in to the AWS Management Console and open the AWS Key Management Service (AWS KMS) console at https://console.aws.amazon.com/kms.
2. To change the AWS Region that the reported resource is presented in, use the Region selector in the upper-right corner of the page.
3. In the navigation pane, choose 'Customer-managed keys'.
4. Select the reported CMK and click on the dropdown 'Key Actions'.
5. Choose the 'Enable' option..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-kms-get-key-rotation-status' AND json.rule = keyMetadata.enabled is false```
Edited_pwdzvysgyp_ui_auto_policies_tests_name
kjbqahijfa_ui_auto_policies_tests_descr
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 api.name = 'aws-iam-list-users' AND json.rule = createDate contains 2018```
AWS CloudTrail S3 buckets have not enabled MFA Delete
This policy identifies the S3 buckets which do not have Multi-Factor Authentication enabled for CloudTrails. For encryption of log files, CloudTrail defaults to use of S3 server-side encryption (SSE). We recommend adding an additional layer of security by adding MFA Delete to your S3 bucket. This will help to prevent deletion of CloudTrail logs without your explicit authorization. We also encourage you to use a bucket policy that places restrictions on which of your identity access management (IAM) users are allowed to delete S3 objects.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MFA'].
Mitigation of this issue can be done as follows: Enable MFA Delete on the bucket(s) you have configured to receive CloudTrail log files.
Note: We recommend that you do not configure CloudTrail to write into an S3 bucket that resides in a different AWS account.
Additional information on how to do this can be found here:
 http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html#MultiFactorAuthenticationDelete.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' as X; config from cloud.resource where api.name = 'aws-cloudtrail-describe-trails' as Y; filter '($.Y.s3BucketName==$.X.bucketName) and ($.X.versioningConfiguration.mfaDeleteEnabled does not exist)'; show X;```
Azure Synapse Workspace vulnerability assessment is disabled
This policy identifies Azure Synpase workspace which has Vulnerability Assessment setting disabled. Vulnerability Assessment service scans Synapse workspaces for known security vulnerabilities and highlight deviations from best practices, such as misconfigurations, excessive permissions, and unprotected sensitive data. It is recommended to enable Vulnerability assessment on Synapse workspaces.
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: To configure vulnerability assessment for your existing Azure Synapse workspace, follow below steps:

1. Log in to Azure Portal and Navigate to Azure Synpase Analytics dashboard
2. Select the reported Synapse Workspace
3. Under Security, select Microsoft Defender for Cloud
4. Enable Defender for Cloud to configure vulnerability assessment for the selected Azure Synapse Workspace.
5 To configure vulnerability assessments to automatically run periodic scans, set Periodic recurring scans to On..

Query:
```config from cloud.resource where api.name = 'azure-synapse-workspace' AND json.rule = properties.provisioningState equal ignore case Succeeded as X; config from cloud.resource where api.name = 'azure-synapse-workspace-managed-sql-server-vulnerability-assessments' AND json.rule = properties.recurringScans.isEnabled is false as Y; filter '$.X.name equals $.Y.workspaceName'; show X;```
Azure Data Explorer cluster double encryption is disabled
This policy identifies Azure Data Explorer clusters in which double encryption is disabled. Double encryption adds a second layer of encryption using service-managed keys. It is recommended to enable infrastructure double encryption on Data Explorer clusters so that encryption can be implemented at the layer closest to the storage device or network wires.

For more details: 
https://learn.microsoft.com/en-us/azure/data-explorer/cluster-encryption-double
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: Enabling double encryption is only possible during cluster creation. Once infrastructure encryption is enabled on your cluster, you can't disable it.

To create Azure Data Explorer cluster with double encryption, follow below URL:
https://learn.microsoft.com/en-us/azure/data-explorer/cluster-encryption-double

NOTE: Using Infrastructure double encryption will have performance impact on the Azure Database for PostgreSQL server due to the additional encryption process..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-kusto-clusters' AND json.rule = properties.state equal ignore case Running and properties.enableDoubleEncryption is false```
GCP Cloud Function is granted a basic role
This policy identifies GCP Cloud Functions that are granted a basic role. This includes both Cloud Functions v1 and Cloud Functions v2.

Basic roles are highly permissive roles that existed before the introduction of IAM and grant wide access over project to the grantee. The use of basic roles for granting permissions increases the blast radius and could help to escalate privilege further in case the Cloud Function is compromised.

Following the principle of least privilege, it is recommended to avoid the use of basic roles.
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: It is recommended to follow the principle of least privilege for granting access.

To update privileges granted to a service account, please refer to the steps below: 
1. Log in to the GCP console
2. Navigate to the Cloud Functions
3. Click on the cloud function for which alert is generated
4. Go to 'DETAILS' tab
5. Note the service account mentioned attached to the cloud function
6. Navigate to the IAM & ADMIN
7. Go to IAM tab
8. Go to 'VIEW BY PRINCIPALS' tab
9. Find the previously noted service account and click on 'Edit principal' button (pencil icon)
10. Remove any binding to any basic role (roles/viewer or roles/editor or roles/owner)
11. Click 'SAVE'..

Query:
```config from cloud.resource where api.name = 'gcloud-projects-get-iam-user' AND json.rule = roles[*] contains "roles/viewer" or roles[*] contains "roles/editor" or roles[*] contains "roles/owner" as X; config from cloud.resource where api.name = 'gcloud-cloud-function-v2' as Y; filter '$.Y.serviceConfig.serviceAccountEmail equals $.X.user'; show Y;```
Azure Storage account container storing activity logs is publicly accessible
This policy identifies the Storage account containers containing the activity log export is publicly accessible. Allowing public access to activity log content may aid an adversary in identifying weaknesses in the affected account's use or configuration.
This is applicable to azure cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: 1. Log in to the Azure portal
2. Navigate to 'Storage accounts'
3. Select the reported storage account
4. Under 'Data storage' section, Select 'Containers'
5. Select the container named as 'insight-operational-logs'
6. Click on 'Change access level'
7. Set 'Public access level' to 'Private (no anonymous access)'
8. Click on 'OK'.

Query:
```config from cloud.resource where api.name = 'azure-storage-account-list' AND json.rule= 'publicContainersList[*] contains insights-operational-logs and (totalPublicContainers > 0 and (properties.allowBlobPublicAccess is true or properties.allowBlobPublicAccess does not exist) and properties.publicNetworkAccess equal ignore case Enabled and networkRuleSet.virtualNetworkRules is empty and (properties.privateEndpointConnections is empty or properties.privateEndpointConnections does not exist))' as X; config from cloud.resource where api.name = 'azure-monitor-log-profiles-list' as Y; filter '$.X.id contains $.Y.properties.storageAccountId'; show X;```
AWS RDS database instance encrypted with Customer Managed Key (CMK) is not enabled for regular rotation
This policy identifies Amazon RDS instances that use Customer Managed Keys (CMKs) for encryption but are not enabled with key rotation. Amazon RDS instance encryption key rotation failure can result in prolonged exposure of sensitive data and potential compliance violations. As a security best practice, it is important to periodically rotate these keys. This ensures that if the keys are compromised, the data in the underlying service remains secure with the new keys.
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: The following steps are recommended to enable the automatic rotation of the KMS key used by the RDS instance

1. Log in to the AWS console.
2. In the console, select the specific region from the region drop-down in the top right corner, for which the alert is generated.
4. Navigate to the 'RDS' service.
5. Select the RDS instance reported in the alert, and click on the 'Configuration' tab.
6. Under the 'Storage' section, click on the KMS key link in 'AWS KMS key'.
7. Under the 'Key rotation' tab on the navigated KMS key window, enable the 'Automatically rotate this CMK every year' check box.
8. Click on Save..

Query:
```config from cloud.resource where api.name = 'aws-rds-describe-db-instances' and json.rule = storageEncrypted is true as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' AND json.rule = keyMetadata.keyState equals Enabled and keyMetadata.keyManager equals CUSTOMER and keyMetadata.origin equals AWS_KMS and (rotation_status.keyRotationEnabled is false or rotation_status.keyRotationEnabled equals "null") as Y; filter '($.X.kmsKeyId equals $.Y.key.keyArn)'; show X;```