knarayan/cloud_posture_checks huggingface dataset:
IBM Cloud API key creation is not restricted in account settings
This policy identifies IBM cloud accounts where API key creation is not restricted in account settings. By default, all members of an account can create API keys. Enabling API key creation will restrict the users from creating API keys unless correct access is granted explicitly. It is recommended to enable API key creation setting and grant access only on a need basis. 
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: Follow the below mentioned URL to enable the API key creation setting:

https://cloud.ibm.com/docs/account?topic=account-allow-api-create&interface=ui#allow-all-api-create.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-iam-identity-account-setting' AND json.rule = restrict_create_platform_apikey does not equal "RESTRICTED"```
GCP User managed service accounts have user managed service account keys
This policy identifies user managed service accounts that use user managed service account keys instead of Google-managed. For user-managed keys, the User has to take ownership of key management activities. Even after owner precaution, keys can be easily leaked by common development malpractices like checking keys into the source code or leaving them in downloads directory or accidentally leaving them on support blogs/channels. So It is recommended to limit the use of User-managed service account keys and instead use Google-managed keys which cannot be downloaded.

Note: This policy might alert the service accounts which are not created using Terraform for cloud account onboarding. These alerts are valid as no user-managed service account should be used for cloud account onboarding.
This is applicable to gcp 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: Follow the below mentioned URL to delete user managed service account keys:

https://cloud.google.com/iam/docs/creating-managing-service-account-keys#deleting.

Query:
```config from cloud.resource where api.name = 'gcloud-iam-service-accounts-keys-list' as X; config from cloud.resource where api.name = 'gcloud-iam-service-accounts-list' as Y; filter '($.X.name does not contain prisma-cloud and $.X.name contains iam.gserviceaccount.com and $.X.name contains $.Y.email and $.X.keyType contains USER_MANAGED)' ; show X;```
AWS ElastiCache cluster not associated with VPC
This policy identifies ElastiCache Clusters which are not associated with VPC. It is highly recommended to associate ElastiCache with VPC, as provides virtual network in your own logically isolated area and features such as selecting IP address range, creating subnets, and configuring route tables, network gateways, and security settings.

NOTE: If you created your AWS account before 2013-12-04, you might have support for the EC2-Classic platform in some regions. AWS has deprecated the use of Amazon EC2-Classic for launching ElastiCache clusters. All current generation nodes are launched in Amazon Virtual Private Cloud only. So this policy only applies legacy ElastiCache clusters which are created using EC2-Classic.
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: AWS ElastiCache cluster VPC association can be done only at the time of the creation of the cluster. So to fix this alert, create a new cluster with VPC, then migrate all required ElastiCache cluster data from the reported ElastiCache cluster to this newly created cluster and delete reported ElastiCache cluster.

To create new ElastiCache 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 or Memcached based on your requirement
5. Choose cluster parameters as per your requirement
6. Click on 'Advanced Redis settings' to expand the cluster advanced settings panel
7. Select desired VPC for 'Subnet group' along with other parameters
NOTE: If you don't specify a subnet when you launch a cluster, the cluster launches into your default Amazon VPC.
8. Click on 'Create' button to launch your new ElastiCache cluster

To delete reported ElastiCache 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. Select reported cluster
5. Click on 'Delete' button
6. 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 api.name = 'aws-elasticache-cache-clusters' as X; config from cloud.resource where api.name = 'aws-elasticache-describe-replication-groups' as Y; filter '$.Y.memberClusters contains $.X.cacheClusterId and $.X.cacheClusterStatus equals available and ($.X.cacheSubnetGroupName is empty or $.X.cacheSubnetGroupName does not exist)'; show Y;```
Azure Key Vault Firewall is not enabled
This policy identifies Azure Key Vault which has Firewall disabled. Enabling Azure Key Vault Firewall feature prevents unauthorised traffic from reaching your key vault. It is recommend to enable Azure Key Vault Firewall which provides additional layer of protection for your secrets.
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: 1. Log in to Azure portal
2. Navigate to 'Key vaults', and select the reported key vault from the list
3. Under 'Settings' select 'Networking'
4. In order to "Allow public access from specific virtual networks and IP addresses", Click on 'Allow public access from specific virtual networks and IP addresses' Under 'Firewalls and virtual networks'. Add 'IPv4 address or CIDR'.
5. In order to disable public access, Click on 'Disable public access'.
6. Click on 'Save'..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-key-vault-list' AND json.rule = (properties.publicNetworkAccess does not equal ignore case disabled and properties.networkAcls does not exist) or (properties.publicNetworkAccess does not equal ignore case disabled and properties.networkAcls.defaultAction equal ignore case allow ) ```
GCP Cloud Run service revision is using default service account with editor role
This policy identifies GCP Cloud Run service revisions that are utilizing the default service account with the editor role. 

