knarayan/cloud_posture_checks huggingface dataset:
AWS Certificate Manager (ACM) RSA certificate key length less than 2048
This policy identifies the RSA certificates managed by AWS Certificate Manager with a key length of less than 2048 bits. 

AWS Certificate Manager (ACM) is a service for managing SSL/TLS certificates. RSA certificates are cryptographic keys used for securing communications over networks. Shorter key lengths may be susceptible to attacks such as brute force or factorization, where an attacker could potentially decrypt the encrypted data by finding the prime factors of the key.

It is recommended that the RSA certificates imported on ACM utilise a minimum key length of 2048 bits or greater to ensure a sufficient level of security.
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: Note: You can't change the key length after importing a certificate. Instead, you must delete certificates with a key length smaller than 2,048 bits, and then the new RSA certificate should be imported with the desired key length.

To import the new certificate, Please refer to the below url
https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-api-cli.html#import-certificate-api

To delete the reported ACM RSA certificate, Please refer to the below url

https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-delete.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-acm-describe-certificate' AND json.rule = status equals "ISSUED" and keyAlgorithm starts with "RSA-" and keyAlgorithm equals RSA-1024```
PCSUP-22411 - policy

This is applicable to gcp cloud and is considered a high severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: N/A.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-firewall-rules-list' AND json.rule = (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(22,22) or (ports does not exist and (IPProtocol contains tcp or IPProtocol contains udp)))] exists```
AWS access keys are not rotated for 90 days
This policy identifies IAM users for which access keys are not rotated for 90 days. Access keys are used to sign API requests to AWS. As a security best practice, it is recommended that all access keys are regularly rotated to make sure that in the event of key compromise, unauthorized users are not able to gain access to your AWS services.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['KEYS_AND_SECRETS'].
Mitigation of this issue can be done as follows: 1. Sign in to the AWS console and navigate to the 'IAM' service.
2. Click on the user that was reported in the alert.
3. Click on 'Security Credentials' and for each 'Access Key'.
4. Follow the instructions below to rotate the Access Keys that are older than 90 days.
https://aws.amazon.com/blogs/security/how-to-rotate-access-keys-for-iam-users/.

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name = 'aws-iam-get-credential-report' AND json.rule = '(access_key_1_active is true and access_key_1_last_rotated != N/A and _DateTime.ageInDays(access_key_1_last_rotated) > 90) or (access_key_2_active is true and access_key_2_last_rotated != N/A and _DateTime.ageInDays(access_key_2_last_rotated) > 90)'```
AWS Amazon Machine Image (AMI) is publicly accessible
This policy identifies AWS AMIs which are owned by the AWS account and are accessible to the public. Amazon Machine Image (AMI) provides information to launch an instance in the cloud. The AMIs may contain proprietary customer information and should be accessible only to authorized internal users.
This is applicable to aws cloud and is considered a low 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 and navigate to 'EC2' service.
2. In the navigation pane, choose AMIs.
3. Select your AMI from the list, and then choose Actions, Modify Image Permissions.
4. Choose Private and choose Save..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-images' AND json.rule = image.public is true and image.shared is false and image.imageOwnerAlias does not exist```
Azure Storage Logging is not Enabled for Table Service for  Read Write and Delete requests

