knarayan/cloud_posture_checks huggingface dataset:
AWS Glue Job using the shadow resource bucket for script location
This policy identifies that the AWS Glue Job using the bucket for script location is not managed from the current location. This could potentially be using the shadow resource bucket for script location.

A shadow resource bucket is an unauthorized S3 bucket posing security risks. AWS Glue is a service utilized to automate the extraction, transformation, and loading (ETL) processes, streamlining data preparation for analytics and machine learning. When a job is created using the Visual ETL tool, Glue automatically creates an S3 bucket with a predictable name pattern 'aws-glue-assets-accountid-region'. An attacker could create the S3 bucket in any region before the victim uses Glue ETL, causing the victims Glue service to write files to the attacker-controlled bucket. This vulnerability allows an attacker to inject any code into the Glue job of the victim, resulting in remote code execution (RCE).

It is recommended to verify the expected bucket owner and update the AWS Glue jobs script location and enforce the aws:ResourceAccount condition in the policy of the AWS Glue Job to check that the AWS account ID of the S3 bucket used by AWS Glue Job according to your business requirements.
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: To update the script location for an AWS Glue Job:

1. Sign in to the AWS Management Console and open the AWS Glue Studio console at https://console.aws.amazon.com/gluestudio/.
2. In the navigation pane, choose 'ETL jobs'.
3. Select the desired AWS Glue Job and choose 'Edit Job' from the 'Actions' drop-down.
4. In the 'Job Details' window, under 'Advanced properties', verify that the 'Script path' and 'Script filename' are authorized and managed according to your business requirements.
5. Move the required script to a new S3 bucket as per your requirements.
6. In the AWS Glue Studio console, go to the 'Job details' tab and update the 'Script filename' and 'Script path' parameters to reflect the new S3 location.
7. Choose 'Save'..

Query:
```config from cloud.resource where api.name = 'aws-glue-job' AND json.rule = Command.BucketName exists and Command.BucketName contains "aws-glue-assets-" as X; config from cloud.resource where api.name = 'aws-s3api-get-bucket-acl' AND json.rule = bucketName contains "aws-glue-assets-" as Y; filter 'not ($.X.Command.BucketName equals $.Y.bucketName)' ; show X;```
AWS RDS cluster delete protection is disabled
This policy identifies RDS clusters for which delete protection is disabled. Enabling delete protection for these RDS clusters prevents irreversible data loss resulting from accidental or malicious operations.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. 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 Amazon RDS dashboard 
4. Click on the DB clusters
5. Select the reported DB cluster
6. Click on the 'Modify' button
7. In Modify DB cluster page, In the 'Additional configuration' section, Check the box 'Enable deletion protection' for Deletion protection..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-rds-db-cluster' AND json.rule = status contains available and deletionProtection is false```
AWS SQS Queue not configured with server side encryption
This policy identifies AWS SQS queues which are not configured with server side encryption. Enabling server side encryption would encrypt all messages that are sent to the queue and the messages are stored in encrypted form. Amazon SQS decrypts a message only when it is sent to an authorised consumer. It is recommended to enable server side encryption for AWS SQS queues in order to protect sensitive data in the event of a data breach or malicious users gaining access to the data.
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: To configure server side encryption for AWS SQS queue follow below URL as required:

To configure Amazon SQS key (SSE-SQS) for a queue:
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-sqs-sse-queue.html

To configure AWS Key Management Service key (SSE-KMS) for a queue:
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-sse-existing-queue.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-sqs-get-queue-attributes' AND json.rule = attributes.KmsMasterKeyId does not exist and attributes.SqsManagedSseEnabled is false```
Azure Virtual Machine (Windows) secure boot feature is disabled
This policy identifies Virtual Machines (Windows) that have secure boot feature disabled. Enabling Secure Boot on supported Windows virtual machines provides mitigation against malicious and unauthorised changes to the boot chain. Secure boot helps protect your VMs against boot kits, rootkits, and kernel-level malware. So it is recommended to enable Secure boot for Azure Windows virtual machines. 

