knarayan/cloud_posture_checks huggingface dataset:
Azure Activity log alert for Delete network security group rule does not exist
This policy identifies the Azure accounts in which activity log alert for Delete network security group rule does not exist. Creating an activity log alert for Delete network security group rule gives insight into network rule access changes and may reduce the time it takes to detect suspicious activity.
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
2. Click on Monitor (Left Panel)
3. Select 'Alerts'
4. Click on Create > Alert rule
5. In 'Create an alert rule' page, choose the Scope as your Subscription and under the CONDITION section, choose 'Delete Security Rule (Microsoft.Network/networkSecurityGroups/securityRules)' and Other fields you can set based on your custom settings.
6. Click on Create.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-activity-log-alerts' AND json.rule = "location equal ignore case Global and properties.enabled equals true and properties.scopes[*] does not contain resourceGroups and properties.condition.allOf[?(@.field=='operationName')].equals equals Microsoft.Network/networkSecurityGroups/securityRules/delete" as X; count(X) less than 1```
AWS access keys not used for more than 45 days
This policy identifies IAM users for which access keys are not used for more than 45 days. Access keys allow users programmatic access to resources. However, if any access key has not been used in the past 45 days, then that access key needs to be deleted (even though the access key is inactive)
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['KEYS_AND_SECRETS'].
Mitigation of this issue can be done as follows: To delete the reported AWS User access key follow below mentioned URL:
https://aws.amazon.com/premiumsupport/knowledge-center/delete-access-key/.

