knarayan/cloud_posture_checks huggingface dataset:
OCI IAM password policy for local (non-federated) users does not have an uppercase character
This policy identifies Oracle Cloud Infrastructure(OCI) accounts that do not have an uppercase 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 UPPERCASE 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.isUppercaseCharactersRequired isFalse'```
GCP Compute instances with confidential computing disabled

This is applicable to gcp 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 = 'gcloud-compute-instances-list' AND json.rule = status equal ignore case "RUNNING" and (machineType contains "machineTypes/n2d-" or machineType contains "machineTypes/c2d-") and (confidentialInstanceConfig.enableConfidentialCompute does not exist or confidentialInstanceConfig.enableConfidentialCompute is false)```
Azure Network Watcher Network Security Group (NSG) flow logs retention is less than 90 days
This policy identifies Azure Network Security Groups (NSG) for which flow logs retention period is 90 days or less. To perform this check, enable this action on the Azure Service Principal: 'Microsoft.Network/networkWatchers/queryFlowLogStatus/action'.

NSG flow logs, a feature of the Network Watcher app, enable you to view information about ingress and egress IP traffic through an NSG. The flow logs include information such as:
- Outbound and inbound flows on a per-rule basis.
- Network interface to which the flow applies.
- 5-tuple information about the flow (source/destination IP, source/destination port, protocol).
- Whether the traffic was allowed or denied.

As a best practice, enable NSG flow logs and set the log retention period to at least 90 days.
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 enable Flow Logs:

1. Log in to the Azure portal.
2. Select 'Network Watcher'.
3. Select 'NSG flow logs'.
4. Select the NSG for which you need to modify the flow log settings.
5. Set the Flow logs 'Status' to 'On'.
6. Select the destination 'Storage account'.
7. Set the 'Retention (days)' to 90 days or greater.
8. 'Save' your changes..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-network-nsg-list' AND json.rule =  ' $.flowLogsSettings does not exist or  $.flowLogsSettings.enabled is false or  ($.flowLogsSettings.retentionPolicy.days does not equal 0 and $.flowLogsSettings.retentionPolicy.days less than 90) '```
AWS IAM Access analyzer is not configured
This policy identifies AWS regions in which the IAM Access analyzer is not configured. AWS IAM Access Analyzer helps you identify the resources in your organization and accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external entity and identify unintended access to your resources and data. So it is recommended to configure the Access analyzer in all regions in your account.

NOTE: Access Analyzer analyzes only policies that are applied to resources in the same AWS Region that it's enabled in. To monitor all resources in your AWS environment, you must create an analyzer to enable Access Analyzer in each Region where you're using supported AWS resources.

For more details:
https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
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 the region drop-down on the top right corner, for which the alert is generated.
3. Navigate to the IAM dashboard 
4. Go to 'Access analyzer', from the left panel
5. Click on the 'Create analyzer' button
6. On the Create analyzer page, enter the parameters as per your requirements.
7. Click on the 'Create analyzer'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-access-analyzer' AND json.rule = status equals ACTIVE as X; config from cloud.resource where api.name = 'aws-region' AND json.rule = optInStatus does not equal not-opted-in as Y; filter '$.X.arn contains $.Y.regionName'; show X; count(X) less than 1```
Azure App Service Web app doesn't use latest TLS version
This policy identifies Azure web apps that are not configured with the latest version of TLS encryption. Azure Web Apps provide a platform to host and manage web applications securely.

Using the latest TLS version is crucial for maintaining secure connections. Older versions of TLS, such as 1.0 and 1.1, have known vulnerabilities that can be exploited by attackers. Upgrading to newer versions like TLS 1.2 or 1.3 ensures that the web app is better protected against modern security threats.

