knarayan/cloud_posture_checks huggingface dataset:
AWS Route53 Hosted Zone having dangling DNS record with subdomain takeover risk associated with AWS S3 Bucket
This policy identifies AWS Route53 Hosted Zones which have dangling DNS records with subdomain takeover risk associated with AWS S3 Bucket. A Route53 Hosted Zone having a CNAME entry pointing to a non-existing S3 bucket will have a risk of these dangling domain entries being taken over by an attacker by creating a similar S3 bucket in any AWS account which the attacker owns / controls. Attackers can use this domain to do phishing attacks, spread malware and other illegal activities. As a best practice, it is recommended to delete dangling DNS records entry from your AWS Route 53 hosted zones.
This is applicable to aws cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: Identify DNS record entry pointing to a non-existing S3 bucket resource.

To remove DNS record entry, follow steps given in following URL:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-deleting.html.

Query:
```config from cloud.resource where api.name = 'aws-route53-list-hosted-zones' AND json.rule = hostedZone.config.privateZone is false and resourceRecordSet[?any( type equals CNAME and resourceRecords[*].value contains s3-website )] exists as X; config from cloud.resource where api.name = 'aws-s3api-get-bucket-acl' as Y; filter 'not ($.X.resourceRecordSet[*].name intersects $.Y.bucketName)'; show X;```
AWS Network ACLs that allow ingress from 0.0.0.0/0 to remote server administration ports

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 cloud.type = 'aws' AND api.name = 'aws-ec2-describe-network-acls' AND json.rule = "entries[?any(egress equals false and ((protocol equals 6 and ((portRange.to equals 22 or portRange.to equals 3389 or portRange.from equals 22 or portRange.from equals 3389) or (portRange.to > 22 and portRange.from < 22) or (portRange.to > 3389 and portRange.from < 3389))) or protocol equals -1) and (cidrBlock equals 0.0.0.0/0 or ipv6CidrBlock equals ::/0) and ruleAction equals allow)] exists"```
AWS S3 buckets with configurations set to host websites
This policy identifies AWS S3 buckets that are configured to host websites. To host a website on AWS S3 you should configure a bucket as a website. By frequently surveying these S3 buckets, you can ensure that only authorized buckets are enabled to host websites. Make sure to disable static website hosting for unauthorized S3 buckets.
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. Login to AWS Console
2. Goto S3 under Services
3. Choose the reported bucket
4. Goto Properties tab
5. Click on Static website hosting
6. Click on Disable website hosting
7. Click on Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule =  'websiteConfiguration exists'```
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```
BikramTest-AWS S3 Object Versioning is disabled
This policy identifies the S3 buckets which have Object Versioning disabled. S3 Object Versioning is an important capability in protecting your data within a bucket. Once you enable Object Versioning, you cannot remove it; you can suspend Object Versioning at any time on a bucket if you do not wish for it to persist. It is recommended to enable Object Versioning on S3.
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 into your AWS Console and select the S3 service.
2. Choose the reported S3 bucket and click the Properties tab in the upper right frame.
3. Expand the Versioning option
4. Click Enable Versioning
5. Click Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = 'versioningConfiguration.status!=Enabled'```
AWS Elastic Load Balancer (Classic) with access log disabled
This policy identifies Classic Elastic Load Balancers which have access log disabled. When Access log enabled, Classic load balancer captures detailed information about requests sent to your load balancer. Each log contains information such as the time the request was received, the client's IP address, latencies, request paths, and server responses. You can use these access logs to analyze traffic patterns and to troubleshoot issues.
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 access logging for Elastic Load Balancer (Classic), follow below mentioned URL:
https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elb-describe-load-balancers' AND json.rule = 'attributes.accessLog.enabled is false'```
AWS EMR cluster is not enabled with data encryption at rest
This policy identifies AWS EMR clusters for which data encryption at rest is not enabled. Encryption of data at rest is required to prevent unauthorized users from accessing the sensitive information available on your  EMR clusters and associated storage systems.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: 1. Login 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 'EMR' dashboard from 'Services' dropdown.
4. Go to 'Security configurations', click 'Create'.
5. On the Create security configuration window,
6. In 'Name' box, provide a name for the new EMR security configuration.
7. For encryption At Rest select the required encryption type ('S3 encryption'/'Local disk encryption'/both) and follow below link for enabling the same.
8. https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-enable.html

9. Click on 'Create' button.
10. On the left menu of EMR dashboard Click 'Clusters'.
11. Select the EMR cluster for which the alert has been generated and click on the 'Clone' button from the top menu.
12. In the Cloning popup, choose 'Yes' and Click 'Clone'.
13. On the Create Cluster page, in the Security Options section, click on 'security configuration'.
14. From the 'Security configuration' drop down select the name of the security configuration created at step 4 to step 8, click 'Create Cluster'.
15. Once you the new cluster is set up verify its working and terminate the source cluster in order to stop incurring charges for it.
16. On the left menu of EMR dashboard Click 'Clusters', from the list of clusters select the source cluster which is alerted.
17. Click on the 'Terminate' button from the top menu.
18. On the 'Terminate clusters' pop-up, click 'Terminate'..

