knarayan/cloud_posture_checks huggingface dataset:
AWS root account configured with Virtual MFA
This policy identifies AWS root accounts which are configured with Virtual MFA. Root is an important role in your account and root accounts must be configured with hardware MFA. Hardware MFA adds extra security because it requires users to type a unique authentication code from an approved authentication device when they access AWS websites or services.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['MFA'].
Mitigation of this issue can be done as follows: To manage MFA devices for your AWS account, you must use your root user credentials to sign in to AWS. You cannot manage MFA devices for the root user while signed in with other credentials.

1. Sign in to the AWS Management Console with your root user credentials
2. Go to IAM
3. Do one of the following:
Option 1: Choose Dashboard, and under Security Status, expand Activate MFA on your root account.
Option 2: On the right side of the navigation bar, select your account name, and then choose My Security Credentials. If necessary, choose Continue to Security Credentials. Then expand the Multi-Factor Authentication (MFA) section on the page.
4. Choose Manage MFA or Activate MFA, depending on which option you chose in the preceding step.
5. In the wizard, choose A hardware MFA device and then choose Next Step.
6. If you have U2F security key as hardware MFA device, choose U2F security key and click on Continue. Next plug the USB U2F security key, when setup is complete click on Close.
If you have any other hardware MFA device, choose Other hardware MFA device option
a. In the Serial Number box, type the serial number that is found on the back of the MFA device.
b. In the Authentication Code 1 box, type the six-digit number displayed by the MFA device. You might need to press the button on the front of the device to display the number.
c. Wait 30 seconds while the device refreshes the code, and then type the next six-digit number into the Authentication Code 2 box. You might need to press the button on the front of the device again to display the second number.
d. Choose Next Step. The MFA device is now associated with the AWS account.

Important:
Submit your request immediately after generating the authentication codes. If you generate the codes and then wait too long to submit the request, the MFA device successfully associates with the user but the MFA device becomes out of sync. This happens because time-based one-time passwords (TOTP) expire after a short period of time. If this happens, you can resync the device..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-list-virtual-mfa-devices' AND json.rule = 'serialNumber contains root-account-mfa-device and user.arn contains root'```
Azure Function App doesn't use latest TLS version
This policy identifies Azure Function App which are not set with latest version of TLS encryption. Azure currently allows the Function App to set TLS versions 1.0, 1.1 and 1.2. It is highly recommended to use the latest TLS 1.2 version for Function App secure connections.
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. Navigate to Function App
3. Click on the reported Function App
4. Under Setting section, Click on 'TLS/SSL settings'
5. In 'Protocol Settings', Set 'Minimum TLS Version' to '1.2'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = properties.state equal ignore case "Running" AND kind contains "functionapp" AND kind does not contain "workflowapp" AND kind does not equal "app" AND config.minTlsVersion does not equal "1.2"```
OCI security group allows unrestricted ingress access to port 22
This policy identifies OCI Security groups that allow unrestricted ingress access to port 22. It is recommended that no security group allows unrestricted ingress access to port 22. As a best practice, remove unfettered connectivity to remote console services, such as Secure Shell (SSH), to reduce server's exposure to risk.
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 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. Under Resources, click Security Rules
5. If you want to add a rule, click Add Rules
6. If you want to delete an existing rule, click the Actions icon (three dots), and then click Remove.
7. If you wanted to edit an existing rule, click the Actions icon (three dots), and then click Edit..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-networking-nsg' AND json.rule = (securityRules[?any((((*.destinationPortRange.min == 22 or *.destinationPortRange.max == 22) or (*.destinationPortRange.min < 22 and *.destinationPortRange.max > 22)) or (protocol equals "all") or ((tcpOptions does not exist) and (udpOptions does not exist) and (protocol does not equal 1))) and (source equals 0.0.0.0/0 and direction equals INGRESS))] exists)```
sailesh of liron's policy #4

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-mysql-server' AND json.rule = properties.sslEnforcement equals Enabled and properties.minimalTlsVersion does not equal TLS1_2```
Azure PostgreSQL servers not configured with private endpoint
This policy identifies Azure PostgreSQL database servers that are not configured with private endpoint. Private endpoint connections enforce secure communication by enabling private connectivity to Azure Database for PostgreSQL. Configuring a private endpoint enables access to traffic coming from only known networks and prevents access from malicious or unknown IP addresses which includes IP addresses within Azure. It is recommended to create private endpoint for secure communication for your Azure PostgreSQL database.
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. Login to Azure portal.
2. Navigate to 'Azure Database for Postgres servers'
3. Click on the reported Postgres server instance you want to modify 
4. Select 'Networking' under 'Settings' from left panel 
5. Under 'Private endpoint', click on Add private endpoint' to create a add add a private endpoint

