knarayan/cloud_posture_checks huggingface dataset:
Medium of AWS S3 bucket publicly readable
This policy identifies the S3 buckets that are publicly readable by Get/Read/List bucket operations. These permissions permit anyone, malicious or not, to Get/Read/List bucket operations on your S3 bucket if they can guess the namespace. S3 service does not protect the namespace if ACLs and Bucket policy is not handled properly, with this configuration you may be at risk of compromise of critical data by leaving S3 public.

For more details:
https://docs.aws.amazon.com/AmazonS3/latest/user-guide/set-permissions.html
https://docs.aws.amazon.com/AmazonS3/latest/dev/about-object-ownership.html#ensure-object-ownership 
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: 1. Log in to the AWS Console
2. Navigate to the 'S3' service
3. Click on the S3 resource reported in the alert
4. Click on the 'Permissions' tab
5. If Access Control List is set to 'Public' follow the below steps
a. Under 'Access Control List', Click on 'Everyone' and uncheck all items
b. Click on Save changes
6. If 'Bucket Policy' is set to public follow the below steps
a. Under 'Bucket Policy', Select 'Edit Bucket Policy' and consider defining what explicit 'Principal' should have the ability to GET/LIST objects in your S3 bucket. You may also want to specifically limit the 'Principal' ability to perform specific GET/LIST functions, without the wild card.
If 'Bucket Policy' is not required delete the existing 'Bucket Policy'.
b. Click on Save changes

Note: Make sure updating 'Access Control List' or 'Bucket Policy' does not affect S3 bucket data access..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = ((((publicAccessBlockConfiguration.ignorePublicAcls is false and accountLevelPublicAccessBlockConfiguration does not exist) or (publicAccessBlockConfiguration does not exist and accountLevelPublicAccessBlockConfiguration.ignorePublicAcls is false) or (publicAccessBlockConfiguration.ignorePublicAcls is false and accountLevelPublicAccessBlockConfiguration.ignorePublicAcls is false)) and acl.grantsAsList[?any(grantee equals AllUsers and permission is member of (ReadAcp,Read,FullControl))] exists) or ((policyStatus.isPublic is true and ((publicAccessBlockConfiguration.restrictPublicBuckets is false and accountLevelPublicAccessBlockConfiguration does not exist) or (publicAccessBlockConfiguration does not exist and accountLevelPublicAccessBlockConfiguration.restrictPublicBuckets is false) or (publicAccessBlockConfiguration.restrictPublicBuckets is false and accountLevelPublicAccessBlockConfiguration.restrictPublicBuckets is false))) and (policy.Statement[?any(Effect equals Allow and (Principal equals * or Principal.AWS equals *) and (Action contains s3:* or Action contains s3:Get or Action contains s3:List) and (Condition does not exist))] exists))) and websiteConfiguration does not exist```
OCI Oracle Autonomous Database (ADB) access is not restricted to allowed sources or deployed within a Virtual Cloud Network
This policy identifies Oracle Autonomous Databases (ADBs) that are not restricted to specific sources or not deployed within a Virtual Cloud Network (VCN). 

Autonomous Database automates critical database management tasks, and restricting its access to corporate IP addresses or VCNs is crucial for enhancing security. Deploying Autonomous Databases within a VCN and configuring access control rules ensure that only authorized sources can connect, significantly reducing the risk of unauthorized access. This protection is vital for maintaining the integrity and security of the databases.

As best practice, it is recommended to have new Autonomous Database instances deployed within a VCN, and existing instances should have access control rules set to restrict connectivity to approved sources.
This is applicable to oci cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: To configure the OCI Oracle Autonomous Database (ADB) access, refer to the following documentation:
https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/access-control-rules-autonomous.html#GUID-F0B59281-E545-48B1-BA49-1FD51B65D123.

Query:
```config from cloud.resource where api.name = 'oci-database-autonomous-database' AND json.rule = lifecycleState contains AVAILABLE AND whitelistedIps is member of ("null") AND privateEndpoint is member of ("null")```
aweawoie

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-kubernetes-cluster' AND json.rule = properties.powerState.code equal ignore case Running and properties.apiServerAccessProfile.enablePrivateCluster is false and (properties.apiServerAccessProfile.authorizedIPRanges does not exist or properties.apiServerAccessProfile.authorizedIPRanges is empty)```
AWS MQ is publicly accessible
This policy identifies the AWS MQ brokers which are publicly accessible. It is advisable to use MQ brokers privately only from within your AWS Virtual Private Cloud (VPC). Ensure that the AWS MQ brokers provisioned in your AWS account are not publicly accessible from the Internet to avoid sensitive data exposure and minimize security risks. 
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: Note: MQ broker configuration for public access cannot be modified. In case we need to update the MQ not to be public we need to recreate it.

