knarayan/cloud_posture_checks huggingface dataset:
AWS ElastiCache Redis cluster with Multi-AZ Automatic Failover feature set to disabled
This policy identifies ElastiCache Redis clusters which have Multi-AZ Automatic Failover feature set to disabled. It is recommended to enable the Multi-AZ Automatic Failover feature for your Redis Cache cluster, which will improve primary node reachability by providing read replica in case of network connectivity loss or loss of availability in the primary's availability zone for read/write operations.
Note: Redis cluster Multi-AZ with automatic failover does not support T1 and T2 cache node types and is only available if the cluster has at least one read replica.
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 into the AWS console
2. In the console, select the specific region from region drop down on the top right corner, for which the alert is generated
3. Navigate to ElastiCache Dashboard
4. Click on Redis
5. Select reported Redis cluster
6. Click on 'Modify' button
7. In the 'Modify Cluster' dialog box,
a. Set 'Multi-AZ' to 'Yes'
b. Select 'Apply Immediately' checkbox, to apply the configuration changes immediately. If Apply Immediately is not selected, the changes will be processed during the next maintenance window.
c. Click on 'Modify'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elasticache-describe-replication-groups' AND json.rule = 'automaticFailover equals disabled or automaticFailover does not exist'```
Azure Service bus namespace not configured with Azure Active Directory (Azure AD) authentication
This policy identifies Service bus namespaces that are not configured with Azure Active Directory (Azure AD) authentication and are enabled with local authentication. Azure AD provides superior security and ease of use over shared access signatures (SAS). With Azure AD, there's no need to store the tokens in your code and risk potential security vulnerabilities. It is recommended to configure the Service bus namespaces with Azure AD authentication so that all actions are strongly authenticated.
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 configure Azure Active Directory (Azure AD) authentication and disable local authentication on existing Service bus, follow below URL instructions:
https://docs.microsoft.com/en-us/azure/service-bus-messaging/disable-local-authentication.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-service-bus-namespace' AND json.rule = properties.status equals "Active" and (properties.disableLocalAuth does not exist or properties.disableLocalAuth is false)```
Copy of AWS CloudTrail bucket is publicly accessible
This policy identifies publicly accessible S3 buckets that store CloudTrail data. These buckets contains sensitive audit data and only authorized users and applications should have access.
This is applicable to aws cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: 1. Login to the AWS Console
2. Navigate to the 'S3' service
3. Click on the 'S3' resource reported in the alert
4. Click on the 'Permissions'
5. If Access Control List' is set to 'Public' follow below steps
a. Under 'Access Control List', Click on 'Everyone' and uncheck all items
b. Click on Save
6. If 'Bucket Policy' is set to public follow below steps
a. Under 'Bucket Policy', modify the policy to remove public access
b. Click on Save
c. If 'Bucket Policy' is not required delete the existing 'Bucket Policy'.

