knarayan/cloud_posture_checks huggingface dataset:
Azure Network Security Group allows all traffic on FTP (TCP Port 21)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on FTP (TCP Port 21). Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict FTP 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(21,21) or destinationPortRanges[*] contains _Port.inRange(21,21) ))] exists```
AWS WAF Classic (Regional) in use
This policy identifies AWS Classic WAF which is in use. As a best practice, create the AWS WAFv2 and configure accordingly to protect against application-layer attacks. The block criteria in the WAFv2 web access control list (web ACL) has more capabilities than the Classic WAF to filter-out malicious traffic.
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: To migrate a web ACL from AWS WAF Classic to AWS WAF, follow below URL:
https://docs.aws.amazon.com/waf/latest/developerguide/waf-migrating-procedure.html.

Query:
```config from cloud.resource where api.name = 'aws-waf-classic-web-acl-resource' AND json.rule = resources.apiGateway[*] exists or resources.applicationLoadBalancer[*] exists```
IBM Cloud Default Security Group allow all traffic on SSH port (22)
This policy identifies IBM Cloud Default Security groups that allow all traffic on SSH port 22. Doing so, may allow a bad actor to brute force their way into the system and potentially get access to the entire network. A VPC comes with a default security group whose initial configuration allows access from all members that are attached to this security group. If you do not specify a security group when you launch a Virtual Server, the Virtual Server is automatically assigned to this default security group. As a result, the Virtual Server will be having risk of uncontrolled connectivity. It is recommended that the Default Security Group allows network ports, protocols, and services listening on a system with validated business needs that are running on each system.
This is applicable to ibm cloud and is considered a medium severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: Before making any changes, please check the impact to your applications/services. If the Security Groups reported indeed need to restrict all traffic, follow the instructions below:
1. Log in to the IBM Cloud Console
2. Click on 'Menu Icon' and navigate to 'VPC Infrastructure' and then 'Security Groups'
3. Select the 'Security Groups' reported in the alert
4. Go to 'Inbound rules' under 'Rules' tab
5. Click on three dots on the right corner of a row containing rule that has 'Source type' as 'Any' and 'Value' as 22 (or range containing 22)
6. Click on 'Delete'.

Query:
```config from cloud.resource where api.name = 'ibm-vpc-network-security-group' AND json.rule = rules[?any( remote.cidr_block equals "0.0.0.0/0" and direction equals "inbound" and ( protocol equals "all" or ( protocol equals "tcp" and (( port_max greater than 22 and port_min less than 22 ) or ( port_max equals 22 and port_min equals 22 )))))] exists as X; config from cloud.resource where api.name = 'ibm-vpc' as Y; filter ' $.X.id equals $.Y.default_security_group.id '; show X;```
AWS EC2 instance not configured with Instance Metadata Service v2 (IMDSv2)
This policy identifies AWS instances that are not configured with Instance Metadata Service v2 (IMDSv2). With IMDSv2, every request is now protected by session authentication. IMDSv2 protects against misconfigured-open website application firewalls, misconfigured-open reverse proxies, unpatched SSRF vulnerabilities, and misconfigured-open layer-3 firewalls and network address translation. It is recommended to use only IMDSv2 for all your EC2 instances.

For more details:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
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: 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. Refer 'Configure instance metadata options for existing instances' section from follwoing URL
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html

NOTE: Make a precaution before you enforce the use of IMDSv2, as applications or agents that use IMDSv1 for instance metadata access will break..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-instances' AND json.rule = state contains running and metadataOptions.httpEndpoint equals enabled and metadataOptions.httpTokens does not contain required```
AWS Log metric filter and alarm does not exist for Network gateways changes
This policy identifies the AWS regions which do not have a log metric filter and alarm for Network gateways changes. Monitoring changes to network gateways will help ensure that all ingress/egress traffic traverses the VPC border via a controlled path. It is recommended that a metric filter and alarm be established for changes to network gateways.

