knarayan/cloud_posture_checks huggingface dataset:
GCP BigQuery Dataset not configured with default CMEK
This policy identifies BigQuery Datasets that are not configured with default CMEK. Setting a Default Customer-managed encryption key (CMEK) for a data set ensures any tables created in the future will use the specified CMEK if none other is provided. It is recommended to configure all BigQuery Datasets with default CMEK.
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: To configure default Customer-managed encryption key (CMEK), use following command for "bq" utility
bq update --default_kms_key=<CMEK> <DATASET_ID>

Please refer to URL mentioned below for more details on the bq update command:
https://cloud.google.com/bigquery/docs/reference/bq-cli-reference#bq_update.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-bigquery-dataset-list' AND json.rule = defaultEncryptionConfiguration.kmsKeyName does not exist```
Azure Network Security Group allows all traffic on Windows SMB (TCP Port 445)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on Windows SMB TCP port 445. Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict DNS solely to known static IP addresses. Limit the access list to include known hosts, services, or specific employees only.
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: Before making any changes, please check the impact to your applications/services. Evaluate whether you want to edit the rule and limit access to specific users, hosts, and services only, deny access, or delete the rule completely.

1. Log in to the Azure Portal.
2. Select 'All services'.
3. Select 'Network security groups', under NETWORKING.
4. Select the Network security group you need to modify.
5. Select 'Inbound security rules' under Settings.
6. Select the rule you need to modify, and edit it to allow specific IP addresses OR set the 'Action' to 'Deny' OR 'Delete' the rule based on your requirement.
7. 'Save' your changes..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name= 'azure-network-nsg-list' AND json.rule = securityRules[?any(access equals Allow and direction equals Inbound and (sourceAddressPrefix equals Internet or sourceAddressPrefix equals * or sourceAddressPrefix equals 0.0.0.0/0 or sourceAddressPrefix equals ::/0) and (protocol equals Tcp or protocol equals *) and (destinationPortRange contains _Port.inRange(445,445) or destinationPortRanges[*] contains _Port.inRange(445,445) ))] exists```
AWS S3 bucket having policy overly permissive to VPC endpoints
This policy identifies S3 buckets that have the bucket policy overly permissive to VPC endpoints. It is recommended to follow the principle of least privileges ensuring that the VPC endpoints have only necessary permissions instead of full permission on S3 operations.

NOTE: When applying the Amazon S3 bucket policies for VPC endpoints described in this section, you might block your access to the bucket without intending to do so. Bucket permissions that are intended to specifically limit bucket access to connections originating from your VPC endpoint can block all connections to the bucket. The policy might disable console access to the specified bucket because console requests don't originate from the specified VPC endpoint. So remediation should be done very carefully.

For details refer https://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies-vpc-endpoint.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: 1. Log in to the AWS console
2. Navigate to the S3 dashboard
3. Choose the reported S3 bucket
4. In the 'Permissions' tab, click on the 'Bucket Policy'
5. Update the S3 bucket policy for the VPC endpoint so that it has only required permissions instead of full S3 permission.
Refer for example: https://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies-vpc-endpoint.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name='aws-s3api-get-bucket-acl' AND json.rule = 'policy.Statement[?any((Condition.StringNotEquals contains aws:SourceVpce and Effect equals Deny and (Action contains s3:* or Action[*] contains s3:*)) or (Condition.StringEquals contains aws:SourceVpce and Effect equals Allow and (Action contains s3:* or Action[*] contains s3:*)))] exists'```
AWS KMS Key policy overly permissive
This policy identifies KMS Keys that have a key policy overly permissive. Key policies are the primary way to control access to customer master keys (CMKs) in AWS KMS. It is recommended to follow the principle of least privilege ensuring that KMS key policy does not have all the permissions to be able to complete a malicious action.

