knarayan/cloud_posture_checks huggingface dataset:
AWS RDS instance with Multi-Availability Zone disabled
This policy identifies RDS instances which have Multi-Availability Zone(Multi-AZ) disabled. When RDS DB instance is enabled with Multi-AZ, RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different availability zone. These Multi-AZ deployments will improve primary node reachability by providing read replica in case of network connectivity loss or loss of availability in the primary’s availability zone for read/write operations, so by making them the best fit for production database workloads.
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 Amazon RDS console
4. Choose Instances, and then select the reported DB instance
5. Click on 'Modify'
6. In 'Availability & durability' section for the 'Multi-AZ Deployment', select 'Create a standby instance'
7. Click on 'Continue'
8. Under 'Scheduling of modifications' choose 'When to apply modifications'
9. On the confirmation page, Review the changes and Click on 'Modify DB Instance' to save your changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-rds-describe-db-instances' AND json.rule = dbinstanceStatus equals available and (engine does not contain aurora and engine does not contain sqlserver and engine does not contain docdb) and (multiAZ is false or multiAZ does not exist)```
GCP Kubernetes Engine Clusters have Alpha cluster feature enabled
This policy identifies GCP Kubernetes Engine Clusters which have enabled alpha cluster. It is recommended to not use alpha clusters or alpha features for production workloads. Alpha clusters expire after 30 days and do not receive security updates. This cluster will not be covered by the Kubernetes Engine SLA.
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: GCP Kubernetes Engine Clusters alpha feature cannot be disabled once it is created. So to resolve this alert, create a new cluster with the alpha feature disabled, then migrate all required cluster data from the reported cluster to this newly created cluster and delete reported Kubernetes engine cluster.

To create new Kubernetes engine cluster with the alpha feature disabled, perform the following: 
1. Login to GCP Portal
2. Go to Kubernetes Engine (Left Panel)
3. Select Kubernetes clusters 
4. Click on CREATE CLUSTER button
5. Set new cluster parameters as per your requirement and make sure 'Enable Kubernetes alpha features in this cluster' is unchecked.
6. Click on Save