1. Go to AWS console
2. Navigate to service 'Amazon MQ' from the 'Services' Menu
3. From the list of 'Brokers' select the reported MQ broker
4. From 'Details' section, copy all the configuration information.
5. Within 'Users' section, locate and copy the ActiveMQ Web Console access credentials.
6. Click on 'Brokers' from left panel, click on 'Create broker' 
7. Provide an unique name in field 'Broker name'
8. In 'Advanced settings' section, select 'No' for 'Public accessibility'
9. Set the new broker configuration parameters using the information copied at step no. 4
10. Set the existing ActiveMQ Web Console access credentials copied at step no. 5
11. Click on 'Create broker'
12. Once the new broker is created, you can replace the broker endpoints within your applications

To delete the publicly accessible broker, 
1. select the alerted from the list of 'Brokers' 
2. Click on 'Delete' button
3. When a dialog box pops up, enter the broker name to confirm and click on 'delete' button.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-mq-broker' AND json.rule = 'brokerState equals RUNNING and publiclyAccessible is true'```
API automation policy vwptv

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 = architecture contains "foo"```
GCP Secrets Manager secret has no expiration date
This policy identifies GCP Secret Manager secrets that have no expiration date.

GCP Secret Manager securely stores and controls access to API keys, passwords, certificates, and other sensitive data. Without an expiration date, secrets remain vulnerable indefinitely. Setting an expiration date limits the potential damage of a security breach, as compromised credentials will eventually become invalid.

It is recommended to configure secrets with an expiration date to reduce the risk of long-lived secrets being compromised or abused.
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 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 'Expiration', select the 'Set expiration date' checkbox and set the date and time for expiration
5. Click on 'UPDATE SECRET'..

Query:
```config from cloud.resource where cloud.type = 'gcp' and api.name = 'gcloud-secretsmanager-secret' AND json.rule = expireTime does not exist```
dnd_test_create_hyperion_policy_without_asset_type_finding_1
Description-bf90f2fb-d709-4040-a033-b74ef4a2f6d8
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```
comcast-policy

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-network-nsg-list' AND json.rule = securityRules[?any(access equals Allow and direction equals Inbound and (sourceAddressPrefix does not equal 96.116.133.104/32 or sourceAddressPrefix does not equal 96.116.134.8/32 or sourceAddressPrefix does not equal 96.118.251.38/32 or sourceAddressPrefix does not equal 96.118.251.70/32 or sourceAddressPrefix does not equal 2001:558:fc0c::f816:3eff:fe2b:7e9f/128 or sourceAddressPrefix does not equal 2001:558:fc0c::f816:3eff:fe2d:f8c0/128 or sourceAddressPrefix does not equal 2001:558:fc18:2:f816:3eff:fea9:fec9/128 or sourceAddressPrefix does not equal 2001:558:fc18:2:f816:3eff:fe86:aa73/128) and (destinationPortRange contains _Port.inRange(22,22) or destinationPortRanges[*] contains _Port.inRange(22,22) ))] exists```
Azure Service bus namespace configured with overly permissive authorization rules
This policy identifies Azure Service bus namespaces configured with overly permissive authorization rules. Service Bus clients should not use a namespace level access policy that provides access to all queues and topics in a namespace. It is recommended to follow the least privileged security model, should create access policies at the entity level for queues and topics to provide access to only the specific entity. All authorization rules except RootManageSharedAccessKey should be removed from the Service bus namespace.