Note: Make sure updating 'Access Control List' or 'Bucket Policy' does not affect S3 bucket data access..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name='aws-s3api-get-bucket-acl' AND json.rule = "((((acl.grants[?(@.grantee=='AllUsers')] size > 0) or policyStatus.isPublic is true) and publicAccessBlockConfiguration does not exist and accountLevelPublicAccessBlockConfiguration does not exist) or ((acl.grants[?(@.grantee=='AllUsers')] size > 0) and ((publicAccessBlockConfiguration.ignorePublicAcls is false and accountLevelPublicAccessBlockConfiguration does not exist) or (publicAccessBlockConfiguration does not exist and accountLevelPublicAccessBlockConfiguration.ignorePublicAcls is false) or (publicAccessBlockConfiguration.ignorePublicAcls is false and accountLevelPublicAccessBlockConfiguration.ignorePublicAcls is false))) or (policyStatus.isPublic is true and ((publicAccessBlockConfiguration.restrictPublicBuckets is false and accountLevelPublicAccessBlockConfiguration does not exist) or (publicAccessBlockConfiguration does not exist and accountLevelPublicAccessBlockConfiguration.restrictPublicBuckets is false) or (publicAccessBlockConfiguration.restrictPublicBuckets is false and accountLevelPublicAccessBlockConfiguration.restrictPublicBuckets is false))))" as X; config from cloud.resource where api.name = 'aws-cloudtrail-describe-trails' as Y; filter'$.X.bucketName equals $.Y.s3BucketName'; show X;```
GCP IAM primitive roles are in use
This policy identifies GCP IAM users assigned with primitive roles. Primitive roles are Roles that existed prior to Cloud IAM. Primitive roles (owner, editor) are built-in and provide a broader access to resources making them prone to attacks and privilege escalation. Predefined roles provide more granular controls than primitive roles and therefore Predefined roles should be used.

Note: For a new GCP project, service accounts are assigned with role/editor permissions. GCP recommends not to revoke the permissions on the SA account. Reference: https://cloud.google.com/iam/docs/service-accounts

Limitation: This policy alerts for Service agents which are Google-managed service accounts. Service Agents are by default assigned with some roles by Google cloud and these roles shouldn't be revoked.
Reference: https://cloud.google.com/iam/docs/service-agents
In case any specific service agent needs to be bypassed, this policy can be cloned and modified accordingly
This is applicable to gcp cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['HIGH_PRIVILEGED_ROLE'].
Mitigation of this issue can be done as follows: Review the projects / resources that have Primitive roles assigned to them and replace them with equivalent Predefined roles.
Note: This policy alerts for Service agents which are Google-managed service accounts. Service Agents are by default assigned with some roles by Google cloud and these roles shouldn't be revoked.
Reference: https://cloud.google.com/iam/docs/service-agents
Do not revoke the roles that are granted to service agents. If you revoke these roles, some Google Cloud services will no longer work..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-projects-get-iam-user' AND json.rule = '(user does not contain appspot.gserviceaccount.com and user does not contain developer.gserviceaccount.com and user does not contain cloudservices.gserviceaccount.com and user does not contain system.gserviceaccount.com and user does not contain cloudbuild.gserviceaccount.com) and (roles contains roles/editor or roles contains roles/owner)'```
Custom AlertRule Azure AD MFA is not enabled for the user
This policy identifies Azure users for whom AD MFA (Active Directory Multi-Factor Authentication) is not enabled. Azure AD MFA is a simple best practice that adds an extra layer of protection on top of your user name and password. MFA provides increased security for your Azure account settings and resources. Enabling Azure AD Multi-Factor Authentication using Conditional Access policies is the recommended approach to protect users.

For more details: 
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates
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: To enable per-user Azure AD Multi-Factor Authentication; follow below URL:
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-active-directory-credential-user-registration-details' AND json.rule = isMfaRegistered is false as X; config from cloud.resource where api.name = 'azure-active-directory-user' AND json.rule = accountEnabled is true as Y; filter '$.X.userDisplayName equals $.Y.displayName'; show X;```
AWS EKS cluster endpoint access publicly enabled
When you create a new cluster, Amazon EKS creates an endpoint for the managed Kubernetes API server that you use to communicate with your cluster (using Kubernetes management tools such as kubectl). By default, this API server endpoint is public to the internet, and access to the API server is secured using a combination of AWS Identity and Access Management (IAM) and native Kubernetes Role Based Access Control (RBAC).

This policy checks your Kubernetes cluster endpoint access and triggers an alert if publicly enabled.
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: Enable private access to the Kubernetes API server so that all communication between your worker nodes and the API server stays within your VPC. Disable public access to your API server so that it's not accessible from the internet.

1. Login to AWS Console
2. Navigate to the Amazon EKS dashboard
3. Choose the name of the cluster to display your cluster information
4. Under Networking, choose 'Manage networking'
5. Select 'Private' radio button
6. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-eks-describe-cluster' AND json.rule =  resourcesVpcConfig.endpointPublicAccess is true or resourcesVpcConfig.endpointPrivateAccess is false```
Azure VM disk configured with overly permissive network access
This policy identifies Azure Virtual Machine disks that are configured with overly permissive network access.

