knarayan/cloud_posture_checks huggingface dataset:
Azure CDN Endpoint Custom domains using insecure TLS version
This policy identifies Azure CDN Endpoint Custom domains which has insecure TLS version. TLS 1.2 resolves the security gap from its preceding versions. As a best security practice, use TLS 1.2 as the minimum TLS version for Azure CDN Endpoint Custom domains.
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 Azure Portal
2. Go to 'CDN profiles'
3. Choose the reported each 'CDN Endpoints' under each 'CDN profiles'
4. Under 'Settings' section, Click on 'Custom domains'
5. Select the 'Custom domain' for which you need to set TLS version
6. Under 'Configure' select 'TLS 1.2' for 'Minimum TLS version'
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cdn-endpoint' AND json.rule = properties.customDomains[?any( properties.customHttpsProvisioningState equals Enabled and properties.customHttpsParameters.minimumTlsVersion equals TLS10 )] exists```
Azure App Services FTP deployment is All allowed
This policy identifies Azure App Services which has FTP deployment setting as All allowed. Attacker could listen to wifi traffic and get the login credentials to a FTP deployments which could be in plain text and get full control of the code base of the app or service. It is highly recommend to use FTPS if FTP deployment for workflow is essential else disable the FTP deployment for Azure App 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: Following recommendation steps are for resources hosted in App Service, Premium and Windows Consumption plans,

1. Log in to the Azure Portal
2. Select 'App Services' from the left pane
3. Select the reported App Services
4. Go to 'Configurations' under 'Settings'
5. Click on 'General settings'
6. Select 'FTPS only' or 'Disabled' for 'FTP state' under 'Platform settings'
7. Click on 'Save'

If Function App Hosted in Linux using Consumption (Serverless) Plan follow below steps

Azure CLI Command 
FTP Disable - \"az functionapp config set --ftps-state Disabled --name MyFunctionApp --resource-group MyResourceGroup\"

FTPS only - \"az functionapp config set --ftps-state FtpsOnly --name MyFunctionApp --resource-group MyResourceGroup\".

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = config.ftpsState equals AllAllowed```
GCP Bucket containing Operations Suite Logs have bucket logging disabled
This policy identifies the buckets containing Operations Suite Logs for which logging is disabled. Enabling bucket logging, logs all the requests made on the bucket which can be used for debugging and forensics. It is recommended to enable logging on the buckets containing Operations Suite Logs.
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: Follow the below mentioned URL to enable logging for a bucket:

https://cloud.google.com/storage/docs/access-logs.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name= 'gcloud-storage-buckets-list' AND json.rule = '($.logging does not exist or $.logging equals null) and ($.acl[*].email exists and $.acl[*].email contains logging)'```
AWS DMS replication instance automatic version upgrade disabled
This policy identifies the AWS DMS(Database Migration Service) replication instances that do not have auto minor version upgrade feature enabled

A replication instance in DMS is a compute resource used to replicate data between a source and target database during the migration or ongoing replication process. Failure to enable automatic minor upgrades can leave your database instances vulnerable to security risks stemming from outdated software.

It is recommended to enable automatic minor version upgrades on DMS replication instances to receive timely patches and updates, reduce the risk of security vulnerabilities and improve overall performance and stability.
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: To modify an AWS DMS(Database Migration Service) Replication Instance's Automatic version upgrade using the AWS console, follow these steps:

1. Sign in to the AWS Management Console.
2. In the console, select the specific region from the region dropdown in the top right corner, for which the alert is generated.
3. Go to the DMS console by either searching for 'DMS' in the AWS services search bar or navigating directly to the DMS service.
4. From the navigation pane on the left, select 'Replication Instances' under the 'Migrate data' section.
5. Select the replication instance that is reported and select 'Modify' from the 'Action' dropdown in the right corner.
6. Under the 'Maintenance' section, choose the 'Yes' option for the 'Automatic version upgrade'.
7. Under the 'When to apply the modifications' section, choose 'Apply immediately' or 'Apply during the next scheduled maintenance window' according to your business requirements.
8. Click 'Save' to save the changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-dms-replication-instance' AND json.rule = replicationInstanceStatus equals "available" and autoMinorVersionUpgrade is false```
AWS Network Firewall is not configured with logging configuration
This policy identifies an AWS Network Firewall where logging is not configured.

