knarayan/cloud_posture_checks huggingface dataset:
AWS Security Hub is not enabled
This policy identifies the AWS Security Hub that is not enabled in specific regions. 

AWS Security Hub is a centralized security management service by Amazon Web Services, providing a comprehensive view of your security posture and automating security checks across AWS accounts. Failure to enable AWS Security Hub in all regions may lead to limited visibility and compromised threat detection across your AWS environment.

It is recommended to enable AWS Security Hub in all regions for consistent visibility and enhanced threat detection across your AWS environment.
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 enable the AWS Security Hub, perform the following actions:

1. Sign in to the AWS Management Console
2. Select the specific region from the region drop-down in the top right corner, for which the alert is generated
3. In the Navigation Panel on the left, Select 'All services' and under 'Security, Identity, & Compliance', select 'Security Hub'
4. When you open the Security Hub console for the first time, choose 'Go to Security Hub'
5. On the welcome page, the 'Security standards' section lists the security standards that Security Hub supports
6. Select the check box for a standard to enable it
8. Choose 'Enable Security Hub'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-securityhub-hub' AND json.rule = SubscribedAt exists as X; count(X) less than 1```
test c p

This is applicable to azure 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 = 'azure' and api.name = 'azure-container-registry' AND json.rule = properties.provisioningState equal ignore case Succeeded and properties.encryption.status equal ignore case disabled```
GCP VPC network not configured with DNS policy with logging enabled
This policy identifies the GCP VPC networks which are not configured with DNS policy with logging enabled. Monitoring of Cloud DNS logs provides visibility to DNS names requested by the clients within the VPC. These logs can be monitored for anomalous domain names and evaluated against threat intelligence. It is recommended to enable DNS logging for all the VPC networks.
Note: For full capture of DNS, firewall must block egress UDP/53 (DNS) and TCP/443 (DNSover HTTPS) to prevent client from using external DNS name server for resolution.
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: To add DNS server policy with logging to a VPC network,

1. Login to GCP console
2. Navigate to service 'VPC network'(Left Panel)
3. Click on the alerting VPC network
4. Click on 'EDIT'
5. Under 'DNS server policy' dropdown, select an available service policy or 'create a new server policy' as required
Link: https://cloud.google.com/dns/docs/policies#creating 
6. Click on 'SAVE'
To enable logging to a DNS policy that is attached to a VPC follow the below reference,

1. Login to GCP console
2. Navigate to service 'VPC network'(Left Panel)
3. Click on the alerting VPC network
4. Click on the attached 'DNS server policy'
5. Click on 'EDIT POLICY'
6. Under section 'Logs' select 'On'
7. Click on 'SAVE'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-networks-list' as X; config from cloud.resource where api.name = 'gcloud-dns-policy' as Y; filter 'not($.Y.networks[*].networkUrl contains $.X.name and $.Y.enableLogging is true)'; show X;```
liron test custom policy #3
run + build policy
This is applicable to azure cloud and is considered a high severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-role-assignment' AND json.rule = (properties.roleDefinition.properties.type equals CustomRole and (properties.roleDefinition.properties.permissions[?any((actions[*] equals Microsoft.Authorization/locks/delete and actions[*] equals Microsoft.Authorization/locks/read and actions[*] equals Microsoft.Authorization/locks/write) or actions[*] equals Microsoft.Authorization/locks/*)] exists) and (properties.roleDefinition.properties.permissions[?any(notActions[*] equals Microsoft.Authorization/locks/delete or notActions[*] equals Microsoft.Authorization/locks/read or notActions[*] equals Microsoft.Authorization/locks/write or notActions[*] equals Microsoft.Authorization/locks/*)] does not exist)) as X; count(X) less than 1```
AWS SQS queue access policy is overly permissive
This policy identifies Simple Queue Service (SQS) queues that have an overly permissive access policy. It is highly recommended to have the least privileged access policy to protect the SQS queue from data leakage and unauthorized access.

