Shifting Left on Security with Google Cloud Infrastructure
(This article was co-authored by Jason Bisson, Bakh Inamov, Jeff Levine, Lanre Ogunmola, Luis Urena, and Holly Willey, all Security & Compliance Specialists at Google Cloud.)
The concept of “shifting left” has been widely promoted in the software development life cycle. The idea behind the concept is that introducing security earlier (“leftwards”) into the development process will lead to fewer software-related security defects in production.
As organizations deploy their environments in the cloud, they must consider how security defects can arise due to cloud-related misconfigurations. In this blog, we are going to explore how to “shift left” in the cloud by identifying such defects earlier in the development cycle and improve the security posture of production deployments.
Some background
Google’s DevOps Research and Assessment (DORA) team first highlighted the importance of integrating security into DevOps in the 2016 State of DevOps Report . The report discussed the placement of testing (including security testing) in the software development lifecycle. In particular, most security testing efforts and tool usage happened after the development of a release has been completed. Once these defects have been identified, remediation may involve architectural changes and additional integration testing resulting in additional costs and delays as shown in Figure 1. For example, security defects in Production can lead to GDPR violations, with fines up to 4% of global annual revenue.
After changing the development lifecycle and inserting security testing into the development phase, we can identify security defects earlier and perform the corresponding remediation sooner. This results in fewer defects post-production and reduces remediation efforts and architectural changes. This process of introducing security early on is known as “shifting left.”
Notice in Figure 2 that the investments in security team time and tooling happens earlier resulting in a decrease in the number of defects and the costs associated with delays. Additionally, DORA’s State of DevOps report calls out the benefits of automated testing. Automated testing provides for the performance of consistent tests without the need for additional skills or intervention by the developer. Developers can continue to iterate quickly while team leads and project managers can be confident that common defects are being identified and remediated.
From code to cloud
The findings of the DORA team with regard to code security can also be applied to cloud security. As more organizations deploy their workloads to the cloud, it is important to consider the benefits of testing the security of the cloud infrastructure itself. Misconfigurations in cloud resources can lead toward security incidents that can result in data loss. Examples of such misconfigurations include overly permissive firewall rules, weak passwords, or incorrect Identity and Access Management (IAM) permissions on service accounts and storage buckets. We can leverage Google Cloud services to identify these misconfigurations early in the development process and prevent such errors from emerging in production to reduce the cost of future remediation.
The key tools in our toolshed are Security Command Center and Cloud Build. Security Command Center provides visibility into misconfigurations, vulnerabilities, and threats within a Google Cloud organization. This information is critical when protecting your cloud infrastructure (virtual machines, containers, web applications) against threats or identifying potential gaps from compliance frameworks such as CIS Benchmarks, PCI-DSS, NIST 800–53 or ISO 27001. Security Command Center further supports the concept of shifting security left by allowing visibility of security findings at the project level for individual developers while still allowing Global visibility for Security Operations.Cloud Build provides for the creation of cloud-native CI/CD pipelines. You can insert custom health checks into a pipeline to evaluate certain conditions (such as security metrics) and fail the pipeline when irregularities are detected. We will now explore two use cases that take advantage of these tools
Security Health Checker
The idea behind Security Health Checker is to continuously monitor the security health of a Google Cloud project and promptly notify project members of security findings. Figure 3 shows developers interacting with a Google Cloud environment containing network, compute, and database components. Security Command Center has been configured to monitor the health of the project.
When Security Command Center identifies findings, it sends them to a Cloud Pub/Sub topic. A Cloud Function then takes the findings published to that topic and sends them to a Slack channel monitored by infrastructure developers. As a spell checker provides timely feedback on misspellings, so Security Health Checker provides prompt feedback on security misconfigurations in a Google Cloud project that could lead to deployment failures or post-production compromises. No additional effort is required on the part of developers.
Security Pipeline Checker
In addition to using Security Command Center for timely notification of security concerns during the development process, we can also integrate security checks into the CI/CD pipeline by using Security Command Center along with Cloud Build as shown in Figure 4.
The pipeline begins with a developer checking some code into a git repository. This repository is mirrored to Cloud Source Repositories. A build trigger will begin the build process. The build pipeline will include a short waiting period of a few minutes to give Security Command Center a chance to identify security vulnerabilities. While at first glance, a brief delay may appear undesirable, the analysis that takes place during that interval can result in the reduction of security defects post-production. At the end of the waiting period, a Cloud Function serving as a Security Health Checker will evaluate the findings from Security Command Center (Connector 1 in Figure 4). If the validator determines that unacceptable security findings exist, the validator will inject a failure indication into the pipeline to terminate the build process (Connector 2 in Figure 4). Developers will have visibility into the failure triggers and remediate them before successfully deploying code to production. This is in contrast to the findings in the 2016 State of DevOps Report wherein organizations that didn’t integrate security into their DevOps processes spent 50% more time remediating security issues than those who “shifted left” on security.
Closing thoughts
DORA’s 2016 State of DevOps report called out the need for “shifting left” with security, introducing security earlier in the development process to identify security vulnerabilities early to reduce mitigation efforts post-production. The report also identified the need for and the benefits of automated testing. We looked at two ways of achieving these objectives using Google Cloud services. The Security Health Checker provides feedback to developers using Security Command Center and Slack to notify developers of security findings as they pursue their development activities. The Security Pipeline Checker uses Security Command Center as part of a Cloud Build pipeline to terminate a build pipeline if vulnerabilities are identified during the build process. If you would like to implement the Security Heath Checker and the Security Pipeline Checker, check out the GitHub repository. We hope these examples will help you “shift left” using Google Cloud services. Happy coding!