To delete reported Kubernetes engine cluster, perform the following:
1. Login to GCP Portal
2. Go to Kubernetes Engine (Left Panel)
3. Select Kubernetes clusters 
4. Click on reported Kubernetes cluster
5. Click on the DELETE button
6. On 'Delete a cluster' popup dialog, Click on DELETE to confirm the deletion of the cluster..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule =  'enableKubernetesAlpha is true'```
GCP Default Firewall rule is overly permissive (except http and https)
This policy identifies the Firewall rules that are configured with default firewall rule. The default Firewall rules will apply to all instances by default in the absence of specific custom rules with higher priority. It is a safe practice to not have these rules in the default Firewall.
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 'VPC network' Under service 'NETWORKING'
3. Click on section 'Firewall' on left panel
4. For 'default' rule, apply filter 'Name : default-',
5. select all the rules which start with 'default-' (except http, https) and click on 'DELETE' icon
6. On pop-up window, click on 'DELETE'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name= 'gcloud-compute-firewall-rules-list' AND json.rule = 'disabled is false and (name equals default-allow-ssh or name equals default-allow-icmp or name equals default-allow-internal or name equals default-allow-rdp) and (deleted is false) and (sourceRanges[*] contains 0.0.0.0/0 or sourceRanges[*] contains ::/0)'```
Azure App Service Web app doesn't have a Managed Service Identity
This policy identifies Azure App Services that are not configured with managed service identity. Managed Service Identity in App Service makes the app more secure by eliminating secrets from the app, such as credentials in the connection strings. When registering with Azure Active Directory in the app service, the app will connect to other Azure services securely without the need for username and passwords.
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: To configure managed service identity on your reported App Service, follow the below URL instructions:
https://docs.microsoft.com/en-us/azure/app-service/overview-managed-identity.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = kind starts with app and (identity.type does not exist or (identity.type exists and identity.type does not contain SystemAssigned and identity.type does not contain UserAssigned))```
AWS KMS customer managed external key expiring in 30 days or less
This policy identifies KMS customer managed external keys which are expiring in 30 days or less. As a best practice, it is recommended to reimport the same key material and specifying a new expiration date. If the key material expires, AWS KMS deletes the key material and the customer managed external key becomes unusable.
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 Key Management Service (KMS) Dashboard
4. Click on Customer managed keys (Left Panel)
5. Click on reported KMS Customer managed key
6. Under 'Key material' section, Delete the existing key material before you reimport the key material by clicking on 'Delete key material'
7. Click on 'Upload key material'
8. Under 'Encrypted key material and import token' section, Reimport same encrypted key material and import token
9. Under 'Expiration option', Select 'Key material expires' and choose new expiration date in 'Key material expires at' date box
10. Click on 'Upload key material' button
NOTE: Deleting key material makes all data encrypted under the customer master key (CMK) unrecoverable unless you later import the same key material into the CMK. The CMK is not affected by this operation..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-kms-get-key-rotation-status' AND json.rule = 'keyMetadata.origin contains EXTERNAL and keyMetadata.keyManager contains CUSTOMER and keyMetadata.enabled is true and (_DateTime.ageInDays($.keyMetadata.validTo) > -30)'```
AWS RDS DB cluster is encrypted using default KMS key instead of CMK
This policy identifies RDS DB(Relational Database Service Database) clusters which are encrypted using default KMS key instead of CMK (Customer Master Key). As a security best practice CMK should be used instead of default KMS key for encryption to gain the ability to rotate the key according to your own policies, delete the key, and control access to the key via KMS policies and IAM policies.
This is applicable to aws 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: RDS DB clusters can be encrypted only while creating the database cluster. You can't convert an unencrypted DB cluster to an encrypted one. However, you can restore an unencrypted Aurora DB cluster snapshot to an encrypted Aurora DB cluster. To do this, specify a KMS encryption key when you restore from the unencrypted DB cluster snapshot.

Step 1: To create a 'Snapshot' of the unencrypted DB cluster,
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_CreateSnapshotCluster.html
NOTE: As you can't restore from a DB cluster snapshot to an existing DB cluster; a new DB cluster is created when you restore. Once the Snapshot status is 'Available'.

Step 2: Follow the below link to restoring the Cluster from a DB Cluster Snapshot,
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_RestoreFromSnapshot.html

Once the DB cluster is restored and verified, follow below steps to delete the reported DB cluster,
1. Log in to the AWS Management 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 'RDS' dashboard from 'Services' dropdown
4. In the navigation pane, choose ‘Databases’
5. In the list of DB instances, choose a writer instance for the DB cluster
6. Choose 'Actions', and then choose 'Delete'
FMI:
1. While deleting a RDS DB cluster, customer has to disable 'Enable deletion protection' otherwise instance cannot be deleted
2. While deleting RDS DB instance , AWS application will ask the end user to take Final snapshot
3. If a RDS DB cluster has a writer role instance, then User has to delete the write instance to delete the main cluster (Delete option won’t be enabled for main RDS DB cluster).

Query:
```config from cloud.resource where api.name = 'aws-rds-db-cluster' as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' as Y; filter '($.X.storageEncrypted is true) and ($.X.kmsKeyId equals $.Y.key.keyArn) and ($.Y.keyMetadata.keyManager does not contain CUSTOMER)' ; show X;```
EIP-CSE-IACOHP-AzurePostgreSQL-NetworkAccessibility-eca1500-51