Query:
```config from cloud.resource where api.name = 'aws-emr-describe-cluster' as X; config from cloud.resource where api.name = 'aws-emr-security-configuration' as Y; filter '($.X.status.state does not contain TERMINATING) and ($.X.securityConfiguration equals $.Y.name) and ($.Y.EncryptionConfiguration.EnableAtRestEncryption is false)'; show X;```
GCP HTTPS Load balancer is configured with SSL policy having TLS version 1.1 or lower
This policy identifies HTTPS Load balancers is configured with SSL policy having TLS version 1.1 or lower. As a best security practice, use TLS 1.2 as the minimum TLS version in your load balancers SSL security policies.
This is applicable to gcp cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: 1. Login to GCP Portal
2. Go to Network services (Left Panel)
3. Select Load balancing
4. Click on 'load balancing components view' hyperlink at bottom of the page to view target proxies
5. Click on 'TARGET PROXIES' tab
6. Click on the reported HTTPS target proxy
7. Click on the hyperlink under 'Load balancer'
8. Click on the 'EDIT' button
9. Select 'Frontend configuration', Click on HTTPS protocol rule
10. Select SSL policy that uses TLS 1.2 version or create a new SSL policy with TLS 1.2 as Minimum TLS version from the dropdown for 'SSL policy'
11. Click on 'DONE'
12. Click on 'UPDATE'.

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;```
AWS SageMaker notebook instance not encrypted using Customer Managed Key
This policy identifies SageMaker notebook instances that are not encrypted using Customer Managed Key. SageMaker notebook instances should be encrypted with Amazon KMS Customer Master Keys (CMKs) instead of AWS managed-keys in order to have more granular control over the data-at-rest encryption/decryption process and meet compliance requirements.

For more details:
https://docs.aws.amazon.com/sagemaker/latest/dg/encryption-at-rest.html
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: AWS SageMaker notebook instance encryption can not be modified once it is created. You need to create a new notebook instance with encryption using a custom KMS key; migrate all required data from the reported notebook instance to the newly created notebook instance before you delete the reported notebook instance.

To create a New AWS SageMaker notebook instance,
1. Log in to AWS console
2. Navigate to the AWS SageMaker dashboard
3. Choose Notebook instances and then choose 'Create notebook instance'
4. On the Create notebook instance page, within the 'Permissions and encryption' section,
From the 'Encryption key - optional' dropdown list, choose a custom KMS key for the new SageMaker notebook instance.
5. Choose other parameters as per your requirement and click on the 'Create notebook instance' button

To delete reported notebook instance,
1. Log in to AWS console
2. Navigate to the AWS SageMaker dashboard
3. Choose Notebook instances and Choose the reported notebook instance
4. Click on the 'Actions' dropdown menu, select the 'Stop' option, and when instance stops, select the 'Delete' option.
5. Within Delete <notebook-instance-name> dialog box, click the Delete button to confirm the action..

Query:
```config from cloud.resource where api.name = 'aws-sagemaker-notebook-instance' AND json.rule = notebookInstanceStatus equals InService and kmsKeyId exists as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' as Y; filter '$.X.kmsKeyId equals $.Y.key.keyArn and $.Y.keyMetadata.keyManager contains AWS'; show X;```
GCP KMS crypto key is anonymously accessible
This policy identifies GCP KMS crypto keys that are anonymously accessible. Granting permissions to 'allUsers' or 'allAuthenticatedUsers' allows anyone to access the KMS key. As a security best practice, it is recommended not to bind such members to KMS IAM policy.
This is applicable to gcp 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: Granting/revoking access for the KMS key is only supported by CLI. To remediate run the below CLI command. 

1. List all the cryptokeys which has overly permissive IAM bindings,

gcloud asset search-all-iam-policies --asset-types=cloudkms.googleapis.com/CryptoKey --query="policy:(allUsers OR allAuthenticatedUsers)" 

2. Remove IAM policy binding for a KMS key to remove access to allUsers and allAuthenticatedUsers using the below command.

gcloud kms keys remove-iam-policy-binding [key_name] --keyring='[key_ring_name]' --location='[location]' --member='[allUsers/allAuthenticatedUsers]' --role='[role]'