This is applicable to azure 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 = 'azure-storage-account-list' as X; config from cloud.resource where api.name = 'azure-storage-account-table-diagnostic-settings' AND json.rule = properties.logs[*].enabled all true as Y; filter 'not($.X.id contains $.Y.properties.storageAccountId)'; show X;```
OCI Event Rule and Notification does not exist for security list changes
This policy identifies the OCI compartments which do not have an Event Rule and Notification that gets triggered for security list changes. Monitoring and alerting on changes to Security Lists will help in identifying changes to traffic flowing into and out of Subnets within a Virtual Cloud Network. It is recommended that an Event Rule and Notification be configured to catch changes made to the security list.
NOTE: 
1. Event Rules are compartment scoped and will detect events in child compartments, it is recommended to create the Event rule at the root compartment level.
2. This policy will trigger alert if you have at least one Event Rule and Notification, even if OCI has single or multi compartments.
This is applicable to oci cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Login to the OCI Console
2. Type the Event into the Search box at the top of the Console.
3. Click the Event Service from the Services submenu
4. Select the compartment that should host the rule
5. Click Create Rule
6. Provide a Display Name and Description
7. Create a Rule Condition by selecting Networking in the Service Name Drop-down and selecting Network Security List – Change Compartment, Security List – Create, Security List - Delete and Security List – Update
8. In the Actions section select Notifications as Action Type
9. Select the Compartment that hosts the Topic to be used.
10. Select the Topic to be used
11. Optionally add Tags to the Rule
12. Click Create Rule.

Query:
```config from cloud.resource where cloud.type = 'oci' AND api.name = 'oci-events-rule' AND json.rule = '(isEnabled equals true) and (actions.actions[?any( actionType equals ONS and isEnabled equals true and lifecycleState equals ACTIVE)] exists) and (condition.eventType[*] contains com.oraclecloud.virtualnetwork.changesecuritylistcompartment and condition.eventType[*] contains com.oraclecloud.virtualnetwork.createsecuritylist and condition.eventType[*] contains com.oraclecloud.virtualnetwork.deletesecuritylist and condition.eventType[*] contains com.oraclecloud.virtualnetwork.updatesecuritylist) and actions.actions[*].topicId exists' as X; count(X) less than 1```
AWS Classic Load Balancer is in use for internet-facing applications
This policy identifies Classic Load Balancers that are being used for internet-facing HTTP/HTTPS applications. Classic Load Balancer should be used when you have an existing application running in the EC2-Classic network. Application Load Balancers (ALB) is recommended for internet-facing HTTP/HTTPS web applications.

For more details:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: To create Application Load Balancer (ALB) refer,
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html

Once Application Load Balancer created, you can delete the reported Classic Load Balancer by,
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 EC2 Dashboard
4. Click on 'Load Balancers', choose the reported load balancer
5. Click on the 'Actions' and from the drop-down click on 'Delete'
6. Click on the 'Yes, Delete'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elb-describe-load-balancers' AND json.rule = description.scheme contains internet-facing```
IBM Cloud VPC Flow Logs not enabled
This policy identifies IBM Cloud VPCs which have flow logs disabled. VPC Flow logs capture information about IP traffic going to and from network interfaces in your VPC. Flow logs are used as a security tool to monitor the traffic that is reaching your instances. Without the flow logs turned on, it is not possible to get any visibility into network traffic.
This is applicable to ibm cloud and is considered a informational severity issue.
Sample categories of findings relevant here are [].
Mitigation of this issue can be done as follows: To configure a Flow log on a VPC, please follow the below URL. Please make sure to provide target as 'VPC':
https://cloud.ibm.com/docs/vpc?topic=vpc-ordering-flow-log-collector&interface=ui
.

Query:
```config from cloud.resource where api.name = 'ibm-vpc' as X; config from cloud.resource where api.name = 'ibm-vpc-flow-log-collector' as Y; filter 'not($.X.id equals $.Y.target.id)'; show X;```
GCP Kubernetes Engine Clusters not configured with network traffic egress metering
This policy identifies Kubernetes Engine Clusters which are not configured with network traffic egress metering. When network traffic egress metering enabled, deployed DaemonSet pod meters network egress traffic by collecting data from the conntrack table, and exports the metered metrics to the specified destination. It is recommended to use, network egress metering so that you will be having data and track over monitored network traffic.

NOTE: Measuring network egress requires a network metering agent (NMA) running on each node. The NMA runs as a privileged pod, consumes some resources on the node (CPU, memory, and disk space), and enables the nf_conntrack_acct sysctl flag on the kernel (for connection tracking flow accounting). If you are comfortable with these caveats, you can enable network egress tracking for use with GKE usage metering.
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: Follow the below mentioned URL to enable GKE usage metering:

https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-usage-metering#enabling.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-container-describe-clusters' AND json.rule =  'resourceUsageExportConfig.enableNetworkEgressMetering does not exist or resourceUsageExportConfig.enableNetworkEgressMetering is false'```
Azure Monitoring log profile is not configured to export activity logs
This policy identifies the Azure accounts in which at least one monitoring log profile is not configured. A Log Profile controls how your Activity Log is exported; using which you could export the logs and store them for a longer duration for analyzing security activities within your Azure account. So it is recommended to have at least one monitoring log profile in an account to export all activity logs.
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 create a new log profile (Export to a storage account) use following command:
az monitor log-profiles create --name <NAME_OF_LOGPROFILE> --location <LOCATION> --locations <LOCATIONS_LIST> --categories "Delete" "Write" "Action" --enabled true --days <RETENTION_IN_DAYS> --storage-account-id "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUPNAME>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME>"