For more details:
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-examples-of-sqs-policies.html
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: 1. Log in to the AWS console
2. Select the region, from the region drop-down, in which the alert is generated
3. Navigate to Simple Queue Service (SQS) dashboard
4. Choose the reported Simple Queue Service (SQS) and choose 'Edit'
5. Scroll to the 'Access policy' section
6. Edit the access policy statements in the input box, Make sure the 'Principal' is not set to '*', which makes your SQS queues accessible to any anonymous users.
7. When you finish configuring the access policy, choose 'Save'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-sqs-get-queue-attributes' AND json.rule = attributes.Policy.Statement[?any(Effect equals Allow and (Action anyStartWith sqs: or Action anyStartWith SQS:) and (Principal.AWS contains * or Principal equals *) and Condition does not exist)] exists```
Alibaba Cloud RAM user has more than one active access keys
This policy identifies Resource Access Management (RAM) users who have more than one active access keys. RAM users having more than one key can lead to increased chances of accidental exposure. As a best security practice, it is recommended to delete unused access keys.
This is applicable to alibaba_cloud cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['KEYS_AND_SECRETS'].
Mitigation of this issue can be done as follows: 1. Login to Alibaba Cloud Portal
2. Go to Resource Access Management
3. In the left-side navigation pane, click 'Users'
4. Select the reported user
5. In the 'Authentication' tab, under 'User AccessKeys'
6. In the list of access keys, Make a note on the access keys which is not used or not required as per your requirements.
7. Click on 'Delete'
8. On the 'Delete AccessKey' popup window, select 'I am aware of the risk and confirm that the deletion' and click on 'Close'..

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ram-user' AND json.rule =  'accessKeys[*] size > 1 and accessKeys[*].status all equal Active'```
Alibaba Cloud Security group allow internet traffic to PostgreSQL port (5432)
This policy identifies Security groups that allow inbound traffic on PostgreSQL port (5432) 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 5432, 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(5432,5432)"```
IBM Cloud Service ID with IAM policies provide administrative privileges for Kubernetes Service
This policy identifies IBM Cloud Service IDs with overly permissive Kubernetes Administrative role. When a Service ID having a policy with admin rights gets compromised, the whole service gets compromised. As a security best practice, it is recommended to grant the least privileged access, such as granting only the permissions required to perform a task, instead of providing excessive permissions.
This is applicable to ibm cloud and is considered a low severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. Log in to the IBM Cloud console.
2. In the IBM Cloud console, click 'Manage' on the title bar > 'Access (IAM)', and click on 'Service IDs' in the left panel.
3. Select the Service ID which is reported and you want to edit access for.
4. Under the 'Access' tab, go to the 'Access policies' section, and click on the three dots on the right corner of a row for the policy which is having Administrator permission on '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 "iam-ServiceId")] exists )] exists as X;config from cloud.resource where api.name = 'ibm-iam-service-id' as Y; filter '$.X.subjects[*].attributes[*].value contains $.Y.id'; show Y;```
GCP VM instances have block project-wide SSH keys feature disabled
This policy identifies VM instances which have block project-wide SSH keys feature disabled. Project-wide SSH keys are stored in Compute/Project-metadata. Project-wide SSH keys can be used to login into all the instances within a project. Using project-wide SSH keys eases the SSH key management but if compromised, poses the security risk which can impact all the instances within a project. It is recommended to use Instance specific SSH keys which can limit the attack surface if the SSH keys are compromised.
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: 1. Login to GCP Portal
2. Go to Computer Engine (Left Panel)
3. Go to VM instances
4. From the list of VMs, choose the reported VM
5. Click on Edit button
6. Under SSH Keys section, Check 'Block project-wide SSH keys' on the checkbox
7. Click on Save.

