knarayan/cloud_posture_checks huggingface dataset:
AWS EMR cluster is not configured with SSE KMS for data at rest encryption (Amazon S3 with EMRFS)
This policy identifies EMR clusters which are not configured with Server Side Encryption(SSE KMS) for data at rest encryption of Amazon S3 with EMRFS. As a best practice, use SSE-KMS for server side encryption to encrypt the data in your EMR cluster and ensure full control over your data.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: 1. Log in to 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 'EMR' dashboard from 'Services' dropdown
4. Go to 'Security configurations', click 'Create'
5. On the Create security configuration window,
6. In 'Name' box, provide a name for the new EMR security configuration
7. For encryption At Rest click the checkbox for 'Enable at-rest encryption for EMRFS data in Amazon S3'
8. From the dropdown 'Default encryption mode' select 'SSE-KMS'. Follow below link for configuration steps.
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-enable.html
9. Click on 'Create' button.
10. On the left menu of EMR dashboard Click 'Clusters'.
11. Select the EMR cluster for which the alert has been generated and click on the 'Clone' button from the top menu.
12. In the Cloning popup, choose 'Yes' and Click 'Clone'.
13. On the Create Cluster page, in the Security Options section, click on 'security configuration'.
14. From the 'Security configuration' drop down select the name of the security configuration created at step 4 to step 8, click 'Create Cluster'
15. Once you the new cluster is set up verify its working and terminate the source cluster in order to stop incurring charges for it.
16. On the left menu of EMR dashboard Click 'Clusters', from the list of clusters select the source cluster which is alerted
17. Click on the 'Terminate' button from the top menu
18. On the 'Terminate clusters' pop-up, click 'Terminate'..

