knarayan/cloud_posture_checks huggingface dataset:
Azure SQL Server audit log retention is less than 91 days
Audit Logs can help you find suspicious events, unusual activity, and trends. Auditing the SQL server, at the server-level, allows you to track all existing and newly created databases on the instance.

This policy identifies SQL servers which do not retain audit logs for more than 90 days. As a best practice, configure the audit logs retention time period to be greater than 90 days.
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. Navigate to 'SQL servers' dashboard
3. Select the SQL server instance you want to modify
4. Select 'Auditing', and verify that 'Enable Azure SQL Auditing' is set
5. If Storage is selected, expand 'Advanced properties'
6. Set the Retention (days) setting is greater than 90 days or 0 for unlimited retention.
7. Click on 'Save'.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-sql-server-list' AND json.rule = serverBlobAuditingPolicy.properties.state equal ignore case Enabled and serverBlobAuditingPolicy.properties.storageEndpoint is not empty and (serverBlobAuditingPolicy.properties.retentionDays does not equal 0 and serverBlobAuditingPolicy.properties.retentionDays < 91)```
AWS IAM password policy does not have a number
Checks to ensure that IAM password policy requires a number. AWS IAM (Identity & Access Management) allows customers to secure AWS console access. As a security best practice, customers must have strong password policies in place.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['WEAK_PASSWORD'].
Mitigation of this issue can be done as follows: 1. Login to the AWS console and navigate to the 'IAM' service.
2. On the left navigation panel, Click on 'Account Settings'
3. check 'Require at least one number'.
4. Click on 'Apply password policy'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name='aws-iam-get-account-password-policy' AND json.rule='isDefaultPolicy is true or requireNumbers is false or requireNumbers does not exist'```
API testing

This is applicable to ibm cloud and is considered a critical 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 = 'ibm-vpc-block-storage-volume' as X; config from cloud.resource where api.name = 'ibm-key-protect-registration' as Y;filter 'not($.Y.resourceCrn equals $.X.crn)' ; show X;```
Azure PostgreSQL database server with log connections parameter disabled
This policy identifies PostgreSQL database servers for which server parameter is not set for log connections. Enabling log_connections helps PostgreSQL Database to log attempted connection to the server, as well as successful completion of client authentication. Log data can be used to identify, troubleshoot, and repair configuration errors and suboptimal performance.
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. Login to Azure console.
2. Navigate to 'Azure Database for PostgreSQL servers' dashboard
3. Click on the alerted database name
4. Go to 'Server parameters' under 'settings’ block
5. From the list of parameters find 'log_connections' and set it to 'on'
6. Click on 'Save' button from top menu to save the change..

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-postgresql-server' AND json.rule = "configurations.value[?(@.name=='log_connections')].properties.value equals OFF or configurations.value[?(@.name=='log_connections')].properties.value equals off"```
AWS SNS topic policy overly permissive for publishing
This policy identifies AWS SNS topics that have SNS policy overly permissive for publishing. When a message is published, Amazon SNS attempts to deliver the message to the subscribed endpoints. To protect these messages from attackers and unauthorized accesses, permissions should be given to only authorized users.

For more details:
https://docs.aws.amazon.com/sns/latest/dg/sns-security-best-practices.html#implement-least-privilege-access
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: 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 'Simple Notification Service' dashboard
4. Go to 'Topics', from the left panel
5. Select the reported SNS topic
6. Click on the 'Edit' button from the top options bar
7. On the edit page go to the 'Access Policy - optional' section
8. Add the restrictive 'Condition' statement to the JSON editor to specify who can publish messages to the topic.
9. Click on 'Save changes'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-sns-get-topic-attributes' AND json.rule = Policy.Statement[?any(Effect equals Allow and (Principal.AWS equals * or Principal equals *) and (Action contains SNS:Publish or Action contains sns:Publish) and (Condition does not exist or Condition all empty))] exists```
GCP Google Workspace User not enrolled with 2-step verification
This policy identifies Google Workspace Users who do not have 2-Step Verification enabled. 