For more details:
https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html#overview-policy-elements
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. 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 Key Management Service (KMS)
4. Click on 'Customer managed keys' (Left Panel)
5. Select reported KMS Customer managed key
6. Click on the 'Key policy' tab
7. Click on 'Edit',
Replace the 'Everyone' grantee (i.e. '*') from the Principal element value with an AWS account ID or an AWS account ARN.
OR
Add a Condition clause to the existing policy statement so that the KMS key is restricted.
8. Click on 'Save Changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-kms-get-key-rotation-status' AND json.rule = keyMetadata.keyState equals Enabled and policies.default.Statement[?any(Principal.AWS contains * and Effect equal ignore case allow and Condition does not exist)] exists```
Azure App Service Web app doesn't use latest .Net Core version
This policy identifies App Service Web apps that are not configured with latest .Net Core version. Periodically, newer versions are released for .Net Core software either due to security flaws or to include additional functionality. It is recommended to use the latest .Net version for web apps in order to take advantage of security fixes, if any.
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. Navigate to 'App Services' dashboard
3. Select the reported web app service
4. Under 'Settings' section, Click on 'Configuration'
5. Click on 'General settings' tab, Ensure that Stack is set to .NET and Minor version is set to latest version.
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = 'config.isDotnetcoreVersionLatest exists and config.isDotnetcoreVersionLatest equals false'```
AWS Customer Master Key (CMK) rotation is not enabled
This policy identifies Customer Master Keys (CMKs) that are not enabled with key rotation. AWS KMS (Key Management Service) allows customers to create master keys to encrypt sensitive data in different services. As a security best practice, it is important to rotate the keys periodically so that if the keys are compromised, the data in the underlying service is still 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: 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 Key Management Service (KMS)
4. Click on 'Customer managed keys' (Left Panel)
5. Select reported KMS Customer managed key
6. Under the 'Key Rotation' tab, Enable 'Automatically rotate this CMK every year'
7. Click on Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND 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") and keyMetadata.customerMasterKeySpec equals SYMMETRIC_DEFAULT```
Azure Database for MariaDB not configured with private endpoint
This policy identifies Azure MariaDB database servers that are not configured with private endpoint. Private endpoint connections enforce secure communication by enabling private connectivity to Azure Database for MariaDB. Configuring a private endpoint enables access to traffic coming from only known networks and prevents access from malicious or unknown IP addresses which includes IP addresses within Azure. It is recommended to create private endpoint for secure communication for your Azure MariaDB database.
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 private endpoint for MariaDB, follow below URL:
https://learn.microsoft.com/en-us/azure/mariadb/howto-configure-privatelink-portal.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-database-maria-db-server' AND json.rule = properties.userVisibleState equal ignore case Ready and properties.privateEndpointConnections[*] is empty```
Azure SQL server public network access setting is enabled
This policy identifies Azure SQL servers which have public network access setting enabled.

Publicly accessible SQL servers are vulnerable to external threats with risk of unauthorized access or may remotely exploit any vulnerabilities.

It is recommended to configure the SQL servers with IP-based strict server-level firewall rules or virtual-network rules or private endpoints so that servers are accessible only to restricted entities.
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 IP-based strict server-level firewall rules on your SQL server, follow below URL:
https://learn.microsoft.com/en-gb/azure/azure-sql/database/firewall-create-server-level-portal-quickstart

To configure virtual-network rules on your SQL server, follow below URL:
https://learn.microsoft.com/en-gb/azure/azure-sql/database/vnet-service-endpoint-rule-overview

To configure private endpoints on your SQL server, follow below URL:
https://learn.microsoft.com/en-gb/azure/azure-sql/database/private-endpoint-overview

NOTE: These settings take effect immediately after they're applied. You might experience connection loss if you don't meet the requirements for each setting..

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.publicNetworkAccess'] equal ignore case Enabled and ['sqlServer'].['properties.privateEndpointConnections'] is empty and firewallRules[*] is empty```
OCI Load Balancer not configured with backend set
This policy identifies OCI Load Balancers that have no backend set configured. 

A backend set is a crucial component of a Load Balancer, comprising a load balancing policy, a health check policy, and a list of backend servers. Without a backend set, the Load Balancer lacks the necessary configuration to distribute incoming traffic and monitor the health of backend servers. 

