knarayan/cloud_posture_checks huggingface dataset:
GCP Cloud DNS has DNSSEC disabled
This policy identifies GCP Cloud DNS which has DNSSEC disabled. Domain Name System Security Extensions (DNSSEC) adds security to the Domain Name System (DNS) protocol by enabling DNS responses to be validated. Attackers can hijack the process of domain/IP lookup and redirect users to a malicious site through DNS hijacking and man-in-the-middle attacks. DNSSEC helps mitigate the risk of such attacks by cryptographically signing DNS records. As a result, it prevents attackers from issuing fake DNS responses that may misdirect browsers to fake websites.
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: 1. Login to GCP portal 
2. Go to Network services
3. Choose Cloud DNS
4. Click on reported Cloud DNS / Zone name
5. Under 'DNSSEC' column choose 'On' from the drop-down.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-dns-managed-zone' AND json.rule = '(dnssecConfig.state does not exist or dnssecConfig.state equals off) and visibility equals public'```
AWS Elasticsearch domain has Index slow logs set to disabled
This policy identifies Elasticsearch domains for which Index slow logs is disabled in your AWS account. Enabling support for publishing indexing slow logs to AWS CloudWatch Logs enables you have full insight into the performance of indexing operations performed on your Elasticsearch clusters. This will help you in identifying performance issues caused by specific queries or due to changes in cluster usage, so that you can optimize your index configuration 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 Index 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 Index 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.INDEX_SLOW_LOGS.enabled is false or logPublishingOptions.INDEX_SLOW_LOGS.cloudWatchLogsLogGroupArn is empty)'```
IBM Cloud Secrets Manager has expired user credentials
This policy identifies IBM Cloud Secrets Manager user credential which is expired. User credentials should be rotated to ensure that data cannot be accessed with an old secret which might have been lost, cracked, or stolen. It is recommended that all user credentials are set with expiration date and expired secrets should be regularly rotated.
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: If the IBM Cloud Secrets Manager user credentials secret is expired, secret needs to be deleted.
Please use below URL as reference:
https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-delete-secrets&interface=ui#delete-secret-ui

If the IBM Cloud Secrets Manager user credentials is about to be expired, secret has to be rotated.
Please use below URL as reference:
https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manual-rotation&interface=ui#manual-rotate-user-credentials-ui

Please make sure to set an expiration date for each secret. Please follow the below steps to set an expiration date:
1. Log in to the IBM Cloud Console
2. Click on Menu Icon and navigate to 'Resource list', from the list of resources select secret manager instance in which reported secret resides, under security section.
3. Select the secret.
4. Under 'Expiration date' section, provide expiration date as required.
5. Click on 'Update'..

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 (expiration_date does not exist or (_DateTime.ageInDays(expiration_date) > -1))'```
Azure SQL Servers Firewall rule allow access to all IPV4 address
This policy identifies Azure SQL Servers which has Firewall rule that allow access to all IPV4 address. Having a firewall rule with start IP being 0.0.0.0 and end IP being 255.255.255.255 would allow access to SQL server from any host on the internet. It is highly recommended not to use this type of firewall rule in any SQL servers.
This is applicable to azure 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: 1. Log in to Azure Portal
2. Navigate to the 'SQL servers' dashboard
4. Click on the reported SQL server
5. Click on 'Networking' under Security
6. In 'Public access' tab, Under Firewall rules, Delete the rule which has 'Start IP' as 0.0.0.0 and 'End IP' as 255.255.255.255
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-sql-server-list' AND json.rule = ['sqlServer'].['properties.publicNetworkAccess'] equal ignore case Enabled and firewallRules[?any(startIpAddress equals "0.0.0.0" and endIpAddress equals "255.255.255.255")] exists```
GCP VM disks not encrypted with Customer-Supplied Encryption Keys (CSEK)
This policy identifies VM disks which are not encrypted with Customer-Supplied Encryption Keys (CSEK). If you provide your own encryption keys, Compute Engine uses your key to protect the Google-generated keys used to encrypt and decrypt your data. It is recommended to use VM disks encrypted with CSEK for business-critical VM instances. 
Limitation: This policy might give false negatives in case VM disks are created with name prefix 'gke-'.
This is applicable to gcp 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: Currently, we can not update the encryption of an existing disk. So to fix this alert, Create a new VM disk with Encryption set to Customer supplied, migrate all required data from reported VM disk to newly created disk and delete the reported VM disk.

