knarayan/cloud_posture_checks huggingface dataset:
AWS SNS topic with cross-account access
This policy identifies AWS SNS topics that are configured with cross-account access. Allowing unknown cross-account access to your SNS topics will enable other accounts and gain control over your AWS SNS topics. To prevent unknown cross-account access, allow only trusted entities to access your Amazon SNS topics by implementing the appropriate SNS policies.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['CROSS_ACCOUNT_TRUST'].
Mitigation of this issue can be done as follows: 1. Log in to the AWS 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. Navigate to the 'Simple Notification Service' dashboard
4. Go to 'Topics', from the left panel
5. Select the reported SNS topic
6. Click on the 'Edit' button from the top options bar
7. On the edit page go to the 'Access Policy - optional' section
8. In the Access Policy section, verify all ARN values in 'Principal' elements are from trusted entities; If not remove those ARN from the entry.
9. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-sns-get-topic-attributes' AND json.rule = Policy.Statement[?any(Effect equals Allow and (Principal.AWS does not equal * and Principal does not equal * and Principal.AWS contains arn and Principal.AWS does not contain $.Owner))] exists```
GCP PostgreSQL instance database flag cloudsql.enable_pgaudit is not set to on
This policy identifies PostgreSQL database instances in which database flag cloudsql.enable_pgaudit is not set to on. Enabling the flag cloudsql.enable_pgaudit enables the logging by pgAudit extenstion for the database (if installed). The pgAudit extenstion for PostgreSQL databases provides detailed session and object logging to comply with government, financial, & ISO standards and provides auditing capabilities to mitigate threats by monitoring security events on the instance. Any changes to the database logging configuration should be made in accordance with the organization's logging policy.
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: It is recommended to set the 'cloudsql.enable_pgaudit' flag to 'on' for PostgreSQL database.

To update the flag of GCP PostgreSQL instance, please refer to the URL given below and set cloudsql.enable_pgaudit flag to on:
https://cloud.google.com/sql/docs/postgres/flags#set_a_database_flag.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = "databaseVersion contains POSTGRES and (settings.databaseFlags[?(@.name=='cloudsql.enable_pgaudit')] does not exist or settings.databaseFlags[?(@.name=='cloudsql.enable_pgaudit')].value does not equal on)"```
Azure Key Vault is not recoverable
The key vault contains object keys, secrets and certificates. Accidental unavailability of a key vault can cause immediate data loss or loss of security functions (authentication, validation, verification, non-repudiation, etc.) supported by the key vault objects.
It is recommended the key vault be made recoverable by enabling the "Do Not Purge" and "Soft Delete" functions. This is in order to prevent loss of encrypted data including storage accounts, SQL databases, and/or dependent services provided by key vault objects (Keys, Secrets, Certificates) etc., as may happen in the case of accidental deletion by a user or from disruptive activity by a malicious user.
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: Azure Portal
Azure Portal does not have provision to update the respective configurations

Azure CLI 2.0
az resource update --id /subscriptions/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<resourceGroupName>/providers/Microsoft.KeyVault/vaults/<keyVaultName> --set properties.enablePurgeProtection=true properties.enableSoftDelete=true.

Query:
```config from cloud.resource where api.name = 'azure-key-vault-list' AND json.rule = 'properties.enableSoftDelete does not exist or properties.enablePurgeProtection does not exist'```
RLP-83104 - Copy of Critical of AWS S3 bucket publicly readable
This policy identifies the S3 buckets that are publicly readable by Get/Read/List bucket operations. These permissions permit anyone, malicious or not, to Get/Read/List bucket operations on your S3 bucket if they can guess the namespace. S3 service does not protect the namespace if ACLs and Bucket policy is not handled properly, with this configuration you may be at risk of compromise of critical data by leaving S3 public.

