knarayan/cloud_posture_checks huggingface dataset:
GCP User managed service account keys are not rotated for 90 days
This policy identifies user-managed service account keys which are not rotated from last 90 days or more. Rotating Service Account keys will reduce the window of opportunity for an access key that is associated with a compromised or terminated account to be used. Service Account keys should be rotated to ensure that data cannot be accessed with an old key which might have been lost, cracked, or stolen. It is recommended that all user-managed service account keys are regularly rotated.
This is applicable to gcp cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['KEYS_AND_SECRETS'].
Mitigation of this issue can be done as follows: To fix this alert, delete the old key which is older than 90 or more days, and Create a new key for that particular service account.To Delete user-managed Service Account Key older than 90 days:

1. Login to GCP Portal
2. Go to APIs & Services (Left Panel)
3. Select 'Credentials' and Under section 'Service Accounts',  select the service account for which we need to delete the key
4. On the page 'Service account details' select the tab 'KEYS'
5. Click on the delete icon for the listed key after confirming the creation date is older than 90

To Create a new user-managed Service Account Key for a Service Account:
1. Login to GCP Portal
2. Go to APIs & Services (Left Panel)
3. Select 'Credentials' and Under the section 'Service Accounts',  select the service account for which we need a key
4. On the page 'Service account details' select the tab 'KEYS'
5. Under 'ADD KEY' dropdown, select 'Create new key'
6. Select desired key type format among JSON or P12
7. Click on CREATE button, It will download the private key. Keep it safe.
8. Click on CLOSE if promptedIt will redirect to the APIs & Services Credentials page. Make a note of the New ID displayed in the section Service account keys with the new creation date.

NOTE: Rotating the service account key might break communication for depending applications. Dependent applications need to configure manually with a new key id..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-iam-service-accounts-keys-list' AND json.rule = 'disabled is false and name contains iam.gserviceaccount.com and (_DateTime.ageInDays($.validAfterTime) > 90) and keyType equals USER_MANAGED'```
IBM Cloud Service ID with IAM policies provide administrative privileges for Cloud Monitoring Service
This policy identifies IBM Cloud Service ID, which has policy with administrator role permission for IBM Cloud Monitoring service. When a Service ID having a policy with admin rights gets compromised, the whole service gets compromised. As a security best practice, it is recommended to grant the least privileged 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)', and click on 'Service IDs' in the left panel.
3. Select the Service ID which is reported and you want to edit access for.
4. Under the 'Access' tab, go to the 'Access policies' section, and click on the three dots on the right corner of a row for the policy which is having Administrator permission on 'IBM Cloud Monitoring' 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 "sysdig-monitor" and operator is member of ("stringEquals", "stringMatch"))] exists and attributes[?any( name is member of ("region","resource","resourceGroupId","resourceType","serviceInstance","sysdigTeam"))] does not exist )] exists and subjects[?any( attributes[?any( name contains "iam_id" and value contains "iam-ServiceId")] exists )] exists as X;config from cloud.resource where api.name = 'ibm-iam-service-id' as Y; filter '$.X.subjects[*].attributes[*].value contains $.Y.id'; show Y;```
AWS S3 bucket policy overly permissive to any principal
This policy identifies the S3 buckets that have a bucket policy overly permissive to any principal and do not have Block public and cross-account access to buckets and objects through any public bucket or access point policies enabled. It is recommended to follow the principle of least privileges ensuring that the only restricted entities have permission on S3 operations instead of any anonymous.
For more details: https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-bucket-user-policy-specifying-principal-intro.html
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: 1. Log in to the AWS console
2. Navigate to the S3 dashboard
3. Choose the reported S3 bucket
4. In the 'Permissions' tab, click on the 'Bucket Policy'
5. Update the S3 bucket policy, by removing Principal conatining wildcard(*) to specific accounts, Services or IAM entities. Also restrict S3 action operations to specific instead of using wildcard (*).
6. In the 'Permissions' tab, click on the 'Block public access' and enable 'Block public and cross-account access to buckets and objects through any public bucket or access point policies'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name='aws-s3api-get-bucket-acl' AND json.rule = ( ( publicAccessBlockConfiguration.restrictPublicBuckets is false and accountLevelPublicAccessBlockConfiguration does not exist ) or ( publicAccessBlockConfiguration does not exist and accountLevelPublicAccessBlockConfiguration.restrictPublicBuckets is false ) or ( publicAccessBlockConfiguration.restrictPublicBuckets is false and accountLevelPublicAccessBlockConfiguration.restrictPublicBuckets is false ) or ( publicAccessBlockConfiguration does not exist and accountLevelPublicAccessBlockConfiguration does not exist ) )AND policy.Statement[?any(Effect equals Allow and Action anyStartWith s3: and (Principal.AWS contains * or Principal equals *) and (Condition does not exist or Condition[*] is empty) )] exists```
OCI Kubernetes Engine Cluster boot volume is not configured with in-transit data encryption
This policy identifies Kubernetes Engine Clusters that are not configured with in-transit data encryption. Configuring In-transit encryption on clusters boot volumes, encrypts data in transit between the instance, the boot volume, and the block volumes. All the data moving between the instance and the block volume is transferred over an internal and highly secure network. It is recommended that Clusters boot volumes should be configured with in-transit data encryption to minimize risk for sensitive data being leaked. 

