What does it take to shift-left on security? What are the pros, cons, and tradeoffs associated with building automated security into your continuous delivery infrastructure?
We’ll take a look at these questions and more in this post. Some of the answers may surprise you.
Security as a Fundamental Necessity
Security is not optional—It is an absolute necessity. Deploying software without adequate security is as dangerous (and as self-destructive) as leaving the front door of your business unlocked all night, with a full cash drawer lying on the counter, and visible from the street. With a traditional brick-and-mortar store, security can focus on the relatively straightforward process of controlling physical access. For software (and in particular, for Internet-based applications), security must focus on the much more complex issues arising from multiple channels of often highly interactive electronic access.
Security at the Basic Level
Traditionally, software security has combined elements of physical access control, automation, and operator-in-attendance live monitoring. While it may not be possible (or even desirable) to completely eliminate physical security measures or live monitoring/response, the emphasis in security has fallen increasingly on automation, and will undoubtedly continue to do so. Commercial and private software users are aware of the need for such automated security basics as antivirus software and firewall protection.
But this level of automation, while a necessity, is limited in its effectiveness. All too often, it is treated as an afterthought—a set of tacked-on, post-deployment measures which add generic (or at best, somewhat customized) security capabilities. It is likely to be most effective against obvious and easily countered threats, and even then, it may require a relatively high degree of live operator attention in order to be truly effective. Security of this type is automated, but it has not been shifted left into the fundamental DevOps infrastructure.
Why You Need to Shift Left
When you shift-left on security, you effectively move security automation up to a new level by integrating it into your continuous delivery chain. Why is it important to do this?
Increased Overall Security
The single most important reason for moving to full shift-left automation is that it increases overall security. The process of integrating security into your continuous delivery infrastructure is itself one of your best and most basic guarantees that it will reflect your system’s security needs, and that it will closely follow your development and deployment process.
It’s Always There
Fully integrated security is always there. A hostile intruder cannot easily identify and neutralize its components, and it cannot easily be turned off (either through accident, neglect, or malicious intent).
When security is fully shift-left, it automatically moves from being a later, post-development or post-deployment step to being a natural part of both development and deployment. Since it is built into your infrastructure, there is effectively no way to treat it as an afterthought, or to relegate it to a “to do if we have time” list.
True shift-left security is intrinsically proactive, rather than reactive. It provides an automated framework for building security into both application and infrastructure code, and detecting vulnerabilities before deployment, rather than after they become a problem.
Making the Shift
How do you make the move from security as an added feature to security as an intrinsic part of your workflow?
Shifting the Culture
The first and perhaps most important phase of the shift is cultural. Your organization must move from thinking of security as a set of added features and processes to seeing it as a fundamental part of infrastructure. Security is infrastructure, and like all DevOps infrastructure, security is code. In practice, this means that you integrate the code that manages security with your infrastructure code, at all points where it is important to address security issues.
What and Where
But how do you determine the what and where of integrated shift-left security? You can start by defining the specific security issues which affect your software and your organization (along with the general security problems which apply to all contemporary Internet-based applications). A well-thought-out set of security-oriented user stories can define your system’s potential security problems in terms of specific kinds of behavior which your system may encounter.
Planning the Shift
After you have defined the security issues which you are likely to face, you can set out an overall plan for integrating the appropriate security measures into your infrastructure. As you do this, it is important to recognize that infrastructure architecture is also software architecture, and to look at delivery chain architecture in the same way that you would look at code architecture. This means that the code that implements security is not just added to your infrastructure. It is, rather, built into your delivery chain at the level of architecture.
Security as Architecture
Where do you build it into that architecture? For each organization and each major application, of course, the answer to that question will be somewhat different. In general, however, security should be built into infrastructure at all points where there is reason to look or test for security issues, and to enforce security policies. Infrastructure-level security code should be responsible for managing both security testing and policy enforcement.
In addition, there are some key points in a continuous delivery system’s architecture where specific kinds of automated security operations are likely to be important:
- As part of software testing during the development-and-test stages. This includes testing security features built into the code, of course, but much more to the point, it includes the impact that any other changes may have on security.
- As part of initial test deployment (A/B, canary, etc.)—At this point, you need to test the effect that any code or infrastructure changes may have on security, and on compliance with formal security standards.
- During post-deployment monitoring. Not surprisingly, even in a full shift-left environment, much of the security focus must, by necessity, continue after deployment. It is, after all, when the software is live that you can expect active security breaches.
Post-Deployment is Crucial
It is important to note, however, that shift-left post-deployment security is not an add-on. It should be based on a comprehensive system that combines in-depth monitoring with highly configurable enforcement of security policies, as well as integration with analytical and alerting services. Ideally, it should integrate with the continuous integration chain and other elements of the DevOps infrastructure to provide a comprehensive security infrastructure.
Comprehensive Shift-Left Security as a Service
There are significant reasons for preferring a comprehensive shift-left security system, rather than attempting to manually integrate a largely unrelated set of security tools. Convenience, of course, is a major factor—You and your DevOps team have much better things to do than reinvent the wheel.
But even beyond convenience, a comprehensive shift-left security system is much more likely to provide you with optimum coverage. When you hand-assemble a security system, you are all too likely to miss at least key points of vulnerability. A comprehensive security system designed and maintained by experienced, specialized development and support staff is far more likely to cover even the most obscure vulnerabilities.
Shifting security left into your continuous integration chain doesn’t have to be difficult. It does require good analysis and planning, as well as a clear understanding of the issues involved. That said, particularly with the help of a high-quality, comprehensive security system that can be integrated across your continuous delivery process, it is an effort that will pay for itself many, many times over.
Let us help your organization’s security shift left. Contact us for an evaluation for your organization today!
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Securing Containers on Oracle Cloud InfrastructureRead the Blog
Docker Security Best Practices: 2018 Wrap-UpRead the Blog
Open Source Cloud Discovery Tool for Visibility Into Cloud Native PlatformsRead the Blog
The Evolution of Container Security, 2013-TodayRead the Blog
Why Automation is the Crucial Ingredient in Microservices SecurityRead the Blog