GCP Compute Engine Default service account is automatically created upon enabling the Compute Engine API. This service account is granted the IAM basic Editor role by default, unless explicitly disabled. Assigning default service account with the editor role to cloud run revisions could lead to privilege escalation. Granting minimal access rights helps in promoting a better security posture.

Following the principle of least privileges, it is recommended to avoid assigning default service account with the editor role to cloud run revision.
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: Changing a service account of an existing cloud run service revision is impossible. The service revision can be deleted and a new revision with appropriate permissions can be deployed.

To delete a cloud run service revision that is serving traffic, please refer to the steps below:
1. Login to the GCP console
2. Navigate to the 'Cloud Run' service
3. Click on the cloud run service on whose revision, alert is generated
4. Go to the 'REVISIONS' tab
5. Click on 'MANAGE TRAFFIC'
6. Click on the delete icon in front of the alerting revision. Adjust traffic distribution appropriately.
7. Click on 'Save'
8. Under the 'REVISIONS' tab, click the actions button (three dots) in front of the alerting revision.
9. Click 'Delete'
10. Click 'DELETE'

To delete a cloud run service revision that is not serving any traffic, please refer to the steps below:
1. Login to the GCP console
2. Navigate to the 'Cloud Run' service
3. Click on the cloud run service on whose revision, alert is generated
4. Go to the 'REVISIONS' tab
5. Under the 'REVISIONS' tab, click the actions button (three dots) in front of the alerting revision.
6. Click 'Delete'
7. Click 'DELETE'.