1. Login to GCP Portal
2. Go to Compute Engine
3. Go to Disks
4. Click on Create a disk
5. Specify other disk parameters as you desire
6. Set Encryption to Customer-supplied key
7. Provide the Key in the box
8. Select Wrapped key
9. Click on Create.

Query:
```config from cloud.resource where api.name = 'gcp-compute-disk-list' AND json.rule = status equals READY and name does not start with "gke-" and diskEncryptionKey.sha256 does not exist```
OCI Autonomous Database not registered in Data Safe
This policy identifies Oracle Autonomous Databases that are not registered in Oracle Data Safe.

Oracle Data Safe is a fully-integrated cloud service that focuses on the security of your data, providing comprehensive features for protecting sensitive and regulated information in Oracle databases. Through the Security Center, you can access functionalities such as user and security assessments, data discovery, data masking, activity auditing, and alerts.

As best practice, it is recommended to register the Autonomous Database in Data Safe.
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: To configure the OCI Autonomous Database with datasafe, refer to the following documentation:
https://docs.oracle.com/en/cloud/paas/data-safe/admds/register-autonomous-database.html#GUID-19A85842-A81C-4F40-A1EE-13C40EA845F0
or
https://docs.oracle.com/en-us/iaas/tools/oci-cli/3.43.2/oci_cli_docs/cmdref/db/autonomous-database/data-safe/register.html.

Query:
```config from cloud.resource where api.name = 'oci-database-autonomous-database' AND json.rule = lifecycleState equal ignore case AVAILABLE and dataSafeStatus does not equal ignore case REGISTERED```
AWS IAM group not in use
This policy identifies AWS IAM groups that are not actively in use. 

An AWS IAM group is a collection of IAM users managed together, allowing for unified permission assignment. These groups, if not assigned any users, pose a potential security risk if left unmanaged and can inadvertently grant unauthorized access to AWS services and resources. 

It is recommended to review and remove any unused IAM groups to prevent attaching unauthorized IAM users.
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 delete an IAM user group (console)

1. Sign in to the AWS Management Console
2. Navigate to the 'Services' menu and, within the 'Security, Identity, & Compliance' category, choose the 'IAM' service to open the IAM console
3. In the IAM console's navigation pane, select 'User groups' located under the 'Access management' section
4. In the list of user groups, select the check box next to the name of the reported user group to delete. You can use the search box to filter the list of user group name.
5. Choose 'Delete' to delete the group
6. In the confirmation box, If you want to delete user groups, type 'delete' and choose 'Delete'.

Query:
```config from cloud.resource where api.name = 'aws-iam-list-groups' as X; config from cloud.resource where api.name = 'aws-iam-list-users' as Y; filter ' not ($.Y.groupList[*] intersects  $.X.groupName)'; show X;```
GCP Storage Buckets with publicly accessible GCP logs
Checks to ensure that Stackdriver logs on Storage Buckets are not  Giving public access to Stackdriver logs will enable anyone with a web association to retrieve sensitive information that is critical to business. Stackdriver Logging enables to store, search, investigate, monitor and alert on log information/events from Google Cloud Platform. The permission needs to be set only for authorized users.
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 set an ACL, please refer to the URL given below. Make sure that no ACL is set to allow 'allUsers' or 'allAuthenticatedUsers' for the reported bucket.
https://cloud.google.com/storage/docs/access-control/create-manage-lists#set-an-acl.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-storage-buckets-list' AND json.rule = '($.acl[*].email exists and $.acl[*].email contains logging) and ($.acl[*].entity contains allUsers or $.acl[*].entity contains allAuthenticatedUsers)'```
Azure Microsoft Defender for Cloud security configurations 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 security configurations monitoring set to disabled. Security configurations will enable the daily analysis of operating system configurations. The rules for hardening the operating system like firewall rules, password and audit policies are reviewed. Recommendations are made for setting the right level of security controls.
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 'Vulnerabilities in security configuration on your machines should be remediated' 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.systemConfigurationsMonitoringEffect.value equals Disabled) or (name == SecurityCenterBuiltIn and properties.parameters[*] is empty and properties.displayName does not start with "ASC Default"))'```
Venu Test