Refer to below link for step by step process:
https://learn.microsoft.com/en-us/azure/postgresql/single-server/how-to-configure-privatelink-portal.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-postgresql-server' AND json.rule = properties.userVisibleState equal ignore case Ready and properties.privateEndpointConnections[*] is empty```
mkurter clone of GCP Cloud Function is publicly accessible
This policy identifies GCP Cloud Functions that are publicly accessible. Allowing 'allusers' / 'allAuthenticatedUsers' to cloud functions can lead to unauthorised invocations of the functions or unwanted access to sensitive information. It is recommended to follow least privileged access policy and grant access restrictively. 
This is applicable to gcp 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: It is recommended to review and add appropriate, but restrictive roles before revoking access.

To revoke access from 'allusers'/'allAuthenticatedUsers', follow the below mentioned steps:
1. Login to GCP console
2. Navigate to service 'Cloud Functions'
3. Click on the function on which the alert is generated
4. Go to tab 'PERMISSIONS'
5. Review the roles to see if 'allusers'/'allAuthenticatedUsers' is present
6. Click on the delete icon to revoke access from 'allusers'/'allAuthenticatedUsers'
7. On Pop-up select the check box to confirm 
8. Click on 'REMOVE'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-cloud-function' AND json.rule = status equals ACTIVE and iamPolicy.bindings[?any(members[*] is member of ("allAuthenticatedUsers","allUsers"))] exists```
AWS EMR cluster is not configured with security configuration
This policy identifies EMR clusters which are not configured with security configuration. With Amazon EMR release version 4.8.0 or later, you can use security configurations to configure data encryption, Kerberos authentication, and Amazon S3 authorization for EMRFS.
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. 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. Follow below link to configure a security configuration
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-create-security-configuration.html
8. Click on 'Create' button
9. On the left menu of EMR dashboard Click 'Clusters'
10. Select the EMR cluster for which the alert has been generated and click on the 'Clone' button from the top menu.
11. In the Cloning popup, choose 'Yes' and Click 'Clone'
12. On the Create Cluster page, in the Security Options section, click on 'security configuration'
13. From the 'Security configuration' drop down select the name of the security configuration created at step 4 to step 8, click 'Create Cluster'.
14. Once you the new cluster is set up verify its working and terminate the source cluster in order to stop incurring charges for it
15. On the left menu of EMR dashboard Click 'Clusters', from the list of clusters select the source cluster which is alerted
16. Click on the 'Terminate' button from the top menu
17. On the 'Terminate clusters' pop-up, click 'Terminate'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-emr-describe-cluster' AND json.rule =  'status.state does not contain TERMINATING and securityConfiguration does not exist'```
AWS Secrets Manager secret not used for more than 90 days
This policy identifies the AWS Secrets Manager secret not accessed within 90 days. 

AWS Secrets Manager securely stores and manages sensitive information like API keys, passwords, and certificates. Leaving unused secrets in AWS Secrets Manager increases the risk of security breaches by providing unnecessary access points for attackers, potentially leading to unauthorized data access or leaks.

It is recommended to routinely review and delete unused secrets to reduce the attack surface and potential for unauthorized access.
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 unused AWS Secrets Manager secret, perform the following actions:

1. Sign in to the AWS Management Console
2. Select the region from the dropdown in the top right corner where the alert is generated
3. In the Navigation Panel on the left, Select 'All services' and under 'Security, Identity, & Compliance', select 'Secrets Manager'
4. Select the reported Secrets Manager secret
5. In the Secret details section, choose 'Actions', and then choose 'Delete secret'
6. In the Disable secret and schedule deletion dialog box, in Waiting period, enter the number of days to wait before the deletion becomes permanent.
7. Choose 'Schedule deletion'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-secretsmanager-describe-secret' AND json.rule = '(lastAccessedDate does not exist and _DateTime.ageInDays(createdDate) > 90) or (lastAccessedDate exists and _DateTime.ageInDays(lastAccessedDate) > 90)'```
Alibaba Cloud Security group allow internet traffic to MS SQL Monitor port (1434)
This policy identifies Security groups that allow inbound traffic on MS SQL Monitor port (1434) from the public internet. As a best practice, restrict security groups to only allow permitted traffic and limit brute force attacks on your network.
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 Elastic Compute Service
3. In the left-side navigation pane, choose Network & Security > Security Groups
4. Select the reported security group and then click Add Rules in the Actions column
5. In Inbound tab, Select the rule with 'Action' as Allow, 'Authorization Object' as 0.0.0.0/0 and 'Port Range' value as 1434, 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 cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ecs-security-group' AND json.rule = "permissions is not empty and permissions[?(@.policy=='Accept' && @.direction=='ingress' && @.sourceCidrIp=='0.0.0.0/0')].portRange contains _Port.inRange(1434,1434)"```
Azure Resource Group does not have a resource lock
Azure Resource Manager locks provide a way to lock down Azure resources from being deleted or modified. The lock level can be set to either 'CanNotDelete' or 'ReadOnly'. When you apply a lock at a parent scope, all resources within the scope inherit the same lock, and the most restrictive lock takes precedence.