Query:
```config from cloud.resource where api.name = 'aws-emr-describe-cluster' as X; config from cloud.resource where api.name = 'aws-emr-security-configuration' as Y; filter '($.X.status.state does not contain TERMINATING) and ($.X.securityConfiguration contains $.Y.name) and ($.Y.EncryptionConfiguration.EnableAtRestEncryption is true) and ($.Y.EncryptionConfiguration.AtRestEncryptionConfiguration.S3EncryptionConfiguration exists) and ($.Y.EncryptionConfiguration.AtRestEncryptionConfiguration.S3EncryptionConfiguration.EncryptionMode contains SSE) and ($.Y.EncryptionConfiguration.AtRestEncryptionConfiguration.S3EncryptionConfiguration.EncryptionMode does not contain KMS)' ; show X;```
AWS AppSync attached WAFv2 WebACL is not configured with AMR for Log4j Vulnerability
This policy identifies AppSync attached with WAFv2 WebACL which is not configured with AWS Managed Rules (AMR) for Log4j Vulnerability. As per the guidelines given by AWS, AppSync 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 AppSync console
3. Click on the reported AppSync
4. Choose 'Settings' in the navigation pane
5. In the Web application firewall section, 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-appsync-graphql-api' AND json.rule = wafWebAclArn is not empty as X; config from cloud.resource where api.name = 'aws-waf-v2-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.wafWebAclArn'; show X;```
Alibaba Cloud ApsaraDB RDS allowlist group is not restrictive
This policy identifies ApsaraDB for Relational Database Service (RDS) allowlist groups which are not restrictive. The value 0.0.0.0/0 indicates that all devices can access the RDS instance and The value 127.0.0.1 is the default IP address means that no devices can access the RDS instance. As a best practice, It is recommended that you periodically check and adjust your allowlists to maintain RDS security.
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 ApsaraDB for RDS
3. In the left-side navigation pane, click on 'Instances' 
4. Choose the reported instance, click on 'Manage'
5. In the left-side navigation pane, click on 'Data Security'
6. In the 'Data Security' section, click 'Edit' on the allow list setting which has IP address 127.0.0.1 or 0.0.0.0/0 and update the restrictive IP address in the box as per your requirement. 
7. Click on 'Ok'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-rds-instance' AND json.rule = 'Items[*].securityIPList contains 0.0.0.0/0 or Items[*].securityIPList contains 127.0.0.1'```
Azure Microsoft Defender for Cloud is set to Off for SQL servers on machines
This policy identifies Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) which has defender setting for SQL servers on machines is set to Off. Enabling Microsoft Defender for Cloud provides the tools needed to harden your resources, track your security posture, protect against cyberattacks, and streamline security management. It is highly recommended to enable Microsoft Defender for SQL servers on machines.
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 'Microsoft Defender for Cloud'
3. Select 'Environment Settings'
4. Click on the subscription name
5. Select the 'Defender plans'
6. Select 'Enable all Microsoft Defender for Cloud plans' if not already enabled
7. On the line in the table for 'SQL servers on machines' Select 'On' under Plan.
8. Select 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = pricings[?any( name equals SqlServerVirtualMachines and properties.pricingTier does not equal Standard)] exists```
Morgan_Stanley_custom_policy

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-ec2-describe-instances' as X; config from cloud.resource where api.name = 'aws-ec2-describe-volumes' as Y; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' as Z; filter "$.X.blockDeviceMappings[*].ebs.volumeId == $.Y.volumeId and $.Y.encrypted contains true and $.Y.kmsKeyId equals $.Z.key.keyArn and $.Z.keyMetadata.keyManager contains AWS and $.X.tags[?(@.key=='Name')].value does not contain CSR"; show Y; ```
Azure Microsoft Defender for Cloud endpoint protection monitoring is set to disabled
This policy identifies the Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) policies which have endpoint protection monitoring set to disabled. Enabling endpoint Protection will make sure that any issues or shortcomings in endpoint protection for all Microsoft Windows virtual machines are identified so that they can, in turn, be removed.
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 'Microsoft Defender for Cloud'
3. Select 'Environment Settings'
4. Choose the reported subscription
5. Click on the 'Security policy' under 'Policy settings' section
6. Click on 'SecurityCenterBuiltIn'
7. Select 'Parameters' tab
8. Set the 'Monitor missing Endpoint Protection in Azure Security Center' to 'AuditIfNotExists'
9. If no other changes required then Click on 'Review + save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-policy-assignments' AND json.rule = '((name == SecurityCenterBuiltIn and properties.parameters.endpointProtectionMonitoringEffect.value equals Disabled) or (name == SecurityCenterBuiltIn and properties.parameters[*] is empty and properties.displayName does not start with "ASC Default"))'```
AWS CloudTrail trail logs is not integrated with CloudWatch Log
This policy identifies AWS CloudTrail which has trail logs that are not integrated with CloudWatch Log. Enabling the CloudTrail trail logs integrated with CloudWatch Logs will enable the real-time as well as historic activity logging. This will further improve monitoring and alarm capability.
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. Login to the AWS Admin Console and access the CloudTrail service.
2. Click on the Trails in the left hand menu.
3. Click on the identified CloudTrail and navigate to the 'CloudWatch Logs' section.
4. Click on 'Configure' tab and provide required
5. Provide a log group name in field 'New or existing log group'
6. Click on 'Continue'
7. In the next page from 'IAM role' dropdown select an IAM role with required access or select the 'Create a new IAM role'
8. Click on 'Allow'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudtrail-describe-trails' AND json.rule = 'cloudWatchLogsRoleArn equals null or cloudWatchLogsRoleArn does not exist'```
Azure Key Vault secret has no expiration date (Non-RBAC Key vault)
This policy identifies Azure Key Vault secrets that do not have an expiry date for the Non-RBAC Key vaults. As a best practice, set an expiration date for each secret and rotate the secret regularly.

Before you activate this policy, ensure that you have added the Prisma Cloud Service Principal to each Key Vault: https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin/connect-your-cloud-platform-to-prisma-cloud/onboard-your-azure-account/azure-onboarding-checklist

