On cybersecurity and IT teams of the future, we’ll all be SREs

Devops is perhaps the most important innovation in the IT and security sectors since the invention of the personal computer. The philosophy is so foreign though, compared to what IT and security staffs have traditionally done, that many do not understand the implications. It is tough for them, and their management chains, to fully wrap their heads around the potential impact to their organizations in the future. However, now is the time to embrace the idea not just for IT administration but for InfoSec too. Inserting InfoSec within the Devops ideology could be the key to building more sustainable and effective security teams. In other words, security team members need to become site reliability engineers alongside their IT peers.

What is devops?

I speak with a lot of network defenders all over the world. Most say they have adopted the devops philosophy. However, when I ask them about the specific projects they are working on, it’s clear most do not understand what the devops philosophy really means. Most default to believing that deploying applications to the cloud means they are doing devops. That can’t be further from the truth.

I view devops as a philosophy. It’s a movement to reduce the technical inefficiencies inherent in managing a system of systems that runs and grows over time. In other words, devops is the idea that we should automate the tasks inherent in deploying, securing, maintaining and end-of-lifing the processes that the IT and InfoSec staffs have been doing manually since the beginning of the digital age. The purpose is to deliver applications and support services at a much higher velocity. With traditional software development processes and standard InfoSec and IT tool maintenance updates, it sometimes takes weeks, months and even years for organizations to roll out a new application, update an old application, install a patch to a machine, or add enhanced prevention controls derived from new intelligence. The devops mantra is to roll out 10 deployments/changes a day. That sounds good when you say it fast, but it is tough to find the edges of this new philosophy when you start to think about the implications.

Before the emergence of devops, or if I could be so bold as to call it DevSecOps, enterprise organizations maintained separate teams for development, operations and information security. This is still the case at most organizations today, which often results in inconsistency and siloed work streams.  However, now, because the DevSecOps philosophy requires tighter integration among all these teams, a new breed of administrator is emerging as the glue that holds everything together to support this: the site reliability engineer, otherwise known as the SRE.  

What exactly is a site reliability engineer?

The SRE role of today combines the skills of the developer responsible for writing applications and the skills that operations engineers use to deploy those applications. The SRE moves an application from proof of concept, to quality control, and then to deployment – automating that entire process and giving it consistency. The SRE role originated with Google in 2004, when leadership was wrestling with how to scale the search engine they had developed. They handed the network management to developers, a counterintuitive choice. When the team received the assignment, they automated everything, helping Google scale its entire operation.

Forward-thinking CIOs, CSOs and CISOs who build with SREs in mind will thrive

Organizations that adopt the devsecops model will outperform their competitors that don’t. I believe the business landscape has about a five- to ten-year window to get on board with this new idea and build its own SRE organizations.

Here’s the bottom line: As every organization races to the cloud, devsecops becomes an opportunity. You’re writing new code anyway. Why continue deploying code and installing fixes the way we did it when the internet was young? Why not use this time to completely rethink and modernize your approach, and take the lead from a successful organization like Google? I believe that if you don’t, your competition will beat you to the punch within the next five years. If they get there before you do, they will dominate in the marketplace because you will not be able to keep up with them. But if you get there first, you can place your organization as the frontrunner. You could potentially be dominating your competition in the marketplace, and that is a great position to be in. I believe that, in the successful organization of the future, we will all be SREs.