NOTE: This assessment only applies to trusted launch enabled Windows virtual machines. You can't enable trusted launch on existing virtual machines that were initially created without it. 
To know more, refer https://docs.microsoft.com/azure/virtual-machines/trusted-launch?WT.mc_id=Portal-Microsoft_Azure_Security
This is applicable to azure 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 Azure portal
2. Navigate to Virtual machines dashboard
3. Click on the reported Virtual machine
4. Select 'Configuration' under 'Settings' from left panel 
NOTE: Enabling Secure Boot will trigger an immediate SYSTEM REBOOT.
5. On the 'Configuration' page, check 'Secure boot' under 'Security type' section
6. Click 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-vm-list' AND json.rule = powerState equal ignore case "PowerState/running" and ['properties.storageProfile'].['osDisk'].['osType'] contains "Windows" and ['properties.securityProfile'].['securityType'] equal ignore case "TrustedLaunch" and ['properties.securityProfile'].['uefiSettings'].['secureBootEnabled'] is false```
GCP Log metric filter and alert does not exist for IAM custom role changes
This policy identifies the GCP account which does not have a log metric filter and alert for IAM custom role changes. Monitoring role creation, deletion and updating activities will help in identifying over-privileged roles at early stages. It is recommended to create a metric filter and alarm to detect activities related to the creation, deletion and updating of custom IAM Roles.
This is applicable to gcp cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Sign in to GCP Console
2. Navigate to 'Logs-based metrics' under the 'Logging' section.
3. Click on 'CREATE METRIC'.
4. Provide 'Metric Type' and 'Details'.
5. In 'Filter selection', add filter as 
resource.type="iam_role" AND protoPayload.methodName = "google.iam.admin.v1.CreateRole" OR protoPayload.methodName="google.iam.admin.v1.DeleteRole" OR protoPayload.methodName="google.iam.admin.v1.UpdateRole"
6. Click on 'CREATE METRIC'.
7. Under 'User-defined metrics' section, choose the metric you created in step 6 and click on the kebab menu (Vertical 3 dots) on the right side of the metrics
8. Click on 'Create alert from metric'; it will navigate to 'Create alerting policy' under the section 'Monitoring'.
9. Add the metric name created above if not auto-filled in the Monitoring filter. Choose an appropriate value for other alert condition parameters as desired. Then Click on 'NEXT'
10. Configure all alert trigger settings as desired. Then Click on 'NEXT'
11. Configure notifications as desired and provide an appropriate name for the alert policy. Then Click on 'NEXT'
12. Click on 'CREATE POLICY'..

Query:
```config from cloud.resource where api.name = 'gcloud-logging-metric' as X; config from cloud.resource where api.name = 'gcloud-monitoring-policies-list' as Y; filter '($.Y.conditions[*].metricThresholdFilter contains $.X.name) and ($.X.filter contains "resource.type =" or $.X.filter contains "resource.type=") and ($.X.filter does not contain "resource.type !=" and $.X.filter does not contain "resource.type!=") and $.X.filter contains "iam_role" and ($.X.filter contains "protoPayload.methodName=" or $.X.filter contains "protoPayload.methodName =") and ($.X.filter does not contain "protoPayload.methodName!=" and $.X.filter does not contain "protoPayload.methodName !=") and $.X.filter contains "google.iam.admin.v1.CreateRole" and $.X.filter contains "google.iam.admin.v1.DeleteRole" and $.X.filter contains "google.iam.admin.v1.UpdateRole"'; show X; count(X) less than 1```
Azure Logic app using insecure TLS version
This policy identifies Azure Logic apps that are using insecure TLS version.

Azure Logic apps configured to use insecure TLS versions are at risk as they may be vulnerable to security threats due to the known vulnerabilities, weaker encryption methods, and support for compromised hash functions. Logic apps using TLS 1.2 or higher will secure communication and protect against potential cyber attacks.

As a security best practice,  it is recommended to configure Logic apps with TLS 1.2 or higher to ensure secure communication.
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. Log in to Azure portal
2. Navigate to Logic apps
3. Click on the reported Logic app
4. Under 'Setting' section, click on 'Configuration'
5. Under 'General settings' tab, Set 'Minimum Inbound TLS Version' to '1.2' or higher.
6. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-app-service' AND json.rule = properties.state equal ignore case Running and kind contains workflowapp and (config.minTlsVersion equals "1.0" or config.minTlsVersion equals "1.1")```
Azure Storage Account using insecure TLS version
This policy identifies Azure Storage Account which is using insecure TLS version. Azure Storage Account uses Transport Layer Security (TLS) from communication with client applications. As a best security practice, use newer TLS version as the minimum TLS version for Azure Storage Account. Currently, Azure Storage Account supports TLS 1.2 version which resolves the security gap from its preceding versions.