For more details:
https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/overview.htm#BlockVolumeEncryption
This is applicable to oci 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. Log in to OCI console
2. Go to Developer Services -> Kubernetes Clusters (OKE)
3. Click on the Kubernetes Clusters you wanted to modify
4. Click on 'Node pools'
5. Click on the reported node pool
6. On the 'Node pool details' page, click on the 'Edit' button.
7. On the 'Edit node pool' dialog; under 'Boot volume' section, select 'Use in-transit encryption' option
8. Click on the 'Save Changes' button..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-containers-artifacts-kubernetes-cluster-nodepool' AND json.rule = lifecycleState equal ignore case ACTIVE and (nodeConfigDetails.isPvEncryptionInTransitEnabled equal ignore case "null" or nodeConfigDetails.isPvEncryptionInTransitEnabled does not exist)```
GCP public-facing (external) global load balancer using HTTP protocol
This policy identifies GCP public-facing (external) global load balancers that are using HTTP protocol.

Using the HTTP protocol with a GCP external load balancer transmits data in plaintext, making it vulnerable to eavesdropping, interception, and modification by malicious actors. This lack of encryption exposes sensitive information, increases the risk of man-in-the-middle attacks, and compromises the overall security and privacy of the data exchanged between clients and servers.

It is recommended to use HTTPS protocol with external-facing load balancers.
This is applicable to gcp 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. Login to the GCP console
2. Navigate to 'Network Service' and then 'Load Balancing'
3. Click on the 'FRONTENDS' tab
4. Identify the frontend that is using the reported forwarding rule.
5. Click on the load balancer name associated with the frontend identified above
6. Click 'Edit'
7. Go to 'Frontend configuration'
8. Delete the frontend rule that allows HTTP protocol.
9. Add new frontend rule(s) as required. Make sure to use HTTPS protocol instead of HTTP for new rules.
10. Click 'Update'
11. Click 'UPDATE LOAD BALANCER' in the pop-up..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-global-forwarding-rule' AND json.rule = globalForwardingRules[?any( target contains "/targetHttpProxies/" and loadBalancingScheme contains "EXTERNAL" )] exists```
dnd_test_create_hyperion_policy_ss_update_child_policy_finding_2
Description-30540d9e-e2ce-4d22-a7df-a5b42c08f155
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = defaultRootObject is empty```
eai_test_policy_demo
EAI Demo policy
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-cloudfront-list-distributions' AND json.rule = arn contains "E2PTZRGF0OBZQJ" and tags[*].key contains "test"```
Azure Key Vault Key has no expiration date (Non-RBAC Key vault)
This policy identifies Azure Key Vault keys that do not have an expiration date for the Non-RBAC Key vaults. As a best practice, set an expiration date for each key and rotate your keys regularly.

