knarayan/cloud_posture_checks huggingface dataset:
IBM Cloud Virtual Server Image for Virtual Private Cloud (VPC) using basic Provider Managed Encryption
This policy identifies IBM Cloud Virtual Server Images for Virtual Private Cloud (VPC) which are not provisioned with Customer Managed Encryption and are using the basic Provider Managed Encryption. With customer-managed encryption, one can import own root keys to the cloud. This process is commonly called "bring your own key". When the encryption is managed by a cloud service provider, the image may still be vulnerable to unauthorized user access and manipulation. Customer-managed encryption (Key Protect & Hyper Protect Crypto Service) provides better audit records for root key usage, therefore it is recommended to use Customer Managed Encrypted Images.
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: The encryption type of the Image cannot be changed once set. If the image's encryption type is set to default (Provider Managed Encryption), Then the image must be deleted and created once again with Customer Managed Encryption
To safely delete the image which has default Provider Managed encryption, follow these steps:
1. Log in to the IBM Cloud Console
2. Click on 'Menu Icon' and navigate to 'VPC Infrastructure' and then select 'Images'
3. Select the 'Image Name' reported in the alert
4. Click on the 'Actions' dropdown
5. Click on 'Delete'.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-virtual-server-image' AND json.rule = status equals "available" and encryption equal ignore case "none"```
IBM Cloud Secrets Manager has expired arbitrary secrets
This policy identifies IBM Cloud Secrets Manager arbitrary secret which is expired. Arbitrary secrets should be rotated to ensure that data cannot be accessed with an old secret which might have been lost, cracked, or stolen. It is recommended that all arbitrary secrets are set with expiration date and expired secrets should be regularly rotated.
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: If the IBM Cloud Secrets Manager Arbitrary secret is expired, the secret needs to be deleted.
Please use below URL as reference:
https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-delete-secrets&interface=ui#delete-secret-ui

If the IBM Cloud Secrets Manager Arbitrary secret is about to be expired, the secret has to be rotated.
Please use below URL as reference:
https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manual-rotation&interface=ui#manual-rotate-arbitrary-ui

Make sure to set an expiration date for each secret.
Please follow the below steps to set an expiration date:
1. Log in to the IBM Cloud Console
2. Click on Menu Icon and navigate to 'Resource list', from the list of resources select secret manager instance in which the reported secret resides, under security section.
3. Select the secret.
4. Under 'Expiration date' section, provide expiration date as required.
6. Click on 'Update'..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-secret-manager-secret' AND json.rule = 'secret_type equals arbitrary and (expiration_date does not exist or (_DateTime.ageInDays(expiration_date) > -1))'```
pk-gcp-global

This is applicable to gcp 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 = 'gcp' AND api.name = 'gcloud-logging-bucket' AND json.rule = name contains "pk"```
AWS Config fails to deliver log files
This policy identifies AWS Configs which are failing to deliver its log files to the specified S3 bucket. It happens when it doesn't have sufficient permissions to complete the operation. To deliver information to S3 bucket, AWS Config needs to assume an IAM role that manages the permissions required to access the designated S3 bucket.
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 the AWS Config Dashboard
4. Go to 'Settings' (Left Pane)
5. In 'AWS Config role' section, 'Choose a role from your account' option and provide a unique name for new IAM role for the 'Role name' box; which does have permission to access S3 bucket.
6. Click Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-configservice-describe-configuration-recorders' AND json.rule = 'status.recording is true and status.lastStatus contains FAILURE'```
GCP VPC Network subnets have Private Google access disabled
This policy identifies GCP VPC Network subnets have disabled Private Google access. Private Google access enables virtual machine instances on a subnet to reach Google APIs and services using an internal IP address rather than an external IP address. Internal (private) IP addresses are internal to Google Cloud Platform and are not routable or reachable over the Internet. You can use Private Google access to allow VMs without Internet access to reach Google APIs, services, and properties that are accessible over HTTP/HTTPS.
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. Go to VPC network (Left Panel)
3. Select VPC networks
4. Click on the name of a reported subnet, The 'Subnet details' page will be displayed
5. Click on 'EDIT' button
6. Set 'Private Google access' to 'On'
7. Click on 'Save'

