knarayan/cloud_posture_checks huggingface dataset:
Azure Front Door does not have the Azure Web application firewall (WAF) enabled
This policy identifies Azure Front Doors which do not have the Azure Web application firewall (WAF) enabled. As a best practice, configure the Azure WAF service on the Front Doors to protect against application-layer attacks. To block malicious requests to your Front Doors, define the block criteria in the WAF rules. 
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 the Azure portal
2. Select 'All services' > 'Front Doors'
3. Click on the reported Front Door
4. Click on the 'Web application firewall' from the left panel
5. Select the frontend to attach WAF policy and Click on 'Apply Policy'
6. In 'Associate a Waf policy' dialog, select appropriate enabled WAF policy from the 'Policy' dropdown.
7. Click on 'Add' 
8. Click on 'Save' to save your changes.

Query:
```config from cloud.resource where api.name = 'azure-frontdoor' AND json.rule = properties.provisioningState equals Succeeded as X; config from cloud.resource where api.name = 'azure-frontdoor-waf-policy' as Y; filter '$.X.properties.frontendEndpoints[*].properties.webApplicationFirewallPolicyLink.id does not exist or ($.X.properties.frontendEndpoints[*].properties.webApplicationFirewallPolicyLink.id equal ignore case $.Y.id and $.Y.properties.policySettings.enabledState equals Disabled)'; show X;```
Azure Logic app configured with public network access
This policy identifies Azure Logic apps that are configured with public network access.

Exposing Logic Apps directly to the public internet increases the attack surface, making them more susceptible to unauthorized access, security threats, and potential breaches. By limiting Logic Apps to private network access, they are securely managed and less prone to external vulnerabilities.

As a security best practice, it is recommended to configure private network access or restrict the public exposure only to the required entities instead of wide ranges.
This is applicable to azure 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. Log in to Azure portal
2. Navigate to Logic apps
3. Click on the reported Logic app
4. Under 'Setting' section, click on 'Networking'
5. On the 'Networking' page, under 'Inbound traffic configuration' section, select the 'Public network access' setting.
6. On the 'Access Restrictions' page, review the list of access restriction rules that are defined for your app and avoid providing access to all networks.
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = 'properties.state equal ignore case running and kind contains workflowapp and ((properties.publicNetworkAccess exists and properties.publicNetworkAccess equal ignore case Enabled) or (properties.publicNetworkAccess does not exist and (properties.privateLinkIdentifiers does not exist or properties.privateLinkIdentifiers is empty))) and config.ipSecurityRestrictions[?any((action equals Allow and ipAddress equals Any) or (action equals Allow and ipAddress equals 0.0.0.0/0))] exists'```
AWS Elasticsearch IAM policy overly permissive to all traffic
This policy identifies Elasticsearch IAM policies that are overly permissive to all traffic. Amazon Elasticsearch service makes it easy to deploy and manage Elasticsearch. Customers can create a domain where the service is accessible. The domain should be granted access restrictions so that only authorized users and applications have access to the service.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['HIGH_PRIVILEGED_ROLE'].
Mitigation of this issue can be done as follows: 1. Log in to AWS console
2. Goto the IAM Services
3. Click on 'Policies' in the left-hand panel
4. Search for the Policy for which the Alert is generated and click on it
5. Under the Permissions tab, click on Edit policy
6. Under the Visual editor, for each of the 'Elasticsearch Service', click to expand and perform following.
6.a. Click to expand 'Request conditions'
6.b. Under the 'Source IP', remove the row with the entry '0.0.0.0/0' or '::/0'. Add condition with restrictive IP ranges.
7. Click on Review policy and Save changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-policy-version' AND json.rule = document.Statement[?any((Condition.IpAddress.aws:SourceIp contains 0.0.0.0/0 or Condition.IpAddress.aws:SourceIp contains ::/0) and Effect equals Allow and Action anyStartWith es:)] exists```
IBM Cloud user with IAM policies provide administrative privileges for Cloud Monitoring Service
This policy identifies IBM Cloud users with overly permissive IBM Cloud Monitoring 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 '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 "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;```
AWS Elasticsearch domain has Search slow logs set to disabled
This policy identifies Elasticsearch domains for which Search slow logs is disabled in your AWS account. Enabling support for publishing Search slow logs to AWS CloudWatch Logs enables you to have full insight into the performance of search operations performed on your Elasticsearch clusters. This will help you in identifying performance issues caused by specific search queries so that you can optimize your queries to address the problem.
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 Elasticsearch Service Dashboard
4. Choose reported Elasticsearch domain
5. Select the 'Logs' tab
6. In 'Set up Search slow logs' section,
	a. click on 'Setup'
	b. In 'Select CloudWatch Logs log group' setting, Create/Use existing CloudWatch Logs log group as per your requirement
	c. In 'Specify CloudWatch access policy', Create new/Select an existing policy as per your requirement
	d. Click on 'Enable'

