knarayan/cloud_posture_checks huggingface dataset:
Azure Machine Learning workspace not enforced with Managed Virtual Network Isolation
This policy identifies Azure Machine Learning workspaces that are not enforced with Managed Virtual Network Isolation.

Managed Virtual Network Isolation ensures that the workspace and its resources are accessible only within a secure virtual network. Without enforcing this isolation, the environment becomes vulnerable to security risks like external threats, data leaks, and non-compliance. If not properly isolated, the workspace may be exposed to public networks, increasing the chances of unauthorized access and data breaches.

As a security best practice, it is recommended to configure Azure Machine Learning workspaces with Managed Virtual Network Isolation. This will restrict network access to the workspace and ensure that it can only be accessed from authorized networks.
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: Note: To update an existing Azure Machine Learning workspace to use a managed virtual network, you first need to delete all its compute resources, including compute instances, compute clusters, and managed online endpoints.

1. Log in to Azure Portal and search for 'Azure Machine Learning'
2. Select 'Azure Machine Learning'
3. Select the reported Azure Machine Learning Workspace
4. Under 'Settings' go to 'Networking' section
5. At the top, select the 'Workspace managed outbound access' tab
6. Choose either 'Allow Internet Outbound' or 'Allow Only Approved Outbound' based on your needs
7. Configure the workspace outbound rules according to your requirements
8. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-machine-learning-workspace' AND json.rule = properties.provisioningState equal ignore case Succeeded and (properties.managedNetwork.isolationMode equal ignore case Disabled OR properties.managedNetwork.isolationMode does not exist)```
Copy of build information

This is applicable to azure 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 cloud.type = 'azure' AND api.name = 'azure-mysql-server' AND json.rule = properties.userVisibleState equal ignore case Ready and properties.privateEndpointConnections[*] is empty```
IBM Cloud Security Group allow all traffic on RDP port (3389)
This policy identifies IBM Cloud Security groups that allow all traffic on RDP port 3389. Doing so, may allow a bad actor to brute force their way into the system and potentially get access to the entire network. Review your list of security group rules to ensure that your resources are not exposed. As a best practice, restrict RDP solely to known static IP addresses. Limit the access list to include known hosts, services, or specific employees only.
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: Before making any changes, please check the impact to your applications/services. If the Security Groups reported indeed need to restrict all traffic, follow the instructions below:
1. Log in to the IBM Cloud Console
2. Click on 'Menu Icon' and navigate to 'VPC Infrastructure' and then 'Security Groups'
3. Select the 'Security Groups' reported in the alert
4. Go to 'Inbound rules' under 'Rules' tab
5. Click on three dots on the right corner of a row containing rule that has 'Source type' as 'Any' and 'Value' as 3389 (or range containing 3389)
6. Click on 'Delete'.

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-vpc-network-security-group' AND json.rule = rules[?any( remote.cidr_block equals "0.0.0.0/0" and direction equals "inbound" and ( protocol equals "all" or ( protocol equals "tcp" and ( port_max greater than 3389 and port_min less than 3389 ) or ( port_max equals 3389 and port_min equals 3389 ))))] exists```
Azure Virtual Machines are not utilising Managed Disks
This policy identifies Azure Virtual Machines which are not utilising Managed Disks. Using Azure Managed disk over traditional BLOB 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: 1. Log in to the Azure Portal
2. Select 'Virtual Machines' from the left pane
3. Select the reported virtual machine
4. Select 'Disks' under 'Settings'
5. Click on 'Migrate to managed disks'
6. Select 'Migrate'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-vm-list' AND json.rule = ['properties.storageProfile'].['osDisk'].['vhd'].['uri'] exists ```
AWS Elastic Beanstalk environment managed platform updates are not enabled
This policy identifies the AWS Elastic Beanstalk Environment where managed platform updates are not enabled.

Elastic Beanstalk is a platform as a service (PaaS) product from Amazon Web Services (AWS) that provides automated application deployment and scaling features. Enabling managed platform updates ensures that the latest available platform fixes, updates, and features for the environment are installed. Users must not apply updates manually without automatic updates, risking missed critical updates and potential security vulnerabilities. This can result in high-severity security risks, loss of data, and possible system downtime.

It is recommended to ensure platform updates are managed automatically is crucial for the overall security and performance of the applications running on the platform.
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 configure managed platform updates for  Elastic Beanstalk environment, perform the following actions

