knarayan/cloud_posture_checks huggingface dataset:
Alibaba Cloud Security group allow internet traffic to FTP-Data port (20)
This policy identifies Security groups that allow inbound traffic on FTP-Data port (20) 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 20, 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(20,20)"```
IBM Cloud Object Storage bucket is not encrypted with BYOK (bring your own key)
This policy identifies IBM Cloud Storage buckets that are not encrypted with BYOK (Bring your own key). Bring your Own Key (BYOK) allows customers to ensure no one outside their organisation has access to the root key and with the support of BYOK, customers can manage the lifecycle of their customer root keys where they can create, rotate, delete those keys. As a security best practice, it is recommended to use BYOK encryption key management system, which provides a significant level of control on the keys when used for encryption.
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: IBM Cloud object storage bucket can be encrypted with Bring your own key (BYOK) only at the time of creation. 

Please create a bucket with bring your own key encryption along with other required configuration as required using the below URL:
https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-tutorial-kp-encrypt-bucket#kp-encrypt-bucket-create

Once the new bucket is created, Please transfer existing bucket objects to the new bucket with proper encryption configured using the below URL:
https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-region-copy

To delete the alerted bucket, please follow the below instructions:
1. Log in to the IBM Cloud Console
2. Click on the 'Navigation Menu' icon and navigate to 'Resource list'. Under the 'Storage' section, select the object storage instance in which the reported bucket resides.
3. For the alerted bucket, select the 'Delete bucket' option from the kebab menu.
4. In the 'Delete Bucket' dialog, select 'Delete bucket'..

Query:
```config from cloud.resource where api.name = 'ibm-key-protect-registration' as X; config from cloud.resource where api.name = 'ibm-object-storage-bucket' AND json.rule = not( locationConstraint contains "ams03" or locationConstraint contains "mon01" or locationConstraint contains "tor01" or locationConstraint contains "sjc03" or locationConstraint contains "sjc04" or locationConstraint contains "sao01" or locationConstraint contains "mil01" or locationConstraint contains "sng01" or locationConstraint contains "che01" ) as Y; filter 'not($.X.resourceCrn equals $.Y.crn)'; show Y;```
AWS S3 access point Block public access setting disabled
This policy identifies AWS S3 access points with the block public access setting disabled.

AWS S3 Access Point simplifies managing data access by creating unique access control policies for specific applications or users within a S3 bucket. The Amazon S3 Block Public Access feature manages access at the account, bucket, and access point levels. Each level's settings can be configured independently but cannot override more restrictive settings at higher levels. Instead, access point settings complement those at the account and bucket levels.

It is recommended to enable the Block public access setting on a S3 access point unless intended for public exposure.
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: Block public access setting can be enabled at creation time only:

1. Sign in to the AWS Management Console and navigate to the Amazon S3 dashboard
2. In the left navigation pane, choose 'Access Points'
3. On the Access Points page, choose 'Create access point'
4. In the Access point name field, enter the name of the access point
5. Under 'Block Public Access settings for this Access Point', make sure to select 'Block all public access'
6. Click on 'Create access point'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3-access-point' AND json.rule = networkOrigin equal ignore case internet and (publicAccessBlockConfiguration does not exist or (publicAccessBlockConfiguration.blockPublicAcls is false and publicAccessBlockConfiguration.ignorePublicAcls is false and publicAccessBlockConfiguration.blockPublicPolicy is false and publicAccessBlockConfiguration.restrictPublicBuckets is false))```
Azure Cosmos DB key based authentication is enabled
This policy identifies Cosmos DBs that are enabled with key-based authentication. Disabling key-based metadata write access on Azure Cosmos DB prevents any changes to resources from a client connecting using the account keys. It is recommended to disable this feature for organizations who want higher degrees of control and governance for production environments.

NOTE: Enabling this feature can have an impact on your application. Make sure that you understand the impact before enabling it.

