knarayan/cloud_posture_checks huggingface dataset:
AWS IAM support access policy is not associated to any role
This policy identifies IAM policies with support role access which are not attached to any role for an account. AWS provides a support centre that can be used for incident notification and response, as well as technical support and customer services.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['UNUSED_PRIVILEGES'].
Mitigation of this issue can be done as follows: 1. Log in to AWS console
2.Go to service IAM under Services panel.
3.From left panel click on 'Policies'
4.Search for the existence of a support policy 'AWSSupportAccess'
5.Create a IAM role 
6.Attach 'AWSSupportAccess' managed policy to the created IAM role.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-policy-version' AND json.rule = 'policyName equals AWSSupportAccess and policyArn contains arn:aws:iam::aws:policy/AWSSupportAccess and (isAttached is false or (isAttached is true and entities.policyRoles[*].roleId is empty))'```
GCP SQL server instance database flag user options is set
This policy identifies GCP SQL server instances fo which database flag user options is set. The user options option specifies global defaults for all users. A list of default query processing options is established for the duration of a user's work session. A user can override these defaults by using the SET statement. It is recommended that, user options database flag for SQL Server instance should not be configured.
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 the GCP console
2. Navigate SQL Instances page
3. Click on the reported SQL server instance
4. Click on EDIT
5. If the flag has not been set on the instance, 
Under 'Customize your instance' section, go to 'Flags and parameters', go to the flag 'user options' and click on delete icon
6. Click on SAVE 
7. If 'Changes requires restart' pop-up appears, click on 'SAVE AND RESTART'.

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 SQLSERVER and settings.databaseFlags[*].name contains "user options"'```
Alibaba Cloud RAM policy attached to users
This policy identifies Resource Access Management (RAM) policies that are attached to users. By default, RAM users, groups, and roles have no access to Alibaba Cloud resources. RAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended that RAM policies be applied directly to groups and roles but not users.
This is applicable to alibaba_cloud cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: 1. Log in to Alibaba Cloud Portal
2. Go to Resource Access Management
3. In the left-side navigation pane, click 'Users'
4. Click on the reported RAM user
5. Under the 'Permissions' tab, In 'Individual' sub-tab
6. Click on 'Remove Permission' for user reported,
7. On 'Remove Permission' popup window, Click on 'OK'

If a group with a similar policy already exists, put the user in that group. If such a group does not exist, create a new group with relevant policy and assign the user to the group..

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ram-user' AND json.rule = 'Policies[*] size > 0'```
Azure VPN is not configured with cryptographic algorithm
This policy identifies Azure VPNs which are not configured with cryptographic algorithm. Azure VPN gateways to use a custom IPsec/IKE policy with specific cryptographic algorithms and key strengths, rather than the Azure default policy sets. IPsec and IKE protocol standard supports a wide range of cryptographic algorithms in various combinations. If customers do not request a specific combination of cryptographic algorithms and parameters, Azure VPN gateways use a set of default proposals. Typically due to compliance or security requirements, you can now configure your Azure VPN gateways to use a custom IPsec/IKE policy with specific cryptographic algorithms and key strengths, rather than the Azure default policy sets. It is thus recommended to use custom policy sets and choose strong cryptography.
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: Follow Microsoft Azure documentation and setup your respective VPN connections using strong recommended cryptographic requirements.
FMI: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-compliance-crypto#cryptographic-requirements.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-network-vpn-connection-list' AND json.rule = 'ipsecPolicies is empty and connectionType does not equal ExpressRoute'```
GCP Firewall rule exposes GKE clusters by allowing all traffic on port 10250
This policy identifies GCP Firewall rule allowing all traffic on port 10250 which allows GKE full node access. The port 10250 on the kubelet is used by the kube-apiserver (running on hosts labelled as Orchestration Plane) for exec and logs. As per security best practice, port 10250 should not be exposed to the public.
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: As port 10250 exposes sensitive information of GKE pod configuration it is recommended to disable this firewall rule. 
Otherwise, remove the overly permissive source IPs following the below steps,

