knarayan/cloud_posture_checks huggingface dataset:
AWS MSK cluster public access is enabled
This policy identifies the Amazon Managed Streaming for Apache Kafka (Amazon MSK) Cluster is configured with public access enabled.

Amazon MSK provides the capability to enable public access to the brokers of MSK clusters. When the AWS MSK Cluster is configured for public access, there is a potential risk of data being exposed to the public.

To mitigate the risk of unauthorized access and to adhere to compliance requirements, it is advisable to disable public access on the AWS MSK cluster.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Sign in to the AWS Management Console, and open the Amazon MSK console at https://console.aws.amazon.com/msk/home.
2. In the Navigation panel, select 'Clusters' under the 'MSK Clusters' section.
3. Click on the cluster that is reported.
4. Choose the 'Properties' tab.
5. In the 'Network settings' section, click on the 'Edit' dropdown.
6. Choose 'Edit public access'.
7. In the 'Edit public access' dialog, uncheck the 'Public access' checkbox to disable public access.
8. Click 'Save changes' to apply the changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-msk-cluster' AND json.rule = brokerNodeGroupInfo.connectivityInfo.publicAccess.type does not equal "DISABLED"```
API automation policy pkgmu

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

Query:
```config from cloud.resource where api.name = "aws-ec2-describe-instances" AND json.rule = architecture contains "foo"```
GCP Vertex AI Workbench Instance has Secure Boot disabled
This policy identifies GCP Vertex AI Workbench instances with Secure Boot disabled.

Secure Boot is a security feature that ensures only trusted, digitally signed software runs during the boot process, protecting against advanced threats such as rootkits and bootkits. By verifying the integrity of the bootloader and operating system, Secure Boot prevents unauthorized software from compromising the system at startup. Without Secure Boot, instances are vulnerable to persistent malware and unauthorized code that could compromise the system deeply.

It is recommended to enable Secure Boot for Vertex AI Workbench instances.
This is applicable to gcp cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Login to the GCP console
2. Navigate to the 'Vertex AI' service
3. In side panel, under 'Notebooks', go to 'Workbench'
4. Under 'INSTANCES' tab, select 'VIEW' as 'INSTANCES'
5. Click on the alerting instance
6. Under the 'SYSTEM' tab, in front of 'VM details', click on the 'View in Compute Engine' link
7. Stop the VM by clicking on the 'STOP' button. Click the 'STOP' button on the confirmation dialogue.
8. Once the the VM has been stopped, click on the 'EDIT' button
9. Under 'Shielded VM', enable 'Turn on Secure Boot'
10. Click on 'Save'
11. Click on 'START/RESUME' from the top menu.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-vertex-ai-workbench-instance' AND json.rule = state equals "ACTIVE" AND shieldedInstanceConfig.enableSecureBoot is false```
AWS RDS instance is not encrypted
This policy identifies AWS RDS instances which are not encrypted. Amazon Relational Database Service (Amazon RDS) is a web service that makes it easier to set up and manage databases. Amazon allows customers to turn on encryption for RDS which is recommended for compliance and security reasons.
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: Amazon RDS instance can only be encrypted at the time of DB instance creation. So to resolve this alert, create a new DB instance with encryption and then migrate all required DB instance data from the reported DB instance to this newly created DB instance.
To create RDS DB instance with encryption, follow the instructions mentioned in below reference link based on your Database vendor:
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name='aws-rds-describe-db-instances' AND json.rule= 'engine is not member of ("sqlserver-ex") and  dbinstanceStatus equals available and dbiResourceId does not equal null' as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' as Y; filter '$.X.storageEncrypted does not exist or $.X.storageEncrypted is false or ($.X.storageEncrypted is true and $.X.kmsKeyId exists and $.Y.keyMetadata.keyState equals Disabled and $.X.kmsKeyId equals $.Y.keyMetadata.arn)'; show X;```
AWS S3 buckets do not have server side encryption
Customers can protect the data in S3 buckets using the AWS server-side encryption. If the server-side encryption is not turned on for S3 buckets with sensitive data, in the event of a data breach, malicious users can gain access to the data.