AWS Network Firewall manages inbound and outbound traffic for the AWS resources within the AWS environment. Logging configuration for the network firewall involves enabling logging of network traffic, including allowed and denied requests, to provide visibility into network activity. Failure to configure logging results in a lack of visibility into potential security threats, making it difficult to detect and respond to malicious activity effectively and hindering threat detection and compliance.

It is recommended to enable logging to ensure comprehensive monitoring, threat detection, compliance adherence, and effective incident response.
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 update a firewall's logging configuration through the console, Perform the following actions:

1. Sign in to the AWS Management Console
2. Select the specific region from the region drop-down in the top right corner, for which the alert is generated
3. Navigate to the VPC Dashboard
4. In the navigation pane, Under 'Network Firewall', choose 'Firewalls'
5. On the Firewalls page, select the reported firewall
6. In the 'Firewall details' tab, under the 'Logging' section, click on 'Edit'
5. Select the Log type as needed for your requirement. You can configure logging for alert and flow logs.

Alert – Sends logs for traffic that matches any stateful rule whose action is set to Alert or Drop. For more information about stateful rules and rule groups, see Rule groups in AWS Network Firewall.

Flow – Sends logs for all network traffic that the stateless engine forwards to the stateful rules engine.

6. For each selected log type, choose the destination type, then provide the information for the logging destination that you prepared following the guidance in Firewall logging destinations.
7. Choose 'Save' to save your changes and return to the firewall's detail page..

Query:
```config from cloud.resource where api.name = 'aws-networkfirewall-firewall' AND json.rule = FirewallStatus.Status equals "READY" as X; config from cloud.resource where api.name = 'aws-network-firewall-logging-configuration' AND json.rule = LoggingConfiguration.LogDestinationConfigs[*].LogType does not exist as Y; filter '$.X.Firewall.FirewallArn equal ignore case $.Y.FirewallArn' ; show X;```
AWS DynamoDB table deletion protection is disabled
This policy identifies AWS DynamoDB tables with deletion protection 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. Deletion protection feature allows authorised administrators to prevent accidental deletion of DynamoDB tables. Enabling deletion protection helps reduce the risk of data loss, maintain data integrity, ensure compliance, and protect DynamoDB tables across different environments.

It is recommended to enable deletion protection on DynamoDB tables to prevent unintended data loss.
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 a Dynamodb table with deletion protection, follow these steps:

1. Sign into the AWS console and navigate to the DynamoDB console.
2. In the navigation pane, under 'Tables', locate the table you want to enable deletion protection for and select it.
3. In the table details page, under the 'Additional settings' tab, go to the 'Deletion protection' section and click on 'Turn on'.
4. Under the confirmation screen, click on 'Confirm'..

Query:
```config from cloud.resource where api.name = 'aws-dynamodb-describe-table' AND json.rule = tableStatus equal ignore case ACTIVE and deletionProtectionEnabled is false```
amtest-eni

This is applicable to aws cloud and is considered a critical severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where api.name = 'aws-ec2-describe-network-interfaces' AND json.rule = association.allocationId exists```
Azure Storage Account default network access is set to 'Allow'
This policy identifies Storage accounts which have default network access is set to 'Allow'. Restricting default network access helps to provide a new layer of security, since storage accounts accept connections from clients on any network. To limit access to selected networks, the default action must be changed.
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: To change the default network access rule, follow below URL:
https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security?tabs=azure-portal#change-the-default-network-access-rule.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-storage-account-list' AND json.rule = 'networkRuleSet.defaultAction equals Allow'```
AWS ECR private repository tag mutable
This policy identifies AWS ECR private repositories whose tag immutability is not configured.

AWS Elastic Container Registry (ECR) tag immutability ensures that once an image is pushed to a repository with tag immutability enabled, the tag cannot be overwritten or updated. This feature is useful for ensuring the security, integrity, and reliability of container images in production environments. It prevents tags from being overwritten, which can help prevent unauthorised changes to images.