1. Login to GCP Console
2. Navigate to 'VPC Network'(Left Panel)
3. Go to the 'Firewall' section (Left Panel)
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(10250,10250) or (ports does not exist and (IPProtocol contains tcp or IPProtocol contains udp or IPProtocol contains "all")))] exists as X; config from cloud.resource where api.name = 'gcloud-container-describe-clusters' AND json.rule = status equals RUNNING as Y; filter '$.X.network contains $.Y.networkConfig.network' ; show X;```
PCSUP-16458-CLI-Test

This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 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 'Function URL'
8. Click on 'Edit'
9. Set 'Auth type' to 'AWS_IAM'
10. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name= 'aws-lambda-list-functions' AND json.rule = authType equal ignore case NONE```
Azure Spring Cloud service is not configured with virtual network
This policy identifies Azure Spring Cloud services that are not configured with a virtual network. Spring Cloud configured with a virtual network isolates apps and service runtime from the internet on your corporate network and provides control over inbound and outbound network communications for Azure Spring Cloud. As best security practice, It is recommended to deploy Spring Cloud service in a virtual network.
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: You can select your Azure virtual network only when you create a new Azure Spring Cloud service instance. You cannot change to use another virtual network after Azure Spring Cloud has been created. 
To resolve this alert create a new Spring Cloud service configuring virtual network, migrate all data to newly created Spring Cloud service and then delete the reported Spring Cloud service.

To create a new Spring Cloud service with virtual network, follow the below URL:
https://docs.microsoft.com/en-us/azure/spring-cloud/how-to-deploy-in-azure-virtual-network?tabs=azure-portal 

NOTE: Azure Virtual network feature is not available to Basic tier Spring Cloud services..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-spring-cloud-service' AND json.rule = properties.powerState equals Running and sku.tier does not equal Basic and properties.networkProfile.serviceRuntimeSubnetId does not exist```
Alibaba Cloud ECS instance is not using VPC network
This policy identifies ECS instances which are still using the ECS classic network instead of the VPC network that enables you to leverage enhanced infrastructure security controls.
Note: If you purchased an ECS instance after 17:00 (UTC+8) on June 14, 2017, you cannot choose the classic network type.
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: You can select the VPC network only when you create a new ECS instance. So to fix this alert, create a new ECS instance with VPC network and then migrate all required ECS instance data from the reported ECS instance to this newly created ECS instance.

To set up the new ECS instance with VPC network, perform the following:
1. Log in to Alibaba Cloud Portal
2. Go to Elastic Compute Service
3. In the left-side navigation pane, click 'Instances'
4. On the Instances list page, click Create Instance.
5. Complete the Basic Configurations
6. Click 'Next: Networking', Select a 'Network Type' as 'VPC'. Select the desired VPC and a VSwitch.
7. Complete the System Configurations, Grouping and Preview the configurations.
8. Click on 'Create Order'

To delete reported ECS instance, perform the following:
1. Log in to Alibaba Cloud Portal
2. Go to Elastic Compute Service
3. In the left-side navigation pane, click 'Instances'
4. Click on the reported ECS instance
5. Click on 'Stop', It will be auto-released..

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ecs-instance' AND json.rule = 'instanceNetworkType does not equal vpc or vpcAttributes is empty'```
API automation policy lgwpn

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 VM instance OS login overrides Project metadata OS login configuration
This policy identifies GCP VM instances where OS login configuration is disabled and overriding enabled Project OS login configuration. Enabling OS Login ensures that SSH keys used to connect to instances are mapped with IAM users. Revoking access to IAM user will revoke all the SSH keys associated with that particular user. It facilitates centralized and automated SSH key pair management which is useful in handling cases like a response to compromised SSH key pairs. 

Note: Enabling OS Login on instances disables metadata-based SSH key configurations on those instances. Disabling OS Login restores SSH keys that you have configured in a project or instance metadata.