The search slow logs setting 'Status' should change now to 'Enabled'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-es-describe-elasticsearch-domain' AND json.rule = 'processing is false and (logPublishingOptions does not exist or logPublishingOptions.SEARCH_SLOW_LOGS.enabled is false or logPublishingOptions.SEARCH_SLOW_LOGS.cloudWatchLogsLogGroupArn is empty)'```
AWS Bedrock agent is not associated with Bedrock guardrails
This policy identifies the AWS Bedrock agent that is not associated with Bedrock guardrails

Amazon Bedrock Guardrails provides governance and compliance controls for generative AI applications, ensuring safe and responsible model use. Associating Guardrails with the Bedrock agent is useful for implementing governance and compliance controls in generative AI applications. Not linking Guardrails to the Bedrock agent raises the risk of non-compliance and harmful AI application outputs.

It is recommended that AWS Bedrock agents be associated with Bedrock guardrails to implement safeguards and prevent unwanted behavior from model responses or user messages.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To associate the aws bedrock agent with the bedrock guardrail, perform the following actions:

1. Log in to the AWS console. and Navigate to Amazon Bedrock console available at https://console.aws.amazon.com/bedrock/.
2. In the navigation panel, under 'Builder tools', select 'Agents'.
3. In the Agents, Click on the agent that is reported.
4. Click on the 'Edit in Agent Builder' button on the right corner.
5. In the Agent builder window, Under the 'Guardrail details' section click 'Edit' and select the name and version of the Amazon Bedrock guardrail created previously or click on the link to Create a new guardtrail.
6. Choose 'Save and exit' to attach the selected guardrail to your Amazon Bedrock agent..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-bedrock-agent' AND json.rule = agentStatus is not member of ( "DELETING","FAILED") and guardrailConfiguration.guardrailIdentifier does not exist```
GCP Cloud Load Balancer HTTP(S) logging is not enabled

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 api.name = 'gcloud-compute-external-backend-service' AND json.rule = logConfig.enable does not exist or logConfig.enable is false```
AWS DMS replication instance is publicly accessible
This policy identifies AWS DMS (Database Migration Service) replication instances with public accessibility enabled.

A DMS replication instance is used to connect and read the source data and prepare it for consumption by the target data store. When AWS DMS replication instances are publicly accessible, it increases the risk of unauthorized access, data breaches, and potentially malicious activities.

It is recommended to disable the public accessibility of DMS replication instances to decrease the attack surface.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: Public accessibility can be disabled only at the time of creation, please follow the below steps to create a new DMS replication instance:

1. Sign in to the AWS Management Console and navigate to the AWS DMS console.
2. In the navigation pane, choose 'Replication instances' and then click the 'Create replication instance' button.
3. Under the 'Connectivity and security' section, Leave the 'Publicly accessible' option unchecked to ensure that the replication instance does not have public IP addresses or DNS names.
4. Configure other settings based on your requirements.
5. Click the 'Create replication instance' button to create the replication instance.

To delete the reported AWS DMS replication instance, Please follow the below steps:

1. Sign in to the AWS Management Console and navigate to the AWS DMS console.
2. In the navigation pane, choose 'Replication instances' to see a list of your existing replication instances.
3. Select the replication instance that you want to delete from the list.
4. After selecting the replication instance, choose 'Actions' and then 'Delete' from the menu.
5. A confirmation dialog box will appear. Review the details and confirm that you want to delete the replication instance by selecting the 'Delete' button..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-dms-replication-instance' AND json.rule = replicationInstanceStatus is not member of ('creating','deleted','deleting') and publiclyAccessible is true```
GCP Vertex AI Workbench Instance has vTPM disabled
This policy identifies GCP Vertex AI Workbench Instances that have the Virtual Trusted Platform Module (vTPM) feature disabled.

