knarayan/cloud_posture_checks huggingface dataset:
AWS FSX Windows filesystem is not configured with file access auditing
This policy identifies the AWS FSX Windows filesystem that lacks configuration for FileAccessAuditLogLevel and FileShareAccessAuditLogLevel.

Amazon FSx for Windows File Server offers the capability to audit user access to files, folders, and file shares. The settings for FileAccessAuditLogLevel and FileShareAccessAuditLogLevel can be adjusted to record successful access attempts, failed attempts, both, or none, based on your auditing needs. Failing to configure these audit logs may result in unrecognized unauthorized access and potential non-compliance with security standards.

It is advisable to set up logging for both file and folder access as well as file share access in alignment with your business needs. This ensures thorough logging, enhances visibility and accountability, supports compliance, and facilitates effective monitoring and incident response.
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 change the file access auditing configuration, Perform the following actions:

1. Sign into the AWS console and Open the Amazon FSx console at https://console.aws.amazon.com/fsx/
2. Navigate to 'File systems', and choose the Windows file system that is reported
3. Choose the 'Administration' tab
4. On the 'File Access Auditing' panel, choose 'Manage'
5. On the 'Manage file access auditing settings dialog', change the desired settings
   5a. For 'Log access to files and folders', select the 'Log successful attempts' and/or 'Log failed attempts'
   
   or

   5b. For 'Log access to file shares', select the 'Log successful attempts' and/or 'Log failed attempts'
6. For 'Choose an audit event log destination', choose 'CloudWatch Logs' or 'Kinesis Data Firehose'. Then choose an existing log or delivery stream or create a new one
7. Choose 'Save'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-fsx-file-system' AND json.rule = FileSystemType equals "WINDOWS" and ( WindowsConfiguration.AuditLogConfiguration.FileAccessAuditLogLevel equals "DISABLED" AND  WindowsConfiguration.AuditLogConfiguration.FileShareAccessAuditLogLevel equals "DISABLED")```
bobby run build informational

This is applicable to aws cloud and is considered a informational 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.type = 'aws' AND api.name = 'aws-mwaa-environment' AND json.rule = EnvironmentClass contains "foo" ```
AWS S3 bucket used for storing AWS Bedrock Custom model training artifacts
This policy identifies the AWS S3 bucket used for storing AWS Bedrock Custom model training job output. 

S3 buckets hold the results and artifacts generated from training models in AWS Bedrock. Ensuring proper configuration and access control is crucial to maintaining the security and integrity of the training output. Improperly secured S3 buckets used for storing AWS Bedrock training output can lead to unauthorized access and potential exposure of model information.

It is recommended to implement strict access controls, enable encryption, and audit permissions to secure AWS S3 buckets for AWS Bedrock training job output and ensure compliance.

NOTE: This policy is designed to identify the S3 buckets utilized for storing results and storing artifacts generated from training custom models in AWS Bedrock. It does not signify any detected misconfiguration or security risk.
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 protect the S3 buckets utilized by the AWS Bedrock Custom model training results data, please refer to the following link for recommended best practices
https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html.

Query:
```config from cloud.resource where api.name = 'aws-s3api-get-bucket-acl' as X; config from cloud.resource where api.name = 'aws-bedrock-custom-model' as Y; filter ' $.Y.outputDataConfig.bucketName equals $.X.bucketName'; show X;```
Azure Microsoft Defender for Cloud system updates monitoring is set to disabled
This policy identifies the Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) policies which have system updates monitoring set to disabled. It retrieves a daily list of available security and critical updates from Windows Update or Windows Server Update Services. The retrieved list depends on the service that's configured for that virtual machine and recommends that the missing updates be applied. For Linux systems, the policy uses the distro-provided package management system to determine packages that have available updates. It also checks for security and critical updates from Azure Cloud Services virtual machines.
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. Choose the reported subscription
5. Click on the 'Security policy' under 'Policy settings' section
6. Click on 'SecurityCenterBuiltIn'
7. Select 'Parameters' tab
8. Set the 'System updates should be installed on your machines' to 'AuditIfNotExists'
9. If no other changes required then Click on 'Review + save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-policy-assignments' AND json.rule = '((name == SecurityCenterBuiltIn and properties.parameters.systemUpdatesMonitoringEffect.value equals Disabled) or (name == SecurityCenterBuiltIn and properties.parameters[*] is empty and properties.displayName does not start with "ASC Default"))'```
jashah_ms_does_not_intersect