For more details:
https://docs.aws.amazon.com/AmazonS3/latest/user-guide/set-permissions.html
https://docs.aws.amazon.com/AmazonS3/latest/dev/about-object-ownership.html#ensure-object-ownership 
This is applicable to aws cloud and is considered a critical severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: 1. Log in 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' tab
5. If Access Control List is set to 'Public' follow the below steps
a. Under 'Access Control List', Click on 'Everyone' and uncheck all items
b. Click on Save changes
6. If 'Bucket Policy' is set to public follow the below steps
a. Under 'Bucket Policy', Select 'Edit Bucket Policy' and consider defining what explicit 'Principal' should have the ability to GET/LIST objects in your S3 bucket. You may also want to specifically limit the 'Principal' ability to perform specific GET/LIST functions, without the wild card.
If 'Bucket Policy' is not required delete the existing 'Bucket Policy'.
b. Click on Save changes

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 = ((((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)) and acl.grantsAsList[?any(grantee equals AllUsers and permission is member of (ReadAcp,Read,FullControl))] exists) 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))) and (policy.Statement[?any(Effect equals Allow and (Principal equals * or Principal.AWS equals *) and (Action contains s3:* or Action contains s3:Get or Action contains s3:List) and (Condition does not exist))] exists))) and websiteConfiguration does not exist```
ajay ec2 describe

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-describe-instances' AND json.rule = enaSupport is true and clientToken contains "foo" ```
AWS Opensearch domain Error logging disabled
This policy identifies AWS Opensearch domains with no error logging configuration.

Opensearch application logs contain information about errors and warnings raised during the operation of the service and can be useful for troubleshooting. Error logs from domains can aid in security assessments, access monitoring, and troubleshooting availability problems.

It is recommended to enable the AWS Opensearch domain with error logs, which will help in security audits and troubleshooting.
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 the AWS Opensearch domain with error logs:

1. Sign into the AWS console and navigate to the Opensearch Service Dashboard
2. In the navigation pane, under 'Managed Clusters', select 'Domains'
2. Choose the reported Elasticsearch domain
3. On the Logs tab, select 'Error logs' and choose 'Enable'.
4. In the 'Set up error logs' section, in the 'Select log group from CloudWatch logs' setting, Create/Use existing CloudWatch Logs log group as per your requirement
5. In 'Specify CloudWatch access policy', create new/Select an existing policy as per your requirement
6. Click on 'Enable'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-es-describe-elasticsearch-domain' AND json.rule = domainProcessingStatus equal ignore case active and (logPublishingOptions does not exist or logPublishingOptions.ES_APPLICATION_LOGS.enabled is false)```
AWS Macie is not enabled
This policy identifies the AWS Macie that is not enabled in specific regions. 

AWS Macie is a data security service that automatically discovers, classifies, and protects sensitive data in AWS, enhancing security and compliance posture. Failure to activate AWS Macie increases the risk of potentially missing out on automated detection and protection of sensitive data, leaving your organization more vulnerable to data breaches and compliance violations.

It is recommended to enable Macie in all regions for comprehensive adherence to security and compliance requirements.
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 Macie in the specific region,

1. Log in to your AWS Management Console.
2. By using the AWS Region selector in the upper-right corner of the page, select the Region which is reported.
3. In the AWS Management Console, search for "Macie" in the services search bar or locate it under the "Security, Identity, & Compliance" category.
4. On the Amazon Macie page, choose Get started.
5. Choose Enable Macie.

To re-enable macie after suspended in the region,

1. Log in to your AWS Management Console.
2. By using the AWS Region selector in the upper-right corner of the page, select the Region which is reported.
3. In the AWS Management Console, search for "Macie" in the services search bar or locate it under the "Security, Identity, & Compliance" category.
4. In the Macie dashboard, navigate to the 'settings' section.
5. Click on the 'Re-enable Macie' button under the 'Suspend Macie' section.

