knarayan/cloud_posture_checks huggingface dataset:
Copy of Copy of Copy of build information

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: 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```
AWS Classic Load Balancer not configured to span multiple Availability Zones
This policy identifies AWS Classic Load Balancers that are not configured to span multiple Availability Zones. Classic Load Balancer would not be able to redirect traffic to targets in another Availability Zone if the sole configured Availability Zone becomes unavailable. As best practice, it is recommended to configure Classic Load Balancer to span multiple Availability Zones.


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 configure AWS Classic Load Balancer to span multiple Availability Zones follow the steps mentioned in below URL:

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-disable-az.html#add-availability-zone.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elb-describe-load-balancers' AND json.rule = description.availabilityZones[*] size less than 2```
Azure Container Instance not configured with the managed identity
This policy identifies Azure Container Instances (ACI) that are not configured with the managed identity. The managed identity is authenticated with Azure AD, developers don't have to store any credentials in code. So It is recommended to configure managed identity on all your container instances.

For more details:
https://docs.microsoft.com/en-us/azure/container-instances/container-instances-managed-identity
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 enable managed identity on your container instance; follow below URL:
https://docs.microsoft.com/en-us/azure/container-instances/container-instances-managed-identity.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-container-instances-container-group' AND json.rule = properties.provisioningState equals Succeeded and (identity.type does not exist or (identity.type exists and identity.type equal ignore case None))```
GCP Vertex AI Workbench user-managed notebook has Integrity monitoring disabled
This policy identifies GCP Vertex AI Workbench user-managed notebooks that have Integrity monitoring disabled.

Integrity Monitoring continuously monitors the boot integrity, kernel integrity, and persistent data integrity of the underlying VM of the shielded user-managed notebooks. It detects unauthorized modifications or tampering, enhancing security by verifying the trusted state of VM components throughout their lifecycle. It provides active alerting allowing administrators to respond to integrity failures and prevent compromised nodes from being deployed into the cluster.

It is recommended to enable integrity monitoring for user-managed notebooks to detect and mitigate advanced threats like rootkits and bootkit malware.
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 the GCP console
2. Navigate to the 'Vertex AI' service (Left Panel)
3. Under 'Notebooks', go to 'Workbench'
4. Open the 'USER-MANAGED NOTEBOOKS' tab
5. Click on the alerting notebook
6. Under the 'SYSTEM' tab, in front of 'VM details', click on the 'View in Compute Engine' link
7. Stop the VM by clicking on the 'STOP' button. Click the 'STOP' button on the confirmation dialogue.
8. Once the the VM has been stopped, click on the 'EDIT' button
9. Under 'Shielded VM', enable 'Turn on vTPM'
10. Enable 'Turn on Integrity Monitoring'
11. Click on 'Save'
12. Click on 'START/RESUME' from the top menu.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-vertex-ai-notebook-instance' AND json.rule = state equals "ACTIVE" and shieldedInstanceConfig.enableIntegrityMonitoring is false```
Copy of navnon-onboarding-policy
navnon-onboarding-policy
This is applicable to aws cloud and is considered a high severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name= 'aws-ec2-describe-security-groups' AND json.rule = isShared is false and (ipPermissions[?any((ipProtocol equals tcp or ipProtocol equals icmp or ipProtocol equals icmpv6 or ipProtocol equals udp) and (ipRanges[*] contains 0.0.0.0/0 or ipv6Ranges[*].cidrIpv6 contains ::/0))] exists)```
Azure Microsoft Defender for Cloud JIT network access monitoring is set to disabled
This policy identifies the Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) policies which have JIT network access monitoring set to disabled. Enabling JIT Network Access will enhance the protection of VMs by creating a Just in Time VM. The JIT VM with NSG rule will restrict the availability of access to the ports to connect to the VM for a pre-set time and only after checking the Role Based Access Control permissions of the user. This feature will control the brute force attacks on the VMs.
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. Choose the reported subscription
5. Click on the 'Security policy' under 'Policy settings' section
6. Click on 'SecurityCenterBuiltIn'
7. Select 'Parameters' tab
8. Set the 'Management ports of virtual machines should be protected with just-in-time network access control' to 'AuditIfNotExists'
9. If no other changes required then Click on 'Review + save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-policy-assignments' AND json.rule = '((name == SecurityCenterBuiltIn and properties.parameters.jitNetworkAccessMonitoringEffect.value equals Disabled) or (name == SecurityCenterBuiltIn and properties.parameters[*] is empty and properties.displayName does not start with "ASC Default"))'```
Copy of Copy of build information

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: 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```
GM-Mukhtar-AyawDaw

This is applicable to gcp cloud and is considered a informational 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-projects-get-iam-user' AND json.rule = roles contains roles/editor or roles contains roles/owner and (user does not start with g-bootstrap-svcacct-terraform and user does not equal "g-devops-admin@cna.com" and user does not equal "g-atos-devsecops@cna.com" and user does not contain "iam.gserviceaccount.com") and (user does not contain "appspot" and user does not contain "cloud" and user does not contain "developer")```
Azure Machine Learning workspace Storage account Datastore using Account key based authentication
This policy identifies Azure Machine Learning workspace datastores that use storage account keys for authentication.