This is applicable to aws cloud and is considered a informational 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-security-groups' AND json.rule = _AWSCloudAccount.orgHierarchyNames() does not intersect ("all-accounts")```
OCI MFA is disabled for IAM users
This policy identifies Identify Access Management (IAM) users for whom Multi Factor Authentication (MFA) is disabled. As a best practice, enable MFA to add an extra layer of protection for increased security of your OCI user’s identity and complete the sign-in process.
This is applicable to oci cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MFA'].
Mitigation of this issue can be done as follows: 1. Login to the OCI Console Page: https://console.ap-mumbai-1.oraclecloud.com/
2. Select Identity from Services menu
3. Select Users from Identity menu.
4. Click on each non-complaint user.
5. Click on Enable Multi-Factor Authentication.

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-user' AND json.rule = lifecycleState equal ignore case ACTIVE and capabilities.canUseConsolePassword is true and isMfaActivated is false```
GCP Storage Bucket storing Vertex AI model
This policy identifies publicly exposed GCS buckets that are used to store the GCP Vertex AI model.

GCP Vertex AI models (except AutoML Models) are stored in the Storage bucket. Vertex AI model is considered sensitive and confidential intellectual property and its storage location should be checked regularly. The storage location should be as per your organization's security and compliance requirements.

It is recommended to monitor, identify, and evaluate storage location for GCP Vertex AI model regularly to prevent unauthorized access and AI model thefts.
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: Review and validate the Vertex AI models are stored in the right Storage buckets. Move and/or delete the model and other related artifacts if they are found in an unexpected location. Review how the model was uploaded to an unauthorised/unapproved storage bucket..

Query:
```config from cloud.resource where api.name = 'gcloud-storage-buckets-list' as X; config from cloud.resource where api.name = 'gcloud-vertex-ai-aiplatform-model' as Y; filter ' $.Y.artifactUri contains $.X.id '; show X;```
dnd_test_create_hyperion_policy_without_asset_type_finding_2
Description-3accdba0-4ab9-4751-8797-ed0c62c25bfb
This is applicable to aws cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['HIGH_PRIVILEGED_ROLE'].
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```
GCP Firewall rule allows all traffic on MongoDB port (27017)
This policy identifies GCP Firewall rules which allow all inbound traffic on MongoDB port (27017). Allowing access from arbitrary IP addresses to this port increases the attack surface of your network. It is recommended that the MongoDB port (27017) should be allowed to specific IP addresses.
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: If the Firewall rule reported indeed needs to restrict all traffic, follow the instructions below:
1. Login to GCP Console
2. Go to 'VPC Network'
3. Go to the 'Firewall'
4. Click on the reported Firewall rule
5. Click on 'EDIT'
6. Modify Source IP ranges to specific IP
7. Click on 'SAVE'..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-firewall-rules-list' AND json.rule = disabled is false and direction equals INGRESS and (sourceRanges[*] equals ::0 or sourceRanges[*] equals 0.0.0.0 or sourceRanges[*] equals 0.0.0.0/0 or sourceRanges[*] equals ::/0 or sourceRanges[*] equals ::) and allowed[?any(ports contains _Port.inRange(27017,27017) or (ports does not exist and (IPProtocol contains tcp or IPProtocol contains udp)))] exists```
Azure Database for MySQL server not configured with private endpoint
This policy identifies Azure MySQL database servers that are not configured with private endpoint. Private endpoint connections enforce secure communication by enabling private connectivity to Azure Database for MySQL. Configuring a private endpoint enables access to traffic coming from only known networks and prevents access from malicious or unknown IP addresses which includes IP addresses within Azure. It is recommended to create private endpoint for secure communication for your Azure MySQL database.
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: 1. Login to Azure portal.
2. Navigate to 'Azure Database for MySQL servers'
3. Click on the reported MySQL server instance you want to modify 
4. Select 'Networking' under 'Settings' from left panel 
5. Under 'Private endpoint', click on Add private endpoint' to create a add add a private endpoint

