knarayan/cloud_posture_checks huggingface dataset:
Informational - 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 informational 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 CloudTrail logs are not encrypted using Customer Master Keys (CMKs)
Checks to ensure that CloudTrail logs are encrypted. AWS CloudTrail is a service that enables governance, compliance, operational & risk auditing of the AWS account. It is a compliance and security best practice to encrypt the CloudTrail data since it may contain sensitive information. 
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: 1. Login to AWS Console and navigate to the 'CloudTrail' service.
2. For each trail, under Configuration > Storage Location, select 'Yes' to 'Encrypt log files' setting
3.Choose and existing KMS key or create a new one to encrypt the logs with..

Query:
```config from cloud.resource where api.name='aws-cloudtrail-describe-trails' AND cloud.type = 'aws' AND json.rule = 'kmsKeyId does not exist'```
GCP Kubernetes Engine Clusters have binary authorization disabled
This policy identifies Google Kubernetes Engine (GKE) clusters that have disabled binary authorization. Binary authorization is a security control that ensures only trusted container images are deployed on GKE clusters. As a best practice, verify images prior to deployment to reduce the risk of running unintended or malicious code in your environment.
This is applicable to gcp cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To enable Binary authorization for a GKE cluster, please refer to the URL given below:
https://cloud.google.com/binary-authorization/docs/enable-cluster#console.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = binaryAuthorization.evaluationMode does not exist or binaryAuthorization.evaluationMode equal ignore case EVALUATION_MODE_UNSPECIFIED or binaryAuthorization.evaluationMode equal ignore case DISABLED```
Azure Virtual machine scale sets are not utilising Managed Disks
This policy identifies Azure Virtual machine scale sets which are not utilising Managed Disks. Using Azure Managed disk over traditional BLOB storage based VHD's has more advantage features like Managed disks are by default encrypted, reduces cost over storage accounts and more resilient as Microsoft will manage the disk storage and move around if underlying hardware goes faulty. It is recommended to move BLOB based VHD's to Managed Disks.
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: Currently migrating Virtual machine scale sets VHD disks to Azure Managed Disks is not available.
It is recommended that all new future scale sets be deployed with managed disks.

Follow steps given in the URL to create new Virtual machine Scale sets,

https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/quick-create-portal.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-virtual-machine-scale-set' AND json.rule = properties.virtualMachineProfile.storageProfile.osDisk.vhdContainers exists```
Azure Event Hub Namespace having authorization rules except RootManageSharedAccessKey
This policy identifies Azure Event Hub Namespaces which have authorization rules except RootManageSharedAccessKey.

Having Azure Event Hub namespace authorization rules other than 'RootManageSharedAccessKey' could provide access to all queues and topics under the namespace which pose a risk if these additional rules are not properly managed or secured.

As best practice, it is recommended to remove Event Hub namespace authorization rules other than RootManageSharedAccessKey and create access policies at the entity level, which provide access to only that specific entity for queues and topics.
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. Navigate to 'Event Hubs' dashboard
3. Select the reported Event Hubs Namespace
4. Select 'Shared access policies' under 'Settings' section
5. Delete all other Shared access policy rules except 'RootManageSharedAccessKey'..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-event-hub-namespace' AND json.rule = authorizationRules[*].name exists and authorizationRules[?any(name does not equal RootManageSharedAccessKey)] exists```
Azure SQL databases Defender setting is set to Off
This policy identifies Azure SQL databases which have Defender setting set to Off. Azure Defender for SQL provides a new layer of security, which enables customers to detect and respond to potential threats as they occur by providing security alerts on anomalous activities. Users will receive an alert upon suspicious database activities, potential vulnerabilities, SQL injection attacks, as well as anomalous database access patterns. Advanced threat protection alerts provide details of suspicious activity and recommend action on how to investigate and mitigate the threat.
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: If Azure Defender is enabled at server level it will also be applied to all the database, regardless of the database Azure Defender settings. It is recommended that you enable only server-level Azure Defender settings.
To enable auditing at server level:
1. Log in to the Azure Portal
2. Note down the reported SQL database and SQL server
3. Select 'SQL servers', Click on the SQL server instance you wanted to modify
4. Click on 'Microsoft Defender for Cloud' under 'Security'
5. Click on 'Enable Microsoft Defender for SQL'