Refer for more details:
https://docs.microsoft.com/en-us/azure/cosmos-db/role-based-access-control#check-list-before-enabling
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: Refer to the following URL to disable key-based metadata write access on your Azure Cosmos DB:
https://docs.microsoft.com/en-us/azure/cosmos-db/role-based-access-control#prevent-sdk-changes.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cosmos-db' AND json.rule = properties.provisioningState equals Succeeded and properties.disableKeyBasedMetadataWriteAccess is false```
AWS CloudTrail is not enabled on the account
Checks to ensure that CloudTrail is enabled on the account. AWS CloudTrail is a service that enables governance, compliance, operational & risk auditing of the AWS account. It is a compliance and security best practice to turn on CloudTrail to get a complete audit trail of activities across various services. 
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. Login to the AWS Console and navigate to the 'CloudTrail' service.
2. Follow the instructions below to enable CloudTrail on the account.
http://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html.

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name='aws-cloudtrail-describe-trails' as X; count(X) less than 1```
GCP SQL server instance database flag 3625 (trace flag) is not set to on
This policy identifies GCP SQL server instance for which database flag 3625 (trace flag) is not set to on. Trace flag can help prevent the disclosure of sensitive information by masking the parameters of some error messages using '*', for users who are not members of the sysadmin fixed server role. It is recommended to set 3625 (trace flag) database flag for Cloud SQL SQL Server instance to on.
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 SQL Instances page
3. Click on reported SQL server instance
4. Click on EDIT
5. If the flag has not been set on the instance, 
Under 'Flags and parameters', click on 'ADD FLAG' in 'New database flag' section, choose the flag '3625' from the drop-down menu and set the value as 'On'
OR
If the flag has been set to other than on, Under 'Flags and parameters', choose the flag '3625' and set the value as 'On'
6. Click on DONE
7. Click on SAVE.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = "databaseVersion contains SQLSERVER and state equals RUNNABLE and (settings.databaseFlags[*].name does not contain 3625 or settings.databaseFlags[?any(name contains 3625 and value contains off)] exists)"```
Alibaba Cloud RAM password policy does not have a lowercase character
This policy identifies Alibaba Cloud accounts that do not have a lowercase character 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 'Required Elements in Password' field, select 'Lowercase Letters'
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 =  'requireLowercaseCharacters does not exist or requireLowercaseCharacters is false'```
AWS API Gateway Rest API attached WAFv2 WebACL is not configured with AMR for Log4j Vulnerability
This policy identifies AWS API Gateway Rest API attached with WAFv2 WebACL which are not configured with AWS Managed Rules (AMR) for Log4j Vulnerability. As per the guidelines given by AWS, API Gateway Rest API attached with WAFv2 WebACL should be configured with AWS Managed Rules (AMR) AWSManagedRulesKnownBadInputsRuleSet and AWSManagedRulesAnonymousIpList to protect from Log4j Vulnerability (CVE-2021-44228).

For more information please refer below URL,
https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
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. Sign in to the AWS console
2. Go to the API Gateway console
3. Click on the reported API Gateway REST API
4. In the Stages pane, choose the name of the stage
5. In the Stage Editor pane, choose the Settings tab
6. Note down the associated AWS WAF web ACL
7. Go to the noted WAF web ACL in AWS WAF & Shield Service
8. Under 'Rules' tab click on 'Add rules' and select 'Add managed rule groups'
9. Under 'AWS managed rule groups' enable 'Anonymous IP list' and 'Known bad inputs'
10. Click on 'Add rules'.

Query:
```config from cloud.resource where api.name = 'aws-apigateway-get-stages' AND json.rule = webAclArn is not empty as X; config from cloud.resource where api.name = 'aws-waf-v2-web-acl-resource' AND json.rule = (webACL.postProcessFirewallManagerRuleGroups.firewallManagerStatement.name does not contain AWSManagedRulesAnonymousIpList or webACL.postProcessFirewallManagerRuleGroups.firewallManagerStatement.name does not contain AWSManagedRulesKnownBadInputsRuleSet) and NOT ( webACL.rules[*].statement.managedRuleGroupStatement.name contains AWSManagedRulesAnonymousIpList and webACL.rules[*].statement.managedRuleGroupStatement.name contains AWSManagedRulesKnownBadInputsRuleSet ) as Y; filter '$.Y.webACL.arn equals $.X.webAclArn'; show X;```
AWS DMS replication task for the target database have logging not set to the minimum severity level
This policy identifies the DMS replication tasks that are logging isn't enabled or the minimum severity level is less than LOGGER_SEVERITY_DEFAULT for TARGET_APPLY and TARGET_LOAD.

Amazon DMS Logging is crucial in DMS replication for monitoring, troubleshooting, auditing, performance analysis, error detection, recovery, and historical reporting. TARGET_APPLY and TARGET_LOAD must be logged because they manage to apply data and DDL changes, as well as loading data into the target database, crucial for maintaining data integrity during migration. The absence of logging for TARGET_APPLY and TARGET_LOAD components hampers monitoring, compliance, auditing, troubleshooting, and accountability efforts during migration.

It's recommended to enable logging for AWS DMS replication tasks and set a minimal logging level of DEFAULT for TARGET_APPLY and TARGET_LOAD to ensure that informational messages, warnings, and error messages are written to the logs.
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 Target Apply and Target Load DMS replication tasks log component during migration:

1. Log in to the AWS Management Console
2. In the console, select the specific region from the region drop-down in the top right corner, for which the alert is generated
3. Navigate to 'Migration & Transfer' from the 'Services' dropdown and select 'Database Migration Service'
4. In the navigation panel, under 'Migrate data', click on 'Database migration tasks'
5. Select the reported replication task and choose 'Modify' from the 'Actions' dropdown on the right
6. Under the 'Task settings' section, enable 'Turn on CloudWatch logs' under 'Task logs'
7. Set the log component severity for both 'Target apply' and 'Target Load' components to 'Default' or greater according to your business requirements
8. Click 'Save' to save the changes.

Query:
```config from cloud.resource where api.name = 'aws-dms-replication-task' AND json.rule = ReplicationTaskSettings.Logging.EnableLogging is false or  ReplicationTaskSettings.Logging.LogComponents[?any( Id is member of ("TARGET_APPLY","TARGET_LOAD") and Severity is not member of ("LOGGER_SEVERITY_DEFAULT","LOGGER_SEVERITY_DEBUG","LOGGER_SEVERITY_DETAILED_DEBUG") )] exists```
OCI Network Load Balancer not configured with inbound rules or listeners
This policy identifies Network Load Balancers that are not configured with inbound rules or listeners.

A Network Load Balancer's subnet security lists should include ingress rules, and the Network Load Balancer should have at least one listener to handle incoming traffic. Without these configurations, the Network Load Balancer cannot receive and route incoming traffic, rendering it ineffective.

As best practice, it is recommended to configure Network Load Balancers with proper inbound rules and listeners.
This is applicable to oci cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To configure the OCI Network Load Balancers with inbound rules and listeners, refer to the following documentation:
https://docs.cloud.oracle.com/iaas/Content/Security/Reference/configuration_tasks.htm#lb-enable-traffic.

Query:
```config from cloud.resource where api.name = 'oci-networking-networkloadbalancer' and json.rule = lifecycleState equal ignore case "ACTIVE" as X; config from cloud.resource where api.name = 'oci-networking-subnet' and json.rule = lifecycleState equal ignore case "AVAILABLE" as Y; config from cloud.resource where api.name = 'oci-networking-security-list' AND json.rule = lifecycleState equal ignore case AVAILABLE as Z; filter 'not ($.X.listeners does not equal "{}" and ($.X.subnetId contains $.Y.id and $.Y.securityListIds contains $.Z.id and $.Z.ingressSecurityRules is not empty))'; show X;```
GCP SQL Server instance database flag 'contained database authentication' is enabled
This policy identifies SQL Server instance database flag 'contained database authentication' is enabled. Most of the threats associated with contained database are related to authentication process. So it is recommended to disable this flag.
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 GCP Console
2. Navigate to SQL
3. Click on SQL Server instance for which you want to disable the database flag from the list
4. Click 'Edit'
5. Go to  'Flags and Parameters'  under 'Configuration options' section
6. Search for the flag 'contained database authentication' and set the value 'off'
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = "databaseVersion contains SQLSERVER and settings.databaseFlags[?(@.name=='contained database authentication')].value equals on"```
GCP Projects have OS Login disabled
This policy identifies GCP Projects which have OS Login disabled. Enabling OS Login ensures that SSH keys used to connect to instances are mapped with IAM users. Revoking access to IAM user will revoke all the SSH keys associated with that particular user. It facilitates centralized and automated SSH key pair management which is useful in handling cases like a response to compromised SSH key pairs.
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 GCP Portal
2. Navigate to service 'Computer Engine' (Left Panel)
3. For setting project-level OS login configuration, go to the 'Metadata' section under 'Settings'(from Left Panel)
4. Click on the 'Edit' button
5. If the metadata for 'enable-oslogin' is not set, click on '+Add item' and add metadata entry key as 'enable-oslogin' and the value as 'TRUE'/'true'
6. Click on 'Save' to apply the changes
7. You need to validate if any overriding instance-level metadata is set,
8. Go to the tab 'VM instances', under section 'Virtual machines', 
9. For every instance, click on 'Edit'
10. Under Custom metadata, remove any entry with key 'enable-oslogin' and the value 'FALSE'/'false'
11. At the bottom of the 'VM instance details' page, click 'Save' to apply your changes to the instance..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-project-info' AND json.rule = 'commonInstanceMetadata.items[*].key does not contain enable-oslogin or (commonInstanceMetadata.items[?any(key contains enable-oslogin and (value contains false or value contains FALSE))] exists)'```
Azure Storage account configured with Shared Key authorization
This policy identifies Azure Storage accounts configured with Shared Key authorization.