Refer to below link for step by step process:
https://learn.microsoft.com/en-us/azure/mysql/single-server/how-to-configure-private-link-cli.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-mysql-server' AND json.rule = properties.userVisibleState equal ignore case Ready and properties.privateEndpointConnections[*] is empty```
Azure Microsoft Entra ID account lockout duration less than 60 seconds
This policy identifies if the account lockout duration for Microsoft Entra ID (formerly Azure AD) accounts is configured to be less than 60 seconds. The lockout duration determines how long the account remains locked after exceeding the lockout threshold.

A lockout duration of less than 60 seconds increases the risk of brute-force or password spray attacks. Malicious actors can exploit a short lockout period to attempt multiple logins more frequently, increasing the likelihood of gaining unauthorized access. Configuring the lockout duration to be at least 60 seconds helps reduce the frequency of repeated login attempts during a brute-force attack, improving protection against such attacks while ensuring a reasonable delay for legitimate users after exceeding the threshold.

As a security best practice, it is recommended to configure the account lockout duration to greater than or equal to 60 seconds.
This is applicable to azure cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to Azure Portal and search for 'Microsoft Entra ID'
2. Select 'Microsoft Entra ID'
3. Under Manage, select Security
4. Under Manage, select Authentication methods
5. Under Manage, select Password protection
6. Set the 'Lockout duration in seconds' to 60 or higher
7. Click 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-active-directory-group-settings' and json.rule = values[?any(name equals LockoutDurationInSeconds and (value less than 60 or value does not exist))] exists```
AWS EMR cluster is not configured with Kerberos Authentication
This policy identifies EMR clusters which are not configured with Kerberos Authentication. Kerberos uses secret-key cryptography to provide strong authentication so that passwords or other credentials aren't sent over the network in an unencrypted format.
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. Log 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 'EMR' dashboard from 'Services' dropdown
4. Go to 'Security configurations', click 'Create'
5. On the Create security configuration window,
6. In 'Name' box, provide a name for the new EMR security configuration
7. Under the section 'Enable Kerberos authentication' select the check box
8. Follow below link for configuration steps,
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-kerberos.html
9. Click on 'Create' button
10. On the left menu of EMR dashboard Click 'Clusters'
11. Select the EMR cluster for which the alert has been generated and click on the 'Clone' button from the top menu
12. In the Cloning popup, choose 'Yes' and Click 'Clone'
13. On the Create Cluster page, in the Security Options section, click on 'security configuration'.
14. From the 'Security configuration' drop down select the name of the security configuration created at step 4 to step 8, click 'Create Cluster'
15. Once you the new cluster is set up verify its working and terminate the source cluster in order to stop incurring charges for it.
16. On the left menu of EMR dashboard Click 'Clusters', from the list of clusters select the source cluster which is alerted
17. Click on the 'Terminate' button from the top menu
18. On the 'Terminate clusters' pop-up, click 'Terminate'..

Query:
```config from cloud.resource where api.name = 'aws-emr-describe-cluster' as X; config from cloud.resource where api.name = 'aws-emr-security-configuration' as Y; filter '($.X.status.state does not contain TERMINATING) and ($.X.securityConfiguration contains $.Y.name) and ($.Y.AuthenticationConfiguration.KerberosConfiguration does not exist)' ; show X;```
Azure Container Registry with anonymous authentication enabled
This policy identifies Azure Container Registries with anonymous authentication enabled, allowing unauthenticated access to the registry.

Allowing anonymous pull or access to container registries poses a significant security risk, exposing them to unauthorized users who may retrieve or manipulate container images. To enhance security, disable anonymous access and require authentication through Azure Active Directory (Azure AD). Additionally, local authentication methods such as admin user, repository-scoped access tokens, and anonymous pull should be turned off to ensure authentication relies solely on Azure AD, providing improved control and accountability.

As a security best practice, it is recommended to disable anonymous authentication for Azure Container Registries.
This is applicable to azure cloud and is considered a high severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: Currently, the Azure UI does not support disabling anonymous authentication for Azure Container Registries. To disable anonymous authentication, refer to the following link:
https://learn.microsoft.com/en-us/azure/container-registry/anonymous-pull-access#disable-anonymous-pull-access.