NOTE: This policy will trigger alert if you have at least one Cloudtrail with the multi trial is enabled, Logs all management events in your account and is not set with specific log metric filter and alarm.
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 in to AWS Console
2. Navigate to CloudWatch dashboard
3. Click on 'Log groups' in the 'Logs' section (Left panel)
4. Select the log group created for your CloudTrail trail event logs (CloudTrail should be multi trail enabled with all management events captured) and click 'Create Metric Filter' button.
5. In 'Define Logs Metric Filter' page, add 'Filter pattern' value as 
{ ($.eventName = CreateCustomerGateway) || ($.eventName = DeleteCustomerGateway) || ($.eventName = AttachInternetGateway) || ($.eventName = CreateInternetGateway) || ($.eventName = DeleteInternetGateway) || ($.eventName = DetachInternetGateway) }
and Click on 'Assign Metric'
6. In 'Create Metric Filter and Assign a Metric' page, Choose Filter Name, Metric Details parameter according to your requirement and click on 'Create Filter'
7. Click on 'Create Alarm',
	- In Step 1 specify metric details and conditions details as required and click on 'Next'
	- In Step 2 Select an SNS topic either by creating a new topic or use existing SNS topic/ARN and click on 'Next'
	- In Step 3 Select name and description to alarm and click on 'Next'
	- In Step 4 Preview your data entered and click on 'Create Alarm'.

Query:
```config from cloud.resource where api.name = 'aws-logs-describe-metric-filters' as X; config from cloud.resource where api.name = 'aws-cloudwatch-describe-alarms' as Y; config from cloud.resource where api.name = 'aws-cloudtrail-describe-trails' as Z; filter '(($.Z.cloudWatchLogsLogGroupArn is not empty and $.Z.cloudWatchLogsLogGroupArn contains $.X.logGroupName and $.Z.isMultiRegionTrail is true and $.Z.includeGlobalServiceEvents is true) and (($.X.filterPattern contains "eventName=" or $.X.filterPattern contains "eventName =") and ($.X.filterPattern does not contain "eventName!=" and $.X.filterPattern does not contain "eventName !=") and $.X.filterPattern contains CreateCustomerGateway and $.X.filterPattern contains DeleteCustomerGateway and $.X.filterPattern contains AttachInternetGateway and $.X.filterPattern contains CreateInternetGateway and $.X.filterPattern contains DeleteInternetGateway and $.X.filterPattern contains DetachInternetGateway) and ($.X.metricTransformations[*] contains $.Y.metricName))'; show X; count(X) less than 1```
AWS SNS topic is exposed to unauthorized access
This policy identifies AWS SNS topics that are exposed to unauthorized access. Amazon Simple Notification Service (Amazon SNS) is a web service that coordinates and manages the delivery or sending of messages to subscribing endpoints or clients. To protect these messages from attackers and unauthorized accesses, permissions should be given to only authorized users.

For more details:
https://docs.aws.amazon.com/sns/latest/dg/sns-security-best-practices.html#ensure-topics-not-publicly-accessible
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 the region drop-down on the top right corner, for which the alert is generated.
3. Navigate to the 'Simple Notification Service' dashboard
4. Go to 'Topics', from the left panel
5. Select the reported SNS topic
6. Click on the 'Edit' button from the top options bar
7. On the edit page go to the 'Access Policy - optional' section
8. Add the restrictive 'Condition' statement to the JSON editor to specify who can access the topic. OR Make 'Principal' restrictive so that only limited resources allowed.
9. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-sns-get-topic-attributes' AND json.rule = Policy.Statement[?any(Effect equals Allow and (Principal.AWS equals * or Principal equals *) and Condition does not exist)] exists```
GCP Dataproc Cluster not configured with Customer-Managed Encryption Key (CMEK)
This policy identifies Dataproc Clusters that are not configured with CMEK. Dataproc cluster and job data are stored on persistent disks associated with the Compute Engine VMs in the cluster as well as in a Cloud Storage staging bucket. As a security best practice use of CMEK to encrypt this data on persistent disk and bucket is advisable and provides more control to the user.
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: Currently, it is not possible to update the encryption key for a GCP Dataproc Cluster. It is recommended to create a new cluster with appropriate CMEK and migrate all workloads from the old cluster to the new cluster.