This is applicable to azure 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 cloud.type = 'azure' AND api.name = 'azure-postgresql-server' AND json.rule = firewallRules.value[*].properties.startIpAddress equals "0.0.0.0" or firewallRules.value[*].properties.endIpAddress equals "0.0.0.0"```
AWS Route53 public Hosted Zone query logging is not enabled
This policy identifies the AWS Route53 public hosted zones DNS query logging is not enabled.

Enabling DNS query logging for an AWS Route 53 hosted zone enhances DNS security and compliance by providing visibility into DNS queries. When enabled, Route 53 sends these log files to Amazon CloudWatch Logs. Disabling DNS query logging for AWS Route 53 limits visibility into DNS traffic, hampering anomaly detection, compliance efforts, and effective incident response.

It is recommended to enable logging for all public hosted zones to enhance the visibility and compliance requirements.
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 configure logging for DNS queries for the Hosted zone, perform the following actions:

1. Sign in to the AWS Management Console and open the Route 53 console
2. In the navigation pane, choose 'Hosted zones'
3. Choose the hosted zone that is reported
4. In the Hosted zone details pane, choose 'Configure query logging'
5. Choose an existing log group or create a new log group from the 'Log group' section drop-down
6. Choose 'Permissions - optional' to see a table that shows whether the resource policy matches the CloudWatch log group,  and whether Route 53 has permission to publish logs to CloudWatch
7. Choose 'Create'.

Query:
```config from cloud.resource where api.name = 'aws-route53-list-hosted-zones' AND json.rule = hostedZone.config.privateZone is false as X; config from cloud.resource where api.name = 'aws-route53-query-logging-config' as Y; filter ' not ($.X.hostedZone.id equals $.Y.HostedZoneId) ' ; show X;```
GCP Firewall rule allows all traffic on DNS port (53)
This policy identifies GCP Firewall rules which allow all inbound traffic on DNS port (53). Allowing access from arbitrary IP addresses to this port increases the attack surface of your network. It is recommended that the DNS port (53) should be allowed to specific IP addresses.
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: 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 = disabled is false and direction equals INGRESS and (sourceRanges[*] equals ::0 or sourceRanges[*] equals 0.0.0.0 or sourceRanges[*] equals 0.0.0.0/0 or sourceRanges[*] equals ::/0 or sourceRanges[*] equals ::) and allowed[?any(ports contains _Port.inRange(53,53) or (ports does not exist and (IPProtocol contains tcp or IPProtocol contains udp)))] exists```
mnm test

This is applicable to aws cloud and is considered a high 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-account-management-alternate-contact' group by account as X; filter ' AlternateContactType is not member of ("SECURITY") ' ;```
AWS Private CA root certificate authority is enabled
This policy identifies enabled AWS Private CA root certificate authorities.

AWS Private CA enables creating a root CA to issue private certificates for securing internal resources like servers, applications, users, devices, and containers. The root CA should be disabled for daily tasks to minimize risk, as it should only issue certificates for intermediate CAs, allowing it to remain secure while intermediate CAs handle the issuance of end-entity certificates.

It is recommended to disable the AWS Private CA root certificate authority to secure.
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 update the status of the Private CA root certificate authority:

1. Sign in to your AWS account and open the AWS Private CA console
2. On the 'Private certificate authorities' page, choose the reported private CA
3. On the 'Actions' menu, choose 'Disable' to disable the private CA..

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name = 'aws-acm-pca-certificate-authority' AND json.rule = Type equal ignore case ROOT and Status equal ignore case active```
Alibaba Cloud MFA is disabled for RAM user
This policy identifies Resource Access Management (RAM) users for whom Multi Factor Authentication (MFA) is disabled. As a best practice, enable MFA to add an extra layer of protection for increased security of your Alibaba Cloud account settings and resources.
This is applicable to alibaba_cloud cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MFA'].
Mitigation of this issue can be done as follows: 1. Log in to Alibaba Cloud Portal
2. Go to Resource Access Management
3. In the left-side navigation pane, click 'Users'
4. Select the reported user
5. In the 'Authentication' tab, Click on 'Modify Logon Settings'
6. Choose the 'Required' radio button for 'Enable MFA' 
7. Click on 'OK'
8. Click on 'Close'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ram-user' AND json.rule = 'MFADevice is empty'```
dnd_test_create_hyperion_policy_multi_cloud_child_policies_ss_finding_2
Description-4ee38fa0-9684-4c83-b917-035b88e2e243
This is applicable to azure 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: N/A.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-active-directory-group' AND json.rule = mail contains 42```
OCI Object Storage Bucket has object Versioning disabled
This policy identifies the OCI Object Storage buckets that are not configured with a Object Versioning. It is recommended that Object Storage buckets should be configured with Object Versioning to minimize data loss because of inadvertent deletes by an authorized user or malicious deletes.
This is applicable to oci 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 OCI Console
2. Type the resource reported in the alert into the Search box at the top of the Console.
3. Click the resource reported in the alert from the Resources submenu
4. Next to Object Versioning, click Edit.
5. In the dialog box, Clink Enable Versioing (to enable)..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-object-storage-bucket' AND json.rule = versioning equals Disabled```
Azure Microsoft Defender for Cloud set to Off for Agentless scanning for machines
This policy identifies Azure Microsoft Defender for Cloud where the Agentless scanning for machines is set to Off.