Account key-based authentication is a security risk because it grants full, unrestricted access to the storage account, including the ability to read, write, and delete all data. If compromised, attackers can control all data in the account. This method lacks permission granularity and time limits, increasing the risk of exposing sensitive information. Using SAS tokens provides more granular control, allowing you to limit access to specific resources and set time-bound access, which enhances security and reduces risks in production environments.

As a security best practice, it is recommended to use SAS tokens for authenticating Azure Machine Learning datastores.
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 and search for 'Azure Machine Learning'
2. Select 'Azure Machine Learning'
3. Select the Azure Machine Learning Workspace that the reported Datastore is associated with
4. On the 'Overview' page, click the 'Studio web URL' link to log in to Azure ML Studio
5. A new tab will open for Azure ML Studio
6. In the left panel, under 'Assets' section, click on the 'Data'
7. Select the 'Datastores' tab at the top
8. Click on the reported Datastore
9. Click on the 'Update authentication' tab at the top
9. A side panel will appear on the right, configure the 'Authentication type' as 'SAS token' and enter the token value
10. Click 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-machine-learning-datastores' AND json.rule = (properties.datastoreType equal ignore case AzureFile or properties.datastoreType equal ignore case AzureBlob) and properties.credentials.credentialsType equal ignore case AccountKey```
Azure log profile not capturing activity logs for all regions
This policy identifies Azure log profiles that are not capturing activity logs for all regions. Activity logs are exported from all the Azure supported regions/locations means that logs for potentially unexpected activities occurring in otherwise unused regions are stored and made available for incident response and investigations.

Note: Since this type of logging is not deprecated from the Cloud service provider yet, we support it until it is removed.
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. Execute the command to check the number of regions present on the account: az account list-locations --query '[*].name' | grep -P 'w+' | wc -l
2. Execute the command to check the number of regions added to the log profile: az monitor log-profiles list --query '[*].locations' | grep -P 'w+' | wc -l
3. In case there is a difference in the count of regions from step 1 and step 2, Execute the command to list all regions az account list-locations --query '[*].name'
4. Use the listed regions from step 3 and Update the Legacy Log profiles activity logs for all regions by following the below URL:
https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/activity-log?tabs=cli#managing-legacy-log-profiles.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-monitor-log-profiles-list' AND json.rule = 'isLegacy is true and properties.isCapturingLogsForAllRegions is false'```
Azure Data Factory (V2) configured with overly permissive network access
This policy identifies Data factories (V2) configured with overly permissive network access. A Data factory managed virtual network along with managed private endpoints protects against data exfiltration. It is recommended to configure the Data factory with a private endpoint; so that the Data factory is accessible only to restricted entities.
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. Login to Azure portal
2. Navigate to 'Data factories'
3. Click on the reported Data factory
4. Select 'Networking' under 'Settings' from left panel 
5. In 'Private endpoint connections' tab, Create a private endpoint as per your requirement.
6. Once Private endpoint is created; In 'Network access' tab, Select the 'Private endpoint'
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-data-factory-v2' AND json.rule = properties.provisioningState equal ignore case Succeeded and properties.publicNetworkAccess equal ignore case Enabled```
Azure App Service Environment configured with weak TLS cipher suites
This policy identifies Azure App Service Environments that are configured with weak TLS Cipher suites.

