knarayan/cloud_posture_checks huggingface dataset:
GCP Organization not configured with essential contacts

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

Query:
```config from cloud.resource where api.name = 'gcloud-essential-contacts-organization-contact' AND json.rule = notificationCategorySubscriptions[] contains "ALL" or (notificationCategorySubscriptions[] contains "LEGAL" and notificationCategorySubscriptions[] contains "SECURITY" and notificationCategorySubscriptions[] contains "SUSPENSION" and notificationCategorySubscriptions[] contains "TECHNICAL" and notificationCategorySubscriptions[] contains "TECHNICAL_INCIDENTS") as X; count(X) less than 1```
chao test change saved search

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-activity-log-alerts' AND json.rule = "location equal ignore case Global and properties.enabled equals true and properties.scopes[*] does not contain resourceGroups and properties.condition.allOf[?(@.field=='operationName')].equals equals Microsoft.Network/networkSecurityGroups/securityRules/delete" as X; count(X) less than 1```
OCI Event Rule and Notification does not exist for Identity Provider Group (IdP) group mapping changes
This policy identifies the OCI compartments which do not have an Event Rule and Notification that gets triggered for Identity Provider Group Mappings (IdP) changes. Monitoring and alerting on changes to IdP group mapping will help in identifying changes to the security posture. It is recommended that an Event Rule and Notification be configured to catch changes made to Identity Provider Group Mappings (IdP).
NOTE: 
1. Event Rules are compartment scoped and will detect events in child compartments, it is recommended to create the Event rule at the root compartment level.
2. This policy will trigger alert if you have at least one Event Rule and Notification, even if OCI has single or multi compartments.
This is applicable to oci 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 OCI Console
2. Type the Event into the Search box at the top of the Console.
3. Click the Event Service from the Services submenu
4. Select the compartment that should host the rule
5. Click Create Rule
6. Provide a Display Name and Description
7. Create a Rule Condition by selecting Identity in the Service Name Drop-down and selecting Idp Group Mapping – Create, Idp Group Mapping – Delete and Idp Group Mapping – Update
8. In the Actions section select Notifications as Action Type
9. Select the Compartment that hosts the Topic to be used.
10. Select the Topic to be used
11. Optionally add Tags to the Rule
12. Click Create Rule.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-events-rule' AND json.rule = '(isEnabled equals true) and (actions.actions[?any( actionType equals ONS and isEnabled equals true and lifecycleState equals ACTIVE)] exists) and (condition.eventType[*] contains com.oraclecloud.identitycontrolplane.createidpgroupmapping and condition.eventType[*] contains com.oraclecloud.identitycontrolplane.deleteidpgroupmapping and condition.eventType[*] contains com.oraclecloud.identitycontrolplane.updateidpgroupmapping) and actions.actions[*].topicId exists' as X; count(X) less than 1```
OCI Network Security Groups (NSG) has stateful security rules
This policy identifies the OCI Network Security Groups (NSG) security rules that have stateful ingress rules configured. It is recommended that Network Security Groups (NSG) security rules are configured with stateless ingress rules to slow the impact of a denial-of-service (DoS) attack.
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: 1. Login to the OCI Console
2. Type the resource reported in the alert into the Search box at the top of the Console.
3. Click the resource reported in the alert from the Resources submenu
4. Select the security rule from Security rules pane where Stateless is set to No and Direction set to Ingress
5. Click on Edit
6. Select the checkbox STATELESS
7. Click on Save Changes.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-networking-nsg' AND json.rule = securityRules[?any( direction equals INGRESS and (isStateless does not exist or isStateless is false) )] exists```
build information