Agentless scanning uses disk snapshots to detect installed software, vulnerabilities, and plain text secrets without needing agents on each machine. When disabled, your environment risks exposure to software vulnerabilities and unauthorized software, diminishing visibility into security issues. Enabling Agentless scanning improves security by identifying vulnerabilities and sensitive data with minimal performance impact, streamlining management and ensuring strong threat detection and compliance.

As a security best practice, it is recommended to enable Agentless scanning for machines in Azure Microsoft Defender for Cloud.
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. Navigate to 'Microsoft Defender for Cloud'
3. Under 'Management', select 'Environment Settings'
4. Click on the subscription name
5. Select the 'Defender plans'
6. Click on 'Settings & monitoring' at the top
7. In the table, find 'Agentless scanning for machines' and select 'On' under Plan
8. Click 'Continue' in the top left
9. Click 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = not (pricings[?any(properties.extensions[?any(name equal ignore case AgentlessVmScanning AND isEnabled is true)] exists AND properties.pricingTier equal ignore case Standard )] exists)```
Dikla test

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-sql-server-list' AND json.rule = serverAdmins does not exist or serverAdmins[*] size equals 0 or (serverAdmins[*].properties.administratorType exists and serverAdmins[*].properties.administratorType does not equal ActiveDirectory and serverAdmins[*].properties.login is not empty)```
IBM Cloud PostgreSQL Database disk encryption is not enabled with customer managed keys
This policy identifies IBM Cloud PostgreSQL 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: PostgreSQL database disk encryption can be enabled with Customer managed keys only at the time of
creation.

Please use below link to provide PostgreSQL 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 PostgreSQL deployment from backup of vulnerable PostgreSQL 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 PostgreSQL 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 PostgreSQL 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-postgresql-deployment-info' AND json.rule = deployment.platform_options.disk_encryption_key_crn is empty```
AWS EKS cluster using the default VPC
This policy identifies AWS EKS clusters which are configured with the default VPC. It is recommended to use a VPC configuration based on your security and networking requirements. You should create your own EKS VPC instead of using the default, so that you can have full control over the cluster network.
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: An AWS EKS cluster VPC cannot be changed once it is created. To resolve this alert, create a new cluster with the custom VPC as per your requirements, then migrate all required cluster data from the reported cluster to this newly created cluster and delete the reported Kubernetes cluster.

1. Open the Amazon EKS dashboard.
2. Choose Create cluster.
3. On the Create cluster page, fill in the following fields:

- Cluster name
- Kubernetes version
- Role name
- VPC - Choose your new custom VPC.
- Subnets
- Security Groups
- Endpoint private access
- Endpoint public access
- Logging

4. Choose Create..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-eks-describe-cluster' as X; config from cloud.resource where api.name = 'aws-ec2-describe-vpcs' as Y; filter ' $.X.resourcesVpcConfig.vpcId contains $.Y.vpcId and $.Y.isDefault is true'; show X;```