As best practice, it is recommended to properly configure the backend set for the Load Balancer to function effectively, distribute incoming data, and maintain the reliability of backend services.
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: To configure the OCI Load Balancers with backend sets, refer to the following documentation:
https://docs.oracle.com/en-us/iaas/Content/Balance/Tasks/managingbackendsets_topic-Creating_Backend_Sets.htm#top.

Query:
```config from cloud.resource where api.name = 'oci-networking-loadbalancer' AND json.rule = lifecycleState equal ignore case "ACTIVE" and backendSets.*.backends is empty OR backendSets.*.backends equals "[]"```
Azure overly permissive HTTP(S) access

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-network-nsg-list' AND json.rule = securityRules[?any((sourceAddressPrefix equals Internet or sourceAddressPrefix equals * or sourceAddressPrefix equals 0.0.0.0/0 or sourceAddressPrefix equals ::/0) and protocol equals Tcp and access equals Allow and direction equals Inbound and destinationPortRange contains *)] exists```
Azure SQL Server ADS Vulnerability Assessment is disabled
This policy identifies Azure SQL Server which has ADS Vulnerability Assessment setting disabled. Advanced Data Security - Vulnerability Assessment service scans SQL databases for known security vulnerabilities and highlight deviations from best practices, such as misconfigurations, excessive permissions, and unprotected sensitive data. It is recommended to enable ADS - VA service.
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. Select 'SQL servers', and select the SQL server you need to modify
3. Click on 'Microsoft Defender for Cloud' under 'Security'
4. Click on 'Enable Microsoft Defender for SQL' if Azure Defender is not enabled for SQL already
5. Click on '(Configure)' next to 'Microsoft Defender for SQL: Enabled at the server-level'
6. Ensure that 'MICROSOFT DEFENDER FOR SQL' status is 'ON'
7. 'Save' your changes.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-sql-server-list' AND json.rule = (serverSecurityAlertPolicy.properties.state equal ignore case Disabled) or (serverSecurityAlertPolicy.properties.state equal ignore case Enabled and vulnerabilityAssessments[*].type does not exist)```
AWS S3 bucket with cross-account access
This policy identifies the AWS S3 bucket policy allows one or more of the actions (s3:DeleteBucketPolicy, s3:PutBucketAcl, s3:PutBucketPolicy, s3:PutEncryptionConfiguration, s3:PutObjectAcl) for a principal in another AWS account.

An S3 bucket policy that defines permissions and conditions for accessing an Amazon S3 bucket and its objects. Granting permissions like s3:DeleteBucketPolicy, s3:PutBucketAcl, s3:PutBucketPolicy, s3:PutEncryptionConfiguration, and s3:PutObjectAcl to other AWS accounts can lead to unauthorized access and potential data breaches.

It is recommended to review and remove permissions from the S3 bucket policy by deleting statements that grant access to restricted actions for other AWS accounts.
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. Login to the AWS Console
2. Navigate to the 'S3' service
3. Click on the 'S3' resource reported in the alert
4. Choose Permissions, and then choose Bucket Policy.
5. In the Bucket policy editor text box, do one of the following:
 5a. Remove the statements that grant access to denied actions to other AWS accounts
   or
    5b. Remove the permitted denied actions from the statements
