knarayan/cloud_posture_checks huggingface dataset:
GCP Log metric filter and alert does not exist for SQL instance configuration changes
This policy identifies the GCP account which does not have a log metric filter and alert for SQL instance configuration changes. Monitoring SQL instance configuration activities will help in reducing time to detect and correct misconfigurations done on sql server. It is recommended to create a metric filter and alarm to detect activities related to the SQL instance configuration.
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. Sign in to GCP Console
2. Navigate to 'Logs-based metrics' under the 'Logging' section.
3. Click on 'CREATE METRIC'.
4. Provide 'Metric Type' and 'Details'.
5. In 'Filter selection', add filter as 
protoPayload.methodName="cloudsql.instances.update"
6. Click on 'CREATE METRIC'.
7. Under 'User-defined metrics' section, choose the metric you created in step 6 and click on the kebab menu (Vertical 3 dots) on the right side of the metrics
8. Click on 'Create alert from metric'; it will navigate to 'Create alerting policy' under the section 'Monitoring'.
9. Add the metric name created above if not auto-filled in the Monitoring filter. Choose an appropriate value for other alert condition parameters as desired. Then Click on 'NEXT'
10. Configure all alert trigger settings as desired. Then Click on 'NEXT'
11. Configure notifications as desired and provide an appropriate name for the alert policy. Then Click on 'NEXT'
12. Click on 'CREATE POLICY'..

Query:
```config from cloud.resource where api.name = 'gcloud-logging-metric' as X; config from cloud.resource where api.name = 'gcloud-monitoring-policies-list' as Y; filter '$.Y.conditions[*].metricThresholdFilter contains $.X.name and ($.X.filter contains "protoPayload.methodName=" or $.X.filter contains "protoPayload.methodName =") and ($.X.filter does not contain "protoPayload.methodName!=" and $.X.filter does not contain "protoPayload.methodName !=") and $.X.filter contains "cloudsql.instances.update"'; show X; count(X) less than 1```
Azure AKS enable role-based access control (RBAC) not enforced
To provide granular filtering of the actions that users can perform, Kubernetes uses role-based access controls (RBAC). This control mechanism lets you assign users, or groups of users, permission to do things like create or modify resources, or view logs from running application workloads. These permissions can be scoped to a single namespace, or granted across the entire AKS cluster.

This policy checks your AKS cluster RBAC setting and alerts if disabled.
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 create a new AKS cluster with RBAC enabled, follow the below URL:
https://learn.microsoft.com/en-us/azure/aks/manage-azure-rbac#create-a-new-cluster-using-azure-rbac-and-managed-azure-ad-integration.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-kubernetes-cluster' AND json.rule =  properties.enableRBAC is false```
Azure Network Security Group having Inbound rule overly permissive to all traffic on TCP protocol
This policy identifies Azure Network Security Groups (NSGs) which are overly permissive to all traffic on TCP protocol. 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. As a best practice, it is recommended to configure NSGs to restrict traffic from known sources, allowing only authorized protocols and ports.
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: 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 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 equals Internet or sourceAddressPrefix equals * or sourceAddressPrefix equals 0.0.0.0/0 or sourceAddressPrefix equals ::/0) and protocol equals Tcp and access equals Allow and direction equals Inbound and destinationPortRange contains *)] exists```
AWS IAM deprecated managed policies in use by User
This policy checks for any usage of deprecated AWS IAM managed policies and returns an alert if it finds one in your cloud resources.

When AWS deprecate an IAM managed policy, a new alternative is released with improved access restrictions. Existing IAM users and roles can continue to use the previous policy without interruption, however new IAM users and roles will use the new replacement policy.

Before you migrate any user or role to the new replacement policy, we recommend you review their differences in the Policy section of AWS IAM console. If you require one or more of the removed permissions, please add them separately to any user or role.

List of deprecated AWS IAM managed policies:

AmazonElasticTranscoderFullAccess (replaced by AmazonElasticTranscoder_FullAccess)
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['UNUSED_PRIVILEGES'].
Mitigation of this issue can be done as follows: 1. Go to the AWS console IAM dashboard.
2. Click Policies on the left navigation menu.
3. Enter the deprecated IAM policy name into the filter.
4. Click on the policy name.
5. Select the Policy usage tab.
6. Check all attached users, make note of them, then select Detach.
7. Click Policies on the left navigation menu.
8. Enter the new IAM policy name into the filter.
9. Click on the policy name.
10. Select the Policy usage tab.
11. Select Attach and check all the users you made a note of.
12. Click Attach policy..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-list-attached-user-policies' AND json.rule = attachedPolicies[*].policyArn contains "arn:aws:iam::aws:policy/AmazonElasticTranscoderFullAccess"```
AWS S3 bucket encrypted using Customer Managed Key (CMK) with overly permissive policy
This policy identifies Amazon S3 buckets that use Customer Managed Keys (CMKs) for encryption that have a key policy overly permissive. Amazon S3 bucket encryption key overly permissive can result in the exposure of sensitive data and potential compliance violations. As a security best practice, It is recommended to follow the principle of least privilege ensuring that the KMS key policy does not have all the permissions to be able to complete a malicious action.
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: The following steps are recommended to add changes to existing key policy of the KMS key used by the S3 bucket
1. Log in to the AWS Console and navigate to the 'S3' service.
2. Click on the S3 bucket reported in the alert.
3. Click on the 'Properties' tab.
4. Under the 'Default encryption' section, click on the KMS key link in 'Encryption key ARN'.
5. Click on the 'Key policy' tab on the navigated KMS key window.
6. Click on 'Edit'.
7. Replace the 'Everyone' grantee (i.e. '*') from the Principal element value with an AWS account ID or an AWS account ARN.
 OR 