NOTE: Do NOT enable this policy if you are using 'Server-Side Encryption with Customer-Provided Encryption Keys (SSE-C).'
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 and navigate to the 'S3' service
2. Click on the reported S3 bucket
3. Click on the 'Properties' tab
4. Under the 'Default encryption' section, choose encryption option either AES-256 or AWS-KMS based on your requirement.
For more information about Server-side encryption,
Default encryption:
https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html
Policy based encryption:
https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name= 'aws-s3api-get-bucket-acl' AND json.rule = 'policyAvailable is true and denyUnencryptedUploadsPolicies[*] is empty and sseAlgorithm equals None'```
GCP Storage bucket using a disabled CMEK
This policy identifies GCP Storage buckets that are using a disabled CMEK.

CMEK (Customer-Managed Encryption Keys) for GCP buckets allows you to use your own encryption keys to secure data stored in Google Cloud Storage. If a CMEK defined for a GCP bucket is disabled, the data in that bucket becomes inaccessible, as the encryption keys are no longer available to decrypt the data. This can lead to data loss and operational disruption. If not properly managed, CMEK can also introduce risks such as accidental key deletion or mismanagement, which could compromise data availability and security.

It is recommended to review the state of CMEK and enable it to keep the data in the bucket accessible.
This is applicable to gcp cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to GCP console
2. Navigate Cloud Storage Buckets page
3. Click on the reported bucket
4. Go to 'Configuration' tab
5. Under 'Default encryption key', click on the key name
6. Select the appropriate key version
7. Click 'ENABLE'and then click 'ENABLE' in the pop up.

Query:
```config from cloud.resource where api.name = 'gcloud-kms-crypto-keys-list' AND json.rule = primary.state does not equal "ENABLED" as X; config from cloud.resource where api.name = 'gcloud-storage-buckets-list' as Y; filter ' $.X.name equals $.Y.encryption.defaultKmsKeyName'; show Y;```
AWS Step Function state machines logging disabled
This policy identifies AWS Step Function state machines with logging disabled.

AWS Step Functions uses state machines to define and execute workflows that coordinate the components of distributed applications and microservices. Step Functions logs state machine executions to Amazon CloudWatch Logs for debugging and monitoring purposes.

It is recommended to enable logging on the Step Function state machine to maintain reliability, availability, and performance.
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 logging on the Step Function state machine, follow the below steps:

1. Log into the AWS console and navigate to the Step Function dashboard
2. On the state machine page, select the reported state machine
3. Click on 'Edit'
4. Select 'Config' to edit the configuration
5. Under the 'Config' tab, under the 'Logging' section, set 'Log level' to 'ALL'
6. Click on 'Save'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-step-functions-statemachine' AND json.rule = loggingConfiguration.level does not equal ignore case "ALL"```
AWS Connect instance not configured with contact flow logs
This policy identifies the Amazon Connect instance configured with CONTACTFLOW_LOGS set to false.

In Amazon Connect, Enabling CONTACTFLOW_LOGS in Amazon Connect is crucial as it allows real-time logging of contact flow executions to CloudWatch. This helps debug, monitor, and optimize customer interactions by tracking steps, conditions, and errors.

It is recommended to enable CONTACTFLOW_LOGS to enhance monitoring and ensure adherence to security policies and regulations.
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 logging for AWS Connect instance, perform the following actions:
1. Sign into AWS console and Open the Amazon Connect console at https://console.aws.amazon.com/connect/.
2. On the instances page, choose the instance alias that is reported.
3. In the navigation pane, choose 'Flows'.
4. Navigate to the Flow logs section and select 'Enable Flow logs' and choose 'Save'.
Note: Logs are generated only for flows that include a 'Set logging behavior block' with logging set to enabled..

Query:
```config from cloud.resource where api.name = 'aws-connect-instance' AND json.rule = InstanceStatus equals "ACTIVE" and attributes[?any( AttributeType equals "CONTACTFLOW_LOGS" and Value equals "false" )] exists```
GCP Log bucket retention policy is not configured using bucket lock
This policy identifies GCP log buckets for which retention policy is not configured using bucket lock. It is recommended to configure the data retention policy for cloud storage buckets using bucket lock to permanently prevent the policy from being reduced or removed in case the system is compromised by an attacker or a malicious insider.

Note: Locking a bucket is an irreversible action. Once you lock a bucket, you cannot remove the retention policy from the bucket or decrease the retention period for the policy.
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 set a retention policy on a bucket, please refer to the URL given below:
https://cloud.google.com/storage/docs/using-bucket-lock#set-policy

To lock a bucket, please refer to the URL given below:
https://cloud.google.com/storage/docs/using-bucket-lock#lock-bucket.

