knarayan/cloud_posture_checks huggingface dataset:
GCP Storage Bucket storing GCP Vertex AI pipeline output data
This policy identifies publicly exposed GCS buckets that are used to store GCP Vertex AI pipeline output data.

GCP Vertex AI pipeline output data is stored in the Storage Bucket. This output data is considered sensitive and confidential intellectual property and its storage location should be checked regularly. The storage location should be as per the organization's security and compliance requirements.

It is recommended to monitor, identify, and evaluate storage location for GCP Vertex AI pipeline output data regularly to prevent unauthorized access and AI model thefts.
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: Review and validate the GCP Vertex AI pipeline output data is stored in the right Storage bucket. Move and/or delete the output data if it is found in an unexpected location. Review how the Vertex AI pipeline was configured to output to an unauthorised/unapproved storage bucket..

Query:
```config from cloud.resource where api.name = 'gcloud-storage-buckets-list' as X; config from cloud.resource where api.name = 'gcloud-vertex-ai-aiplatform-pipeline-job' as Y; filter ' $.Y.runtimeConfig.gcsOutputDirectory contains $.X.id '; show X;```
IBM Cloud OS disk is not encrypted with customer managed keys
This policy identifies IBM Cloud OS disk attached to a virtual server instance which are not encrypted with customer managed keys. As a best practice, use customer managed keys to encrypt the data and maintain control of your keys and sensitive data.
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: A os disk(boot storage volume) can be encrypted with customer managed keys only at the time of creation of virtual server instance. Please
create a snapshot for reported os data disk following below url:
https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-create&interface=ui#snapshots-vpc-create-from-vol-details

Please create a virtual service instance with os disk from the above created snapshot with customer managed encryption:
https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-restore&interface=ui#snapshots-vpc-restore-vol-ui

Once new virtual server instance got created, delete the virtual server instance to which reported os disk got attached:
https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-remove_vs#delete_vs

Note: Please note deleting a virtual server instance is irreversible make sure to backup any required data..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-block-storage-volume' AND json.rule = volume_attachments[*] size greater than 0 and volume_attachments[*].type equals boot and encryption equal ignore case provider_managed```
Azure Log Analytics workspace configured with overly permissive network access
This policy identifies Log Analytics workspaces configured with overly permissive network access.

Virtual networks access configuration in Log Analytics workspace allows you to restrict data ingestion and queries coming from the public networks.