It is recommended to avoid enabling Azure Defender in both server and database.
If you want to enable different storage account, email addresses for scan and alert notifications or 'Advanced Threat Protection types' for a specific database that differ from the rest of the databases on the server. Then to enable auditing at database level by:
1. Log in to the Azure Portal
2. Note down the reported SQL database
3. Select 'SQL databases', Click on the SQL database instance you wanted to modify
4. Click on 'Microsoft Defender for Cloud' under 'Security'
5. Click on 'Enable Microsoft Defender for SQL'.

Query:
```config from cloud.resource where api.name = 'azure-sql-db-list' AND json.rule = sqlDatabase.properties.status equals Online and (securityAlertPolicy.properties.state equals Disabled or securityAlertPolicy does not exist or securityAlertPolicy.[*] isEmpty) as X; config from cloud.resource where api.name = 'azure-sql-server-list' AND json.rule = ['sqlServer'].['properties.state'] equals Ready and (serverSecurityAlertPolicy.properties.state equals Disabled or serverSecurityAlertPolicy does not exist or serverSecurityAlertPolicy isEmpty) as Y; filter "$.X.blobAuditPolicy.id contains $.Y.sqlServer.name"; show X;```
AWS Elastic Load Balancer (ELB) with IAM certificate expiring in 90 days
This policy identifies Elastic Load Balancers (ELB) which are using IAM certificates expiring in 90 days or using expired certificates. Removing expired IAM certificates eliminates the risk and prevents the damage of credibility of the application/website behind the ELB. As a best practice, it is recommended to reimport expiring certificates while preserving the ELB associations of the original certificate.
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: Removing invalid certificates via AWS Management Console is not currently supported. To delete/upload SSL/TLS certificates stored in IAM via the AWS API use the Command Line Interface (CLI).

Remediation CLI:
1. Run describe-load-balancers command to make sure that the expiring server certificate is not currently used by any active load balancer.
aws elb describe-load-balancers --region <COMPUTE_REGION> --load-balancer-names <ELB_NAME> --query 'LoadBalancerDescriptions[*].ListenerDescriptions[*].Listener.SSLCertificateId'
This command output will return the Amazon Resource Name (ARN) for the SSL certificate currently used by the selected ELB:
[
	[
		\"arn:aws:iam::1234567890:server-certificate/MyCertificate\"
	]
]
2. Create new AWS IAM certificate with your desired parameters value
3. To upload new IAM Certificate:
aws iam upload-server-certificate --server-certificate-name <NEW_CERTIFICATE_NAME> --certificate-body file://Certificate.pem --certificate-chain file://CertificateChain.pem --private-key file://PrivateKey.pem
4. To replaces the existing SSL certificate for the specified HTTPS load balancer:
aws elb set-load-balancer-listener-ssl-certificate --load-balancer-name <ELB_NAME> --load-balancer-port 443 --ssl-certificate-id arn:aws:iam::1234567890:server-certificate/<NEW_CERTIFICATE_NAME>
5. Now that is safe to remove the expiring SSL/TLS certificate from AWS IAM, To delete it run:
aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>.

Query:
```config from cloud.resource where api.name = 'aws-elb-describe-load-balancers' as X; config from cloud.resource where api.name = 'aws-iam-list-server-certificates' as Y; filter '($.X.description.listenerDescriptions[*].listener.sslcertificateId equals $.Y.arn and ((_DateTime.ageInDays($.Y.expiration) > -90 and (_DateTime.ageInDays($.Y.expiration) < 0 or _DateTime.ageInDays($.Y.expiration) == 0)) or (_DateTime.ageInDays($.Y.expiration) > 0)))'; show X;```
Alibaba Cloud RAM policy allows full administrative privileges
This policy identifies RAM policies with full administrative privileges. RAM policies are the means by which privileges are granted to users, groups or roles. It is recommended to grant the least privilege access like granting only the permissions required to perform a task, instead of allowing full administrative privileges.
This is applicable to alibaba_cloud 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: 1. Log in to Alibaba Cloud Portal
2. Go to Resource Access Management
3. In the left-side navigation pane, click 'Policies'
4. Click on the reported RAM policy
5. Under the 'References' tab, 'Revoke Permission' for all users/roles/groups attached to the policy.
6. Delete the reported policy