Enabling public network access provides overly permissive network access on Azure Virtual Machine disks, increasing the risk of unauthorized access and potential security breaches. Public network access exposes sensitive data to external threats, which attackers could exploit to compromise VM disks. Disabling public access and using Azure Private Link reduces exposure, ensuring only trusted networks have access and enhancing the security of your Azure environment by minimizing the risk of data leaks and breaches.

As a security best practice, it is recommended to disable public network access for Azure Virtual Machine disks.
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 the Azure portal
2. Navigate to 'Disks'
3. Click on the reported disk
4. Under 'Settings', go to 'Networking'
5. Ensure that Network access is NOT set to 'Enable public access from all networks'
6. Click 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-disk-list' AND json.rule = publicNetworkAccess equal ignore case Enabled and networkAccessPolicy equal ignore case AllowAll and managedBy contains virtualMachines```
IBM Cloud Service ID with IAM policies provide administrative privileges for Databases for PostgreSQL service
This policy identifies IBM Cloud Service ID, which has policy with administrator role permission for 'Databases for PostgreSQL' service. Service ID has full platform control as an administrator for 'Databases for PostgreSQL' service, including the ability to assign other users access policies and modify deployment passwords. If a Service ID with administrator privilege becomes compromised, it may result in a compromised database. As a security best practice, it is advised to provide the least privilege access, such as allowing only the rights necessary to complete a task, instead of excessive permissions.
This is applicable to ibm cloud and is considered a low severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. Log in to the IBM Cloud console.
2. In the IBM Cloud console, click 'Manage' on the title bar > 'Access (IAM)', click on 'Service IDs' in the left panel.
3. Select the Service ID which is reported and you want to edit access for.
4. Under the 'Access' tab, go to the 'Access policies' section > Click on three dots on the right corner of a row for the policy, which has administrator permission on 'Databases for PostgreSQL' service.
5. Click on Remove OR Edit to assign limited permission to the policy.
6. Review the policy details that you're about to Edit/Remove, and confirm by clicking Save/Remove..

Query:
```config from cloud.resource where api.name = 'ibm-iam-policy' AND json.rule = type equal ignore case "access" and roles[?any( role_id contains "crn:v1:bluemix:public:iam::::role:Administrator" )] exists and resources[?any( attributes[?any( name equal ignore case "serviceName" and value equal ignore case "databases-for-postgresql" and operator is member of ("stringEquals", "stringMatch"))] exists and attributes[?any( name is member of ("region","resourceGroupId","serviceInstance"))] does not exist )] exists and subjects[?any( attributes[?any( name contains "iam_id" and value contains "iam-ServiceId")] exists )] exists as X;config from cloud.resource where api.name = 'ibm-iam-service-id' as Y; filter '$.X.subjects[*].attributes[*].value contains $.Y.iam_id'; show Y;```
Azure Network Security Group allows all traffic on NetBIOS (UDP Port 137)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on NetBIOS (UDP Port 137). 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(137,137) or destinationPortRanges[*] contains _Port.inRange(137,137) ))] exists```
Azure Cognitive Services account configured with public network access
This policy identifies Azure Cognitive Services accounts configured with public network access. Overly permissive public network access allows access to resource through the internet using a public IP address. It is recommended to restrict IP ranges to allow access to your cognitive Services account and endpoint from specific public internet IP address ranges and is accessible only to restricted entities.
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: To restirct internet IP ranges on your existing Cognitive Services account, follow the below URL:
https://learn.microsoft.com/en-us/azure/ai-services/cognitive-services-virtual-networks?tabs=portal.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cognitive-services-account' AND json.rule = properties.provisioningState equal ignore case Succeeded and properties.publicNetworkAccess equal ignore case Enabled and (properties.networkAcls.defaultAction does not exist or properties.networkAcls.defaultAction equal ignore case Allow)```
Azure Storage account with cross tenant replication enabled
This policy identifies Azure Storage accounts that are enabled with cross tenant replication.

Azure Storage account cross tenant replication allows data to be replicated across multiple Azure tenants. Though this feature is beneficial for data availability it also poses a significant security risk if not properly managed. Possible risks include unauthorized access to data, data leaks, and compliance violations. Disabling Cross Tenant Replication reduces the risk of unauthorized data access and prevents the accidental sharing of sensitive information.

