knarayan/cloud_posture_checks huggingface dataset:
AWS Access logging not enabled on S3 buckets
Checks for S3 buckets without access logging turned on. Access logging allows customers to view complete audit trail on sensitive workloads such as S3 buckets. It is recommended that Access logging is turned on for all S3 buckets to meet audit & compliance requirement
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. Login to the AWS Console and navigate to the 'S3' service.
2. Click on the the S3 bucket that was reported.
3. Click on the 'Properties' tab.
4. Under the 'Server access logging' section, select 'Enable logging' option..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name='aws-s3api-get-bucket-acl' AND json.rule='loggingConfiguration.targetBucket equals null or loggingConfiguration.targetPrefix equals null'```
Azure Active Directory Security Defaults is disabled
This policy identifies Azure Active Directory which have Security Defaults configuration disabled. Security Defaults contains preconfigured security settings for common identity-related attacks. This provides a basic level of security-enabled by default. It is recommended to enable this configuration as a security best practice.
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. Login to Azure portal.
2. Navigate to 'Azure Active Directory'
3. Select 'Properties' under 'Manage'
4. Click on 'Manage Security defaults' if not selected
5. Under 'Enable Security defaults' select 'Yes' for 'Enable Security defaults'
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-active-directory-enforcement-policy' AND json.rule = isEnabled is false```
Azure Cosmos DB Virtual network is not configured
This policy identifies Azure Cosmos DBs that are not configured with a Virtual network. Azure Cosmos DB by default is accessible from any source if the request is accompanied by a valid authorization token. By configuring Virtual network only requests originating from those subnets will get a valid response. It is recommended to configure Virtual network to Cosmos DB.
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 following URL to configure Virtual networks on your Cosmos DB:
https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-configure-vnet-service-endpoint.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cosmos-db' AND json.rule = properties.provisioningState equals Succeeded AND properties.publicNetworkAccess equal ignore case Enabled AND properties.virtualNetworkRules[*] is empty```
GCP HTTPS Load balancer SSL Policy not using restrictive profile
This policy identifies HTTPS Load balancers which are not using restrictive profile in it's SSL Policy, which controls sets of features used in negotiating SSL with clients. As a best security practice, use RESTRICTED as SSL policy profile as it meets stricter compliance requirements and does not include any out-of-date SSL features.
This is applicable to gcp cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
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 SSL policy which uses the RESTRICTED/CUSTOM profile or if no SSL policy is already present then create a new SSL policy with RESTRICTED as Profile.
NOTE: If you choose CUSTOM as profile then make sure you are using profile features equally restrictive as the RESTRICTED profile or more than the RESTRICTED profile.
11. Click on 'Done'
12. Click on 'Update'.

Query:
```config from cloud.resource where api.name = 'gcloud-compute-ssl-policies' AND json.rule = profile does not equal RESTRICTED and profile does not equal CUSTOM as X; config from cloud.resource where api.name = 'gcloud-compute-target-https-proxies' AND json.rule = sslPolicy exists as Y; filter " $.X.selfLink contains $.Y.sslPolicy "; show Y;```
Azure Storage Account Container with activity log has BYOK encryption disabled
This policy identifies the Storage Accounts in which container with activity log has BYOK encryption disabled. Azure storage account with the activity logs being exported to container should use BYOK (Use Your Own Key) for encryption, which provides additional confidentiality controls on log data.
This is applicable to azure cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: 1. Log in to Azure Portal
2. Go to Storage accounts dashboard and Click on reported storage account
3. Under the Settings menu, click on Encryption
4. Select Customer Managed Keys
- Choose 'Enter key URI' and Enter 'Key URI'
OR
- Choose 'Select from Key Vault', Enter 'Key Vault' and 'Encryption Key'
5. Click on 'Save'.