The Virtual Trusted Platform Module (vTPM) validates the guest VM's pre-boot and boot integrity and provides key generation and protection. The root keys of the vTPM, as well as the keys it generates, cannot leave the vTPM, thereby offering enhanced protection against compromised operating systems or highly privileged project administrators.

It is recommended to enable the virtual TPM device on GCP Vertex AI Workbench Instances to support measured boot and other OS security features that require a TPM.
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 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 'Shielded VM', enable 'Turn on vTPM'
10. Click on 'Save'
11. Click on 'START/RESUME' from the top menu.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-vertex-ai-workbench-instance' AND json.rule = state equals "ACTIVE" AND shieldedInstanceConfig.enableVtpm is false```
OCI API Gateway is not configured with Network Security Groups
This policy identifies API Gateways that are not configured with Network Security Groups.

Network security groups give fine-grained control of resources and help in restricting network access to your Private API Gateway with specific ports or with specific IP address range.

As best practice, it is recommended to restrict access to the API Gateway by configuring network security groups.
This is applicable to oci 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. Log in to OCI console
2. Go to Developer Services -> API Management -> Gateways
3. Click on the reported Gateway
4. Click on the 'Edit' button
NOTE: Before you update API gateway with Network security group, make sure you have a restrictive Network Security Group already created with only specific traffic ports or with specific IP address range based on requirement.
5. On the 'Edit gateway' dialog, select the 'Enable network security groups' and select the restrictive Network Security Group 
6. Click on the 'Save Changes' button..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-apimanagement-apigateway' AND json.rule = lifecycleState equal ignore case ACTIVE and (networkSecurityGroupIds[*] is empty or networkSecurityGroupIds[*] does not exist)```
GCP Cloud Armor policy not configured with cve-canary rule
This policy identifies GCP Cloud Armor rules where cve-canary is not enabled. Preconfigured WAF rule called "cve-canary" can help detect and block exploit attempts of CVE-2021-44228 and CVE-2021-45046 to address the Apache Log4j vulnerability. It is recommended to create a Cloud Armor security policy with rule blocking Apache Log4j exploit attempts.

Reference : https://cloud.google.com/blog/products/identity-security/cloud-armor-waf-rule-to-help-address-apache-log4j-vulnerability
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: To Update Existing rules follow the below steps,

1. Login to GCP console
2. Navigate to 'Cloud Armor' from service 'Network Security'(Left Panel)
3. Click on the alerted policy
4. Click on the pencil icon on the rule to edit the rule
5. Under 'Mode', select 'Advanced mode', add expression "evaluatePreconfiguredExpr('cve-canary')"
6. Under 'Action', select 'Deny' to block the exploit
7. Click on 'Update'

To Add rule follow the below steps,

1. Login to GCP console
2. Navigate to 'Cloud Armor' from service 'Network Security'(Left Panel)
3. Click on the alerted policy
4. Click on 'Add rule'
5. Under 'Mode', select 'Advanced mode', add expression "evaluatePreconfiguredExpr('cve-canary')"
6. Under 'Action', select 'Deny' to block the exploit
7. Update other details and click on 'Add'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-armor-security-policy' AND json.rule = type does not equal ignore case CLOUD_ARMOR_EDGE and (rules[*].match.expr.expression does not contain cve-canary or rules[?any(match.expr.expression contains cve-canary and action equals allow)] exists)```
Copy of Copy of GCP API key is created for a project
This policy identifies GCP projects where API keys are created. Keys are insecure because they can be viewed publicly, such as from within a browser, or they can be accessed on a device where the key resides. To avoid the security risk in using API keys, it is recommended to use standard authentication flow instead.

