knarayan/cloud_posture_checks huggingface dataset:
IBM Cloud user with IAM policies provide administrative privileges for Kubernetes Service
This policy identifies IBM Cloud users with overly permissive Kubernetes Administrative role. When a user having policy with admin rights gets compromised, the whole service gets compromised. As a security best practice, it is recommended to grant the least privilege access, such as granting only the permissions required to perform a task, instead of providing excessive permissions.
This is applicable to ibm cloud and is considered a low severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. Log in to the IBM Cloud console.
2. In the IBM Cloud console, click 'Manage' on the title bar > 'Access (IAM)', click on 'Users' in the left panel.
3. Select the user which is reported and you want to edit access for.
4. Go to 'Access' tab and under the 'Access policies' section, click on three dots on the right corner of a row for the policy which is having Administrator permission on 'Kubernetes 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 "containers-kubernetes" and operator is member of ("stringEquals", "stringMatch"))] exists and attributes[?any( name is member of ("region","resource","resourceGroupId","resourceType","serviceInstance","namespace"))] does not exist )] exists and subjects[?any( attributes[?any( name contains "iam_id" and value contains "IBMid")] exists )] exists as X;config from cloud.resource where api.name = 'ibm-iam-user' as Y; filter '$.X.subjects[*].attributes[*].value contains $.Y.iam_id'; show Y;```
GCP Storage buckets are publicly accessible to all authenticated users
This policy identifies the buckets which are publicly accessible to all authenticated users. Enabling public access to Storage Buckets enables anybody with a web association to access sensitive information that is critical to business. Access over a whole bucket is controlled by IAM. Access to individual objects within the bucket is controlled by its ACLs.
This is applicable to gcp 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. Login to GCP Portal
2. Go to Storage (Left Panel)
3. Click Browse
4. Choose the identified Storage bucket whose ACL needs to be modified
5. Click on SHOW INFO PANEL button
6. Check all the ACL groups and make sure that the none of them are set to 'allAuthenticatedUsers'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-storage-buckets-list' AND json.rule = 'iam.bindings[*] size greater than 0 and iam.bindings[*].members[*] any equal allAuthenticatedUsers'```
IBM Cloud Virtual Private Cloud (VPC) classic access is enabled
This policy identifies IBM Virtual Private Cloud where access to classic resources are enabled. If the classic access is enabled one can access & communicate IBM Cloud classic infrastructure & network from the VPC. Classic access should be disabled initially.
This is applicable to ibm cloud and is considered a high severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: Refer to https://cloud.ibm.com/docs/vpc?topic=vpc-deleting-vpc-resources&interface=ui to safely delete the affected VPC. Note- A VPC must be set up for classic access when it is created & it cannot be updated to add or remove classic access..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc' AND json.rule = classic_access is true```
Azure Virtual network not protected by DDoS Protection Standard
This policy identifies Virtual networks not protected by DDoS Protection Standard. Distributed denial of service (DDoS) attacks are some of the largest availability and security concerns exhausting an application's resources, making the application unavailable to legitimate users. Azure DDoS Protection Standard provides enhanced DDoS mitigation features to defend against DDoS attacks. 
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. Go to Virtual networks dashboard 
3. Click on the reported Virtual network
4. Under the 'Settings', click on 'DDoS protection'
NOTE: Before enabling DDoS Protection, If already no DDoS protection plan exist you need to configure one DDoS protection plan for your organization by following below URL instructions:
https://docs.microsoft.com/en-us/azure/ddos-protection/manage-ddos-protection#create-a-ddos-protection-plan
5. Select 'Enable' for 'DDoS Protection Standard' and choose 'DDoS protection plan' from dropdown or enter DDoS protection plan resource ID.
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-network-vnet-list' AND json.rule = ['properties.provisioningState'] equals Succeeded and (['properties.ddosProtectionPlan'].['id'] does not exist or ['properties.enableDdosProtection'] is false)```
AWS ElastiCache Redis cluster automatic version upgrade disabled
This policy identifies the ElastiCache Redis clusters that do not have the auto minor version upgrade feature enabled.

An ElastiCache Redis cluster is a fully managed in-memory data store used to cache frequently accessed data, reducing latency and improving application performance. Failure to enable automatic minor upgrades can leave your cache clusters vulnerable to security risks stemming from outdated software.

