knarayan/cloud_posture_checks huggingface dataset:
AWS SageMaker endpoint data encryption at rest not configured with CMK
This policy identifies AWS SageMaker Endpoints not configured with data encryption at rest.

AWS SageMaker Endpoint configuration defines the resources and settings for deploying machine learning models to SageMaker endpoints. By default, SageMaker encryption uses transient keys if a KMS key is not specified, which does not provide the control and management benefits of AWS Customer Managed KMS Key. Enabling the encryption helps protect the integrity and confidentiality of the data on the storage volume attached to the ML compute instance that hosts the endpoint.

It is recommended to set encryption at rest to mitigate the risk of unauthorized access and potential data breaches.
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 ensure that SageMaker endpoint configuration with data encryption using the KMS key, you must create a new EndpointConfig by cloning the existing endpoint configuration used by the endpoint and update it with the required changes.

1. Sign in to the AWS Management Console.
2. Go to the SageMaker service dashboard at https://console.aws.amazon.com/sagemaker/.
3. In the navigation panel, under Inference, choose Endpoint configurations.
4. Select the SageMaker endpoint that is reported, Click on clone on top right corner.
5. Give a name to the Endpoint configuration and choose the Encryption key. For AWS Managed Keys, enter a KMS key ARN. For customer-managed keys, choose one from the drop-down.
6. Click Create endpoint configuration.

To update the endpoint using the endpoint configuration:

1. Sign in to the AWS Management Console.
2. Go to the SageMaker service dashboard at https://console.aws.amazon.com/sagemaker/.
3. In the navigation panel, under Inference, choose Endpoints.
4. Select the SageMaker endpoint that you want to examine, then click on it to access the resource configuration details under the "settings" tab.
5. Scroll down to Endpoint Configuration Settings and click Change.
6. choose to "use an existing endpoint configuration" and select the Endpoint configuration which is created earlier with encryption key specified.
7. Click "Select endpoint configuration" and click "Update Endpoint" for changes to propagate..

Query:
```config from cloud.resource where cloud.type = 'aws' and api.name = 'aws-sagemaker-endpoint-config' as X; config from cloud.resource where api.name = 'aws-kms-get-key-rotation-status' as Y; config from cloud.resource where api.name = 'aws-sagemaker-endpoint' AND json.rule = endpointStatus does not equal "Failed" as Z; filter '($.X.KmsKeyId does not exist or (($.X.KmsKeyId exists and $.Y.keyMetadata.keyState equals Disabled) and $.X.KmsKeyId equals $.Y.keyMetadata.arn)) and ($.X.EndpointConfigName equals $.Z.endpointConfigName)' ; show X;```
Alibaba Cloud Security group allow internet traffic to MS SQL port (1433)
This policy identifies Security groups that allow inbound traffic on MS SQL port (1433) from the public internet. As a best practice, restrict security groups to only allow permitted traffic and limit brute force attacks on your network.
This is applicable to alibaba_cloud 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 Alibaba Cloud Portal
2. Go to Elastic Compute Service
3. In the left-side navigation pane, choose Network & Security > Security Groups
4. Select the reported security group and then click Add Rules in the Actions column
5. In Inbound tab, Select the rule with 'Action' as Allow, 'Authorization Object' as 0.0.0.0/0 and 'Port Range' value as 1433, Click Modify in the Actions column
6. Replace the value 0.0.0.0/0 with specific IP address range
7. Click on 'OK'.