This is applicable to aws 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 = 'aws-ec2-describe-instances' AND json.rule = clientToken is not empty AND monitoring.state contains "running"```
AWS FSx for OpenZFS file systems not configured to copy tags to backups or volumes
This policy identifies the AWS FSx for OpenZFS file system is configured to copy tags to backups or volumes.

AWS FSx for OpenZFS is a managed service for deploying and scaling OpenZFS file systems on AWS. Tags make resource identification and management easier, ensuring consistent security policies across file systems. Without copying tags to backups and volumes in AWS FSx for OpenZFS, enforcing consistent access control and tracking sensitive data in these resources becomes challenging.

It is recommended to configure an FSx for the OpenZFS file system to copy tags to backups and volumes.
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 configure an  AWS FSx for OpenZFS file system to copy tags to backups and volumes, perform following actions:

1. Sign in to your AWS account and Open the Amazon FSx console.
2. In the left navigation pane, choose 'File systems', and then choose the FSx for OpenZFS file system that is reported.
3. For 'Actions', choose 'Update tags preferences'. The Update tags preferences dialog box displays.
4. For 'Copy tags to backups', select 'Enabled' to copy tags from the file system to any backup thats taken.
5. For 'Copy tags to volumes', select 'Enabled' to copy tags from the file system to any volume that you create.
6. Choose Update to update the file system with your changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-fsx-file-system' AND json.rule = FileSystemType equals "OPENZFS" and Lifecycle equals "AVAILABLE" and (OpenZFSConfiguration.CopyTagsToBackups is false or OpenZFSConfiguration.CopyTagsToVolumes is false )```
Azure Network Security Group allows all traffic on NetBIOS DNS (UDP Port 53)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on DNS UDP port 53. Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict DNS solely to known static IP addresses. Limit the access list to include known hosts, services, or specific employees only.
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: 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 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(access equals Allow and direction equals Inbound and (sourceAddressPrefix equals Internet or sourceAddressPrefix equals * or sourceAddressPrefix equals 0.0.0.0/0 or sourceAddressPrefix equals ::/0) and (protocol equals Udp or protocol equals *) and (destinationPortRange contains _Port.inRange(53,53) or destinationPortRanges[*] contains _Port.inRange(53,53) ))] exists```
IBM Cloud Multi-Factor Authentication (MFA) not enabled at the account level
This policy identifies IBM Cloud accounts where Multi-Factor Authentication (MFA) is not enabled at the account level. MFA adds an extra layer of protection on top of your user name and password and helps protect accounts from stolen, phished, or weak password exploits. Enabling IBM MFA at the account level is the recommended approach to protect users.
This is applicable to ibm cloud and is considered a medium severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: Follow the below mentioned URL to enable IBM MFA:

https://cloud.ibm.com/docs/account?topic=account-enablemfa#enabling.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-iam-identity-account-setting' AND json.rule = mfa equal ignore case "NONE"```
OCI Database system is not configured with Network Security Groups
This policy identifies Oracle Cloud Infrastructure (OCI) Database Systems that are not configured with Network Security Groups (NSGs).

