Have you read “The Phoenix Project“? If you haven’t, you should! It mirrors the method used by Goldratt in “The Goal,” first published in 1984. It’s a story, not a textbook. The Phoenix Project will help you understand the problems that arise in the way software is being built and deployed today and the ways that DevOps can help. In it, we are introduced to the Three Ways of DevOps. You can also read about them in Gene Kim’s blog post. I think they are extremely powerful and foundational concepts.
As a security professional and software development practitioner, I wanted to marry the two worlds into something that would make sense to security, resonate with developers and stay true to DevOps. The result is the Three Ways of DevSecOps. I know, I know … Why do we need to say DevSecOps? I’ll just point you at a great article by John Willis that will hopefully put that objection to rest.
I will break this out over three posts, so keep coming back and I hope that by the end I will have helped you be more successful in your AppSec program in general and in your DevSecOps programs in particular. Agree or disagree, I would love to discuss this with you on Twitter @PeteChestna. Does this resonate with you? Where did I get it wrong? Let me hear from you.
The First Way of DevSecOps: Flow
The first way, initially known as Systems Thinking, is now being called Flow in the recently released “Beyond The Phoenix Project” audio series. Think of it simply as the value stream between idea and customer and the performance of the system/people that create the value in that stream. In a company that values the security of its applications, security must be a part that value stream.
To make DevSecOps a reality, there are two things that are absolutely mandatory to getting the best results. Without these, everything is a struggle. With these, progress becomes easier. As with most problems, application security is like Soylent Green—it’s people!
You must start with the relationships between security and development teams. If they don’t know each other, why not? Are you not playing for the same team (company), after all? It’s likely that their goals are not in alignment. How would you know unless you discuss it? It’s easy to play us versus them when they are just a department or silo. “Those developers are just doing it wrong.” “Security keeps slowing us down”—these are the kinds of statements that have been said for decades. How’s that working for us? If we get on a first-name basis, cooperation becomes easier. Our enemies are on the outside. Let’s start acting like it.
The second ingredient is mutual accountability. This is the gold standard. It is the one thing that every AppSec professional needs regardless of development methodology. See my previous post about it here. If you get this done right, you are more than halfway there. Most organizations struggle with this. I was at a BSides security conference last year and one of the OWASP chapter leads stood up and stated: “We will hold the developers accountable!” He was very aggressive. It felt like one of those “go grab your pitchfork” moments. This is exactly the problem with how we treat each other. How does he expect the development teams to react to his aggressiveness? Does he care? I can’t answer those questions, but I’m sure you know what will happen: Compliance. Compliance sucks. I want more. Fortunately, my talk was after his. When I started my talk, I suggested that it would be a much better world if we could convince the developers to take accountability. They wrote it, why shouldn’t they feel accountable? Similarly at this past RSA, I was in a meeting with one of our best customers. I have known the CISO for many years and I have a great deal of respect for him. He was talking about the CI/CD pipeline and how he was going to enforce the policy on the teams. I was stunned. I stopped the conversation and suggested that it was the wrong message and the wrong goal. What if he could get the developers to embrace his security policy? Wouldn’t that be better? Let’s turn from push to pull. Would you rather change enforced upon you or would you rather be given the chance to embrace it? We all need to reboot our attitudes. Words matter here.
The way to accomplish mutual accountability is simple in concept: Leadership must be the example. The C-levels in charge of security (CISO) and development (CIO) must commit to application security as a measured individual goal to the CEO. This must include frequent, regular, transparent reporting directly to the CEO. Too many times I have seen security teams try to win hearts and minds one team at a time. They are working at the bottom of the pyramid where there are hundreds or thousands instead of the pointy end where there are only two. It’s time to rethink our tactics. Either security is important or it isn’t. If it’s not, then there are a ton of companies looking to put you to better use. If it is, then let’s put our paycheck where our mouth is. Believe me, when the CEO starts asking questions, the CISO and CIO will do most of the work for you. They will ask you for data broken down by their direct reports and so on and so on. Behavior and culture will change. It will take time. Be patient but determined!
Stay tuned for the next installment of my Three Ways of DevSecOps series, “The Second Way: Amplify Feedback Loops!”