Query:
```config from cloud.resource where cloud.type = 'alibaba_cloud' AND api.name = 'alibaba-cloud-ecs-security-group' AND json.rule = "permissions is not empty and permissions[?(@.policy=='Accept' && @.direction=='ingress' && @.sourceCidrIp=='0.0.0.0/0')].portRange contains _Port.inRange(1433,1433)"```
Azure Microsoft Defender for Cloud security contact additional email is not set
This policy identifies the Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender) which has not set security contact additional email addresses. Microsoft Defender for Cloud emails the subscription owners whenever a high-severity alert is triggered for their subscription. Providing a security contact email address as an additional email address ensures that the proper people are aware of any potential compromise in order to mitigate the risk in a timely fashion.
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. Click on 'Email notifications'
6. Enter a valid security contact email address (or multiple addresses separated by commas) in the 'Additional email addresses' field
7. Select 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-security-center-settings' AND json.rule = (securityContacts is empty or securityContacts[?any(properties.email is empty)] exists) and pricings[?any(properties.pricingTier equal ignore case Standard)] exists```
GCP Cloud Function has risky basic role assigned
This policy identifies GCP Cloud Functions configured with the risky basic role. Basic roles are highly permissive roles that existed prior to the introduction of IAM and grant wide access over project to the grantee. To reduce the blast radius and defend against privilege escalations if the Cloud Function is compromised, it is recommended to follow the principle of least privilege and avoid use of basic roles.
This is applicable to gcp cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['PRIVILEGE_ESCALATION'].
Mitigation of this issue can be done as follows: It is recommended to the principle of least privilege for granting access.

To assign desired service account to the cloud funtion, please refer to the URL given below:
https://cloud.google.com/functions/docs/securing/function-identity#individual

To update priviledges granted to a service account, please refer to the URL given below:
https://cloud.google.com/iam/docs/granting-changing-revoking-access.

Query:
```config from cloud.resource where api.name = 'gcloud-projects-get-iam-user' AND json.rule = roles[*] contains "roles/editor" or roles[*] contains "roles/owner" as X; config from cloud.resource where api.name = 'gcloud-cloud-function' as Y; filter '$.Y.serviceAccountEmail equals $.X.user'; show Y;```
AWS Opensearch domain audit logging disabled
This policy identifies AWS Opensearch domains with audit logging disabled.

Opensearch audit logs enable you to monitor user activity on your Elasticsearch clusters, such as authentication successes and failures, OpenSearch requests, index updates, and incoming search queries.

It is recommended to enable audit logging for an Elasticsearch domain to audit activity in the domain.
This is applicable to aws cloud and is considered a informational severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: To enable the AWS Opensearch domain with audit logs:

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

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-es-describe-elasticsearch-domain' AND json.rule = domainProcessingStatus equal ignore case active and (logPublishingOptions does not exist or logPublishingOptions.AUDIT_LOGS.enabled is false)```
GCP SQL server instance database flag user connections is not set
This policy identifies GCP SQL server instances where the database flag 'user connections' is not set. The user connections option specifies the maximum number of simultaneous user connections (value varies in range 10-32,767) that are allowed on an instance of SQL Server. The default is 0, which means that the maximum (32,767) user connections are allowed. It is recommended to set database flag user connections for SQL Server instance according to organization-defined value.
This is applicable to gcp cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Log in to the GCP console
2. Navigate SQL Instances page
3. Click on the reported SQL server instance
4. Click on EDIT
5. If the flag has not been set on the instance, 
Under 'Customize your instance' section, go to 'Flags and parameters', click on 'ADD FLAG' in the 'New database flag' section, choose the flag 'user connections' from the drop-down menu, and set the value an appropriate value(10-32,767)
6. Click on DONE
7. Click on SAVE 
8. If 'Changes requires restart' pop-up appears, click on 'SAVE AND RESTART'
.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = 'state equals RUNNABLE and databaseVersion contains SQLSERVER and settings.databaseFlags[*].name does not contain "user connections"'```
mkurter-testing--0002

This is applicable to azure 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 = 'azure' aND api.name = 'azure-vm-list' AND json.rule = ['properties.storageProfile'].osDisk.vhd.uri exists```
mkurter-testing-pcf-azure

