knarayan/cloud_posture_checks huggingface dataset:
AWS ECS Fargate task definition root user found
This policy identifies AWS ECS Fargate task definition which has user name as root. As a best practice, the user name to use inside the container should not be root.

Note: This parameter is not supported for Windows containers.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['HIGH_PRIVILEGED_ROLE'].
Mitigation of this issue can be done as follows: Create a task definition revision.

1. Open the Amazon ECS console.
2. From the navigation bar, choose the region that contains your task definition.
3. In the navigation pane, choose Task Definitions.
4. On the Task Definitions page, select the box to the left of the task definition to revise and choose Create new revision.
5. On the Create new revision of Task Definition page, change the existing Container Definitions.
6. Under Security, remove root from the User field.
7. Verify the information and choose Update, then Create.
8. If your task definition is used in a service, update your service with the updated task definition.
9. Deactivate previous task definition.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ecs-describe-task-definition' AND json.rule =  containerDefinitions[*].user exists and containerDefinitions[*].user contains root```
Alibaba Cloud Security group allow internet traffic to SSH port (22)
This policy identifies Security groups that allow inbound traffic on SSH port (22) from the public internet. As a best practice, restrict security groups to only allow permitted traffic and limit brute force attacks on your network.
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. Go to Elastic Compute Service
3. In the left-side navigation pane, choose Network & Security > Security Groups
4. Select the reported security group and then click Add Rules in the Actions column
5. In Inbound tab, Select the rule having 'Action' as Allow, 'Authorization Object' as 0.0.0.0/0 and 'Port Range' value as 22, Click Modify in the Actions column
6. Replace the value 0.0.0.0/0 with specific IP address range.
7. Click on 'OK'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ecs-security-group' AND json.rule = "permissions is not empty and permissions[?(@.policy=='Accept' && @.direction=='ingress' && @.sourceCidrIp=='0.0.0.0/0')].portRange contains _Port.inRange(22,22)"```
Alibaba Cloud RAM password policy does not have a minimum of 14 characters
This policy identifies Alibaba Cloud accounts that do not have a minimum of 14 characters in the password policy. As a security best practice, configure a strong password policy for secure access to the Alibaba Cloud console.
This is applicable to alibaba_cloud cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['WEAK_PASSWORD'].
Mitigation of this issue can be done as follows: 1. Log in to Alibaba Cloud Portal
2. Go to Resource Access Management (RAM) service
3. In the left-side navigation pane, click on 'Settings'
4. In the 'Security Settings' tab, In the 'Password Strength Settings' Section, Click on 'Edit Password Rule'
5. In the 'Password Length' field, enter 14 as the minimum number of characters for password complexity.
6. Click on 'OK'
7. Click on 'Close'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ram-password-policy' AND json.rule =  'minimumPasswordLength does not exist or minimumPasswordLength less than 14'```
IBM Cloud unattached disk is not encrypted with customer managed key
This policy identifies IBM Cloud unattached disks (storage volume) which are not encrypted with customer managed keys. As a best practice, use customer managed keys to encrypt the data and maintain control of your keys and sensitive data.
This is applicable to ibm cloud and is considered a informational severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: A disk (boot storage volume) can be encrypted with customer managed keys only at the time of
creation. Please delete reported data disk following below URL:
https://cloud.ibm.com/docs/vpc?topic=vpc-managing-block-storage&interface=ui#delete

Before deleting a disk, make sure to take snapshot of the disk by attaching it to a virtual
server instance and follow below URL to create a snapshot:
https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-create&interface=ui#snapshots-vpc-create-from-vol-details.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-block-storage-volume' AND json.rule = volume_attachments[*] size equals 0 and encryption equal ignore case provider_managed```
API automation policy mtmay

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"```
Copy of Azure Microsoft Defender for Cloud set to Off for DNS
This policy identifies Azure Microsoft Defender for Cloud which has defender setting for DNS set to Off. Enabling Azure Defender provides advanced security capabilities like providing threat intelligence, anomaly detection, and behavior analytics in the Azure Microsoft Defender for Cloud. Defender for DNS monitors the queries and detects suspicious activities without the need for any additional agents on your resources. It is highly recommended to enable Azure Defender for DNS.
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 'Defender plans'
6. Expand 'Select Defender plan by resource type'
7. Select 'On' status for 'DNS' under the column 'Microsoft Defender for'
8. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = pricings[?any(name equals Dns and properties.pricingTier does not equal Standard)] exists```
AWS Redshift instances are not encrypted
This policy identifies AWS Redshift instances which are not encrypted. These instances should be encrypted for clusters to help protect data at rest which otherwise can result in a data breach.
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: To enable encryption on your Redshift cluster follow the steps mentioned in below URL:
https://docs.aws.amazon.com/redshift/latest/mgmt/changing-cluster-encryption.html.

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name='aws-redshift-describe-clusters' AND json.rule='encrypted is false'```
Alibaba Cloud Security group allow internet traffic to VNC Server port (5900)
This policy identifies Security groups that allow inbound traffic on VNC Server port (5900) from the public internet. As a best practice, restrict security groups to only allow permitted traffic and limit brute force attacks on your network.
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. Go to Elastic Compute Service
3. In the left-side navigation pane, choose Network & Security > Security Groups
4. Select the reported security group and then click Add Rules in the Actions column
5. In Inbound tab, Select the rule with 'Action' as Allow, 'Authorization Object' as 0.0.0.0/0 and 'Port Range' value as 5900, Click Modify in the Actions column
6. Replace the value 0.0.0.0/0 with specific IP address range
7. Click on 'OK'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ecs-security-group' AND json.rule = "permissions is not empty and permissions[?(@.policy=='Accept' && @.direction=='ingress' && @.sourceCidrIp=='0.0.0.0/0')].portRange contains _Port.inRange(5900,5900)"```
GCP Google Workspace Super Admin not enrolled with 2-step verification
This policy identifies Google Workspace Super Admins that do not have 2-Step Verification enabled. 