It is recommended to enable tag immutability on ECR repositories to maintain the integrity and security of the images pushed.
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 tag immutability for an ECR repository, follow the below steps:

1. Log into the AWS console and navigate to the ECR dashboard.
2. In the navigation pane, choose 'Repositories' under 'Private registry'.
3. Select the repository you want to edit and choose 'Edit' from the 'Actions' dropdown.
4. Make 'Tag immutability' to 'enabled'.
5. Choose 'Save'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ecr-get-repository-policy' AND json.rule = imageTagMutability equal ignore case mutable```
GCP Kubernetes cluster node auto-repair configuration disabled
This policy identifies GCP Kubernetes cluster nodes with auto-repair configuration disabled. GKE's node auto-repair feature helps you keep the nodes in your cluster in a healthy, running state. When enabled, GKE makes periodic checks on the health state of each node in your cluster. If a node fails consecutive health checks over an extended time period, GKE initiates a repair process for that node.

FMI: https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair
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. Log in to Google cloud console
2. Navigate to Google Kubernetes Engine, click on 'Clusters' to get the list
3. Click on the alerted cluster and go to section 'Node pools'
4. Click on a node pool to ensure Auto repair' is enabled in the 'Management' section
5. To modify click on the 'Edit' button at the top
6. To enable the configuration click on the check box against 'Enable auto-repair'
7. Click on 'Save'
8. Repeat Step 4-7 for each node pool associated with the reported cluster.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = nodePools[?any(management.autoRepair does not exist or management.autoRepair is false)] exists```
llatorre - RoleAssignment  v1

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: Reach out to llatorre@paloaltonetworks.com.

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) < 80) and (($.X.properties.principalId contains $.Y.id)))'; show X; addcolumn properties.roleDefinition.properties.roleName```
AWS Database Migration Service endpoint do not have SSL configured
This policy identifies Database Migration Service (DMS) endpoints that are not configured with SSL to encrypt connections for source and target endpoints. It is recommended to use SSL connection for source and target endpoints; enforcing SSL connections help protect against 'man in the middle' attacks by encrypting the data stream between endpoint connections.

NOTE: Not all databases use SSL in the same way. An Amazon Redshift endpoint already uses an SSL connection and does not require an SSL connection set up by AWS DMS. So there are some exlcusions included in policy RQL to report only those endpoints which can be configured using DMS SSL feature. 

For more details:
https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Security.html#CHAP_Security.SSL
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. Log in to the AWS Console
2. Navigate to the AWS DMS dashboard
3. In the navigation pane, choose 'Endpoints'
4. Select the reported DMS endpoint
5. Under 'Actions', choose 'Modify'
6. In the 'Endpoint configuration' section, select the 'Secure Socket Layer (SSL) mode' from the dropdown list select suitable SSL mode according to your requirement other than 'none'.
7. Click on 'Save'

NOTE: Before modifying the SSL setting, you should be configured with the proper certificate you want to use for SSL connection under the DMS 'Certificate' service..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-dms-endpoint' AND json.rule = status equals active and (endpointType equals SOURCE and sslMode equals none and engineName is not member of ("s3", "azuredb")) or (endpointType equals TARGET and sslMode equals none and engineName is not member of ("dynamodb", "kinesis", "neptune", "redshift", "s3", "elasticsearch", "kafka"))```
jashah_ms_config

This is applicable to aws cloud and is considered a low 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-security-groups' AND json.rule = _AWSCloudAccount.orgHierarchyNames() intersects ("all-accounts")```
GCP VM instance Confidential VM service disabled
This policy identifies GCP VM instances that have Confidential VM service disabled.

GCP VM encrypts data at rest and in transit, but the data must be decrypted before processing. Confidential VM service (Confidential Computing) allows GCP VM to keep in-memory data secure by utilizing hardware-based memory encryption. This protects any sensitive data leakage in case the VM is compromised.

It is recommended to enable Confidential VM service on GCP VMs to enhance the confidentiality and integrity of in-memory data on the VMs.
This is applicable to gcp 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: Confidential VM services cannot be enabled for existing VM instances. A new VM should be created to enable confidential VM services on the instance.

