knarayan/cloud_posture_checks huggingface dataset:
GCP Log metric filter and alert does not exist for Cloud Storage IAM permission changes
This policy identifies the GCP account which does not have a log metric filter and alert for Cloud Storage IAM permission changes. Monitoring Cloud Storage IAM permission activities will help in reducing time to detect and correct permissions on sensitive Cloud Storage bucket and objects inside the bucket. It is recommended to create a metric filter and alarm to detect activities related to the Cloud Storage IAM permission.
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. Sign in to GCP Console
2. Navigate to 'Logs-based metrics' under the 'Logging' section.
3. Click on 'CREATE METRIC'.
4. Provide 'Metric Type' and 'Details'.
5. In 'Filter selection', add filter as 
resource.type="gcs_bucket" AND protoPayload.methodName="storage.setIamPermissions"
6. Click on 'CREATE METRIC'.
7. Under 'User-defined metrics' section, choose the metric you created in step 6 and click on the kebab menu (Vertical 3 dots) on the right side of the metrics
8. Click on 'Create alert from metric'; it will navigate to 'Create alerting policy' under the section 'Monitoring'.
9. Add the metric name created above if not auto-filled in the Monitoring filter. Choose an appropriate value for other alert condition parameters as desired. Then Click on 'NEXT'
10. Configure all alert trigger settings as desired. Then Click on 'NEXT'
11. Configure notifications as desired and provide an appropriate name for the alert policy. Then Click on 'NEXT'
12. Click on 'CREATE POLICY'..

Query:
```config from cloud.resource where api.name = 'gcloud-logging-metric' as X; config from cloud.resource where api.name = 'gcloud-monitoring-policies-list' as Y; filter '$.Y.conditions[*].metricThresholdFilter contains $.X.name and ($.X.filter contains "resource.type =" or $.X.filter contains "resource.type=") and ($.X.filter does not contain "resource.type !=" and $.X.filter does not contain "resource.type!=") and $.X.filter contains "gcs_bucket" and ($.X.filter contains "protoPayload.methodName=" or $.X.filter contains "protoPayload.methodName =") and ($.X.filter does not contain "protoPayload.methodName!=" and $.X.filter does not contain "protoPayload.methodName !=") and $.X.filter contains "storage.setIamPermissions"'; show X; count(X) less than 1```
Azure Application Gateway WAF policy is not enabled in prevention mode
This policy identifies the Azure Application Gateway WAF policies that are not enabled in prevention mode.

Azure Application Gateway WAF policies support Prevention and Detection modes. Detection mode monitors and logs all threat alerts to a log file. Detection mode is useful for testing purposes and configures WAF initially but it does not provide protection. It logs the traffic, but it doesn't take any actions such as allow or deny. Where as, in Prevention mode, WAF analyzes incoming traffic to the application gateway and blocks any requests that are determined to be malicious based on a set of rules.

As a best security practice, it is recommended to enable Application Gateway WAF policies with Prevention mode to prevent malicious requests from reaching your application and potentially causing damage.
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 'Web Application Firewall policies (WAF)' dashboard
3. Click on the reported WAF policy
4. In 'Overview' section, Click on 'Switch to prevention mode'.