1. Sign 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 'Elastic Beanstalk' service
4. In the navigation pane, choose 'Environments', then select the reported environment's name from the list
5. In the navigation pane, choose Configuration
6. In the 'Updates, monitoring, and logging' configuration category, choose Edit
7. Under 'Managed platform updates' section, Enable Managed updates by selecting the 'Activated' checkbox
8. If managed updates are enabled, select a maintenance window, and then select an 'Update level' according to your business requirements
9. To save the changes choose 'Apply' at the bottom of the page.

Query:
```config from cloud.resource where api.name = 'aws-elasticbeanstalk-environment' AND json.rule = status does not equal "Terminated" as X; config from cloud.resource where api.name = 'aws-elasticbeanstalk-configuration-settings' AND json.rule = configurationSettings[*].optionSettings[?any( optionName equals "ManagedActionsEnabled" and namespace equals "aws:elasticbeanstalk:managedactions" and value equals "false")] exists as Y; filter ' $.X.environmentName equals $.Y.configurationSettings[*].environmentName and $.X.applicationName equals $.Y.configurationSettings[*].applicationName'; show X;```
GCP GKE unsupported Master node version
This policy identifies the GKE master node version and generates an alert if the version running is unsupported.

Using an unsupported version of Google Kubernetes Engine (GKE) on Google Cloud Platform (GCP) can lead to several potential issues and risks, such as security vulnerabilities, compatibility issues, performance and stability problems, and compliance concerns. To mitigate these risks, it's crucial to regularly update the GKE clusters to supported versions recommended by Google Cloud.

As a security best practice, it is always recommended to use the latest version of GKE.

Note: This Policy is in line with the GCP GKE release version schedule https://cloud.google.com/kubernetes-engine/docs/release-schedule#schedule-for-release-channels
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: Manually initiate a master upgrade:

1. Visit the Google Kubernetes Engine Clusters menu in Google Cloud Platform Console.
2. Click the desired cluster name.
3. Under Cluster basics, click "Upgrade Available" next to Version.
4. Select the desired version, then click Save Changes..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = isMasterVersionSupported exists AND isMasterVersionSupported does not equal "true"```
AWS SageMaker notebook instance is not placed in VPC
This policy identifies SageMaker notebook instances that are not placed inside a VPC. It is recommended to place your SageMaker inside VPC so that VPC-only resources able to access your SageMaker data, which cannot be accessed outside a VPC network.

For more details:
https://docs.aws.amazon.com/sagemaker/latest/dg/process-vpc.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: AWS SageMaker notebook instance can be not placed in VPC once it is created. You need to create a new notebook instance placing it in VPC; migrate all required data from the reported notebook instance to the newly created notebook instance before you delete the reported notebook instance.

To create a New AWS SageMaker notebook instance,
1. Log in to AWS console
2. Navigate to the AWS SageMaker dashboard
3. Choose Notebook instances and then choose 'Create notebook instance'
4. On the Create notebook instance page, within the 'Network' section,
From the 'VPC – optional' dropdown list, select the VPC where you want to deploy a new SageMaker notebook instance.
5. Choose other parameters as per your requirement and click on the 'Create notebook instance' button

To delete reported notebook instance,
1. Log in to AWS console
2. Navigate to the AWS SageMaker dashboard
3. Choose Notebook instances and Choose the reported notebook instance
4. Click on the 'Actions' dropdown menu, select the 'Stop' option, and when instance stops, select the 'Delete' option.
5. Within Delete <notebook-instance-name> dialog box, click the Delete button to confirm the action..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-sagemaker-notebook-instance' AND json.rule = notebookInstanceStatus equals InService and subnetId does not exist```
AWS EC2 Instance IAM Role not enabled
AWS provides Identity Access Management (IAM) roles to securely access AWS services and resources. The role is an identity with permission policies that define what the identity can and cannot do in AWS. As a best practice, create IAM roles and attach the role to manage EC2 instance permissions securely instead of distributing or sharing keys or passwords.
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: The most common setup is the AWS default that allows for EC2 access to AWS Services. For most, this is a great way to realize flexible, yet secure, EC2 access enabled for your instances. Select this when you launch EC2 instances to automatically inherit these permissions.

IAM
1. Go to the AWS console IAM dashboard.
2. In the navigation pane, choose Roles, Create new role.
3. Under 'Choose the service that will use this role' select EC2, then 'Next:Permissions.'
4. On the Attach permissions policies page, select an AWS managed policy that grants your instance access to the resources that they need, then 'Next:Tags.'
5. Add tags (optional), the select 'Next:Review.'
6. On the Create role and Review page, type a name for the role and choose Create role.