Query:
```config from cloud.resource where api.name = 'azure-storage-account-list' as X; config from cloud.resource where api.name = 'azure-monitor-log-profiles-list' as Y; filter '($.X.properties.encryption.keySource does not equal "Microsoft.Keyvault" and $.X.properties.encryption.keyvaultproperties.keyname is not empty and $.X.properties.encryption.keyvaultproperties.keyversion is not empty and $.X.properties.encryption.keyvaultproperties.keyvaulturi is not empty and $.Y.properties.storageAccountId contains $.X.name)'; show X;```
test-resource-status

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 resource.status = Deleted and api.name = 'aws-securityhub-hub' AND json.rule = SubscribedAt exists```
Azure Function app configured with public network access
This policy identifies Azure Function apps that are configured with public network access. Publicly accessible web apps could allow malicious actors to remotely exploit any vulnerabilities and could. It is recommended to configure the Function apps with private endpoints so that the functions hosted are 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: To restrict App Service access, follow the below URL:
https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = 'kind contains functionapp and kind does not contain workflowapp and kind does not equal app and properties.state equal ignore case running and ((properties.publicNetworkAccess exists and properties.publicNetworkAccess equal ignore case Enabled) or (properties.publicNetworkAccess does not exist)) and config.ipSecurityRestrictions[?any((action equals Allow and ipAddress equals Any) or (action equals Allow and ipAddress equals 0.0.0.0/0))] exists'```
AWS IAM role/user with unused CloudTrail delete or full permission
This policy identifies IAM roles/users that have unused CloudTrail delete permission or CloudTrail full permissions. As a security best practice, it is recommended to grant the least privilege access like granting only the permissions required to perform a task, instead of providing excessive permissions to a particular role/user. It helps to reduce the potential improper or unintended access to your critical CloudTrail infrastructure.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: If Roles with unused CloudTrail delete permission,
1. Log in to AWS console
2. Navigate IAM service
3. Click on Roles
4. Click on reported IAM role
5. In the Permissions tab, Under the 'Permissions policies' section, Remove the policies which have CloudTrail permissions or Delete role if is not required.

If Users with unused CloudTrail delete permission,
1. Log in to AWS console
2. Navigate IAM service
3. Click on Users
4. Click on reported IAM user
5. In the Permissions tab, Under the 'Permissions policies' section, Remove the policies which have CloudTrail permissions or Delete user if is not required..

Query:
```config from cloud.resource where api.name = 'aws-iam-service-last-accessed-details' AND json.rule = '(arn contains :role or arn contains :user) and serviceLastAccesses[?any(serviceNamespace contains cloudtrail and totalAuthenticatedEntities any equal 0)] exists' as X; config from cloud.resource where api.name = 'aws-iam-get-policy-version' AND json.rule = 'isAttached is true and (document.Statement[?any(Effect equals Allow and (Action[*] contains DeleteTrail or Action contains DeleteTrail or Action contains cloudtrail:* or Action[*] contains cloudtrail:*))] exists)' as Y; filter '($.Y.entities.policyRoles[*].roleName exists and $.X.arn contains $.Y.entities.policyRoles[*].roleName) or ($.Y.entities.policyUsers[*].userName exists and $.X.arn contains $.Y.entities.policyUsers[*].userName)'; show X;```
Azure Service bus namespace configured with overly permissive network access
This policy identifies Azure Service bus namespaces configured with overly permissive network access. By default, Service Bus namespaces are accessible from the internet as long as the request comes with valid authentication and authorization. With an IP firewall, you can restrict it further to only a set of IPv4 addresses or IPv4 address ranges. With Virtual Networks, the network traffic path is secured on both ends. It is recommended to configure the Service bus namespace with an IP firewall or by Virtual Network; so that the Service bus namespace is accessible only to restricted entities.
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 restrict Service bus namespace access to only a set of IPv4 addresses or IPv4 address ranges; follow below URL:
https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-ip-filtering

To restrict Service bus namespace access with a virtual network; follow below URL:
https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-service-endpoints.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-service-bus-namespace' AND json.rule = sku.tier equals "Premium" and properties.status equals "Active" and networkRuleSets[*].properties.defaultAction equals "Allow" and networkRuleSets[*].properties.publicNetworkAccess equals Enabled```
AWS Cognito service role does not have identity pool verification
This policy identifies the AWS Cognito service role that does not have identity pool verification.

AWS Cognito is an identity and access management service for web and mobile apps. AWS Cognito service roles define permissions for AWS services accessing resources. The 'aud' claim in a cognito service role is an identity pool token that specifies the intended audience for the token. If the aud claim is not enforced in the cognito service role trust policy, it could potentially allow tokens issued for one audience to be used to access resources intended for a different audience. This oversight increases the risk of unauthorized access, compromising access controls and elevating the potential for data breaches within the AWS environment.