Add a Condition clause to the existing policy statement so that the KMS key is restricted.
8. Click on 'Save Changes'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name= 'aws-s3api-get-bucket-acl' AND json.rule = (sseAlgorithm contains "aws:kms" or sseAlgorithm contains "aws:kms:dsse") and kmsMasterKeyID exists as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' AND json.rule = keyMetadata.keyState equals Enabled and keyMetadata.keyManager equals CUSTOMER and policies.default.Statement[?any((Principal.AWS equals * or Principal equals *)and Condition does not exist)] exists as Y; filter '$.X.kmsMasterKeyID contains $.Y.key.keyArn' ; show X;```
Azure PostgreSQL Database Server 'Allow access to Azure services' enabled
This policy identifies Azure PostgreSQL Database Server which has 'Allow access to Azure services' settings enabled. When 'Allow access to Azure services' settings is enabled, PostgreSQL Database 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. Login to Azure console
2. Navigate to 'Azure Database for PostgreSQL servers' dashboard
3. Select the reported PostgreSQL server
4. Go to 'Connection security' under 'Settings'
5. Select 'No' for 'Allow access to Azure services' under 'Firewall rules'
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-postgresql-server' AND json.rule = properties.publicNetworkAccess equal ignore case Enabled and firewallRules.value[*].properties.startIpAddress equals "0.0.0.0" and firewallRules.value[*].properties.endIpAddress equals "0.0.0.0"```
AWS RDS database not encrypted using Customer Managed Key
This policy identifies RDS databases that are encrypted with default KMS keys and not with customer managed keys. As a best practice, use customer managed keys to encrypt the data on your RDS databases and maintain control of your keys and data on sensitive workloads.
This is applicable to aws 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: Because you can set AWS RDS database encryption only during database creation, the process for resolving this alert requires you to create a new RDS database with a customer managed key for encryption, migrate the data from the reported database to this newly created database, and delete the RDS database identified in the alert.

To create a new RDS database with encryption using a customer managed key:
1. Log in to the AWS console.
2. Select the region for which the alert was generated.
3. Navigate to the Amazon RDS Dashboard.
4. Select 'Create database'.
5. On the 'Select engine' page, select 'Engine options' and 'Next'.
6. On the 'Choose use case' page, select 'Use case' of database and 'Next'.
7. On the 'Specify DB details' page, specify the database details you need and click 'Next'.
Note: Amazon RDS encryption has some limitation on region and type instances. For Availability of Amazon RDS Encryption refer to: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html#Overview.Encryption.Availability
8. On the 'Configure advanced settings' page, Under 'Encryption', select 'Enable encryption' and select the customer managed key [i.e. Other than (default)aws/rds] from 'Master key' dropdown list].
9. Select 'Create database'.

To delete the RDS database that uses the default KMS keys, which triggered the alert:
1. Log in to the AWS console
2. Select the region for which the alert was generated.
3. Navigate to the Amazon RDS Dashboard.
4. Click on Instances, and select the reported RDS database.
5. Select the 'Instance actions' drop-down and click 'Delete'.
7. In the 'Delete' dialog, select the 'Create final snapshot?' checkbox, if you want a backup. Provide a name for the final snapshot, confirm deletion and select 'Delete'..

Query:
```config from cloud.resource where api.name = 'aws-rds-describe-db-instances' as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' as Y; filter '$.X.storageEncrypted is true and $.X.kmsKeyId equals $.Y.key.keyArn and $.Y.keyMetadata.keyManager contains AWS'; show X;```
AWS ECS task definition is not configured with read-only access to container root filesystems
This policy identifies the AWS Elastic Container Service (ECS) task definitions with readonlyRootFilesystem parameter set to false or if the parameter does not exist in the container definition within the task definition.

ECS root filesystem is the base filesystem that containers run on, providing the necessary environment and isolation for the containerized application.
If a containerized application is compromised, it could enable an attacker to alter the root file system of the host machine, thus compromising the entire system or application. This could lead to significant data loss, system crashes, or a broader security breach. 

It is recommended to limit all ECS containers to have read-only access on ECS task definition to limit the potential impact of a compromised container.
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 limit ECS task definitions to read-only access to root filesystems, perform the following actions:

1. Sign into the AWS console and navigate to the Amazon ECS console
2. In the navigation pane, choose 'Task definitions'
3. Choose the task definition that is reported
4. Select 'Create new revision', and then click on 'Create new revision'
5. On the 'Create new task definition revision' page, select the container with Read-only root file system disabled
6. Under the 'Read-only root file system' section, enable 'Read only'
7. Specify the remaining configuration as per the requirements
8. Choose 'Create'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ecs-describe-task-definition' AND json.rule = status equals "ACTIVE" AND containerDefinitions[*].readonlyRootFilesystem any false or containerDefinitions[*].readonlyRootFilesystem does not exist```
AWS EKS cluster public endpoint access overly permissive to all traffic
This policy identifies EKS clusters that have an overly permissive public endpoint accessible to all traffic. 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 accepts all connections from public 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).

Allowing all traffic to EKS cluster may allow a bad actor to brute force their way into the system and potentially get access to the entire network. As a best practice, restrict traffic solely from known static IP addresses. Limit the access list to include known hosts, services, or specific employees only.
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: Either disable public access to your API server so that it's not accessible from the internet and allow only private access, or restrict traffic solely from known static IP addresses.

For more details on Amazon EKS cluster endpoint access control, follow below mentioned URL:
https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-eks-describe-cluster' AND json.rule = resourcesVpcConfig.endpointPublicAccess is true and resourcesVpcConfig.publicAccessCidrs contains "0.0.0.0/0"```
OCI Event Rule and Notification does not exist for Network Security Groups changes
This policy identifies the OCI compartments which do not have an Event Rule and Notification that gets triggered for Network Security Group (NSG) changes. Monitoring and alerting on changes to security groups will help in identifying changes to traffic flowing between Virtual Network Cards attached to Compute instances. It is recommended that an Event Rule and Notification be configured to catch changes made to Network Security Groups.
NOTE: 
1. Event Rules are compartment scoped and will detect events in child compartments, it is recommended to create the Event rule at the root compartment level.
2. This policy will trigger alert if you have at least one Event Rule and Notification, even if OCI has single or multi compartments.
This is applicable to oci cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Login to the OCI Console
2. Type the Event into the Search box at the top of the Console.
3. Click the Event Service from the Services submenu
4. Select the compartment that should host the rule
5. Click Create Rule
6. Provide a Display Name and Description
7. Create a Rule Condition by selecting Networking in the Service Name Drop-down and selecting Network Security Group – Change Compartment, Network Security Group – Create, Network Security Group - Delete and Network Security Group – Update
8. In the Actions section select Notifications as Action Type
9. Select the Compartment that hosts the Topic to be used.
10. Select the Topic to be used
11. Optionally add Tags to the Rule
12. Click Create Rule.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-events-rule' AND json.rule = '(isEnabled equals true) and (actions.actions[?any( actionType equals ONS and isEnabled equals true and lifecycleState equals ACTIVE)] exists) and (condition.eventType[*] contains com.oraclecloud.virtualnetwork.changenetworksecuritygroupcompartment and condition.eventType[*] contains com.oraclecloud.virtualnetwork.createnetworksecuritygroup and condition.eventType[*] contains com.oraclecloud.virtualnetwork.deletenetworksecuritygroup and condition.eventType[*] contains  com.oraclecloud.virtualnetwork.updatenetworksecuritygroup) and actions.actions[*].topicId exists' as X; count(X) less than 1```
AWS Log metric filter and alarm does not exist for Route table changes
This policy identifies the AWS regions which do not have a log metric filter and alarm for Route table changes. Monitoring changes to route tables will help ensure that all VPC traffic flows through an expected path. It is recommended that a metric filter and alarm be established for changes to route tables.

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 = CreateRoute) || ($.eventName = CreateRouteTable) || ($.eventName = ReplaceRoute) || ($.eventName = ReplaceRouteTableAssociation) || ($.eventName = DeleteRouteTable) || ($.eventName = DeleteRoute) || ($.eventName = DisassociateRouteTable) }
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 CreateRoute and $.X.filterPattern contains CreateRouteTable and $.X.filterPattern contains ReplaceRoute and $.X.filterPattern contains ReplaceRouteTableAssociation and $.X.filterPattern contains DeleteRouteTable and $.X.filterPattern contains DeleteRoute and $.X.filterPattern contains DisassociateRouteTable) and ($.X.metricTransformations[*] contains $.Y.metricName))'; show X; count(X) less than 1```
Azure Activity log alert for Create or update network security group does not exist
This policy identifies the Azure accounts in which activity log alert for Create or update network security group does not exist. Creating an activity log alert for Create or update network security group gives insight into network access changes and may reduce the time it takes to detect suspicious activity.
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 'Create or Update Network Security Group (Microsoft.Network/networkSecurityGroups)' 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/networkSecurityGroups/write" as X; count(X) less than 1```