Overview
It seemed like just recently simply transforming your monolith into a Cloud-Native application was the way to digitally transform your business and organization into an ever scaling, highly functioning machine. Leveraging DevOps, organizations have continuously delivered new features quickly and reliably. For some, the mastery of DevOps is still an ongoing adventure but for the many that have figured it out, the next level of their transformation within Cloud-Native and DevOps has emerged. Incorporating Cloud-Native security into your existing practices is now becoming the new standard.
The Cloud-Native space is evolving. As with any maturing project, yesterday’s problems become trivial, easier to implement, and solutions accepted as is. When new heights are achieved the playing field resets itself and a new level begins. For more than a decade, organizations that have been trying to solve the Dev vs Ops problem are finally realizing the benefits of DevOps, and the positive impact it is having on their business. Those organizations now find themselves taking on the next challenge of understanding how to secure such a complex and quickly moving target. Successful teams have been shifting towards a SecDevOps model by replicating DevOps’ proven agility and guiding principles but with Security as a top objective.
A New Norm
Without alignment, consistency, and automation across your development, systems, and security teams, businesses will fall behind at most, or risk exposing vulnerabilities at a minimum. Today’s high performing teams move too fast to keep up without the right automation so automating your security seems like the logical next step. We are transcending the days of DevOps and now entering a new norm of SecDevOps, where security moves to the forefront of an already established and successful paradigm.
Systems and software engineers have been pushing the boundaries of a release, with speed and repeatability taking full advantage of a Cloud-Native mindset. All the while, Security Engineers have been working with an existing perimeter-style security model that doesn’t quite meet the needs of a Cloud-Native application. Specifically, within Kubernetes, there are multiple layers along with different components within the same layer that can be at risk. The perimeter-based security model may have added protection between the layers, but maybe not so much within each layer. This then forces us to build a defense-in-depth strategy to work in conjunction with perimeter-based security.
Security Moves Left and to the Front of the Line
Securing applications and your environment isn’t an option. In 2018, one of the more publicly announced Kubernetes breaches occurred at Telsa, Inc. This wasn’t due to a sophisticated social engineering scam or something spectacular you’d see in the movies but because of an unsecured console. 2 years ago “in the cloud” seems like a lifetime ago, and we have collectively gotten better about this type of lapse, but so have hackers.
Aside from a hacker using your stack to mine cryptocurrencies, imagine the access to sensitive data a hacker would gain by running their own process inside of your cluster. When you plug these holes after the fact, the damage is already done and the fallout could be disastrous.
What Policy-as-Code can do for security is what Infrastructure-as-Code did for systems, and what Ci/CD solutions have done for developers. Incorporating security with Policy-as-Code into your existing build and release pipelines creates a shared responsibility model so you can catch these types of misconfigurations during the development cycle, and not after deployment. This is what shifting left is all about.
The Challenge
If security shifts left and requires intra-layer and perimeter-based protections, the line between team responsibility begins to blur. Security teams are not sure if they have to become Kubernetes gurus, while systems engineering teams aren’t sure who needs to make changes to their stack once a risk is exposed. If you’re lucky enough to have internal champions who understand the necessity to collaborate, in the same way, DevOps came about, they can foster a healthy relationship between Dev, Ops, and Sec. For most, the internal struggle to redraw the lines of responsibility isn’t technical, but cultural.
Mirroring the original challenge of DevOps, establishing a common ground, understanding the roles each team must play, and focusing on the end goal is the pathway to success. A top-down approach could be a quick remedy to a rough start, but the most dynamic and high performing teams tend to have concrete directives but are autonomous in devising its execution.
Conclusion
As technology evolves, you and your organization must evolve as well. Fully investing in Cloud-Native requires every aspect of your technology to go all-in, or risk losing the momentum and agility that Cloud-Native a DevOps provides. Security can no longer remain on its own independent island and must be incorporated into the rest of the stack in order to maintain a hardened infrastructure without sacrificing agility.
I’ll leave you with a paraphrased quote, “The well-being of your application and its security, are unattainable unless and until unity is firmly established.”
Comments and Responses