EC2
1. Go to the AWS console EC2 dashboard.
2. Select Running Instances.
3. Check the instance you want to modify.
4. From the Actions pull down menu, select Instance Settings and Attach/Replace IAM Role.
5. On the Attach/Replace IAM Role page, under the IAM role pull down menu, choose the role created in the IAM steps above..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-instances' AND json.rule =  iamInstanceProfile.arn does not exist and state.code equals 16```
AWS Log metric filter and alarm does not exist for Network Access Control Lists (NACL) changes
This policy identifies the AWS regions which do not have a log metric filter and alarm for Network Access Control Lists (NACL) changes. Monitoring changes to NACLs will help ensure that AWS resources and services are not unintentionally exposed. It is recommended that a metric filter and alarm be established for changes made to NACLs.

NOTE: This policy will trigger alert if you have at least one Cloudtrail with the multi trial is enabled, Logs all management events in your account and is not set with specific log metric filter and alarm.
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 in to AWS Console
2. Navigate to CloudWatch dashboard
3. Click on 'Log groups' in the 'Logs' section (Left panel)
4. Select the log group created for your CloudTrail trail event logs (CloudTrail should be multi trail enabled with all management events captured) and click 'Create Metric Filter' button.
5. In 'Define Logs Metric Filter' page, add 'Filter pattern' value as 
{ ($.eventName = CreateNetworkAcl) || ($.eventName = CreateNetworkAclEntry) || ($.eventName = DeleteNetworkAcl) || ($.eventName = DeleteNetworkAclEntry) || ($.eventName = ReplaceNetworkAclEntry) || ($.eventName = ReplaceNetworkAclAssociation) }
and Click on 'Assign Metric'
6. In 'Create Metric Filter and Assign a Metric' page, Choose Filter Name, Metric Details parameter according to your requirement and click on 'Create Filter'
7. Click on 'Create Alarm',
	- In Step 1 specify metric details and conditions details as required and click on 'Next'
	- In Step 2 Select an SNS topic either by creating a new topic or use existing SNS topic/ARN and click on 'Next'
	- In Step 3 Select name and description to alarm and click on 'Next'
	- In Step 4 Preview your data entered and click on 'Create Alarm'.