Super Admin accounts have access to all features in the Admin console and Admin API. This additional layer of 2SV significantly reduces the risk of unauthorized access, protecting administrative controls and sensitive data from potential breaches. Implementing 2-Step Verification safeguards your entire Google Workspace environment, maintaining robust security and compliance standards.

It is recommended to enable 2-Step Verification for all Super Admins as it provides an additional layer of security in case account credentials are compromised.
This is applicable to gcp 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: Workspace users should be allowed to turn on 2-Step verification (2SV) before enabling 2SV. Follow the steps mentioned below to allow users to turn on 2SV.
1. Sign in to Workspace Admin Console with an administrator account. 
2. Go to Menu then 'Security' > 'Authentication' > '2-step verification'.
3. Check the 'Allow users to turn on 2-Step Verification' box.
4. Select 'Enforcement' as per need.
5. Click Save.

For more details, please refer to below URL:
https://support.google.com/a/answer/9176657


To enable 2-Step Verification for GCP Workspace User accounts, follow the steps below.
1. Open your Google Account.
2. In the navigation panel, select 'Security'.
3. Under 'How you sign in to Google', select '2-Step Verification' > 'Get started'.
4. Follow the on-screen steps.

For more details, please refer to below URL:
https://support.google.com/accounts/answer/185839.

Query:
```config from cloud.resource where api.name = 'gcloud-domain-users' AND json.rule = isAdmin is true and isEnrolledIn2Sv is false and archived is false and suspended is false```
AWS ECS IAM policy overly permissive to all traffic
This policy identifies ECS IAM policies that are overly permissive to all traffic. It is recommended that the ECS should be granted access restrictions so that only authorized users and applications have access to the service.

For more details:
https://docs.aws.amazon.com/AmazonECS/latest/userguide/security_iam_id-based-policy-examples.html#security_iam_service-with-iam-policy-best-practices
This is applicable to aws 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. Login to AWS console
2. Goto IAM Services
3. Click on 'Policies' in left hand panel
4. Search for the Policy for which the Alert is generated and click on it
5. Under Permissions tab, click on Edit policy
6. Under the Visual editor, for each of the 'ECS' Service, click to expand and perform following.
6.a. Click to expand 'Request conditions'
6.b. Under the 'Source IP', remove the row with the entry '0.0.0.0/0' or '::/0'. Add condition with restrictive IP ranges.
7. Click on Review policy and Save changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-policy-version' AND json.rule = isAttached is true and document.Statement[?any((Condition.ForAnyValue:IpAddress.aws:SourceIp contains 0.0.0.0/0 or Condition.IpAddress.aws:SourceIp contains 0.0.0.0/0 or Condition.IpAddress.aws:SourceIp contains ::/0 or Condition.ForAnyValue:IpAddress.aws:SourceIp contains ::/0) and Effect equals Allow and Action anyStartWith ecs:)] exists```
VenuTestCLi

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

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-networkfirewall-firewall' AND json.rule = FirewallStatus.Status equals READY and Firewall.DeleteProtection is false```
GCP PostgreSQL instance database flag log_planner_stats is not set to off
This policy identifies PostgreSQL database instances in which database flag log_planner_stats is not set to off. The PostgreSQL planner/optimizer is responsible to create an optimal execution plan for each query. The log_planner_stats flag controls the inclusion of PostgreSQL planner performance statistics in the PostgreSQL logs for each query. This can be useful for troubleshooting but may increase the number of logs significantly and have performance overhead. It is recommended to set log_planner_stats off.
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_planner_stats' from the drop-down menu and set the value as 'off'
OR
If the flag has been set to other than off, Under 'Customize your instance', In 'Flags' section choose the flag 'log_planner_stats' and set the  value as 'off'
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_planner_stats or settings.databaseFlags[?any(name contains log_planner_stats and value contains on)] exists)"```
AWS Log metric filter and alarm does not exist for disabling or scheduled deletion of customer created CMKs
This policy identifies the AWS regions which do not have a log metric filter and alarm for disabling or scheduled deletion of customer created CMKs. Data encrypted with disabled or deleted keys will no longer be accessible. It is recommended that a metric filter and alarm be established for customer created CMKs which have changed state to disabled or scheduled deletion.

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 
{ ($.eventSource = kms.amazonaws.com) && (($.eventName=DisableKey)||($.eventName=ScheduleKeyDeletion)) }
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 "eventSource=" or $.X.filterPattern contains "eventSource =") and ($.X.filterPattern does not contain "eventSource!=" and $.X.filterPattern does not contain "eventSource !=") and $.X.filterPattern contains kms.amazonaws.com and $.X.filterPattern contains DisableKey and $.X.filterPattern contains ScheduleKeyDeletion) and ($.X.metricTransformations[*] contains $.Y.metricName))'; show X; count(X) less than 1```
Azure Application Gateway listener not secured with SSL profile
This policy identifies Azure Application Gateway listeners that are not secured with an SSL profile.