NOTE: Define managed rule or custom rules properly as per your business requirement prior to transition to Prevention mode. This can help in unexpected blocked traffic..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-application-gateway-waf-policy' AND json.rule = properties.applicationGateways[*].id size greater than 0 and properties.policySettings.state equal ignore case Enabled and properties.policySettings.mode does not equal ignore case Prevention```
Azure SQL server Defender setting is set to Off
This policy identifies Azure SQL server which have Defender setting set to Off. Azure Defender for SQL provides a new layer of security, which enables customers to detect and respond to potential threats as they occur by providing security alerts on anomalous activities. Users will receive an alert upon suspicious database activities, potential vulnerabilities, SQL injection attacks, as well as anomalous database access patterns. Advanced threat protection alerts provide details of suspicious activity and recommend action on how to investigate and mitigate the threat.
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 the Azure Portal
2. Go to the reported SQL server
3. Select 'SQL servers', Click on the SQL server instance you wanted to modify
4. Click on 'Microsoft Defender for Cloud' under 'Security'
5. Click on 'Enable Microsoft Defender for SQL'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-sql-server-list' AND json.rule =  "$.serverSecurityAlertPolicy.properties.retentionDays does not exist or $.serverSecurityAlertPolicy.properties.state equals Disabled"```
Copy of GCP API key is created for a project1
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 EMR shadow resource
sdvdsv
This is applicable to aws 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 api.name = 'aws-emr-studio' AND json.rule = DefaultS3Location exists and DefaultS3Location contains "aws-emr-studio-" as X; config from cloud.resource where api.name = 'aws-s3api-get-bucket-acl' AND json.rule = bucketName contains "aws-emr-studio-" as Y; filter 'not ($.X.BucketName equals $.Y.bucketName)' ; show X;```
Azure Network Security Group having Inbound rule overly permissive to all traffic on any protocol
This policy identifies Azure Network Security Groups (NSGs) which are overly permissive to all traffic on any protocol. A network security group contains a list of security rules that allow or deny inbound or outbound network traffic based on source or destination IP address, port, and protocol. As a best practice, it is recommended to configure NSGs to restrict traffic from known sources, allowing only authorized protocols and ports.
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: Before making any changes, please check the impact to your applications/services. Evaluate whether you want to edit the rule and limit access to specific users, hosts, and services only, deny access, or delete the rule completely.

1. Log in to the Azure Portal.
2. Select 'All services'.
3. Select 'Network security groups', under NETWORKING.
4. Select the Network security group you need to modify.
5. Select 'Inbound security rules' under Settings.
6. Select the rule you need to modify, and edit it to allow specific IP addresses and Port ranges OR set the 'Action' to 'Deny' OR 'Delete' the rule based on your requirement.
7. 'Save' your changes..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name= 'azure-network-nsg-list' AND json.rule = securityRules[?any((sourceAddressPrefix equals Internet or sourceAddressPrefix equals * or sourceAddressPrefix equals 0.0.0.0/0 or sourceAddressPrefix equals ::/0) and protocol equals * and access equals Allow and destinationPortRange contains * and direction equals Inbound)] exists```
IBM Cloud Virtual Private Cloud (VPC) Subnet has public gateways attached
This policy identifies IBM Virtual Private Cloud Subnet where public gateway attached. A Public Gateway enables resources to connect to the internet. After public gateway is attached, all resources in that subnet can connect to the internet. If the use case for public gateway is not external connectivity, it is recommended not to attach any public gateways.
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. Click on 'Menu Icon' and navigate to 'VPC Infrastructure' and then 'Public Gateways'
3. Select the 'Public Gateway' reported in the alert
4. From the drop down select Detach
5. Safely detach the public gateway and then delete the public gateway.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-network-subnet' and json.rule = public_gateway exists```
test-3

This is applicable to azure 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 = 'azure' AND api.name = 'azure-key-vault-list' AND json.rule = properties.provisioningState equals Succeeded and diagnosticSettings.value[*].properties.workspaceId does not equal ignore case "/subscriptions/8dff688e-d9b0-477c-b2b0-b0e729fb06bd/resourceGroups/rg-analytics-sh-prd-scus/providers/Microsoft.OperationalInsights/workspaces/log-sh-workspace"```
AWS IAM Roles with Administrator Access Permissions
This policy identifies AWS IAM roles which has administrator access permission set. This would allow all users who assume this role to have administrative privileges. As a security best practice, it is recommended to grant least privilege access like granting only the permissions required to perform a task, instead of providing excessive permissions.
This is applicable to aws cloud and is considered a medium 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. Navigate to IAM service
3. Click on Roles
4. Click on reported IAM role
5. Under 'Permissions policies' click on 'X' to detach or remove the policy having excessive permissions and assign a limited permission policy as required for a particular role..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-list-roles' as X; config from cloud.resource where api.name = 'aws-iam-get-policy-version' as Y; filter "($.X.inlinePolicies[*].policyDocument.Statement[?(@.Effect=='Allow' && @.Resource=='*')].Action any equal *) or ($.X.attachedPolicies[*].policyArn contains $.Y.policyArn and $.Y.document.Statement[?(@.Effect=='Allow' && @.Resource=='*')].Action any equal *)"; show X;```
Hostfindings test