Query:
```config from cloud.resource where api.name = 'aws-logs-describe-metric-filters' as X; config from cloud.resource where api.name = 'aws-cloudwatch-describe-alarms' as Y; config from cloud.resource where api.name = 'aws-cloudtrail-describe-trails' as Z; filter '(($.Z.cloudWatchLogsLogGroupArn is not empty and $.Z.cloudWatchLogsLogGroupArn contains $.X.logGroupName and $.Z.isMultiRegionTrail is true and $.Z.includeGlobalServiceEvents is true) and (($.X.filterPattern contains "eventName=" or $.X.filterPattern contains "eventName =") and ($.X.filterPattern does not contain "eventName!=" and $.X.filterPattern does not contain "eventName !=") and $.X.filterPattern contains CreateNetworkAcl and $.X.filterPattern contains CreateNetworkAclEntry and $.X.filterPattern contains DeleteNetworkAcl and $.X.filterPattern contains DeleteNetworkAclEntry and $.X.filterPattern contains ReplaceNetworkAclEntry and $.X.filterPattern contains ReplaceNetworkAclAssociation) and ($.X.metricTransformations[*] contains $.Y.metricName))'; show X; count(X) less than 1```
GCP PostgreSQL instance database flag log_hostname is not set to off
This policy identifies PostgreSQL database instances in which database flag log_hostname is not set to off. Logging hostnames can incur overhead on server performance as for each statement logged, DNS resolution will be required to convert IP address to hostname. It is recommended to set log_hostname as off.
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 GCP console
2. Navigate SQL Instances page
3. Click on reported PostgreSQL instance
4. Click EDIT
5. If the flag has not been set on the instance, 
Under 'Customize your instance', click on 'ADD FLAG' in 'Flags' section, choose the flag 'log_hostname' from the drop-down menu and set the value as 'off'
OR
If the flag has been set to other than off, Under 'Customize your instance', In 'Flags' section choose the flag 'log_hostname' and set the value as 'off'
6. Click on 'DONE' and then 'SAVE'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = "state equals RUNNABLE and databaseVersion contains POSTGRES and settings.databaseFlags[?any(name contains log_hostname and value contains on)] exists"```
Azure Activity log alert for Delete public IP address rule does not exist
This policy identifies the Azure accounts in which activity log alert for Delete public IP address rule does not exist.

Creating an activity log alert for Delete public IP address rule gives insight into network rule access changes and may reduce the time it takes to detect suspicious activity. By enabling this monitoring, you get alerts whenever any deletions are made to public IP addresses rules.

As a best practice, it is recommended to have an activity log alert for Delete public IP address rule to enhance network security monitoring and detect suspicious activities.
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 Public Ip Address (Public Ip Address)' 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/publicIPAddresses/delete" as X; count(X) less than 1```
AWS S3 bucket policy does not enforce HTTPS request only
This policy identifies AWS S3 bucket having a policy that does not enforce only HTTPS requests. Enforcing the S3 bucket to accept only HTTPS requests would prevent potential attackers from eavesdropping on data in-transit or manipulating network traffic using man-in-the-middle or similar attacks. It is highly recommended to explicitly deny access to HTTP requests in S3 bucket policy.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: 1. Log in to the AWS console
2. Navigate to the S3 dashboard
3. Choose the reported S3 bucket
4. In the 'Permissions' tab, Click on 'Edit' under 'Bucket policy'
5. To update S3 bucket policy to enforce HTTPS request only, follow the below URL:
https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-policy-for-config-rule/.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = policy.Statement[?any(Effect equals Deny and Action equals s3:* and (Principal.AWS equals * or Principal equals *) and Condition.Bool.aws:SecureTransport contains false )] does not exist```
bboiko test 04 - policy

This is applicable to azure 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 cloud.type = 'azure' AND api.name = 'azure-key-vault-list' AND json.rule = properties.provisioningState equals Succeeded and diagnosticSettings.value[*].properties.workspaceId does not equal ignore case "/subscriptions/8dff688e-d9b0-477c-b2b0-b0e729fb06bd/resourceGroups/rg-analytics-sh-prd-scus/providers/Microsoft.OperationalInsights/workspaces/log-sh-workspace"```
AWS CloudFront web distribution with AWS Web Application Firewall (AWS WAF) service disabled
This policy identifies Amazon CloudFront web distributions which have the AWS Web Application Firewall (AWS WAF) service disabled. As a best practice, enable the AWS WAF service on CloudFront web distributions to protect against application layer attacks. To block malicious requests to your Cloudfront Content Delivery Network, define the block criteria in the WAF web access control list (web ACL).
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 in to the AWS console
2. Go to the CloudFront Distributions Dashboard
3. Click on the reported web distribution
4. On 'General' tab, Click on 'Edit' button
5. On 'Edit Distribution' page, Choose a 'AWS WAF Web ACL' from dropdown.
6. Click on 'Yes, Edit'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = 'webACLId is empty'```
Azure Load Balancer diagnostics logs are disabled
Azure Load Balancers provide different types of logs related to alert events, health probe and metrics to help you manage and troubleshoot issues. This policy identifies Azure Load Balancers that have diagnostics logs disabled. As a best practice, enable diagnostic logs to start collecting the data available through these logs.
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: Diagnostic logs is not supported for Azure Load Balancer which are in Basic SKU
Please create new Load Balancer and selecting Standard SKU
OR
To upgrade Basic SKU Load Balancer to Standard SKU follow the steps provided in the link below,
https://docs.microsoft.com/en-us/azure/load-balancer/upgrade-basic-standard

For Azure Load Balancer Standard SKU follow below steps,
1. Log in to the Azure portal.
2. Navigate to 'Load Balancers', and select the reported load balancer from the list
3. Select 'Diagnostic settings' under 'Monitoring' section
4. Click on '+Add diagnostic setting'
5. Specify a 'Diagnostic settings name',
6. Under 'Category details' section, select the type of 'Log' that you want to enable
7. Under section 'Destination details',
a. If you select 'Send to Log Analytics', select the 'Subscription' and 'Log Analytics workspace'
b. If you set 'Archive to storage account', select the 'Subscription', 'Storage account' and set the 'Retention (days)'
c. If you set 'Stream to an event hub', select the 'Subscription', 'Event hub namespace', 'Event hub name' and set the 'Event hub policy name'
8. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-network-lb-list' AND json.rule =  diagnosticSettings.value[*] size equals 0```