https://docs.microsoft.com/en-us/azure/storage/common/transport-layer-security-configure-minimum-version?tabs=portal
This is applicable to azure 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 Azure Portal
2. Go to Storage accounts dashboard and Click on the reported storage account
3. Under the 'Settings' menu, click on 'Configuration'
4. Under 'Minimum TLS version' select 'Version 1.2' from the drop down
5. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-storage-account-list' AND json.rule = properties.supportsHttpsTrafficOnly is true and properties.minimumTlsVersion does not equal TLS1_2```
AWS OpenSearch node-to-node encryption is disabled
This policy identifies AWS OpenSearch for which none-to-node encryption is disabled. Each OpenSearch domain resides within a dedicated VPC and, by default, traffic within the VPC is unencrypted. Enabling node to node encryption provides additional security layer by making use of TLS encryption for all communications between Amazon OpenSearch Service instances in a cluster.

For more information, please follow the URL given below,
https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ntn.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: Go to https://aws.amazon.com, and then choose Sign In to the Console
1. Under Analytics, choose Amazon OpenSearch Service
2. Choose your domain
3. Choose Actions, Edit security configuration
4. Under Encryption section, check Node-to-node encryption
5. Click Save changes button

For more details on node-to-node encryption for an Amazon OpenSearch Service Domain, follow below mentioned URL:
https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ntn.html

Note: Node-to-node encryption is supported only from OpenSearch 6.0 or later. To upgrade older versions of AWS OpenSearch please refer to the URL given below,
https://docs.aws.amazon.com/opensearch-service/latest/developerguide/version-migration.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-es-describe-elasticsearch-domain' AND json.rule = processing is false and (nodeToNodeEncryptionOptions.enabled is false or nodeToNodeEncryptionOptions.enabled does not exist)```
GCP Log metric filter and alert does not exist for Audit Configuration Changes
This policy identifies the GCP accounts which do not have a log metric filter and alert for Audit Configuration Changes. Configuring metric filter and alerts for Audit Configuration Changes ensures recommended state of audit configuration and hence, all the activities in project are audit-able at any point in time.
This is applicable to gcp cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Sign in to GCP Console
2. Navigate to 'Logs-based metrics' under the 'Logging' section.
3. Click on 'CREATE METRIC'.
4. Provide 'Metric Type' and 'Details'.
5. In 'Filter selection', add filter as 
protoPayload.methodName="SetIamPolicy" AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*
6. Click on 'CREATE METRIC'.
7. Under 'User-defined metrics' section, choose the metric you created in step 6 and click on the kebab menu (Vertical 3 dots) on the right side of the metrics
8. Click on 'Create alert from metric'; it will navigate to 'Create alerting policy' under the section 'Monitoring'.
9. Add the metric name created above if not auto-filled in the Monitoring filter. Choose an appropriate value for other alert condition parameters as desired. Then Click on 'NEXT'
10. Configure all alert trigger settings as desired. Then Click on 'NEXT'
11. Configure notifications as desired and provide an appropriate name for the alert policy. Then Click on 'NEXT'
12. Click on 'CREATE POLICY'..