It is recommended to enable automatic minor version upgrades on ElastiCache Redis clusters to receive timely patches and updates, reduce the risk of security vulnerabilities, and improve overall performance and stability.
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. Navigate to the ElastiCache Dashboard
2. Click on 'Redis caches' under the 'Resources' section
3. Select the reported Redis cluster
4. Click on the 'Modify' button
5. In the 'Modify' page, under the 'Maintenance' section
6. Find the 'Auto upgrade minor versions' setting and click on 'Enable'
7. Click on 'Preview changes'. Under 'Apply immediately', select 'Yes'
8. Click on 'Modify'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elasticache-cache-clusters' AND json.rule = engine contains redis and autoMinorVersionUpgrade is false```
AWS AppSync has field-level logging disabled
This policy identifies an AWS AppSync GraphQL API not configured with field-level logging with either 'ERROR' or 'ALL'.

AWS AppSync is a managed GraphQL service that simplifies the development of scalable APIs. Field-level logging in AWS AppSync lets you capture detailed logs for specific fields in your GraphQL API. Without enabling field-level logging, the security monitoring and debugging capabilities may be compromised, increasing the risk of undetected threats and vulnerabilities.

It is recommended to enable field-level logging to ensure granular visibility into API requests, aiding in security, and compliance with regulatory requirements.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To turn on field-level logging on an AWS AppSync GraphQL API,

1. Sign in to the AWS Management Console.
2. In the console, select the specific region from the region drop-down on the top right corner, for which the alert is generated
3. In the navigation pane, choose 'AWS AppSync' under the 'Front-end Web & Mobile' section.
4. On the APIs page, choose the name of a reported GraphQL API.
5. On your API's homepage, in the navigation pane, choose Settings.
6. Under Logging, Turn on Enable Logs.
7. Under Field resolver log level, choose your preferred field-level logging level Error or All according to your business requirements.
8. Under Create or use an existing role, choose New role to create a new AWS Identity and Access Management (IAM) that allows AWS AppSync to write logs to CloudWatch. Or, choose the Existing role to select the Amazon Resource Name (ARN) of an existing IAM role in your AWS account.
9. Choose Save..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-appsync-graphql-api' AND json.rule = logConfig.fieldLogLevel is not member of ('ERROR','ALL')```
AWS CloudFront attached WAFv2 WebACL is not configured with AMR for Log4j Vulnerability
This policy identifies AWS CloudFront attached with WAFv2 WebACL which is not configured with AWS Managed Rules (AMR) for Log4j Vulnerability. As per the guidelines given by AWS, CloudFront attached with WAFv2 WebACL should be configured with AWS Managed Rules (AMR) AWSManagedRulesKnownBadInputsRuleSet and AWSManagedRulesAnonymousIpList to protect from Log4j Vulnerability (CVE-2021-44228).

For more information please refer below URL,
https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
This is applicable to aws 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. Sign in to the AWS console
2. Go to the CloudFront Distributions Dashboard
3. Click on the reported web distribution
4. On 'General' tab, Click on 'Edit' button under 'Settings'
5. Note down the associated AWS WAF web ACL
6. Go to the noted WAF web ACL in AWS WAF & Shield Service
7. Under 'Rules' tab click on 'Add rules' and select 'Add managed rule groups'
8. Under 'AWS managed rule groups' enable 'Anonymous IP list' and 'Known bad inputs'
9. Click on 'Add rules'.