For more information, refer: https://cloud.google.com/vpc/docs/configure-private-google-access#enabling-pga.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-networks-subnets-list' AND json.rule = purpose is not member of (REGIONAL_MANAGED_PROXY, PRIVATE_SERVICE_CONNECT, GLOBAL_MANAGED_PROXY, PRIVATE_NAT) and (privateIpGoogleAccess does not exist or privateIpGoogleAccess is false)```
GCP PostgreSQL instance with log_checkpoints database flag is disabled
This policy identifies PostgreSQL instances in which log_checkpoints database flag is not set. Enabling the log_checkpoints database flag would enable logging of checkpoints and restart points to the server log.
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. Select the PostgreSQL instance for which you want to enable the database flag from the list
4. Click 'Edit'
NOTE: If the instance is stopped, You need to START instance first to edit the configurations, then Click on EDIT.
5. Go to the 'Flags' section under 'Configuration options'
6. Click 'Add item', choose the flag 'log_checkpoints' from the drop-down menu and set the value to 'on'
OR
If 'log_checkpoints' database flag is already set to 'off', from the drop-down menu set the value to 'on'
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 POSTGRES and (settings.databaseFlags[?(@.name=='log_checkpoints')] does not exist or settings.databaseFlags[?(@.name=='log_checkpoints')].value equals off)"```
AWS Log metric filter and alarm does not exist for AWS management console authentication failures
This policy identifies the AWS accounts which do not have a log metric filter and alarm for AWS management console authentication failures. Monitoring failed console logins may decrease lead time to detect an attempt to brute force a credential, which may provide an indicator, such as source IP, that can be used in other event correlation. It is recommended that a metric filter and alarm be established for failed console authentication attempts.

NOTE: This policy will trigger alert if you have at least one Cloudtrail with the multi trial is enabled, Logs all management events and is not set with specific log metric filter and alarm in your account.
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 in to AWS Console
2. Navigate to CloudWatch dashboard
3. Click on 'Log groups' in the 'Logs' section (Left panel)
4. Select the log group created for your CloudTrail trail event logs (Cloudtrail should be multi trail enabled with all Management Events captured) and click 'Create Metric Filter' button.
5. In 'Define Logs Metric Filter' page, add 'Filter pattern' value as 
{ ($.eventName = ConsoleLogin) && ($.errorMessage = "Failed authentication") }
and Click on 'Assign Metric'
6. In 'Create Metric Filter and Assign a Metric' page, Choose Filter Name, Metric Details parameter according to your requirement and click on 'Create Filter'
7. Click on 'Create Alarm',
	- In Step 1, specify metric details and conditions details as required and click on 'Next'
	- In Step 2, Select an SNS topic either by creating a new topic or use existing SNS topic/ARN and click on 'Next'
	- In Step 3, Select name and description to alarm and click on 'Next'
	- In Step 4, Preview your data entered and click on 'Create Alarm'.

Query:
```config from cloud.resource where api.name = 'aws-logs-describe-metric-filters' as X; config from cloud.resource where api.name = 'aws-cloudwatch-describe-alarms' as Y; config from cloud.resource where api.name = 'aws-cloudtrail-describe-trails' as Z; filter '(($.Z.cloudWatchLogsLogGroupArn is not empty and $.Z.cloudWatchLogsLogGroupArn contains $.X.logGroupName and $.Z.isMultiRegionTrail is true and $.Z.includeGlobalServiceEvents is true) and (($.X.filterPattern contains "eventName=" or $.X.filterPattern contains "eventName =") and ($.X.filterPattern does not contain "eventName!=" and $.X.filterPattern does not contain "eventName !=") and $.X.filterPattern contains ConsoleLogin and ($.X.filterPattern contains "errorMessage=" or $.X.filterPattern contains "errorMessage =") and ($.X.filterPattern does not contain "errorMessage!=" and $.X.filterPattern does not contain "errorMessage !=") and $.X.filterPattern contains "Failed authentication") and ($.X.metricTransformations[*] contains $.Y.metricName))'; show X; count(X) less than 1```
GCP Kubernetes cluster size contains less than 3 nodes with auto upgrade enabled
Ensure your Kubernetes cluster size contains 3 or more nodes. (Clusters smaller than 3 may experience downtime during upgrades.)

This policy checks the size of your cluster pools and alerts if there are fewer than 3 nodes in a pool.
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: Resize your cluster.