After enabling Macie, you can further configure policies, alerts, and other settings according to your organization's security and compliance needs..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-macie2-session' AND json.rule = status equals "ENABLED" as X; count(X) less than 1```
AWS CloudFront web distribution with geo restriction disabled
This policy identifies CloudFront web distributions which have geo restriction feature disabled. Geo Restriction has the ability to block IP addresses based on Geo IP by allowlist or denylist a country in order to allow or restrict users in specific locations from accessing web application content.
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. Sign in to the AWS console
2. Select the region, from the region drop-down, in which the alert is generated
3. Navigate to CloudFront Distributions Dashboard
4. Click on the reported distribution
5. On 'Restrictions' tab, Click on the 'Edit' button
6. On 'Edit Geo-Restrictions' page, Set 'Enable Geo-Restriction' to 'Yes' and allowlist/denylist countries as per your requirement.
7. Click on 'Yes, Edit'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = 'restrictions.geoRestriction.restrictionType contains none'```
GCP MySQL instance database flag skip_show_database is not set to on
This policy identifies Mysql database instances in which database flag skip_show_database is not set to on. This prevents people from using the SHOW DATABASES statement if they do not have the SHOW DATABASES privilege. This can improve security if you have concerns about users being able to see databases belonging to other users. It is recommended to set skip_show_database to on.
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. Log in to GCP console
2. Navigate SQL Instances page
3. Click on reported MYSQL instance
4. Click on 'EDIT'
NOTE: If the instance is stopped, You need to START instance first to edit the configurations, then Click on EDIT.
5. If the flag has not been set on the instance, 
Under 'Customize your instance', click on 'ADD FLAG' in 'Flags' section, choose the flag 'skip_show_database' from the drop-down menu and set the value as 'on'
OR
If the flag has been set to off, Under 'Customize your instance', In 'Flags' section choose the flag 'skip_show_database' and set the value as 'on', Click on DONE
6. Click on 'DONE' and then 'SAVE' and if popup window appears, select 'SAVE AND RESTART'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = state equals RUNNABLE and databaseVersion contains MYSQL and (settings.databaseFlags[*].name does not contain skip_show_database or settings.databaseFlags[?any(name contains skip_show_database and value does not contain on)] exists)```
GCP IAM user have overly permissive Cloud KMS roles
This policy identifies IAM users who have overly permissive Cloud KMS roles. Built-in/Predefined IAM role Cloud KMS Admin allows the user to create, delete, and manage service accounts. Built-in/Predefined IAM role Cloud KMS CryptoKey Encrypter/Decrypter allows the user to encrypt and decrypt data at rest using the encryption keys. It is recommended to follow the principle of 'Separation of Duties' ensuring that one individual does not have all the necessary permissions to be able to complete a malicious action.
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: 1. Login to GCP Portal
2. Go to IAM & Admin (Left Panel)
3. Select IAM
4. From the list of users, choose the reported IAM user
5. Click on Edit permissions pencil icon
6. For member having 'Cloud KMS Admin' and any of the 'Cloud KMS CryptoKey Encrypter/Decrypter', 'Cloud KMS CryptoKey Encrypter', 'Cloud KMS CryptoKey Decrypter' or any CryptoKey roles granted/assigned, Click on the Delete Bin icon to remove the role from a member.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-projects-get-iam-user' AND json.rule = 'roles[*] contains roles/cloudkms.admin and roles[*] contains roles/cloudkms.crypto'```
xnbnuowcaz_ui_auto_policies_tests_name
kszyashfvs_ui_auto_policies_tests_descr
This is applicable to aws cloud and is considered a critical 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-iam-list-users' AND json.rule = createDate contains 2018```
IBM Cloud PostgreSQL Database network access is not restricted to a specific IP range
This policy identifies IBM Cloud PostgreSQL Databases with no specified IP range for network access. To restrict access to your databases, you can allowlist specific IP addresses or ranges of IP addresses on your deployment. When no IP addresses are in the allowlist, the allowlist is disabled and the deployment accepts connections from any IP address. It is recommended to create an allowlist, only IP addresses that match the allowlist or are in the range of IP addresses in the allowlist can connect to your deployment.
This is applicable to ibm cloud and is considered a medium 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. Click on 'Menu Icon' and navigate to 'Resource list', from the list of resources select PostgreSQL database reported in the alert.
3. Refer below URL for setting allowlist IP addresses : 
https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-allowlisting&interface=ui#set-allowlist-ui
4. Please remove IP address starting with '0.0.0.0' if any added already in the allow list and make sure to add IP address other than '0.0.0.0'..

Query:
```config from cloud.resource where cloud.type = 'ibm' AND api.name = 'ibm-postgresql-deployment-info' AND json.rule = allowedListIPAddresses[*] size equals 0 or allowedListIPAddresses[?any( address equals 0.0.0.0/0 )] exists```
AWS Elastic Load Balancer v2 (ELBv2) with deletion protection disabled
This policy identifies Elastic Load Balancers v2 (ELBv2), which are configured with the deletion protection feature disabled.

AWS Elastic Load Balancer automatically distributes incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses, to improve the availability and fault tolerance of applications. To prevent your load balancer from being deleted accidentally, you can enable deletion protection.

It is recommended to enable deletion protection on AWS Elastic load balancers to protect them from being deleted accidentally.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To enable deletion protection on load balancer:

1. Log in to the AWS console. Navigate to EC2 dashboard
2. Select 'Load Balancers'
3. Click on the reported Load Balancer
4. On the 'Attributes' tab, choose 'Edit'
5. On the Edit load balancer attributes page, select 'Enable' for 'Delete Protection'
6. Click on 'Save' to save your changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elbv2-describe-load-balancers' AND json.rule = ['attributes'].['deletion_protection.enabled'] contains false```
AWS S3 bucket not configured with secure data transport policy
This policy identifies S3 buckets which are not configured with secure data transport policy. AWS S3 buckets should enforce encryption of data over the network using Secure Sockets Layer (SSL). It is recommended to add a bucket policy that explicitly denies (Effect: Deny) all access (Action: s3:*) from anybody who browses (Principal: *) to Amazon S3 objects within an Amazon S3 bucket if they are not accessed through HTTPS (aws:SecureTransport: false).
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: 1. Sign into the AWS console
2. Navigate to Amazon S3 Dashboard
3. Click on 'Buckets' (Left Panel)
4. Choose the reported S3 bucket
5. On 'Permissions' tab, Click on 'Bucket Policy'
6. Add a bucket policy that explicitly denies (Effect: Deny) all access (Action: s3:) from anybody who browses (Principal: ) to Amazon S3 objects within an Amazon S3 bucket if they are not accessed through HTTPS (aws:SecureTransport: false). Below is the sample policy:
{
	"Sid": "ForceSSLOnlyAccess",
	"Effect": "Deny",
	"Principal": "*",
	"Action": "s3:GetObject",
	"Resource": "arn:aws:s3:::bucket_name/*",
	"Condition": {
			"Bool": {
			"aws:SecureTransport": "false"
		}
	}
}.

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) or ((acl.grants[?(@.grantee=='AllUsers')] size > 0) and publicAccessBlockConfiguration.ignorePublicAcls is false) or (policyStatus.isPublic is true and publicAccessBlockConfiguration.restrictPublicBuckets is false)) and websiteConfiguration does not exist) and ((policy.Statement[*].Condition.Bool.aws:SecureTransport does not exist) or ((policy.Statement[?(@.Principal=='*' || @.Principal.AWS=='*')].Action contains s3: or policy.Statement[?(@.Principal=='*' || @.Principal.AWS=='*')].Action[*] contains s3:) and (policy.Statement[?(@.Principal=='*' && @.Effect=='Allow')].Condition.Bool.aws:SecureTransport contains false or policy.Statement[?(@.Principal.AWS=='*' && @.Effect=='Allow')].Condition.Bool.aws:SecureTransport contains false or policy.Statement[?(@.Principal=='*' && @.Effect=='Allow')].Condition.Bool.aws:SecureTransport contains FALSE or policy.Statement[?(@.Principal.AWS=='*' && @.Effect=='Allow')].Condition.Bool.aws:SecureTransport contains FALSE or policy.Statement[?(@.Principal=='*' && @.Effect=='Deny')].Condition.Bool.aws:SecureTransport contains true or policy.Statement[?(@.Principal.AWS=='*' && @.Effect=='Deny')].Condition.Bool.aws:SecureTransport contains true or policy.Statement[?(@.Principal=='*' && @.Effect=='Deny')].Condition.Bool.aws:SecureTransport contains TRUE or policy.Statement[?(@.Principal.AWS=='*' && @.Effect=='Deny')].Condition.Bool.aws:SecureTransport contains TRUE)))"```
AWS IAM policy is overly permissive to all traffic via condition clause
This policy identifies IAM policies that have a policy that is overly permissive to all traffic via condition clause. If any IAM policy statement with a condition containing 0.0.0.0/0 or ::/0, it allows all traffic to resources attached to that IAM policy. It is highly recommended to have the least privileged IAM policy to protect the data leakage and unauthorized access.
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: 1. Log in to the AWS Console
2. Navigate to the IAM dashboard
3. Click on 'Policies' in left hand panel
4. Search for the Policy for which the alert is generated and click on it.
5. Under the Permissions tab, click on Edit policy
6. Under the Visual editor, click to expand and perform following;
a. Click to expand 'Request conditions'
b. Under the 'Source IP', remove the row with the entry '0.0.0.0/0' or '::/0'. Add condition with restrictive IP ranges.
7. Click on Review policy and Save changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-policy-version' AND json.rule = document.Statement[?any((Condition.ForAnyValue:IpAddress.aws:SourceIp contains 0.0.0.0/0 or Condition.IpAddress.aws:SourceIp contains 0.0.0.0/0 or Condition.IpAddress.aws:SourceIp contains ::/0 or Condition.ForAnyValue:IpAddress.aws:SourceIp contains ::/0) and Effect equals Allow and Action contains *)] exists```