Query:
```config from cloud.resource where api.name = 'aws-cloudfront-list-distributions' AND json.rule = webACLId is not empty as X; config from cloud.resource where api.name = 'aws-waf-v2-global-web-acl-resource' AND json.rule =(webACL.postProcessFirewallManagerRuleGroups.firewallManagerStatement.name does not contain AWSManagedRulesAnonymousIpList or webACL.postProcessFirewallManagerRuleGroups.firewallManagerStatement.name does not contain AWSManagedRulesKnownBadInputsRuleSet) and NOT ( webACL.rules[*].statement.managedRuleGroupStatement.name contains AWSManagedRulesAnonymousIpList and webACL.rules[*].statement.managedRuleGroupStatement.name contains AWSManagedRulesKnownBadInputsRuleSet ) as Y; filter '$.Y.webACL.arn equals $.X.webACLId'; show X;```
Naveed
instance-with-default-security-group
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where cloud.type = 'aws' AND cloud.service = 'Amazon EC2' AND api.name = 'aws-ec2-describe-instances' AND json.rule = securityGroups[*].groupName equals "default" as X; config from cloud.resource where api.name = 'aws-ec2-describe-security-groups' AND json.rule = groupName equals "default" as Y; filter '$.X.securityGroups[*].groupId equals $.Y.groupId';show Y;```
GCP Cloud Run service is publicly accessible
This policy identifies GCP Cloud Run services that are publicly accessible. Granting Cloud Run Invoker permission to 'allUsers' or 'allAuthenticatedUsers' allows anyone to access the Cloud Run service over internet. Such access might not be desirable if sensitive data is stored at the location. As security best practice it is recommended to remove public access and assign the least privileges to the GCP Cloud Run service according to requirements.

Note: For public API/website Cloud Run service will permit 'Cloud Run Invoker' to 'allUsers'. 

Refer to the following link for common use cases of authentication to the Cloud Run service.
Link: https://cloud.google.com/run/docs/authenticating/overview 
This is applicable to gcp 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: It is recommended to review and add appropriate, but restrictive roles before revoking access.

To revoke access from 'allusers'/'allAuthenticatedUsers', refer to the following URL:
https://cloud.google.com/run/docs/securing/managing-access#remove-principals.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-cloud-run-services-list' AND json.rule = status.conditions[?any(type equals Ready and status equals True)] exists and status.conditions[?any(type equals RoutesReady and status equals True)] exists and iamPolicy.bindings[?any(role equals roles/run.invoker and members is member of (allUsers, allAuthenticatedUsers))] exists```
AWS S3 Buckets with Object-level logging for write events not enabled

This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where api.name= 'aws-cloudtrail-describe-trails' AND json.rule = 'isMultiRegionTrail is true and includeGlobalServiceEvents is true' as X; config from cloud.resource where api.name= 'aws-cloudtrail-get-trail-status' AND json.rule = 'status.isLogging equals true' as Y; config from cloud.resource where api.name= 'aws-cloudtrail-get-event-selectors' AND json.rule = eventSelectors[?any( dataResources[?any( type contains "AWS::S3::Object" and values contains "arn:aws:s3")] exists and readWriteType is member of ("All","Writeonly") and includeManagementEvents is true)] exists as Z; filter '($.X.trailARN equals $.Z.trailARN) and ($.X.name equals $.Y.trail)'; show X; count(X) less than 1```
GCP PostgreSQL instance database flag log_duration is not set to on
This policy identifies PostgreSQL database instances in which database flag log_duration is not set to on. Enabling the log_duration setting causes the duration of each completed statement to be logged. Monitoring the time taken to execute the queries can be crucial in identifying any resource-hogging queries and assessing the performance of the server. Further steps such as load balancing and the use of optimized queries can be taken to ensure the performance and stability of the server. It is recommended to set log_duration as on.
This is applicable to gcp cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to GCP console
2. Navigate SQL Instances page
3. Click on reported PostgreSQL instance
4. Click EDIT
5. If the flag has not been set on the instance, 
Under 'Customize your instance', click on 'ADD FLAG' in 'Flags' section, choose the flag 'log_duration' from the drop-down menu and set the value as 'on'
OR
If the flag has been set to other than on, Under 'Customize your instance', In 'Flags' section choose the flag 'log_duration' and set the value as 'on'
6. Click on 'DONE' and then 'SAVE'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = "state equals RUNNABLE and databaseVersion contains POSTGRES and (settings.databaseFlags[*].name does not contain log_duration or settings.databaseFlags[?any(name contains log_duration and value contains off)] exists)"```
IBM Cloud Kubernetes secrets data is not encrypted with bring your own key
This policy identifies IBM Cloud kubernetes clusters for which secrets data have encryption using key protect disabled. Kubernetes Secret data is encoded in the base64 format and stored as plain text in etcd. Etcd is a key-value store used as a backing store for Kubernetes cluster state and configuration data. Storing Secrets as plain text in etcd is risky, as they can be easily compromised by attackers and used to access systems. It is recommended that secrets data is encrypted for better security.
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 your IBM Cloud console.
2. To view the list of services that are available on IBM Cloud, click 'Catalog'.
3. From the 'All Categories' navigation pane, click the 'Security' category.
4. From the list of services, click the Key Protect tile.
5. Select a service plan, and click Create to provision an instance of Key Protect in the
account, region, and resource group where you are logged in.
6. To view a list of your resources, go to 'Menu > Resource List'.
7. From your IBM Cloud resource list, select your provisioned instance of Key Protect.
8. To create a new key, click 'Add +' and select the 'Create a key' window. Specify the
key's name and key type.
9. When you are finished filling out the key's details, click 'Add key' to confirm.
10. From the Clusters console, select the cluster that you want to enable encryption for.
11. From the 'Overview' tab, in the 'Integrations > Key management service' section, click
'Enable'.
12. Select the 'Key management service instance' and 'Root key' that you want to use
for the encryption.
13. Click 'Enable'.
14. Verify that the KMS enablement process is finished. From the 'Summary > Master
status' section, you can check the progress.
15. After the KMS provider is enabled in the cluster, data and new secrets that
are created in the cluster are automatically encrypted by using your root key..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-kubernetes-cluster' AND json.rule = type equal ignore case kubernetes and state equal ignore case "normal" and features.keyProtectEnabled is false```
GCP Vertex AI Workbench Instance JupyterLab interface access mode set to single user
This policy identifies GCP Vertex AI Workbench Instances with JupyterLab interface access mode set to single user.