This is applicable to azure 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 = 'azure' AND cloud.accountgroup NOT IN ( 'AWS' ) AND api.name = 'azure-vm-list' AND json.rule = ['properties.storageProfile'].osDisk.vhd.uri exists```
GCP API key not rotating in every 90 days
This policy identifies GCP API keys for which the creation date is aged more than 90 days. Google recommends using the standard authentication flow instead of API Keys. However, there are limited cases where API keys are more appropriate. API keys should be rotated to ensure that data cannot be accessed with an old key that might have been lost, cracked, or stolen.
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 google cloud console
2. Navigate to 'Credentials', Under service 'APIs & Services'
3. In the section 'API Keys', Click on the reported 'API Key Name'
4. Click on 'REGENERATE KEY' to rotate the API key
5. On the pop-up window click on 'REPLACE KEY'
6. Validate the Creation date once it is updated..

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-api-key' AND json.rule = "_DateTime.ageInDays(createTime) > 90"```
AWS ECS cluster not configured with active services
This policy identifies ECS clusters that are not configured with active services. ECS service enables you to run and maintain a specified number of instances of a task definition simultaneously in an Amazon ECS cluster. It is recommended to remove Idle ECS clusters to reduce the container attack surface or create new services for the reported ECS cluster.

For details:
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html
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 delete the reported idle ECS Cluster follow below mentioned URL:
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete_cluster.html

To create new container services follow below mentioned URL:
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service.html.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ecs-cluster' AND json.rule = status equals ACTIVE and activeServicesCount equals 0```
Azure Application Gateway is configured with SSL policy having TLS version 1.1 or lower
This policy identifies the Application Gateway instances that are configured to use TLS versions 1.1 or lower as the minimum protocol version. The Application Gateway supports SSL encryption using multiple TLS versions and by default, it supports TLS version 1.0 as the minimum version. As a best practice set the minimum protocol version to TLSv1.2 or more (if you use custom SSL policy) or use the predefined policy use policy which has support TLSv1.2 or more.

For more details:
https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-ssl-policy-overview
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: To set the SSL policy with TLSv1.2 or more, refer below URL:
https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-configure-listener-specific-ssl-policy.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-application-gateway' AND json.rule = (['properties.sslPolicy'] does not exist and ['properties.defaultPredefinedSslPolicy'] does not equal ignore case AppGwSslPolicy20220101) or (['properties.sslPolicy'].['policyType'] equal ignore case Predefined and (['properties.sslPolicy'].['policyName'] equal ignore case AppGwSslPolicy20150501 or ['properties.sslPolicy'].['policyName'] equal ignore case AppGwSslPolicy20170401)) or (['properties.sslPolicy'].['policyType'] equal ignore case Custom and (['properties.sslPolicy'].['minProtocolVersion'] equal ignore case TLSv1_0 or ['properties.sslPolicy'].['minProtocolVersion'] equal ignore case TLSv1_1))```
Azure Function App authentication is off
This policy identifies Azure Function App which has set authentication to off. Azure Function App Authentication is a feature that can prevent anonymous HTTP requests from reaching the API app, or authenticate those that have tokens before they reach the API app. If an anonymous request is received from a browser, Function App will redirect to a logon page. To handle the logon process, a choice from a set of identity providers can be made, or a custom authentication mechanism can be implemented.
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 the Azure portal
2. Navigate to Function App
3. Click on the reported Function App
4. Under Settings section, Click on 'Authentication'
5. Click on 'Add identity provider'
6. Select an identity provider from the dropdown and choose other parameters as per your requirement
7. Click on 'Add'.

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 functionapp and kind does not contain workflowapp and kind does not equal app and config.siteAuthEnabled is false```
AWS Elasticsearch domain Encryption for data at rest is disabled
This policy identifies Elasticsearch domains for which encryption is disabled. Encryption of data at rest is required to prevent unauthorized users from accessing the sensitive information available on your Elasticsearch domains components. This may include all data of file systems, primary and replica indices, log files, memory swap files and automated snapshots. The Elasticsearch uses AWS KMS service to store and manage the encryption keys. It is highly recommended to implement encryption at rest when you are working with production data that have sensitive information, to protect from unauthorized access.
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: Enabling the encryption feature on existing domains requires Elasticsearch 6.7 or later. If your Elasticsearch 6.7 or later, follow below steps to enable encryption on existing Elasticsearch domain:
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 Elasticsearch Service Dashboard
4. Choose reported Elasticsearch domain
5. Click on 'Actions' button, from drop-down select 'Modify encryptions'
6.In Modify encryptions page, Select the 'Enable encryption of data at rest' checkbox and Choose KMS key as per your requirement. It is recommended to choose KMS CMKs instead of default KMS [Default(aws/es)]; to get more grannular control on your Elasticsearch domain data.
7. Click on 'Submit'.

If your Elasticsearch is less than 6.7 version, then AWS Elasticsearch Domain encryption can be set only at the time of the creation of domain. So to fix this alert, create a new domain with encryption using KMS Keys and then migrate all required Elasticsearch domain data from the reported Elasticsearch domain to this newly created domain.
To set up the new Elasticsearch domain with encryption using KMS Key, refer the following URL:
https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-createupdatedomains.html

To delete reported ES domain, refer the following URL:
https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-gsg-deleting.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 (encryptionAtRestOptions.enabled is false or encryptionAtRestOptions does not exist)'```
Copy of AWS EKS cluster endpoint access publicly enabled
When you create a new cluster, Amazon EKS creates an endpoint for the managed Kubernetes API server that you use to communicate with your cluster (using Kubernetes management tools such as kubectl). By default, this API server endpoint is public to the internet, and access to the API server is secured using a combination of AWS Identity and Access Management (IAM) and native Kubernetes Role Based Access Control (RBAC).

