diff --git a/skills/cloud/gcp-review/SKILL.md b/skills/cloud/gcp-review/SKILL.md index 8c61f49e..21e5e664 100644 --- a/skills/cloud/gcp-review/SKILL.md +++ b/skills/cloud/gcp-review/SKILL.md @@ -5,15 +5,16 @@ description: > Foundation Benchmark v2.0.0. Auto-invoked when reviewing GCP infrastructure, IAM bindings, VPC firewall rules, Cloud Audit Logs, or GCS bucket security. Walks through all seven benchmark sections, evaluates each recommendation, - and produces a prioritized findings report with remediation guidance mapped - to specific CIS control IDs. + checks VPC Service Controls evidence for data-boundary claims, and produces a + prioritized findings report with remediation guidance mapped to specific CIS + control IDs. tags: [cloud, gcp, cis-benchmark] role: [cloud-security-engineer, security-engineer] phase: [assess, operate] frameworks: [CIS-GCP-v2.0.0] difficulty: intermediate time_estimate: "60-90min" -version: "1.0.0" +version: "1.0.1" author: unitoneai license: MIT allowed-tools: Read, Grep, Glob @@ -27,7 +28,7 @@ argument-hint: "[target-file-or-directory]" This skill performs a structured security assessment of Google Cloud Platform environments against the **CIS Google Cloud Platform Foundation Benchmark v2.0.0**. The benchmark is organized into seven sections covering identity and access management, logging and monitoring, networking, virtual machines, storage, Cloud SQL, and BigQuery. Each recommendation is evaluated by inspecting infrastructure-as-code definitions (Terraform, Deployment Manager), gcloud CLI output, or configuration files available in the repository. -The CIS GCP Foundation Benchmark v2.0.0 provides prescriptive guidance for hardening GCP projects and organizations. This skill evaluates each applicable control and produces a findings report with CIS recommendation IDs, severity ratings, and actionable remediation steps. +The CIS GCP Foundation Benchmark v2.0.0 provides prescriptive guidance for hardening GCP projects and organizations. This skill evaluates each applicable control and produces a findings report with CIS recommendation IDs, severity ratings, and actionable remediation steps. When a review makes data-boundary claims for BigQuery, Cloud Storage, or service-to-service API access, CIS coverage is not the full boundary assessment; collect VPC Service Controls evidence separately and score it as posture evidence rather than as a CIS pass unless a specific benchmark control maps to it. --- @@ -74,6 +75,8 @@ Use Glob to locate all GCP-related infrastructure definitions. **/org-policies/**/*.json **/org-policies/**/*.yaml **/iam/**/*.json +**/access-context-manager/**/*.yaml +**/access-context-manager/**/*.json ``` Record all discovered files. If no GCP configurations are found, report that finding and halt. @@ -88,7 +91,64 @@ For detailed CIS benchmark checklist items with specific Terraform patterns, gre --- -### Step 9: Compile Assessment Report +### Step 9: VPC Service Controls Evidence Review + +Perform this step when the target includes Cloud Storage, BigQuery, sensitive data projects, service-to-service access boundaries, or any claim that VPC Service Controls protect data exfiltration paths. Do not treat the presence of a service perimeter as proof of enforcement. + +**Evidence to locate:** + +``` +google_access_context_manager_service_perimeter +google_access_context_manager_service_perimeters +google_access_context_manager_access_level +accessPolicies/ +servicePerimeters/ +PERIMETER_TYPE_REGULAR +PERIMETER_TYPE_BRIDGE +use_explicit_dry_run_spec +useExplicitDryRunSpec +restricted_services +restrictedServices +ingress_policies +ingressPolicies +egress_policies +egressPolicies +``` + +For each perimeter, record the following fields: + +- Access policy name or ID +- Perimeter name and title +- `perimeter_type` / `perimeterType` +- Enforced `status` resources and restricted services +- Dry-run `spec` resources and restricted services +- Whether `use_explicit_dry_run_spec` / `useExplicitDryRunSpec` is enabled +- Ingress rules, including identities, source projects, access levels, and allowed services +- Egress rules, including identities, destination projects, operations, and allowed services +- Access levels, including identity, device, IP range, and source-project conditions +- Shared VPC host projects and service projects included in or excluded from the perimeter +- Bridge membership and the data domains connected by the bridge +- Restricted/private VIP routing assumptions and any internet egress or Private Service Access paths that remain outside the perimeter + +**Evaluation gates:** + +- Separate enforced `status` from dry-run `spec`. Dry-run findings are advisory until promoted into enforced state. +- For `PERIMETER_TYPE_BRIDGE`, treat access as broad and bidirectional. Require business justification, project inventory, data classification for both sides, compensating IAM controls, and a rationale for why targeted ingress/egress rules are not safer. +- Do not score Terraform module inputs as sufficient evidence when they hide expanded `status`, `spec`, `perimeter_type`, ingress, or egress resources. Mark the VPC-SC portion **Not Evaluable** unless rendered configuration, Terraform plan output with expanded resources, or `gcloud access-context-manager perimeters describe` output is available. +- Check that Shared VPC service projects and host projects are covered consistently. A perimeter that lists only an application project can leave service-project or host-project access paths under-reviewed. +- When access levels are used, require the actual identity, device, IP range, and source-project conditions. Do not reduce access levels to a boolean. +- Call out Google-managed service and resource exceptions when a finding claims the perimeter blocks all service access paths. + +**Severity guidance:** + +- **Critical / High:** Sensitive data projects rely only on dry-run, bridge perimeters connect unrelated data domains, broad egress permits all projects or services, or Shared VPC service projects are outside the intended perimeter. +- **Medium:** Dry-run promotion evidence is missing, bridge justification is incomplete, access-level evidence is partial, or ingress/egress scope is broader than the stated data-flow requirement. +- **Low:** Enforcement appears present, but documentation, project inventory, or reviewer evidence is incomplete. +- **Informational:** VPC Service Controls are not in scope and no data-boundary claims are made. + +--- + +### Step 10: Compile Assessment Report Produce the final report using the structure defined in the Output Format section. @@ -105,6 +165,10 @@ Produce the final report using the structure defined in the Output Format sectio | **Low** | Hardening recommendation or defense-in-depth measure | OS Login not enabled, serial port access not explicitly disabled, BigQuery tables without CMEK | | **Informational** | Best practice observation, no direct security impact | Default network still exists (non-production), naming conventions, documentation gaps | +### VPC Service Controls Severity Addendum + +When VPC Service Controls are in scope, base severity on effective service-perimeter enforcement rather than perimeter existence. Dry-run-only protection for sensitive data is not an enforced control. Bridge perimeters and broad egress rules should be scored by the data domains and services they connect, not by the fact that they are declared in configuration. + --- ## Output Format @@ -150,6 +214,23 @@ Produce the final report using the structure defined in the Output Format sectio - **Evidence:** - **Remediation:** +### VPC Service Controls Evidence + +| Perimeter | Type | Enforced Resources/Services | Dry-run Resources/Services | Ingress/Egress Scope | Shared VPC Coverage | Status | +|-----------|------|-----------------------------|----------------------------|----------------------|---------------------|--------| +| | Regular / Bridge | | | | | Pass / Fail / Not Evaluable | + +#### [VPC-SC] +- **Status:** Pass / Fail / Not Evaluable +- **Severity:** Critical / High / Medium / Low / Informational +- **Perimeter:** +- **File:** +- **Line(s):** +- **Description:** +- **Evidence:** +- **Effective enforcement:** +- **Remediation:** + ### Prioritized Remediation Plan 1. **[Critical]** CIS X.Y -- @@ -194,6 +275,10 @@ Produce the final report using the structure defined in the Output Format sectio 4. **Cloud SQL authorized_networks vs. private IP.** CIS 6.5 flags `0.0.0.0/0` in authorized networks, but CIS 6.6 goes further and recommends disabling public IP entirely in favor of private networking. 5. **BigQuery dataset-level vs. table-level CMEK.** CIS 7.2 checks table-level encryption, while CIS 7.3 checks the dataset default. Both should be evaluated independently. 6. **Default compute service account identification.** The default SA follows the pattern `PROJECT_NUMBER-compute@developer.gserviceaccount.com`. Grep for this pattern, not just the string "default." +7. **Dry-run VPC Service Controls are not enforcement.** `spec` and `useExplicitDryRunSpec` show proposed behavior; `status` shows the active perimeter. Report the delta instead of treating both as equivalent. +8. **Perimeter bridges are intentionally broad.** `PERIMETER_TYPE_BRIDGE` can be valid, but it connects projects bidirectionally and should not be scored like narrow ingress/egress policies. +9. **Module inputs may hide real perimeter state.** If the review has only variables or wrapper-module inputs, mark VPC-SC claims Not Evaluable until rendered resources or `gcloud` exports show effective `status`, `spec`, type, ingress, and egress. +10. **Shared VPC membership can split the boundary.** Review both host and service projects so the assessment does not protect the workload project while leaving network or service-project paths outside the perimeter. --- @@ -218,6 +303,10 @@ Produce the final report using the structure defined in the Output Format sectio - Google Cloud IAM Documentation: https://cloud.google.com/iam/docs - Google Cloud Audit Logs: https://cloud.google.com/logging/docs/audit - Google Cloud VPC Documentation: https://cloud.google.com/vpc/docs +- Google Cloud VPC Service Controls Overview: https://cloud.google.com/vpc-service-controls/docs/overview +- Google Cloud VPC Service Controls Dry Run Mode: https://cloud.google.com/vpc-service-controls/docs/dry-run-mode +- Google Cloud VPC Service Controls Ingress and Egress Rules: https://cloud.google.com/vpc-service-controls/docs/ingress-egress-rules +- Google Cloud VPC Service Controls Perimeter Bridges: https://cloud.google.com/vpc-service-controls/docs/share-across-perimeters - Google Cloud SQL Security: https://cloud.google.com/sql/docs/mysql/configure-ssl-instance - Terraform Google Provider Documentation: https://registry.terraform.io/providers/hashicorp/google/latest/docs @@ -225,4 +314,5 @@ Produce the final report using the structure defined in the Output Format sectio ## Changelog +- **1.0.1** -- Added VPC Service Controls evidence gates for enforced vs. dry-run state, perimeter bridge scope, Shared VPC coverage, ingress/egress/access-level evidence, and Not Evaluable handling when rendered perimeter state is unavailable. - **1.0.0** -- Initial release. Full coverage of CIS Google Cloud Platform Foundation Benchmark v2.0.0 sections 1 through 7.