Enabling 2-Step Verification for Google Workspace users significantly enhances account security by adding an additional layer of authentication beyond just passwords. This reduces the risk of unauthorized access, protects sensitive data, and ensures compliance with security best practices. Implementing this measure strengthens overall organizational security and helps safeguard against potential cyber threats.

It is recommended to enable 2-Step Verification for all users as it provides increased security for user account settings and resources.
This is applicable to gcp 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: Workspace users should be allowed to turn on 2-Step verification (2SV) before enabling 2SV. Follow the steps mentioned below to allow users to turn on 2SV.
1. Sign in to Workspace Admin Console with an administrator account. 
2. Go to Menu then 'Security' > 'Authentication' > '2-step verification'.
3. Check the 'Allow users to turn on 2-Step Verification' box.
4. Select 'Enforcement' as per need.
5. Click Save.

For more details, please refer to below URL:
https://support.google.com/a/answer/9176657


To enable 2-Step Verification for GCP Workspace User accounts, follow the steps below.
1. Open your Google Account.
2. In the navigation panel, select 'Security'.
3. Under 'How you sign in to Google', select '2-Step Verification' > 'Get started'.
4. Follow the on-screen steps.

For more details, please refer to below URL:
https://support.google.com/accounts/answer/185839.

Query:
```config from cloud.resource where api.name = 'gcloud-domain-users' AND json.rule = isAdmin is false and isEnrolledIn2Sv is false and archived is false and suspended is false```
pk-gcp-empty

This is applicable to gcp cloud and is considered a critical 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-logging-sinks-list' AND json.rule = name contains "pk"```
OCI Event Rule and Notification does not exist for Identity Provider changes
This policy identifies the OCI compartments which do not have an Event Rule and Notification that gets triggered for Identity Provider changes. Monitoring and alerting on changes to Identity Provider will help in identifying changes to the security posture. It is recommended that an Event Rule and Notification be configured to catch changes made to Identity Provider.
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 Identity in the Service Name Drop-down and selecting Identity Provider – Create, Identity Provider - Delete and Identity Provider – 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.identitycontrolplane.createidentityprovider and condition.eventType[*] contains com.oraclecloud.identitycontrolplane.deleteidentityprovider and condition.eventType[*] contains com.oraclecloud.identitycontrolplane.updateidentityprovider) and actions.actions[*].topicId exists' as X; count(X) less than 1```
AWS Log metric filter and alarm does not exist for unauthorized API calls
This policy identifies the AWS regions which do not have a log metric filter and alarm for unauthorized API calls. Monitoring unauthorized API calls will help reveal application errors and may reduce the time to detect malicious activity. It is recommended that a metric filter and alarm be established for unauthorized API calls.

NOTE: This policy will trigger alert if you have at least one Cloudtrail with the multi trial is enabled, Logs all management events in your account and is not set with specific log metric filter and alarm.
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. Sign in to AWS Console
2. Navigate to CloudWatch dashboard
3. Click on 'Log groups' in the 'Logs' section (Left panel)
4. Select the log group created for your CloudTrail trail event logs (CloudTrail should be multi trail enabled with all management events captured) and click 'Create Metric Filter' button.
5. In 'Define Logs Metric Filter' page, add 'Filter pattern' value as 
{ ($.errorCode = "*UnauthorizedOperation") || ($.errorCode = "AccessDenied*") }
and Click on 'Assign Metric'
6. In 'Create Metric Filter and Assign a Metric' page, Choose Filter Name, Metric Details parameter according to your requirement and click on 'Create Filter'
7. Click on 'Create Alarm',
	- In Step 1 specify metric details and conditions details as required and click on 'Next'
	- In Step 2 Select an SNS topic either by creating a new topic or use existing SNS topic/ARN and click on 'Next'
	- In Step 3 Select name and description to alarm and click on 'Next'
	- In Step 4 Preview your data entered and click on 'Create Alarm'.