Query:
```config from cloud.resource where api.name = 'gcloud-logging-sinks-list' AND json.rule = 'destination.bucket exists' as X; config from cloud.resource where api.name = 'gcloud-storage-buckets-list' AND json.rule = (retentionPolicy.isLocked does not exist or retentionPolicy.isLocked is false) as Y; filter '($.X.destination.bucket contains $.Y.name)'; show Y;```
AWS Inactive users for more than 30 days
This policy identifies users who are inactive for more than 30 days. Inactive user accounts are an easy target for attacker because any activity on the account will largely get unnoticed.

NOTE: Exception to this policy is, it is not valid for SSO login users and Root users
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['UNUSED_PRIVILEGES'].
Mitigation of this issue can be done as follows: 1.Sign in to AWS console and navigate to IAM.
2.Identify the user reported and Make sure that the user has legitimate reason to be inactive for such an extended period.
3. Delete the user account, if the user no longer needs access to the console or no longer exists..

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name = 'aws-iam-get-credential-report' AND json.rule = 'user does not equal <root_account> and _DateTime.ageInDays(user_creation_time) > 30 and (password_last_used equals N/A or password_last_used equals no_information or _DateTime.ageInDays(password_last_used) > 30) and ((access_key_1_last_used_date equals N/A or _DateTime.ageInDays(access_key_1_last_used_date) > 30) and (access_key_2_last_used_date equals N/A or _DateTime.ageInDays(access_key_2_last_used_date) > 30))'```
harish-GCP Firewall rule allows all traffic on SMTP port (25)
This policy identifies GCP Firewall rules which allow all inbound traffic on SMTP port (25). Allowing access from arbitrary IP addresses to this port increases the attack surface of your network. It is recommended that the SMTP port (25) should be allowed to specific IP addresses.
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: If the Firewall rule reported indeed needs to restrict all traffic, follow the instructions below:
1. Login to GCP Console
2. Go to 'VPC Network'
3. Go to the 'Firewall'
4. Click on the reported Firewall rule
5. Click on 'EDIT'
6. Modify Source IP ranges to specific IP
7. Click on 'SAVE'..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name='gcloud-compute-firewall-rules-list' AND json.rule= 'sourceRanges[*] contains 0.0.0.0/0 and allowed[?any(ports contains _Port.inRange(25,25) or (ports does not exist and (IPProtocol contains tcp or IPProtocol contains udp)) )] exists'```
Azure CDN Endpoint Custom domains is not configured with HTTPS
This policy identifies Azure CDN Endpoint Custom domains which has not configured with HTTPS. Enabling HTTPS would allow sensitive data to be delivered securely via TLS/SSL encryption when it is sent across the internet. It is recommended to enable HTTPS in Azure CDN Endpoint Custom domains which will provide additional security and protects your web applications from attacks.
This is applicable to azure cloud and is considered a medium 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. Go to 'CDN profiles'
3. Choose the reported each 'CDN Endpoints' under each 'CDN profiles'
4. Under 'Settings' section, Click on 'Custom domains'
5. Select the 'Custom domain' for which you need to enable HTTPS
6. Under 'Configure' select 'On' for 'Custom domain HTTPS'
7. Select 'Certificate management type' and 'Minimum TLS version'
8. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cdn-endpoint' AND json.rule = properties.customDomains[?any( properties.customHttpsProvisioningState does not equal Enabled )] exists```
AWS Route53 Domain transfer lock is not enabled
This policy identifies the AWS Route53 domain, which is not enabled with transfer lock.

Route 53 Domain Transfer Lock is a security feature that prevents unauthorised domain transfers by locking the domain at the registrar level. The feature sets the "clientTransferProhibited" flag, which is a registry setting enabled by the registrar to force all transfer requests to be rejected automatically. If Route 53 Domain Transfer Lock is disabled, your domain is vulnerable to unauthorized transfers, which can lead to service disruptions, data breaches, reputational damage, and financial loss. 

It is recommended to enable Route 53 Domain Transfer Lock to prevent unauthorized domain transfers and protect your domain from potential security threats and disruptions.
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 lock a domain to prevent unauthorized transfer to another registrar, perform the following actions:

