Cloud IDS

Introduction

Cloud IDS is Google Cloud's managed network-based intrusion detection service. It uses the Palo Alto Networks threat-detection engine to inspect a copy of your VPC traffic for malware, spyware, command-and-control (C2) callbacks, lateral-movement attempts, exploit traffic against known CVEs, and policy-violating protocols. Critically, Cloud IDS is out-of-band detection only — it does not sit inline, does not drop packets, and does not add latency to the production path. Instead, it consumes a mirrored copy of traffic produced by Google Cloud Packet Mirroring and emits alerts to Cloud Logging and Security Command Center (SCC).

For the PCNE exam, Cloud IDS is the canonical answer whenever a scenario combines deep packet inspection, PCI-DSS / HIPAA compliance evidence, and a requirement that traffic not be blocked or slowed. It is not the answer for "block this attack at the edge" (that is Cloud Armor) or "filter east-west between subnets" (that is hierarchical firewall policy). This study note walks through Cloud IDS endpoints, mirroring policies, signature classes, severity levels, throughput tiers, SCC integration, the VPC peering plumbing that powers it, alert routing to Pub/Sub, exclusion lists, and the canonical out-of-band deployment patterns the exam expects you to recognize.

白話文解釋（Plain English Explanation）

Cloud IDS vocabulary — endpoint, mirroring policy, severity, exclusion, producer VPC — is dense, so three analogies make the constructs stick before we get into gcloud commands and field names.

Analogy 1: Hotel Security Camera Plus Off-Duty Cop

