elastic · orouz · Aug 15, 2023 · Aug 15, 2023 · Aug 15, 2023
@@ -4,6 +4,11 @@
 # 1.4.x - 8.9.x
 # 1.3.x - 8.8.x
 # 1.2.x - 8.7.x
+- version: "1.5.0-preview34"
+  changes:
+    - description: Add CIS GCP rule templates
+      type: enhancement
+      link: https://github.com/elastic/integrations/pull/7390
 - version: "1.5.0-preview33"
   changes:
     - description: Remove default value for project id

@@ -0,0 +1,38 @@
+{
+    "id": "0e318770-7077-5996-afd8-27ca34fc5446",
+    "type": "csp-rule-template",
+    "attributes": {
+        "metadata": {
+            "impact": "Enabling of logging may result in your project being charged for the additional logs usage. These charges could be significant depending on the size of the organization.",
+            "default_value": "",
+            "references": "1. https://cloud.google.com/logging/docs/logs-based-metrics/\n2. https://cloud.google.com/monitoring/custom-metrics/\n3. https://cloud.google.com/monitoring/alerts/\n4. https://cloud.google.com/logging/docs/reference/tools/gcloud-logging\n5. https://cloud.google.com/vpc/docs/firewalls",
+            "id": "0e318770-7077-5996-afd8-27ca34fc5446",
+            "name": "Ensure That the Log Metric Filter and Alerts Exist for VPC Network Firewall Rule Changes",
+            "profile_applicability": "* Level 2",
+            "description": "It is recommended that a metric filter and alarm be established for Virtual Private Cloud (VPC) Network Firewall rule changes.",
+            "rationale": "Monitoring for Create or Update Firewall rule events gives insight to network access changes and may reduce the time it takes to detect suspicious activity.",
+            "audit": "**From Google Cloud Console**\n\n**Ensure that the prescribed log metric is present:**\n\n1. Go to `Logging/Logs-based Metrics` by visiting [https://console.cloud.google.com/logs/metrics](https://console.cloud.google.com/logs/metrics).\n\n2. In the `User-defined Metrics` section, ensure at least one metric `<Log_Metric_Name>` is present with this filter text:\n\n```\nresource.type=\"gce_firewall_rule\" \nAND (protoPayload.methodName:\"compute.firewalls.patch\" \nOR protoPayload.methodName:\"compute.firewalls.insert\"\nOR protoPayload.methodName:\"compute.firewalls.delete\")\n```\n\n**Ensure that the prescribed alerting policy is present:**\n\n3. Go to `Alerting` by visiting [https://console.cloud.google.com/monitoring/alerting](https://console.cloud.google.com/monitoring/alerting).\n\n4. Under the `Policies` section, ensure that at least one alert policy exists for the log metric above. Clicking on the policy should show that it is configured with a condition. For example, `Violates when: Any logging.googleapis.com/user/<Log Metric Name> stream` `is above a threshold of zero(0) for greater than zero(0) seconds` means that the alert will trigger for any new owner change. Verify that the chosen alerting thresholds make sense for the user's organization.\n\n5. Ensure that appropriate notification channels have been set up.\n\n**From Google Cloud CLI**\n\n**Ensure that the prescribed log metric is present:**\n\n6. List the log metrics:\n```\ngcloud logging metrics list --format json\n```\n7. Ensure that the output contains at least one metric with the filter set to: \n\n```\nresource.type=\"gce_firewall_rule\" \nAND (protoPayload.methodName:\"compute.firewalls.patch\" \nOR protoPayload.methodName:\"compute.firewalls.insert\"\nOR protoPayload.methodName:\"compute.firewalls.delete\")\n```\n\n8. Note the value of the property `metricDescriptor.type` for the identified metric, in the format `logging.googleapis.com/user/<Log Metric Name>`.\n\n**Ensure that the prescribed alerting policy is present:**\n\n9. List the alerting policies:\n```\ngcloud alpha monitoring policies list --format json\n```\n10. Ensure that the output contains an least one alert policy where:\n- `conditions.conditionThreshold.filter` is set to `metric.type=\\\"logging.googleapis.com/user/<Log Metric Name>\\\"`\n- AND `enabled` is set to `true`",
+            "remediation": "**From Google Cloud Console**\n\n**Create the prescribed log metric:**\n\n1. Go to `Logging/Logs-based Metrics` by visiting [https://console.cloud.google.com/logs/metrics](https://console.cloud.google.com/logs/metrics) and click \"CREATE METRIC\".\n\n2. Click the down arrow symbol on the `Filter Bar` at the rightmost corner and select `Convert to Advanced Filter`.\n\n3. Clear any text and add: \n\n```\nresource.type=\"gce_firewall_rule\" \nAND (protoPayload.methodName:\"compute.firewalls.patch\" \nOR protoPayload.methodName:\"compute.firewalls.insert\"\nOR protoPayload.methodName:\"compute.firewalls.delete\")\n```\n\n4. Click `Submit Filter`. Display logs appear based on the filter text entered by the user.\n\n5. In the `Metric Editor` menu on the right, fill out the name field. Set `Units` to `1` (default) and `Type` to `Counter`. This ensures that the log metric counts the number of log entries matching the advanced logs query.\n\n6. Click `Create Metric`. \n\n**Create the prescribed Alert Policy:** \n\n7. Identify the newly created metric under the section `User-defined Metrics` at [https://console.cloud.google.com/logs/metrics](https://console.cloud.google.com/logs/metrics).\n\n8. Click the 3-dot icon in the rightmost column for the new metric and select `Create alert from Metric`. A new page displays.\n\n9. Fill out the alert policy configuration and click `Save`. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value ensures that a notification is triggered for every owner change in the project:\n```\nSet `Aggregator` to `Count`\n\nSet `Configuration`:\n\n- Condition: above\n\n- Threshold: 0\n\n- For: most recent value\n```\n\n10. Configure the desired notifications channels in the section `Notifications`.\n\n11. Name the policy and click `Save`.\n\n**From Google Cloud CLI**\n\nCreate the prescribed Log Metric\n- Use the command: gcloud logging metrics create \n\nCreate the prescribed alert policy: \n- Use the command: gcloud alpha monitoring policies create",
+            "section": "Logging and Monitoring",
+            "version": "1.0",
+            "tags": [
+                "CIS",
+                "GCP",
+                "CIS 2.7",
+                "Logging and Monitoring"
+            ],
+            "benchmark": {
+                "name": "CIS Google Cloud Platform Foundation",
+                "version": "v2.0.0",
+                "id": "cis_gcp",
+                "rule_number": "2.7",
+                "posture_type": "cspm"
+            },
+            "rego_rule_id": "cis_2_7"
+        }
+    },
+    "migrationVersion": {
+        "csp-rule-template": "8.7.0"
+    },
+    "coreMigrationVersion": "8.7.0"
+}
@@ -0,0 +1,38 @@
+{
+    "id": "1316108c-33a8-5198-9529-45716c5a87b1",
+    "type": "csp-rule-template",
+    "attributes": {
+        "metadata": {
+            "impact": "Turning on logging will increase the required storage over time. Mismanaged logs may cause your storage costs to increase. Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage.",
+            "default_value": "",
+            "references": "1. https://cloud.google.com/sql/docs/postgres/flags\n2. https://www.postgresql.org/docs/current/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT",
+            "id": "1316108c-33a8-5198-9529-45716c5a87b1",
+            "name": "Ensure That the \u2018Log_min_duration_statement\u2019 Database Flag for Cloud SQL PostgreSQL Instance Is Set to \u2018-1\u2032 (Disabled)",
+            "profile_applicability": "* Level 1",
+            "description": "The `log_min_duration_statement` flag defines the minimum amount of execution time of a statement in milliseconds where the total duration of the statement is logged.\nEnsure that `log_min_duration_statement` is disabled, i.e., a value of `-1` is set.",
+            "rationale": "Logging SQL statements may include sensitive information that should not be recorded in logs.\nThis recommendation is applicable to PostgreSQL database instances.",
+            "audit": "**From Google Cloud Console**\n\n1. Go to the Cloud SQL Instances page in the Google Cloud Console by visiting [https://console.cloud.google.com/sql/instances](https://console.cloud.google.com/sql/instances).\n2. Select the instance to open its `Instance Overview` page.\n3. Go to the `Configuration` card.\n4. Under `Database flags`, check that the value of `log_min_duration_statement` flag is set to `-1`.\n\n**From Google Cloud CLI**\n\n5. Use the below command for every Cloud SQL PostgreSQL database instance to verify the value of `log_min_duration_statement` is set to `-1`.\n```\ngcloud sql instances list --format=json| jq '.settings.databaseFlags[] | select(.name==\"log_min_duration_statement\")|.value'\n```",
+            "remediation": "**From Google Cloud Console**\n\n1. Go to the Cloud SQL Instances page in the Google Cloud Console by visiting [https://console.cloud.google.com/sql/instances](https://console.cloud.google.com/sql/instances).\n2. Select the PostgreSQL instance where the database flag needs to be enabled.\n3. Click `Edit`.\n4. Scroll down to the `Flags` section.\n5. To set a flag that has not been set on the instance before, click `Add item`, choose the flag `log_min_duration_statement` from the drop-down menu and set a value of `-1`.\n6. Click `Save`.\n7. Confirm the changes under `Flags` on the Overview page.\n\n**From Google Cloud CLI**\n\n8. List all Cloud SQL database instances using the following command:\n```\ngcloud sql instances list\n```\n9. Configure the `log_min_duration_statement` flag for every Cloud SQL PosgreSQL database instance using the below command:\n```\ngcloud sql instances patch <INSTANCE_NAME> --database-flags log_min_duration_statement=-1\n```\n```\nNote: This command will overwrite all database flags previously set.\nTo keep those and add new ones, include the values for all flags to be set on the instance; any flag not specifically included is set to its default value.\nFor flags that do not take a value, specify the flag name followed by an equals sign (\"=\").\n```",
+            "section": "PostgreSQL Database",
+            "version": "1.0",
+            "tags": [
+                "CIS",
+                "GCP",
+                "CIS 6.2.7",
+                "PostgreSQL Database"
+            ],
+            "benchmark": {
+                "name": "CIS Google Cloud Platform Foundation",
+                "version": "v2.0.0",
+                "id": "cis_gcp",
+                "rule_number": "6.2.7",
+                "posture_type": "cspm"
+            },
+            "rego_rule_id": "cis_6_2_7"
+        }
+    },
+    "migrationVersion": {
+        "csp-rule-template": "8.7.0"
+    },
+    "coreMigrationVersion": "8.7.0"
+}
@@ -12,7 +12,7 @@
             "description": "S3 object-level API operations such as GetObject, DeleteObject, and PutObject are called data events.\nBy default, CloudTrail trails don't log data events and so it is recommended to enable Object-level logging for S3 buckets.",
             "rationale": "Enabling object-level logging will help you meet data compliance requirements within your organization, perform comprehensive security analysis, monitor specific patterns of user behavior in your AWS account or take immediate actions on any object-level API activity using Amazon CloudWatch Events.",
             "audit": "**From Console:**\n\n1. Login to the AWS Management Console and navigate to S3 dashboard at `https://console.aws.amazon.com/s3/`\n2. In the left navigation panel, click `buckets` and then click on the S3 Bucket Name that you want to examine.\n3. Click `Properties` tab to see in detail bucket configuration.\n4. If the current status for `Object-level` logging is set to `Disabled`, then object-level logging of read events for the selected s3 bucket is not set.\n5. If the current status for `Object-level` logging is set to `Enabled`, but the Read event check-box is unchecked, then object-level logging of read events for the selected s3 bucket is not set.\n6. Repeat steps 2 to 5 to verify `object-level` logging for `read` events of your other S3 buckets.\n\n**From Command Line:**\n7. Run `describe-trails` command to list the names of all Amazon CloudTrail trails currently available in the selected AWS region:\n```\naws cloudtrail describe-trails --region <region-name> --output table --query trailList[*].Name\n```\n8. The command output will be table of the requested trail names.\n9. Run `get-event-selectors` command using the name of the trail returned at the previous step and custom query filters to determine if Data events logging feature is enabled within the selected CloudTrail trail configuration for s3 bucket resources:\n```\naws cloudtrail get-event-selectors --region <region-name> --trail-name <trail-name> --query EventSelectors[*].DataResources[]\n```\n10. The command output should be an array that contains the configuration of the AWS resource(S3 bucket) defined for the Data events selector.\n11. If the `get-event-selectors` command returns an empty array, the Data events are not included into the selected AWS Cloudtrail trail logging configuration, therefore the S3 object-level API operations performed within your AWS account are not recorded.\n12. Repeat steps 1 to 5 for auditing each s3 bucket to identify other trails that are missing the capability to log Data events.\n13. Change the AWS region by updating the `--region` command parameter and perform the audit process for other regions.",