It is recommended to implement proper validation of the 'aud' claim by adding the 'aud' in the Cognito service role trust policy.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['UNAUTHORIZED_ACCESS'].
Mitigation of this issue can be done as follows: To mitigate the absence of 'aud' claim validation in service roles associated with Cognito identity pools, follow these steps:

1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
2. In the navigation pane of the IAM console, choose 'Roles'.
3. In the list of roles in account, choose the name of the role that is reported.
4. Choose the 'Trust relationships' tab, and then choose 'Edit trust policy'.
5. Edit the trust policy, add a condition to verify that the 'aud' claim matches the expected identity pool.
6. Click 'Update Policy'.

Refer to the below link to add the required aud validation in service roles
https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html#creating-roles-for-role-mapping.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-list-roles' AND json.rule = role.assumeRolePolicyDocument.Statement[*].Action contains "sts:AssumeRoleWithWebIdentity" and role.assumeRolePolicyDocument.Statement[*].Principal.Federated contains "cognito-identity.amazonaws.com" and role.assumeRolePolicyDocument.Statement[*].Effect contains "Allow" and role.assumeRolePolicyDocument.Statement[*].Condition.StringEquals does not contain "cognito-identity.amazonaws.com:aud"```
GCP VM instances have serial port access enabled
This policy identifies VM instances which have serial port access enabled. Interacting with a serial port is often referred to as the serial console. The interactive serial console does not support IP-based access restrictions such as IP allowlists. If you enable the interactive serial console on an instance, clients can attempt to connect to that instance from any IP address. So it is recommended to keep interactive serial console support disabled.
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 Portal
2. Go to Computer Engine (Left Panel)
3. Go to VM instances
4. From the list of VMs, choose the reported VM
5. Click on Edit
6. Under Remote access section, Uncheck 'Enable connecting to serial ports'
7. Click on Save button.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-instances-list' AND json.rule = metadata.items[?any(key contains "serial-port-enable" and value contains "true")] exists and (status equals RUNNING and name does not start with "gke-")```
Azure Storage Account storing Cognitive service diagnostic logs is publicly accessible
This policy identifies Azure Storage Accounts storing Cognitive service diagnostic logs are publicly accessible.

Azure Storage account stores Cognitive service diagnostic logs which might contain detailed information of platform logs, resource logs, trace logs and metrics. Diagnostic log data may contain sensitive data and helps in identifying potentially malicious activity. The attacker could exploit publicly accessible storage account to get cognitive diagnostic data logs and could breach into the system by leveraging exposed data and propagate across your system.

As a best security practice, it is recommended to restrict storage account access to only the services as per business requirement.
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 the Azure portal
2. Navigate to 'Storage Accounts' dashboard
3. Select the reported storage account
4. Under 'Data storage' section, Select 'Containers'
5. Select the blob container you need to modify
6. Click on 'Change access level'
7. Set 'Public access level' to 'Private (no anonymous access)'
8. Click on 'OK'.

Query:
```config from cloud.resource where api.name = 'azure-cognitive-services-account-diagnostic-settings' AND json.rule = (properties.logs[?any(enabled equal ignore case "true")] exists or properties.metrics[?any( enabled equal ignore case "true" )] exists) and properties.storageAccountId exists as X; config from cloud.resource where api.name = 'azure-storage-account-list' AND json.rule = 'totalPublicContainers > 0 and (properties.allowBlobPublicAccess is true or properties.allowBlobPublicAccess does not exist) and properties.publicNetworkAccess equal ignore case Enabled and networkRuleSet.virtualNetworkRules is empty and (properties.privateEndpointConnections is empty or properties.privateEndpointConnections does not exist)' as Y; filter '$.X.properties.storageAccountId contains $.Y.id'; show Y;```
OCI Compute Instance has Legacy MetaData service endpoint enabled
This policy identifies the OCI Compute Instances that are configured with Legacy MetaData service (IMDSv1) endpoints enabled. It is recommended that Compute Instances should be configured with legacy v1 endpoints (Instance Metadata Service v1) being disabled, and use Instance Metadata Service v2 instead following security best practices.
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: 1. Login to the OCI Console
2. Type the resource reported in the alert into the Search box at the top of the Console.
3. Click the resource reported in the alert from the Resources submenu
4. In the Instance Details section, next to Instance Metadata Service, click Edit.
5. For the Allowed IMDS version, select the Version 2 only option.
6. Click Save Changes.