Reference: https://cloud.google.com/compute/docs/instances/managing-instance-access
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 GCP Portal
2. Go to Computer Engine (Left Panel)
3. Go to the VM instances
4. Select the alerted VM instance
5. Click on the 'EDIT' button
6. Go to 'Custom metadata'
7. Remove the metadata entry where the key is 'enable-oslogin' and the value is 'FALSE' or 'false' or 0.(For more information on adding boolean values, refer: https://cloud.google.com/compute/docs/metadata/setting-custom-metadata#boolean)
8. Click on 'Save' to apply the changes.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-project-info' AND json.rule = commonInstanceMetadata.items[?any(key contains "enable-oslogin" and (value contains "Yes" or value contains "Y" or value contains "True" or value contains "true" or value contains "TRUE" or value contains "1"))] exists as X; config from cloud.resource where api.name = 'gcloud-compute-instances-list' AND json.rule = (metadata.items[?any(key exists and key contains "enable-oslogin" and (value contains "False" or value contains "N" or value contains "No" or value contains "false" or value contains "FALSE" or value contains "0"))] exists and name does not start with "gke-" and status equals RUNNING) as Y;filter'$.Y.zone contains $.X.name';show Y;```
AWS EMR Studio using the shadow resource bucket for workspace storage
This policy identifies that the AWS EMR Studio using the bucket for workspace storage is not managed from the current account. This could potentially be using the shadow resource bucket for workspace storage.

AWS EMR enables data processing and analysis using big data frameworks like Hadoop, Spark, and Hive. To create an EMR Studio, the EMR service automatically generates an S3 bucket. This S3 bucket follows the naming pattern 'aws-emr-studio-{Account-ID}-{Region}'. An attacker can create an unclaimed bucket with this predictable name and wait for the victim to deploy a new EMR Studio in a new region. This can result in multiple attacks, including cross-site scripting (XSS) when the user opens the compromised notebook in EMR Studio.

It is recommended to verify the expected bucket owner and update the AWS EMR storage location and enforce the aws: ResourceAccount condition in the policy of the service role used by the AWS EMR to check that the AWS account ID of the S3 bucket used by AWS EMR Studio according to your business requirements.
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 update an EMR Studio with the new workspace storage, Follow the below actions:

1. Sign in to the AWS Management Console
2. Move the required script to a new S3 bucket as per your requirements.
3. Open the Amazon EMR console at https://console.aws.amazon.com/emr.
4. Under EMR Studio on the left navigation, choose Studios.
5. Select the reported studio from the Studios list and Click the 'Edit' button on the right corner to edit the Studio details.
6. Verify that the 'Workspace storage' is authorized and managed according to your business requirements. 
7. On the Edit studio page, Update 'Workspace storage' by selecting 'Browse S3', and select the 'Encrypt Workspace files with your own AWS KMS key' as per your organisation's requirements.
8. Click 'Save Changes'..

Query:
```config from cloud.resource where api.name = 'aws-emr-studio' AND json.rule = DefaultS3Location exists and DefaultS3Location contains "aws-emr-studio-" as X; config from cloud.resource where api.name = 'aws-s3api-get-bucket-acl' AND json.rule = bucketName contains "aws-emr-studio-" as Y; filter 'not ($.X.BucketName equals $.Y.bucketName)' ; show X;```
GCP VM instance used by Vertex AI Workbench Instance
This policy identifies GCP VM instances used by Vertex AI Workbench.

Vertex AI Workbench relies on GCP Compute Engine VM instances for backend processing. The selection of the appropriate VM instance type, size, and configuration directly impacts the performance and security of the Workbench. Proper configuration of these VM instances is critical to ensuring the security of the associated Vertex AI environment.

It is recommended to regularly identify and assess the VM instances supporting Vertex AI Workbench to maintain a strong security posture and ensure compliance with best practices.
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: Review and validate the GCP VM instances used by Vertex AI Workbench Instances. Verify the VM instance is configured as per organizational needs..

Query:
```config from cloud.resource where api.name = 'gcloud-compute-instances-list' AND json.rule = status equals "RUNNING" as X; config from cloud.resource where api.name = 'gcloud-vertex-ai-workbench-instance' as Y; filter ' $.Y.labels.resource-name equals $.X.labels.resource-name '; show X;```
dnd_test_validate_compliance_hyperion_policy_ss_finding_1
Description-d84c12b2-384e-429e-967a-2e9ea515846d
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['SSH_BRUTE_FORCE'].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = defaultRootObject is empty```
Azure user not restricted to create Microsoft Entra Security Group
This policy identifies instances in the Microsoft Entra ID configuration where security group creation is not restricted to administrators only.

When the ability to create security groups is enabled, all users in the directory can create new groups and add members to them. Unless there is a specific business need for this broad access, it is best to limit the creation of security groups to administrators only.

As a best practice, it is recommended to restrict the ability to create Microsoft Entra Security Groups to administrators 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: 1. Log in to Azure Portal and search for 'Microsoft Entra ID'
2. Select 'Microsoft Entra ID'
3. Under 'Manage' select 'Groups'
4. Under 'Settings' select 'General'
5. Under 'Security Groups' section, set 'Users can create security groups in Azure portals, API or PowerShell' to No
6. Select 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-active-directory-authorization-policy' AND json.rule = defaultUserRolePermissions.allowedToCreateSecurityGroups is true ```
AWS route table with VPC peering overly permissive to all traffic
This policy identifies VPC route tables with VPC peering connection  which are overly permissive to all traffic. Being highly selective in peering routing tables is a very effective way of minimizing the impact of breach as resources outside of these routes are inaccessible to the peered VPC.
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. Log in to 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 'VPC' dashboard from 'Services' dropdown
4. From left menu, select 'Route Tables'
5. Click on the alerted route table
6. From top click on 'Action' button
7. From the Action menu dropdown, select 'Edit routes'
8. From the list of destination remove the extra permissive destination by clicking the cross symbol available for that destination
9. Add a destination with 'least access'
10. Click on 'Save Routes'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-route-tables' AND json.rule = "routes[*].vpcPeeringConnectionId exists and routes[?(@.destinationCidrBlock=='0.0.0.0/0' || @.destinationIpv6CidrBlock == '::/0')].vpcPeeringConnectionId starts with pcx"```
GCP PostgreSQL instance database flag log_error_verbosity is not set to default or stricter
This policy identifies PostgreSQL database instances in which database flag log_error_verbosity is not set to default. The flag log_error_verbosity controls the amount of detail written in the server log for each message that is logged. Valid values are TERSE, DEFAULT, and VERBOSE. It is recommended to set log_error_verbosity to default or terse.
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_error_verbosity' from the drop-down menu and set the value as 'default' or 'terse'
OR
If the flag has been set to other than default or terse, Under 'Customize your instance', In 'Flags' section choose the flag 'log_error_verbosity' and set the value as 'default' or 'terse'
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[*].name does not contain log_error_verbosity or settings.databaseFlags[?any(name contains log_error_verbosity and value contains verbose)] exists)"```
Azure Storage account diagnostic setting for table is disabled
This policy identifies Azure Storage account tables that have diagnostic logging disabled.