This policy identifies Azure Resource Groups that do not have a lock set. As a best practice, place a lock on important resources to prevent accidental or malicious modification or deletion by unauthorized users.
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. Navigate to 'Resource groups' dashboard
3. Select the resource group that you want to lock
4. Select 'Locks' under 'Settings' from left panel, then click on 'Add'
5. Specify the lock name and type
6. Select on 'OK' to save your changes.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-resource-group' AND json.rule =  locks.*  size equals 0```
AWS IAM Password policy is unsecure
Checks to ensure that IAM password policy is in place for the cloud accounts. As a security best practice, customers must have strong password policies in place. This policy ensures password policies are set with all following options:
- Minimum Password Length
- At least one Uppercase letter
- At least one Lowercase letter
- At least one Number
- At least one Symbol/non-alphanumeric character
- Users have permission to change their own password
- Password expiration period
- Password reuse
- Password expiration requires administrator reset
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['WEAK_PASSWORD'].
Mitigation of this issue can be done as follows: 1. Login to AWS Console and navigate to the 'IAM' Service
2. Click on 'Account Settings'
3. Under 'Password Policy', select and set all the options
4. Click on 'Apply password policy'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-account-password-policy' AND json.rule =  'requireNumbers contains false and requireSymbols contains false and expirePasswords contains false and allowUsersToChangePassword contains false and requireLowercaseCharacters contains false and requireUppercaseCharacters contains false and maxPasswordAge does not exist and passwordReusePrevention does not exist and minimumPasswordLength==6'```
Alibaba Cloud SLB listener that allow connection requests over HTTP
This policy identifies Server Load Balancer (SLB) listeners that are configured to accept connection requests over HTTP instead of HTTPS. As a best practice, use the HTTPS protocol to encrypt the communication between the application clients and the server load balancer.
This is applicable to alibaba_cloud cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: Once Load balancer listener created we can not modify its protocol. So to resolve this alert, delete the existing HTTP Listener and create a new listener with HTTPS protocol.

To create a new HTTPS Listener follow:
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, click on 'Add Listener'
5. Select 'Select Listener Protocol' as 'HTTPS' and other parameters as per your requirement.
6. Click on 'Next' 
7. Choose 'SSL Certificates', 'Backend Servers' and 'Health Check' sections parameters accordingly and Click on 'Submit'

To delete existing HTTP Listener follow:
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 HTTP Listener, Click on 'More' and select 'Remove'
5. Click on 'OK'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-load-balancer' AND json.rule =  'listenerPortsAndProtocal[*].listenerProtocal equals http'```
Azure Network Security Group allows all traffic on ICMP (Ping)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on ICMP (Ping) protocol. ICMP is used by devices to communicate error messages and status. While ICMP is useful for  diagnostics and troubleshooting, it can also be used to exploit or disrupt systems. Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict ICMP (Ping) 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((sourceAddressPrefix equals Internet or sourceAddressPrefix equals * or sourceAddressPrefix equals 0.0.0.0/0 or sourceAddressPrefix equals ::/0) and (protocol equals Icmp or protocol equals *) and access equals Allow and direction equals Inbound and destinationPortRange contains *)] exists```
Azure Container Instance is not configured with virtual network
This policy identifies Azure Container Instances (ACI) that are not configured with a virtual network. Making container instances public makes an internet routable network. By deploying container instances into an Azure virtual network, your containers can communicate securely with other resources in the virtual network. So it is recommended to configure all your container instances within a virtual network.

For more details:
https://docs.microsoft.com/en-us/azure/container-instances/container-instances-vnet
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: Virtual network can only be configured at the time of container instance creation. Hence, it is suggested to delete an existing container instance having not configured with virtual network and create a new container instance having virtual network configured with secure values.
Note: Backup or migrate data from the container instance before deleting it.

To create a Container Instance within a virtual network; follow below URL:
https://docs.microsoft.com/en-us/azure/container-instances/container-instances-vnet

To delete a reported Container instance; follow below URL:
https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-portal#clean-up-resources.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-container-instances-container-group' AND json.rule = properties.provisioningState equals Succeeded and properties.ipAddress.type exists and properties.ipAddress.type equals Public```
OCI File Storage File System Export is publicly accessible
This policy identifies the OCI File Storage File Systems Exports that are publicly accessible. Monitoring and alerting on publicly accessible file systems exports will help in identifying changes to the security posture and thus reduces risk for sensitive data being leaked. It is recommended that no File System exports be publicly  accessible.
FMI : https://docs.cloud.oracle.com/en-us/iaas/Content/File/Tasks/exportoptions.htm#scenarios
This is applicable to oci 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: 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. Click on the alerted Export Path from the list of Exports
5. Click on the Edit NFS Export Options
6. Edit the export options to make it more restrictive
7. Click Update.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-file-storage-file-system' as X; config from cloud.resource where api.name = 'oci-file-storage-export' AND json.rule = (exportOptions[?any(source equals 0.0.0.0/0 and requirePrivilegedSourcePort is false and access equals READ_WRITE and identitySquash equals NONE)] exists) as Y; filter '($.X.id equals $.Y.fileSystemId)';show X;```