knarayan/cloud_posture_checks huggingface dataset:
AWS Cognito service role with wide privileges does not validate authentication
This policy identifies the AWS Cognito service role that has wide privileges and does not validate user authentication.

AWS Cognito is an identity and access management service for web and mobile apps. AWS Cognito service roles define permissions for AWS services accessing resources. The 'amr' field in the service role represents how the user was authenticated. if the user was authenticated using any of the supported providers, the 'amr' will contain 'authenticated' and the name of the provider. Not validating the 'amr' field can allow an unauthenticated user (guest access) with a valid token signed by the identity-pool to assume the Cognito role. If this Cognito role has a '*' wildcard in the action and resource, it could lead to lateral movement or unauthorized access.

Ensuring limiting privileges according to business requirements can help in restricting unauthorized access and misuse of resources. It is recommended to limit the Cognito service role used for guest access to not have a '*' wildcard in the action or resource.
This is applicable to aws cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['HIGH_PRIVILEGED_ROLE'].
Mitigation of this issue can be done as follows: To remove the policy which have excessive permission from the guess access role,
1. Log in to the AWS console.
2. Navigate to the IAM service.
3. Click on Roles.
4. Click on the reported IAM role.
5. Under 'Permissions policies' section, remove the policy having excessive permissions and assign a limited permission policy as required for a particular role..

Query:
```config from cloud.resource where api.name = 'aws-iam-list-roles' AND json.rule = role.assumeRolePolicyDocument.Statement[*].Action contains "sts:AssumeRoleWithWebIdentity" and role.assumeRolePolicyDocument.Statement[*].Principal.Federated contains "cognito-identity.amazonaws.com" and role.assumeRolePolicyDocument.Statement[*].Effect contains "Allow" and role.assumeRolePolicyDocument.Statement[*].Condition contains "cognito-identity.amazonaws.com:amr" and role.assumeRolePolicyDocument.Statement[*].Condition contains "unauthenticated" as X; config from cloud.resource where api.name = 'aws-iam-get-policy-version' AND json.rule = document.Statement[?any(Effect equals Allow and Action contains :* and Resource equals * )] exists as Y; filter "($.X.inlinePolicies[*].policyDocument.Statement[?(@.Effect=='Allow' && @.Resource=='*')].Action contains :* ) or ($.X.attachedPolicies[*].policyArn intersects $.Y.policyArn)"; show X;```
AWS SageMaker notebook instance not configured with data encryption at rest using KMS key
This policy identifies SageMaker notebook instances that are not configured with data encryption at rest using the AWS managed KMS key. It is recommended to implement encryption at rest in order to protect data from unauthorized entities.

For more details:
https://docs.aws.amazon.com/sagemaker/latest/dg/encryption-at-rest.html
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['UNENCRYPTED_DATA'].
Mitigation of this issue can be done as follows: AWS SageMaker notebook instance can not be configured with data encryption at rest once it is created. You need to create a new notebook instance with encryption at rest using the KMS key; migrate all required data from the reported notebook instance to the newly created notebook instance before you delete the reported notebook instance.

To create a New AWS SageMaker notebook instance,
1. Log in to AWS console
2. Navigate to the AWS SageMaker dashboard
3. Choose Notebook instances and then choose 'Create notebook instance'
4. On the Create notebook instance page, From the 'Permissions and encryption' section, 
select the KMS key from the 'Encryption key - optional' dropdown list. If no KMS keys already, you have to create a KMS key first.
5. Choose other parameters as per your requirement and click on the 'Create notebook instance' button

To delete reported notebook instance,
1. Log in to AWS console
2. Navigate to the AWS SageMaker dashboard
3. Choose Notebook instances and Choose the reported notebook instance
4. Click on the 'Actions' dropdown menu and, select the 'Stop' option, and when instance stops, select the 'Delete' option.
5. Within Delete <notebook-instance-name> dialog box, click the Delete button to confirm the action..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-sagemaker-notebook-instance' AND json.rule = 'notebookInstanceStatus equals InService and kmsKeyId does not exist'```
GCP PostgreSQL instance database flag log_min_messages is not set
This policy identifies PostgreSQL database instances in which database flag log_min_messages is not set. The log_min_messages flag controls which message levels are written to the server log, valid values are DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC. Each level includes all the levels that follow it. log_min_messages flag value changes should only be made in accordance with the organization's logging policy. Auditing helps in troubleshooting operational problems and also permits forensic analysis.
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. Log in to GCP console
2. Navigate SQL Instances page
3. Click on reported PostgreSQL instance
4. Click EDIT
NOTE: If the instance is stopped, You need to START instance first to edit the configurations, then Click on EDIT.
5.Under 'Configuration options', click on 'Add item' in 'Flags' section, choose the flag 'log_min_messages' from the drop-down menu and set the value in accordance with your organization's logging policy.
6. Click Save.

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=='log_min_messages')] does not exist"```
OCI Cloud Guard is not enabled in the root compartment of the tenancy
This policy identifies the absence of OCI Cloud Guard enablement in the root compartment of the tenancy.