Query:
```config from cloud.resource where api.name = 'gcloud-projects-get-iam-user' AND json.rule = user contains "compute@developer.gserviceaccount.com" and roles[*] contains "roles/editor" as X; config from cloud.resource where api.name = 'gcloud-cloud-run-revisions-list' AND json.rule = spec.serviceAccountName contains "compute@developer.gserviceaccount.com" as Y; filter ' $.X.user equals $.Y.spec.serviceAccountName '; show Y;```
pkodoth - AWS S3 bucket not configured with secure data transport policy
This policy identifies S3 buckets which are not configured with secure data transport policy. AWS S3 buckets should enforce encryption of data over the network using Secure Sockets Layer (SSL). It is recommended to add a bucket policy that explicitly denies (Effect: Deny) all access (Action: s3:*) from anybody who browses (Principal: *) to Amazon S3 objects within an Amazon S3 bucket if they are not accessed through HTTPS (aws:SecureTransport: false).
This is applicable to aws 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. Sign into the AWS console
2. Navigate to Amazon S3 Dashboard
3. Click on 'Buckets' (Left Panel)
4. Choose the reported S3 bucket
5. On 'Permissions' tab, Click on 'Bucket Policy'
6. Add a bucket policy that explicitly denies (Effect: Deny) all access (Action: s3:) from anybody who browses (Principal: ) to Amazon S3 objects within an Amazon S3 bucket if they are not accessed through HTTPS (aws:SecureTransport: false). Below is the sample policy:
{
	"Sid": "ForceSSLOnlyAccess",
	"Effect": "Deny",
	"Principal": "*",
	"Action": "s3:GetObject",
	"Resource": "arn:aws:s3:::bucket_name/*",
	"Condition": {
			"Bool": {
			"aws:SecureTransport": "false"
		}
	}
}.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = "(((((acl.grants[?(@.grantee=='AllUsers')] size > 0) or policyStatus.isPublic is true) and publicAccessBlockConfiguration does not exist) or ((acl.grants[?(@.grantee=='AllUsers')] size > 0) and publicAccessBlockConfiguration.ignorePublicAcls is false) or (policyStatus.isPublic is true and publicAccessBlockConfiguration.restrictPublicBuckets is false)) and websiteConfiguration does not exist) and ((policy.Statement[*].Condition.Bool.aws:SecureTransport does not exist) or ((policy.Statement[?(@.Principal=='*' || @.Principal.AWS=='*')].Action contains s3: or policy.Statement[?(@.Principal=='*' || @.Principal.AWS=='*')].Action[*] contains s3:) and (policy.Statement[?(@.Principal=='*' && @.Effect=='Allow')].Condition.Bool.aws:SecureTransport contains false or policy.Statement[?(@.Principal.AWS=='*' && @.Effect=='Allow')].Condition.Bool.aws:SecureTransport contains false or policy.Statement[?(@.Principal=='*' && @.Effect=='Allow')].Condition.Bool.aws:SecureTransport contains FALSE or policy.Statement[?(@.Principal.AWS=='*' && @.Effect=='Allow')].Condition.Bool.aws:SecureTransport contains FALSE or policy.Statement[?(@.Principal=='*' && @.Effect=='Deny')].Condition.Bool.aws:SecureTransport contains true or policy.Statement[?(@.Principal.AWS=='*' && @.Effect=='Deny')].Condition.Bool.aws:SecureTransport contains true or policy.Statement[?(@.Principal=='*' && @.Effect=='Deny')].Condition.Bool.aws:SecureTransport contains TRUE or policy.Statement[?(@.Principal.AWS=='*' && @.Effect=='Deny')].Condition.Bool.aws:SecureTransport contains TRUE)))"```
GCP Vertex AI Workbench Instance is using default service account with the editor role
This policy identifies GCP Vertex AI Workbench Instances that are using the default service account with the Editor role.

The Compute Engine default service account is automatically created with an autogenerated name and email address when you enable the Compute Engine API. By default, this service account is granted the IAM basic Editor role unless you explicitly disable this behavior. If this service account is assigned to a Vertex AI Workbench instance, it may lead to potential privilege escalation.

In line with the principle of least privilege, it is recommended that Vertex AI Workbench Instances are not assigned the 'Compute Engine default service account', particularly when the Editor role is granted to the service account.
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: 1. Login to the GCP console
2. Navigate to the 'Vertex AI' service
3. In side panel, under 'Notebooks', go to 'Workbench'
4. Under 'INSTANCES' tab, select 'VIEW' as 'INSTANCES'
5. Click on the alerting instance
6. Under the 'SYSTEM' tab, in front of 'VM details', click on the 'View in Compute Engine' link
7. Stop the VM by clicking on the 'STOP' button. Click the 'STOP' button on the confirmation dialogue.
8. Once the the VM has been stopped, click on the 'EDIT' button
9. Under 'Identity and API access', use the dropdown to select a non-default service account as per needs
10. Click on 'Save'
11. Click on 'START/RESUME' from the top menu.

Query:
```config from cloud.resource where api.name = 'gcloud-vertex-ai-workbench-instance' AND json.rule = state equals "ACTIVE" and gceSetup.serviceAccounts[*].email contains "compute@developer.gserviceaccount.com" as X; config from cloud.resource where api.name = 'gcloud-projects-get-iam-user' AND json.rule = user contains "compute@developer.gserviceaccount.com" and roles[*] contains "roles/editor" as Y; filter ' $.X.gceSetup.serviceAccounts[*].email equals $.Y.user'; show X;```
Azure AKS cluster Azure CNI networking not enabled
Azure CNI provides the following features over kubenet networking:

- Every pod in the cluster is assigned an IP address in the virtual network. The pods can directly communicate with other pods in the cluster, and other nodes in the virtual network.
- Pods in a subnet that have service endpoints enabled can securely connect to Azure services, such as Azure Storage and SQL DB.
- You can create user-defined routes (UDR) to route traffic from pods to a Network Virtual Appliance.
- Support for Network Policies securing communication between pods.

This policy checks your AKS cluster for the Azure CNI network plugin and generates an alert if not found.
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 create a new AKS cluster with the Azure CNI network plugin enabled, follow the below URL:
https://learn.microsoft.com/en-us/azure/aks/configure-azure-cni.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-kubernetes-cluster' AND json.rule =  properties.networkProfile.networkPlugin does not contain azure```
IBM Cloud Key Protect root key have aged more than 90 days without being rotated
This policy identifies IBM Cloud Key Protect root keys that have aged more than 90 days without being rotated. It is a procedure that adheres to security best practices to rotate keys on a regular basis. So that if the keys are compromised, the data in the underlying service is still secure with the new 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: 1. Log in to the IBM Cloud console.
2. Click on Menu Icon and navigate to 'Resource list', From the list of resources, select your provisioned instance of Key Protect in which the reported root key resides.
3. Select the key and click on three dots on the right corner of the row to open the list of options for the key that you want to rotate.
4. Click on 'Rotate'.
5. In the 'Rotation' window, click on 'Rotate Key' 
6. In order to set the rotation policy, Under 'Manage rotation policy', enable 'Rotation policy' checkbox and select the day intervals for the key rotation as per the requirement.
7. Click on 'Set policy' button to establish this policy..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-key-protect-key' AND json.rule = 'extractable is false and state equals 1 and ((lastRotateDate does not exist and _DateTime.ageInDays(creationDate) > 90 ) or _DateTime.ageInDays(lastRotateDate) > 90)'```
GCP Storage log buckets have object versioning disabled
This policy identifies Storage log buckets which have object versioning disabled. Enabling object versioning on storage log buckets will protect your cloud storage data from being overwritten or accidentally deleted. It is recommended to enable object versioning feature on all storage buckets where sinks are configured.
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: Follow the below mentioned URL to enable object versioning on a bucket:

https://cloud.google.com/storage/docs/using-object-versioning#set.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-storage-buckets-list' AND json.rule = '(acl[*].email exists and acl[*].email contains logging) and (versioning.enabled is false or versioning does not exist)'```
AWS ElastiCache Redis with in-transit encryption disabled (Non-replication group)
This policy identifies ElastiCache Redis that are in non-replication groups or individual ElastiCache Redis 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 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 in-transit encryption can be set, only at the time of creation. 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-cache-clusters' AND json.rule = engine equals redis and transitEncryptionEnabled is false and replicationGroupId does not exist```
bboiko test 02 - policy

This is applicable to gcp 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 = 'gcp' AND api.name = 'gcloud-iam-service-accounts-keys-list' AND json.rule = 'name contains iam.gserviceaccount.com and (_DateTime.ageInDays($.validAfterTime) > -1) and keyType equals USER_MANAGED'```
Azure MySQL database flexible server SSL enforcement is disabled
This policy identifies Azure MySQL database flexible servers for which the SSL enforcement is disabled. SSL connectivity helps to provide a new layer of security, by connecting database server to client applications using Secure Sockets Layer (SSL). Enforcing SSL connections between database server and client applications helps protect against 'man in the middle' attacks by encrypting the data stream between the server and application.
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 enable MySQL database flexible server SSL connection, refer below URL:
https://docs.microsoft.com/en-us/azure/mysql/flexible-server/how-to-connect-tls-ssl.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-mysql-flexible-server' AND json.rule = properties.state equal ignore case "Ready" and require_secure_transport.value equal ignore case "OFF"```
GCP SQL instance configured with overly permissive authorized networks
This policy identifies GCP Cloud SQL instances that are configured with overly permissive authorized networks. You can connect to the SQL instance securely by using the Cloud SQL Proxy or adding your client's public address as an authorized network. If your client application is connecting directly to a Cloud SQL instance on its public IP address, you have to add your client's external address as an Authorized network for securing the connection. It is recommended to add specific IPs instead of public IPs as authorized networks as per the requirement.

Reference: https://cloud.google.com/sql/docs/mysql/authorize-networks
This is applicable to gcp cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Login to GCP Portal
2. Navigate to the 'Instances' page on section 'SQL'(Left Panel)
3. Click on the alerted instance name 
4. Select the 'Connections' tab on the left panel
5. Inspect for the networks added as Authorized Networks
6. If any public IP is set for 'Authorized networks', review and delete the network by clicking the delete icon on the network
7. Click on 'DONE'.
8. Click on 'SAVE'..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = settings.ipConfiguration.authorizedNetworks[?any(value contains 0.0.0.0/0 or value contains ::/0)] exists```