Alternatively, run the following command on the Azure cloud shell:
az keyvault list | jq '.[].name' | xargs -I {} az keyvault set-policy --name {} --certificate-permissions list listissuers --key-permissions list --secret-permissions list --spn <prismacloud_app_id>
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. Select 'All services' > 'Key vaults'
3. Select the Key vault instance where the secrets are stored
4. Select 'Secrets', and select the secret that you need to modify
5. Select the current version
6. Set the expiration date
7. 'Save' your changes.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-key-vault-list' and json.rule = secrets[?any(attributes.exp equals -1 and attributes.enabled contains true)] exists and properties.enableRbacAuthorization is false```
Alibaba Cloud RAM password policy does not have an uppercase character
This policy identifies Alibaba Cloud accounts that do not have an uppercase character in the password policy. As a security best practice, configure a strong password policy for secure access to the Alibaba Cloud console.
This is applicable to alibaba_cloud cloud and is considered a medium 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 'Required Elements in Password' field, select 'Upper-Case Letter'
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 = 'requireUppercaseCharacters does not exist or requireUppercaseCharacters is false'```
GCP Log metric filter and alert does not exist for VPC network changes
This policy identifies the GCP account which does not have a log metric filter and alert for VPC network changes. Monitoring network insertion, patching, deletion, removePeering and addPeering activities will help in identifying VPC traffic flow is not getting impacted. It is recommended to create a metric filter and alarm to detect activities related to the insertion, patching, deletion, removePeering and addPeering of VPC network.
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="gce_network" AND jsonPayload.event_subtype="compute.networks.insert" OR jsonPayload.event_subtype="compute.networks.patch" OR jsonPayload.event_subtype="compute.networks.delete"  OR jsonPayload.event_subtype="compute.networks.removePeering" OR jsonPayload.event_subtype="compute.networks.addPeering"
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 "gce_network" and ($.X.filter contains "jsonPayload.event_subtype=" or $.X.filter contains "jsonPayload.event_subtype =") and ($.X.filter does not contain "jsonPayload.event_subtype!=" and $.X.filter does not contain "jsonPayload.event_subtype !=") and $.X.filter contains "compute.networks.insert" and $.X.filter contains "compute.networks.patch" and $.X.filter contains "compute.networks.delete" and $.X.filter contains "compute.networks.removePeering" and $.X.filter contains "compute.networks.addPeering"'; show X; count(X) less than 1```
AWS SNS Topic not encrypted by Customer Managed Key (CMK)
This policy identifies AWS SNS Topics that are not encrypted by Customer Managed Key (CMK).

AWS SNS Topics are used to send notifications to subscribers and might contain sensitive information. SNS Topics are encrypted by default by a 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 SNS Topics 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: 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 Amazon SNS Dashboard
4. Click on 'Topics'
5. Click on the reported Topic
6. Click on 'Edit' button from the console top menu to access the topic configuration settings.
7. Select the 'Encryption – optional', Ensure that Enable encryption option is selected.
8. Select the 'AWS KMS key' from the box other than default '(Default) alias/aws/sns' key based on your business requirement.
9. Choose 'Save changes' to apply the configuration changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-sns-get-topic-attributes' AND json.rule = KmsMasterKeyId exists and KmsMasterKeyId equal ignore case "alias/aws/sns"```
Azure Cosmos DB IP range filter not configured
This policy identifies Azure Cosmos DB with IP range filter not configured. Azure Cosmos DB should be restricted access from All Networks. It is recommended to add defined set of IP / IP range which can access Azure Cosmos DB from the Internet.
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. Go to Azure Cosmos DB
3. Select the reported Cosmos DB resource 
4. Click on 'Firewall and virtual networks' under 'Settings'
5. Click on 'Selected networks' radio button
6. Under 'Firewall' add IP ranges
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cosmos-db' AND json.rule = properties.ipRangeFilter is empty```
GCP Firewall rule allows inbound traffic from anywhere with no specific target set
This policy identifies GCP Firewall rules which allow inbound traffic from anywhere with no target filtering. 