Query:
```config from cloud.resource where api.name = 'gcloud-compute-project-info' AND json.rule = commonInstanceMetadata.kind equals "compute#metadata" and commonInstanceMetadata.items[?any(key contains "enable-oslogin" and (value contains "Yes" or value contains "Y" or value contains "True" or value contains "true" or value contains "TRUE" or value contains "1"))] does not exist and commonInstanceMetadata.items[?any(key contains "ssh-keys")] exists as X; config from cloud.resource where api.name = 'gcloud-compute-instances-list' AND json.rule = status equals RUNNING and ( metadata.items[?any(key exists and key contains "block-project-ssh-keys" and (value contains "Yes" or value contains "Y" or value contains "True" or value contains "true" or value contains "TRUE" or value contains "1"))] does not exist and metadata.items[?any(key exists and key contains "enable-oslogin" and (value contains "Yes" or value contains "Y" or value contains "True" or value contains "true" or value contains "TRUE" or value contains "1"))] does not exist and name does not start with "gke-") as Y; filter '$.Y.zone contains $.X.name'; show Y;```
Alibaba Cloud RAM password policy does not expire in 90 days
This policy identifies Alibaba Cloud accounts for which do not have password expiration set to 90 days or less. As a best practice, change your password every 90 days or sooner to ensure secure access to the Alibaba Cloud console.
This is applicable to alibaba_cloud cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['WEAK_PASSWORD'].
Mitigation of this issue can be done as follows: 1. Log in to Alibaba Cloud Portal
2. Go to Resource Access Management (RAM) service
3. In the left-side navigation pane, click on 'Settings'
4. In the 'Security Settings' tab, In the 'Password Strength Settings' Section, Click on 'Edit Password Rule'
5. In the 'Password Validity Period' field, enter 90 or less based on your requirement.
6. Click on 'OK'
7. Click on 'Close'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ram-password-policy' AND json.rule = 'maxPasswordAge !isType Integer or maxPasswordAge > 90 or maxPasswordAge equals 0'```
Azure PostgreSQL database server with log checkpoints parameter disabled
This policy identifies PostgreSQL database servers for which server parameter is not set for log checkpoints. Enabling log_checkpoints helps the PostgreSQL Database to Log each checkpoint in turn generates query and error logs. However, access to transaction logs is not supported. Query and error logs can be used to identify, troubleshoot, and repair configuration errors and sub-optimal performance.
This is applicable to azure cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Login to Azure console.
2. Navigate to 'Azure Database for PostgreSQL servers' dashboard
3. Click on the alerted database name
4. Go to 'Server parameters' under 'Settings' block
5. From the list of parameters find 'log_checkpoints' and set it to on
6. Click on 'Save' button from top menu to save the change..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-postgresql-server' AND json.rule = "configurations.value[?(@.name=='log_checkpoints')].properties.value equals OFF or configurations.value[?(@.name=='log_checkpoints')].properties.value equals off"```
AWS Elastic Beanstalk environment logging not configured
This policy identifies the Elastic Beanstalk environments not configured to send logs to CloudWatch Logs.

An Elastic Beanstalk environment is a configuration of AWS resources where you can deploy your application. The environment logs refer to the logs generated by various components of your application, which can provide valuable insights into any errors or issues that may arise during operation. Failing to enable logging in an Elastic Beanstalk environment reduces visibility, hinders incident detection and response, and increases vulnerability to security breaches.

It is recommended to configure AWS Elastic Beanstalk environments to send logs to CloudWatch to ensure security and meet compliance 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 stream Elastic Beanstalk environment logs to CloudWatch Logs,
1. Sign in to the AWS 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. Go to 'Elastic Beanstalk' service.
4. In the navigation pane, choose 'Environments', then select the reported environment's name from the list.
5. In the navigation pane, choose Configuration.
6. In the 'Updates, monitoring, and logging' configuration category, choose Edit.
7. Under 'Instance log streaming to CloudWatch Logs', Enable Log streaming by selecting the 'Activated' checkbox.
8. Set 'Retention' to the number of days to save the logs.
9. Select the 'Lifecycle' setting that determines whether the logs are saved after the environment is terminated according to your business requirements.
10. To save the changes choose 'Apply' at the bottom of the page..