This is applicable to azure cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: 1. Log in to the Azure Portal
2. Go to Service Bus
3. Select the reported Service bus namespace
4. Click on 'Shared access policies' under 'Settings'
5. Select and remove all authorization rules except RootManageSharedAccessKey..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-service-bus-namespace' AND json.rule = authorizationRules[*] size greater than 1 and authorizationRules[?any(name does not equal RootManageSharedAccessKey and properties.rights contains Manage)] exists```
AWS Elastic Load Balancer (ELB) not in use
This policy identifies unused Elastic Load Balancers (ELBs) in your AWS account. Any Elastic Load Balancer in your AWS account is adding charges to your monthly bill, although it is not used by any resources. As a best practice, it is recommended to remove ELBs that are not associated with any instances, it will also help you avoid unexpected charges on your bill.
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 check and remove ELB that has no registered instances, perform the following:
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 EC2 dashboard
4. In the navigation pane, under 'LOAD BALANCING', click on 'Load Balancers'
5. Select reported Elastic Load Balancer
6. Select the 'Description' tab from the bottom panel
7. In 'Basic Configuration' section, see If the selected load balancer 'Status' is '0 of 0 instances in service'.
It means that there are no registered instances and the ELB can be safely removed.
8. Click the 'Actions' dropdown from the ELB dashboard top menu
9. Select Delete
10. In the 'Delete Load Balancer' pop-up dialog, confirm the action to delete on clicking 'Yes, Delete' button.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elb-describe-load-balancers' AND json.rule = 'instancesAttached is false'```
GCP SQL database is assigned with public IP
This policy identifies GCP SQL databases which are assigned with public IP.  To lower the organisation's attack surface, Cloud SQL databases should not have public IPs. Private IPs provide improved network security and lower latency for your application. It is recommended to configure Second Generation Sql instance to use private IPs instead of public IPs. 
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. Login to GCP Console
2. Navigate to SQL
3. Click on the reported SQL instance, 
4. On overview page, click on 'EDIT' from top menu
5. Under 'Configuration options' Click on  'Connectivity'
6. From dropdown deselect 'Public IP' checkbox 
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = backendType equals SECOND_GEN and ipAddresses[*].type contains PRIMARY```
Azure Microsoft Defender for Cloud set to Off for Open-Source Relational Databases
This policy identifies Azure Microsoft Defender for Cloud which has defender setting for Open-Source Relational Databases set to Off. Enabling Azure Defender for cloud provides advanced security capabilities like threat intelligence, anomaly detection, and behaviour analytics. Microsoft Defender for Cloud detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases. It is highly recommended to enable Azure Defender for Open-Source Relational Databases.
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. Click 'Select types >' in the row for 'Databases'
7. Set the radio button next to 'Open-source relational databases' to 'On'
8. Click on 'Save'.

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

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-role-assignment' as X; config from cloud.resource where api.name = 'azure-active-directory-user' as Y; filter '((_DateTime.ageInDays($.X.properties.updatedOn) < 1) and (($.X.properties.principalId contains $.Y.id)))'; show X;```
API automation policy pkifp

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 = architecture contains "foo"```
AWS KMS Key scheduled for deletion
This policy identifies KMS Keys which are scheduled for deletion. Deleting keys in AWS KMS is destructive and potentially dangerous. It deletes the key material and all metadata associated with it and is irreversible. After a key is deleted, you can no longer decrypt the data that was encrypted under that key, which means that data becomes unrecoverable. You should delete a key only when you are sure that you don't need to use it anymore. If you are not sure, It is recommended that to disable the key instead of deleting it.
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: You should delete a KMS key only when you are sure that you don't need to use it anymore. To fix this alert, If you sure you no longer need a reported KMS key; dismiss the alert. If you are not sure, consider disabling the KMS key instead of deleting it.

To enable KMS CMKs which are scheduled for deletion, perform the following:
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 Key Management Service (KMS)
4. Click on 'Customer managed keys' (Left Panel)
5. Select reported KMS Customer managed key
6. Click on 'Key actions' dropdown
7. Click on 'Cancel key deletion'
8. Click on 'Enable'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-kms-get-key-rotation-status' AND json.rule = 'keyMetadata.keyState contains PendingDeletion'```
AWS Elastic Load Balancer v2 (ELBv2) with cross-zone load balancing disabled
This policy identifies load balancers that do not have cross-zone load balancing enabled.