OCI Cloud Guard is a vital service that detects misconfigured resources and insecure activities within an OCI tenancy. It offers security administrators visibility to identify and resolve these issues promptly. Cloud Guard not only detects but also suggests, assists, or takes corrective actions to mitigate security risks. By enabling Cloud Guard in the root compartment of the tenancy with default configuration, activity detectors, and responders, administrators can proactively monitor and secure their OCI resources against potential security threats.

As best practice, it is recommended to have Cloud Guard enabled in the root compartment of your tenancy.
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: To enable the OCI Cloud Guard setting, refer to the following documentation:
https://docs.oracle.com/en-us/iaas/cloud-guard/using/part-start.htm#cg-access-enable.

Query:
```config from cloud.resource where api.name = 'oci-cloudguard-configuration' AND json.rule = status does not equal ignore case ENABLED```
AWS Elastic Load Balancer (Classic) SSL negotiation policy configured with vulnerable SSL protocol
This policy identifies Elastic Load Balancers (Classic) which are configured with SSL negotiation policy containing vulnerable SSL protocol. The SSL protocol establishes a secure connection between a client and a server and ensures that all the data passed between the client and your load balancer is private. As a security best practice, it is recommended to use the latest version SSL protocol.
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 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 EC2 Dashboard
4. Click on 'Load Balancers' (Left Panel)
5. Click on the reported Load Balancer
6. On 'Listeners' tab, Click on 'Edit' button
7. On 'Edit Listeners' popup for rule 'HTTPS/SSL',
-  If your cipher is 'Predefined Security Policy', change 'Cipher' to 'ELBSecurityPolicy-TLS-1-2-2017-01 or latest'
OR
- If your cipher is 'Custom Security Policy', Choose 'Protocol-TLSv1.2' only on 'SSL Protocols' section
8. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elb-describe-load-balancers' AND json.rule = "(policies[*].policyAttributeDescriptions[?(@.attributeValue=='true')].attributeName equals Protocol-TLSv1) or (policies[*].policyAttributeDescriptions[?(@.attributeValue=='true')].attributeName equals Protocol-SSLv3) or (policies[*].policyAttributeDescriptions[?(@.attributeValue=='true')].attributeName equals Protocol-TLSv1.1)"```
Azure Microsoft Defender for Cloud set to Off for Cosmos DB
This policy identifies Azure Microsoft Defender for Cloud which has defender setting for Cosmos DB set to Off. Enabling Azure Defender for the cloud provides advanced security capabilities like threat intelligence, anomaly detection, and behaviour analytics. Microsoft Defender for Azure Cosmos DB detects potential SQL injections, known bad actors based on Microsoft Threat Intelligence, suspicious access patterns, and potential exploitation of your database through compromised identities, or malicious insiders. It is highly recommended to enable Azure Defender for Cosmos DB.
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 the Azure portal
2. Go to 'Microsoft Defender for Cloud'
3. Select 'Environment Settings'
4. Click on the subscription name
5. Select the 'Defender plans'
6. Click 'Select types >' in the row for 'Databases'
7. Set the radio button next to 'Azure Cosmos DB' to 'On'
8. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = pricings[?any(name equals CosmosDbs and properties.pricingTier does not equal Standard)] exists```
AWS OpenSearch domain does not have the latest service software version
This policy identifies Amazon OpenSearch Service domains that have service software updates available but not installed for the domain.

Amazon OpenSearch Service is a managed solution for deploying, managing, and scaling OpenSearch clusters. Service software updates deliver the most recent platform fixes, enhancements, and features for the environment, ensuring domain security and availability. To minimize service disruption, it's advisable to schedule updates during periods of low domain traffic.

It is recommended to keep OpenSearch regularly updated to maintain system security, while also accessing the latest features and improvements.
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 request a service software update for an Amazon OpenSearch Service, perform the following actions:

1. Sign in to the AWS Management Console
2. Select the region from the dropdown in the top right corner where the alert is generated
3. In the Navigation Panel on the left, under 'Analytics', select 'Amazon OpenSearch Service'
4. Select the reported domain name
5. Under 'Actions', under 'Service software update', click on 'Update' and select one of the following options:

a. Apply update now - Immediately schedules the action to happen in the current hour if there's capacity available. If capacity isn't available, we provide other available time slots to choose from

b. Schedule it in off-peak window - Only available if the off-peak window is enabled for the domain. Schedules the update to take place during the domain's configured off-peak window. There's no guarantee that the update will happen during the next immediate window. Depending on capacity, it might happen in subsequent days

c. Schedule for specific date and time - Schedules the update to take place at a specific date and time. If the time that you specify is unavailable for capacity reasons, you can select a different time slot

6. Choose 'Confirm'.

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name= 'aws-es-describe-elasticsearch-domain' AND json.rule = serviceSoftwareOptions.updateAvailable exists and serviceSoftwareOptions.updateAvailable is true```
AWS DocumentDB clusters have backup retention period less than 7 days
This policy identifies Amazon DocumentDB clusters lacking sufficient backup retention tenure.