It is highly recommended to use the latest TLS version (greater than 1.1) for secure web app 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 App Services
3. Click on the reported App
4. Under "Settings" section, Click on "Configuration"
5. In "Platform Settings", Set "Minimum Inbound TLS Version" to "1.2" or "1.3"
6. Click on "Save" icon at the top
7. Click "Continue" to save the changes.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = kind starts with app and config.minTlsVersion is member of ('1.0', '1.1')```
OCI Event Rule and Notification does not exist for IAM policy changes
This policy identifies the OCI compartments which do not have an Event Rule and Notification that gets triggered for IAM policy changes. Monitoring and alerting on changes to IAM policies will help in identifying changes to the security posture. It is recommended that an Event Rule and Notification be configured to catch changes made to Identity and Access Management (IAM) policies.
NOTE: 
1. Event Rules are compartment scoped and will detect events in child compartments, it is recommended to create the Event rule at the root compartment level.
2. This policy will trigger alert if you have at least one Event Rule and Notification, even if OCI has single or multi compartments.
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 Event into the Search box at the top of the Console.
3. Click the Event Service from the Services submenu
4. Select the compartment that should host the rule
5. Click Create Rule
6. Provide a Display Name and Description
7. Create a Rule Condition by selecting Identity in the Service Name Drop-down and selecting Policy – Change Compartment, Policy – Create, Policy - Delete and Policy – Update
8. In the Actions section select Notifications as Action Type
9. Select the Compartment that hosts the Topic to be used.
10. Select the Topic to be used
11. Optionally add Tags to the Rule
12. Click Create Rule.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-events-rule' AND json.rule = '(isEnabled equals true) and (actions.actions[?any( actionType equals ONS and isEnabled equals true and lifecycleState equals ACTIVE)] exists) and (condition.eventType[*] contains com.oraclecloud.identitycontrolplane.createpolicy and condition.eventType[*] contains com.oraclecloud.identitycontrolplane.deletepolicy and condition.eventType[*] contains com.oraclecloud.identitycontrolplane.updatepolicy) and actions.actions[*].topicId exists' as X; count(X) less than 1```
IBM Cloud OpenShift cluster is accessible by using public endpoint
This policy identifies IBM Cloud OpenShift clusters which has public service endpoint enabled. If any cluster has public service endpoint enabled, the cluster will be accessible from Internet routable IP address. It is highly recommended to use a private service endpoint instead of a public service endpoint.
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: An OpenShift cluster can be made private only at the time of creation. To create a private 
OpenShift cluster follow below URL:
https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-create-vpc-gen2&interface=ui#clusters_vpcg2_ui Please make sure to select 'Private endpoint only' at 'Master service endpoint' section..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-kubernetes-cluster' AND json.rule = type equal ignore case openshift and state equal ignore case normal and serviceEndpoints.publicServiceEndpointEnabled is true```
AWS Web Application Firewall v2 (AWS WAFv2) logging is disabled
This policy identifies Web Application Firewall v2s (AWS WAFv2) for which logging is disabled. Enabling WAFv2 logging, logs all web requests inspected by the service which can be used for debugging and additional forensics. The logs will help to understand why certain rules are triggered and why certain web requests are blocked. You can also integrate the logs with any SIEM and log analysis tools for further analysis. It is recommended to enable logging on your Web Application Firewall v2s (WAFv2).

For details:
https://docs.aws.amazon.com/waf/latest/developerguide/logging.html#logging-management

NOTE: Global (CloudFront) WAFv2 resources are out of scope for this policy.
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 logging on your reported WAFv2s, follow below mentioned URL:
https://docs.aws.amazon.com/waf/latest/developerguide/logging.html#logging-management

NOTE: No additional cost to enable logging on AWS WAFv2 (minus Kinesis Firehose and any storage cost).
For Kinesis Firehose or any storage additional charges refer https://aws.amazon.com/cloudwatch/pricing/.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-waf-v2-web-acl-resource' AND json.rule = '(resources.applicationLoadBalancer[*] exists or resources.apiGateway[*] exists or resources.other[*] exists) and loggingConfiguration.resourceArn does not exist'```
Azure Network Security Group allows all traffic on NetBIOS (UDP Port 138)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on NetBIOS UDP port 138. Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict NetBIOS 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(138,138) or destinationPortRanges[*] contains _Port.inRange(138,138) ))] exists```
GCP Cloud Function configured with overly permissive Ingress setting
This policy identifies GCP Cloud Functions that are configured with overly permissive Ingress setting. With overly permissive Ingress setting, all inbound requests to the function are allowed, from both the public and resources within the same project. It is recommended to restrict the traffic from the public and other resources, to get better network-based access control and allow traffic from VPC networks in the same project or traffic through the Cloud Load Balancer.
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 'Cloud Functions' service (Left Panel)
3. Click on the alerting function
4. Click on 'EDIT'
5. Click on 'Runtime, build, connections and security settings' drop-down to get the detailed view
6. Click on the 'CONNECTIONS' tab
7. In 'Ingress settings', select either 'Allow internal traffic only' or 'Allow internal traffic and traffic from Cloud Load Balancing'
8. Click on 'NEXT'
9. Click on 'DEPLOY'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-cloud-function' AND json.rule = status equals ACTIVE and ingressSettings equals ALLOW_ALL```
AWS Elastic Load Balancer (ELB) has security group with no outbound rules
This policy identifies Elastic Load Balancers (ELB) which have security group with no outbound rules. A security group with no outbound rule will deny all outgoing requests. ELB security groups should have at least one outbound rule, ELB with no outbound permissions will deny all traffic going to any EC2 instances or resources configured behind that ELB; in other words, the ELB is useless without outbound permissions.
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 EC2 Dashboard
4. Click on 'Load Balancers', choose the reported load balancer
5. Click on the 'Description' tab, click on the security group, it will open Security Group properties in a new tab in your browser
6. Click on the 'Outbound Rules'
7. If there are no rules, click on 'Edit rules', add an outbound rule according to your ELB functional requirement
8. Click on 'Save'.