Refer to the following URL for more information on “remove-iam-policy-binding” command.
https://cloud.google.com/sdk/gcloud/reference/projects/remove-iam-policy-binding.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-kms-crypto-keys-list' AND json.rule = ((purpose does not equal ENCRYPT_DECRYPT) or (purpose equals ENCRYPT_DECRYPT and primary.state equals ENABLED)) and iamPolicy.bindings[*].members contains allUsers or iamPolicy.bindings[*].members contains allAuthenticatedUsers```
Azure App Service Web app authentication is off
Azure App Service Authentication is a feature that can prevent anonymous HTTP requests from reaching the API app, or authenticate those that have tokens before they reach the API app. If an anonymous request is received from a browser, App Service will redirect to a logon page. To handle the logon process, a choice from a set of identity providers can be made, or a custom authentication mechanism can be implemented.
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 the Azure portal
2. Navigate to App Services
3. Click on the reported App
4. Under the Setting section, Click on 'Authentication / Authorization'
	a. In case the Identity Provider is not configured: https://learn.microsoft.com/en-gb/azure/app-service/overview-authentication-authorization#identity-providers 
	b. In case the identity Provider is configured and disabled:
		i. Edit Authentication Settings
		ii. Set 'App Service Authentication' to 'Enabled'
		iii. Choose other parameters as per your requirement and Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = 'kind starts with app and config.siteAuthEnabled equals false'```
tbsjmfcdgf_ui_auto_policies_tests_name
rjyyqylxvc_ui_auto_policies_tests_descr
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 api.name = 'aws-iam-list-users' AND json.rule = createDate contains 2018```
PCSUP-22910-Policy

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 cloud.type = 'aws' and api.name='aws-ec2-describe-snapshots' AND json.rule='createVolumePermissions[*].group contains all' ```
IBM Cloud Service ID with IAM policies provide administrative privileges for Cloud object storage buckets
This policy identifies IBM Cloud Service ID, which has policy with administrator role permission for cloud object storage service. 

IBM Cloud Object Storage is a highly scalable, resilient, and secure managed data storage service on the IBM Cloud platform that offers an alternative to traditional block and file storage solutions. When a Service ID having a policy with admin rights on object storage gets compromised, the whole service gets compromised.

As a security best practice, it is recommended to grant the least privileged access, such as granting only the permissions required to perform a task, instead of providing excessive permissions.
This is applicable to ibm cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['HIGH_PRIVILEGED_ROLE'].
Mitigation of this issue can be done as follows: 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 'Service IDs' in the left panel.
3. Select the Service ID that is reported and that you want to edit access to.
4. Under the 'Access' tab, go to the 'Access policies' section and click on the three dots on the right corner of a row for the policy that has administrator permission on the 'IBM Cloud Object Storage' service.
5. Click on Remove or Edit to assign limited permission to the policy.
6. Review the policy details that you're about to edit or remove, and confirm by clicking Save or Remove..

Query:
```config from cloud.resource where 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:iam::::role:Administrator","crn:v1:bluemix:public:iam::::serviceRole:Manager") )] exists and resources[?any( attributes[?any( name equal ignore case "serviceName" and value equal ignore case "cloud-object-storage" and operator is member of ("stringEquals", "stringMatch"))] exists and (attributes[?any( name is member of ("resource","resourceGroupId","serviceInstance","prefix"))] does not exist or attributes[?any( name equal ignore case "resourceType" and value equal ignore case "bucket" )] exists ) )] exists and subjects[?any( attributes[?any( name contains "iam_id" and value contains "iam-ServiceId")] exists )] exists as X;config from cloud.resource where api.name = 'ibm-iam-service-id' as Y; filter '$.X.subjects[*].attributes[*].value contains $.Y.id'; show Y;```
Azure Automation account variables are not encrypted
This policy identifies Automation accounts variables that are not encrypted. Variable assets are values that are available to all runbooks and DSC configurations in your Automation account. When a variable is created, you can specify that it be stored encrypted. Azure Automation stores each encrypted variable securely. It is recommended to enable encryption of Automation account variable assets when storing sensitive data.
This is applicable to azure cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: 1. Log in to Azure portal
2. Navigate to 'Automation Accounts'
3. Click on the reported Automation Account
4. Select 'Variables' under 'Shared Resources' from left panel 
NOTE: If you have Automation account variables storing sensitive data that are not already encrypted, then you will need to delete them and recreate them as encrypted variables.
5. Delete the unencrypted variables and recreate them by setting the option 'Encrypted' as 'Yes'..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-automation-account' AND json.rule = variable[?any(properties.isEncrypted is false)] exists```
AWS SSM documents are public
This policy identifies list of SSM documents that are public and might allow unintended access. A public SSM document can expose valuable information about your account, resources, and internal processes. It is recommended to only share SSM documents to only few private AWS accounts based on the requirement.
This is applicable to aws 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 make an SSM document private follow the steps mentioned in below URL:
1.Go to the AWS console Systems Manager Dashboard.
2.If the AWS Systems Manager home page opens first, choose the menu icon to open the navigation pane, and then choose Documents in the navigation pane.

3.In the documents list, choose the document you want to stop sharing, and then choose details. On the Permissions tab, verify that you're the document owner. Only a document owner can stop sharing a document.
4.Choose Edit.
5.Select Private option, and enter AWS accountId only with which this document can be shared(leave it blank if not willing to share now). 
6.Choose Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ssm-document' AND json.rule = accountSharingInfoList[*].accountId equal ignore case "all"```