This is applicable to all 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 finding.type IN ( 'Host Vulnerability', 'Serverless Vulnerability' , 'Compliance' , 'AWS Inspector Runtime Behavior Analysis' , 'AWS Inspector Security Best Practices' , 'AWS GuardDuty Host' , 'AWS GuardDuty IAM' ) ```
AWS MQ Broker is not encrypted by Customer Managed Key (CMK)
This policy identifies AWS MQ Brokers that are not encrypted by Customer Managed Key (CMK).

AWS MQ Broker messages might contain sensitive information. AWS MQ Broker messages are encrypted by default by an AWS managed key but users can specify CMK to get enhanced security, control over the encryption key, and also comply with any regulatory requirements.

As a security best practice use of CMK to encrypt your MQ Broker is advisable as it gives you full control over the encrypted data.
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: AWS MQ Broker encryption option can be done only at the creation of MQ broker. You cannot change the encryption options once it has been created. To resolve this alert create a new MQ broker configuring encryption with CMK key, migrate all data to newly created MQ broker and then delete the reported MQ broker.

To create a new AWS MQ broker encryption with CMK key,
1. Log 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 the AWS MQ broker Dashboard
4. Click on 'Create brokers'
5. Select the broker engine type, deployment mode as per your business requirement
6. Under 'Configure settings', In Additional settings section choose Encryption option choose 'Customer managed CMKs are created and managed by you in AWS Key Management Service (KMS).' based on your business requirement.
7. Review and Create the MQ broker.

To delete reported MQ broker, refer following URL:
For ActiveMQ Broker: https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/getting-started-activemq.html#delete-broker
For RabbitMQ Broker: https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/getting-started-rabbitmq.html#rabbitmq-delete-broker.

Query:
```config from cloud.resource where api.name = 'aws-mq-broker' AND json.rule = brokerState equal ignore case RUNNING as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' AND json.rule = keyMetadata.keyState equal ignore case Enabled and keyMetadata.keyManager does not equal ignore case CUSTOMER as Y; filter '$.X.encryptionOptions.kmsKeyId equals $.Y.keyMetadata.arn or $.X.encryptionOptions.useAwsOwnedKey is true'; show X;```
OCI Object Storage Bucket write level logging is disabled
This policy identifies Object Storage buckets that have write-level logging disabled.

Enabling write-level logging for Object Storage provides more visibility into changes to objects in your buckets. Without write-level logging, there is no record of changes made to the bucket. This lack of visibility can lead to undetected data breaches, unauthorized changes, and compliance violations.

As a best practice, it is recommended to enable write-level logging on Object Storage buckets.
This is applicable to oci 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: First, if a log group for holding these logs has not already been created, create a log group by the following steps:

1. Login to the OCI Console
2. Go to the Log Groups page
3. Click the 'Create Log Group' button in the middle of the screen
4. Select the relevant compartment to place these logs
5. Type a name for the log group in the 'Name' box.
6. Add an optional description in the 'Description' box
7. Click the 'Create' button in the lower left hand corner

Second, enable Object Storage write log logging for reported bucket by the following steps:
1. Login to the OCI Console
2. Go to the Logs page
3. Click the 'Enable Service Log' button in the middle of the screen
4. Select the relevant resource compartment
5. Select ‘Object Storage’ from the Service drop-down menu 
6. Select the reported bucket from the ‘Resource’ drop-down menu 
7. Select ‘Write Access Events’ from the ‘Log Category’ drop-down menu 
8. Type a name for your Object Storage write log in the ‘Log Name’ drop-down menu 
9. Click the ‘Enable Log’ button in the lower left hand corner.