Vertex AI Workbench Instance can be accessed using the web-based JupyterLab interface. Access mode controls the control access to this interface. Allowing access to only a single user could limit collaboration, increase chances of credential sharing, and hinder security audits and reviews of the resource.

It is recommended to avoid single user access and make use of the service account access mode for workbench instances.
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: Access mode cannot be changed for existing Vertex AI Workbench Instances. A new Vertex AI Workbench instance should be created.

To create a new Vertex AI Workbench instance with access mode set to service account, please refer to the steps below:
1. Login to the GCP console
2. Navigate to the 'Vertex AI' service
3. In side panel, under 'Notebooks', go to 'Workbench'
4. Select 'INSTANCES' tab
5. Click 'CREATE NEW'
6. Click 'ADVANCED OPTIONS'
7. Configure the instance as required
8. Go to 'IAM and security' tab
9. Select 'Service account'
10. Click 'CREATE'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-vertex-ai-workbench-instance' AND json.rule = state equals "ACTIVE" and ( gceSetup.metadata.proxy-mode equals "mail" or gceSetup.metadata.proxy-user-mail exists )```
AWS ElastiCache cluster not using supported engine version
This policy identifies AWS Elastic Redis or Memcache cluster not using the supported engine version.

AWS ElastiCache simplifies deploying, operating, and scaling Redis and Memcached in-memory caches in the cloud. An ElastiCache cluster not using a supported engine version runs on outdated Redis or Memcached versions. These versions may be end-of-life (EOL) or lack current updates and patches from AWS. This exposes the cluster to unpatched vulnerabilities, compliance risks, and potential service instability.

It is recommended to regularly update your ElastiCache clusters to the latest supported engine versions as recommended by AWS.
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 Upgrade the AWS ElastiCache cluster perform the following actions:
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 caches' under the 'Resources' section
5. Select reported Redis cluster
6. Click on 'Modify' button
7. In the 'Modify Cluster' dialog box, Under the 'Cluster settings' section 
8. Select 'Engine version' from the drop down according to your requirements.
9. select 'Parameter groups' family that is compatible with the new engine version.
10. Click on 'Preview Changes'
11. Select Yes checkbox under 'Apply Immediately' , to apply the configuration changes immediately. If Apply Immediately is not selected, the changes will be processed during the next maintenance window.
12. Click on 'Modify'.

Query:
```config from cloud.resource where api.name = 'aws-elasticache-cache-clusters' as X; config from cloud.resource where api.name = 'aws-cache-engine-versions' as Y; filter 'not( $.X.engine equals $.Y.engine and $.Y.cacheEngineVersionDescription contains $.X.engineVersion)'; show X;```
Azure Spring Cloud App system-assigned managed identity is disabled
This policy identifies Azure Spring Cloud apps in which system-assigned managed identity is disabled. System-assigned 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 system-assigned managed identity to your Spring Cloud apps.
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 enable system-assigned managed identity on an existing Azure Spring Cloud app, follow the below URL:
https://docs.microsoft.com/en-in/azure/spring-cloud/how-to-enable-system-assigned-managed-identity.

Query:
```config from cloud.resource where api.name = 'azure-spring-cloud-service' AND json.rule = properties.powerState equals Running as X; config from cloud.resource where api.name = 'azure-spring-cloud-app' AND json.rule = properties.provisioningState equals Succeeded and identity does not exist as Y; filter '$.X.name equals $.Y.serviceName'; show Y;```