Network Security Groups provide granular security controls at the instance level, allowing for more precise management of inbound and outbound traffic to database systems.

It is recommended to configure database systems with NSGs to enhance their security thereby mitigating the risk of unauthorized access and potential data breaches.
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: To manage Network Security Groups for a DB System, follow below URL:
https://docs.oracle.com/en-us/iaas/base-database/doc/manage-network-security-groups-db-system.html

NOTE: Before you update DB Systems with Network security group, make sure you have a restrictive Network Security Group already created with only specific traffic ports based on requirement..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-oracledatabase-bmvm-dbsystem' AND json.rule = 'lifecycleState equals AVAILABLE and nsgIds contains null'```
Bobby Copy of AWS Access logging not enabled on S3 buckets
Checks for S3 buckets without access logging turned on. Access logging allows customers to view complete audit trail on sensitive workloads such as S3 buckets. It is recommended that Access logging is turned on for all S3 buckets to meet audit & compliance requirement
This is applicable to aws 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. Login to the AWS Console and navigate to the 'S3' service.
2. Click on the the S3 bucket that was reported.
3. Click on the 'Properties' tab.
4. Under the 'Server access logging' section, select 'Enable logging' option..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name='aws-s3api-get-bucket-acl' AND json.rule='loggingConfiguration.targetBucket equals null or loggingConfiguration.targetPrefix equals null'```
CNA customer
FASDFDSAF
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 cloud.type = 'gcp' AND api.name= 'gcloud-compute-instances-list' AND json.rule = (networkInterfaces[*].accessConfigs[*].type exists and networkInterfaces[*].accessConfigs[*].type contains "ONE_TO_ONE_NAT") and (labels.goog-composer-environment does not exist and tags.items[*] does not contain "dataflow") and (metadata.items[*].key does not equal "nat" and metadata.items[*].value does not equal "TRUE") and (name does not contain "paloALTO")```
IBM Cloud Secrets Manager certificate not configured with automatic rotation
This policy identifies IBM Cloud Secrets Manager certificates that are not configured with automatic rotation.

IBM Cloud Secrets Manager allows you to manage various types of certificates, including those from imported third-party certificate authorities, public certificates, and private certificates, providing a centralised platform for secure certificate storage and management. Securely storing and timely rotating certificates before expiration is crucial for maintaining a high security posture and avoiding any service disruptions.

It is recommended to set IBM Cloud Secrets Manager certificates with auto-rotation.
This is applicable to ibm 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 set a rotation policy for a certificate, follow the below steps:

1. Log in to the IBM Cloud Console
2. Click on the menu icon and navigate to 'Resource list', From the list of resources, select the secret manager instance in which the reported secret resides under the security section.
3. Select the secret.
4. Under the 'Rotation' tab, enable 'Automatic secret rotation'.
5. Set 'Rotation Interval' according to the requirements.
6. Click on 'Update'.

Note: Imported certificates cannot be set with an automatic rotation policy; they have to be re-imported before expiration..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-secret-manager-secret' AND json.rule = state_description equal ignore case active and secret_type is member of (private_cert, public_cert) and rotation.auto_rotate is false```
Azure Machine learning workspace configured with overly permissive network access
This policy identifies Machine learning workspaces configured with overly permissive network access. Overly permissive public network access allows access to resource through the internet using a public IP address. It is recommended to restrict IP ranges to allow access to your workspace and endpoint from specific public internet IP address ranges and is accessible only to restricted entities.
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 restrict internet IP ranges on your existing Machine learning workspace, follow the below URL:
https://learn.microsoft.com/en-us/azure/machine-learning/how-to-configure-private-link?view=azureml-api-2&tabs=azure-portal#enable-public-access-only-from-internet-ip-ranges-preview.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-machine-learning-workspace' AND json.rule = properties.provisioningState equal ignore case Succeeded and properties.publicNetworkAccess equal ignore case Enabled and (properties.ipAllowlist does not exist or properties.ipAllowlist is empty)```