Amazon DocumentDB clusters are managed database services on AWS, compatible with MongoDB. They handle tasks like provisioning and backup. With features like automated backups and read replicas, they offer a reliable solution for MongoDB workloads in the cloud. The backup retention period denotes the duration for storing automated backups of the DocumentDB cluster. Inadequate retention periods heighten the risk of data loss, compliance issues, and hinder effective recovery in security breaches or system failures.

It is recommended to ensure a backup retention period of at least 7 days or according to your business and compliance requirement.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To modify an Amazon DocumentDB cluster's backup retention period:
1. Sign in to the AWS Management Console.
2. In the console, select the specific region from the region dropdown in the top right corner where the alert is generated.
3. Navigate to the Amazon DocumentDB console by either searching for 'Amazon DocumentDB' in the AWS services search bar or directly accessing the Amazon DocumentDB service.
4. In the navigation pane, choose 'Clusters' and select the cluster name that is reported.
5. Click 'Actions' in the right corner, and then select 'Modify' from the drop-down menu.
6. On the Modify cluster page, under the 'Backup' section, select the desired backup retention period in days from the 'Backup retention period' drop-down menu based on your business or compliance requirements.
7. Click 'Continue' to review a summary of your changes.
8. Choose either 'Apply during the next scheduled maintenance window' or 'Apply immediately' based on your scheduling preference for modifications.
9. Click on 'Modify Cluster' to implement the changes..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-docdb-db-cluster' AND json.rule = Status equals available and ( BackupRetentionPeriod does not exist or BackupRetentionPeriod less than 7 )```
AWS S3 buckets are accessible to public via ACL
This policy identifies S3 buckets which are publicly accessible via ACL. Amazon S3 often used to store highly sensitive enterprise data and allowing public access to such S3 bucket through ACL would result in sensitive data being compromised. It is highly recommended to disable ACL configuration for all S3 buckets and use resource based policies to allow access to S3 buckets.
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. 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.

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)))) and websiteConfiguration does not exist"```
Azure Machine learning compute instance configured with public IP
This policy identifies Azure Machine Learning compute instances which are configured with public IP.

Configuring an Azure Machine Learning compute instance with a public IP exposes it to significant security risks, including unauthorized access and cyber-attacks. This setup increases the likelihood of data breaches, where sensitive information and intellectual property could be accessed by unauthorized individuals, leading to potential data leakage and loss.

As a best practice, it is recommended not to configure Azure Machine Learning instances with public IP.
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: Note: Disabling a public IP address on an existing Azure Machine Learning compute instance is not supported without deleting and recreating the instance. To secure your instance, it’s recommended to configure it without a public IP from the start. Additionally, to update an existing Azure Machine Learning workspace to use a managed virtual network, all compute resources (including compute instances, compute clusters, and managed online endpoints) must first be deleted.

To create a new compute instance with no public IP:
1. Log in to Azure Portal and search for 'Azure Machine Learning'
2. Select 'Azure Machine Learning'
3. Select the Azure Machine Learning Workspace that the reported compute instance is associated with
4. Under 'Settings' go to 'Networking' section
5. At the top, select the 'Workspace managed outbound access' tab
6. Select either 'Allow Internet Outbound' or 'Allow Only Approved Outbound' based on your requirements, if one hasn't been chosen already
7. Click on 'Save'
8. On the 'Overview' page, click the 'Studio web URL' link to log in to Azure ML Studio
9. A new tab will open for Azure ML Studio
10. In the left panel, under 'Manage' section, click on the 'Compute'
11. Click 'New' to create a new compute instance
12. In the 'Security' tab, under the 'Virtual network' section, enable the 'No public IP' option to disable the public IP
13. Select 'Review + Create' to create the compute instance.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-machine-learning-compute' AND json.rule = properties.provisioningState equal ignore case Succeeded AND properties.properties.connectivityEndpoints.publicIpAddress exists AND properties.properties.connectivityEndpoints.publicIpAddress does not equal ignore case "null"```
AWS S3 bucket access control lists (ACLs) in use
This policy identifies AWS S3 buckets which are using access control lists (ACLs). ACLs are legacy way to control access to S3 buckets. It is recommended to disable bucket ACL and instead use IAM policies or S3 bucket policies to manage access to your S3 buckets.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Login to the AWS Console
2. Navigate to the 'S3' service
3. Click on the 'S3' resource reported in the alert
4. Click on the 'Permissions' tab
5. Under 'Object Ownership' click 'Edit'
6. Select 'ACLs disabled (recommended)'
7. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = ownershipControls.rules[*] does not contain BucketOwnerEnforced```
GCP Kubernetes Engine Clusters have Master authorized networks disabled
This policy identifies Kubernetes Engine Clusters which have disabled Master authorized networks. Enabling Master authorized networks will let the Kubernetes Engine block untrusted non-GCP source IPs from accessing the Kubernetes master through HTTPS.
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: Follow the below link for enabling Master authorized networks feature on kubernetes clusters,
Link: https://cloud.google.com/kubernetes-engine/docs/how-to/authorized-networks#add.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule = status equals RUNNING and masterAuthorizedNetworksConfig.enabled does not equal "true"```