Note : 
If you disable IMDSv1 on an instance that does not support IMDSv2, you might not be able to connect to the instance when you launch it. To re enable IMDSv1: using the Console, on the Instance Details page, next to Instance Metadata Service, click Edit. Select the Version 1 and version 2 option, save your changes, and then restart the instance. Using the API, use the UpdateInstance operation.

FMI : https://docs.cloud.oracle.com/en-us/iaas/Content/Compute/Tasks/gettingmetadata.htm#upgrading-v2.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-compute-instance' AND json.rule = instanceOptions.areLegacyImdsEndpointsDisabled is false```
AWS DAX cluster not configured with encryption at rest
This policy identifies the AWS DAX cluster where encryption at rest is disabled.

AWS DAX cluster encryption at rest provides an additional layer of data protection, helping secure your data from unauthorized access to underlying storage. Without encryption, anyone with access to the storage media could potentially intercept and view the data.

It is recommended to enable encryption at rest for the AWS DAX cluster.
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 DAX encryption at rest while creating the new DynamoDB cluster, perform the following actions:

1. Sign in to the AWS Management 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 'DynamoDB' service under the 'Database' section in 'Services' menu
4. In the navigation pane on the left side of the console, under 'DAX', choose 'Clusters'
5. Choose 'Create cluster'
6. For Cluster name , and other configurations set according to your reported DAX cluster
7. On the 'Configure security' panel, In 'Encryption' section, select the checkbox 'Turn on encryption at rest' and Click 'Next'
8. On the 'Verify advanced settings' set according your reported DAX cluster and click 'Next'
9. On the 'Review and create' click 'Create cluster'

Once the new cluster is created, change the cluster endpoint within your DynamoDB application to reference the new resource.

To delete the existing DAX cluster where encryption not enabled

1.  Sign in to the AWS Management 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 'DynamoDB' service under the 'Database' section in 'Services' menu
4. In the navigation pane on the left side of the console, under 'DAX', choose Clusters
5. Select the DAX cluster that is reported and required to remove
6. Click 'Delete' to delete the cluster.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-dax-cluster' AND json.rule = Status equals "available" and SSEDescription.Status equals "DISABLED"```
AWS Elasticsearch domain has Zone Awareness set to disabled
This policy identifies Elasticsearch domains for which Zone Awareness is disabled in your AWS account. Enabling Zone Awareness (cross-zone replication) increases the availability by distributing your Elasticsearch data nodes across two availability zones available in the same AWS region. It also prevents data loss and minimizes downtime in the event of node or availability zone failure.
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 Zone Awareness feature on existing Elasticsearch, following CLI can be used:
aws es update-elasticsearch-domain-config --domain-name <DOMAINNAME> --region <REGION> --elasticsearch-cluster-config ZoneAwarenessEnabled=true, ZoneAwarenessConfig={AvailabilityZoneCount=<COUNT>}

For more refer:
https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-multiaz.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-es-describe-elasticsearch-domain' AND json.rule = 'processing is false and (elasticsearchClusterConfig.zoneAwarenessEnabled is false or elasticsearchClusterConfig.zoneAwarenessEnabled does not exist)'```
Test-Uilian

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-network-private-endpoint' AND json.rule = properties.privateLinkServiceConnections[*].properties.privateLinkServiceId is not empty and properties.privateLinkServiceConnections[*].properties.privateLinkServiceId contains id```
Azure AD Users can consent to apps accessing company data on their behalf is enabled
This policy identifies Azure Active Directory which have 'Users can consent to apps accessing company data on their behalf' configuration enabled. User profiles contain private information which could be shared with others without requiring any further consent from the user if this configuration is enabled. It is recommended not to allow users to use their identity outside of the cloud environment.
This is applicable to azure cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: To configure user consent to apps accessing company data on their behalf, follow the below URL:
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-user-consent?pivots=portal.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-active-directory-authorization-policy' AND json.rule = defaultUserRolePermissions.permissionGrantPoliciesAssigned[*] contains microsoft-user-default-legacy```