Query:
```config from cloud.resource where api.name = 'aws-logs-describe-metric-filters' as X; config from cloud.resource where api.name = 'aws-cloudwatch-describe-alarms' as Y; config from cloud.resource where api.name = 'aws-cloudtrail-describe-trails' as Z; filter '(($.Z.cloudWatchLogsLogGroupArn is not empty and $.Z.cloudWatchLogsLogGroupArn contains $.X.logGroupName and $.Z.isMultiRegionTrail is true and $.Z.includeGlobalServiceEvents is true) and (($.X.filterPattern contains "errorCode=" or $.X.filterPattern contains "errorCode =") and ($.X.filterPattern does not contain "errorCode!=" and $.X.filterPattern does not contain "errorCode !=") and $.X.filterPattern contains "UnauthorizedOperation" and $.X.filterPattern contains "AccessDenied") and ($.X.metricTransformations[*] contains $.Y.metricName))'; show X; count(X) less than 1```
AWS ECS task definition logging configuration disabled
This policy identifies AWS ECS task definitions that have logging configuration disabled.

AWS ECS logging involves capturing and storing container logs for monitoring, troubleshooting, and analysis purposes within the Amazon ECS environment. Collecting data from task definitions gives visibility, which can aid in debugging processes and determining the source of issues.

It is recommended to configure logging for an AWS ECS task definition.
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 log configuration for your Amazon ECS task definitions, follow these steps:

1. Sign into the AWS console and navigate to the Amazon ECS console
2. In the navigation pane, choose 'Task definitions'
3. Choose the task definition to be updated
4. Select 'Create new revision', and then click on 'Create new revision'.
5. On the 'Create new task definition revision' page, select the container with logging configuration disabled
6. Under the 'Logging' section, enable 'Use log collection'
7. Select the log driver to be used under the dropdown
8. At 'awslogs-group', specify the log group that the logdriver sends its log streams to
9. Specify the remaining configuration as per the requirements
10. Choose 'Update'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ecs-describe-task-definition' AND json.rule = status equals ACTIVE and containerDefinitions[?any(logConfiguration.logDriver does not exist)] exists```
AWS Athena Workgroup data encryption at rest not configured
This policy identifies AWS Athena workgroups not configured with data encryption at rest.

AWS Athena workgroup enables you to isolate queries for you or your group of users from other queries in the same account, to set the query results location and the encryption configuration. By default, Athena workgroup query run results are not encrypted at rest and client side settings can override the workgroup settings. Encrypting workgroups and preventing overrides from the client side helps in protecting the integrity and confidentiality of the data stored on Athena.

It is recommended to set encryption at rest and enable 'override client-side settings' to mitigate the risk of unauthorized access and potential data breaches.
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 enable encryption at rest for the Athena workgroup, follow the below steps:

1. Sign in to the AWS Management Console and open the Amazon Athena console.
2. Under the navigation bar, click on Workgroups.
3. Select the alerted workgroup. Click on 'Edit'.
4. For Athena-based engines, under 'Query result configuration', enable 'Encrypt query results'.
5. Select 'Encryption type' based on the requirements. Make sure to set 'Minimum encryption'.
6. Under 'Settings', enable 'Override client-side settings'.
7. For Apache Spark-based engines, under 'Calculation result settings', enable 'Encrypt query results'.
8. Select 'Encryption type' based on the requirements.
9. Click on 'Save changes'..

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-athena-workgroup' AND json.rule = WorkGroup.State equal ignore case enabled and (WorkGroup.Configuration.ResultConfiguration.EncryptionConfiguration does not exist or (WorkGroup.Configuration.EngineVersion.EffectiveEngineVersion contains Athena and WorkGroup.Configuration.EnforceWorkGroupConfiguration is false))```
Azure Data Explorer cluster disk encryption is disabled
This policy identifies Azure Data Explorer clusters in which disk encryption is disabled. Enabling encryption at rest on your cluster provides data protection for stored data. It is recommended to enable disk encryption on Data Explorer clusters.

For more details: 
https://learn.microsoft.com/en-us/azure/data-explorer/cluster-encryption-disk
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 configure Disk encryption on existing Data Explorer cluster, follow below URL:
https://learn.microsoft.com/en-us/azure/data-explorer/cluster-encryption-disk.

Query:
```config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-kusto-clusters' AND json.rule = properties.state equal ignore case Running and properties.enableDiskEncryption is false```
GCP Cloud Function is publicly accessible by allUsers or allAuthenticatedUsers
This policy identifies GCP Cloud Functions that are publicly accessible by allUsers or allAuthenticatedUsers. This includes both Cloud Functions v1 and Cloud Functions v2.