Query:
```config from cloud.resource where cloud.type ='aws' and api.name = 'aws-iam-get-credential-report' AND json.rule = '(access_key_1_active is true and ((access_key_1_last_used_date != N/A and _DateTime.ageInDays(access_key_1_last_used_date) > 45) or (access_key_1_last_used_date == N/A and access_key_1_last_rotated != N/A and _DateTime.ageInDays(access_key_1_last_rotated) > 45))) or (access_key_2_active is true and ((access_key_2_last_used_date != N/A and _DateTime.ageInDays(access_key_2_last_used_date) > 45) or (access_key_2_last_used_date == N/A and access_key_2_last_rotated != N/A and _DateTime.ageInDays(access_key_2_last_rotated) > 45)))'```
Azure MariaDB database server with SSL connection disabled
This policy identifies MariaDB database servers for which SSL enforce status is disabled. Azure Database for MariaDB supports connecting your Azure Database for MariaDB server to client applications using Secure Sockets Layer (SSL). Enforcing SSL connections between your database server and your client applications helps protect against 'man in the middle' attacks by encrypting the data stream between the server and your application. It is recommended to enforce SSL for accessing your database server.
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 SSL connection on an existing Azure Database for MariaDB, follow the below URL:
https://docs.microsoft.com/en-us/azure/mariadb/howto-configure-ssl.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-database-maria-db-server' AND json.rule = properties.userVisibleState equals Ready and properties.sslEnforcement equals Disabled```
IR-test-GCP Firewall rule allows all traffic on HTTP port (80)
Test GCP policy to check cli remediation / can be deleted.
This is applicable to gcp 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 = 'gcp' AND api.name='gcloud-compute-firewall-rules-list' AND json.rule= disabled is false and direction equals INGRESS and (sourceRanges[*] equals ::0 or sourceRanges[*] equals 0.0.0.0 or sourceRanges[*] equals 0.0.0.0/0 or sourceRanges[*] equals ::/0 or sourceRanges[*] equals ::) and allowed[?any(ports contains _Port.inRange(80,80) or (ports does not exist and (IPProtocol contains tcp or IPProtocol contains udp)))] exists```
AWS ElastiCache Memcached cluster with in-transit encryption disabled
This policy identifies AWS ElastiCache Memcached clusters that have in-transit encryption disabled. It is highly recommended to implement in-transit encryption in order to protect data from unauthorized access as it travels through the network, between clients and cache servers. Enabling data encryption in-transit helps to prevent unauthorized users from reading sensitive data between your Memcached and their associated cache storage systems.
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: AWS ElastiCache Memcached in-transit encryption can be set, only at the time of creation. So to resolve this alert, create a new cluster with in-transit encryption enabled, then migrate all required ElastiCache Memcached cluster data from the reported ElastiCache Memcached cluster to this newly created cluster and delete reported ElastiCache Memcached cluster.

To create new ElastiCache Memcached cluster with In-transit encryption set, 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 ElastiCache
4. Click on 'Memcached clusters' under 'Resources'
5. Click on 'Create Memcached clusters' button
6. On the 'Cluster settings' page,
a. Enter a name for the new cache cluster
b. Select Memcached engine version from 'Engine version' dropdown list
Note: As of September 2022,In-transit encryption can be enabled only for AWS ElastiCache clusters with Memcached engine version 1.6.12 or later
c. Enter the 'Subnet group settings' and click on 'Next'
d. Under 'Security', Select 'Enable' checkbox under 'Encryption in transit'
e. Fill in other necessary parameters
7. Click on 'Create' button to launch your new ElastiCache Memcached cluster

To delete reported ElastiCache Memcached cluster follow below given URL:
https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/GettingStarted.DeleteCacheCluster.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elasticache-cache-clusters' AND json.rule = engine equals memcached and transitEncryptionEnabled is false```
Azure AKS cluster is not configured with disk encryption set
This policy identifies AKS clusters that are not configured with disk encryption set. Azure Key Vault Provider for Secrets Store CSI Driver allows for the integration of an Azure key vault as a secrets store with an Azure Kubernetes Service (AKS) cluster via a CSI volume. It is recommended to enable secret store CSI driver for your Kubernetes clusters.
This is applicable to azure 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. Log in to the Azure portal
2. Navigate to Kubernetes services dashboard
3. Click on the reported Kubernetes cluster
4. Under Setting section, Click on 'Cluster configuration'
5. Select 'Enable secret store CSI driver'
NOTE: Once the CSI driver is enabled, Azure will deploy additional pods onto the cluster. You'll still need to configure Azure Key Vault, define secrets to securely fetch, and redeploy the application to use these secrets.
For more details: https://azure.github.io/secrets-store-csi-driver-provider-azure/docs/demos/standard-walkthrough/
6. Click on 'Save'.

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.addonProfiles.azureKeyvaultSecretsProvider.enabled is false```
OCI IAM password policy for local (non-federated) users does not have a lowercase character
This policy identifies Oracle Cloud Infrastructure(OCI) accounts that do not have a lowercase character in the password policy for local (non-federated) users. As a security best practice, configure a strong password policy for secure access to the OCI console.
This is applicable to oci 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 the OCI Console Page: https://console.ap-mumbai-1.oraclecloud.com/
2. Go to Identity in the Services menu.
3. Select Authentication Settings from the Identity menu.
4.Click Edit Authentication Settings in the middle of the page.
5.Ensure the checkbox is selected next to MUST CONTAIN AT LEAST 1 LOWERCASE CHARACTER.
Note : The console URL is region specific, your tenancy might have a different home region and thus console URL..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-iam-authentication-policy' AND json.rule = 'passwordPolicy.isLowercaseCharactersRequired isFalse'```
OCI Block Storage Block Volume does not have backup enabled
This policy identifies the OCI Block Storage Volumes that do not have backup enabled. It is recommended to have block volume backup policies on each block volume so that the block volume can be restored during data loss events.

Note: This Policy is not applicable for block volumes that are added to volume groups.
This is applicable to oci cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Login to the OCI Console
2. Type the resource reported in the alert into the Search box at the top of the Console.
3. Click the resource reported in the alert from the Resources submenu
4. Click on Edit button
5. Select the Backup Policy from the Backup Policies section as appropriate
6. Click Save Changes.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-block-storage-volume' AND json.rule = volumeBackupPolicyAssignment[*] size equals 0 and volumeGroupId equal ignore case "null"```
GCP VM instance has risky basic role assigned
This policy identifies GCP VM instances configured with the risky basic role. Basic roles are highly permissive roles that existed prior to the introduction of IAM and grant wide access over project to the grantee. To reduce the blast radius and defend against privilege escalations if the VM is compromised, it is recommended to follow the principle of least privilege and avoid use of basic roles.
This is applicable to gcp cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: It is recommended to the principle of least privilege for granting access.

