By Virtual Clarity
Many of those who aspire to create a high-performing security function within a company are looking at DevSecOps and what it represents. This is laudable, as the concepts that are represented in DevSecOps mirror many of the successful organisations I’ve experienced, as well as the views of dozens of CSOs that I’ve interviewed since 2010. The CSOs I interviewed often reflected that many of the skills that they valued were not traditional technology skills, but instead skills in critical thinking and collaborative discourse. (Before you toss aside this assertion, bear in mind, they also asserted that technology skill is also needed, just not in isolation)
When a group of us were reviewing very early drafts of “The DevOps Cookbook”, many of us felt something was missing in its approach. It was David Mortman who first put to paper what many felt was that missing piece: culture. DevOps depended upon a culture - one that was seemingly at odds with how things were currently being done and that required buy-in to change. It required an agent of change and long-term commitment to overcome dysfunction within an organisation that may feel counter to existing dogma.
This blog will provide a glimpse of the strategy we take, codify some of the successful approaches we’ve taken and describe the why around the success.
This is by no means an exhaustive nor dictatorially prescriptive list. Not all specific approaches will work for all teams. Culture isn’t something that changes overnight and the techniques you use will need to account for different values, priorities and ways of perceiving. The keys however are the core tenants of a DevOps approach: a culture of broad collaboration, empathy for the “customer” and a willingness to take chances and learn. The results we have seen are quite rewarding and you’ll see how each played out in these stories. These are far from the end-all of approaches, but if they help give you a jump-start in your journey, then this has achieved what we hoped.
We all know the mantra of People, Process, Technology. It is a fantastic model to explain how things should be. I even stack them much like I might order Maslow’s Hierarchy of Needs. People are needed to operate an environment and they are the culture of doing and knowledge. They build processes that do things that reflect how they believe things get done and then they build technology to facilitate the speed of those processes that are designed by these people.
That is wonderful if you are an anthropologist examining how an organisation is. The challenge is that this is rarely how people try to transform their organisations. They (mistakenly) start upside down.
How many of you have watched an organisation declare it’s starting its “DevOps Transformation” and bring in a bunch of technology tools (automation, deployment, cloud)? This is the “technology shall cure all our ills” club. The problem is that, if a process is bad, technology just makes the “bad” faster. If your process for approving user access requires five different approvals from people who have no idea what system or data it exposes, all technology will do is make that uninformed approval faster. Garbage in, garbage out, but at speed. Have you really made anything better? How would you know?
How many of you have seen an organisation build an isolated team in IT and give it the title “DevOps”? This seems to imply that only one team needs to do DevOps, or more likely a naïve notion that it’s all about the automation. How does this help all processes improve? How are other groups improving?
Security teams are no better at fostering DevOps. Too frequently I encounter teams sitting behind walls throwing findings like darts over those walls at groups they barely know. This bothers me more than someone calling their team “DevOps”. I call this the “We Do This, You Do That” club. (By the way, I also see Development teams and Infrastructure teams doing the same). How do your findings relate to what the company is trying to achieve? How do they relate to the company’s tolerance for risk?
You would think that, by now, people would have learned what DevOps is, but instead DevOps has been miscast as purely automation, or more commonly, deployment tooling. Let’s get over this myth. Tooling is an outcome. Even refinement of work is an outcome. Make no mistake, I love the technology solutions that have come out of the DevOps movement – methods and tools that have refined the flow of work, that have increased its speed. But these solutions are the outcome. DevOps is the ongoing journey of getting there. DevOps is about how we work together with a common goal of making things better in a way that makes it possible to focus on the real customers, (blamelessly) identify inefficiencies, collectively learn and make leaps of faith and create rapid and large shifts in how we do things. It’s a mindset, or I would say, a culture change that allows us to get ourselves into a state where we can think in this way.
When we work with an organisation to change their way of operating, we focus on how certain activities can effect change in organisational behavior. We focus in on how to effect being embedded, collaborative, encouraging discourse, learning, growth and refinement. Even when there are often badly broken technology or compliance failures, we use the opportunity to teach security, development, infrastructure and operations teams to work together and learn the cultural workings of DevSecOps.
We first focus on changing how people work and think – their perceptions, understanding, as well as interpersonal and organisational interactions. I call this "Changing People".
Next, we start changing the processes of working – how they communicate, problem solve and learn. This overlaps with changing people and can even overlap with changing the company’s operational processes as people try to refine how they work. I call this "Changing Process".
Lastly we look to apply these techniques to evolve and refine the processes, tools and technology used in our operational work. This can and usually does include changing security controls and operational processes, as well as looking at techniques of refinement. I call this "Changing Technology" – but in reality, it’s about everything that DevSecOps can consume, refine and make better. By this point in the journey, the ideas start flowing and the DevSecOps machine is in motion.
Applying these techniques can be a challenge to organisations new to these concepts. Facilitation can be the difference between muddling through and finding success. Reach out to Virtual Clarity to see how we can act as that facilitator and send you on your journey.