To create a new VM instance with confidential VM services enabled, please refer to the steps below:
1. Login to the GCP console
2. Under 'Compute Engine', navigate to the 'VM instances' (Left Panel)
3. Click on 'Create instance'
4. Navigate to 'Security' section, Click Enable under 'Confidential VM service'.
5. In the Enable Confidential Computing dialog, review the list of settings updated when you enable the service, and then click 'Enable'.
6. Review other settings for the VM instance.
7. Click 'Create'.

Note: For the list of supported VM configurations for confidential VM services, please refer to the URL given below: https://cloud.google.com/confidential-computing/confidential-vm/docs/supported-configurations.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-instances-list' AND json.rule = status equal ignore case "RUNNING" and (machineType contains "machineTypes/n2d-" or machineType contains "machineTypes/c2d-" or machineType contains "machineTypes/c3d-" or machineType contains "machineTypes/c3-standard-")and (disks[*].guestOsFeatures[*].type contains "SEV_CAPABLE" or disks[*].guestOsFeatures[*].type contains "SEV_LIVE_MIGRATABLE_V2" or disks[*].guestOsFeatures[*].type contains "SEV_SNP_CAPABLE" or disks[*].guestOsFeatures[*].type contains "TDX_CAPABLE") and (confidentialInstanceConfig.enableConfidentialCompute does not exist or confidentialInstanceConfig.enableConfidentialCompute is false)```
AWS Elastic Load Balancer v2 (ELBv2) with listener TLS/SSL is not configured
This policy identifies AWS Elastic Load Balancers v2 (ELBv2) which have non-secure listeners. As Load Balancers will be handling all incoming requests and routing the traffic accordingly. The listeners on the load balancers should always receive traffic over secure channel with a valid SSL certificate configured.
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 Listeners tab, Click the 'Edit' button under the available listeners
7. In the Load Balancer Protocol type is application select the listener protocol as 'HTTPS (Secure HTTP)' or If the load balancer type is network, select the listener protocol as TLS
8. Select appropriate 'Security policy' 
9. In the SSL Certificate column, click 'Change'
10. On 'Select Certificate' popup dialog, Choose a certificate from ACM or IAM or upload a new certificate based on requirement and Click on 'Save'
11. Back to the 'Edit listeners' dialog box, review the secure listeners configuration, then click on 'Save'.

Query:
```config from cloud.resource where api.name = 'aws-elbv2-describe-load-balancers' AND json.rule = state.code contains active and listeners[?any( protocol is member of (HTTP,TCP,UDP,TCP_UDP) and defaultActions[?any( redirectConfig.protocol contains HTTPS)] does not exist )] exists as X; config from cloud.resource where api.name = 'aws-elbv2-target-group' AND json.rule = targetType does not equal alb and protocol exists and protocol is not member of ('TLS', 'HTTPS') as Y; filter '$.X.listeners[?any( protocol equals HTTP or protocol equals UDP or protocol equals TCP_UDP )] exists or ( $.X.listeners[*].protocol equals TCP and $.X.listeners[*].defaultActions[*].targetGroupArn contains $.Y.targetGroupArn)'; show X;```
OCI Kubernetes Engine Cluster pod security policy not enforced
This policy identifies Kubernetes Engine Clusters that are not enforced with pod security policy. The Pod Security Policy defines a set of conditions that pods must meet to be accepted by the cluster; when a request to create or update a pod does not meet the conditions in the pod security policy, that request is rejected and an error is returned.
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: To configure Pod Security Policies for Container Engine for Kubernetes, refer below URL:
https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengusingpspswithoke.htm

NOTE: You must define pod security policies for the pod security policy admission controller to enforce when accepting pods into the cluster. If you do not define pod security polices, the pod security policy admission controller will prevent any pods being created in the cluster..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-containers-artifacts-kubernetes-cluster' AND json.rule = lifecycleState equal ignore case ACTIVE and options.admissionControllerOptions.isPodSecurityPolicyEnabled is false```