By enabling diagnostic settings, you can capture various types of activities and events occurring within these storage account tables. These logs provide valuable insights into the operations, performance, and security of the storage account tables.

As a best practice, it is recommended to enable diagnostic logs on all storage account tables.
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: 1. Log in to Azure Portal
2. Navigate to the Storage Accounts dashboard
3. Click on the reported Storage account
4. Under the 'Monitoring' menu, click on 'Diagnostic settings'
5. Select the table resource
6. Under 'Diagnostic settings', click on 'Add diagnostic setting'
7. At the top, enter the 'Diagnostic setting name'
8. Under 'Logs', select all the checkboxes under 'Categories'
9. Under 'Destination details', select the destination for logging
10. Click on 'Save'.

Query:
```config from cloud.resource where api.name = 'azure-storage-account-list' AND json.rule = properties.provisioningState equal ignore case Succeeded as X; config from cloud.resource where api.name = 'azure-storage-account-table-diagnostic-settings' AND json.rule = properties.logs[*].enabled all true as Y; filter 'not($.X.name equal ignore case $.Y.StorageAccountName)'; show X;```
Check BC

This is applicable to gcp 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 api.name = 'gcloud-compute-ssl-policies' AND json.rule = (profile equals MODERN or profile equals CUSTOM) and minTlsVersion does not equal "TLS_1_2" as X; config from cloud.resource where api.name = 'gcloud-compute-target-https-proxies' AND json.rule = sslPolicy exists as Y; filter "$.X.selfLink contains $.Y.sslPolicy"; show Y;```