Azure App Service Environments host web applications and APIs in a dedicated and isolated environment. When these environments are configured with weak TLS Cipher suites, they can expose sensitive data to potential security risks. Weak cipher suites may allow attackers to intercept and decrypt communication between clients and the App Service Environment, leading to unauthorized access, data breaches, and potential compliance violations. The recommended cipher suites are TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

As best practice, it is recommended to avoid using weak TLS Cipher suites to enhance security and protect sensitive data.
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: Refer to the documentation:
https://learn.microsoft.com/en-us/azure/app-service/environment/app-service-app-service-environment-custom-settings.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service-environment' AND json.rule = properties.provisioningState equal ignore case Succeeded and properties.clusterSettings exists and properties.clusterSettings[?any(name equal ignore case FrontEndSSLCipherSuiteOrder)] does not exist```
Azure Network Security Group having Inbound rule overly permissive to HTTP(S) traffic
This policy identifies Network Security Groups (NSGs) that have inbound rules allowing overly permissive access to HTTP or HTTPS traffic.

A network security group contains a list of security rules that allow or deny inbound or outbound network traffic based on source or destination IP address, port, and protocol. Overly permissive inbound rules for HTTP(S) traffic increase the risk of unauthorized access and potential attacks on your network resources. This can lead to data breaches, exposure of sensitive information, and other security incidents.

As a best practice, it is recommended to configure NSGs to restrict HTTP(S) traffic to only necessary and trusted IP addresses.
This is applicable to azure cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: Before making any changes, please check the impact on 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 and Port ranges 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((sourceAddressPrefix equal ignore case Internet or sourceAddressPrefix equals * or sourceAddressPrefix equals 0.0.0.0/0 or sourceAddressPrefix equals ::/0) and access equal ignore case Allow and direction equal ignore case Inbound and ((protocol equal ignore case Tcp and (destinationPortRange contains * or destinationPortRange contains _Port.inRange(80,80) or destinationPortRange contains _Port.inRange(443,443) or destinationPortRanges any equal * or destinationPortRanges[*] contains _Port.inRange(80,80) or destinationPortRanges contains _Port.inRange(443,443) )) or (protocol contains * and (destinationPortRange contains _Port.inRange(80,80) or destinationPortRange contains _Port.inRange(443,443) or destinationPortRanges[*] contains _Port.inRange(80,80) or destinationPortRanges contains _Port.inRange(443,443) ))) )] exists```
Azure Storage Sync Service configured with overly permissive network access
This policy identifies Storage Sync Services configured with overly permissive network access.

A Storage Sync Service is a management construct that represents registered servers and sync groups. Allowing all traffic to the Sync Service may allow a bad actor to brute force their way into the system and potentially get access to the entire network. With a private endpoint, the network traffic path is secured on both ends and access is restricted to only defined authorized entities.

It is recommended to configure the Storage Sync Service with private endpoints to minimize the access vector.
This is applicable to azure cloud and is considered a high 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 Storage Sync Services dashboard 
3. Click on the reported Storage Sync Service
4. Under the 'Settings' menu, click on 'Network'
5. Under 'Allow access from' select 'Private endpoints only'
6. Click on 'Private endpoint' and Create a private endpoint with required parameters 
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-storage-sync-service' AND json.rule = properties.provisioningState equals Succeeded and properties.incomingTrafficPolicy equals AllowAllTraffic```
Azure Storage account diagnostic setting for blob is disabled
This policy identifies Azure Storage account blobs that have diagnostic logging disabled.

