knarayan/cloud_posture_checks huggingface dataset:
cloned copy - RLP-93423 - 2
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 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 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;```
GCP Kubernetes Engine cluster workload identity is disabled
This policy identifies GCP Kubernetes Engine clusters for which workload identity is disabled. Manual approaches for authenticating Kubernetes workloads violates the principle of least privilege on a multi-tenanted node when one pod needs to have access to a service, but every other pod on the node that uses the service account does not. Enabling Workload Identity manages the distribution and rotation of Service account keys for the workloads to use.
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 to service 'Kubernetes Engine'(Left Panel)
3. Select the reported cluster from the available list
4. Under section 'Security', click on edit icon for 'Workload Identity'
5. Click on the checkbox 'Enable Workload Identity'
6. Ensure that the Workload Identity Namespace is set to the namespace of the GCP
project containing the cluster, e.g: $PROJECT_ID.svc.id.goog
7. Click on 'SAVE CHANGES'
8. After enabling, go to tab 'NODES'
9. To investigate each node pool, Click on 'Edit', In section 'Security', select the 'Enable GKE Metadata Server' checkbox
10. Click on 'SAVE'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule =status equals "RUNNING" and resourceLabels.goog-composer-version does not start with "composer-1" and ((workloadIdentityConfig[*] does not exist) or (workloadIdentityConfig[*] exists and (nodePools[?any(config.workloadMetadataConfig does not contain GKE_METADATA)] exists)))```
Azure Blob Storage utilized for Azure Machine Learning training job data
This policy identifies Azure Blob Storage accounts used for storing data utilized in Azure Machine Learning training jobs. This policy provides visibility into storage utilization for Machine Learning workloads but does not indicate a security or compliance risk.

Azure Blob Storage serves as a robust storage solution for large-scale Machine Learning training data. This policy emphasizes the importance of securing stored data by employing encryption and additional security parameters like firewalls, private endpoints, and access policies to safeguard sensitive information.

As a security best practice, it is recommended to properly configure Azure Blob Storage utilized in Azure Machine Learning training jobs.
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: For configuring Azure Blob Storage used in Azure Machine Learning training jobs, refer to the following link for Blob storage security recommendations:
https://learn.microsoft.com/en-us/azure/storage/blobs/security-recommendations.

Query:
```config from cloud.resource where api.name = 'azure-machine-learning-datastores' AND json.rule = properties.datastoreType equal ignore case AzureBlob as X; config from cloud.resource where api.name = 'azure-storage-account-list' as Y; filter ' $.X.properties.accountName equal ignore case $.Y.name ' ; show Y;```
AWS Redshift does not have require_ssl configured
This policy identifies Redshift databases in which data connection to and from is occurring on an insecure channel. SSL connections ensures the security of the data in transit.
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 the AWS and navigate to the 'Amazon Redshift' service.
2. Expand the identified 'Redshift' cluster and make a note of the 'Cluster Parameter Group'
3. In the navigation panel, click on the 'Parameter group'.
4. Select the identified 'Parameter Group' and click on 'Edit Parameters'.
5. Review the require_ssl flag. Update the parameter 'require_ssl' to true and save it.
Note: If the current parameter group is a Default parameter group, it cannot be edited. You will need to create a new parameter group and point it to an affected cluster..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-redshift-describe-clusters' AND json.rule = "clusterGroupsDetails[*].parameters[?(@.parameterName=='require_ssl')].parameterValue is false"```
Alibaba Cloud VPC flow log not enabled
This policy identifies Virtual Private Clouds (VPCs) where flow logs are not enabled.

VPC flow logs capture information about the traffic entering and exiting network interfaces in the VPC. Without VPC flow logs, there’s limited visibility into network traffic, making it challenging to detect and investigate suspicious activities, potential data breaches, or security policy violations. Enabling VPC flow logs enhances network monitoring, improves threat detection, and supports compliance requirements.

As a security best practice, it is recommended to enable VPC flow logs.
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. Navigate to VPC console
3. Under 'O&M and Monitoring', click on 'Flow Log'
4. Create and configure a new flow log for the reported VPC, specifying the required traffic filters and log storage destination
5. Enable and save the configuration.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' and api.name = 'alibaba-cloud-vpc' AND json.rule = vpcFlowLogs[*].flowLogId does not exist and status equal ignore case Available```
GCP Vertex AI Workbench Instance auto-upgrade is disabled
This policy identifies GCP Vertex AI Workbench Instances that have auto-upgrade disabled.

Auto-upgrading Google Cloud Vertex environments ensures timely security updates, bug fixes, and compatibility with APIs and libraries. It reduces security risks associated with outdated software, enhances stability, and enables access to new features and optimizations.