-            "remediation": "**From Console:**\n\n1. Login to the AWS Management Console and navigate to S3 dashboard at `https://console.aws.amazon.com/s3/`\n2. In the left navigation panel, click `buckets` and then click on the S3 Bucket Name that you want to examine.\n3. Click `Properties` tab to see in detail bucket configuration.\n4. Click on the `Object-level` logging setting, enter the CloudTrail name for the recording activity. You can choose an existing Cloudtrail or create a new one by navigating to the Cloudtrail console link `https://console.aws.amazon.com/cloudtrail/`\n5. Once the Cloudtrail is selected, check the Read event checkbox, so that `object-level` logging for `Read` events is enabled.\n6. Repeat steps 2 to 5 to enable `object-level` logging of read events for other S3 buckets.\n\n**From Command Line:**\n7. To enable `object-level` data events logging for S3 buckets within your AWS account, run `put-event-selectors` command using the name of the trail that you want to reconfigure as identifier:\n```\naws cloudtrail put-event-selectors --region <region-name> --trail-name <trail-name> --event-selectors '[{ \"ReadWriteType\": \"ReadOnly\", \"IncludeManagementEvents\":true, \"DataResources\": [{ \"Type\": \"AWS::S3::Object\", \"Values\": [\"arn:aws:s3:::<s3-bucket-name>/\"] }] }]'\n```\n8. The command output will be `object-level` event trail configuration.\n9. If you want to enable it for all buckets at ones then change Values parameter to `[\"arn:aws:s3\"]` in command given above.\n10. Repeat step 1 for each s3 bucket to update `object-level` logging of read events.\n11. Change the AWS region by updating the `--region` command parameter and perform the process for other regions.",
+            "remediation": "**From Console:**\n\n1. Login to the AWS Management Console and navigate to S3 dashboard at `https://console.aws.amazon.com/s3/`\n2. In the left navigation panel, click `buckets` and then click on the S3 Bucket Name that you want to examine.\n3. Click `Properties` tab to see in detail bucket configuration.\n4. Click on the `Object-level` logging setting, enter the CloudTrail name for the recording activity. You can choose an existing Cloudtrail or create a new one by navigating to the Cloudtrail console link `https://console.aws.amazon.com/cloudtrail/`\n5. Once the Cloudtrail is selected, check the Read event checkbox, so that `object-level` logging for `Read` events is enabled.\n6. Repeat steps 2 to 5 to enable `object-level` logging of read events for other S3 buckets.\n\n**From Command Line:**\n7. To enable `object-level` data events logging for S3 buckets within your AWS account, run `put-event-selectors` command using the name of the trail that you want to reconfigure as identifier:\n```\naws cloudtrail put-event-selectors --region <region-name> --trail-name <trail-name> --event-selectors '[{\n    \"ReadWriteType\": \"ReadOnly\",\n    \"IncludeManagementEvents\": true,\n    \"DataResources\": [\n        {\n            \"Type\": \"AWS::S3::Object\",\n            \"Values\": [\n                \"arn:aws:s3:::<s3-bucket-name>/\"\n            ]\n        }\n    ]\n}]'\n```\n8. The command output will be `object-level` event trail configuration.\n9. If you want to enable it for all buckets at ones then change Values parameter to `[\"arn:aws:s3\"]` in command given above.\n10. Repeat step 1 for each s3 bucket to update `object-level` logging of read events.\n11. Change the AWS region by updating the `--region` command parameter and perform the process for other regions.",
             "section": "Logging",
             "version": "1.0",
             "tags": [