Compliance

Compliance Engineering - Continuous Compliance GCP case studies

#security

Our previous article provided tools and techniques to transform your productionalization process and make it ready for Cloud workloads. In this post, we will cover technical examples of GCP controls and how it can help your organization maintain your security and compliance posture in GCP.

In comparison to on-prem infrastructure, GCP is a highly integrated environment and provides out of the box capabilities to evidence a large variety of controls. The following cornerstones build the foundation of an effective control attestation:

  • Inventory Management - On-prem workloads frequently have discovery tools installed to understand what infrastructure components are actually deployed in the corporate IT environment. In GCP, every component has to be explicitly declared for it to exist. This accurate and real-time inventory is the basis for the below case studies to reach continuous compliance.

  • Infrastructure as Code - All deployments and configuration in GCP should be implemented in machine readable instructions (such as Terraform) and as part of a CI/CD pipeline staging to higher level environments. The programmatic definition of infrastructure resources allows for efficient checking of the security posture before the deployment takes place (such as a misconfigured Google Cloud Storage bucket that would be exposed to the public Internet).

  • Compliance as Code - The same is true for the implementation of policies. Programmatic definition, “Compliance as Code” should be used to automate the evidence-gathering and compliance-checking during the lifetime of the workload. Google Cloud’ Risk and Compliance as Code solution can help implement such a process based on best practices.

Now let’s take a few controls out from the Cloud Security Alliance Cloud Controls Matrix (CSA CCM) and show how GCP helps you to fulfill them. 

Case Study - Log Key Lifecycle Management events

Let’s have a look at a specific control from CSA CCM regarding log key lifecycle management:

LOG-11 - Logging & Monitoring Transaction/Activity Logging - Log and monitor key lifecycle management events to enable auditing and reporting on usage of cryptographic keys.

Cloud Key Management Service (KMS) in combination with Cloud Audit Logs records customer activities on the Key object, such as creating or destroying a key. Customers can define the retention period of the logs as well as access permissions. A log message would look like the following:

  gcloud logging read "logName : projects/my-project/logs/cloudaudit.googleapis.com" --project=my-project

[...]
   permission: cloudkms.cryptoKeys.create
    resource: projects/my-project/locations/us-central1/keyRings/sample-keyring
    resourceAttributes:
      name: projects/my-project/locations/us-central1/keyRings/sample-keyring/cryptoKeys/key-us
      service: google.cloud.kms
      type: google.cloud.kms.CryptoKey
  methodName: CreateCryptoKey
[...]

Figure 1 - Logging of key creation

In order to actively monitor these activities, a counter log-based metric in Operations Suite has to be created for protoPayload.methodName="CreateCryptoKey" . This log-based metric can then be used to create an alarm for each event, or trigger a notification for when a certain threshold is reached. Cloud Monitoring will display an incident notification and have visualizations ready to be inspected. 

Case Study - Change restoration

In the traditional IT world, production roll-outs are often staged through the environments guarded by a strict change management process and subject to change approval boards. In the cloud world, equivalent checks should take place but can be accomplished end-to-end much more quickly. As mentioned above, there should be limited human interaction in the production environment. All application and infrastructure deployments should be following the infrastructure as code pattern and leverage automation technologies. Repeatable automated patterns will simplify operations and enable compliance verification at scale. Let’s look at the following example out of the CSA CCM control set:

CCC-09 Change Control & Configuration Management - Change Restoration - Define and implement a process to proactively roll back changes to a previous known good state in case of errors or security concerns.

By describing the state of the infrastructure configuration in Terraform, each change can easily be rolled-out and rolled-back without missing out a step or having a non-reversible change. The control owners have assurance that the changes are automated and fully reversible to a known working state.

As a best practice, we recommend storing the Infrastructure as Code patterns along the application project source code in the version control system, and staging it through the environments by leveraging a CI/CD pipeline.

Case Study - Safeguard Logs Integrity

Extensive logging capabilities of GCP such as Cloud Audit Logs and Access Transparency take a record of activities happening in the environment. Especially in regulated industries, these logs have to be kept for an extended period while ensuring their immutability and integrity. This requirement is reflected in the following CSA CCM: 

 IAM-12 Identity & Access Management - Safeguard Logs Integrity - Define, implement and evaluate processes, procedures and technical measures to ensure the logging infrastructure is read-only for all with write access, including privileged access roles, and that the ability to disable it is controlled through a procedure that ensures the segregation of duties and break glass procedures.

Leveraging GCP Log Sinks, log entries can be exported into different supported destinations, including Google Cloud Storage. Log entries will be stored as JSON files on a GCS bucket. GCS buckets support data retention policies, which govern how long objects in the bucket must be retained. The  “Bucket Lock” feature lets you set a permanent non-reversible configuration of the data retention policy on the corresponding GCS bucket.  

Example Terraform for locking a bucket and keeping the files for 2 days:

  resource "google_storage_bucket" "my-log-bucket" {
  name          = "my-log-bucket-8225"
  location      = "EU"
  force_destroy = false

  retention_policy {
    retention_period = 172800
    is_locked        = true
  }
}

Figure 2 - Bucket Locking mechanism

The Bucket Lock is a non-reversible activity. As outlined in the above example, files stored within that GCS bucket will be retained for the defined period, including roles with privileged access.

  $ gsutil retention get gs://my-log-bucket-8225
  Retention Policy (LOCKED):
    Duration: 2 Day(s)
    Effective Time: Tue, 30 Nov 2021 13:17:14 GMT

$ gsutil retention set 1d gs://my-log-bucket-8225
Setting Retention Policy on gs://my-log-bucket-8225/...
AccessDeniedException: 403 Cannot reduce retention duration of a locked Retention Policy for bucket 'my-log-bucket-8225'.

gsutil rm gs://my-log-bucket-8225/README.txt
Removing gs://my-log-bucket-8225/README.txt...
AccessDeniedException: 403 Object 'my-log-bucket-8225/README.txt' is subject to bucket's retention policy and cannot be deleted, overwritten or archived until 2021-12-02T05:24:02.18624-08:00

Figure 3 - Bucket Locking effects

FSI transformation

Automation has been a key driver for accelerating transformation at Deutsche Bank:

With the last few controls being transformed to ‘cloud ready’ and the initial set of applications passing through the controls, control automation is now at the center of our focus. As we progressively learn, utilize, and gain confidence in the real power of the embedded control framework of Google Cloud, we closely work with the control owners to leverage Google Cloud native capabilities. The success we see in automation is now driving the momentum in the on-prem world as well, therefore the hybrid model for automating controls is the next challenge for us in the upcoming months.Greta Binder, Operational Readiness Product Owner - Vice President at Deutsche Bank

The integrated environment of GCP provides foundational capabilities (such as real-time inventory) that can significantly reduce the burden for control owners as they work to establish and maintain their security and compliance posture. The case studies give examples as to how GCP customers can move into continuous compliance, encompassing real-time attestation and notification (something which could occur in case of a misconfiguration, for example). The more familiar control owners become with the GCP capabilities the more confident they feel to automate their controls.

Building on the control automation examples we covered, potential next steps could be embedding the controls into policies within GKE Policy Controller, and GKE Config Connector seamlessly logging into Cloud Operations Suite, as well as Security Command Center. Read more about this topic as part of our recently released solution Modernizing Compliance: Introducing Risk and Compliance as Code.