05 · Platform · landing zones, GitOps, evidence
Compliance as code.
We build Google Cloud estates where every control is a line of Terraform, every change is a pull request, and every question an auditor asks links to the line that answers it. CIS, ISO/IEC 27001:2022, SOC 2 and MITRE ATT&CK, evidenced continuously rather than assembled once a year.
The landing zone
Six stages, applied in dependency order. Then tenants.
Aligned with Google's security foundations blueprint and the CIS GCP Foundations Benchmark. Modules compose in tiers: primitives wrap one resource, services integrate a managed product, links wire cross-project IAM from both sides, blueprints are the opinionated compositions environments consume.
- 0 · bootstrapShared DevOps project, state bucket, per-stage service accounts, Workload Identity Federation.
- 1 · organisationFolder hierarchy, shared projects, organisation-wide audit logging.
- 2 · networkingShared VPCs, NAT, DNS hub, private Google API access.
- 3 · securityOrg policies, KMS, Security Command Center, hierarchical firewall, secrets.
- 4 · devopsCI identity pool, deploy service accounts, logging infrastructure.
- 5 · vpc-scService perimeters, dry-run first, enforced after a clean soak.
Simulation · the delivery path
Three changes. Only one of them reaches production.
Every change to the estate is a pull request: validated, planned on the PR, approved, applied by a pipeline that holds no keys, and re-checked every night. Run a compliant change, a non-compliant one, and a hand patch in the console, and read the reasoning as each stage reports.
A pull request encrypts the audit dataset with a customer-managed key. Does it reach production, and what proves it did?
Each stage in order. A failed gate stops every gate after it; a guard runs regardless · feat/cmek-audit-dataset
- Pull request openedgaterunning
- Validategate·
- Previewgate·
- Reviewgate·
- Deploygate·
- Convergegate·
- Evidencegate·
- The questionA pull request encrypts the audit dataset with a customer-managed key. Does it reach production, and what proves it did?
Evidence
Every requirement, linked to the line that meets it.
Most recent client estate, anonymised, scan of 16 September 2026, re-run weekly into a locked evidence bucket. The 31 remaining scanner findings are accepted risks, each with a written rationale, such as DNSSEC on private zones the platform cannot sign. ISO and SOC 2 figures are control mappings prepared for an auditor, not a third-party attestation.
Identity and access
Group-based access managed in code, no direct user grants, keyless impersonated pipeline identities, break-glass through Privileged Access Manager.
SOC 2 CC6.1–CC6.3 · ISO A.5.15, A.5.18 · CIS 1.xData protection
Customer-managed keys on etcd, disks, databases, secrets and logs. Confidential Computing on every cluster. Binary Authorization enforced. Public zones signed with DNSSEC.
ISO A.8.24 · SOC 2 CC6.6, CC6.7 · CIS 4.x, 6.x, 7.xLogging and monitoring
Organisation-wide audit logs into a locked, encrypted 365-day archive. The full CIS metric-and-alert set deployed to every project. Security Command Center findings triaged in code.
ISO A.8.15, A.8.16 · SOC 2 CC7.2 · CIS 2.xNetwork
Private clusters with no public control plane, Private Service Connect, no external IPs on workloads, flow logs, VPC Service Controls perimeters.
ISO A.8.20–A.8.22 · CIS 3.xChange and supply chain
Every change a reviewed pull request, applied through an approval gate with destroy disabled by default. Providers and charts pinned and current.
SOC 2 CC8.1 · ISO A.8.32Recovery
Automated backups with point-in-time restore, tested and logged. A disaster recovery runbook that has actually been run.
ISO A.8.13 · SOC 2 CC7.4, CC7.5 · CIS 6.8MITRE ATT&CK · cloud
Read the controls from the attacker's side.
Benchmarks list what to configure. ATT&CK lists what an adversary does next. We map each relevant cloud technique to the control that prevents it and the alert that sees it. Pick one.
How would an attacker open a path through the firewall here, and what stops them?
MITRE ATT&CK Enterprise, cloud · T1562.007 · Impair Defenses: Disable or Modify Cloud Firewall
Loosening a firewall rule to open a path in or out.
Tactics in ATT&CK order, from first access to impact, with the techniques mapped under each.
- Initial accessCloud accountsPublic-facing apps
- PersistenceExtra credentialsExtra rolesImplanted image
- Defence evasionDisable logsOpen firewallModify compute
- Credential accessMetadata API
- CollectionStorage data
- ExfiltrationTo another account
- ImpactHijacked compute
- The questionHow would an attacker open a path through the firewall here, and what stops them?
- Exhibit 01 · PreventHierarchical firewall policy denies 0.0.0.0/0 on 22 and 3389 at the organisation.› CIS 3.6, 3.7
- Exhibit 02 · DetectAlert on firewall rule changes.› CIS 2.8
- Exhibit 03 · DetectNightly drift detection against main.
- FindingCovered both ways. 1 control stands in the way before it starts, and 2 controls see it if it is tried anyway. The technique is mapped to ISO A.8.20 · SOC 2 CC6.6, CC6.7.
- ConclusionOpen firewall (T1562.007, defence evasion) meets 1 preventive control and 2 detective controls, each one a line in the estate's code.
- Why a spreadsheet cannotA spreadsheet control matrix would tick T1562.007 and move on. The tick says a control exists, not that the line of code setting it is deployed today, and it does not fire when someone tries to open a path through the firewall. It is evidence for an auditor, not a tripwire.
Technique IDs from MITRE ATT&CK Enterprise, cloud platforms. The mapping to controls is ours. attack.mitre.org ↗