6. Choose Save..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = policy.Statement[?any(Effect equals Allow and (Principal.AWS does not equal * and Principal does not equal * and Principal.AWS contains arn and Principal.AWS does not contain $.accountId) and (Action contains "s3:Put*" or Action contains "s3:Delete*" or Action equals "*" or Action contains "s3:*" or Action is member of ('s3:DeleteBucketPolicy','s3:PutBucketAcl','s3:PutBucketPolicy','s3:PutEncryptionConfiguration','s3:PutObjectAcl') ))] exists```
IBM Cloud Object Storage bucket is publicly readable through an access group
This policy identifies an IBM Cloud Object Storage bucket that is publicly readable by 'ObjectReader' or 'ContentReader' roles via the public access group. 

IBM Public Access Group is a predefined group that manages public permissions and access control for resources and services. Assigning an access policy to the public access group with a resource, provides access to the resource to anyone, whether they're a member of your account or not, because  authentication is no longer required. With this configuration, you may risk compromising critical data by leaving the IBM Cloud Object Storage public. 

As a best security practice, avoid adding policies to the public access group to make sure buckets are not publicly accessible.
This is applicable to ibm cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: To remove the public access policy for a bucket,

1. Log in to the IBM Cloud console
2. In the IBM Cloud console, click 'Manage' on the title bar > 'Access (IAM)', and click on 'Access groups' in the left panel
3. Click on the 'Public Access' access group
4. Click on the three dots in the right corner of a row for the policy that has the reported resource or bucket name in the Resources section
5. Click on 'Remove' to delete the public access policy in the reported resource
6. Review the policy details that you're about to remove, and confirm by clicking 'Remove'.

Query:
```config from cloud.resource where cloud.type = 'ibm' and api.name = 'ibm-iam-policy' AND json.rule = type equal ignore case "access" and roles[?any( role_id is member of ("crn:v1:bluemix:public:cloud-object-storage::::serviceRole:ObjectReader","crn:v1:bluemix:public:cloud-object-storage::::serviceRole:ContentReader") )] exists and resources[?any( attributes[?any( name equal ignore case "resourceType" and value equal ignore case "bucket" and operator is member of ("stringEquals", "stringMatch") )] exists )] exists and subjects[?any( attributes[?any( name contains "access_group_id" and value contains "AccessGroupId-PublicAccess")] exists )] exists as X; config from cloud.resource where api.name = 'ibm-object-storage-bucket' as Y; filter ' $.X.resources[*].attributes[*].value intersects $.Y.name and $.X.resources[*].attributes[*].value intersects $.Y.service_instance_id '; show Y;```
again test perf of AWS EKS cluster endpoint access publicly enabled
When you create a new cluster, Amazon EKS creates an endpoint for the managed Kubernetes API server that you use to communicate with your cluster (using Kubernetes management tools such as kubectl). By default, this API server endpoint is public to the internet, and access to the API server is secured using a combination of AWS Identity and Access Management (IAM) and native Kubernetes Role Based Access Control (RBAC).

This policy checks your Kubernetes cluster endpoint access and triggers an alert if publicly enabled.
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: Enable private access to the Kubernetes API server so that all communication between your worker nodes and the API server stays within your VPC. Disable public access to your API server so that it's not accessible from the internet.

1. Login to AWS Console
2. Navigate to the Amazon EKS dashboard
3. Choose the name of the cluster to display your cluster information
4. Under Networking, choose 'Manage networking'
5. Select 'Private' radio button
6. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-eks-describe-cluster' AND json.rule =  resourcesVpcConfig.endpointPublicAccess is true or resourcesVpcConfig.endpointPrivateAccess is false```
OCI users customer secret keys have aged more than 90 days without being rotated
This policy identifies all of your IAM User customer secret keys which have not been rotated in the past 90 days. It is recommended to verify that they are rotated on a regular basis in order to protect OCI customer secret keys access directly or via SDKs or OCI CLI.
This is applicable to oci cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['KEYS_AND_SECRETS'].
Mitigation of this issue can be done as follows: 1. Login to the OCI Console
2. Select Identity & Security from the Services menu.
3. Select Users from the Identity menu.
4. Click on an individual user under the Name heading.
5. Click on Customer Secret Keys in the lower left-hand corner of the page.
6. Delete any Access Keys with a date of 90 days or older under the Created column of
the Customer Secret Keys..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-iam-user' AND json.rule = 'customerSecretKeys[?any(lifecycleState equals ACTIVE and (_DateTime.ageInDays(timeCreated) > 90))] exists'```
Azure Microsoft Defender for Cloud MCAS integration Disabled
This policy identifies Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) which has Microsoft Defender for Cloud Apps (MCAS) integration disabled. Enabling Microsoft Defender for Cloud provides the tools needed to harden your resources, track your security posture, protect against cyberattacks, and streamline security management. It is highly recommended to enable Microsoft Defender for MCAS.
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'
3. Select 'Environment Settings'
4. Click on the subscription name
5. Select the 'Integrations'
6. Check/Enable option 'Allow Microsoft Defender for Cloud Apps to access my data'
7. Select 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = settings[?any( name equals MCAS and properties.enabled is false )] exists ```