knarayan/cloud_posture_checks huggingface dataset:
test again - delete it

This is applicable to azure cloud and is considered a low 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 = 'azure' AND api.name = 'azure-key-vault-list' AND json.rule = properties.provisioningState equals Succeeded and diagnosticSettings.value[*].properties.workspaceId does not equal ignore case "/subscriptions/8dff688e-d9b0-477c-b2b0-b0e729fb06bd/resourceGroups/rg-analytics-sh-prd-scus/providers/Microsoft.OperationalInsights/workspaces/log-sh-workspace"```
GCP Composer environment web server network access control allows access from all IP addresses
This policy identifies GCP Composer environments with web server network access control that allows access from all IP addresses.

Web server network access control defines which IP addresses will have access to the Airflow web server. By default, web server network access control is set to allow all connections from the public internet. Allowing all traffic to the composer environment may allow a bad actor to brute force their way into the system and potentially get access to the entire network.

As a best practice, restrict traffic solely from known IP addresses and limit access to known hosts, services, or specific entities only.
This is applicable to gcp 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: To configure web server network access of an existing Cloud Composer 1 and Cloud Composer 2 environments, follow the steps given below:
1. Login to the GCP console
2. Navigate to the 'Composer' service (Left Panel)
3. Click on the alerting composer environment
4. Click on the 'ENVIRONMENT CONFIGURATION' tab
5. Under 'Network configuration', click on the 'EDIT' button for the 'Web server access control' setting
6. Select 'Allow access only from specific IP addresses'
7. Add the desired IPs and IP ranges to be allowed.
8. Click the 'Save' button.

To configure web server network access of a new Cloud Composer 1 environment, please refer to the URLs given below:
https://cloud.google.com/composer/docs/how-to/managing/creating#web-server-access

To configure web server network access of a new Cloud Composer 2 environment, please refer to the URLs given below:
https://cloud.google.com/composer/docs/composer-2/create-environments#web-server-access

Note: Cloud Composer 1 is nearing the end of support. The creation of new Cloud Composer 1 environments might be restricted. Further, updates to the existing Cloud Composer 1 environment may be restricted. In such cases, it is recommended to migrate to Cloud Composer 2. To migrate to Cloud Composer 2, please refer to the URLs given below and configure web server network access to limit the access for the new environment:
https://cloud.google.com/composer/docs/migrate-composer-2-snapshots-af-2.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-composer-environment' AND json.rule = state equals "RUNNING" and config.webServerNetworkAccessControl.allowedIpRanges[?any( value equals "0.0.0.0/0" or value equals "::0/0" )] exists ```
Copy 2 of Bobby Copy of AWS Access logging not enabled on S3 buckets
Checks for S3 buckets without access logging turned on. Access logging allows customers to view complete audit trail on sensitive workloads such as S3 buckets. It is recommended that Access logging is turned on for all S3 buckets to meet audit & compliance requirement
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: 1. Login to the AWS Console and navigate to the 'S3' service.
2. Click on the the S3 bucket that was reported.
3. Click on the 'Properties' tab.
4. Under the 'Server access logging' section, select 'Enable logging' option..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name='aws-s3api-get-bucket-acl' AND json.rule='loggingConfiguration.targetBucket equals null or loggingConfiguration.targetPrefix equals null'```
llatorre - RoleAssigment v5

This is applicable to azure 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 = 'azure' AND api.name = 'azure-role-assignment' AND json.rule = '((_DateTime.ageInDays($.properties.updatedOn) < 60) and (properties.principalType contains User))'```
GCP Kubernetes cluster intra-node visibility disabled
With Intranode Visibility, all network traffic in your cluster is seen by the Google Cloud Platform network. This means you can see flow logs for all traffic between Pods, including traffic between Pods on the same node. And you can create firewall rules that apply to all traffic between Pods.

This policy checks your cluster's intra-node visibility feature and generates an alert if it's disabled.
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: Upgrade your cluster to use Intranode Visibility.