To create a new instance with desired service account, please refer to the URL given below:
https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#using

To update the assigned service account to VM, please refer to the URL given below:
https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#changeserviceaccountandscopes

To update priviledges granted to a service account, please refer to the URL given below:
https://cloud.google.com/iam/docs/granting-changing-revoking-access.

Query:
```config from cloud.resource where api.name = 'gcloud-projects-get-iam-user' AND json.rule = roles[*] contains "roles/editor" or roles[*] contains "roles/owner" as X; config from cloud.resource where api.name = 'gcloud-compute-instances-list' AND json.rule = status equals RUNNING and name does not start with "gke-" as Y; filter '$.Y.serviceAccounts[*].email contains $.X.user'; show Y;```
Azure Network Security Group allows all traffic on SQL Server (UDP Port 1434)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on SQL Server (UDP Port 1434). Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict SQL Server 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(1434,1434) or destinationPortRanges[*] contains _Port.inRange(1434,1434) ))] exists```
GCP Cloud Run service with overly permissive ingress rule
This policy identifies GCP Cloud Run services configured with overly permissive ingress rules. It is recommended to restrict the traffic from the internet and other resources by allowing traffic to enter through load balancers or internal traffic for better network-based access control.
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 service 'Cloud Run'
3. Click on the alerted service, go to tab 'TRIGGERS'
4. Under section 'Ingress', select a ingress type other than 'Allow all traffic'
5. Click on 'SAVE'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-cloud-run-services-list' AND json.rule = "status.conditions[?any(type equals Ready and status equals True)] exists and status.conditions[?any(type equals RoutesReady and status equals True)] exists and ['metadata'].['annotations'].['run.googleapis.com/ingress'] equals all"```
Allowing all to HTTPS

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 cloud.type = 'aws' AND api.name= 'aws-ec2-describe-security-groups' AND json.rule = isShared is false and (ipPermissions[?any((ipRanges[*] contains 0.0.0.0/0 or ipv6Ranges[*].cidrIpv6 contains ::/0) and ((toPort == 443 or fromPort == 443) or (toPort > 443 and fromPort < 443)))] exists)```
AWS Route53 Hosted Zone having dangling DNS record with subdomain takeover  risk
This policy identifies AWS Route53 Hosted Zones which have dangling DNS records with subdomain takeover risk. A Route53 Hosted Zone having a CNAME entry pointing to a non-existing S3 bucket will have a risk of these dangling domain entries being taken over by an attacker by creating a similar S3 bucket in any AWS account which the attacker owns / controls. Attackers can use this domain to do phishing attacks, spread malware and other illegal activities. As a best practice, it is recommended to delete dangling DNS records entry from your AWS Route 53 hosted zones.
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-route53-list-hosted-zones' AND json.rule = resourceRecordSet[?any( resourceRecords[*].value contains s3-website or aliasTarget.dnsname contains s3-website )] exists as X; config from cloud.resource where api.name = 'aws-s3api-get-bucket-acl' as Y; filter 'not($.X.resourceRecordSet[*].name contains $.Y.bucketName)'; show X;```
IBM Cloud Database MySQL is exposed to public
The policy identifies IBM Cloud Database MySQL instances exposed to the public via public endpoints. When provisioning an IBM Cloud database service, it is generally not recommended to use public endpoints because it can pose a security risk. Public endpoints can make your database accessible to anyone with internet access, potentially leaving your data vulnerable to unauthorized access or malicious attacks. Instead, it is recommended to use private endpoints when provisioning a database service in IBM Cloud.
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: Refer to the IBM documentation to change the service endpoints from public to private
https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-service-endpoints.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-mysql-deployment-info' AND json.rule = deployment.enable_public_endpoints is true```
AWS RDS snapshots are accessible to public
This policy identifies AWS RDS snapshots which are accessible to public. Amazon Relational Database Service (Amazon RDS) is a web service that makes it easier to setup and manage databases. If RDS snapshots are inadvertently shared to public, any unauthorized user with AWS console access can gain access to the snapshots and gain access to sensitive data.
This is applicable to aws 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: 1. Sign 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 the 'RDS' service.
4. For the RDS instance reported in the alert, change 'Publicly Accessible' setting to 'No'..

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name='aws-rds-describe-db-snapshots' AND json.rule="attributes[?(@.attributeName=='restore')]‌‌.attributeValues[*] contains all"```
AWS SageMaker notebook instance with root access enabled
This policy identifies the SageMaker notebook instances which are enabled with root access. Root access means having administrator privileges, users with root access can access and edit all files on the compute instance, including system-critical files. Removing root access prevents notebook users from deleting system-level software, installing new software, and modifying essential environment components.
NOTE: Lifecycle configurations need root access to be able to set up a notebook instance. Because of this, lifecycle configurations associated with a notebook instance always run with root access even if you disable root access for users.

For more details:
https://docs.aws.amazon.com/sagemaker/latest/dg/nbi-root-access.html
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: 1. Log in to AWS console
2. Navigate to the AWS SageMaker dashboard
3. Choose Notebook instances (Left panel)
4. Click on the reported SageMaker notebook instance
Note: To update root access for SageMaker notebook instances; Instances need to be stopped. So stop running instance before editing.
5. In the 'Notebook instance settings' section, click on 'Edit'
6. On the Edit notebook instance page, within the 'Permissions and encryption' section,
From the 'Root access - optional' options, select 'Disable - Don't give users root access to the notebook'
7. Click on the 'Update notebook instance'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-sagemaker-notebook-instance' AND json.rule = notebookInstanceStatus equals InService and rootAccess equals Enabled and notebookInstanceLifecycleConfigName does not exist```
AWS DynamoDB table Auto Scaling not enabled
This policy identifies AWS DynamoDB tables with auto-scaling disabled.