Picture a busy hotel. The front-door lock is your VPC firewall policy — it checks the key card before anyone gets in. The lobby security camera is VPC Flow Logs — it records who walked in and out, how long they stayed, and how many bags they carried, but it cannot see what is inside the bags. Cloud IDS is the off-duty police officer the hotel hired: this officer does not check key cards (that is the lock's job), does not block anyone (because they are off-duty, technically observers), but they have decades of training in spotting suspicious behavior. The hotel pipes a copy of the lobby's CCTV feed to the officer's monitor (that is Packet Mirroring). When they spot someone trying to pick a vending-machine lock or matching a face on the wanted list (that is a Palo Alto Networks signature match), they radio the hotel manager (a Security Command Center finding) and the hotel decides whether to call the on-site security team to physically intervene (your automation pipeline through Pub/Sub). The officer never touches a guest — Cloud IDS never touches a packet.

Analogy 2: Mail-Room X-Ray vs. Postal-Address Sticker

Compare two ways of inspecting parcels arriving at a corporate mail room. The shipping label (sender address, weight, destination department) is what VPC Flow Logs sees — 5-tuple metadata: source IP, destination IP, ports, protocol, bytes. That is enough to detect "this department got 10× more mail than usual" but useless for spotting an actual threat inside a box. The X-ray machine is Cloud IDS — it inspects what is inside the parcel: explosives, contraband, malware payloads, exploit signatures. The X-ray runs on a conveyor belt parallel to the regular sorting belt (out-of-band Packet Mirroring), so the parcels are not delayed. When the X-ray spots something matching a known threat signature, it lights up a colored lamp ranked by danger — green for Informational, yellow for Low, orange for Medium, red for High, flashing red for Critical — and the mail-room supervisor decides what to do. Crucially, the X-ray itself does not stop parcels; it produces alerts. If you want parcels stopped, you need a separate enforcement mechanism (Cloud Armor / firewall rule / SOAR playbook triggered by the alert).

Analogy 3: Smoke Detector Network in a Factory

A modern factory deploys smoke detectors per zone — production line A, production line B, chemical storage, shipping dock. Each detector watches its own zone for smoke signatures (burning plastic vs. electrical fire vs. solvent fire) and reports back to a central panel. Cloud IDS endpoints are zone-specific smoke detectors: you create one endpoint per region per VPC and attach mirroring policies that specify which zones (subnets / instance groups) feed mirrored traffic into it. The detector's sensitivity is the severity threshold you set — a chemical-storage detector flips alarms on Informational smoke because false negatives are catastrophic; a workshop detector might only trip on Medium or higher to avoid flooding the operator with false alarms. The exclusion list is the whitelist the maintenance team taped to the panel — "ignore the fork-lift exhaust between 6 a.m. and 8 a.m. on receiving days" — because they confirmed those smoke patterns are benign and noisy. And like a real smoke-detector network, Cloud IDS does not put out fires — it raises alarms that drive the actual response (manually or via automation).

Cloud IDS Endpoints — The Regional Inspection Engine

A Cloud IDS endpoint is the unit of deployment. It is a regional, managed resource that runs the Palo Alto Networks inspection engine inside a Google-managed service producer VPC, connected to your VPC via Private Services Access (VPC peering). You do not see the VMs that run the engine — Google manages all scaling, patching, and signature updates.

Endpoint creation and scope

Endpoints are created with gcloud ids endpoints create:

gcloud ids endpoints create ids-east \
  --network=prod-vpc \
  --zone=us-central1-a \
  --severity=INFORMATIONAL \
  --threat-exceptions=12345,67890

The --severity flag sets the minimum severity the endpoint will emit alerts for. Choices, from most verbose to least, are INFORMATIONAL, LOW, MEDIUM, HIGH, CRITICAL. Endpoint creation typically takes 20–30 minutes because Google must provision a producer-VPC peering connection if one does not already exist for the project.

Endpoint is regional, mirroring is zonal

A Cloud IDS endpoint is created in a zone but inspects traffic across the entire region of the attached VPC subnet network. You attach as many mirroring policies as you need, but each policy mirrors a single region's traffic. To inspect multi-region traffic, you create one endpoint per region.

Endpoint quotas and limits

Default quotas are conservative: 10 endpoints per project, 5 mirroring policies per endpoint, and a regional VPC peering relationship is established once and reused for every endpoint in the same VPC. Hitting quotas is the most common reason a deployment plan needs an upfront quota-increase ticket.

Packet Mirroring — How Traffic Reaches the Endpoint

Cloud IDS does not see traffic by magic. It depends on Packet Mirroring, a separate VPC networking feature that clones selected packets and forwards the clones to a collector. When Cloud IDS is the collector, the mirroring policy auto-detects the endpoint's forwarding-rule frontend.

Selecting what to mirror

A Packet Mirroring policy chooses sources by:

• Subnet: every VM in a subnet is mirrored.
• Instance: a list of specific Compute Engine VMs.
• Tag: VMs carrying network tags such as prod-web, pci-tier. You can additionally filter by protocol and CIDR (tcp, udp, icmp, esp) so that the endpoint only inspects, say, north-south HTTPS while ignoring intra-cluster gRPC.

What is mirrored

Both ingress and egress packets are copied, including their full payload. The clone is a true copy, not a sample — Cloud IDS analyses 100% of mirrored packets up to the endpoint's throughput cap.

Mirroring does not affect production traffic

The clone takes a parallel path inside Google's network fabric. The original packet continues to its real destination at full speed. The mirroring fan-out is metered against the source VM's egress quota only nominally — the dominant cost is the Cloud IDS endpoint hourly charge and the inspected-GB charge.

Cross-VPC mirroring caveat

A Packet Mirroring policy and its collector must be in the same VPC network. To inspect traffic in a different VPC, you create a second endpoint in that VPC — you cannot mirror VPC A's traffic into VPC B's endpoint, even when those VPCs are peered.

Palo Alto Networks Signature Engine — What Cloud IDS Actually Detects

The engine inside Cloud IDS is the Palo Alto Networks Threat Prevention content set — the same signature database used in PAN-OS NGFWs. Signatures are updated by Google in the background; you do not control signature versions.

Threat categories

• Vulnerability exploits: known CVE exploitation traffic, e.g., Log4Shell payloads, Apache Struts OGNL injection, ProxyShell attack chains. The engine matches the on-wire byte pattern, not the destination application's actual version.
• Malware: file-based payloads identified by sha256 hashes and behavioral signatures, including known ransomware droppers, cryptominers, and remote-access trojans (RATs).
• Spyware / C2: command-and-control beaconing patterns from infected hosts, including DNS tunnelling, IRC C2, and HTTPS metadata heuristics (JA3 fingerprints, certificate anomalies).
• Anti-spyware DNS: queries to known malicious domains in Palo Alto's DNS sinkhole feed.
• Suspicious protocols: anonymizer traffic (Tor handshake patterns), unsanctioned VPN protocols, and protocol-anomaly events such as malformed TLS or HTTP smuggling.

Decryption boundary

Cloud IDS inspects plaintext only. TLS-encrypted payloads pass through as opaque blobs — only the TLS handshake metadata (SNI, JA3, certificate) is usable. To inspect HTTPS payloads, terminate TLS upstream (External HTTPS Load Balancer with SSL Policy, or instance-level decryption) and mirror the post-decryption traffic.

Signature update cadence

Palo Alto Networks ships content updates several times per week. Cloud IDS picks these up automatically — there is no signature-management API you operate. The trade-off: you cannot pin or roll back a signature set; if a new signature produces false positives, your only options are exclusion list (per signature ID) or endpoint-level severity threshold.

Severity Levels — Informational, Low, Medium, High, Critical

Every Cloud IDS alert carries a severity from the Palo Alto engine. The five levels are not arbitrary labels — they map to PAN-OS conventions and drive how you triage alerts at scale.

Definitions

• Informational — protocol anomalies, suspicious headers, low-confidence DNS reputation. High false-positive rate; useful only when you have spare analyst capacity.
• Low — reconnaissance traffic, port scans, banner grabbing. Indicates someone is looking but has not yet exploited anything.
• Medium — exploit attempts against non-critical vulnerabilities, suspicious file downloads. The "actionable but not panic" bucket.
• High — successful exploit indicators, known-malicious payload signatures, lateral movement attempts, common ransomware C2 callbacks.
• Critical — confirmed exploitation of severe CVEs (e.g., RCE on edge-facing services), active data exfiltration patterns, ransomware encryption-loop signatures.

Endpoint minimum severity

The --severity flag at endpoint creation drops alerts below the chosen level before they are emitted. Setting --severity=MEDIUM means Informational and Low signatures still match but are silently discarded; you save log volume and SCC noise.

Per-environment tuning

• Production internet-facing: use LOW or INFORMATIONAL so the SOC sees reconnaissance attempts and can pre-emptively block.
• PCI / HIPAA cardholder data environment: use INFORMATIONAL — auditors expect full visibility, and the cost is acceptable for the smaller scope.
• Dev/test: use HIGH to suppress reconnaissance noise that does not represent real risk.
• Lift-and-shift VMs from on-prem: start at MEDIUM, observe two weeks, then tune.

Throughput Tiers — 5, 10, and 20 Gbps Endpoints

Cloud IDS endpoints are sized by inspection throughput, not by VM count. You choose a tier at endpoint creation; tier dictates both capability and price.

Available tiers

• 5 Gbps — entry tier, sized for small fleets or dev/test environments.
• 10 Gbps — mid-tier, the most common choice for production single-region workloads.
• 20 Gbps — high tier, for hub-and-spoke architectures funnelling multiple spokes' mirrored traffic into a central inspection point, or for high-traffic ecommerce / streaming workloads.

Sizing rule of thumb

Plan inspection capacity at 2× peak mirrored throughput. Packet Mirroring sends both ingress and egress, so a workload pushing 3 Gbps north-south already produces ~6 Gbps of mirrored traffic, exceeding a 5 Gbps endpoint. Going over the cap causes the endpoint to drop mirrored packets, which silently reduces detection coverage — you do not get a "buffer full" alert by default.

Hitting the cap

If your fleet outgrows 20 Gbps, the architectural answer is shard across endpoints: split mirroring policies by tag (e.g., tier-1 traffic to endpoint A, tier-2 to endpoint B) so each endpoint stays under its cap. Cross-region workloads automatically shard because each region needs its own endpoint.

Tier change

Changing tiers is not in-place — you create a new endpoint at the larger tier, point the mirroring policy at it, then delete the old endpoint. Plan a brief detection gap window (or run both endpoints in parallel for an hour for cutover testing).

Security Command Center Integration — Findings, Sources, and Routing

Cloud IDS is a registered security source in Security Command Center (SCC). Every threat the engine emits is published as a structured SCC finding in the THREAT category, in addition to landing in Cloud Logging.

Finding fields

Each Cloud IDS finding carries:

• category — the Palo Alto signature category (e.g., vulnerability, spyware, c2).
• severity — LOW / MEDIUM / HIGH / CRITICAL (SCC normalises Informational up to LOW).
• network — source/destination IP, port, protocol, application identifier (App-ID).
• signature_id — numeric Palo Alto signature ID; this is the value you put in an exclusion list.
• cvss — score where available.
• resource_name — the impacted VM/instance derived from internal IP.

SCC tier requirement

Cloud IDS findings appear in all SCC tiers (Standard, Premium, Enterprise). Standard tier sees them but does not get the cross-source correlation. Premium/Enterprise enables continuous exports, automation playbooks via SCC's notification module, and Sensitive Data Protection cross-referencing.

Routing findings out of SCC

SCC publishes new and updated findings to a Pub/Sub topic when you create a notification config. From there:

• Cloud Functions / Cloud Run can call APIs to remediate (firewall rule update, instance quarantine).
• BigQuery via Dataflow for SOC analytics.
• SIEM (Chronicle, Splunk, Sumo Logic) via Pub/Sub pull subscription.

Cloud Logging path

Independently of SCC, every Cloud IDS alert is written to Cloud Logging under the cloudids.googleapis.com/threat log name. Most operators set up a log sink to BigQuery or Pub/Sub for retention beyond 30 days.

VPC Peering Caveats — The Private Services Access Plumbing

Under the hood, your VPC reaches the IDS endpoint over a VPC peering with the Google-managed service producer VPC. This peering is established once per project per network using Private Services Access — and it imports a host of constraints you must plan around.

One peering per VPC

A given VPC can have one peering relationship with the Cloud IDS service producer. The first endpoint creates it; subsequent endpoints reuse it. Deleting all endpoints does not automatically delete the peering — you must explicitly delete the allocated IP range if you want a clean teardown.

Allocated IP range

Private Services Access requires you to allocate a CIDR block (/24 or larger) from your VPC's address space. The IDS producer VPC takes IPs out of this block. Choose a block that does not overlap with any existing or planned on-prem CIDR, because future VPN/Interconnect routes cannot conflict with the producer-VPC routes.

Transitive peering is forbidden

GCP VPC peering is not transitive. If your VPC peers with a shared-services VPC, and shared-services peers with the Cloud IDS producer VPC, your VPC cannot reach the IDS endpoint through the shared-services VPC. You must create an IDS endpoint in each VPC that needs inspection, or design a hub-and-spoke with Network Connectivity Center (which uses VPC Spokes, not peering).

Shared VPC host project

For Shared VPC architectures, the IDS endpoint and mirroring policy live in the host project. Service projects mirror their VMs to the host-project endpoint as long as the service-project VMs sit in the host-project subnets — there is no separate per-service-project endpoint.

Alert Routing to Pub/Sub — The Automation On-Ramp

Cloud IDS findings become operational only when something acts on them. The canonical route is SCC notification config → Pub/Sub → consumer.

Wire the notification config

gcloud scc notifications create cloud-ids-critical \
  --organization=123456789 \
  --pubsub-topic=projects/sec-ops/topics/scc-findings \
  --filter='category="THREAT" AND source_properties.product_name="Cloud IDS" AND severity="CRITICAL"'

The --filter clause means only Critical Cloud IDS findings reach the topic — High/Medium/Low can be routed to a different topic or directly to BigQuery.

Cloud Functions for auto-remediation

A gen2 Cloud Function subscribed to the topic can parse the finding, look up the impacted VM via resource_name, and call compute.instances.removeAccessConfig (cut public IP) or update a firewall rule to deny outbound. Keep response logic idempotent — SCC may deliver duplicates during outages.

SIEM forwarding

For Chronicle, use the Chronicle ingestion API with a Pub/Sub Dataflow pipeline. For Splunk, use the Splunk Dataflow template which accepts Pub/Sub input and emits HEC events. For both, the Cloud IDS finding JSON is preserved end-to-end so analyst queries can pivot by signature_id.

Log-based metrics for Cloud Monitoring

A simpler alerting path: create a log-based metric on the cloudids.googleapis.com/threat log filtered by severity, then a Cloud Monitoring alert policy on that metric. Routes via Pub/Sub, PagerDuty, or email/SMS.

Exclusion Lists — Silencing False Positives Without Blinding Yourself

Every IDS deployment hits false positives — vulnerability scanners on the corporate fleet, custom internal protocols flagged as anomalies, partner integrations using unusual TLS configurations. Cloud IDS handles this with threat exceptions (a.k.a. exclusion lists) at the endpoint.

How exceptions work

You pass --threat-exceptions to gcloud ids endpoints with a comma-separated list of Palo Alto signature IDs. Matching alerts are suppressed at the endpoint before they leave the inspector — they do not appear in Cloud Logging, SCC, or any downstream pipeline.

Finding the right signature ID

The signature ID is the threat_id field in any Cloud Logging entry for the alert. Investigate the first occurrence, confirm with the asset owner that the traffic is benign, then add the ID to the exception list. Document the justification — auditors will ask why each exception exists.

Per-endpoint, not global

Exceptions are per-endpoint, not per-organization. Suppressing signature 12345 on the dev endpoint does not suppress it on prod. This matters when your scanner fleet runs across environments — you must update each endpoint's list.

When not to use exceptions

Avoid suppressing Critical-severity signatures. If a Critical is a true false positive, prefer fixing the upstream traffic (e.g., update the scanner's TLS profile so it no longer trips the anomaly signature). A long exclusion list of Critical IDs is an audit red flag.

Deployment Patterns — Out-of-Band Detection-Only Architectures

Cloud IDS is always out-of-band. Every deployment pattern that works is a variation on the same theme: production traffic flows untouched, a mirrored copy reaches Cloud IDS, alerts feed an asynchronous response pipeline.

Pattern 1 — Single VPC, perimeter inspection

For workloads that all live in one VPC: one endpoint, one mirroring policy filtered by tag internet-facing. Cheapest design, sufficient for a single-team product.

Pattern 2 — Shared VPC host-project inspection

For organizations using Shared VPC: endpoint and mirroring policy in the host project, mirroring subnets that span service projects. One inspection point covers the whole shared environment. Common in regulated industries (banking, healthcare) where the network team owns Cloud IDS and product teams just produce mirrored traffic.

Pattern 3 — Hub-and-spoke (per-spoke endpoint)

For multi-VPC architectures connected via peering or Network Connectivity Center: one endpoint per VPC because mirroring cannot cross peerings. This is the design forced on you by the no-transitive-peering rule. Pricier but only viable shape when VPC isolation is required.

Pattern 4 — Multi-region production

For global services: one endpoint per region. Configure Pub/Sub routing so a single SOC consumes findings from all regions through one subscription. Tag findings with region for analyst routing.

Detection-only is the point, not a limitation

PCNE candidates sometimes "fix" Cloud IDS by trying to wire it inline. There is no inline mode. If the requirement is prevention, the answer is Cloud Armor (L7), VPC firewall rules / hierarchical policy (L3/4), Secure Web Proxy (egress URL filtering), or a third-party NGFW like Palo Alto VM-Series or Check Point CloudGuard. Cloud IDS is detection + alerting + audit-grade evidence; remediation is everywhere else.

Logging, Monitoring, and Audit Evidence

For compliance use cases — PCI-DSS Req 11.4 (intrusion detection on cardholder data network segments), HIPAA Security Rule §164.312(b) (audit controls), ISO 27001 A.13 (communications security) — Cloud IDS produces the evidence trail.

Cloud Logging retention

Default Cloud Logging retention is 30 days. For compliance, sink cloudids.googleapis.com/threat to Cloud Storage for 7-year retention (PCI keeps records 1 year online, 1 additional year retrievable; many orgs go longer) or BigQuery for searchable retention plus dashboarding.

Cloud Monitoring SLOs

Useful built-in metrics:

• ids.googleapis.com/preprocessor/received_bytes_count — bytes the inspector accepted from mirroring.
• ids.googleapis.com/preprocessor/dropped_bytes_count — bytes dropped due to throughput cap.
• ids.googleapis.com/alert_count — alerts emitted, broken down by severity label. Set an SLO alert when dropped_bytes / received_bytes > 1% — that means you are losing detection coverage and need a tier upgrade.

Audit trail

All endpoint CRUD operations are written to Cloud Audit Logs, so reviewers can see when a severity threshold was lowered, an exception was added, or an endpoint was deleted. Lock down ids.endpoints.update to a small group and require change tickets for severity / exception modifications.

Cost Anatomy

Cloud IDS pricing has three dimensions:

1. Endpoint hourly charge — depends on throughput tier (5/10/20 Gbps). Charged whether or not traffic flows.
2. Inspected traffic — per-GB charge on traffic actually examined.
3. Packet Mirroring costs — egress data charges may apply to the cloned traffic depending on cross-zone configuration.

Cost-control tactics

• Filter mirroring policies to high-value tiers only (tag pci, internet-facing); never mirror everything in a noisy dev environment.
• Set endpoint severity to MEDIUM in non-critical environments to drop low-value alerts before they hit storage.
• Use log sinks with exclusion filters to drop INFORMATIONAL severity entries from long-term retention.
• Single host-project endpoint in Shared VPC architectures rather than per-service-project duplication.

Comparison Table — Cloud IDS vs. Adjacent Services

The exam loves to slot Cloud IDS into rows where candidates reach for Cloud Armor or VPC Flow Logs. Anchor on three properties — out-of-band, deep packet inspection, no blocking — and the trap is easy to dodge.

Common PCNE Exam Scenarios

Scenario A — Detection without business impact

"A retail company must meet PCI-DSS Req 11.4 and cannot accept any added latency on the payment flow." Answer: Cloud IDS mirroring the PCI tier. Cloud Armor sits inline and adds tiny but non-zero latency; the requirement says zero impact, plus PCI specifically wants IDS, not WAF.

Scenario B — Encrypted traffic

"Compliance auditors want DPI on inbound HTTPS, but Cloud IDS sees only ciphertext." Answer: terminate TLS at the External HTTPS Load Balancer with an SSL Policy and a managed certificate, then mirror the decrypted traffic from the backend VMs. Cloud IDS does not decrypt itself.

Scenario C — Hub-and-spoke fail

"Three workload VPCs peer with a central security VPC; the team installed Cloud IDS in the security VPC and is confused that workloads' east-west traffic is not appearing." Answer: peering is not transitive and mirroring cannot cross peerings — install an endpoint in each workload VPC, or migrate workloads into a Shared VPC.

Scenario D — Endpoint drops bytes

"After a marketing campaign, alert volume halved despite traffic doubling." Answer: the 5 Gbps endpoint is dropping mirrored bytes; check dropped_bytes_count, then either upgrade the tier or shard the mirroring policy across two endpoints.

Scenario E — False positive on internal scanner

"The corporate vulnerability scanner trips a Cloud IDS signature daily." Answer: identify the signature_id from the Cloud Logging entry, add it to the endpoint's --threat-exceptions list, document the justification.

FAQs

Q: Does Cloud IDS block any traffic?

No. Cloud IDS is detection only. It consumes a mirrored copy of traffic and emits alerts to Cloud Logging and Security Command Center. To block traffic, pair findings with Cloud Armor, VPC firewall rules, or a Cloud Function that updates a deny rule in response to an SCC notification.

Q: Can Cloud IDS inspect TLS-encrypted (HTTPS) traffic?

Not directly — it sees only ciphertext. To inspect HTTPS payloads, terminate TLS upstream (External HTTPS Load Balancer with SSL Policy, or instance-level decryption) and ensure Packet Mirroring captures the post-decryption traffic. The TLS handshake itself (SNI, JA3, certificate) is still inspectable on encrypted flows.

Q: How do I deploy Cloud IDS across multiple regions?

One endpoint per region. Each region requires its own Packet Mirroring policy because mirroring is regional. A single Pub/Sub topic can fan in alerts from all regions via SCC notification configs, so the SOC sees a unified feed.

Q: What happens when mirrored traffic exceeds my endpoint's throughput tier?

The endpoint silently drops the excess. There is no automatic upgrade. Monitor ids.googleapis.com/preprocessor/dropped_bytes_count and either upgrade the tier (5 → 10 → 20 Gbps) or shard the mirroring policy across two endpoints based on tag.

Q: Can I peer two VPCs and share one Cloud IDS endpoint?

No. VPC peering is not transitive for Packet Mirroring. The mirroring policy and the Cloud IDS endpoint must be in the same VPC. The alternatives are an endpoint per VPC, or consolidating into a Shared VPC where the host project owns the single endpoint.

Q: How do I suppress alerts from a known-benign internal scanner?

Add the scanner's matched signature IDs to the endpoint's exclusion list via gcloud ids endpoints update --threat-exceptions=.... Exclusions are per-endpoint, so you must repeat the change on each endpoint where the scanner runs.

Q: Where do Cloud IDS findings go for long-term retention?

By default, Cloud Logging keeps them for 30 days. Create a log sink to Cloud Storage for compliance-grade archival (PCI/HIPAA), or to BigQuery for searchable retention plus analyst dashboards. Independently, SCC findings can be exported to Pub/Sub and fanned out to SIEM systems like Chronicle or Splunk.