1. Visit the Google Kubernetes Engine menu in GCP Console.
2. Click the cluster's Edit button, which looks like a pencil.
3. Select Enabled under Intranode visibility.
4. Click Save to modify the cluster..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule =  $.networkConfig.enableIntraNodeVisibility does not exist or $.networkConfig.enableIntraNodeVisibility is false```
AWS Neptune DB clusters have backup retention period less than 7 days
This policy identifies Amazon Neptune DB clusters lacking sufficient backup retention tenure.

AWS Neptune DB is a fully managed graph database service. The backup retention period denotes the duration for storing automated backups of the Neptune DB clusters. Inadequate retention periods heighten the risk of data loss, and compliance issues, and hinder effective recovery in security breaches or system failures.

It is recommended to ensure a backup retention period of at least 7 days or according to your business and compliance requirements.
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 modify an Amazon Neptune DB cluster's backup retention period, perform the following actions:

1. Sign in to the AWS Management Console
2. Select the region from the dropdown in the top right corner where the alert is generated
3. In the Navigation Panel on the left, under 'Database', select 'Neptune'
4. Under ‘Databases', select 'Clusters' and choose the reported cluster name
5. Click 'Modify' from the top right corner 
6. Under the 'Additional settings' section, Click the 'Show more' dropdown 
7. Select the desired backup retention period in days from the 'Backup retention period' drop-down menu based on your business or compliance requirements 
8. Click 'Next' to review the summary of your changes 
9. Choose either 'Apply during the next scheduled maintenance window' or 'Apply immediately' based on your scheduling preference
10. Click on 'Submit' to implement the changes.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-neptune-db-cluster' AND json.rule = Status equals "available" and (BackupRetentionPeriod does not exist or BackupRetentionPeriod less than 7)```
Alibaba Cloud Security group allow internet traffic to RDP port (3389)
This policy identifies Security groups that allow inbound traffic on RDP port (3389) 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 3389, 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(3389,3389)"```
AWS Certificate Manager (ACM) has invalid or failed certificate
This policy identifies certificates in ACM which are either in Invalid or Failed state. If the ACM certificate is not validated within 72 hours, it becomes Invalid. An ACM certificate fails when,
- the certificate is requested for invalid public domains
- the certificate is requested for domains which are not allowed
- missing contact information
- typographical errors
In such cases (Invalid or Failed certificate), you will have to request for a new certificate. It is strongly recommended to delete the certificates which are in failed or invalid state.
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 delete Certificates: 
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. Go to Certificate Manager(ACM) service
4. Choose the reported certificate
5. Under 'Actions' drop-down click on 'Delete'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-acm-describe-certificate' AND json.rule = 'status contains VALIDATION_TIMED_OUT or status contains FAILED'```
GCP Kubernetes Engine Clusters without any label information
This policy identifies all Kubernetes Engine Clusters which do not have labels. Having a cluster label helps you identify and categorize Kubernetes clusters.
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. Login to GCP Portal
2. Go to Kubernetes Engine (Left Panel)
3. Select Kubernetes clusters 
4. From the list of clusters, choose the reported cluster
5. Click on 'SHOW INFO PANEL' button
6. Click on 'Add Label'
7. Specify customized data for Key and Value
8. Click on Save.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = 'resourceLabels does not exist or resourceLabels.[*] is empty'```
Azure SQL database auditing is disabled
This policy identifies SQL databases in which auditing is set to Off.  Database events are tracked by the Auditing feature and the events are written to an audit log in your Audit log destinations. This process helps you to monitor database activity, and get insight into anomalies that could indicate business concerns or suspected security violations.
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: If server auditing is enabled, it always applies to the database. The database will be audited, regardless of the database auditing settings. It is recommended that you enable only server-level auditing and leave the database-level auditing disabled for all databases.

To enable auditing at server level:
1. Log in to the Azure Portal
2. Note down the reported SQL database and SQL server
3. Select 'SQL servers', Click on the SQL server instance you wanted to modify
4. Select 'Auditing' under 'Security' section, and set the status to 'On' and choose any Audit log destinations.
5.  Click on 'Save'

It is recommended to avoid enabling both server auditing and database blob auditing together, unless:
If you want to use a different storage account, retention period or Log Analytics Workspace for a specific database or want to use for audit event types or categories for a specific database that differ from the rest of the databases on the server.
To enable auditing at database level:
1. Log in to the Azure Portal
2. Note down the reported SQL database
3. Select 'SQL databases', Click on the SQL database instance you wanted to modify
4. Select 'Auditing' under 'Security' section, and set the status to 'On' and choose any Audit log destinations.
5.  Click on 'Save'.

Query:
```config from cloud.resource where api.name = 'azure-sql-db-list' AND json.rule = blobAuditPolicy.properties.state equals Disabled or blobAuditPolicy does not exist or blobAuditPolicy is empty as X; config from cloud.resource where api.name = 'azure-sql-server-list' AND json.rule = serverBlobAuditingPolicy.properties.state equals Disabled or serverBlobAuditingPolicy does not exist or serverBlobAuditingPolicy is empty as Y; filter '$.X.blobAuditPolicy.id contains $.Y.sqlServer.name'; show X;```
ECS Cluster CloudWatch Logs Encryption Disabled
This policy alerts you when an AWS ECS cluster is configured with CloudWatch logs encryption disabled, potentially exposing sensitive information. By enforcing encryption on CloudWatch logs, you can enhance the security of your data and maintain compliance with regulatory requirements. Ensure that you enable encryption for CloudWatch logs to protect your ECS cluster from unauthorized access and safeguard your critical information.
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 api.name = 'aws-ecs-cluster' and json.rule = configuration.executeCommandConfiguration.logConfiguration.cloudWatchEncryptionEnabled exists and configuration.executeCommandConfiguration.logConfiguration.cloudWatchEncryptionEnabled is false```
EMR Cluster Termination Protection Enforcement
This policy alerts you when an AWS Elastic MapReduce (EMR) cluster is configured without termination protection, which could potentially expose your cluster to accidental terminations or unauthorized changes. By enabling termination protection, you can safeguard your EMR clusters against unintended shutdowns and ensure the continuity of your data processing tasks, thereby enhancing the overall security and reliability of your cloud environment.
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 api.name = 'aws-emr-describe-cluster' and json.rule = terminationProtected exists and terminationProtected is false```
IBM Cloud user with IAM policies provide administrative privileges for Secrets Manager service
This policy identifies IBM Cloud users with administrator role permission for the Secrets Manager service. Users with admin access will be able to perform all platform tasks for Secrets Manager, including the creation, modification, and deletion of Secrets Manager service instances, as well as the assignment of access policies to other users. On Secret Manager, there is a chance that sensitive data might be exposed in the underlying service if a user with administrative rights is compromised. As a security best practice, it is recommended to grant the least privilege access, such as granting only the permissions required to perform a task, instead of providing excessive permissions.
This is applicable to ibm cloud and is considered a low severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. Log in to the IBM Cloud console.
2. In the IBM Cloud console, click 'Manage' on the title bar > 'Access (IAM)', click on 'Users' in the left panel.
3. Select the user which is reported and you want to edit access for.
4. Go to 'Access' tab and under the 'Access policies' section> Click on three dots on the right corner of a row for the policy which is having Administrator permission on 'Secrets Manager' service.
5. Click on Remove OR Edit to assign limited permission to the policy.
6. Review the policy details that you're about to Edit/Remove, and confirm by clicking Save/Remove..

Query:
```config from cloud.resource where api.name = 'ibm-iam-policy' AND json.rule = type equal ignore case "access" and roles[?any( role_id contains "crn:v1:bluemix:public:iam::::role:Administrator" )] exists and resources[?any( attributes[?any( name equal ignore case "serviceName" and value equal ignore case "secrets-manager" and operator is member of ("stringEquals", "stringMatch"))] exists and attributes[?any( name is member of ("region","resource","resourceGroupId","resourceType","serviceInstance"))] does not exist )] exists and subjects[?any( attributes[?any( name contains "iam_id" and value contains "IBMid")] exists )] exists as X;config from cloud.resource where api.name = 'ibm-iam-user' as Y; filter '$.X.subjects[*].attributes[*].value contains $.Y.iam_id'; show Y;```
AWS Security Group allows all ingress traffic on CIFS port (445)
This policy identifies AWS Security groups that allow all traffic on port 445 used by Common Internet File System (CIFS).

Common Internet File System (CIFS) is a network file-sharing protocol that allows systems to share files over a network. unrestricted CIFS access can expose your data to unauthorized users, leading to potential security risks. 

It is recommended to restrict CIFS port 445 access to only trusted networks to prevent unauthorized access and data breaches.
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 restrict the traffic on the security group to known IP/CIDR range, perform the following actions:

1. Log in to the AWS Console
2. Navigate to the 'VPC' service
3. On the left-hand panel, click on 'Security Groups' under the 'Security' section 
4. Select the 'Security Group' that is reported.
4. Click on the 'Edit Inbound Rule'.
5. in the 'Edit inbound rules' window, remove or restric the CIDR to trusted IP on the rule which has 'Source' value as 0.0.0.0/0 or ::/0 and 'Port Range' value as 445 (or range containing 445)
6. Click 'Save rules' to save.

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-ec2-describe-security-groups' AND json.rule = isShared is false and (ipPermissions[?any((ipRanges[*] contains 0.0.0.0/0 or ipv6Ranges[*].cidrIpv6 contains ::/0) and ((toPort == 445 or fromPort == 445) or (toPort > 445 and fromPort < 445)))] exists)```
IBM Cloud MySQL Database disk encryption is not enabled with customer managed keys
This policy identifies IBM Cloud MySQL Databases with default disk encryption. Using customer managed keys will increase significant control where keys are managed by customers. It is recommended to use customer managed keys for disk encryption which provides customer control over the lifecycle of the keys.
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: MySQL database disk encryption can be enabled with Customer managed keys only at the time of
creation.