Granting permissions to 'allusers' or 'allAuthenticatedUsers' on any resource in GCP makes the resource public. Public access over cloud functions can lead to unauthorized invocations of the function or leakage of sensitive information such as the function's source code. 

Following the least privileged access policy, it is recommended to grant access restrictively and avoid granting permissions to allUsers or allAuthenticatedUsers unless absolutely needed.
This is applicable to gcp cloud and is considered a medium severity issue.
Sample categories of findings relevant here are ['INTERNET_EXPOSURE'].
Mitigation of this issue can be done as follows: It is recommended to review and add appropriate, but restrictive roles before revoking access.

To revoke access from 'allusers'/'allAuthenticatedUsers', follow the below mentioned steps:
1. Login to the GCP console
2. Navigate to service 'Cloud Functions'
4. Select the required cloud function
5. Click on 'PERMISSIONS' button
6. Filter for 'allUsers'
7. Click on the 'Remove principal' button (bin icon)
8. Select 'Remove allUsers from all roles on this resource. They may still have access via inherited roles.'
9. Click 'Remove'
10. Repeat steps 6-9 for 'allAuthenticatedUsers'.

Query:
```config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-cloud-function-v2' AND json.rule = state equals ACTIVE and iamPolicy.bindings[?any(members[*] is member of ("allAuthenticatedUsers","allUsers"))] exists```
Azure Microsoft Defender for Cloud security contact phone number is not set
This policy identifies Subscriptions that are not set with security contact phone number for Azure Microsoft Defender for Cloud (previously known as Azure Security Center and Azure Defender). It is recommended to set security contact phone number to receive notifications when Microsoft Defender for Cloud detects compromised resources.
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: Use below Azure CLI example command to create new contact with phone number details for Azure Microsoft Defender for Cloud,

az security contact create -n "default1" --email 'john@contoso.com' --phone '214275-4038' --alert-notifications 'on' --alerts-admins 'on'

For more information:
https://docs.microsoft.com/en-us/cli/azure/security/contact?view=azure-cli-latest.

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.phone is empty)] exists) and pricings[?any(properties.pricingTier equal ignore case Standard)] exists```
AWS Cloudfront Distribution with S3 have Origin Access set to disabled
This policy identifies the AWS CloudFront distributions which are utilizing S3 bucket and have Origin Access Disabled. The origin access identity feature should be enabled for all your AWS CloudFront CDN distributions in order to restrict any direct access to your objects through Amazon S3 URLs.
This is applicable to aws cloud and is considered a low severity issue.
Sample categories of findings relevant here are ['MISCONFIGURATION'].
Mitigation of this issue can be done as follows: 1. Sign in to the AWS Console
2. Go to CloudFront
3. Choose the reported Distribution
4. Click on Distribution Settings
5. Click on 'Origins and Origin Groups
6. Select the S3 bucket and click on Edit
7. On the 'Restrict Bucket Access', Select Yes
8. Click on 'Yes, Edit'.

Query:
```config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-cloudfront-list-distributions' AND json.rule = 'origins.items[*].s3OriginConfig exists and origins.items[*].s3OriginConfig.originAccessIdentity is empty and origins.items[*].originAccessControlId is empty'```
OCI Event Rule and Notification does not exist for route tables changes
This policy identifies the OCI compartments which do not have an Event Rule and Notification that gets triggered for route tables changes. Monitoring and alerting on changes to route tables will help in identifying changes to traffic flowing to or from Virtual Cloud Networks and Subnets. It is recommended that an Event Rule and Notification be configured to catch changes made to route tables.
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 Route Table – Change Compartment, Route Table – Create, Route Table - Delete and Route Table – 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.changeroutetablecompartment and condition.eventType[*] contains com.oraclecloud.virtualnetwork.createroutetable and condition.eventType[*] contains com.oraclecloud.virtualnetwork.deleteroutetable and condition.eventType[*] contains com.oraclecloud.virtualnetwork.updateroutetable) and actions.actions[*].topicId exists' as X; count(X) less than 1```