To configure encryption key for GCP Dataproc Cluster while creation, please refer to the URL given below:
https://cloud.google.com/dataproc/docs/concepts/configuring-clusters/customer-managed-encryption#use_cmek_with_cluster_data.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-dataproc-clusters-list' AND json.rule = config.encryptionConfig.gcePdKmsKeyName does not exist and config.encryptionConfig.kmsKey does not exist```
Copy of AWS Cognito identity pool allows unauthenticated guest access
This policy identifies AWS Cognito identity pools that allow unauthenticated guest access.

AWS Cognito identity pools unauthenticated guest access and allows unauthenticated users to assume a role in your AWS account. These unauthenticated users will be granted permissions of the assumed role which may have more privileges than that are intended. This could lead to unauthorized access or data leakage.

It is recommended to disable unauthenticated guest access for the Cognito identity pools.
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: To deactivate guest access in an identity pool,
1. Log in to AWS console
2. Navigate to the reported resource region by selecting the region from the dropdown in the top right corner.
3. Navigate to the Amazon Cognito dashboard
4. Under '''Identity pools''' section, select the reported identity pool
5. In '''User access''' tab, under '''Guest access''' section
6. Click on '''Deactivate''' button to deactivate the guest access configured.

NOTE: Before you deactivate unauthenticated guest access, it is must to have at-least one authenticated access configured in your identity pool..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cognito-identity-pool' AND json.rule = allowUnauthenticatedIdentities is true```
bobby remediation 1

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: ddddd.

Query:
```config from cloud.resource where api.name = 'gcloud-logging-metric' as X; config from cloud.resource where api.name = 'gcloud-monitoring-policies-list' as Y; filter '$.Y.conditions[*].metricThresholdFilter contains $.X.name and ( $.X.filter contains "resource.type =" or $.X.filter contains "resource.type=" ) and ( $.X.filter does not contain "resource.type !=" and $.X.filter does not contain "resource.type!=" ) and $.X.filter contains "gce_route" and ( $.X.filter contains "protoPayload.methodName:" or $.X.filter contains "protoPayload.methodName :" ) and ( $.X.filter does not contain "protoPayload.methodName!:" and $.X.filter does not contain "protoPayload.methodName !:" ) and $.X.filter contains "compute.routes.delete" and $.X.filter contains "compute.routes.insert"'; show X; count(X) less than 1```
AWS RDS PostgreSQL exposed to local file read vulnerability
This policy identifies AWS RDS PostgreSQL which are exposed to local file read vulnerability. AWS RDS PostgreSQL installed with vulnerable 'log_fdw' extension is exposed to local file read vulnerability, due to which attacker could gain access to local system files of the database instance within their account, including a file which contained credentials specific to PostgreSQL. It is highly recommended to upgrade AWS RDS PostgreSQL to the latest version.

For more information,
https://aws.amazon.com/security/security-bulletins/AWS-2022-004/
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: Amazon has deprecated affected versions of RDS for PostgreSQL and customers can no longer create new instances with the affected versions.