OR

To create a new log profile (Export to an event hub) use following command:
az monitor log-profiles create --name <NAME_OF_LOGPROFILE> --location <LOCATION> --locations <LOCATIONS_LIST> --categories "Delete" "Write" "Action" --enabled true --days <RETENTION_IN_DAYS> --service-bus-rule-id "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUPNAME>/providers/Microsoft.EventHub/namespaces/<EVENTHUB_NAMESPACENAME>/authorizationrules/RootManageSharedAccessKey"

NOTE: Make sure before referring Storage Account or Eventhub in above CLI commands, you have already created Storage Account or Eventhub as per your requirements..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-monitor-log-profiles-list' as X; count(X) less than 1```
HD-GCP VM instances have block project-wide SSH keys feature disabled
This policy identifies VM instances which have block project-wide SSH keys feature disabled. Project-wide SSH keys are stored in Compute/Project-metadata. Project-wide SSH keys can be used to login into all the instances within a project. Using project-wide SSH keys eases the SSH key management but if compromised, poses the security risk which can impact all the instances within a project. It is recommended to use Instance specific SSH keys which can limit the attack surface if the SSH keys are compromised.
This is applicable to gcp 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 GCP Portal
2. Go to Computer Engine (Left Panel)
3. Go to VM instances
4. From the list of VMs, choose the reported VM
5. Click on Edit button
6. Under SSH Keys section, Check 'Block project-wide SSH keys' on the checkbox
7. Click on Save.

Query:
```config from cloud.resource where api.name = 'gcloud-compute-project-info' AND json.rule = commonInstanceMetadata.kind equals "compute#metadata" and commonInstanceMetadata.items[?any(key contains "enable-oslogin" and (value contains "Yes" or value contains "Y" or value contains "True" or value contains "true" or value contains "TRUE" or value contains "1"))] does not exist and commonInstanceMetadata.items[?any(key contains "ssh-keys")] exists as X; config from cloud.resource where api.name = 'gcloud-compute-instances-list' AND json.rule = status equals RUNNING and ( metadata.items[?any(key exists and key contains "block-project-ssh-keys" and (value contains "Yes" or value contains "Y" or value contains "True" or value contains "true" or value contains "TRUE" or value contains "1"))] does not exist and metadata.items[?any(key exists and key contains "enable-oslogin" and (value contains "Yes" or value contains "Y" or value contains "True" or value contains "true" or value contains "TRUE" or value contains "1"))] does not exist and name does not start with "gke-") as Y; filter '$.Y.zone contains $.X.name'; show Y;```
AWS Default Security Group does not restrict all traffic
This policy identifies the default security groups which does not restrict inbound and outbound traffic. A VPC comes with a default security group whose initial configuration denies all inbound traffic and allow all outbound traffic. If you do not specify a security group when you launch an instance, the instance is automatically assigned to this default security group. As a result, the instance may accidentally send outbound traffic. It is recommended that to remove any inbound and outbound rules in the default security group and not to attach the default security group to any resources.
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: Before making any changes, please check the impact on your applications/services.

For Resources associated with the alerted security group:
1. Identify AWS resources that exist within the default security group
2. Create a set of least privilege security groups for those resources
3. Place the resources in those security groups
4. Remove the associated resources from the default security group

For alerted Security Groups:
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 'VPC' service
4. For each region, Click on 'Security Groups' specific to the alert
5. On section 'Inbound rules', Click on 'Edit Inbound Rules' and remove the existing rule, click on 'Save'
6. On section 'Outbound rules', Click on 'Edit Outbound Rules' and remove the existing rule, click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-security-groups' AND json.rule = '((groupName == default) and (ipPermissions[*] is not empty or ipPermissionsEgress[*] is not empty))'```
AWS Redshift cluster with commonly used master username and public access setting enabled
This policy identifies AWS Redshift clusters configured with commonly used master usernames like 'awsuser', 'administrator', or 'admin', and the public access setting is enabled.

AWS Redshift, a managed data warehousing service typically stores sensitive and critical data. Allowing public access increases the risk of unauthorized access, data breaches, and potential malicious activities. Using standard usernames increases the risk of password brute-force attacks by potential intruders.

