Google Cloud network-security analysis

Evidence-Driven GCP Firewall Audit and Least-Privilege Automation

Implemented human-gated tool

Overview

Built a local-first audit tool that correlates GCP firewall inventory with flow evidence and identity context, then produces least-privilege candidates for human review and controlled change.

  • Security & Compliance Engineering
  • Cloud & Platform Architecture
  • Architecture Delivery & Evidence

Context / Problem

Broad firewall rules could not be assessed safely from configuration alone. The workflow needed to distinguish observed traffic from potential exposure, represent logging and identity blind spots, and turn evidence into reviewable candidates without allowing automated analysis to become uncontrolled change.

My Role

I designed and implemented the local audit application, evidence model, correlation logic, candidate generation, offline validation, approval boundary, preflight checks, execution journal, post-change verification, and rollback-oriented safeguards.

What I Did

  • Collected and normalized firewall inventory, logging context, flow evidence, and available identity information.
  • Correlated configuration and observed use while preserving unknowns and the difference between observed and potential behavior.
  • Generated least-privilege candidates for human review and designed controlled execution, verification, journaling, and rollback steps.

Architecture

Firewall inventory, flow evidence, and identity context enter a local correlation pipeline. The tool produces bounded candidates rather than commands, then requires human review before any optional controlled execution. Preflight, an evidence journal, verification, and rollback context surround the change path.

Human-gated firewall audit workflowConfiguration, flow evidence, and identity context are correlated into candidates that cross a human approval boundary before optional controlled execution.
  1. Firewall inventoryImplemented
  2. Flow evidenceImplemented
  3. Identity contextImplemented
  4. CorrelationImplemented
  5. CandidatesImplemented
  6. Human reviewHuman approval
  7. Controlled executionHuman approval
  8. Verification / rollbackImplemented

Observed traffic and potential exposure stay distinct; unknowns remain visible.

Key Decisions / Trade-offs

Keep observed and potential behavior separate
Absence of observed flow is not proof of no legitimate use, especially when logging coverage or identity context is incomplete.
Make approval a system boundary
Candidates remain advisory until a person reviews intent, ownership, blast radius, and the supporting evidence.
Preserve evidence around change
Immutable inputs and a journal make later verification and rollback reasoning possible.

Implementation Scope

The local-first analysis tool, evidence correlation, candidate generation, offline fixtures, approval gates, and change-safety workflow were implemented. Optional execution remained controlled and bounded by preflight and explicit review.

Safety / Security / Governance

The workflow surfaces blind spots and unknown identities, avoids treating missing logs as absence of traffic, and keeps changes human-gated. Public material omits project identifiers, IP ranges, rule names, sensitive counts, and operational records.

Scope Boundary

The tool supports evidence-driven review and controlled action; it does not autonomously change every rule or classify every broad rule as unsafe. Recommendations are not presented as universally executed, missing logs are not treated as proof of no traffic, and no unsupported reduction metric is claimed.

Related Capabilities

  • Security & Compliance Engineering
  • Cloud & Platform Architecture
  • Architecture Delivery & Evidence