Determine what users need to do and then craft policies for them that let the users perform only those tasks, instead of allowing full administrative privileges..

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ram-policy' AND json.rule = "(policy.policyType does not contain System) and (defaultPolicyVersion.policyDocument.Statement[?(@.Resource == '*' && @.Effect== 'Allow')].Action equals *)"```
AWS Elastic Load Balancer (Classic) with cross-zone load balancing disabled
This policy identifies Classic Elastic Load Balancers which have cross-zone load balancing disabled. When Cross-zone load balancing enabled, classic load balancer distributes requests evenly across the registered instances in all enabled Availability Zones. Cross-zone load balancing reduces the need to maintain equivalent numbers of instances in each enabled Availability Zone, and improves your application's ability to handle the loss of one or more instances.
This is applicable to aws 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. 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. Click on 'Load Balancers' (Left Panel)
5. Select the reported ELB
6. On the Description tab, choose 'Change cross-zone load balancing setting'
7. On the 'Configure Cross-Zone Load Balancing' popup dialog, select 'Enable'
8. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elb-describe-load-balancers' AND json.rule = 'attributes.crossZoneLoadBalancing.enabled is false'```
GCP Kubernetes Engine Clusters have legacy compute engine metadata endpoints enabled
This policy identifies Google Kubernetes Engine (GKE) clusters that have legacy compute engine metadata endpoints enabled. Because GKE uses instance metadata to configure node VMs, some of this metadata is potentially sensitive and should be protected from workloads running on the cluster. Legacy metadata APIs expose the Compute Engine's instance metadata of server endpoints. As a best practice, disable legacy API and use v1 APIs to restrict a potential attacker from retrieving instance metadata.
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: You can currently disable legacy metadata APIs only when creating a new cluster, or when adding a new node pool to an existing cluster. To fix this alert, create a new GKE cluster with legacy metadata APIs disabled, migrate all required data from the reported cluster to the newly created cluster before you delete the reported GKE cluster.

To create new Kubernetes engine cluster with private node feature enabled, perform the following:
1. Login to GCP Portal
2. Go to Kubernetes Engine (Left Panel)
3. Select Kubernetes clusters 
4. Click on CREATE CLUSTER button
5. Under the Node pools section, Click on the 'More node pool options' button
6. On 'Edit node pool' window, For 'GCE instance metadata' click on 'Add metadata'
7. Add 'disable-legacy-endpoints' as a metadata key and 'true' as a metadata value
8. Click on 'Save'
9. Click on 'Create'