1. Visit the Google Kubernetes Engine menu in GCP Console.
2. Click the cluster's Edit button, which looks like a pencil.
3. In the Node pools section, expand the disclosure arrow for the node pool you want to change, and change the value of the Current size field to the desired value, then click Save.
4. Repeat for each node pool as needed.
5. Click Save to exit the cluster modification screen..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule =  $.nodePools[*].management.autoUpgrade is true and $.currentNodeCount less than 3```
GCP Firewall rule allows all traffic on FTP port (21)
This policy identifies GCP Firewall rules which allow all inbound traffic on FTP port (21). Allowing access from arbitrary IP addresses to this port increases the attack surface of your network. It is recommended that the FTP port (21) 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(21,21) or (ports does not exist and (IPProtocol contains tcp or IPProtocol contains udp)))] exists```
OCI Object Storage Bucket is not encrypted with a Customer Managed Key (CMK)
This policy identifies the OCI Object Storage buckets that are not encrypted with a Customer Managed Key (CMK). It is recommended that Object Storage buckets should be encrypted with a Customer Managed Key (CMK), using  Customer Managed Key (CMK), provides an additional level of security on your data by allowing you to manage your own encryption key lifecycle management for the bucket.
This is applicable to oci 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: 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 Assign next to Encryption Key: Oracle managed key.
5. Select a Vault from the appropriate compartment
6. Select a Master Encryption Key
7. Click Assign.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-object-storage-bucket' AND json.rule = kmsKeyId is member of ("null")```
Alibaba Cloud Security group allow internet traffic to HTTP port (80)
This policy identifies Security groups that allow inbound traffic on HTTP port (80) 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 80, 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(80,80)"```
AWS ElastiCache Redis cluster with encryption for data at rest disabled
This policy identifies ElastiCache Redis clusters which have encryption for data at rest(at-rest) is disabled. It is highly recommended to implement at-rest encryption in order to prevent unauthorized users from reading sensitive data saved to persistent media available on 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 at-rest encryption can be set only at the time of the creation of the cluster. So to fix this alert, create a new cluster with at-rest encryption, 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 at-rest 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 at-rest' 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 = 'atRestEncryptionEnabled is false or atRestEncryptionEnabled does not exist'```
OCI users API keys have aged more than 90 days without being rotated
This policy identifies all of your IAM API keys which have not been rotated in the past 90 days. It is recommended to verify that they are rotated on a regular basis in order to protect OCI API access directly or via SDKs or OCI CLI.
This is applicable to oci cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['KEYS_AND_SECRETS'].
Mitigation of this issue can be done as follows: 1. Login to the OCI Console Page: https://console.ap-mumbai-1.oraclecloud.com/
2. Select Identity from the Services menu.
3. Select Users from the Identity menu.
4. Click on an individual user under the Name heading.
5. Click on API Keys in the lower left hand corner of the page.
6. Delete any API Keys with a date of 90 days or older under the Created column of the API Key table.

Note : The console URL is region specific, your tenancy might have a different home region and thus console URL..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-iam-user' AND json.rule = '(_DateTime.ageInDays(apiKeys[*].timeCreated) > 90)'```
Azure Activity log alert for Update security policy does not exist
This policy identifies the Azure accounts in which activity log alert for Update security policy does not exist. Creating an activity log alert for Update security policy gives insight into changes to security policy and may reduce the time it takes to detect suspicious activity.
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 Azure Portal
2. Click on Monitor (Left Panel)
3. Select 'Alerts'
4. Click on Create > Alert rule
5. In 'Create an alert rule' page, choose the Scope as your Subscription and under the CONDITION section, choose 'Update security policy (Microsoft.Security/policies)' and Other fields you can set based on your custom settings.
6. Click on Create.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-activity-log-alerts' AND json.rule = "location equal ignore case Global and properties.enabled equals true and properties.scopes[*] does not contain resourceGroups and properties.condition.allOf[?(@.field=='operationName')].equals equals Microsoft.Security/policies/write" as X; count(X) less than 1```
IBM Cloud Service ID with IAM policies provide administrative privileges for all Identity and Access enabled services
This policy identifies IBM Cloud Service ID, which has administrator role permission across 'All Identity and Access enabled services'. Service IDs with administrator permission on 'All Identity and Access enabled services' can access all services or resources in the account. If a Service ID with administrator privileges becomes compromised, it may result in compromised resources in the account. As a security best practice, granting the least privilege access, such as granting only the permissions required to perform a task instead of providing excessive permissions, is recommended.
This is applicable to ibm cloud and is considered a medium 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 'Service IDs' in the left panel.
3. Select the Service ID that is reported and that you want to edit access for.
4. Under the 'Access' tab, go to the 'Access policies' section > Click on three dots on the right corner of a row for the policy, which has administrator permission on 'All Identity and Access enabled services' 
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(tags does not exist and attributes[?any( value equal ignore case "service" and name equal ignore case "serviceType" and operator is member of ("stringEquals", "stringMatch"))] exists and attributes[?any( name equal ignore case "region")] 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.iam_id'; show Y;```