By enabling diagnostic settings, you can capture various types of activities and events occurring within these storage account blobs. These logs provide valuable insights into the operations, performance, and security of the storage account blobs.

As a best practice, it is recommended to enable diagnostic logs on all storage account blobs.
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. Navigate to the Storage Accounts dashboard
3. Click on the reported Storage account
4. Under the 'Monitoring' menu, click on 'Diagnostic settings'
5. Select the blob resource
6. Under 'Diagnostic settings', click on 'Add diagnostic setting'
7. At the top, enter the 'Diagnostic setting name'
8. Under 'Logs', select all the checkboxes under 'Categories'
9. Under 'Destination details', select the destination for logging
10. Click on 'Save'.

Query:
```config from cloud.resource where api.name = 'azure-storage-account-list' AND json.rule = properties.provisioningState equal ignore case Succeeded as X; config from cloud.resource where api.name = 'azure-storage-account-blob-diagnostic-settings' AND json.rule = (properties.logs[?(@.categoryGroup)] exists and properties.logs[*].enabled any true) or (properties.logs[?(@.category)] exists and properties.logs[*].enabled all true) as Y; filter 'not($.X.name equal ignore case $.Y.StorageAccountName)'; show X;```
AWS IAM policy allows full administrative privileges
This policy identifies IAM policies with full administrative privileges. IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered a standard security advice to grant least privilege like granting only the permissions required to perform a task. 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.
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: 1. Log in to the AWS Console
2. Navigate to the IAM dashboard
3. In the navigation pane, click on Policies and then search for the policy name reported
4. Select the policy, click on the 'Policy actions', select 'Detach'
5. Select all Users, Groups, Roles that have this policy attached, Click on 'Detach policy'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-policy-version' AND json.rule = isAttached is true and document.Statement[?any(Action anyStartWith * and Resource equals * and Effect equals Allow)] exists and (policyArn exists and policyArn does not contain iam::aws:policy/AdministratorAccess)```
bikram_test

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

Query:
```config from cloud.resource where api.name = 'aws-ec2-describe-instances' AND json.rule = state.name contains "stopped" ```
AWS Lambda function URL having overly permissive cross-origin resource sharing permissions
This policy identifies AWS Lambda functions which have overly permissive cross-origin resource sharing (CORS) permissions. Overly permissive CORS settings (allowing wildcards) can potentially expose the Lambda function to unwarranted requests and cross-site scripting attacks. It is highly recommended to specify the exact domains (in 'allowOrigins') and HTTP methods (in 'allowMethods') that should be allowed to interact with your function to ensure a secure setup.
This is applicable to aws 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: To properly configure CORS permissions, refer the following URL:
https://docs.aws.amazon.com/lambda/latest/dg/API_Cors.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name= 'aws-lambda-list-functions' AND json.rule = cors exists and cors.allowOrigins[*] contains "*" and cors.allowMethods[*] contains "*"```
Azure SQL Server allow access to any Azure internal resources
This policy identifies SQL Servers that are configured to allow access to any Azure internal resources. Firewall settings with start IP and end IP both with ‘0.0.0.0’ represents access to all Azure internal network. When this settings is enabled, SQL server will accept connections from all Azure resources including other subscription resources as well. It is recommended to use firewall rules or VNET rules to allow access from specific network ranges or virtual networks.
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. Navigate to the 'SQL servers' dashboard
3. Click on the reported SQL server
4. Click on 'Networking' under Security
5. Unselect 'Allow Azure services and resources to access this server' under Exceptions if selected.
6. Remove any firewall rule which allows access to 0.0.0.0 in startIpAddress and endIpAddress if any.
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-sql-server-list' AND json.rule = ['sqlServer'].['properties.publicNetworkAccess'] equal ignore case Enabled and firewallRules[?any(startIpAddress equals "0.0.0.0" and endIpAddress equals "0.0.0.0")] exists```