The default target is all instances in the network. The use of target tags or target service accounts allows the rule to apply to select instances. Not using any firewall rule filtering may allow a bad actor to brute force their way into the system and potentially get access to the entire network.
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: Follow the instructions below to restrict the default target parameter (all instances in the network):

1. Login to GCP Console.
2. Go to VPC Network.
3. Go to the Firewall rules.
4. Click on each Firewall rule reported.
5. Click Edit.
6. Change the Targets field from 'All instances in the network' to 'Specified target tags' or 'Specified service account'.
7. Type the target tag/target service account into the Target tags/Target service account field respectively.
8. Review Source IP ranges and change to specific IP ranges if traffic is not required to be allowed from anywhere.
9. Click Save.

Reference:
https://cloud.google.com/vpc/docs/add-remove-network-tags.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name='gcloud-compute-firewall-rules-list' AND json.rule = 'disabled is false and direction equals INGRESS and allowed[*] exists and (sourceRanges[*] equals ::0 or sourceRanges[*] equals 0.0.0.0 or sourceRanges[*] equals 0.0.0.0/0 or sourceRanges[*] equals ::/0 or sourceRanges[*] equals ::) and targetTags[*] does not exist and targetServiceAccounts[*] does not exist'```
Informational - AWS access keys not used for more than 90 days
This policy identifies IAM users for which access keys are not used for more than 90 days. Access keys allow users programmatic access to resources. However, if any access key has not been used in the past 90 days, then that access key needs to be deleted (even though the access key is inactive).
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: To delete the reported AWS User access key follow below mentioned URL:
https://aws.amazon.com/premiumsupport/knowledge-center/delete-access-key/.

Query:
```config from cloud.resource where cloud.type ='aws' and api.name = 'aws-iam-get-credential-report' AND json.rule = '(access_key_1_active is true and ((access_key_1_last_used_date != N/A and _DateTime.ageInDays(access_key_1_last_used_date) > 90) or (access_key_1_last_used_date == N/A and access_key_1_last_rotated != N/A and _DateTime.ageInDays(access_key_1_last_rotated) > 90))) or (access_key_2_active is true and ((access_key_2_last_used_date != N/A and _DateTime.ageInDays(access_key_2_last_used_date) > 90) or (access_key_2_last_used_date == N/A and access_key_2_last_rotated != N/A and _DateTime.ageInDays(access_key_2_last_rotated) > 90)))'```
GCP Secrets Manager secret not encrypted with CMEK
This policy identifies GCP Secret Manager secrets that are not encrypted with a Customer-Managed Encryption Key (CMEK).

GCP Secret Manager securely stores and manages access to API keys, passwords, certificates, and other sensitive information. Using CMEK for secrets gives you complete control over the encryption keys protecting your sensitive data, ensuring that only authorized users with access to these keys can decrypt and access the information. Without CMEK, data is encrypted with Google-managed keys, which may not provide the level of control required for handling sensitive data in regulated industries.

It is recommended to encrypt Secret Manager secrets with a Customer-Managed Encryption Key (CMEK) for enhanced data control and compliance.
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. Sign in to the Google Cloud Management Console. Navigate to the 'Secrets Manager' page
2. Under 'Secrets', click on the reported secret
3. Select 'EDIT SECRET' on the top navigation bar
4. Under the 'Edit secret' page, under 'Encryption', select the 'Customer-managed encryption key (CMEK)' radio button and Select a CMEK key for each location
5. Click on 'UPDATE SECRET'..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-secretsmanager-secret' AND json.rule = replication.userManaged.replicas[*].customerManagedEncryption.kmsKeyName does not exist and replication.automatic.customerManagedEncryption.kmsKeyName does not exist```