An SSL profile provides a secure channel by encrypting the data transferred between the client and the application gateway. Without SSL profiles, the data transferred is vulnerable to interception, posing security risks. This could lead to potential data breaches and compromise sensitive information.

As a security best practice, it is recommended to secure all Application Gateway listeners with SSL profiles. This ensures data confidentiality and integrity by encrypting traffic.
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 'Application gateways'.
2. Select 'Application gateways'.
3. Click on reported Application gateway.
4. Under 'Settings' select 'Listeners' from the left-side menu.
5. Select the HTTPS listener.
6. Check the 'Enable SSL Profile' box.
7. Select the SSL profile you created (e.g., applicationGatewaySSLProfile) from the dropdown. If no profile exists, you'll need to create one first.
8. Finish configuring the listener as needed.
9. Click 'Add' to save the listener with the SSL profile..

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-application-gateway' AND json.rule = ['properties.provisioningState'] equal ignore case Succeeded AND ['properties.httpListeners'][*].['properties.provisioningState'] equal ignore case Succeeded AND ['properties.httpListeners'][*].['properties.protocol'] equal ignore case Https AND ['properties.httpListeners'][*].['properties.sslProfile'].['id'] does not exist```
AWS Route53 Hosted Zone having dangling DNS record with subdomain takeover risk associated with AWS Elastic Beanstalk Instance
This policy identifies AWS Route53 Hosted Zones which have dangling DNS records with subdomain takeover risk. A Route53 Hosted Zone having a CNAME entry pointing to a non-existing Elastic Beanstalk (EBS) will have a risk of these dangling domain entries being taken over by an attacker by creating a similar Elastic beanstalk (EBS) 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.

Note: Please ignore the reported alert if the Elastic Beanstalk (EBS) configured in the Route53 Hosted Zone DNS record are in different accounts. 
This is applicable to aws cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['RESOURCE_HIJACKING'].
Mitigation of this issue can be done as follows: Identify DNS record entry pointing to a non-existing Elastic Beanstalk (EBS) 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 elasticbeanstalk.com)] exists as X; config from cloud.resource where api.name = 'aws-elasticbeanstalk-environment' as Y; filter 'not (X.resourceRecordSet[*].resourceRecords[*].value intersects $.Y.cname)'; show X;```
AWS CloudWatch log groups retention set to less than 365 days
This policy identifies the AWS CloudWatch LogGroups having a retention period set to less than 365 days. 

CloudWatch Logs centralize and store logs from AWS services and systems. 1-year retention of the logs aids in compliance with log retention standards. Shorter retention periods can lead to the loss of historical logs needed for audits, forensic analysis, and compliance, increasing the risk of undetected issues or non-compliance.

It is recommended that AWS CloudWatch log group retention be set to at least 365 days to meet compliance needs and support audits, investigations, and analysis.
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 change the log retention setting, perform the following actions:

1. Sign into the AWS console
2. In the console, select the specific region from region drop down on the top right corner, for which the alert is generated
3. Navigate to 'CloudWatch Dashboard' by selecting 'CloudWatch' under the 'Management & Governance' in All services
4. In the navigation pane, choose 'Log groups' under the 'Logs' section
5. Select the log group that is reported and select 'Edit retention setting(s)' under the 'Actions' drop-down
6. In 'Retention setting', for 'Expire events after', choose a log retention value either 'Never expire' or the value more than 365 days according to your business requirements
7. Choose 'Save'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudwatch-log-group' AND json.rule = retentionInDays exists and retentionInDays less than 365```
IBM Cloud ACL for VPC with overly permissive egress rule
This policy identifies IBM Cloud VPC Access Control List which are having overly permissive outbound rules allowing outgoing traffic to internet (0.0.0.0/0). ACL contains a list of security rules that allow or deny inbound or outbound network traffic based on source or destination IP address, port, and protocol. As a best practice, it is recommended to configure ACL to restrict traffic to known destination on authorised protocols and ports.
This is applicable to ibm cloud and is considered a low 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 VPC ACL 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 'Access control lists'
3. Select the Access control list reported in the alert
4. Go to 'Outbound rules' under 'Rules' tab
5. Click on three dots on the right corner of a row containing rule that has 'Destination Type' as 'Any' or 'IP or CIDR' as '0.0.0.0/0'
6. Click on 'Delete'.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-network-acl' AND json.rule = rules[?any( action equals allow and direction equals outbound and destination equals 0.0.0.0/0 )] exists```