Please use below link to provide MySQL service to KMS service authorization if not authorized already;
https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-key-protect&interface=ui#granting-service-auth

Please use below link to provision a KMS instance with a key to use for encryption if not provisioned:
https://cloud.ibm.com/docs/key-protect?topic=key-protect-getting-started-tutorial#create-keys

Please follow below steps to create a new MySQL deployment from backup of vulnerable MySQL deployment:
1. Log in to the IBM Cloud Console
2. Click on 'Menu Icon' and navigate to 'Resource list', from the list of resources select MySQL database reported in the alert.
3. In the left navigation pane, navigate to 'Backups and restore', under 'Available Backups' section click on 'Create backup' to get latest backup of the database.
4. Under 'Available Backups' tab, click on three dots on the right corner of a row containing latest backup and click on 'Restore backup'.
5. On create a new Database for MySQL from backup page, select all the configuration as per the requirement.
6. Under 'Encryption' section, under 'KMS Instance' please select a KMS instance and a key from the instance to use for encryption.
7. Click on 'Restore backup'.

Please follow below steps to delete the reported database deployment :
1. Log in to the IBM Cloud Console
2. Click on 'Menu Icon' and navigate to 'Resource list'.
3. Select your deployment. Next, by using the stacked three-dot menu icon , choose Delete from the drop list..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-mysql-deployment-info' AND json.rule = deployment.platform_options.disk_encryption_key_crn is empty```
Azure disk is unattached and is encrypted with the default encryption key instead of ADE/CMK
This policy identifies the disks which are unattached and are encrypted with default encryption instead of ADE/CMK. Azure encrypts disks by default Server-Side Encryption (SSE) with platform-managed keys [SSE with PMK]. It is recommended to use either SSE with Azure Disk Encryption [SSE with PMK+ADE] or Customer Managed Key [SSE with CMK] which improves on platform-managed keys by giving you control of the encryption keys to meet your compliance need.
This is applicable to azure cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: If data stored in the disk is no longer useful, refer to Azure documentation to delete unattached data disks at:
API: https://docs.microsoft.com/en-us/rest/api/compute/disks/delete
CLI: https://docs.microsoft.com/en-us/cli/azure/disk?view=azure-cli-latest#az-disk-delete

If data stored in the disk is important, To enable SSE with Azure Disk Encryption [SSE with PMK+ADE] disk needs to be attached to VM.
Follow https://docs.microsoft.com/en-us/azure/security/azure-security-disk-encryption-prerequisites based VM the data disk is assigned. Once encryption is done, Un-attach the disk form the VM using azure portal / CLI.

To enable SSE with Customer Managed Key [SSE with CMK],
Follow https://docs.microsoft.com/en-us/azure/virtual-machines/disks-enable-customer-managed-keys-portal?toc=/azure/virtual-machines/linux/toc.json&bc=/azure/virtual-machines/linux/breadcrumb/toc.json#enable-on-an-existing-disk.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-disk-list' AND json.rule = '(managedBy does not exist or managedBy is empty) and (encryptionSettings does not exist or encryptionSettings.enabled is false) and encryption.type is not member of ("EncryptionAtRestWithCustomerKey", "EncryptionAtRestWithPlatformAndCustomerKeys")'```