DynamoDB is a fully managed NoSQL database that provides a highly reliable, scalable, low-latency database solution for applications that require consistent, single-digit millisecond latency at any scale. Auto-scaling functionality allows you to dynamically alter the allocated throughput capacity for your DynamoDB tables based on current traffic patterns. This feature employs the Application Auto Scaling service to automatically boost provisioned read and write capacity to manage unexpected traffic increases and reduce throughput when the workload falls in order to avoid paying for wasted supplied capacity.

It is recommended to enable auto-scaling for the DynamoDB table to ensure efficient resource utilisation, cost optimisation, improved performance, simplified management, and scalability.
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 auto-scaling for a DynamoDB table through the AWS Management Console, follow these steps:

1. Sign into the AWS console. Navigate to the DynamoDB console.
2. In the navigation pane, choose 'Tables'.
3. Select the table you want to enable auto-scaling for.
4. Choose the 'Additional settings' tab.
5. In the 'Read/write capacity' section, choose 'Edit'.
6. In the 'Capacity mode' section, choose 'Provisioned'.
7. For 'Table capacity', set 'Auto scaling' to 'On' for read capacity, write capacity, or both.
8. Set the minimum and maximum capacity units, and the target utilization percentage for read and write capacity.
9. Choose 'Save changes'..

Query:
```config from cloud.resource where Resource.status = Active AND api.name = 'aws-application-autoscaling-scaling-policy' as Y; config from cloud.resource where api.name = 'aws-dynamodb-describe-table' AND json.rule = tableStatus equal ignore case ACTIVE AND billingModeSummary.billingMode does not equal PAY_PER_REQUEST as X; filter 'not($.Y.ResourceName equals $.X.tableName)'; show X;```