Over the past couple of years, a discussion has been brewing in the Security community about the future of its work. On one hand, the need for security is more urgent than ever as all areas of business and personal computing are being impacted by cyber threats. On the other hand, the process of delivering software has changed: We have significantly streamlined the development process by reducing organizational silos through various implementations of a DevOps culture.

So here’s the question: Faced with this changing landscape, how can Security transform the way it does business in order to contribute its full value — without negatively impacting development schedules and operational procedures?Security needs to adjust to the rapid and agile world of the cloud, but the transition doesn’t have to be difficult. The Ops community faced a similar transition when it integrated with Dev, and there’s much that Security can learn from their experience.

To help out, I’d like to share some of the things I’ve learned over the past few years as I witnessed Ops being integrated into Dev, along with some observations on how Security might use these lessons to transition into the DevOps world.

1. Enable: No more culture of “No”

I used to think my mission in Ops was to say “No.” No you can’t do that because it will fail. No you can’t do that because we can’t support it. The truth is, I wanted to say “Yes” a lot of the time, but I’d been taught that my job was to be the adult in the room who would keep the children (developers) from shipping something that would take everything down with it. I thought people had to listen to me.

But robust networks have the ability to route around failures and obstacles. If I failed to deliver what developers wanted, they stopped coming to me and made their own workarounds. They rerouted their requests to someone who would deliver. If operations couldn’t, or wouldn’t, deliver adequate resources, someone with access to a company credit card would create an AWS account and give the developers what they were looking for.

Of course, this ShadowOps approach flew in the face of Ops and Security’s goal of containing costs, ensuring reliability, and preventing or containing security incidents. So, to get back in the loop, I changed the way I worked. Over time I made it my job to be more open and responsive, to work towards acceptable solutions, and to be flexible. This kept me involved in the decision-making process, and enabled me to learn from Dev while contributing some of the best practices I’d learned in Ops.

Getting rid of “No” allowed me become part of the transformation to DevOps. Security can take the same approach, and reap the same benefits.

2. Communicate: Learn to speak the language of Dev and Ops.

Just as Ops bridged the gap with Dev to form DevOps, Security must find a way to close the disconnect between Ops and Security. A territorial stance won’t work, and the Bastard Operator From Hell (BOFH) approach definitely needs to be regarded as a historical artifact! It’s essential to look beyond conventional boundaries with the goal of finding common ground based on an understanding of joint requirements, roles and responsibilities, and aligned objectives.

Through open communication and conscious effort, Ops and Dev teams discovered that they were driving toward the same outcomes. Security can follow the same approach to align itself with Ops, and there’s every reason to expect that the two will find a way of harmonizing their efforts.

3. Change: Don’t fight change; Embrace innovation.

“The cloud is unreliable. There’s no way we’re going to run our production environments in it.” I heard this a lot a few years ago. The people saying this were resisting change: to them, the cloud was just a less reliable virtualization platform than what they already had — if they even had a virtualization platform. Their platform made it faster to deploy new hosts compared to bare metal, but even the process of setting up a single new host could be a time suck. Of course, automating new hosts wasn’t all that important at the time, since setting up a few new hosts at a time was the norm. So the process worked, sort of, even though it was slow and cumbersome. And finally, turnaround time for a new host might have been days or weeks for the requester to get their new VM.

Well — that was the old world, and staying rooted in it instead of embracing innovation was a guaranteed way to become sidelined from participating in the DevOps world.

Today many of us run our production environments in the cloud, and cloud adoption continues to increase. Those of us who put our resistance aside and embraced the cloud got a head start on new trends and methods. Instead of engineering to prevent failure of a single component, for example, we assumed that anything could fail. This led to a change in our systems design approach. We started breaking large services into smaller services spread across more hosts so we could lose pieces and still perform adequately. Our answer to capacity issues wasn’t to do it the old way by purchasing new, larger, and more expensive hardware but to “spin up more hosts,” which necessitated learning how to automate the process of creating many hosts quickly.

It’s no longer a question of whether we will or won’t use the cloud; it’s a question of how much we’ll use it and how effectively. The bigger question is whether Security wants to solve the new issues around security now or be catching up later.

Again, Security can learn from Ops by putting resistance aside and embracing change. This will lead to innovation and bring Security closer to the DevOps way of working.

4. Automate: Be repeatable, be faster, be a multiplier.

“Why automate? It just means we’ll fail faster if we fail.” Sentiments like this were often used as an excuse for not automating processes. People argued that the time spent developing automated processes would take too long to recoup downstream. And while this was never completely true, it could pass for truth in organizations where infrastructure changes moved slowly.

Embracing the cloud, on the other hand, meant that we needed to find ways of moving faster, and automation was key to that. We took our knowledge and turned it into systems that were faster than us, made others faster, and provided repeatable, scalable, quality outcomes. I’ve often found myself building tools to let others do what used to be my job. What used to be my work can now be performed by many people.

The lesson for Security: What used to be one person or one team’s job may not scale effectively, so Security needs to be innovative and find ways of automating processes and enabling others to become involved in the work.

5. Define: Discover what’s right for your organization.

There’s no one way to implement DevOps in an organization. What works for one organization doesn’t mean it will work for another. Some organizations left the fundamental purpose of Operations intact and put greater emphasis on communication and making sure Development and Operations were always in sync with one another. Some changed the role of Operations inside their organization and experimented with new team formations and responsibilities. With this we saw teams that were a hybrid of Operations and software development, providing productized infrastructure to Development for consumption. Others have experimented with embedding an operations engineer into a development team. The operations engineer’s job is to ensure that the team is designing reliable and resilient services and is helping to ensure that the service remains reliable and performant once shipped.

There is no single way for Security teams to adapt to the changes ahead. They need to choose the style that works best for their organization. What works at a small startup may not work in a more mature company.

Parting Thoughts . . .

Given the intense threat landscape that surrounds us, there is an urgent need for Security to become part of the DevOps equation. Again, while there is no one way to transform Security into an equal participant along with Dev and Ops, Security can learn from the transition that Ops made in order to become a partner with Dev.

It’s a complex subject, but it can be demystified, and that’s what I’ll be attempting to do in future posts. Stay tuned for updates.