This is the first part of a new series of weekly posts that will dive into the role of SecDevOps. This series looks into why we need it in our lives, how we may go about implementing this methodology, and real life stories of how SecDevOps can save the Cloud.
The world has changed. I feel it in the water, I feel it in the Earth. I feel it in the packet loss. This is the age of “the Cloud”. We were not without our skeptics, but we knew what was happening. A revolution was on our doorstep, and we wanted it all. We wanted it yesterday.
Configuration management, automation, orchestration, continuous integration and delivery. New concepts were born, titles were given, and philosophies of win floated around the web like confetti after a New Years Eve celebration. We weren’t sure where we were going, but we knew where we didn’t want to be: Configuration drift, tedious provisioning of systems, lack of acceptance and unit tests. Our fears were real, and we sought answers.
DevOps is born. “This is the solution we’ve been searching for,” we proclaimed! As if millions of voices suddenly cried out in terror, and were suddenly silenced… The end is far from nigh. In fact, it has only just begun.
“What is a DevOp?” you may ask. We’ve all heard the jargon, the marketing pitches, but what is it really? The answer, at its core, is quite simple. “DevOps” is not a team, nor is it an organizational role. “DevOps” is a philosophy of collaboration.
“In the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed.” Charles Darwin
For years we sectioned off teams. Developers to the left, Operations to the right. Security teams… where did they hide? Who knows, really? (Reports have been made of Security Engineers haunting the halls of office buildings, lamenting about zero-day exploits and security patch upgrades.) Applications and services were developed and passed over the wall to the Operations team where they did what they could to piece things together and create a working environment. It was how we “got shit done.” Yet, something had always been missing. Where was the bottleneck? How do we optimize our development and deployment pipelines? Things need to be faster! Mush! Mush! Fellow Engineers!
DevOps unite: Infrastructure as code took the community by storm. Various Configuration Management solutions started making themselves available, code was written, and progress was made. But something was still missing — something of incredible value. With all of these new tools at our disposal, teams began pushing out code changes faster than ever before, but something was astray.
Security! Where have you been, where have you gone? Were we foolish enough to believe that these progressive methodologies would save us from something so integral to our success? Why have we forsaken you?
The cloud has left us questioning our surroundings. Who has access, what are the controls, what services are publicly available and which are safely kept behind “locked” doors? What is our risk, and how efficiently was it assessed? If you have yet to ask yourself these questions, it will only be a matter of time before you are one of the Lost.
Suddenly, a new methodology appeared in the distance… SecDevOps. What is it? Where did it come from? Is this just another silly marketing initiative? No, this is natural progression. The move to the Cloud leaves many of us with questions, and the most important one of them being: Without complete ownership of our systems and their supporting environments, how do we protect ourselves?
SecDevOps, or SecOps, is a natural extension of DevOps. The rate of change we see today leaves very little room for Security teams to properly assess risk in our application and infrastructure code. While the mission of our Security colleagues has never been to slow down the process, without bringing them into the fold, we will continue to be at risk of ever-looming threats.
By integrating our Security tool-chains into our DevOps pipeline, we can effectively mitigate our risks and continue our journey towards a secure, automated infrastructure.
In next Wednesday’s follow up post, we will start to explore some of the basic principles of the SecDevOps methodology and how it can be operationalized for fun and profit. Over the course of the series, we will hear from a few notable guests on their experiences, and get their take on the SecDevOps movement and why we need it.