Note: There are limited cases where API keys are more appropriate. For example, if there is a mobile application that needs to use the Google Cloud Translation API, but doesn't otherwise need a backend server, API keys are the simplest way to authenticate to that API. If a business requires API keys to be used, then the API keys should be secured using appropriate IAM policies.
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: Use of API keys is generally considered as less secure authentication mechanism and should be avoided. A secure authentication mechanism should be used. Follow the below mentioned URL to evaluate an alternate, suitable authentication mechanism:
https://cloud.google.com/endpoints/docs/openapi/authentication-method

To delete an API Key:
1. Log in to google cloud console
2. Navigate to section 'Credentials', under 'APIs & Services'.
3. To delete API Key, go to 'API Keys' section, click the Actions button (three dots) in front of key name.
4. Click on ‘Delete API key’ button.
5. In the 'Delete credential' dialog, click 'DELETE' button.

Note: Deleting API keys might break dependent applications. It is recommended to thoroughly review and evaluate the impact of API key before deletion..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-api-key' as X; count(X) greater than 0```
AWS CloudTrail bucket is publicly accessible
This policy identifies publicly accessible S3 buckets that store CloudTrail data. These buckets contains sensitive audit data and only authorized users and applications should have access.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: 1. Login to the AWS Console
2. Navigate to the 'S3' service
3. Click on the 'S3' resource reported in the alert
4. Click on the 'Permissions'
5. If Access Control List' is set to 'Public' follow below steps
a. Under 'Access Control List', Click on 'Everyone' and uncheck all items
b. Click on Save
6. If 'Bucket Policy' is set to public follow below steps
a. Under 'Bucket Policy', modify the policy to remove public access
b. Click on Save
c. If 'Bucket Policy' is not required delete the existing 'Bucket Policy'.

Note: Make sure updating 'Access Control List' or 'Bucket Policy' does not affect S3 bucket data access..

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 and accountLevelPublicAccessBlockConfiguration does not exist) or ((acl.grants[?(@.grantee=='AllUsers')] size > 0) and ((publicAccessBlockConfiguration.ignorePublicAcls is false and accountLevelPublicAccessBlockConfiguration does not exist) or (publicAccessBlockConfiguration does not exist and accountLevelPublicAccessBlockConfiguration.ignorePublicAcls is false) or (publicAccessBlockConfiguration.ignorePublicAcls is false and accountLevelPublicAccessBlockConfiguration.ignorePublicAcls is false))) or (policyStatus.isPublic is true and ((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))))" as X; config from cloud.resource where api.name = 'aws-cloudtrail-describe-trails' as Y; filter'$.X.bucketName equals $.Y.s3BucketName'; show X;```
AWS RDS instance not configured with IAM authentication
This policy identifies RDS instances that are not configured with IAM authentication. If you enable IAM authentication you don't need to store user credentials in the database, because authentication is managed externally using IAM. IAM database authentication provides the network traffic to and from database instances is encrypted using Secure Sockets Layer (SSL), Centrally manage access to your database resources and Profile credentials instead of a password, for greater security.

For details:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html

NOTE: IAM database authentication works only with MySQL and PostgreSQL. IAM database authentication is not available on all database engines; please refer https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html#UsingWithRDS.IAMDBAuth.Availability for available versions. 
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: To enable IAM authentication follow the below mentioned URL:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.Enabling.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name= 'aws-rds-describe-db-instances' AND json.rule = dbinstanceStatus contains available and dbclusterIdentifier does not exist and (engine contains postgres or engine contains mysql) and engineVersion is not member of (8.0.11, 8.0.13, 8.0.15, 9.6.1, 9.6.2, 9.6.3, 9.6.5, 9.6.6, 9.6.8, 9.6.9, 9.6.10, 10.1, 10.3, 10.4, 10.5) and iamdatabaseAuthenticationEnabled is false```