Before you activate this policy, ensure that you have added the Prisma Cloud Service Principal to each Key Vault: https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin/connect-your-cloud-platform-to-prisma-cloud/onboard-your-azure-account/azure-onboarding-checklist

Alternatively, run the following command on the Azure cloud shell:
az keyvault list | jq '.[].name' | xargs -I {} az keyvault set-policy --name {} --certificate-permissions list listissuers --key-permissions list --secret-permissions list --spn <prismacloud_app_id>
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. Select 'All services' > 'Key vaults'
3. Select the Key vault where the key is stored
4. Select 'Keys', and select the key that you need to modify
5. Select the current version
6. Set the expiration date
7. 'Save' your changes.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-key-vault-list' and json.rule = keys[?any(attributes.exp equals -1 and attributes.enabled contains true)] exists and properties.enableRbacAuthorization is false```
Azure MariaDB database server not using latest TLS version
This policy identifies Azure MariaDB database servers that are not using the latest TLS version for SSL enforcement. Azure Database for MariaDB uses Transport Layer Security (TLS) from communication with client applications. As a best security practice, use the newer TLS version as the minimum TLS version for the MariaDB database server. Currently, Azure MariaDB supports TLS 1.2 version which resolves the security gap from its preceding versions.
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 configure SSL connection with latest TLS version on an existing Azure Database for MariaDB, follow the below URL:
https://docs.microsoft.com/en-us/azure/mariadb/howto-tls-configurations

NOTE: Once you enforce a minimum TLS version, you cannot later disable minimum version enforcement..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-database-maria-db-server' AND json.rule = properties.userVisibleState equals Ready and properties.sslEnforcement equals Enabled and properties.minimalTlsVersion does not equal TLS1_2```
Azure Batch account is not configured with managed identity
This policy identifies Batch accounts that are not configured with managed identity. Managed identity can be used to authenticate to any service that supports Azure AD authentication, without having credentials in your code. Storing credentials in a code increases the threat surface in case of exploitation and also managed identities eliminate the need for developers to manage credentials. So as a security best practice, it is recommended to have the managed identity to your Batch account.
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. Login to Azure portal.
2. Navigate to 'Batch accounts'
3. Click on the reported Batch account
4. Select 'Identity' under 'Settings' from left panel 
5. Configure either 'System assigned' or 'User assigned' identity
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-batch-account' AND json.rule = properties.provisioningState equal ignore case Succeeded and identity does not exist or identity.type equal ignore case "None"```
GCP Firewall rule allows all traffic on PostgreSQL port (5432)
This policy identifies GCP Firewall rules which allow all inbound traffic on PostgreSQL port (5432). Allowing access from arbitrary IP addresses to this port increases the attack surface of your network. It is recommended that the PostgreSQL port (5432) 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(5432,5432) or (ports does not exist and (IPProtocol contains tcp or IPProtocol contains udp)))] exists```
Alibaba Cloud RAM password policy configured to allow login after the password expires
This policy identifies Alibaba Cloud accounts that are configured to allow login after the password has expired. As a best practice, denying login after the password expires allows you to ensure that RAM users reset their password before they can access 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 'Action After Password Expires' field, select 'Deny Logon' radio button
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 =  'hardExpiry is false'```
AWS ElastiCache Redis cluster with in-transit encryption disabled (Replication group)
This policy identifies ElastiCache Redis clusters that are replication groups and have in-transit encryption disabled. It is highly recommended to implement in-transit encryption in order to protect data from unauthorized access as it travels through the network, between clients and cache servers. Enabling data encryption in-transit helps prevent unauthorized users from reading sensitive data between your Redis clusters and their associated cache storage systems.
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: AWS ElastiCache Redis cluster in-transit encryption can be set, only at the time of creation of the cluster. So to resolve this alert, create a new cluster with in-transit encryption enabled, then migrate all required ElastiCache Redis cluster data from the reported ElastiCache Redis cluster to this newly created cluster and delete reported ElastiCache Redis cluster.