Azure Storage accounts authorized with Shared Key authorization via Shared Access Signature (SAS) tokens pose a security risk, as they allow sharing information with external unidentified identities. It is highly recommended to disable Shared Key authorization and Use Azure AD authorization as it provides superior security and ease of use over Shared Key.

For more details:
https://learn.microsoft.com/en-us/azure/storage/common/shared-key-authorization-prevent
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: To prevent Shared Key authorization for an Azure Storage account, follow bellow URL:
https://learn.microsoft.com/en-us/azure/storage/common/shared-key-authorization-prevent.

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name= 'azure-storage-account-list' AND json.rule = properties.provisioningState equal ignore case Succeeded and properties.allowSharedKeyAccess is true```
GCP Log metric filter and alert does not exist for VPC network route delete and insert
This policy identifies GCP accounts which do not have a log metric filter and alert for VPC network route delete and insert events. Monitoring network routes deletion and insertion activities will help in identifying VPC traffic flows through an expected path. It is recommended to create a metric filter and alarm to detect activities related to the deletion and insertion of VPC network routes.
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. Sign in to GCP Console
2. Navigate to 'Logs-based metrics' under the 'Logging' section.
3. Click on 'CREATE METRIC'.
4. Provide 'Metric Type' and 'Details'.
5. In 'Filter selection', add filter as 
resource.type="gce_route" AND (protoPayload.methodName:"compute.routes.delete" OR protoPayload.methodName:"compute.routes.insert")
6. Click on 'CREATE METRIC'.
7. Under 'User-defined metrics' section, choose the metric you created in step 6 and click on the kebab menu (Vertical 3 dots) on the right side of the metrics
8. Click on 'Create alert from metric'; it will navigate to 'Create alerting policy' under the section 'Monitoring'.
9. Add the metric name created above if not auto-filled in the Monitoring filter. Choose an appropriate value for other alert condition parameters as desired. Then Click on 'NEXT'
10. Configure all alert trigger settings as desired. Then Click on 'NEXT'
11. Configure notifications as desired and provide an appropriate name for the alert policy. Then Click on 'NEXT'
12. Click on 'CREATE POLICY'..

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```