Query:
```config from cloud.resource where api.name = 'aws-elasticbeanstalk-environment' AND json.rule = status does not equal "Terminated" as X; config from cloud.resource where api.name = 'aws-elasticbeanstalk-configuration-settings' AND json.rule = configurationSettings[*].optionSettings[?any( optionName equals "StreamLogs" and value equals "false" )] exists as Y; filter ' $.X.environmentName equals $.Y.configurationSettings[*].environmentName and $.X.applicationName equals $.Y.configurationSettings[*].applicationName'; show X;```
IBM Cloud Secrets Manager user credentials have aged more than 90 days without being rotated
This policy identifies IBM Cloud Secrets Manager user credentials that have aged more than 90 days without being rotated. User credentials should be rotated to ensure that data cannot be accessed with an old password which might have been lost, cracked, or stolen. It is recommended that user credentials are regularly rotated.
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 the secret manager instance in which the reported secret resides, under security section.
3. Select the secret and click on 'Actions' dropdown.
4. Select 'Rotate' from the dropdown.
5. In the 'Rotate secret' screen, provide data as required.
6. Click on 'Rotate'..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-secret-manager-secret' AND json.rule = 'secret_type equals username_password and state_description equal ignore case active and (_DateTime.ageInDays(last_update_date) > 90)'```
GCP SQL Server instance database flag 'cross db ownership chaining' is enabled
This policy identifies GCP SQL Server instance database flag 'cross db ownership chaining' is enabled. Enabling cross db ownership is not recommended unless all of the databases hosted by the instance of SQL Server must participate in cross-database ownership chaining and you are aware of the security implications of this setting.
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. Login to GCP Console
2. Navigate to SQL
3. Click on the SQL Server instance for which you want to disable the database flag from the list
4. Click 'Edit'
5. Go to  'Flags and Parameters'  under 'Configuration options' section
6. Search for the flag 'cross db ownership chaining' and set the value 'off'
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 SQLSERVER and settings.databaseFlags[?(@.name=='cross db ownership chaining')].value equals on"```
Azure Application Insights not configured with Azure Active Directory (Azure AD) authentication
This policy identifies Application Insights that are not configured with Azure Active Directory (AAD) authentication and are enabled with local authentication.

Disabling local authentication and using AAD-based authentication enhances the security and reliability of the telemetry used to make both critical operational and business decisions.

It is recommended to configure the Application Insights with Azure Active Directory (AAD) authentication so that all actions are strongly authenticated.
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: To configure Azure Active Directory (AAD) authentication and disable local authentication on existing Application Insights, follow the below URL instructions:
https://docs.microsoft.com/en-us/azure/azure-monitor/app/azure-ad-authentication.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-application-insights-component' AND json.rule = properties.provisioningState equals Succeeded and (properties.DisableLocalAuth does not exist or properties.DisableLocalAuth is false)```
Azure Cognitive Services account hosted with OpenAI is not configured with data loss prevention
This policy identifies Azure Cognitive Services accounts hosted with OpenAI that are not configured with data loss prevention.

Azure AI services offer data loss prevention capabilities that allow customers to configure the list of outbound URLs their Azure AI services resources can access.

As a best practice, it is recommended to enable the data loss prevention feature in OpenAI-hosted Azure Cognitive Services accounts to prevent data loss.
This is applicable to azure cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To enable data loss prevention on existing Azure Cognitive Services account hosted with OpenAI, follow the below URL:
https://learn.microsoft.com/en-us/azure/ai-services/cognitive-services-data-loss-prevention?tabs=azure-cli#enabling-data-loss-prevention.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cognitive-services-account' AND json.rule = kind equal ignore case OpenAI and properties.provisioningState equal ignore case Succeeded and (properties.restrictOutboundNetworkAccess does not exist or properties.restrictOutboundNetworkAccess is false or (properties.restrictOutboundNetworkAccess is true and properties.allowedFqdnList is empty))```