It is recommended to enable auto-upgrade to minimize maintenance overhead and mitigate security risks.
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. Select 'INSTANCES' tab
5. Click on the reported notebook
6. Go to 'SYSTEM' tab
7. Enable 'Environment auto-upgrade'
8. Configure upgrade schedule as required
9. Click 'SUBMIT'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-vertex-ai-workbench-instance' AND json.rule = gceSetup.metadata.notebook-upgrade-schedule does not exist```
Azure ACR HTTPS not enabled for webhook
Ensure you send container registry webhooks only to a HTTPS endpoint. This policy checks your container registry webhooks and alerts if it finds a URI with HTTP.
This is applicable to azure 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: Update your container registry webhook URI to use HTTPS.

1. Sign in to the Azure portal.
2. Navigate to the container registry in which you want to modify the webhook.
3. Under Services, select Webhooks.
4. Select your existing webhook.
5. Near the top of the next window pane, select Configure.
6. Under Service URI in the next window, modify your URI to use https:// and click Save..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-container-registry' AND json.rule = 'webhooks[*] contains config and webhooks[*].config.serviceUri starts with http://'```
Detect Unrestricted Access to EC2 Client VPN Endpoints
This policy helps you identify AWS EC2 Client VPN endpoints that have been configured to allow access for all clients, which could potentially expose your VPN to unauthorized users. By detecting such configurations, the policy enables you to take necessary actions to secure your VPN endpoints, ensuring that only authorized clients can access your cloud resources and maintain a strong security posture in your public cloud environment.
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-ec2-client-vpn-endpoint' and json.rule = authorizationRules[*].accessAll exists and authorizationRules[*].accessAll equals "True" ```
API automation policy sizbn

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

Query:
```config from cloud.resource where api.name = "aws-ec2-describe-instances" AND json.rule = architecture contains "foo"```
AWS Amazon Machine Image (AMI) infected with mining malware
This policy identifies Amazon Machine Images (AMIs) that are infected with mining malware. As per research, AWS Community AMI Windows 2008 hosted by an unverified vendor containing malicious code running an unidentified crypto (Monero) miner. It is recommended to delete such AMIs to protect from malicious activity and attack blast.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['MALWARE'].
Mitigation of this issue can be done as follows: To delete reported AMI follow below mentioned URL:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/deregister-ami.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name='aws-ec2-describe-images' AND json.rule = image.platform contains windows and image.imageId contains ami-1e542176```
pcsup-13966-policy

This is applicable to gcp cloud and is considered a high 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-organization-asset-group-member' as X; config from cloud.resource where api.name = 'gcloud-projects-get-iam-user' AND json.rule = '(roles[*] contains roles/editor or roles[*] contains roles/owner or roles[*] contains roles/appengine.* or roles[*] contains roles/browser or roles[*] contains roles/compute.networkAdmin or roles[*] contains roles/cloudtpu.serviceAgent or roles[*] contains roles/composer.serviceAgent or roles[*] contains roles/composer.ServiceAgentV2Ext or roles[*] contains roles/container.serviceAgent or roles[*] contains roles/dataflow.serviceAgent)' as Y; filter '($.X.groupKey.id contains $.Y.user)'; show Y;```
GCP Firewall rule allows all traffic on SSH port (22)
This policy identifies GCP Firewall rules which allow all inbound traffic on SSH port (22). Allowing access from arbitrary IP addresses to this port increases the attack surface of your network. It is recommended that the SSH port (22) should be allowed to specific IP addresses.
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: If the Firewall rule reported indeed needs to restrict all traffic, follow the instructions below:
1. Login to GCP Console
2. Go to 'VPC Network'
3. Go to the 'Firewall'
4. Click on the reported Firewall rule
5. Click on 'EDIT'
6. Modify Source IP ranges to specific IP
7. Click on 'SAVE'..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-firewall-rules-list' AND json.rule = disabled is false and direction equals INGRESS and (sourceRanges[*] equals ::0 or sourceRanges[*] equals 0.0.0.0 or sourceRanges[*] equals 0.0.0.0/0 or sourceRanges[*] equals ::/0 or sourceRanges[*] equals ::) and allowed[?any(ports contains _Port.inRange(22,22) or (ports does not exist and (IPProtocol contains tcp or IPProtocol contains udp)))] exists```
Azure storage account has a blob container with public access
This policy identifies blob containers within an Azure storage account that allow anonymous/public access ('CONTAINER' or 'BLOB'). As a best practice, do not allow anonymous/public access to blob containers unless you have a very good reason. Instead, you should consider using a shared access signature token for providing controlled and time-limited access to blob containers.