To delete reported Kubernetes engine cluster, perform the following:
1. Login to GCP Portal
2. Go to Kubernetes Engine (Left Panel)
3. Select Kubernetes clusters 
4. Click on reported Kubernetes cluster
5. Click on the DELETE button
6. On 'Delete a cluster' popup dialog, Click on DELETE to confirm the deletion of the cluster..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = "nodePools[*].config.metadata does not exist or nodePools[*].config.metadata does not contain disable-legacy-endpoints or nodePools[*].config.metadata.disable-legacy-endpoints does not contain true"```
Azure Virtual Network subnet is not configured with a Network Security Group
This policy identifies Azure Virtual Network (VNet) subnets that are not associated with a Network Security Group (NSG).

While binding an NSG to a network interface of a Virtual Machine (VM) enables fine-grained control of the VM, associating an NSG to a subnet enables better control over network traffic to all resources within a subnet.

It is recommended to associate an NSG with a subnet so that you can protect your VMs on a subnet-level.

For more information,
https://learn.microsoft.com/en-gb/archive/blogs/igorpag/azure-network-security-groups-nsg-best-practices-and-lessons-learned
https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview#limitations

Note: This policy will not report for subnets used by Azure Firewall Subnet, Azure Firewall Management Subnet, Gateway Subnet, NetApp File Share, Route Server Subnet, Private endpoints and Private links as Azure recommends not to configure Network Security Group (NSG) for these services.
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. Select 'Virtual Networks', and select the virtual network you need to modify.
3. Select 'Subnets', and select the subnet you need to modify.
4. Select the Network security group (NSG) you want to associate with the subnet.
5. 'Save' your changes..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-network-subnet-list' AND json.rule = networkSecurityGroupId does not exist and name does not equal ignore case "GatewaySubnet" and name does not equal ignore case "RouteServerSubnet" and name does not equal ignore case "AzureFirewallSubnet" and name does not equal ignore case "AzureFirewallManagementSubnet" and ['properties.delegations'][*].['properties.serviceName'] does not equal "Microsoft.Netapp/volumes"```
Azure Application Insights configured with overly permissive network access
This policy identifies Application Insights configured with overly permissive network access.

Virtual network access configuration in Application Insights allows you to restrict data ingestion and queries coming from  public networks.

It is recommended to configure the Application Insights with virtual networks access configuration set to restrict, so that the Application Insight 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 Application Insights dashboard 
3. Click on the reported Application Insights
4. Under the 'Configure' menu, click on 'Network Isolation'
5. Create a Azure Monitor Private Link Scope if it is not already created by referring:
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-application-insights-component' AND json.rule = properties.provisioningState equals Succeeded and (properties.publicNetworkAccessForQuery equals Enabled or properties.publicNetworkAccessForIngestion equals Enabled)```
Azure Microsoft Defender for Cloud is set to Off for Azure SQL Databases
This policy identifies Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) which has defender setting for Azure SQL Databases is set to Off. Enabling Microsoft Defender for Cloud provides the tools needed to harden your resources, track your security posture, protect against cyberattacks, and streamline security management. It is highly recommended to enable Microsoft Defender for Azure SQL 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. Select 'Enable all Microsoft Defender for Cloud plans' if not already enabled
7. On the line in the table for 'Azure SQL Databases' Select 'On' under Plan.
8. Select 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = pricings[?any( name equals SqlServers and properties.pricingTier does not equal Standard)] exists```
AWS CloudTrail logs should integrate with CloudWatch for all regions
This policy identifies the Cloudtrails which is not integrated with cloudwatch for all regions. CloudTrail uses Amazon S3 for log file storage and delivery, so log files are stored durably. In addition to capturing CloudTrail logs within a specified S3 bucket for long term analysis, realtime analysis can be performed by configuring CloudTrail to send logs to CloudWatch Logs. For a trail that is enabled in all regions in an account, CloudTrail sends log files from all those regions to a CloudWatch Logs log group. It is recommended that CloudTrail logs be sent to CloudWatch Logs.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Sign into AWS and navigate to CloudTrail service.
2. Click on Trail in the left menu navigation and choose the reported cloudtrail.
3. Go to CloudWatch Logs section and click Configure.
4. Define a new or select an existing log group and click Continue to complete the process..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudtrail-describe-trails' as X; config from cloud.resource where api.name = 'aws-cloudtrail-get-trail-status' as Y; filter '(($.X.name == $.Y.trail) and ($.X.cloudWatchLogsLogGroupArn is not empty and $.X.cloudWatchLogsLogGroupArn exists) and $.X.isMultiRegionTrail is false and ($.Y.status.latestCloudWatchLogsDeliveryTime exists))'; show X;```
Azure Network Security Group allows all traffic on SQL Server (TCP Port 1433)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on SQL Server (TCP Port 1433). 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 Tcp or protocol equals *) and (destinationPortRange contains _Port.inRange(1433,1433) or destinationPortRanges[*] contains _Port.inRange(1433,1433) ))] exists```