Query:
```config from cloud.resource where api.name = 'azure-container-registry' AND json.rule = (skuName contains Standard or skuName contains Premium) and properties.provisioningState equal ignore case Succeeded and properties.anonymousPullEnabled is false```
Azure Activity log alert for Create or update network security group rule does not exist
This policy identifies the Azure accounts in which activity log alert for Create or update network security group rule does not exist. Creating an activity log alert for Create or update network security group rule gives insight into network 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 'Create or Update Security Rule (Microsoft.Network/networkSecurityGroups/securityRules)' 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/securityRules/write" as X; count(X) less than 1```
GCP Spanner Databases not encrypted with CMEK
This policy identifies GCP Spanner databases that are not encrypted with a Customer-Managed Encryption Key (CMEK).

Google Cloud Spanner is a scalable, globally distributed, and strongly consistent database service. By using CMEK with Spanner, you retain complete control over the encryption keys protecting your sensitive data, ensuring that only authorized users with access to these keys can decrypt and access the information. Without CMEK, data is encrypted with Google-managed keys, which may not provide the level of control required for handling sensitive data in certain industries.

It is recommended to encrypt Spanner database data using a Customer-Managed Encryption Key (CMEK).
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: Encryption configuration can only be updated during spanner database creation. Follow the below steps to create a new spanner database with a customer-managed encryption key:

1. Sign in to the Google Cloud Management Console. Navigate to the Cloud Spanner page
2. Under instances, select the instance under which the reported database exists
3. Under databases, select the 'CREATE DATABASE' option
4. Under the create database page, under the 'SHOW ENCRYPTION OPTIONS' section, select 'Cloud KMS Key'
5. Select the KMS key you prefer
6. Click on 'CREATE'.

Note: It is recommended to migrate data from an old database to a new database created..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-cloud-spanner-database' AND json.rule = state equal ignore case ready AND encryptionConfig.kmsKeyNames does not exist```
AWS CloudFormation template contains globally open resources
This alert triggers if a CloudFormation template that when launched will result in resources allowing global network access. Below are three common causes:

- Security Group with a {0.0.0.0/0, ::/0} rule
- Network Access Control List with a {0.0.0.0/0, ::/0} rule
- Network Access Control List with -1 IpProtocol
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: Prisma Cloud encourages you to review the template and ensure this is the intended behavior.

1. Goto the AWS CloudFormation dashboard.
2. Click on the Stack you want to modify.
3. Select the Template tab and then View in Designer.
4. Make your template modifications.
5. Check for syntax errors in your template by choosing Validate template near the top of the page.
6. Select Save from the file (icon) menu.
7. Choose Amazon S3 bucket, name your template and Save.
8. Copy the bucket URL and click OK.
9. Select Close to close Designer. 
10. Click on the Stack you want to modify.
11. From the Actions pull down menu, select Update stack
12. Choose Replace current template and paste the URL from Designer into the Amazon S3 URL field. Then click on Next.
13. Specify stack details, then click on Next.
14. Configure stack options, then click on Next.
15. Review, then select Update stack near the bottom of the page..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudformation-describe-stacks' AND json.rule = "(($.stackResources[?( @.resourceType == 'AWS::EC2::SecurityGroup' || @.resourceType == 'AWS::EC2::SecurityGroupIngress' || @.resourceType == 'AWS::EC2::NetworkAclEntry')].resourceStatus any equal CREATE_COMPLETE) or ($.stackResources[?( @.resourceType == 'AWS::EC2::SecurityGroup' || @.resourceType == 'AWS::EC2::SecurityGroupIngress' || @.resourceType == 'AWS::EC2::NetworkAclEntry')].resourceStatus any equal UPDATE_COMPLETE)) and (($.cloudFormationTemplate.Resources.{}.SecurityGroupIngress[*].CidrIp any equal 0.0.0.0/0 or $.cloudFormationTemplate.Resources.{}.SecurityGroupIngress[*].CidrIpv6 any equal ::/0 or $.cloudFormationTemplate.Resources.{}.Properties.CidrIp any equal 0.0.0.0/0 or $.cloudFormationTemplate.Resources.{}.Properties.CidrIpv6 any equal ::/0) or ($.cloudFormationTemplate.Resources.{}.Properties.CidrBlock any equal 0.0.0.0/0 or $.cloudFormationTemplate.Resources.{}.Properties.Ipv6CidrBlock any equal ::/0 or $.cloudFormationTemplate.Resources.{}.Properties.Protocol any equal -1))"```