- Add comprehensive description explaining the print management solution
- Include impact and remediation sections for better security context
- Add verified metadata and max-request count
- Enhance tags with exposure and misconfig for better categorization
- Add ZoomEye search queries for broader coverage
- Improve template name to be more descriptive
* Update misp-panel
- Additional Shodan/FOFA queries
- Match systems with server error
- Match on Github link instead of title
* the more is better with OR condition
---------
Co-authored-by: sandeep <[email protected]>
* Update mitel-micollab-panel
- Add version extract
- Add more Shodan/Foda queries
* re-adjusted request order + stop at first match to avoid double nuclei result
---------
Co-authored-by: sandeep <[email protected]>
* Update CVE-2023-20198.yaml
The original template was giving false negatives.
Added both /%77ebui_wsma_https and /%2577ebui_wsma_https paths to check for the vulnerability, as some Cisco devices may respond to different URL encodings.
Created a more flexible matching system that will detect the vulnerability if:
The response contains "enable secret" or "username" (credentials in config)
The response contains XML structure indicating command execution
The response has HTTP 200 status code
The response has "text/xml" content type
Added an extractor to capture any credentials found in the response.
* Update CVE-2023-20198.yaml
Changes as per https://github.com/projectdiscovery/nuclei-templates/pull/12087#issuecomment-2925142821
* Update CVE-2023-20198.yaml
---------
Co-authored-by: Prince Chaddha <[email protected]>
Co-authored-by: sandeep <[email protected]>
* jenkins-default: detect dashboard from newer jenkins versions
* jenkins-default: use a slightly more exact match
* jenkins-default: remove leftover debug line
* jenkins: adjust name for consistency
* jenkins: remove trailing space
- Extract version from Server header and serverinfo on page
- Additional Shodan queries
- Cover non-English installations using alternative matching words
- Added %3f (URL-encoded question mark) path to both templates for better detection
- Added stop-at-first-match flag to improve performance and reduce noise
This template detects CVE-2024-51211, a vulnerability in ChurchCRM <4.5.5 allowing unauthenticated arbitrary file uploads via the /api/fileupload/upload.php endpoint. Successfully tested.
Fix typo on Allen_Bradley
reminder of the 1st pull request
After discussions on the project dicovery discord, on the request to add the following templates (oriented toward the industrial and Industrial Internet of thing world)
https://github.com/biero-el-corridor/ICS_CPS_nuclei_template/
here's an ordered pul request with the templates in the sections that seem suitable for placing them
NOTE: 2 folders have been created under Network => detection
Network => detections
- Allan_Bradlley
- Allen_Bradley_CompactLogix_enip-cip_detect
- Allen_Bradley_GuardPLC_enip-cip_detect.yaml
- Allen_Bradley_Micro800_enip-cip_detect.yaml
- Allen_Bradley_MicroLogix_enip-cip_detect.yaml
- Allen_Bradley_PLC-5_enip-cip_detect.yaml
- Allen_Bradley_SLC-500_enip-cip_detect.yaml
- Schneider
- modicon_340_detect.yaml
- modicon_580_detect.yaml
- Red_Lion_enip_detect.yaml
---
Network => Honeypot
- Ethernet_IP_CIP_conpot_default_config.yaml
- snap7_honeypot_default_config.yaml
---
Network => enumeration
- modicon-info.yaml
- S7-enumerate.yaml
---
http => default password
- LOYETC_PLC_defaul_password.yaml
- OSASI_default_credential.yaml
- SIEMENS_SIMATIC_HMI_Miniweb_default_password.yaml
- WAGO_default_password_web_panel.yaml
---
http => exposed_panel
- CAE_Monitoring_page.yaml
- ETIC_telecom_router_login_page.yaml
- ETIC_telecom_unprotected_admin_panel.yaml
- Moxa_vpn_router_login_page.yaml
- OSASI_login_page.yaml
- Siemens_LOGO_login_page.yaml
- SIEMENS_SIMATIC_HMI_Miniweb_panel.yaml
- WAGO_web_based_management_panel.yaml
---
In some cases (e.g. if the database is not available) the error message is not 500 but 503, so to match any 5xx status code a DSL matcher replaces the simple status code matcher.
Add new CVE entries for vulnerabilities in Best Practical Request Tracker.
These entries document cross-site scripting and information exposure
vulnerabilities, enhancing security awareness and response. Also,
introduce a version detection template for Request Tracker to aid
in identifying affected versions.
Introduce a new YAML configuration for detecting valid AdmissionReview
requests in Kubernetes Ingress-Nginx. This change provides a minimal
AdmissionReview JSON payload to test webhook endpoints, enhancing
the ability to validate Ingress resources effectively. The new
configuration includes matchers to ensure the presence of key
terms in the response body, improving monitoring and debugging
capabilities for Ingress-Nginx setups.
Nuclei-Templates is an open-source project featuring security checks written in YAML format, used by the Nuclei scanner.
You are a reviewer for the GitHub repository: https://github.com/projectdiscovery/nuclei-templates. You will review a Pull Request (PR) diff, which may include new or updated templates, provided at the end of this prompt.
Your objective is to thoroughly analyze the PR diff step-by-step and suggest improvements based solely on the context below. Begin your response by thanking the contributor and including: “You can join our [Discord server](https://discord.com/invite/projectdiscovery). It's a great place to connect with fellow contributors and stay updated with the latest developments. Thank you once again.”
### Nuclei Templates Contribution Guide
When submitting a new template, include these details with a proof of concept (P.O.C):
1. `id`: A concise identifier (3-4 words, e.g., `grafana-unauth-rce`). For CVE templates, use the format `CVE-XXX-XXX`.
2. Filename: Must match the template `id`.
3. `name`: For vulnerability/CVE templates, use the format: `<Vendor> <Product> <Version> - Vulnerability`.
4. `author`: Your GitHub/Twitter username or alias. Optionally, update [contributors.json](https://github.com/projectdiscovery/nuclei-templates/blob/master/contributors.json) with author details.
5. `severity`: Based on CVSS score, adjusted for exploit impact and real-world implications.
6. `description`: A brief summary of the vulnerability.
7. `reference`: Include links to the POC, setup guide, or product details for verification.
Best Practices:
- Specify matcher location (e.g., `part: body` for response body).
- Use `{{cmd}}` or `{{payloads}}` for RCE/injection templates, `{{username}}`/`{{password}}` for authenticated templates, and `{{token}}` for key/token templates.
- For web shell uploads (last resort), use a random filename (`{{randstr}}`) and add the `intrusive` tag.
- Add appropriate tags: `dos` for DoS templates, `auth` for authenticated templates, `cve` and `cve<year>` for CVE templates, `intrusive` for templates modifying configurations or files.
- For XSS templates, include a unique endpoint string with the payload to avoid false positives (e.g., [CVE-2022-24899](https://github.com/projectdiscovery/nuclei-templates/blob/main/http/cves/2022/CVE-2022-24899.yaml)).
- For SSRF templates, include response-based matchers to reduce false positives from honeypots (see: https://github.com/projectdiscovery/nuclei-templates/issues/7401).
- For time-based SQL injection templates, include a unique endpoint string with duration DSL to avoid false positives from network issues.
Do’s:
- Mark verified templates as `verified: true` and share debug data (redact sensitive server info).
- Include multiple matchers to minimize false positives.
- Provide a vulnerable environment (e.g., via [Vulhub](https://github.com/vulhub/vulhub)) when possible.
- Include an active P.O.C in the template.
Don’t:
- Avoid weak matchers (e.g., strings from GET/POST data) to prevent false positives.
- Do not make unnecessary changes to existing templates.
- Avoid version-based CVE/exploit detection unless a full/partial POC is included. Exceptions (e.g., trending CVEs) require justification.
### Templates Review Guide
#### Functional Validation
- Verify the reference to ensure the POC aligns with the template’s purpose (e.g., an RCE template must demonstrate RCE, not just version detection).
- For XSS templates, confirm a unique endpoint string is included to avoid false positives.
- Ensure sufficient, unique matchers to validate the issue without being overly strict.
- For web templates, include at least two matchers (e.g., response header, status code).
- For SSRF templates, add response-based matchers to counter honeypot triggers.
- For time-based SQL injection templates, include a unique endpoint string with duration DSL.
#### Non-Functional Validation
After functional validation, check:
- Template is in the correct folder, and filename matches `id`.
- `id` is unique, descriptive, and uses 2-3 keywords (e.g., `alumni-management-sqli.yaml`). For CVE templates, the ID should be the CVE itself for example, CVE-2020-0796
- Maintain consistent template structure and remove unnecessary headers/parameters.
- Avoid using GET/POST data as matchers.
- Fix indentation and trailing spaces using `yamllint` or the `validate` argument.
- Assign a teammate for review before merging.
#### Best Practices
- For tech detection templates, consider adding templates for the tech’s panel or default credentials.
- Ensure tag names start with the folder/vulnerability name.
- Create a dedicated folder for technologies with multiple templates.
- Add a `good first issue` label for first-time contributors’ PRs.
- Use the `epic` label for creative templates.
- Do not share vulnerable URLs publicly on GitHub or Discord.
#### Below are examples of existing YAML templates for each protocol, along with their paths. You can use them as references when reviewing templates for the corresponding protocols.
name: ECOA Building Automation System - Directory Traversal Content Disclosure
author: gy741
severity: high
description: The ECOA BAS controller suffers from a directory traversal content disclosure vulnerability. Using the GET parameter cpath in File Manager (fmangersub), attackers can disclose directory content on the affected device
impact: |
An attacker can exploit this vulnerability to access sensitive files and directories, potentially exposing sensitive information.
remediation: |
Apply the latest security patches or updates provided by the vendor to fix the directory traversal vulnerability in the ECOA Building Automation System.
Ensure that Storage Auto-Growth feature is enabled for your production Azure PostgreSQL database servers. Storage auto-growth prevents your PostgreSQL servers from running out of storage and becoming read-only.
impact: |
Failing to enable Storage Auto-Growth can lead to PostgreSQL servers running out of space, becoming read-only, and disrupting database services.
remediation: |
Enable the Storage Auto-Growth feature on your Azure PostgreSQL servers to prevent potential disruptions and ensure continuous database operation.
for (let ServerData of iterate(template.serverList)) {
ServerData = JSON.parse(ServerData);
set("name", ServerData.Name);
set("resourceGroup", ServerData.ResourceGroup);
code(2);
}
self-contained: true
code:
- engine:
- sh
- bash
source: |
az postgres server list --output json --query '[*].{"Name":name,"ResourceGroup":resourceGroup}'
extractors:
- type: json
name: serverList
internal: true
json:
- '.[]'
- engine:
- sh
- bash
source: |
az postgres server show --name "$name" --resource-group "$resourceGroup" --output json --query 'storageProfile.storageAutogrow'
matchers-condition: and
matchers:
- type: word
words:
- '"Disabled"'
extractors:
- type: dsl
dsl:
- 'name + " in " + resourceGroup + " has Storage Auto-Growth disabled"'
```
=== ssl/c2/gozi-malware-c2.yaml ===
```
id: gozi-malware-c2
info:
name: Gozi Malware C2 - Detect
author: pussycat0x
severity: info
description: |
Gozi is a banking Trojan that has been modified to include new obfuscation techniques, to evade detection. Previous breaches involving Gozi in the healthcare sector led to the compromise of data associated with 3.7 million patients costing $5.55 million.
name:Use AWS-managed policy to manage AWS resources
author:princechaddha
severity:high
description:|
Ensure that all Amazon EKS clusters use the "AmazonEKSClusterPolicy" managed policy to efficiently manage the resources that you use with the EKS service. This policy grants Kubernetes the necessary permissions to handle resources on your behalf.
impact:|
Without the AmazonEKSClusterPolicy, Kubernetes may not have the required permissions to perform essential operations like EC2:CreateTags, which are needed for proper resource management and identification.
remediation:|
Attach the AmazonEKSClusterPolicy to the IAM role associated with your EKS cluster using either the AWS Console or AWS CLI.
Ensure that your Amazon Elastic Kubernetes Service (EKS) clusters have control plane logs enabled to publish API, audit, controller manager, scheduler and authenticator logs to AWS CloudWatch Logs.
impact:|
Without control plane logging enabled, you lose visibility into API requests, authentication attempts, and cluster operations, making it difficult to monitor, troubleshoot, and audit cluster activities.
remediation:|
Enable control plane logging for your EKS cluster by configuring all log types (api, audit, authenticator, controllerManager, scheduler) in the cluster configuration.
Ensure that your Amazon EKS cluster's Kubernetes API server endpoint is not publicly accessible from the Internet in order to avoid exposing private data and minimizing security risks.
impact:|
Publicly accessible EKS cluster endpoints expose your Kubernetes API server to potential unauthorized access and attacks, increasing the risk of data breaches and security compromises.
remediation:|
Configure the EKS cluster endpoint access to be private or restrict public access to specific IP addresses. Use VPC endpoints and security groups to control access to the Kubernetes API server.
name:Use AWS-managed policy to Manage Networking Resources
author:princechaddha
severity:high
description:|
Ensure that all Amazon EKS cluster node groups use the "AmazonEKS_CNI_Policy" managed policy to manage cloud networking resources effectively. This policy provides the necessary permissions to the Amazon VPC CNI Plugin for managing network interfaces.
impact:|
Without the AmazonEKS_CNI_Policy, the VPC CNI plugin cannot properly manage network interfaces, which will affect pod networking and communication within the EKS cluster.
remediation:|
Attach the AmazonEKS_CNI_Policy to the IAM role associated with your EKS node groups using either the AWS Console or AWS CLI.
Ensure that your Amazon Elastic Kubernetes Service (EKS) clusters have encryption enabled for Kubernetes secrets using AWS KMS Customer Master Keys (CMKs). This is a security best practice for protecting sensitive data stored in Kubernetes secrets.
impact:|
Without encryption enabled, Kubernetes secrets are stored in plaintext, making them vulnerable to unauthorized access and potentially violating compliance requirements for data-at-rest encryption.
remediation:|
Enable encryption for your EKS cluster by creating a KMS CMK and configuring it for the cluster. Note that this requires recreating the cluster with the encryption configuration.
name:Enable CloudTrail Logging for Kubernetes API Calls
author:princechaddha
severity:high
description:|
Ensure that CloudTrail logging is enabled for Amazon Elastic Kubernetes Service (EKS) clusters in order to record all Kubernetes API calls. Amazon CloudTrail records and documents all activities performed on EKS clusters.
impact:|
Without CloudTrail logging enabled, there is no audit trail of API calls made to EKS clusters, making it difficult to track unauthorized access, investigate security incidents, and maintain compliance.
remediation:|
Enable CloudTrail logging for your EKS clusters by either starting logging on existing trails or creating a new multi-region trail if none exists.
Ensure that Amazon Elastic Kubernetes Service (EKS) clusters do not have pods running for more than 30 days. Long-running pods may indicate stale deployments, potential security risks, or resource inefficiencies.
impact:|
Long-running pods can lead to security vulnerabilities, outdated software versions, and inefficient resource utilization. They may also indicate a lack of proper deployment practices and maintenance.
remediation:|
Review and update long-running pods. Consider implementing proper deployment strategies, regular updates, and automated pod rotation policies.
name:Use AWS-managed policy to access Amazon ECR Repositories
author:princechaddha
severity:high
description:|
Ensure that all EKS cluster node groups use the "AmazonEC2ContainerRegistryReadOnly" managed policy to access Amazon ECR repositories. This policy provides read-only access to Amazon EC2 Container Registry (ECR) repositories.
impact:|
Without the AmazonEC2ContainerRegistryReadOnly policy, EKS node groups cannot pull container images from ECR repositories, which will prevent pods from starting and running properly.
remediation:|
Attach the AmazonEC2ContainerRegistryReadOnly policy to the IAM role associated with your EKS node groups using either the AWS Console or AWS CLI.
Ensure that Amazon EKS node groups are configured with appropriate remote access settings to maintain security and enable necessary administrative access.
impact:|
Improper remote access configuration in EKS node groups can lead to security vulnerabilities or hinder necessary administrative access, potentially affecting cluster management and troubleshooting capabilities.
remediation:|
Configure remote access settings for EKS node groups by specifying appropriate SSH key pairs and source security groups to enable secure administrative access while maintaining security best practices.
Ensure that the usage of your Google Cloud API keys is restricted to specific APIs such as Cloud Key Management Service (KMS) API, Cloud Storage API, Cloud Monitoring API, and Cloud Logging API. All Google Cloud API keys that are being used for production applications should use API restrictions.
impact:|
API keys without specific API restrictions can be used to access any GCP API, potentially leading to unauthorized access and misuse of resources. Implementing API restrictions helps in limiting the scope of API keys to intended services only.
remediation:|
Apply API restrictions to each Google Cloud API key to limit their usage to specific APIs. This can be managed through the Google Cloud Console or using the gcloud command-line tool.
Ensure that the use of Google Cloud API keys is limited to trusted and reliable hosts, HTTP referrers, or applications. An API key application restriction manages the authorization of websites, IP addresses, or Android/iOS mobile applications that can employ your API key. It is crucial that all API keys used in production employ host and application restrictions. By enforcing these restrictions, you can reduce the impact that a compromised API key can have on your applications.
impact:|
API keys without restrictions can be used unrestrictedly, which might lead to unauthorized access and misuse, potentially exposing sensitive data or services.
remediation:|
Apply restrictions to all production API keys to specify the allowed websites, IP addresses, or mobile applications that can use each key, to mitigate potential abuse.
name:API Keys Should Only Exist for Active Services
author:princechaddha
severity:low
description:|
Ensure that your Google Cloud projects are using the standard authentication flow as the preferred method for authentication, rather than relying on API keys. API keys are simple encrypted strings that can be used when calling certain APIs which don't need to access private user data. API keys should be exclusively employed for active services when alternative authentication methods are not accessible, otherwise deleted.
impact:|
Using API keys for inactive services can expose your applications to unnecessary security risks. It is advisable to employ standard authentication methods and ensure that API keys are used judiciously and only for active services.
remediation:|
Review and ensure that API keys are only configured for active services. Delete or disable API keys associated with inactive or unnecessary services to minimize security risks.
Ensure that critical service APIs are enabled for your GCP projects to gain access to essential functionalities and services provided by Google Cloud Platform (GCP), manage your project resources efficiently, enhance the security of your cloud environment, and track your usage and billing. The critical service APIs include, but are not limited to, Identity and Access Management (IAM) API, Compute Engine API, Cloud Storage, Google Cloud Pub/Sub API, Cloud Key Management Service (KMS) API, and Cloud Logging API.
impact:|
Disabling critical service APIs can prevent the proper management and security of GCP resources, potentially leading to service disruptions or compromised security.
remediation:|
Enable the necessary service APIs via the GCP Console or the gcloud command-line tool for each project where they are found to be disabled.
To access historical security findings and asset data in Security Command Center, ensure that the Security Command Center API is enabled within your Google Cloud account. If the API is not enabled, certain security features and monitoring capabilities will be unavailable.
impact:|
Disabling the Security Command Center API may limit visibility and control over security threats, leading to potential vulnerabilities and undetected risks within Google Cloud environments.
remediation:|
Enable the Security Command Center API for each Google Cloud project to maintain proper security monitoring and threat detection capabilities. This can be done through the Google Cloud Console or using the `gcloud services enable securitycenter.googleapis.com` command.
Ensure that Cloud Asset Inventory is enabled for all your GCP projects in order to efficiently manage the history and the inventory of your cloud resources. Google Cloud Asset Inventory is a fully managed metadata inventory service that allows you to view, monitor, analyze, and gain insights for your Google Cloud and Anthos assets. Cloud Asset Inventory is disabled by default in each GCP project.
impact:|
Not having Cloud Asset Inventory enabled can prevent the organization from having a managed and insightful view over its cloud resources, potentially leading to mismanagement and security risks.
remediation:|
Enable the Google Cloud Asset Inventory by activating the Cloud Asset API in each GCP project through the Google Cloud Console or using the `gcloud services enable cloudasset.googleapis.com --project <project-id>` command.
Identify any publicly accessible Artifact Registry repositories within your Google Cloud account and update their IAM policy in order to protect against unauthorized access. To deny access from anonymous and public users, remove the bindings for "allUsers" and "allAuthenticatedUsers" members from the IAM policy associated with your repository.
impact:|
Public accessibility of Artifact Registry repositories can lead to unauthorized data access or data leaks. Restricting access ensures that only authorized entities can view or manipulate the repositories.
remediation:|
Update the IAM policies for each Artifact Registry repository to remove "allUsers" and "allAuthenticatedUsers". This action will ensure that repositories are not exposed to any user on the internet or authenticated users not explicitly granted permission.
name:Artifact Registry Vulnerability Scanning Not Enabled
author:princechaddha
severity:high
description:|
Ensure that vulnerability scanning for Google Cloud Artifact Registry repositories is enabled in order to find security weaknesses in your container images before deploying them and help prevent security breaches.
impact:|
Disabling vulnerability scanning on Artifact Registry repositories can expose your deployment to undiscovered security vulnerabilities, increasing the risk of security breaches.
remediation:|
Enable the Container Scanning API for each Artifact Registry by visiting the API & services page in the Google Cloud Console and enabling `containerscanning.googleapis.com`.
name:BigQuery Dataset Encryption with Customer-Managed Encryption Keys Not Enabled
author:princechaddha
severity:high
description:|
Ensure that all your Google Cloud BigQuery datasets are encrypted using Customer-Managed Encryption Keys (CMEKs) in order to have a more granular control over the dataset encryption/decryption process. Datasets not encrypted with CMEKs may expose sensitive data to higher risks.
impact:|
Using Google-managed keys for dataset encryption limits control over the encryption process and may not meet compliance requirements that specify encryption key management policies.
remediation:|
Update the encryption configuration of your BigQuery datasets to use Customer-Managed Encryption Keys. This can be done by setting the 'defaultEncryptionConfiguration' property of each dataset to use a 'kmsKeyName' that you manage.
name:BigQuery Datasets Not Encrypted with Customer-Managed Keys
author:princechaddha
severity:high
description:|
Ensure that the tables created for your Google Cloud BigQuery datasets are encrypted with Customer-Managed Keys (CMKs) to have more granular control over the data encryption/decryption process. Using CMKs allows you to create, rotate, manage, and destroy your own encryption keys using Google Cloud Key Management Service (Cloud KMS).
impact:|
If BigQuery dataset tables are not encrypted using CMKs, it limits the control over data encryption and decryption, increasing the risk of unauthorized data access.
remediation:|
Configure BigQuery dataset tables to use Customer-Managed Keys (CMKs) for encryption. This can be done in the dataset settings where you specify the encryption key managed in Google Cloud KMS.
Ensure there are no anonymously and/or publicly accessible BigQuery datasets available within your Google Cloud Platform (GCP) account. Google Cloud BigQuery datasets have Identity and Access Management (IAM) policies configured to determine who can have access to these resources. To refuse access from anonymous and public users, remove the bindings for "allUsers" and "allAuthenticatedUsers" members from the IAM policy associated with your datasets.
impact:|
Publicly accessible BigQuery datasets can lead to unauthorized data access or data leaks. Ensuring that access is restricted helps maintain the integrity and confidentiality of your data.
remediation:|
Update the IAM policies for each BigQuery dataset to remove "allUsers" and "allAuthenticatedUsers". This action will ensure that datasets are not exposed to any user on the internet or authenticated users not explicitly granted permission.
Ensure that your Cloud CDN backend buckets are referencing existing storage buckets in order to be able to deliver static content efficiently from the nearest edge location to users, reducing latency and improving performance.
impact:|
Referencing missing storage buckets can lead to a failure in content delivery, increased latency, and a poor user experience.
remediation:|
Verify that each backend bucket is referencing an existing storage bucket. Update the Cloud CDN backend bucket configuration to point to valid and existing storage buckets.
Ensure that the Cloud CDN origin associated with your Google Cloud load balancer points to a backend bucket instead of a backend service in order to provide enhanced performance, cost savings, simplified management, and the ability to customize caching rules.
impact:|
Using a backend service as the Cloud CDN origin instead of a backend bucket may lead to increased costs, complex management, and suboptimal caching configurations, impacting performance and operational efficiency.
remediation:|
Reconfigure the Cloud CDN origin to point to a backend bucket instead of a backend service by modifying the associated Google Cloud load balancer's URL map.
Ensure that Cloud CDN origins are configured to authenticate access to the content available at backend (backend buckets or backend services) using signed cookies and signed URLs. Signed cookies and URLs are designed to prevent unauthorized users from bypassing the authentication process and accessing sensitive information.
impact:|
If Cloud CDN origins are not properly configured with signed cookies and signed URLs, it could lead to unauthorized access and potential exposure of sensitive information. This configuration is essential for maintaining the security and integrity of content delivery.
remediation:|
Configure your Cloud CDN origins to use signed cookies and URLs by adding signed request keys to your backend services. This will enforce authentication on CDN-cached content, preventing unauthorized access.
Ensure that Google Cloud CDN backend bucket origins enforce HTTPS using SSL/TLS certificates in order to handle encrypted traffic. This helps to protect the integrity and confidentiality of the transmitted information.
impact:|
Not enforcing HTTPS can expose data to interception or alteration during transmission, compromising data confidentiality and integrity.
remediation:|
Configure SSL/TLS certificates for Cloud CDN backend bucket origins and ensure all traffic is served over HTTPS by adjusting the forwarding rules and url-maps.
name:Unenforced SSL/TLS on Cloud CDN Backend Service Origins
author:princechaddha
severity:medium
description:|
Ensure that Google Cloud CDN backend service origins are using SSL/TLS certificates to enforce HTTPS in order to manage encrypted traffic. This helps to protect the integrity and confidentiality of the transmitted information.
impact:|
If SSL/TLS certificates are not enforced, the integrity and confidentiality of the transmitted information through Cloud CDN can be compromised, leading to potential data leaks and security breaches.
remediation:|
Configure SSL/TLS certificates for your Cloud CDN backend service origins to enforce HTTPS and ensure that all communications are securely encrypted.
Ensure that SSL certificates managed with Google Cloud Certificate Manager don't have a validity period greater than 398 days (13 months). This is to enhance security by reducing the risk of certificate compromise and misuse, while aligning with industry standards and support from modern web browsers.
impact:|
An SSL certificate with a validity period exceeding 398 days poses a higher risk of compromise and misuse. It also fails to comply with industry standards, potentially leading to incompatibilities or security warnings in web browsers.
remediation:|
Review and adjust the renewal configurations for SSL certificates to ensure their validity periods do not exceed 398 days.
Ensure that your virtual machine disk images are not publicly shared with all other Google Cloud Platform (GCP) accounts in order to avoid exposing sensitive or confidential data. If required, you can share your disk images with specific GCP accounts only, without making them public.
impact:|
Publicly shared disk images can expose sensitive application data and configurations to anyone with a Google Cloud account, potentially leading to security breaches.
remediation:|
Remove the "allAuthenticatedUsers" member from the IAM policy of affected disk images using the 'gcloud compute images remove-iam-policy-binding' command or through the Google Cloud Console.
Ensure that your Google Cloud Managed Instance Groups (MIGs) are configured with Autohealing feature. Autohealing allows re-creating virtual machine instances when they become unresponsive. Application-based autohealing improves application availability by relying on a health checking signal that detects application-specific issues such as freezing, crashing, or overloading.
impact:|
Without autohealing enabled, your application's availability may be compromised as unhealthy instances will not be automatically detected and replaced, potentially leading to service disruptions.
remediation:|
Enable autohealing for your Managed Instance Groups by configuring a health check that monitors instance health. Configure appropriate check intervals, timeouts, and healthy/unhealthy thresholds based on your application requirements.
name:Managed Instance Group Not Using Load Balancer
author:princechaddha
severity:low
description:|
Ensure that each Managed Instance Group is using a load balancer to act as an instance group frontend. Google Cloud Managed Instance Groups (MIGs) are groups of virtual machine (VM) instances that you control as a single entity. MIGs support rich features such as autoscaling and autohealing, load balancing, multiple zone coverage, and stateful workloads.
impact:|
Without a load balancer, traffic is not evenly distributed among instances, potentially leading to poor performance, reduced availability, and inefficient resource utilization.
remediation:|
Configure a load balancer for your Managed Instance Group by creating a backend service and associating it with your MIG. This ensures even traffic distribution and improved availability.
name:Managed Instance Group Not Configured for Multiple Zones
author:princechaddha
severity:low
description:|
Ensure that Managed Instance Groups (MIGs) are spread across multiple zones within a Google Cloud region for high availability and fault tolerance. Spreading application load across multiple Google Cloud zones with MIGs is crucial for enhancing the availability, resilience, and performance of your application. When you allocate your MIG instances across multiple zones, you can guarantee the continuous availability and functionality of your application even during failures or outages.
impact:|
Single-zone MIGs are vulnerable to zone-level failures, which could cause complete application downtime. This reduces availability and resilience of your applications.
remediation:|
Re-create your Managed Instance Groups with multiple zones configuration. Select "Multiple zones" for location, choose a region and desired zones, and set "Target distribution shape" to "Even" for balanced instance distribution.
Ensure that the OS Login feature is enabled at the Google Cloud Platform (GCP) project level in order to provide you with centralized and automated SSH key pair management. OS Login ensures that SSH keys are mapped with Google Cloud IAM users, facilitating centralized management of SSH access.
impact:|
Without OS Login enabled, managing SSH access becomes decentralized and complex, making it difficult to handle compromised SSH keys or revoke access for specific users across multiple instances.
remediation:|
Enable OS Login at the project level by setting the "enable-oslogin" metadata key to "TRUE". Note that enabling OS Login disables metadata-based SSH key configurations on all instances within the project.
name:Persistent Disks Attached to Suspended Virtual Machines
author:princechaddha
severity:high
description:|
Ensure that persistent disks are not attached to suspended virtual machine (VM) instances in your Google Cloud environment. Persistent disks attached to suspended VMs continue to incur charges even when the VM is not running, leading to unnecessary costs.
impact:|
Keeping persistent disks attached to suspended VMs results in ongoing storage charges without active utilization, increasing cloud infrastructure costs unnecessarily.
remediation:|
Identify and detach persistent disks from suspended VMs, or delete the disks if they are no longer needed to optimize cloud resource costs.
Ensure that Google Cloud Compute Engine service restarts automatically your virtual machine instances when they are terminated due to non-user initiated reasons such as maintenance events, hardware, and software failures. The Automatic Restart feature configures the virtual machine restart behavior when an instance crashes or it is terminated by the system.
impact:|
Without automatic restart enabled, VM instances that crash or are terminated due to system events will not automatically recover, potentially leading to extended service disruptions.
remediation:|
Enable automatic restart for your VM instances. Note that this behavior does not affect any terminations initiated by the user, such as when the instance is taken offline through a user action like calling sudo shutdown.
name:VM Instance Confidential Computing Not Enabled
author:princechaddha
severity:medium
description:|
Ensure that the Confidential Computing security feature is enabled for your Google Cloud virtual machine (VM) instances in order to add protection to your sensitive data in use by keeping it encrypted in memory and using encryption keys that Google doesn't have access to. Confidential Computing is a breakthrough technology which encrypts data while it is being processed. This technology keeps data encrypted in memory, outside the CPU.
impact:|
Without Confidential Computing enabled, sensitive data in memory is not encrypted during processing, potentially exposing it to unauthorized access from the infrastructure provider or malicious insiders.
remediation:|
Re-create your VM instances with Confidential Computing enabled. Note that enabling this feature requires compatible machine types (N2D series) and may change certain instance parameters if they were set to incompatible values.
name:VM Instance Using Default Service Account with Full API Access
author:princechaddha
severity:medium
description:|
Ensure that your Google Compute Engine instances are not configured to use the default service account with the Cloud API access scope set to "Allow full access to all Cloud APIs". The principle of least privilege (POLP), also known as the principle of least authority, is the security concept of giving the user/system/service the minimal set of permissions required to successfully perform its tasks.
impact:|
Using default service accounts with full API access violates the principle of least privilege and could allow compromised instances to make unauthorized API calls to any GCP service.
remediation:|
Either replace the default service account with a custom one having minimal permissions, or change the access scope to "Allow default access" or "Set access for each API" with only required permissions.
- '"VM instance " + instanceName + " in zone " + zone + " of project " + projectId + " is using the default Compute Engine service account with full API access"'
Ensure that your Google Compute Engine instances are not configured to use the default Google Cloud service account in order to implement the principle of least privilege (POLP) and secure the access to your cloud resources. The default Compute Engine service account, named <project-number>[email protected], is associated with the Editor role at the project level, which allows read and write access to most Google Cloud Platform (GCP) services.
impact:|
Using default service accounts with Editor role permissions violates the principle of least privilege and could allow compromised instances to access most GCP services in the project.
remediation:|
Create a new service account with minimal required permissions and update VM instances to use it instead of the default Compute Engine service account. Note that this requires stopping and restarting the instances.
Ensure that your production Google Compute Engine instances have Deletion Protection feature enabled in order to protect them from being accidentally deleted. With Deletion Protection safety feature enabled, you have the guarantee that your VM instances cannot be accidentally deleted and make sure that your production environment remains safe.
impact:|
Without deletion protection enabled, production and mission-critical VM instances are at risk of accidental deletion, which could lead to service disruptions and data loss.
remediation:|
Enable deletion protection for your production VM instances. You can enable this feature for an existing instance regardless of its current status - stopping the instance is not required.
name:Auto-Delete Not Disabled for VM Instance Persistent Disks
author:princechaddha
severity:medium
description:|
Ensure that the Auto-Delete behavior rule is disabled for the persistent disks attached to your Google Cloud virtual machine (VM) instances in order to protect the VM data from being deleted and meet security and compliance requirements. When Auto-Delete is on, the persistent disks are deleted when the associated VM instance is deleted.
impact:|
With Auto-Delete enabled, persistent disks are automatically deleted when their associated VM instances are deleted, potentially causing unintended data loss for mission-critical systems.
remediation:|
Disable Auto-Delete for your VM instance persistent disks using the 'gcloud compute instances set-disk-auto-delete' command or through the Google Cloud Console. This ensures disks are retained after instance deletion.
name:Virtual Machine Disk Encryption with Customer-Managed Keys Not Enabled
author:princechaddha
severity:high
description:|
Ensure that the persistent disks attached to your Google Compute Engine instances are encrypted with Customer-Managed Keys (CMKs) in order to have a fine control over your sensitive data encryption and decryption process. You can create and manage your own Customer-Managed Keys (CMKs) with Cloud Key Management Service (Cloud KMS). Cloud KMS provides secure and efficient encryption key management, controlled key rotation, and revocation mechanisms.
impact:|
Without CMK encryption, you have limited control over the encryption keys used to protect your VM disk data, potentially exposing sensitive information to unauthorized access.
remediation:|
Configure your Compute Engine persistent disks to use Customer-Managed Keys (CMKs) for encryption by specifying a Cloud KMS key during disk creation or by updating existing disks.
- '"Disk " + diskName + " attached to instance " + instanceName + " in zone " + zone + " of project " + projectId + " is not encrypted with a Customer-Managed Key (CMK)"'
name:VM Disk Encryption with Customer-Supplied Keys Disabled
author:princechaddha
severity:high
description:|
Ensure that the disks attached to your production Google Compute Engine instances are encrypted with Customer-Supplied Encryption Keys (CSEKs) in order to have complete control over the data-at-rest encryption and decryption process, and meet strict compliance requirements.
impact:|
Without CSEK encryption, you have limited control over the encryption process of your VM disk data, which may not meet strict compliance requirements for sensitive data protection.
remediation:|
Enable Customer-Supplied Encryption Keys (CSEKs) for your VM disks by providing a valid encryption key during disk creation or instance launch. The key must be a 256-bit string encoded in RFC 4648 base64 format.
name:Virtual Machine Disk Encryption with Customer-Supplied Keys Not Enabled
author:princechaddha
severity:high
description:|
Ensure that the disks attached to your production Google Compute Engine instances are encrypted with Customer-Supplied Encryption Keys (CSEKs) in order to have complete control over the data-at-rest encryption and decryption process. CSEKs allow you to provide your own encryption keys that Google Compute Engine uses to protect the Google-generated keys used to encrypt and decrypt your instance data.
impact:|
Without CSEK encryption, you have limited control over the encryption process of your VM disk data. Google Compute Engine service manages the encryption keys, which may not meet strict compliance requirements for sensitive data.
remediation:|
Re-create your VM instances with Customer-Supplied Encryption Keys (CSEKs) by providing a 256-bit string encoded in RFC 4648 standard base64 during instance creation. Note that Compute Engine does not store your CSEKs on its servers and cannot access your protected data unless you provide the required key.
- '"Disk " + diskName + " attached to instance " + instanceName + " in zone " + zone + " of project " + projectId + " is not encrypted with a Customer-Supplied Encryption Key (CSEK)"'
Ensure that IP Forwarding feature is not enabled at the Google Compute Engine instance level for security and compliance reasons, as instances with IP Forwarding enabled act as routers/packet forwarders. Because IP forwarding is rarely required, except when the virtual machine (VM) is used as a network virtual appliance, each Google Cloud VM instance should be reviewed to decide whether IP forwarding is really needed.
impact:|
With IP forwarding enabled, VM instances can act as routers and receive traffic addressed to other destinations, potentially creating security risks if not properly configured and monitored.
remediation:|
Re-create your VM instances with IP forwarding disabled. Note that you cannot disable IP forwarding on an existing instance - you must create a new instance without the IP forwarding option.
name:VM Instance Maintenance Policy Set to Terminate
author:princechaddha
severity:high
description:|
Ensure that Google Cloud Compute Engine performs live migration of your virtual machine instances during periodic infrastructure maintenance. The virtual machine maintenance behavior determines whether the VM instances are live migrated or terminated during a maintenance event. To ensure that your Google Cloud VM instances are migrated to new hardware, set "On Host Maintenance" configuration setting to "Migrate".
impact:|
When maintenance policy is set to terminate, VM instances will be shut down during maintenance events, leading to service disruptions and potential data loss.
remediation:|
Configure the maintenance behavior to "MIGRATE" using the gcloud compute instances set-scheduling command or through the Google Cloud Console. This ensures instances are live migrated during maintenance events.
- '"VM instance " + instanceName + " in zone " + zone + " of project " + projectId + " is configured to terminate instead of migrate during maintenance events"'
name:OS Login with 2FA Authentication Not Enabled for VM Instances
author:princechaddha
severity:high
description:|
Ensure that the OS Login feature enabled at the virtual machine instance level is configured with Two-Factor Authentication (2FA) in order to help protect the access to your Google Cloud VM instances. Two-Factor Authentication (also known as Multi-Factor Authentication - MFA) provides an additional layer of security on top of the existing credentials.
impact:|
Without 2FA enabled for OS Login, VM instances are more vulnerable to unauthorized access through compromised credentials.
remediation:|
Enable OS Login with 2FA authentication for all VM instances by setting the "enable-oslogin-2fa" metadata key to "TRUE".
Ensure that your Google Cloud Platform (GCP) projects are not using preemptible virtual machine instances for production and business-critical applications. A preemptible virtual machine (VM) is an instance that you can create and run at a much lower price than normal instances but it can be terminated sooner due to system demands.
impact:|
Preemptible VM instances can be terminated at any time to free up resources for standard VM instances, making them unsuitable for production workloads and potentially causing service disruptions.
remediation:|
Re-create your VM instances with preemptibility disabled. Note that you cannot disable preemptibility on an existing instance - you must create a new instance without the preemptible option.
- '"VM instance " + instanceName + " in zone " + zone + " of project " + projectId + " is configured as preemptible and may not be suitable for production workloads"'
Ensure that your Google Compute Engine instances are configured to ignore GCP project-wide (shared) public SSH keys and use instance-level SSH keys instead. Project-wide SSH keys can be used to log in to all the VM instances running inside a GCP project. While project-wide SSH keys can ease SSH key management, if compromised, they pose a security risk which can impact all VM instances within the project.
impact:|
Using project-wide SSH keys increases the attack surface - if compromised, an attacker could gain access to all VM instances in the project instead of just a single instance.
remediation:|
Enable "Block Project-Wide SSH Keys" feature for your VM instances and configure instance-specific SSH keys instead. This limits the impact if any single key is compromised.
Ensure that your Google Compute Engine instances are not configured to have external IP addresses in order to minimize their exposure to the Internet. To reduce attack surface, Google Cloud virtual machine (VM) instances should not have public IP addresses attached. Instead, VM instances should be configured to run behind load balancers.
impact:|
VM instances with public IP addresses are directly exposed to the internet, increasing the attack surface and risk of unauthorized access.
remediation:|
Remove external IP addresses from your VM instances using the 'gcloud compute instances delete-access-config' command or through the Google Cloud Console. Configure instances to run behind load balancers instead.
name:Interactive Serial Console Support Not Disabled
author:princechaddha
severity:medium
description:|
Ensure that "Enable connecting to serial ports" configuration setting is disabled for all your production Google Compute Engine instances. The interactive serial console does not support IP-based access restrictions such as IP address whitelists. If enabled, clients can attempt to connect to your instance from any IP address if they know the username, SSH key, project ID, instance name and zone.
impact:|
With interactive serial console enabled, instances are accessible from any IP address without IP-based restrictions, potentially allowing unauthorized access if credentials are compromised.
remediation:|
Disable interactive serial console support by setting the "serial-port-enable" metadata key to "false" for your VM instances to prevent unauthorized access through serial ports.
Ensure that your Google Compute Engine instances are configured to use Shielded VM security feature for protection against rootkits and bootkits. Google Compute Engine service can enable 3 advanced security components for Shielded VM instances:
- Virtual Trusted Platform Module (vTPM) - validates the guest virtual machine pre-boot and boot integrity, and provides key generation and protection
- Integrity Monitoring - lets you monitor and verify the runtime boot integrity using Google Cloud Operations reports
- Secure boot - protects your VM instances against boot-level and kernel-level malware and rootkits
impact:|
Without Shielded VM features enabled, your VM instances are more vulnerable to rootkits, bootkits, and other advanced threats that can compromise the boot integrity and security of your instances.
remediation:|
Enable Shielded VM security features (vTPM and Integrity Monitoring) for your VM instances. Note that enabling Secure Boot is optional and should only be done if you don't use custom or unsigned drivers, as it may prevent the VM from booting.
- '"VM instance " + instanceName + " in zone " + zone + " of project " + projectId + " does not have Shielded VM features (vTPM and Integrity Monitoring) fully enabled"'
name:Dataproc Cluster Not Using Customer-Managed Keys
author:princechaddha
severity:high
description:|
Ensure that your Google Cloud Dataproc clusters on Compute Engine are encrypted with Customer-Managed Keys (CMKs) in order to control the cluster data encryption/decryption process. You can create and manage your own Customer-Managed Keys (CMKs) with Cloud Key Management Service (Cloud KMS). Cloud KMS provides secure and efficient encryption key management, controlled key rotation, and revocation mechanisms.
impact:|
Without Customer-Managed Keys, you have less control over data encryption and key management, potentially impacting compliance requirements and security controls.
remediation:|
Re-create your Dataproc clusters with Customer-Managed Keys using Cloud KMS. Configure a key ring and CMK in Cloud KMS, then specify the key when creating the cluster using the '--gce-pd-kms-key' flag or through the console.
Ensure that your Google Cloud Dataproc clusters are not configured with external IP addresses to minimize exposure to the Internet. When external IP addresses are assigned to Dataproc clusters, the cluster instances are exposed directly to the Internet. This increases the attack surface and risks accidental data exposure if firewall rules are misconfigured.
impact:|
Publicly accessible Dataproc clusters increase the attack surface and risk of data exposure, as cluster instances can be directly accessed from the internet.
remediation:|
Re-create your Dataproc clusters with internal IP addresses only by using the '--no-address' flag or enabling 'Internal IP only' in the console. This ensures cluster instances use private IP addresses and communicate over internal networks only.
- '"Dataproc cluster " + clusterName + " in region " + region + " of project " + projectId + " is configured with external IP addresses and is publicly accessible"'
Ensure that dangling DNS records are removed from your public Cloud DNS zones in order to maintain the integrity and authenticity of your domains/subdomains and to protect against domain hijacking.
impact:|
Dangling DNS records can lead to domain hijacking and misrouting of traffic, compromising the security and reliability of your domain infrastructure.
remediation:|
Regularly audit your DNS records and associated IP addresses. Remove any DNS records that point to IP addresses no longer reserved under your Google Cloud account.
reference:
- https://cloud.google.com/dns/docs
tags:cloud,devops,gcp,gcloud,dns,gcp-cloud-config
flow:|
code(1)
for(let projectId of iterate(template.projectIds)){
set("projectId", projectId)
code(2)
for(let managedZone of iterate(template.managedZones)){
set("managedZone", managedZone)
code(3)
for(let recordSet of iterate(template.recordSets)){
recordSet = JSON.parse(recordSet)
set("recordType", recordSet.type)
set("recordData", recordSet.rrdatas)
code(4)
}
}
}
self-contained:true
code:
- engine:
- sh
- bash
source:|
gcloud projects list --format="json(projectId)"
extractors:
- type:json
name:projectIds
internal:true
json:
- '.[].projectId'
- engine:
- sh
- bash
source:|
gcloud dns managed-zones list --project $projectId --format="json(name,visibility)"
extractors:
- type:json
name:managedZones
internal:true
json:
- '.[].name'
- engine:
- sh
- bash
source:|
gcloud dns record-sets list --zone=$managedZone --format="json(type,rrdatas)"
extractors:
- type:json
name:recordSets
internal:true
json:
- '{type: .type, rrdatas: .rrdatas[]}'
- engine:
- sh
- bash
source:|
gcloud compute addresses list --filter "addressType~EXTERNAL" --format="json(name,status,address)"
matchers:
- type:word
words:
- 'RESERVED'
extractors:
- type:dsl
dsl:
- '"Dangling DNS Record: Type: " + recordType + " Data: " + recordData + " in Zone: " + managedZone + " of Project: " + projectId'
name:DNSSEC Not Enabled for Google Cloud DNS Zones
author:princechaddha
severity:medium
description:|
Ensure that DNSSEC security feature is enabled for all your Google Cloud DNS managed zones in order to protect your domains against spoofing and cache poisoning attacks. By default, DNSSEC is not enabled for Google Cloud public DNS managed zones.
impact:|
Not enabling DNSSEC for DNS zones can increase the risk of DNS spoofing and cache poisoning, compromising the security of domain resolutions.
remediation:|
Enable DNSSEC for each Google Cloud DNS managed zone through the Google Cloud Console or using the `gcloud dns managed-zones update` command with the `--dnssec-state=on` flag.
reference:
- https://cloud.google.com/dns/docs/dnssec
tags:cloud,devops,gcp,gcloud,dns,gcp-cloud-config
flow:|
code(1)
for(let projectId of iterate(template.projectIds)){
set("projectId", projectId)
code(2)
for(let managedZone of iterate(template.managedZones)){
set("managedZoneName", managedZone)
code(3)
}
}
self-contained:true
code:
- engine:
- sh
- bash
source:|
gcloud projects list --format="json(projectId)"
extractors:
- type:json
name:projectIds
internal:true
json:
- '.[].projectId'
- engine:
- sh
- bash
source:|
gcloud dns managed-zones list --project $projectId --format="json(name,visibility)"
extractors:
- type:json
name:managedZones
internal:true
json:
- '.[].name'
- engine:
- sh
- bash
source:|
gcloud dns managed-zones describe $managedZoneName --project $projectId --format="json(dnssecConfig.state)"
matchers:
- type:word
words:
- 'off'
extractors:
- type:dsl
dsl:
- '"DNSSEC not enabled for Managed Zone: " + managedZoneName + " in Project: " + projectId'
Ensure that Domain Name System Security Extensions (DNSSEC) feature is not using the deprecated RSASHA1 algorithm for the Key-Signing Key (KSK) associated with your DNS managed zone file.
impact:|
Using the deprecated RSASHA1 algorithm in DNSSEC configurations can expose DNS infrastructure to vulnerabilities and compromise the integrity and security of DNS data.
remediation:|
Update the DNSSEC configuration for each DNS managed zone to use more secure algorithms like RSASHA256 or ECDSAP256SHA256 for the Key-Signing Key (KSK).
Ensure that Domain Name System Security Extensions (DNSSEC) feature is not using the deprecated RSASHA1 algorithm for the Zone-Signing Key (ZSK) associated with your public DNS managed zone.
impact:|
Using RSASHA1 as the zone-signing algorithm in DNSSEC can expose DNS data to increased risks of being compromised due to weaker cryptographic strength.
remediation:|
Update the DNSSEC configuration to use a stronger, more secure signing algorithm like RSASHA256 or ECDSAP256SHA256 for your DNS managed zones.
name:Filestore Instance Deletion Protection Not Enabled
author:princechaddha
severity:medium
description:|
Ensure that your Google Cloud Filestore instances have Deletion Protection feature enabled in order to protect them from being accidentally deleted. With the Deletion Protection safety feature enabled, your Filestore instances are guaranteed to be protected from accidental deletion, ensuring your data remains safe.
impact:|
Without deletion protection, Filestore instances could be accidentally or maliciously deleted through the console, CLI, or API calls, leading to data loss and service disruption.
remediation:|
Enable deletion protection for your Filestore instances using the 'gcloud filestore instances update' command with the '--deletion-protection' flag or through the Google Cloud Console.
name:Filestore Instance Not Using On-Demand Backup
author:princechaddha
severity:high
description:|
Ensure that on-demand backup and restore functionality is in use for your Google Cloud Filestore instances to ensure data protection, disaster recovery, and regulatory compliance. The backup and restore process does not consume provisioned capacity and has no impact on the performance and availability of your Filestore applications.
impact:|
Without backups, data loss from accidental deletion, corruption, or disaster events could lead to extended application downtime and inability to recover critical data.
remediation:|
Create on-demand backups for your Filestore instances using the 'gcloud filestore backups create' command or through the Google Cloud Console. Configure regular backup schedules to ensure point-in-time recovery capabilities.
name:Filestore Instance Not Using Customer-Managed Encryption Keys
author:princechaddha
severity:high
description:|
Ensure that data stored on your Google Cloud Filestore instances is encrypted at rest with Customer-Managed Encryption Keys (CMEK) instead of Google-managed encryption keys. CMEKs provide greater control over the encryption and decryption process, enabling you to meet stringent compliance requirements.
impact:|
Without Customer-Managed Encryption Keys, you have less control over data encryption and key management, potentially impacting compliance requirements and security controls.
remediation:|
Re-create your Filestore instances with Customer-Managed Encryption Keys using Cloud KMS. Configure a key ring and CMK in Cloud KMS, then specify the key when creating the instance using the '--kms-key' flag or through the console.
name:Filestore Instance Not Protected by VPC Service Controls
author:princechaddha
severity:medium
description:|
Ensure that VPC Service Controls are used to configure a security perimeter around your Google Cloud Filestore instances. VPC Service Controls is a powerful security tool that allows you to restrict access to your cloud resources, including Filestore instances, to specific networks and clients. This helps prevent data exfiltration and enhances the security posture of your cloud environment.
impact:|
Without VPC Service Controls, Filestore instances may be vulnerable to unauthorized access and data exfiltration, as there is no security perimeter controlling data flow between resources.
remediation:|
Configure VPC Service Controls perimeter to protect your Filestore instances by including the Cloud Filestore API (file.googleapis.com) in the restricted services list and adding your project to the perimeter's protected resources.
name:Filestore Instance Client Access Not Restricted by IP
author:princechaddha
severity:medium
description:|
Ensure that client access to your Google Cloud Filestore instances is limited to specific (trusted) IP addresses or IP address ranges in order to protect your data against unauthorized access. By default, Filestore instances provide full (root-level read/write) access to all clients within the same Google Cloud project and VPC network.
impact:|
Granting untrusted clients access exposes Filestore instance data to unapproved access, modification, or deletion. Without IP-based access rules, any client in the same project and VPC can access the instance.
remediation:|
Configure IP-based access rules for your Filestore instances to restrict access to specific IP addresses or ranges. Once configured, any IP address or range not explicitly allowed will be denied access.
name:Automatic Runtime Security Updates Disabled in Google Cloud Functions
author:princechaddha
severity:medium
description:|
Ensure that automatic runtime security updates are enabled for your Google Cloud functions in order to keep the functions secure and protected against vulnerabilities without manual intervention.
impact:|
Having automatic runtime security updates disabled can expose Google Cloud functions to vulnerabilities which could be mitigated by timely updates.
remediation:|
Enable automatic runtime security updates for each Google Cloud function by setting the `serviceConfig.minInstanceCount` to a non-null value, ensuring functions are automatically updated with the latest security patches.
name:NoCustomer-Managed Encryption Keys in Google Cloud Functions
author:princechaddha
severity:high
description:|
Ensure that your Google Cloud functions use Customer-Managed Encryption Keys (CMEK) instead of Google-managed encryption keys to encrypt data at rest. CMEKs provide greater control over the encryption and decryption process, enabling you to meet stringent compliance requirements.
impact:|
Using Google-managed encryption keys instead of CMEKs reduces your ability to control the encryption process and comply with certain regulatory standards.
remediation:|
Configure your Google Cloud functions to use Customer-Managed Encryption Keys (CMEK) to ensure data encryption at rest is managed according to your compliance and security requirements.
name:Inactive Service Accounts in Google Cloud Functions
author:princechaddha
severity:high
description:|
Ensure that your Google Cloud functions are referencing existing, active service accounts in order to prevent execution failures and operational disruptions.
impact:|
Using inactive or deleted service accounts in Google Cloud Functions can lead to runtime errors and potential service disruption, affecting the stability and reliability of cloud services.
remediation:|
Verify and update the service accounts associated with your Google Cloud functions to ensure they are active and have the necessary permissions for function execution.
To minimize cold start latency and enhance performance, ensure that your Google Cloud Functions have a sufficient number of warm instances configured.
impact:|
Not setting a minimum number of instances for Google Cloud functions can result in potential cold start delays and degraded performance, especially for critical or latency-sensitive functions.
remediation:|
Configure the serviceConfig.minInstanceCount parameter for your Google Cloud Functions to an appropriate value that suits your workload demands.
name:Missing User-Defined Labels in Google Cloud Functions
author:princechaddha
severity:low
description:|
Ensure that user-defined labels are being used to tag, collect, and organize Google Cloud functions within your Google Cloud Platform (GCP) projects. User-defined labels are a lightweight and efficient way to group together related or associated cloud resources.
impact:|
Not using labels can lead to challenges in managing, identifying, and organizing resources, potentially increasing the complexity of operations and governance.
remediation:|
Define and apply user-defined labels to all Google Cloud functions to enhance resource management capabilities and improve operational efficiency.
name:NoServerless VPC Access in Google Cloud Functions
author:princechaddha
severity:high
description:|
Ensure that your Google Cloud functions are configured to use Serverless VPC Access in order to connect functions directly to your VPC network, allowing access to other VPC resources such as VM instances, MemoryStore instances, or any other cloud resources with an internal IP address. Without Serverless VPC Access, these functions may not be able to communicate efficiently with other resources in the same VPC.
impact:|
Lack of Serverless VPC Access in Google Cloud functions can lead to inefficient or failed communications between your serverless functions and other resources within the same VPC, impacting application performance and increasing latency.
remediation:|
Configure Serverless VPC Access for your Google Cloud functions by setting the vpcConnector parameter to the name of an already configured VPC connector in your project settings.
Identify any publicly accessible Google Cloud functions within your GCP account and update their IAM policy to protect against unauthorized users sending requests to invoke these functions. To deny access from anonymous and public users, remove the bindings for allUsers and allAuthenticatedUsers members from your function's IAM policy. The allUsers member represents any user on the Internet, while allAuthenticatedUsers represents any user or service account that can sign into Google Cloud Platform (GCP) with a Google account.
impact:|
Allowing public access to Google Cloud functions can lead to unauthorized use and potential security breaches.
remediation:|
Update the IAM policies of your Google Cloud functions to remove allUsers and allAuthenticatedUsers from the bindings to ensure that the functions are not publicly accessible.
name:Configure Dead Lettering for Pub/Sub-Triggered Functions
author:princechaddha
severity:low
description:|
Ensure that Google Cloud functions triggered by Pub/Sub have a Dead-Letter Topic (DLT) configured to handle undeliverable messages. To achieve this, configure your Pub/Sub subscriptions with a maximum number of delivery attempts. If a message cannot be delivered, it will be sent to the designated Dead-Letter Topic (DLT).
impact:|
Not having a Dead-Letter Topic for Pub/Sub-triggered functions can result in lost messages and unhandled failures, affecting the reliability of your application.
remediation:|
Configure a Dead-Letter Topic for each Pub/Sub-triggered function by setting up the necessary Pub/Sub subscription settings.
name:Use Secrets Manager for Managing Secrets in Google Cloud Functions
author:princechaddha
severity:medium
description:|
To prevent unauthorized access or accidental exposure of sensitive information, ensure that Secrets Manager service is used to store and manage secrets instead of storing them in cleartext within Cloud Functions environment variables.
impact:|
Storing secrets in environment variables without encryption can expose sensitive information to unauthorized access, potentially leading to security breaches and compliance issues.
remediation:|
Refactor your Google Cloud Functions to use Secrets Manager for managing sensitive configuration settings instead of storing them directly in environment variables.
name:Unrestricted Outbound Network Access in Google Cloud Functions
author:princechaddha
severity:high
description:|
Ensure that your Google Cloud functions are not configured to allow unrestricted outbound network access in order to prevent security vulnerabilities and minimize cloud costs. To ensure that your function's outbound traffic is restricted to internal IP ranges and can't communicate with external networks or the public Internet, set the VpcConnectorEgressSettings parameter to PRIVATE_RANGES_ONLY.
impact:|
Allowing unrestricted outbound network access can lead to potential security risks such as data exfiltration and increased cloud costs from unexpected external network communications.
remediation:|
Configure the VpcConnectorEgressSettings of your Google Cloud functions to PRIVATE_RANGES_ONLY to ensure all outgoing traffic is limited to internal IP ranges only.
name:Deprecated 1st Generation Google Cloud Functions
author:princechaddha
severity:high
description:|
Ensure that none of your Google Cloud functions are 1st (first) generation functions. 1st generation Google Cloud functions are considered deprecated and no longer receive updates or support, making them less secure, less performant, and lacking in new features compared to newer generations.
impact:|
Using deprecated 1st generation functions can expose your applications to security vulnerabilities, degrade performance, and miss out on new features provided by newer generations.
remediation:|
Migrate all 1st generation Google Cloud functions to newer generation runtimes as recommended by Google to ensure continued support and access to the latest features and security enhancements.
name:Google Cloud Functions Using Default Service Account
author:princechaddha
severity:medium
description:|
Ensure that your Google Cloud functions are configured to use user-managed service accounts instead of the default service account managed by Google Cloud in order to follow the Principle of Least Privilege (POLP) and enhance the security posture of your functions.
impact:|
Using default service accounts can grant more permissions than required to your functions, violating the Principle of Least Privilege and increasing security risks.
remediation:|
Configure your Google Cloud functions to use user-managed service accounts that have only the permissions necessary for the function to operate.
Ensure that the Auto-Repair feature is enabled for all your GKE cluster nodes to help maintain node health. Google Kubernetes Engine (GKE) triggers a repair action if a node reports consecutive unhealthy status reports for a given time threshold, such as when a node broadcasts a "NotReady" status, fails to broadcast any status, or runs out of disk space.
impact:|
Without auto-repair enabled, unhealthy nodes may remain in a degraded state indefinitely, potentially affecting the availability and reliability of your workloads running on those nodes.
remediation:|
Enable auto-repair for your GKE cluster node pools using:
Ensure that the Auto-Upgrade feature is enabled for all the nodes running within your Google Kubernetes Engine (GKE) clusters. This feature helps you keep your cluster nodes up to date with the latest supported version of Kubernetes, automatically applying security fixes and new functionalities.
impact:|
Without auto-upgrades enabled, cluster nodes may run outdated Kubernetes versions, missing critical security patches and feature updates, which could expose your clusters to known vulnerabilities.
remediation:|
Enable auto-upgrade for your GKE cluster node pools using:
Ensure that backups are enabled for your Google Kubernetes Engine (GKE) clusters to protect your workloads and enable disaster recovery capabilities. GKE backups capture both configuration and volume data, allowing selective or comprehensive restoration of workloads, which is valuable for disaster recovery, CI/CD pipelines, workload cloning, and managing upgrades.
impact:|
Without backups enabled, you risk potential data loss and extended downtime in case of disasters, and lack the ability to efficiently roll back workloads, migrate between clusters, or clone environments for testing and development.
name:GKE Clusters Without Binary Authorization Enabled
author:princechaddha
severity:medium
description:|
Ensure that Binary Authorization is enabled for your Google Kubernetes Engine (GKE) clusters to enforce container image security policies. Binary Authorization enhances security by ensuring only trusted container images can be deployed, reducing the risk of deploying vulnerable or unauthorized software.
impact:|
Without Binary Authorization enabled, there is no policy enforcement to prevent the deployment of untrusted or unauthorized container images, increasing the risk of deploying vulnerable or malicious software.
remediation:|
Enable Binary Authorization for your GKE clusters using:
name:GKE Clusters With Client Certificate Authentication Enabled
author:princechaddha
severity:medium
description:|
Ensure that authentication using client certificates is disabled for your Google Kubernetes Engine (GKE) clusters. Client certificates require manual key rotation for authentication and are difficult to revoke. It is highly recommended to use alternative authentication methods like OpenID Connect, which is the default authentication method used by gcloud and handles token management automatically.
impact:|
Using client certificate authentication introduces security management challenges as certificates don't auto-rotate and are difficult to revoke, potentially leading to security risks if certificates are compromised or not properly rotated.
remediation:|
Re-create your clusters without client certificates using:
Ensure that your Google Kubernetes Engine (GKE) cluster node pools use confidential GKE nodes to encrypt all running workloads. Confidential GKE nodes employ hardware-based memory encryption to safeguard your data and applications from unauthorized access or modification while in use.
impact:|
Without confidential GKE nodes enabled, workload data may be vulnerable to unauthorized access or modification while in use, even if the underlying hardware is compromised.
remediation:|
Enable confidential GKE nodes for your cluster node pools using:
name:GKE Clusters Not Using Container-Optimized OS
author:princechaddha
severity:medium
description:|
Ensure that your Google Kubernetes Engine (GKE) cluster nodes use the Container-Optimized OS (cos_containerd), a managed, optimized, and hardened base OS provided by GKE to limit the host's attack surface. cos_containerd's layered architecture enables advanced GKE features like gVisor and Image Streaming, and offers improved resource efficiency and security.
impact:|
Not using Container-Optimized OS with containerd can result in reduced security posture and inability to use advanced GKE features. Other OS images may have larger attack surfaces and lack the optimizations specific to container workloads.
remediation:|
Update your GKE node pools to use Container-Optimized OS with containerd using the command:
- '"Node pool " + nodePoolName + " in GKE cluster " + clusterName + " (" + location + ") of project " + projectId + " is not using Container-Optimized OS with containerd"'
Ensure that cost allocation is enabled for your Google Kubernetes Engine (GKE) clusters to gain detailed insights into resource usage. This feature allows you to break down resource consumption by Kubernetes namespaces and labels, making it easier to associate costs with specific entities and access detailed cost reports through billing data exported to BigQuery.
impact:|
Without cost allocation enabled, you lack detailed visibility into resource consumption and cost distribution across Kubernetes components, making it difficult to make informed decisions for cost optimization, budgeting, and chargeback allocation.
remediation:|
Enable cost allocation for your GKE clusters using:
Ensure that your Google Kubernetes Engine (GKE) clusters are configured to use user-managed service accounts instead of the default service account managed by Google Cloud. The default service account has broad permissions across your GCP project, which violates the Principle of Least Privilege (POLP).
impact:|
Using the default service account increases security risks as it has broad permissions that could be exploited if compromised, potentially leading to unauthorized access across project resources.
remediation:|
Create a custom service account with minimal required permissions and update your node pools to use it instead of the default service account.
- '"Node pool " + nodePoolName + " in GKE cluster " + clusterName + " (" + location + ") of project " + projectId + " is using the default service account"'
Ensure that Integrity Monitoring is enabled for your Google Kubernetes Engine (GKE) cluster nodes to monitor and automatically check the runtime boot integrity using Google Cloud Monitoring service. This feature helps verify that the boot loader and other measured components remain untampered.
impact:|
Without Integrity Monitoring enabled, there is no automated verification of boot integrity for cluster nodes, making it harder to detect potential tampering or compromises of the boot components.
remediation:|
Re-create your node pools with Integrity Monitoring enabled using:
Loaded 100 of 4171 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Prince Chaddha