'Public access level' allows you to grant anonymous/public read access to a container and the blobs within Azure blob storage. By doing so, you can grant read-only access to these resources without sharing your account key, and without requiring a shared access signature.
This is applicable to azure 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 the Azure portal
2. Navigate to 'Storage Accounts' dashboard
3. Select the reported storage account
4. Under 'Data storage' section, Select 'Containers'
5. Select the blob container you need to modify
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 cloud.type = 'azure' AND api.name = 'azure-storage-account-list' AND json.rule = 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)```
API automation policy sklde

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

Query:
```config from cloud.resource where api.name = "aws-ec2-describe-instances" AND json.rule = architecture contains "foo"```
AWS Lambda Function resource-based policy is overly permissive
This policy identifies Lambda Functions that have overly permissive resource-based policy. Lambda functions having overly permissive policy could lead to lateral movement in account or privilege being escalated when compromised. It is highly recommended to have the least privileged access policy to protect the Lambda Functions from unauthorized access.

For more details:
https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html
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 modify permission from AWS Lambda Function resource-based policy
1. Sign in to the AWS console
2. Select the region, from the region drop-down, for which the alert is generated
3. Navigate to AWS Lambda Dashboard
4. Click on the 'Functions' (Left panel)
5. Select the lambda function on which the alert is generated
6. Go to Configuration tab
7. Select Permissions
8. Scroll to the \"Resource-based policy\" area
9. For each policy statement, use fine-grained and restrictive permissions instead of using wildcards (Lambda:* and Resource:*) OR add in appropriate conditions with least privilege access.
10. Click on \"Edit\" button to modify the statement
11. When you finish configuring the statement, choose 'Save'.

To remove permission from AWS Lambda Function resource-based policy
1. Sign in to the AWS console
2. Select the region, from the region drop-down, for which the alert is generated
3. Navigate to AWS Lambda Dashboard
4. Click on the 'Functions' (Left panel)
5. Select the lambda function on which the alert is generated
6. Go to Configuration tab
7. Select Permissions
8. Scroll to the \"Resource-based policy\" area
9. For each policy statement, use fine-grained and restrictive permissions instead of using wildcards (Lambda:* and Resource:*) OR add in appropriate conditions with least privilege access.
10. Click on \"Delete\" button to modify the statement
11. In Delete statement dialog box, click on \"Delete\" button..

Query:
```config from cloud.resource where api.name = 'aws-lambda-list-functions' AND json.rule = policy.Statement[?any(Effect equals Allow and Principal equals "*" and Condition does not exist and (Action equals "*" or Action equals lambda:*))] exists```
AWS RDS Event subscription All event categories and All instances disabled for DB instance
This policy identifies AWS RDS event subscriptions for DB instance which has 'All event categories' and 'All instances' is disabled. As a best practice enabling 'All event categories' for 'All instances' helps to get notified when an event occurs for a DB instance.
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. 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 Amazon RDS Dashboard
4. Click on 'Event subscriptions' (Left Panel)
5. Choose the reported Event subscription
6. Click on 'Edit'
7. On 'Edit event subscription' page, Under 'Details' section; Select 'Yes' for 'Enabled' and Make sure you have subscribed your DB to 'All instances' and 'All event categories'
8. Click on 'Edit'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-rds-describe-event-subscriptions' AND json.rule = 'sourceType equals db-instance and ((status does not equal active or enabled is false) or (status equals active and enabled is true and (sourceIdsList is not empty or eventCategoriesList is not empty)))'```
asasas23

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: N/A.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = binaryAuthorization.evaluationMode does not exist or binaryAuthorization.evaluationMode equal ignore case EVALUATION_MODE_UNSPECIFIED or binaryAuthorization.evaluationMode equal ignore case DISABLED```
GuardDuty IAM Impact: AnomalousBehavior

This is applicable to aws cloud and is considered a high 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 = 'AWS' AND finding.type = 'AWS GuardDuty IAM' AND finding.name = 'Impact:IAMUser/AnomalousBehavior'```
API automation policy nrnqu

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

Query:
```config from cloud.resource where api.name = "aws-ec2-describe-instances" AND json.rule = architecture contains "foo"```
GCP KMS Symmetric key not rotating in every 90 days
This policy identifies GCP KMS Symmetric keys that are not rotating every 90 days. A key is used to protect some corpus of data. A collection of files could be encrypted with the same key and people with decrypt permissions on that key would be able to decrypt those files. It's recommended to make sure the 'rotation period' is set to a specific time to ensure data cannot be accessed through the old key.
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 configure automatic rotation for GCP KMS Symmetric keys, please refer to the URL given below and configure "Rotation period" to less than or equal to 90 days:
https://cloud.google.com/kms/docs/rotating-keys#automatic.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-kms-crypto-keys-list' AND json.rule = purpose equal ignore case "ENCRYPT_DECRYPT" and primary.state equals "ENABLED" and (rotationPeriod does not exist or rotationPeriod greater than 7776000)```
OCI Data Catalog configured with overly permissive network access
This policy identifies Data Catalogs configured with overly permissive network access.

The OCI Data Catalog service provides a centralized repository to manage and govern data assets, including their metadata. When network access settings are too permissive, it can expose sensitive metadata to unauthorized users or malicious actors, potentially leading to data breaches and compliance issues.

As a best practice, it is recommended to configure the Data catalog with private endpoints; so that the Data catalog is accessible only to restricted entities.
This is applicable to oci 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: To configure private endpoint to your Data catalog, follow the below URL:
https://docs.oracle.com/en-us/iaas/data-catalog/using/private-network.htm.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-datacatalog-catalogs' AND json.rule = lifecycleState equal ignore case ACTIVE and (attachedCatalogPrivateEndpoints is empty or attachedCatalogPrivateEndpoints does not exist)```