This is applicable to azure cloud and is considered a informational 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-mysql-server' AND json.rule = properties.userVisibleState equal ignore case Ready and properties.privateEndpointConnections[*] is empty```
dnd_test_create_hyperion_policy_attack_path_policy_as_child_policies_ss_finding_1
Description-49e9b494-9bab-4e02-ad26-c6ac7731d570
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['SSH_BRUTE_FORCE'].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = defaultRootObject is empty```
AWS Default VPC is being used
This policy identifies AWS Default VPCs that are being used.

AWS creates a default VPC automatically upon the creation of your AWS account with a default security group and network access control list (NACL). Using AWS default VPC can lead to limited customization and security concerns due to shared resources and potential misconfigurations, hindering scalability and optimal resource management.

As a best practice, using a custom VPC with specific security and network configuration provides greater flexibility and control over your architecture.
This is applicable to aws cloud and is considered a critical severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: It is recommended to remove association with the default VPC and create a new custom VPC configuration based on your security and networking requirements, and associate the resource back to a newly created custom VPC.

To create a new VPC, follow below URL:
https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html

To remove the default VPC, follow below URL:
https://docs.aws.amazon.com/vpc/latest/userguide/delete-vpc.html

NOTE: Before any modification identify and analyze the potential results of a change in the environment..

Query:
```config from cloud.resource where api.name = 'aws-ec2-describe-vpcs' AND json.rule = default is true and shared is false and state equal ignore case available as X; config from cloud.resource where api.name = 'aws-ec2-describe-network-interfaces' AND json.rule = status equal ignore case in-use as Y; filter '$.X.vpcId equals $.Y.vpcId'; show X;```
GCP PostgreSQL instance database flag log_min_duration_statement is not set to -1
This policy identifies PostgreSQL database instances in which database flag log_min_duration_statement is not set to -1. The log_min_duration_statement flag defines the minimum amount of execution time of a statement in milliseconds where the total duration of the statement is logged. Logging SQL statements may include sensitive information that should not be recorded in logs. So it is recommended to set  log_min_duration_statement flag value to -1 so that execution statements logging will be disabled.
This is applicable to gcp cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to GCP console
2. Navigate SQL Instances page
3. Click on reported PostgreSQL instance
4. Click EDIT
NOTE: If the instance is stopped, You need to START instance first to edit the configurations, then Click on EDIT.
5. If the flag has not been set on the instance, 
Under 'Configuration options', click on 'Add item' in 'Flags' section, choose the flag 'log_min_duration_statement' from the drop-down menu and set the value as '-1'
OR
If the flag has been set to other than -1, Under 'Configuration options', In 'Flags' section choose the flag 'log_min_duration_statement' and set the value as '-1'
6. Click Save.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = "databaseVersion contains POSTGRES and (settings.databaseFlags[?(@.name=='log_min_duration_statement')] does not exist or settings.databaseFlags[?(@.name=='log_min_duration_statement')].value does not equal -1)"```
GCP Cloud DNS zones using RSASHA1 algorithm for DNSSEC zone-signing
This policy identifies the GCP Cloud DNS zones which are using the RSASHA1 algorithm for DNSSEC zone-signing. DNSSEC is a feature of the Domain Name System that authenticates responses to domain name lookups and also prevents attackers from manipulating or poisoning the responses to DNS requests. So the algorithm used for key signing should be recommended one and it should not be weak.
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: Currently, DNSSEC zone-signing can be updated using command line interface only.
1. If you need to change the settings for a managed zone where it has been enabled, you have to turn DNSSEC off and then re-enable it with different settings. To turn off DNSSEC, run following command:
gcloud dns managed-zones update <ZONE_NAME> --dnssec-state off
2. To update zone-signing for a reported managed DNS Zone, run following command:
gcloud dns managed-zones update <ZONE_NAME> --dnssec-state on --ksk-algorithm <KSK_ALGORITHM> --ksk-key-length <KSK_KEY_LENGTH> --zsk-algorithm <ZSK_ALGORITHM> --zsk-key-length <ZSK_KEY_LENGTH> --denial-of-existence <DENIAL_OF_EXISTENCE>.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-dns-managed-zone' AND json.rule = 'dnssecConfig.defaultKeySpecs[*].keyType contains zoneSigning and dnssecConfig.defaultKeySpecs[*].algorithm contains rsasha1'```
AWS EMR cluster is not configured with CSE CMK for data at rest encryption (Amazon S3 with EMRFS)
This policy identifies EMR clusters which are not configured with Client Side Encryption with Customer Master Keys(CSE CMK) for data at rest encryption of Amazon S3 with EMRFS. As a best practice, use Customer Master Keys (CMK) 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 informational 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 'CSE-Custom'. 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 CSE) and ($.Y.EncryptionConfiguration.AtRestEncryptionConfiguration.S3EncryptionConfiguration.EncryptionMode does not contain Custom)' ; show X;```