To create new ElastiCache Redis cluster with In-transit encryption set, perform the following:
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 ElastiCache Dashboard
4. Click on Redis
5. Click on 'Create' button
6. On the 'Create your Amazon ElastiCache cluster' page,
a. Select 'Redis' cache engine type.
b. Enter a name for the new cache cluster
c. Select Redis engine version from 'Engine version compatibility' dropdown list.
Note: As of July 2018, In-transit encryption can be enabled only for AWS ElastiCache clusters with Redis engine version 3.2.6 and 4.0.10.
d. Click on 'Advanced Redis settings' to expand the cluster advanced settings panel
e. Select 'Encryption in-transit' checkbox to enable encryption along with other necessary parameters
7. Click on 'Create' button to launch your new ElastiCache Redis cluster

To delete reported ElastiCache Redis cluster, perform the following:
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 ElastiCache Dashboard
4. Click on Redis
5. Select reported Redis cluster
6. Click on 'Delete' button
7. In the 'Delete Cluster' dialog box, if you want a backup for your cluster select 'Yes' from the 'Create final backup' dropdown menu, provide a name for the cluster backup, then click on 'Delete'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elasticache-describe-replication-groups' AND json.rule = 'transitEncryptionEnabled is false or transitEncryptionEnabled does not exist'```
OCI VCN has no inbound security list
This policy identifies the OCI Virtual Cloud Networks (VCN) that lack ingress rules configured in their security lists. It is recommended that Virtual Cloud Networks (VCN) security lists are configured with ingress rules which provide stateful and stateless firewall capability to control network access to your instances.
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. Click on Ingress rules
5. Click on Add Ingress Rules (To add ingress rules appropriately in the pop up)
6. Click on Add Ingress Rules.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-networking-security-list' AND json.rule = ingressSecurityRules[*] size equals 0```
AWS ElastiCache Redis cluster encryption not configured with CMK key
This policy identifies ElastiCache Redis clusters that are encrypted using the default KMS key instead of Customer Managed CMK (Customer Master Key) or CMK key used for encryption is disabled. As a security best practice enabled CMK should be used instead of the 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.

For details:
https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/at-rest-encryption.html#using-customer-managed-keys-for-elasticache-security
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: To encrypt your ElastiCache Redis cluster with CMK follow below mentioned URL:
https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/at-rest-encryption.html#at-reset-encryption-enable-existing-cluster.

Query:
```config from cloud.resource where api.name = 'aws-elasticache-describe-replication-groups' AND json.rule = status equals available and atRestEncryptionEnabled is true as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' as Y; filter '($.X.kmsKeyId does not exist) or ($.X.kmsKeyId exists and $.Y.keyMetadata.keyState equals Disabled) and $.X.kmsKeyId equals $.Y.keyMetadata.arn'; show X;```
Azure virtual network peer is disconnected
Virtual network peering enables you to connect two Azure virtual networks so that the resources in these networks are directly connected.

This policy identifies Azure virtual network peers that are disconnected. Typically, the disconnection happens when a peering configuration is deleted on one virtual network, and the other virtual network reports the peering status as disconnected.
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 reconnect the virtual network peers, you need to delete the 'Disconnected' peering connection and re-configure the peering connection.

To re-configure the peering connection:
1. Log in to the Azure Portal.
2. Select 'Virtual Networks', and select the virtual network on which has 'Disconnected' peering.
3. Select 'Peerings'.
4. Delete the peering with 'Disconnected' status.
5. Select 'Add' to re-initiate the peering configuration.
6. Specify the 'Name' and target 'Virtual Network'.
7. Select 'OK'
8. Verify that peering state is 'Initiated'.
9. Repeat step 5-7 on the target/other vnet.
10. Verify that the peering state is 'Connected'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-network-vnet-list'  AND json.rule = ['properties.virtualNetworkPeerings'][*].['properties.peeringState'] equals "Disconnected"```