Cross-zone load balancing evenly distributes incoming traffic across healthy targets in all availability zones. This can help to ensure your application can manage additional traffic and limit the risk of any single availability zone getting overwhelmed and perhaps affecting load balancer performance.

It is recommended to enable cross-zone load balancing.
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 enable cross-zone load balancing, please follow the below steps:

1. Log in to the AWS console.
2. Go to the EC2 Dashboard and select 'Load Balancers'
3. Click on the reported load balancer. Under the 'Actions' dropdown, select 'Edit load balancer attributes'.
4. For Gateway load balancers, under 'Availability Zone routing Configuration', enable 'Cross-zone load balancing'.
5. For Network load balancers, under 'Availability Zone routing Configuration', select the 'Enable cross-zone load balancing' option.
6. Click on 'Save changes'..

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name = 'aws-elbv2-describe-load-balancers' AND json.rule = ['attributes'].['load_balancing.cross_zone.enabled'] is false```
Azure Network Watcher not enabled
This policy identifies Azure subscription regions where Network Watcher is not enabled.

Azure Network Watcher provides tools to monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network. Without Network Watcher enabled, you lose critical capabilities to monitor and diagnose network issues, making it difficult to identify and resolve performance bottlenecks, network security rules, and connectivity issues.

As a best practice, it is recommended to enable Azure Network Watcher for your region to leverage its monitoring and diagnostic capabilities.
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: Note: Enabling Network Watcher will incur costs. There are additional costs per transaction to run and store network data. For high-
volume networks these charges will add up quickly.

To enable Network Watcher, follow the below URL:
https://learn.microsoft.com/en-us/azure/network-watcher/network-watcher-create?tabs=portal#enable-network-watcher-for-your-region.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-network-watcher-list' AND json.rule = provisioningState equals Succeeded as X; count(X) less than 1```
Alibaba Cloud SLB listener is configured with SSL policy having TLS version 1.1 or lower
This policy identifies Server Load Balancer (SLB) listeners which are configured with SSL policy having TLS version 1.1 or lower. As a best security practice, use TLS 1.2 as the minimum TLS version in your load balancers SSL security policies.
This is applicable to alibaba_cloud 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 Alibaba Cloud Portal
2. Go to Server Load Balancer
3. Click on the reported load balancer
4. In the 'Listeners' tab, Choose HTTPS Listener, Click on 'Configure'
5. In the 'Configure Listener' page, Click on 'Next'
6. In the 'SSL Certificates', Click on 'Modify' for 'Advanced' section
7. For 'TLS Security Policy', Choose TLS 1.2 or later version policy as per your requirement.
8. Click on 'Next'
9. If no changes to Backend Servers and Health Check, Click on 'Next'
10. In 'Submit' section, click on 'Submit'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-load-balancer' AND json.rule =  'listenerPortsAndProtocal[*].listenerProtocal equals https and ([*].tlscipherPolicy equals tls_cipher_policy_1_0 or [*].tlscipherPolicy equals tls_cipher_policy_1_1)'```
Azure Microsoft Defender for Cloud email notification for subscription owner is not set
This policy identifies the Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) in which email notification for subscription owners is not set. Enabling security alert emails to subscription owners ensures that they receive security alert emails from Microsoft. This ensures that they are aware of any potential security issues and can mitigate the risk in a timely fashion.
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. In the drop down of the 'All users with the following roles' field select 'Owner'
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[*].properties.email is empty or securityContacts[*].properties.alertsToAdmins equal ignore case Off) and pricings[?any(properties.pricingTier equal ignore case Standard)] exists```