1. Sign in to the AWS Management Console and open the Route 53 console at https://console.aws.amazon.com/route53/.
2. In the navigation pane, choose 'Registered Domains'.
3. Choose the name of the domain that is reported.
4. On the 'Details' section, in the 'Actions' dropdown, choose 'Turn on transfer lock' to turn the transfer lock on.
5. You can navigate to the 'Requests' page to see the progress of your request..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-route53-domain' AND json.rule = statusList[*] does not contain "clientTransferProhibited"```
Alibaba Cloud Security group allow internet traffic to DNS port (53)
This policy identifies Security groups that allow inbound traffic on DNS port (53) 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 53, 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(53,53)"```
AWS VPC not in use
This policy identifies VPCs which are not in use. These VPC resources might be unintentionally launched and AWS also imposes a limit to the number of VPCs allowed per region. So it is recommended to either delete or use effectively such VPCs that do not have resources attached to them.
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 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 VPC Dashboard
4. Click on 'Your VPCs' and Choose the reported VPC
5. If you want use reported VPC, Associate subnets to VPC or If you want to delete VPC, Click on 'Actions' and Choose 'Delete VPC' from the dropdown.

Query:
```config from cloud.resource where api.name = 'aws-ec2-describe-vpcs' as X; config from cloud.resource where api.name = 'aws-ec2-describe-subnets' as Y; filter 'not $.X.vpcId equals $.Y.vpcId'; show X;```
Tamir policy

This is applicable to alibaba_cloud 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 api.name = 'alibaba-cloud-action-trail' AND json.rule = ossBucketName equals 42```
AWS Lightsail Instance does not restrict traffic on admin ports
This policy identifies the AWS Lightsail instance having network rule with unrestricted access ("0.0.0.0/0" or "::/0") on port 22 or 3389.

The firewall in Amazon Lightsail manages inbound traffic permitted to connect to your instance via its public IP address, controlling access to specific IPs and ports. Leaving administrative ports open to unrestricted access increases the risk of unauthorized access, such as brute-force attacks, which can compromise the instance and expose sensitive data.

It is recommended to limit access to specific IP addresses in the firewall rules to reduce unauthorized access attempts.
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 restrict the traffic on the AWS Lighsail instance firewall rule to known IP/CIDR range, perform the following actions:

1. Sign in to the Lightsail console https://lightsail.aws.amazon.com/.
2. In the left navigation pane, choose Instances.
3. Choose the reported instance.
4. Choose the Networking tab on your instance's management page.
5. Click on the Edit icon on the rule contains the unrestricted access ("0.0.0.0/0" or "::/0") on port 22 or 3389 under the 'IPv4 Firewall' section or 'IPv6 firewall'
6a. Click on 'Restrict to IP address' to update Source IP address to the Trusted CIDR range
or 
6b. Remove the rule which has 'Source' value as 0.0.0.0/0 or ::/0 and 'Port Range' value as 22 or 3389 or (range containing 3389 or 22) by clicking delete icon.

Note: Before making any changes, please check the impact on your applications/services..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-lightsail-instance' AND json.rule = state.name contains "running" and networking.ports[?any( accessDirection equals inbound and (cidrs contains "0.0.0.0/0" or ipv6Cidrs contains "::/0") and (((toPort == 22 or fromPort == 22) or (toPort > 22 and fromPort < 22)) or ((toPort == 3389 or fromPort == 3389) or (toPort > 3389 and fromPort < 3389))))] exists```
AWS Elasticsearch domain has Dedicated master set to disabled
This policy identifies Elasticsearch domains for which Dedicated master is disabled in your AWS account. If dedicated master nodes are provided those handle the management tasks and cluster nodes can easily manage index and search requests from different types of workload and make them more resilient in production. Dedicated master nodes improve environmental stability by freeing all the management tasks from the cluster data nodes.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. 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 Elasticsearch Service Dashboard
4. Choose reported Elasticsearch domain
5. Click on 'Edit Domain'
6. On the 'Edit domain' page,
	a. Check 'Enable dedicated master' checkbox to enable dedicated master nodes for the current cluster.
	b. Select the 'Instance type' based on your ES cluster requirements from the dropdown list.
	Note: As dedicated master nodes do not hold any data nor process any search and query requests, the instance node for this role typically does not require a large amount of CPU/RAM memory.
	c. Select the 'Number of master nodes' from dropdown list to allocate dedicated master nodes.
7. Click on 'Submit'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-es-describe-elasticsearch-domain' AND json.rule = 'processing is false and (elasticsearchClusterConfig.dedicatedMasterEnabled is false or elasticsearchClusterConfig.dedicatedMasterEnabled does not exist)'```