It is recommended to configure the Log Analytics workspace with virtual networks access configuration set to restrict, so that the Log Analytics workspace is accessible only to restricted Azure Monitor Private Link Scopes.
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: 1. Log in to Azure Portal
2. Go to Log Analytics workspaces dashboard 
3. Click on the reported Log Analytics workspace
4. Under the 'Settings' menu, click on 'Network Isolation'
5. Create a Azure Monitor Private Link Scope if it is not already created by refering:
https://docs.microsoft.com/en-us/azure/azure-monitor/logs/private-link-configure#create-an-azure-monitor-private-link-scope
6. After creating, Under 'Virtual networks access configuration', 
Set 'Accept data ingestion from public networks not connected through a Private Link Scope' to 'No' and 
Set 'Accept queries from public networks not connected through a Private Link Scope' to 'No'
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-log-analytics-workspace' AND json.rule = properties.provisioningState equals Succeeded and (properties.publicNetworkAccessForQuery equals Enabled or properties.publicNetworkAccessForIngestion equals Enabled)```
Izabella  config with tags test 1

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 = tags[*] exists```
Azure Virtual Desktop workspace diagnostic log is disabled
This policy identifies Azure Virtual Desktop workspaces where diagnostic logs are not enabled.

Diagnostic logs are vital for monitoring and troubleshooting Azure Virtual Desktop, which offers virtual desktops and remote app services. They help detect and resolve issues, optimize performance, and meet security and compliance standards. Without these logs, it’s difficult to track activities and detect anomalies, potentially jeopardizing security and efficiency.

As a best practice, it is recommended to enable diagnostic logs for Azure Virtual Desktop workspaces.
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 Azure Portal and search for 'Azure Virtual Desktop'
2. Select 'Azure Virtual Desktop'
3. Under 'Manage' select 'Workspaces'
4. Select the reported Workspace
5. Under 'Monitoring' select 'Diagnostic settings'
6. Under Diagnostic settings tab. Click on '+ Add diagnostic setting' to create a new Diagnostic Setting
7. Specify a 'Diagnostic settings name'
8. Under section 'Categories', select the type of log that you want to enable
9. Under section 'Destination details'
  a. If you select 'Send to Log Analytics', select the 'Subscription' and 'Log Analytics workspace'
  b. If you set 'Archive to storage account', select the 'Subscription' and 'Storage account'
  c. If you set 'Stream to an event hub', select the 'Subscription', 'Event hub namespace', 'Event hub name' and set the 'Event hub policy name'
10. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-virtual-desktop-workspace' AND json.rule = diagnostic-settings[?none( properties.logs[?any( enabled is true )] exists )] exists```
Azure Microsoft Defender for Cloud security alert email notifications is not set
This policy identifies the Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) which have not set security alert email notifications. Enabling security alert emails ensures that security alert emails are received from Microsoft. This ensures that the right people are aware of any potential security issues and are able to mitigate the risk.
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. Click on 'Email notifications'
6. Under 'Notification types', check the check box next to Notify about alerts with the following severity (or higher): and select High from the drop down menu
7. Select 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = (securityContacts is empty or securityContacts[?any(properties.email is empty and alertNotifications equal ignore case Off)] exists) and pricings[?any(properties.pricingTier equal ignore case Standard)] exists```
Azure Storage account encryption key is not rotated regularly
This policy identifies Azure Storage accounts which are encrypted by an encryption key that is not rotated regularly. As a security best practice, it is important to rotate the keys periodically so that if the keys are compromised, the data in the underlying service is still secure with the new keys.
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: To configure Stroage account encryption key rotation; refer below URL:
https://learn.microsoft.com/en-us/azure/storage/common/customer-managed-keys-configure-existing-account?tabs=azure-portal#configure-encryption-for-automatic-updating-of-key-versions

NOTE: Azure Storage checks the key vault for a new key version only once daily. When you rotate a key, be sure to wait 24 hours before disabling the older version..

Query:
```config from cloud.resource where api.name = 'azure-storage-account-list' AND json.rule = properties.encryption.keySource equal ignore case "Microsoft.Keyvault" as X; config from cloud.resource where api.name = 'azure-key-vault-list' and json.rule = keys[?any(attributes.exp equals -1 and attributes.enabled contains true)] exists as Y; filter '$.Y.properties.vaultUri contains $.X.properties.encryption.keyvaultproperties.keyvaulturi'; show X;```
dnd_test_create_hyperion_policy_ss_finding_1
Description-d63012c8-3c89-4ac2-ac4f-6c6523921d5f
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 Aurora PostgreSQL exposed to local file read vulnerability
This policy identifies AWS Aurora PostgreSQL which are exposed to local file read vulnerability. AWS Aurora PostgreSQL installed with vulnerable 'log_fdw' extension is exposed to local file read vulnerability, due to which attacker could gain access to local system files of the database instance within their account, including a file which contained credentials specific to Aurora PostgreSQL. It is highly recommended to upgrade AWS Aurora PostgreSQL to the latest version.

For more information,
https://aws.amazon.com/security/security-bulletins/AWS-2022-004/
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: Amazon has deprecated affected versions of Aurora PostgreSQL and customers can no longer create new instances with the affected versions.

To upgrade the latest version of Amazon Aurora PostgreSQL, please follow below URL:
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.PostgreSQL.html
.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-rds-describe-db-instances' AND json.rule = dbinstanceStatus equals available and engine equals aurora-postgresql and engineVersion is member of ('10.11','10.12','10.13','11.6','11.7','11.8')```
AWS Kinesis Firehose with Direct PUT as source has SSE encryption disabled
This policy identifies Amazon Kinesis Firehose with Direct PUT as source which has Server-side encryption (SSE) encryption disabled. Enabling Server Side Encryption allows you to meet strict regulatory requirements and enhance the security of your data at rest. As a best practice, enable SSE for the Amazon Kinesis Firehose.
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. Sign in to the AWS Console
2. Go to Amazon Kinesis Service
3. Click on 'Delivery streams'
4. Select the reported Kinesis Firehose for the corresponding region
5. Click on 'Configuration' tab
6. Under Server-side encryption, Click on Edit
7. Choose 'Enable server-side encryption for source records in delivery stream'
8. Under 'Encryption type' select 'Use AWS owned CMK'
9. Click 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-kinesis-firehose-delivery-stream' AND json.rule = deliveryStreamEncryptionConfiguration exists and deliveryStreamEncryptionConfiguration.status equals DISABLED```
OCI Compute Instance with Secure Boot disabled
This policy identifies OCI compute instances in which Secure Boot is disabled.

