We're hearing a lot about “shifting left” these days in the industry, and like most popular terms the meaning can be hard to pin down, and some of the implications buried. This post will focus on how to shift security and compliance left in cloud computing. These two functions are closely related, but the operational aspect of each is quite different. However, before we get into specifics, it might be helpful to define what we mean by shifting left in general.

What is "Shift Left"?

In every software development lifecycle (SDLC), there are similar steps. They are sometimes described in Agile as:

Requirements → Design → Develop → Test → Deploy → Review

These are a loop that iterates, and in agile methodology, they iterate quickly—perhaps every two or three weeks.

Shifting left is moving a function that used to take place only in later phases to earlier phases. The reason this is attractive is that as we move to the right through the lifecycle, we've committed more resources and time, so making changes becomes more expensive and slows down the process.

In the cases of compliance and security, they're often implemented as a gate during the test phase, and it's common for them to cause rework in design, development, and testing to continue due to problems found during security and compliance testing. If we could shift compliance and security into the design and develop phases, we'd go faster, make better systems, and turn those functions into highway builders rather than toll booth operators. To shift compliance and security left, they need to be automated and fit naturally into the development process.

Perhaps more difficult than the technical aspects of shifting left for security and compliance are the organizational aspects. We need a way to establish trust and confidence between the dev, ops, security, and compliance teams, and that has been a challenge. We believe the best way to accomplish this is to have an explicit and detailed contract between the teams from the development phase forward, and with Fugue, this contract is manifested as a baseline of the environment that all parties agree to, and is then enforced all the way through the SDLC.

The Baseline is the Contract Between Cloud Stakeholders

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, and compliance needs to know that it meets audit and/or regulatory controls. This is nearly impossible to achieve with design documents, after-the-fact scans, and other traditional methods. With Fugue, the baseline can be established in minutes with complete insight for all parties.

Shifting Left on Cloud Compliance

What we mean by cloud compliance is the analysis of whether cloud infrastructure and services are configured in conformance with compliance standards such as PCI, CIS, GDPR, etc. and also with organizational policy. Shifting this left requires having automation that performs the analysis rather than humans, and tooling that is accessible by the development teams in real time. Development teams need to have immediate access to analysis of whether their changes are running afoul of compliance, so that they can course correct if needed as they go. When you are thinking about shifting compliance left, consider a change from an auditing perspective to providing tools.

A good place to start shifting compliance left is the development environments. To do this, you'll need a tool that can scan dev environments for compliance issues and provide a report to the developers on how they're doing. The compliance team will need to select which compliance controls are needed, and configure the tool to give specific feedback on the controls to the developers. Developers move really fast, so it's important that the tool be able to move with them. Daily or weekly scans/reports aren't good enough - the teams need the ability to run the tool themselves on whatever frequency they need. For example, if you need to meet NIST or HIPAA compliance controls, encryption must be used at rest on filesystems. If a developer is creating an Amazon Web Services (AWS) Elastic Block Store (EBS) volume without encryption, they should be able to see right away that they need to turn it on - not wait until the testing phase or a manual audit.

Once a development environment is correct from a compliance standpoint, it can be made into a baseline that can then be enforced throughout the rest of the SDLC.

Shifting Left on Cloud Security

The greatest source of risk in cloud computing is the configuration of cloud services. Of particular interest for security is configuration of services such as AWS Virtual Private Cloud (VPC) network, Amazon S3, AWS Security Groups, and AWS Identity and Access Management (IAM) Roles that defines the virtual perimeter of the cloud environment. Security certainly relies on compliance as a basis for determining what is acceptable and safe, but also often have their own policies to enforce. It's critical that security and compliance are in agreement up front about what configurations are allowed, and what breaks policy, as the development teams need a single source of truth for what they can and cannot do.

Another way that security can shift left is to provide automated tools so that once the system goes into production, security isn't a manual process. We recommend doing this via baselining a known-good configuration, rather than having security run separate tools against production environments, such as "bots" or lambda scripts. By shifting the definition of known-good into the design and development phases, all the stakeholders can come to an agreement early in the process, which will avoid delays and confusion later. If security participates in creating a known-good baseline, and developers can get real time automated feedback through the design and develop phases, both parties are better served. If security remains in the test and deployment/post-deployment phases, all manner of problems arise.

How to Get Started on Shifting Left on Cloud Security and Compliance

With a product like Fugue, you can get started on shifting compliance and security left in under an hour. Schedule a workshop with us, and we can show you a thorough audit of your current security and compliance posture in your development (or other) environments, which will give you the tools and information to bring back to Dev and Ops. You can then give them direct access to the live product, so they can see where they are in violation of policy as they work.