knarayan/cloud_posture_checks huggingface dataset:
AWS Certificate Manager (ACM) contains certificate pending validation
This policy identifies invalid certificates which are in AWS Certificate Manager. When your Amazon ACM certificates are not validated within 72 hours after the request is made, those certificates become invalid and you will have to request new certificates, which could cause interruption to your applications or services. Though AWS Certificate Manager automatically renews certificates issued by the service that is used with other AWS resources. However, the ACM service does not automatically renew certificates that are not currently in use or not associated anymore with other AWS resources. So the renewal process including validation must be done manually before these certificates become invalid.
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 validate Certificates: 
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. Go to Certificate Manager(ACM) service
4. Choose the reported certificate
5. Validate your certificate for your domain using either Email or DNS validation, depending upon your certificate validation method.

OR

If the certificate is not required you can delete that certificate. To delete invalid Certificates:
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. Go to Certificate Manager(ACM) service
4. Choose the reported certificate
5. Under 'Actions' drop-down click on 'Delete'

Note: This alert will get auto-resolved, as the certificate becomes invalid in 72 hours. It is recommended to either delete or validate the certificate within the timeframe..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-acm-describe-certificate' AND json.rule =  'status contains PENDING_VALIDATION'```
Alibaba Cloud RAM user has both console access and access keys
This policy identifies Resource Access Management (RAM) users who have both console access and access keys. When a RAM user is created, the Administrator can assign either console access or access keys or both. As a best practice, it is recommended to assign console access to users and access keys for system / API applications, but not both to the same RAM user.
This is applicable to alibaba_cloud cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['KEYS_AND_SECRETS'].
Mitigation of this issue can be done as follows: 1. Log in to Alibaba Cloud Portal
2. Go to Resource Access Management
3. In the left-side navigation pane, click 'Users'
4. Click on reported user
5. Based on the requirement and company policy, either delete the access keys or Remove Logon Settings for the reported RAM user..

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ram-user' AND json.rule =  'accessKeys[*] size > 0 and accessKeys[*].status any equal Active and loginProfile[*] is not empty'```
IBM Cloud Service ID with IAM policies provide administrative privileges for Secrets Manager service
This policy identifies IBM Cloud Service ID, which has policy with administrator role permission for the Secrets Manager service. A Service ID with admin access will be able to perform all platform tasks for Secrets Manager, including the creation, modification, and deletion of Secrets Manager service instances, as well as the assignment of access policies to other users. On Secret Manager, there is a chance that sensitive data might be exposed in the underlying service if a Service ID with administrative rights is compromised. As a security best practice, it is recommended to grant the least privilege access, such as granting only the permissions required to perform a task, instead of providing 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 'Secrets Manager' 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 "secrets-manager" and operator is member of ("stringEquals", "stringMatch"))] exists and attributes[?any( name is member of ("region","resource","resourceGroupId","resourceType","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 Activity log alert for Delete SQL server firewall rule does not exist
This policy identifies the Azure accounts in which activity log alert for Delete SQL server firewall rule does not exist. Creating an activity log alert for Delete SQL server firewall rule gives insight into SQL server firewall rule 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 'Delete server firewall rule (Microsoft.Sql/servers/firewallRules)' 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.Sql/servers/firewallRules/delete" as X; count(X) less than 1```
IBM Cloud Default Security Group allow ingress rule from 0.0.0.0/0
This policy identifies IBM Cloud Default Security Groups which has ingress rules that allow traffic from 0.0.0.0/0. A VPC comes with a default security group whose initial configuration allows access from all members that are attached to this security group. If you do not specify a security group when you launch a Virtual Server, the Virtual Server is automatically assigned to this default security group. As a result, the Virtual Server will be having risk of uncontrolled connectivity. It is recommended that Default Security Group allows network ports, protocols, and services listening on a system with validated business needs that are running on each system.
This is applicable to ibm cloud and is considered a high severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: Before making any changes, please check the impact to your applications/services. If the Security Groups reported indeed need to restrict all traffic, follow the instructions below:
1. Log in to the IBM Cloud Console
2. Click on 'Menu Icon' and navigate to 'VPC Infrastructure' and then 'Security Groups'
3. Select the 'Security Groups' reported in the alert
4. Go to 'Inbound rules' under 'Rules' tab
5. Click on three dots on the right corner of a row containing rule that has 'Source type' as 'Any' or 'Source' as Security Groups name
6. Click on 'Delete'.

Query:
```config from cloud.resource where api.name = 'ibm-vpc-network-security-group' AND json.rule = rules[?any( ( remote.cidr_block equals "0.0.0.0/0" or remote.name equals $.name ) and direction equals "inbound" )] exists as X; config from cloud.resource where api.name = 'ibm-vpc' as Y; filter ' $.X.id equals $.Y.default_security_group.id '; show X;```
bikram-test-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.account = 'Bikram-Personal-AWS Account' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = versioningConfiguration.status contains "Off" ```
Azure Key Vault Purge protection is not enabled
This policy identifies Azure Key Vault which has Purge protection disabled. Enabling Azure Key Vault Purge protection feature prevents malicious deletion of a key vault which can lead to permanent data loss. It is recommended to enable Purge protection for Azure Key Vault which protects by enforcing a mandatory retention period for soft deleted key vaults.
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 'Key vaults', and select the reported key vault from the list
3. Under 'Settings' select 'Properties'
4. For 'Purge protection' click on 'Enable Purge protection (enforce a mandatory retention period for deleted vaults and vault objects)'
5. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-key-vault-list' AND json.rule = properties.enablePurgeProtection is false```
AWS S3 Bucket Policy allows public access to CloudTrail logs
This policy scans your bucket policy that is applied to the S3 bucket to prevent public access to the CloudTrail logs. CloudTrail logs a record of every API call made in your AWS account. These logs file are stored in an S3 bucket. Bucket policy or the access control list (ACL) applied to the S3 bucket does not prevent public access to the CloudTrail logs. It is recommended that the bucket policy or access control list (ACL) applied to the S3 bucket that stores CloudTrail logs prevents public access. Allowing public access to CloudTrail log content may aid an adversary in identifying weaknesses in the affected account's use or configuration.
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: 1. Sign in to the AWS Console
2. Goto S3
3. Choose the reported S3 bucket and click Properties
4. In the Properties pane, click the Permissions tab.
5. If the Edit bucket policy button is present, select it.
6. Remove any statement having an effect Set to 'Allow' and a principal set to '*'.
Note: We recommend that you do not configure CloudTrail to write into an S3 bucket that resides in a different AWS account..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudtrail-describe-trails' as X; config from cloud.resource where api.name = 'aws-s3api-get-bucket-acl' as Y; filter "($.Y.bucketName==$.X.s3BucketName) and ($.Y.acl.grants[*].grantee contains AllUsers or $.Y.acl.grants[*].permission contains FullControl) and ($.Y.policy.Statement[?(@.Principal=='*' && @.Effect=='Allow')].Action contains s3:* or $.Y.policy.Statement[?(@.Principal.AWS=='*' && @.Effect=='Allow')].Action contains s3:*)" ; show Y;```
dnd_test_add_remove_child_policy_hyperion_policy_ss_finding_1
Description-e12f27fd-c82b-4362-8105-60994fe17eec
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = defaultRootObject is empty```
OCI boot volume is not encrypted with Customer Managed Key (CMK)
This policy identifies OCI boot volumes that are not encrypted with a Customer Managed Key (CMK).

Encrypting boot volumes with a CMK enhances data security by providing an additional layer of protection. Effective management of encryption keys is crucial for safeguarding and accessing sensitive data. Customers should review boot volumes encrypted with Oracle service managed keys to determine if they prefer managing keys for specific volumes and implement their own key lifecycle management accordingly.

As best practice, it is recommended to encrypt OCI boot volumes using a Customer Managed Key (CMK) to strengthen data security measures.
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. Log in to the OCI Console.
2. Switch to the Region of the reported resource from the Region drop-down in top-right corner.
3. Type the reported boot volume name into the Search box at the top of the Console.
4. Click on the reported boot volume from the search results.
5. Next to "Encryption Key", click on "Assign".
6. Choose the Vault Compartment, Vault, Master Encryption Key Compartment and Master Encryption Key.
7. Click Assign..

Query:
```config from cloud.resource where api.name = 'oci-block-storage-boot-volume' AND json.rule = lifecycleState equal ignore case "AVAILABLE" AND kmsKeyId is member of ("null")```
Copy of 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 [].
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```
AWS EKS control plane logging disabled
Amazon EKS control plane logging provides audit and diagnostic logs directly from the Amazon EKS control plane to CloudWatch Logs in your account. These logs make it easy for you to secure and run your clusters. You can select the exact log types you need, and logs are sent as log streams to a group for each Amazon EKS cluster in CloudWatch.

This policy generates an alert if control plane logging is disabled.
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 control plane logs:

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 Logging, choose 'Manage logging'
5. For each individual log type, choose Enabled
6. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-eks-describe-cluster' AND json.rule =  logging.clusterLogging[*].types[*] all empty or logging.clusterLogging[*].enabled is false```
AWS IAM policy attached to AWS Lambda execution role is overly permissive
This policy identifies Lambda Functions execution role having overly permissive IAM policy attached to it. Lambda functions having overly permissive policy could lead to lateral movement in account or privilege being escalated when compromised. It is highly recommended to have the least privileged access policy to protect the Lambda Functions from unauthorized access.
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: Refer to the following URL to give fine-grained and restrictive permissions to IAM Policy:
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html#edit-managed-policy-console.

Query:
```config from cloud.resource where api.name = 'aws-lambda-list-functions' as X; config from cloud.resource where api.name = 'aws-iam-list-roles' as Y; 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 equals "*" or Action contains :* or Action[*] contains :*) and (Resource equals "*" or Resource[*] anyStartWith "*") and Condition does not exist)] exists as Z; filter '$.X.role equals $.Y.role.arn and $.Y.attachedPolicies[*].policyName equals $.Z.policyName'; show Z;```
OCI IAM password policy for local (non-federated) users does not have a number
This policy identifies Oracle Cloud Infrastructure(OCI) accounts that do not have a number in the password policy for local (non-federated) users. As a security best practice, configure a strong password policy for secure access to the OCI console.
This is applicable to oci cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['WEAK_PASSWORD'].
Mitigation of this issue can be done as follows: 1. Login to the OCI Console Page: https://console.ap-mumbai-1.oraclecloud.com/
2. Go to Identity in the Services menu.
3. Select Authentication Settings from the Identity menu.
4. Click Edit Authentication Settings in the middle of the page.
5. Ensure the checkbox is selected next to MUST CONTAIN AT LEAST 1 NUMERIC CHARACTER.

Note : The console URL is region specific, your tenancy might have a different home region and thus console URL..

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-iam-authentication-policy' AND json.rule = 'passwordPolicy.isNumericCharactersRequired isFalse'```
AWS RDS database instance is publicly accessible
This policy identifies RDS database instances which are publicly accessible. DB instances should not be publicly accessible to protect the integrity of data. Public accessibility of DB instances can be modified by turning on or off the Public accessibility parameter.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
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 the 'RDS' service.
4. Select the RDS instance reported in the alert, Click on 'Modify' 
5. Under 'Network and Security', update the value of 'public accessibility' to 'No' and Click on 'Continue'
6. Select required 'Scheduling of modifications' option and click on 'Modify DB Instance'.

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name = 'aws-rds-describe-db-instances' AND json.rule = 'publiclyAccessible is true'```
AWS RDS Cluster snapshot is accessible to public
This policy identifies AWS RDS Cluster snapshots which is accessible to public. Amazon Relational Database Service (Amazon RDS) is a web service that makes it easier to setup and manage databases. If RDS Cluster snapshots are inadvertently shared to public, any unauthorized user with AWS console access can gain access to the snapshots and gain access to sensitive data.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: 1. Sign in to 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 the 'RDS' service
4. Click on 'Snapshots'
5. Under 'Manual' tab select the reported RDS Cluster
6. Click on 'Actions' and select 'Share snapshot'
7. Under 'DB snapshot visibility' select 'Private'
8. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name= 'aws-rds-db-cluster-snapshots' AND json.rule = dbclusterSnapshotAttributes[?any( attributeName equals restore and attributeValues[*] contains "all" )] exists```
Roman - AWS EBS volume region with encryption is disabled -  Revised for

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 api.name = 'aws-ec2-ebs-encryption' AND cloud.region IN ( 'AWS Ohio' ) AND json.rule = ebsEncryptionByDefault is false```
AWS API gateway request authorisation is not set
This policy identifies AWS API Gateways of protocol type REST for which the request authorisation is not set. The method request for API gateways takes the client input that is passed to the back end through the integration request. It is recommended to add authorization type to each of the method to add a layer of protection.
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 AWS management console
2. Navigate to 'API Gateway' service
3. Select the region for which the API gateway is reported.
4. Find the alerted API by the API gateway ID which is the first part of reported resource and click on it
5. Navigate to the reported method
6. Click on the clickable link of 'Method Request'
7. Under section 'Settings', click on the pencil symbol for 'Authorization' field
8. From the dropdown, Select the type of Authorization as per the requirement 
9. Click on the tick symbol next to it to save the changes.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-apigateway-method' AND json.rule = authorizationType contains NONE```