This policy checks your Kubernetes cluster endpoint access and triggers an alert if publicly enabled.
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: Enable private access to the Kubernetes API server so that all communication between your worker nodes and the API server stays within your VPC. Disable public access to your API server so that it's not accessible from the internet.

1. Login to AWS Console
2. Navigate to the Amazon EKS dashboard
3. Choose the name of the cluster to display your cluster information
4. Under Networking, choose 'Manage networking'
5. Select 'Private' radio button
6. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-eks-describe-cluster' AND json.rule =  resourcesVpcConfig.endpointPublicAccess is true or resourcesVpcConfig.endpointPrivateAccess is false```
Azure Key Vault Key has no expiration date (RBAC Key vault)
This policy identifies Azure Key Vault keys that do not have an expiration date for the RBAC Key vaults. As a best practice, set an expiration date for each key and rotate your keys regularly.

Before you activate this policy, ensure that you have added the Prisma Cloud Service Principal to each Key Vault: https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin/connect-your-cloud-platform-to-prisma-cloud/onboard-your-azure-account/azure-onboarding-checklist

Alternatively, run the following command on the Azure cloud shell:
az keyvault list | jq '.[].id' | xargs -I {} az role assignment create --assignee "<Object ID of Prisma Cloud Principal>" --role "Key Vault Reader" --scope {}
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. Select 'All services' > 'Key vaults'.
3. Select the Key vault where the key is stored.
4. Select 'Keys', and select the key that you need to modify.
5. Select the current version.
6. Set the expiration date.
7. 'Save' your changes..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-key-vault-list' and json.rule = keys[?any(attributes.exp equals -1 and attributes.enabled contains true)] exists and properties.enableRbacAuthorization is true```
Azure SQL Server auditing is disabled
Audit logs can help you find suspicious events, unusual activity, and trends to analyze database events. Auditing the SQL Server, at the server-level, enables you to track all new and existing databases on the server.

This policy identifies SQL servers do not have auditing enabled. As a best practice, enable auditing on each SQL server so that the database are audited, regardless of the database auditing settings.
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 the Azure Portal.
2. Select 'SQL servers', and select the SQL server instance you want to modify.
3. Select 'Auditing', and set the status to  'On'.
4. 'Save' your changes..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-sql-server-list' AND json.rule =  "$.serverBlobAuditingPolicy.properties.retentionDays does not exist or $.serverBlobAuditingPolicy.properties.state equals Disabled"```