Query:
```config from cloud.resource where api.name = 'aws-elb-describe-load-balancers' as X; config from cloud.resource where api.name = 'aws-ec2-describe-security-groups' as Y; filter '$.X.description.securityGroups[*] contains $.Y.groupId and $.Y.ipPermissionsEgress[*] is empty'; show X;```
GCP Load balancer HTTPS target proxy is not configured with QUIC protocol
This policy identifies Load Balancer HTTPS target proxies which are not configured with QUIC protocol. Enabling QUIC protocol in load balancer target https proxies adds advantage by establishing connections faster, stream-based multiplexing, improved loss recovery, and eliminates head-of-line blocking.
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. Login to GCP Portal
2. Go to Network services (Left Panel)
3. Select Load balancing
4. Click on 'advanced menu' hyperlink to view target proxies
5. Click on 'Target proxies' tab
6. Click on the reported HTTPS target proxy
7. Click on the hyperlink under 'URL map'
8. Click on the 'EDIT' button
9. Select 'Frontend configuration', Click on HTTPS protocol rule
10. Select 'Enabled' from the dropdown for 'QUIC negotiation'
11. Click on 'Done'
12. Click on 'Update'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-target-https-proxies' AND json.rule = 'quicOverride does not contain ENABLE'```
Khalid Test Policy

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

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-instances' and json.rule = state .name contains "running"```
AWS ECS task definition elevated privileges enabled
This policy identifies the ECS containers that are having elevated privileges on the host container instance. When the Privileged parameter is true, the container is given elevated privileges on the host container instance (similar to the root user).

Note: This parameter is not supported for Windows containers or tasks using the Fargate launch type.
This is applicable to aws 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: Create a task definition revision.

1. Open the Amazon ECS console.
2. From the navigation bar, choose the region that contains your task definition.
3. In the navigation pane, choose Task Definitions.
4. On the Task Definitions page, select the box to the left of the task definition to revise and choose Create new revision.
5. On the Create new revision of Task Definition page, change the existing Container Definitions.
6. Under Security, uncheck the Privileged box.
7. Verify the information and choose Update, then Create.
8. If your task definition is used in a service, update your service with the updated task definition.
9. Deactivate previous task definition.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ecs-describe-task-definition' AND json.rule = status equals ACTIVE and containerDefinitions[*].privileged exists and containerDefinitions[*].privileged is true```
AWS Neptune Cluster not configured with IAM authentication
This policy identifies AWS Neptune clusters that are not configured with IAM authentication. If you enable IAM authentication you don't need to store user credentials in the database, because authentication is managed externally using IAM. IAM database authentication ensures the network traffic to and from database clusters is encrypted using Secure Sockets Layer (SSL), provides central access management to your database resources and enforces use of profile credentials instead of a password, for greater security.
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 enable IAM authentication for AWS Neptune cluster follow the steps mentioned in below URL:

https://docs.aws.amazon.com/neptune/latest/userguide/iam-auth-enable.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name= 'aws-neptune-db-cluster' AND json.rule = Status contains available and IAMDatabaseAuthenticationEnabled is false```
AWS Application Load Balancer (ALB) is not using the latest predefined security policy
This policy identifies Application Load Balancers (ALBs) are not using the latest predefined security policy. A security policy is a combination of protocols and ciphers. The protocol establishes a secure connection between a client and a server and ensures that all data passed between the client and your load balancer is private. A cipher is an encryption algorithm that uses encryption keys to create a coded message. So it is recommended to use the latest predefined security policy which uses only secured protocol and ciphers.

We recommend using either non-FIPS security policy ELBSecurityPolicy-TLS13-1-2-2021-06 or FIPS security policy ELBSecurityPolicy-TLS13-1-2-FIPS-2023-04 to meet compliance and security standards that require disabling certain TLS protocol versions or to support legacy clients that require deprecated ciphers.

For more details:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies
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. In the console, select the specific region from the region drop-down on the top right corner, for which the alert is generated

3. Go to the EC2 Dashboard, and select 'Load Balancers'

4. Click on the reported Load Balancer

5. On the 'Listeners' tab, Choose the 'HTTPS' or 'SSL' rule

6. Click on 'Edit Listener' in the 'Manage listener' dropdown, Change 'Security policy' to 'ELBSecurityPolicy-TLS13-1-2-2021-06' (non-FIPS) or 'ELBSecurityPolicy-TLS13-1-2-FIPS-2023-04' (FIPS) to meet compliance and security standards that require disabling certain TLS protocol versions or to support legacy clients that require deprecated ciphers.

7. Click on 'Update' to save your changes.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elbv2-describe-load-balancers' AND json.rule = type equals application and listeners[?any(protocol equals HTTPS and sslPolicy exists and sslPolicy is not member of ('ELBSecurityPolicy-TLS13-1-2-2021-06','ELBSecurityPolicy-TLS13-1-2-FIPS-2023-04'))] exists```
GCP Kubernetes cluster not in redundant zones
Putting resources in different zones in a region provides isolation from many types of infrastructure, hardware, and software failures.

This policy alerts if your cluster is not located in at least 3 zones.
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: Add zones to your zonal cluster.

1. Visit the Google Kubernetes Engine menu in GCP Console.
2. Click the cluster's Edit button, which looks like a pencil.
3. From the Additional zones section, select the desired zones.
4. Click Save..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule =  zone exists and locations[*] size less than 3```