Secure Boot serves as a security standard ensuring that a machine exclusively boots using Original Equipment Manufacturer (OEM) trusted software. Without the activation of Secure Boot, a compute instance becomes susceptible to booting unauthorized or malicious software, posing a threat to the integrity and security of the instance. Consequently, this vulnerability can lead to unauthorized access, data breaches, or other malicious activities within the instance.

As a security best practice, enabling Secure Boot on all compute instances is strongly recommended to guarantee the exclusive execution of trusted software during the boot process.
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: Note: Secure Boot can only be enabled during resource creation. To fix this, you must terminate the reported instance and create a new one with Secure Boot enabled.

1. Log in to the OCI Console.
2. Switch to the Region of the reported resource from the Region drop-down in top-right corner.
3. Type the reported compute instance name into the Search box at the top of the Console.
4. Click on the reported compute instance from the search results.
5. Click 'Terminate' to terminate the instance (decide whether to permanently delete the instance's attached boot volume).
6. To recreate the compute instance with Secure Boot enabled, navigate to the instance creation page.
7. Click 'Create Instance'.
8. In the 'Image and Shape' section, select an Image and Shape that support Shielded Instance configuration, indicated by the shield icon.
9. In the 'Security' section, click 'Edit'.
10. Enable 'Shielded Instance', then activate the 'Secure Boot' toggle.
11. Complete the remaining details as required.
12. Click 'Create'..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-compute-instance' AND json.rule = lifecycleState equal ignore case running AND (platformConfig does not exist OR platformConfig equal ignore case "null" OR platformConfig.isSecureBootEnabled is false)```
pcsup-aws-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' AND resource.status = Active AND json.rule = tags[*].key none equal "application" AND tags[*].key none equal "Application"```
GCP Cloud Function not enabled with VPC connector for network egress
This policy identifies GCP Cloud Functions that are not enabled with a VPC connector for network egress. This includes both Cloud Functions v1 and Cloud Functions v2.

Using a VPC connector for network egress in GCP Cloud Functions is crucial to prevent security risks such as data interception and unauthorized access. This practice strengthens security by allowing safe communication with private resources, enhancing traffic monitoring, reducing the risk of data leaks, and ensuring compliance with security policies.

Note: For a Cloud Function to access public traffic using Serverless VPC Connector, Cloud NAT might be needed.
Link: https://cloud.google.com/functions/docs/networking/network-settings#route-egress-to-vpc

It is recommended to configure GCP Cloud Functions with a VPC connector.
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 'Cloud Functions' service
3. Click on the alerting function
4. Click on 'EDIT'
5. Click on 'Runtime, build, connections and security settings’ drop-down to get the detailed view
6. Click on the 'CONNECTIONS' tab
7. Under Section 'Egress settings', select a VPC connector from the dropdown
8. In case VPC connector is not available, either select 'Custom' and provide the name of the VPC Connector manually or click on 'Create a Serverless VPC Connector' and follow the link to create a Serverless VPC connector: https://cloud.google.com/vpc/docs/configure-serverless-vpc-access
9. Once the Serverless VPC connector is available, select it from the dropdown
10. Select 'Route only requests to private IPs through the VPC connector' or 'Route all traffic through the VPC connector' as per your organization's policies.
10. Click on 'NEXT'
11. Click on 'DEPLOY'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-cloud-function-v2' AND json.rule = state equals ACTIVE and serviceConfig.vpcConnector does not exist```
Alibaba Cloud ECS instance that has a public IP address and is attached to a security group with internet access
This policy identifies ECS instances that have a public IP address and are attached to security groups with internet access. Because an ECS instance receives a public IP address at the launch, by default, as a best practice ensure that the instance is attached to a security group which is not overly permissive.
This is applicable to alibaba_cloud 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: Instead of using a public IP address for the ECS instance, either associate an Elastic IP address to it or evaluate the rules for the security groups to ensure restricted access.

To allocate an Elastic IP address, follow the instructions below:
1. Log in to Alibaba Cloud Portal
2. Go to Elastic Compute Service
3. Select the reported ECS instance
4. Choose More > Network and Security Group > Convert to EIP
5. On 'Convert to EIP' popup window, click on 'OK'

To restrict Security Groups allowing all traffic, follow the instructions below:
1. Log in to Alibaba Cloud Portal
2. Go to Elastic Compute Service
3. Click on the reported ECS instance
3. In the left-side navigation pane, choose Security Groups
4. Check the rules of each security group by clicking on 'Add Rules' in the Actions column
5. In Inbound tab, Select the rule having 'Action' as Allow and 'Authorization Object' as 0.0.0.0/0, 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 api.name = 'alibaba-cloud-ecs-instance' as X; config from cloud.resource where api.name = 'alibaba-cloud-ecs-security-group' as Y; filter "$.X.publicIpAddress[*] is not empty and $.X.securityGroupIds[*] contains $.Y.securityGroupId and $.Y.permissions[?(@.policy=='Accept' && @.direction=='ingress')].sourceCidrIp contains 0.0.0.0/0"; show X;```
Chao Copy of Critical - AWS S3 Object Versioning is disabled
This policy identifies the S3 buckets which have Object Versioning disabled. S3 Object Versioning is an important capability in protecting your data within a bucket. Once you enable Object Versioning, you cannot remove it; you can suspend Object Versioning at any time on a bucket if you do not wish for it to persist. It is recommended to enable Object Versioning on S3.
This is applicable to aws cloud and is considered a critical severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. Log into your AWS Console and select the S3 service.
2. Choose the reported S3 bucket and click the Properties tab in the upper right frame.
3. Expand the Versioning option
4. Click Enable Versioning
5. Click Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = 'versioningConfiguration.status!=Enabled'```
AWS root account activity detected in last 14 days
This policy identifies if AWS root account activity was detected within the last 14 days.

The AWS root account user is the primary administrative identity associated with an AWS account, providing complete access to all AWS services and resources. Since the root user has complete access to the account, adopting the principle of least privilege is important to lower the risk of unintentional disclosure of highly privileged credentials and inadvertent alterations. It's also advised to remove the root user access keys and restrict the use of the root user, refraining from using them for routine or administrative duties.

It is recommended to restrict the use of the AWS root account.
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: If any access keys are created for the root account, please delete the keys using the following steps:

1. Sign in to AWS Console as the root user.
2. Click the root account name and on the top right select  'Security Credentials' from the dropdown.
3. For each key in 'Access Keys', click on 'X' to delete the keys.

Limiting root user console access as much as feasible is advised..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-credential-report' AND json.rule = 'user equals "<root_account>" and ( _DateTime.ageInDays(access_key_1_last_used_date) < 14 or _DateTime.ageInDays(access_key_2_last_used_date) < 14 or _DateTime.ageInDays(password_last_used) < 14 )'```