As best practice, it is recommended to disable cross tenant replication on your storage accounts.
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. Go to Storage Account dashboard
3. Click on the reported Storage Account
4. Under 'Data management', select 'Object replication'
5. Select 'Advanced settings'
6. Uncheck 'Allow cross-tenant replication'
7. Click on 'OK'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-storage-account-list' AND json.rule = properties.provisioningState equal ignore case Succeeded and properties.allowCrossTenantReplication exists and properties.allowCrossTenantReplication is true```
IBM Cloud Support Access Group to manage incidents has not been created
This policy identifies IBM Cloud accounts with no access group to manage support incidents. Support cases are used to raise issues with IBM Cloud. Users with access to the IBM Cloud Support Center can create and/or manage support tickets based on their IAM role. Support Center access should be managed and assigned using Access Groups.
This is applicable to ibm 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. In the IBM Cloud console, Under the 'Manage' dropdown click on 'Access (IAM)', and then select Access Groups.
2. Select 'Create Access Group'.
3. Give the Access Group a descriptive name, for example, Support Center Viewers or Support Center Admins.
4. Optionally, provide a brief description.
5. Click 'Create'.
6. Once the Access Group is created, click on the 'Access' tab.
7. Click 'Assign Access'. Under the 'Service' section search for 'Support Center' and select.
8. Under 'Resources' select All Resources.
9. Select the Support Center role(s) higher than the viewer.
10. Click add.
11. Click Assign.
12. Click on the 'Users' tab.
13. Click Add users
14. Select users from the list and click 'Add to group'..

Query:
```config from cloud.resource where api.name = 'ibm-iam-policy' AND json.rule = type equal ignore case access and roles[?any( role_id is member of (crn:v1:bluemix:public:iam::::role:Administrator,crn:v1:bluemix:public:iam::::role:Editor,crn:v1:bluemix:public:iam::::role:Viewer ) )] exists and resources[?any( attributes[?any( value equal ignore case support and operator is member of (stringEquals, stringMatch))] exists)] exists and subjects[?any( attributes[?any( value contains AccessGroupId)] exists )] exists as X; count(X) less than 1```
Azure Network Security Group allows all traffic on SMTP (TCP Port 25)
This policy identifies Azure Network Security Groups (NSG) that allow all traffic on SMTP (TCP Port 25). Review your list of NSG rules to ensure that your resources are not exposed. As a best practice, restrict SMTP 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 Tcp or protocol equals *) and (destinationPortRange contains _Port.inRange(25,25) or destinationPortRanges[*] contains _Port.inRange(25,25) ))] exists```
API automation policy ajtmu

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 api.name = "aws-ec2-describe-instances" AND json.rule = architecture contains "foo"```
Azure Storage Logging is not Enabled for Queue Service for Read Write and Delete requests

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 api.name = 'azure-storage-account-list' as X; config from cloud.resource where api.name = 'azure-storage-account-queue-diagnostic-settings' AND json.rule = properties.logs[*].enabled all true as Y; filter 'not($.X.id contains $.Y.properties.storageAccountId)'; show X;```
OCI VCN subnet flow logging is disabled
This policy identifies Virtual Cloud Network (VCN) subnets that have flow logs disabled.

Enabling VCN flow logs enables you to monitor traffic flowing within your virtual network and can be used to detect anomalous traffic. Without the flow logs turned on, it is not possible to get any visibility into network traffic.

It is recommended to enable a VCN flow log on each of your VCN subnets.
This is applicable to oci cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To configure VCN flow log for reported subnet, follow below URL:
https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/vcn-flow-logs-enable.htm#vcn-flow-logs-enable.

Query:
```config from cloud.resource where api.name = 'oci-networking-subnet' as X; config from cloud.resource where api.name = 'oci-logging-logs' AND json.rule = lifecycleState equals ACTIVE and isEnabled is true and configuration.source.service contains flowlogs as Y; filter 'not ($.X.id contains $.Y.configuration.source.resource)'; show X;```