Query:
```config from cloud.resource where api.name = 'gcloud-logging-metric' as X; config from cloud.resource where api.name = 'gcloud-monitoring-policies-list' as Y; filter '($.Y.conditions[*].metricThresholdFilter contains $.X.name) and ($.X.filter contains "protoPayload.methodName =" or $.X.filter contains "protoPayload.methodName=") and ($.X.filter does not contain "protoPayload.methodName !=" and $.X.filter does not contain "protoPayload.methodName!=") and $.X.filter contains "SetIamPolicy" and $.X.filter contains "protoPayload.serviceData.policyDelta.auditConfigDeltas:*"'; show X; count(X) less than 1```
Azure Automation account is not configured with managed identity
This policy identifies Automation accounts that are not configured with managed identity. Managed identity can be used to authenticate to any service that supports Azure AD authentication, without having credentials in your code. Storing credentials in a code increases the threat surface in case of exploitation and also managed identities eliminate the need for developers to manage credentials. So as a security best practice, it is recommended to have the managed identity to your Automation account.

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: To enable managed identity on an existing Azure Automation account, follow the below URL:
https://docs.microsoft.com/en-us/azure/automation/quickstarts/enable-managed-identity.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-automation-account' AND json.rule = identity does not exist or identity.type equal ignore case "None"```
Bobby Copy of AWS Redshift database does not have audit logging enabled
Audit logging is not enabled by default in Amazon Redshift. When you enable logging on your cluster, Amazon Redshift creates and uploads logs to Amazon S3 that capture data from the creation of the cluster to the present time.
This is applicable to aws 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. Login to AWS Console.
2. Goto Amazon Redshift service
3. On left navigation panel, click on Clusters
4. Click on the reported cluster
5. Click on Database tab and choose 'Configure Audit Logging'
6. On Enable Audit Logging, choose 'Yes'
7. Create a new s3 bucket or use an existing bucket
8. click Save.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-redshift-describe-clusters' AND json.rule ='loggingStatus.loggingEnabled is false'```
AWS Lambda function URL AuthType set to NONE
This policy identifies AWS Lambda functions which have function URL AuthType set to NONE. AuthType determines how Lambda authenticates or authorises requests to your function URL. When AuthType is set to NONE, Lambda doesn't perform any authentication before invoking your function. It is highly recommended to set AuthType to AWS_IAM for Lambda function URL to authenticate via AWS IAM.
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 in to the AWS console
2. Select the region, from the region drop-down, for which the alert is generated
3. Navigate to AWS Lambda Dashboard
4. Click on the 'Functions' (Left panel)
5. Select the lambda function on which the alert is generated
6. Go to 'Configuration' tab
7. Select 'Function URL'
8. Click on 'Edit'
9. Set 'Auth type' to 'AWS_IAM'
10. Click on 'Save'
 .

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name= 'aws-lambda-list-functions' AND json.rule = authType equal ignore case NONE```
API automation policy xzypd

This is applicable to aws cloud and is considered a medium 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 = architecture contains "foo"```
IBM Cloud user with IAM policies provide administrative privileges for Activity Tracker Service
This policy identifies IBM Cloud users with overly permissive Activity Tracker Administrative role. When a user having policy with admin rights gets compromised, the whole service gets 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 'Users' in the left panel.
3. Select the user which is reported and you want to edit access for.
4. Go to 'Access' tab and under the 'Access policies' section, click on three dots on the right corner of a row for the policy which is having Administrator permission on 'IBM Cloud Activity Tracker ' 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 "logdnaat" and operator is member of ("stringEquals", "stringMatch"))] exists and attributes[?any( name is member of ("region","resource","resourceGroupId","logGroup","resourceType","serviceInstance"))] does not exist )] exists and subjects[?any( attributes[?any( name contains "iam_id" and value contains "IBMid")] exists )] exists as X;config from cloud.resource where api.name = 'ibm-iam-user' as Y; filter '$.X.subjects[*].attributes[*].value contains $.Y.iam_id'; show Y;```
Copy of AWS S3 Buckets Block public access setting disabled
This policy identifies AWS S3 buckets which have 'Block public access' setting disabled. Amazon S3 provides 'Block public access' setting to manage public access of AWS S3 buckets. Enabling 'Block public access' setting prevents S3 resource data being accidentally or maliciously becoming publicly accessible. It is highly recommended to enable 'Block public access' setting for all AWS s3 buckets appropriately.
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: 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. Under 'Block public access' click on 'Edit'
6. Select 'Block all public access' checkbox
7. Click on Save
8. 'Confirm' the changes

Note: Make sure updating 'Block public access' setting 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 does not exist and accountLevelPublicAccessBlockConfiguration does not exist) or ((publicAccessBlockConfiguration does not exist or publicAccessBlockConfiguration.blockPublicAcls is false) and (accountLevelPublicAccessBlockConfiguration does not exist or accountLevelPublicAccessBlockConfiguration.blockPublicAcls is false)) or ((publicAccessBlockConfiguration does not exist or publicAccessBlockConfiguration.ignorePublicAcls is false) and (accountLevelPublicAccessBlockConfiguration does not exist or accountLevelPublicAccessBlockConfiguration.ignorePublicAcls is false)) or ((publicAccessBlockConfiguration does not exist or publicAccessBlockConfiguration.blockPublicPolicy is false) and (accountLevelPublicAccessBlockConfiguration does not exist or accountLevelPublicAccessBlockConfiguration.blockPublicPolicy is false)) or ((publicAccessBlockConfiguration does not exist or publicAccessBlockConfiguration.restrictPublicBuckets is false) and (accountLevelPublicAccessBlockConfiguration does not exist or accountLevelPublicAccessBlockConfiguration.restrictPublicBuckets is false))"```