As a recommended security measure, it is advised not to use commonly used usernames and to disable public access for the Redshift cluster.
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: Changing the default master user name for your existing Amazon Redshift clusters requires relaunching those clusters with a different master user name and migrating the existing data to the new clusters.

To launch the new Redshift database clusters,
1. Sign in to the AWS Management Console and open the Amazon Redshift console at https://console.aws.amazon.com/redshift/.
2. On the navigation menu, choose 'Clusters'. The clusters for your account in the current AWS Region are listed. A subset of the properties of each cluster is displayed in columns in the list.
3. Choose 'Create cluster' to create a cluster.
4. Follow the instructions on the console page to enter the properties for Cluster configuration.
5. In the 'Database configuration' section, type a unique (non-default) user name within the 'Master user name' field.
6. In the 'Additional configurations', Under the 'Network and security' Dropdown, Ensure the checkbox 'Turn on Publicly accessible' in the 'Publicly accessible' section is unchecked.
7. Fill out the rest of the fields available on this page with the information taken from the existing cluster.
8. Choose 'Create cluster' to create the cluster. The cluster might take several minutes to be ready to use.
9. Once the Cluster Status value changes to available and the DB Health status changes to healthy, the new cluster can used to load the existing data from the old cluster.
10. Once the data migration process is completed and all the data is loaded into the new Redshift cluster and all applications configured to use the new cluster, delete the old cluster.

To delete the existing cluster, refer to the below link.
https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-console.html#delete-cluster.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-redshift-describe-clusters' AND json.rule = publiclyAccessible is true and masterUsername is member of ("awsuser","administrator","admin")```
Azure Key vault used for machine learning workspace secrets storage is not enabled with audit logging
This policy identifies Azure Key vaults used for machine learning workspace secrets storage that are not enabled with audit logging.

Azure Key vaults are used to store machine learning workspace secrets and other sensitive information that is needed by the workspace. Enabling key vaults with audit logging will help in monitoring how and when machine learning workspace secrets are accessed, and by whom. This audit log data enhances visibility by providing valuable insights into the trail of interactions involving confidential information.

As a best practice,  it is recommended to enable audit event logging for key vaults used for machine learning workspace secrets storage.
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. Select 'Key vaults'
3. Select the key vault instance to modify
4. Select 'Diagnostic settings' under 'Monitoring'
5. Click on '+Add diagnostic setting'
6. In the 'Diagnostic setting' page, Select the Logs, Metrics and Destination details as per your business requirements.
7. Click on 'Save'.

Query:
```config from cloud.resource where api.name = 'azure-machine-learning-workspace' AND json.rule = properties.keyVault exists as X; config from cloud.resource where api.name = 'azure-key-vault-list' AND json.rule =  "not (diagnosticSettings.value[*].properties.logs[*].enabled any equal true and diagnosticSettings.value[*].properties.logs[*].enabled size greater than 0)" as Y; filter '$.X.properties.keyVault contains $.Y.name'; show Y;```
GCP External Load Balancer logging is disabled
This policy identifies GCP External Load Balancers using any of the protocols like HTTP, HTTPS, and HTTP/2 having logging disabled. 

GCP external load balancers distribute incoming traffic across multiple instances or services hosted on Google Cloud Platform. Feature \"logging\" for external load balancers captures and records detailed information about the traffic flowing through the load balancers. This includes data such as incoming requests, responses, errors, latency metrics, and other relevant information.  By enabling logging for external load balancers, you gain visibility into the performance, health, and security of the applications. Logged data comes handy for troubleshooting an incident, monitoring, analysis, and compliance purposes. 

It is recommended to enable logging for all external load balancers.
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 the GCP console.
2. Navigate to 'Network Services' and select 'Load Balancing' from the left panel.
3. Click on 'BACKENDS'.
4. Click on the load balancer link under the 'Load balancer' column for the reported backend service.
5. On the Load Balancer details page, click on 'EDIT'.
6. Click on 'Backend configuration', and then click the edit icon next to the reported backend service under the 'Backend services' section.
7. Under 'Logging', select 'Enable logging' checkbox.
8. Choose the appropriate Sample rate.
9. To finish editing the backend service, click 'UPDATE'.
10. To finish editing the load balancer, click 'UPDATE'..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-compute-external-backend-service' AND json.rule = backends exists and ( protocol equal ignore case "HTTP" or protocol equal ignore case "HTTPS" or protocol equal ignore case "HTTP2" ) and ( logConfig.enable does not exist or logConfig.enable is false )```