To upgrade the latest version of Amazon RDS for PostgreSQL, please follow below URL:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html
.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-rds-describe-db-instances' AND json.rule = dbinstanceStatus equals available and engine equals postgres and engineVersion is member of ('13.2','13.1','12.6','12.5','12.4','12.3','12.2','11.11','11.10','11.9','11.8','11.7','11.6','11.5','11.4','11.3','11.2','11.1','10.16','10.15','10.14','10.13','10.12','10.11','10.10','10.9','10.7','10.6','10.5','10.4','10.3','10.1','9.6.21','9.6.20','9.6.19','9.6.18','9.6.17','9.6.16','9.6.15','9.6.14','9.6.12','9.6.11','9.6.10','9.6.9','9.6.8','9.6.6','9.6.5','9.6.3','9.6.2','9.6.1','9.5','9.4','9.3')```
AWS EMR cluster is not enabled with local disk encryption
This policy identifies AWS EMR clusters that are not enabled with local disk encryption. Applications using the local file system on each cluster instance for intermediate data throughout workloads, where data could be spilled to disk when it overflows memory. With Local disk encryption at place, data at rest can be protected.
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. Under 'Local disk encryption', check the box 'Enable at-rest encryption for local disks'.
8. Select the appropriate Key provider type from the  'Key provider type' dropdown list.
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 the new cluster is set up verify its working and terminate the source cluster.
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.status.state does not contain TERMINATED and $.X.status.state does not contain TERMINATED_WITH_ERRORS) and ($.X.securityConfiguration contains $.Y.name) and ($.Y.EncryptionConfiguration.EnableAtRestEncryption is true) and ($.Y.EncryptionConfiguration.AtRestEncryptionConfiguration.LocalDiskEncryptionConfiguration does not exist)' ; show X;```
AWS IAM user is not a member of any IAM group
This policy identifies an AWS IAM user as not being a member of any IAM group.

It is generally a best practice to assign IAM users to at least one IAM group. If the IAM users are not in a group, it complicates permission management and auditing, increasing the risk of privilege mismanagement and security oversights. It also leads to higher operational overhead and potential non-compliance with security best practices.

It is recommended to ensure all IAM users are part of at least one IAM group according to your business requirement to simplify permission management, enforce consistent security policies, and reduce the risk of privilege mismanagement.
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 add a user to an IAM user group (console)

1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/
2. In the navigation pane, choose 'Users' under the 'Access management' section and then choose the name of the user that is reported
3. Choose the 'Groups' tab and then choose 'Add user to groups'. 
4. Select the check box next to the groups under 'Group Name' according to your requirements.
5. Choose 'Add user to group(s)'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-list-users' AND json.rule = groupList is empty```
Alibaba Cloud OSS bucket logging not enabled
This policy identifies Alibaba Cloud Object Storage Service (OSS) buckets that do not have logging enabled.

Enabling logging for OSS buckets helps capture access and operation events, which are critical for security monitoring, troubleshooting, and auditing. Without logging, you lack visibility into who accesses and interacts with your bucket, potentially missing unauthorized access or suspicious behaviour.

As a security best practice, it is recommended to enable logging for OSS buckets.
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 Object Storage Service
3. In the bucket-list pane, click on a reported OSS bucket
4. Under Log, click configure
5. Configure bucket logging
6. Click the Enabled checkbox
7. Select Target Bucket from list
8. Enter a Target Prefix
9. Click Save.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' and api.name = 'alibaba-cloud-oss-bucket-info' AND json.rule = bucket.logging.targetBucket does not exist```
AWS S3 bucket is not configured with MFA Delete
This policy identifies the S3 buckets which do not have Multi-Factor Authentication(MFA) enabled to delete S3 object version. Enabling MFA Delete on a versioned bucket adds another layer of protection. In order to permanently delete an object version or suspend or reactivate versioning on the bucket valid code from the account's MFA device required.

Note: MFA Delete only works for CLI or API interaction, not in the AWS Management Console. Also, you cannot make version DELETE actions with MFA using IAM user credentials. You must use your root AWS account.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MFA'].
Mitigation of this issue can be done as follows: Using console you can enable versioning on the bucket but you cannot enable MFA delete.
You can do it via only with the AWS CLI:
aws s3api put-bucket-versioning --bucket <BUCKET_NAME> --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa "<MFA_SERIAL_NUMBER> <MFA_CODE>"

NOTE: The bucket owner, the AWS account that created the bucket (root account), and all authorized IAM users can enable versioning, but only the bucket owner (root account) can enable MFA Delete. Successful execution will enable the S3 bucket versioning and MFA delete on the bucket..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = versioningConfiguration.status equals Enabled and (versioningConfiguration.mfaDeleteEnabled does not exist or versioningConfiguration.mfaDeleteEnabled is false) AND (bucketLifecycleConfiguration does not exist or bucketLifecycleConfiguration.rules[*].status equals Disabled)```