“Shift Left” to Harden Your Cloud Security Posture

“Shift Left” to Harden Your Cloud Security Posture

Blog Article Published: 07/18/2019

This article was originally published on Fugue's blog here.

By Josh Stella, Co-founder & Chief Technology Officer, Fugue

After a decade-long uneasy courtship with cloud computing, enterprises are migrating their IT systems to platforms like AWS and Azure as fast as they can. This means the key question for the security team is no longer “do we trust the cloud?” -- it’s “can we trust ourselves in the cloud?” Answering “yes” requires embracing a term common in application developers circles: “Shift Left”. Just as developers unit test their application code prior to merging into the build, they should also implement automated unit security testing of their modules prior to merging into the stage environment.

Small errors create big problems

If you've been running in the cloud at scale, you’re familiar with the challenge of trying to constantly monitor for the security risks created by resources without known owners, misconfigurations, and humans making errors like leaving too much access after a maintenance event. Human error is the number one cause of data breaches in the cloud, primarily due to the misconfiguration of cloud infrastructure.

Asking the security team to monitor and address misconfigurations in real-time is asking them to tilt at windmills. They quickly become overwhelmed by alerts and struggle to keep up with manual remediation or an ever-growing bag of bespoke automated remediation scripts. The all-too-common result is that the organization finds its brand name and reputation splashed across news headlines and articles about data exposure or loss due to a cloud misconfiguration.

Security and compliance shift left

Among developers, the term “shift left” describes moving a particular function to earlier phases of their processes to make identifying and fixing bugs and other errors easier and less time-consuming. The longer they wait, the more difficult making a fix becomes, and that creates delays.

Developers typically relegate security and compliance considerations as afterthoughts implemented as a gate during the test phase. Then they grow frustrated when red flags go up that force them to perform rework in design, development, and testing, and blame the security team for delays moving applications into production.

Automating the shift left of compliance and security into the design and develop phases will eliminate those delays and frustrations, make better systems, and turn those functions into highway builders rather than toll booth operators.

Establish universal policy interpretations and secure baselines

This isn’t just a process change, it’s a culture change. Organizations will likely need to get their security, DevOps and compliance teams to commit to establishing trust and confidence with one another. The best way to accomplish this is to have a “contract” between the teams in the form of actual code that includes explicit and shared interpretations of policy and establishes a baseline of the environment that is enforced via automated tools and processes all the way through the software development lifecycle (SDLC).

A baseline is a complete configuration of an application from the infrastructure up. Baselining allows all stakeholders to determine if the configuration is acceptable early in the process. Developers need to make sure the system functions as intended. Operations needs to know that the system is reliable and maintainable. Security needs to know that it is configured in conformance with best practices and policies at deployment and during operations, and compliance needs to know that it meets audit and/or regulatory controls.

By establishing a definition of known-good into the design and development phases, all parties can come to an agreement early in the process and work together to avoid costly delays. The term “DevSecOps” is becoming more popular as security and DevOps realize they need to come together to address security and compliance considerations earlier in the development process. Creating and enforcing a known-good baseline provides developers with real-time automated feedback through the design and develop phases so they avoid interrupts that breed delays and ensure that the production environment meets all security and compliance policies when deployed to the cloud.

Read more industry insights by the team from Fugue at their blog.

Share this content on your favorite social network today!

Sign up to receive CSA's latest blogs

This list receives 1-2 emails a month.