Query:
```config from cloud.resource where api.name = 'oci-object-storage-bucket' as X; config from cloud.resource where api.name = 'oci-logging-logs' as Y; filter 'not ($.X.name contains $.Y.configuration.source.resource and $.Y.configuration.source.service contains objectstorage and $.Y.configuration.source.category contains write and $.Y.lifecycleState equal ignore case ACTIVE )'; show X;```
Azure Active Directory MFA is not enabled for user
This policy identifies Azure users for whom AD MFA (Active Directory Multi-Factor Authentication) is not enabled. 

Azure AD is a simple best practice that adds an extra layer of protection on top of your user name and password. MFA provides increased security for your Azure account settings and resources. Enabling Azure AD Multi-Factor Authentication using Conditional Access policies is the recommended approach to protect users.

As best practice, it is recommended to enable Azure AD Multi-Factor Authentication for users.
This is applicable to azure cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MFA'].
Mitigation of this issue can be done as follows: To enable per-user Azure AD Multi-Factor Authentication; follow below URL:
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates.

Query:
```config from cloud.resource where api.name = 'azure-active-directory-user-registration-details' AND json.rule = isMfaRegistered is false as X; config from cloud.resource where api.name = 'azure-active-directory-user' AND json.rule = accountEnabled is true as Y; filter '$.X.userDisplayName equals $.Y.displayName'; show X;```
Azure App Service Web app client certificate is disabled
This policy identifies Azure web apps which are not set with client certificate. Client certificates allow for the app to request a certificate for incoming requests. Only clients that have a valid certificate will be able to reach the app.
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 the Azure portal
2. Navigate to App Services
3. Click on the reported App
4. Under Setting section, Click on 'Configuration'
5. Under 'General Settings' tab, In 'Incoming client certificates', Set 'Client certificate mode' to 'Require'
6. Click on 'Save'

Note: App Services with Free sku plan is ideal for testing applications in a managed Azure environment. For Free sku plan client certificates option is not supported. We recomended to upgrade such reported app service as per your requirement apart from free sku plan..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = 'kind starts with app and properties.clientCertEnabled equals false'```
Bobby Copy of Azure Service bus namespace not configured with Azure Active Directory (Azure AD) authentication
This policy identifies Service bus namespaces that are not configured with Azure Active Directory (Azure AD) authentication and are enabled with local authentication. Azure AD provides superior security and ease of use over shared access signatures (SAS). With Azure AD, there's no need to store the tokens in your code and risk potential security vulnerabilities. It is recommended to configure the Service bus namespaces with Azure AD 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 [].
Mitigation of this issue can be done as follows: To configured Azure Active Directory (Azure AD) authentication and disable local authentication on existing Service bus, follow below URL instructions:
https://docs.microsoft.com/en-us/azure/service-bus-messaging/disable-local-authentication.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-service-bus-namespace' AND json.rule = properties.status equals "Active" and (properties.disableLocalAuth does not exist or properties.disableLocalAuth is false)```
GCP Storage Bucket encryption not configured with Customer-Managed Encryption Key (CMEK)
This policy identifies GCP Storage Buckets that are not configured with a Customer-Managed Encryption key.

GCP Storage Buckets might contain sensitive information. Google Cloud Storage service encrypts all data within the buckets using Google-managed encryption keys by default but users can specify Customer-Managed Keys (CMKs) to get enhanced security, control over the encryption key, and also comply with any regulatory requirements.

As a security best practice, the use of CMK to encrypt your Storage bucket is advisable as it gives you full control over the encrypted data.
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: To update the GCP storage bucket with customer-managed encryption, follow the below steps:

1. Sign in to the Google Cloud Management Console. Navigate to the Cloud Storage Buckets page.
2. Click on the name of the bucket where you want to enable customer-managed encryption.
3. Under the 'Configuration' tab, under the 'Protection' section, select the 'Edit encryption type' option.
4. A 'Edit encryption' dialogue box will appear. Select the 'Customer-managed encryption key' option.
5. Under the 'Select a customer-managed key' dropdown, select the KMS key to be used for encryption.
6. Click on 'SAVE'.

Note: Make sure the storage bucket service account has cloudkms.cryptoKeyEncrypterDecrypter permissions to encrypt or decrypt with the selected key..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-storage-buckets-list' AND json.rule = encryption.defaultKmsKeyName does not exist```