Intersection of pink, blue and white lines on blue background

Secure DevOps: Learning how to let go

Secure DevOps: Learning how to let go

Secure DevOps: Learning how to let go

Dimitrios Petropoulos | Director,

The rainy autumn day, I drove my eldest to university to start his freshman year was one of mixed emotions. It was the day he was coming of age, spreading his wings and embarking on a journey of discovery, freedom and fulfillment of aspirations. He would face adversities, risks and disappointments, but I hoped that the education, knowledge and tools I had equipped him with would help him navigate challenges and learn from his mistakes. Although I was happy and proud he was taking the big step, like every parent, I was also worried.

The following day I was back at work, discussing with a client the introduction of Secure DevOps in their organization, a target operating model and the requirements for the characteristics of a ‘to-be’ state. And then it struck me: there are many similarities and parallels between the journey I was taking as a father and the journey a corporate security organization has to take to enable and empower Secure DevOps to reach its true potential.

I moved into cybersecurity from software development 30 years ago — developing security/crypto middleware was my thing, and this then led to secure software development, application security architecture and secure SDLCs. Back then, and until the not-too-distant past, the waterfall model was king. Because security knowledge was in its infancy in the development and operations communities, the Information Security Department was the gatekeeper of all security-related software development and operations activities. It set the policies, developed the standards and participated in every stage gate discussion, determining if the stage deliverables had met the necessary security objectives before the next stage could commence.

This led to resentment from the rest of the organization, as we were seen as police officers, always saying ‘no’, delaying project go-live dates and seemingly holding back the business. In our eyes, however, we were the last bastion, protecting the realm from unfathomable risks. Back then, we security professionals claimed sole security knowledge, and the development and operations organizations had to be guided, directed and governed.

The industry has progressed, thankfully, and nowadays, everyone understands the importance of agility and the competitive advantage brought by the ability to react to rapidly-evolving market needs swiftly. DevOps is no longer seen as a fad, as it has ushered the much-needed abolition of silos between development and operations, continuously delivering tangible results in an era that demands doing business at the speed of thought. But what about security? It should not slow down business, but it also should not be sacrificed entirely in the name of a faster go-to-market. Has the way we deliver security within the enterprise aligned, supported and empowered this new paradigm?

Indisputably, we have come a long way. We have contributed to securing DevOps CI/CD pipelines by providing standards on system and network security and IAM, all of which have helped secure workflows, toolchains and supportive environments. We have assisted in the automation of mundane security controls and their integration into CD pipelines such as infrastructure vulnerability scanning, platform security hardening and automatically deploying controls e.g., micro-segmentation. We have assisted in the automation of application security testing via SAST, SCA and DAST tools (a step in the right direction but not a panacea1). Despite us relinquishing our control, via automation, over the less challenging security tasks, have we done enough? What about relinquishing our sole control over higher cognitive security functions by enabling DevSecOps to perform them without our constant omnipresence? There, we just might be found wanting.

Although we have trained our developers in secure code development practices and even (begrudgingly) championed embedding security champions in agile teams to act as security SPOCs, there is room for improvement. Given the worldwide skill shortages in cybersecurity, retaining detailed decision control will only reiterate the perception we are the bottleneck. Instead, we should be delegating more security decisions, including security design (where the human intellect still performs functions that machines cannot match, at least for now) to the empowered DevSecOps teams to enable faster time-to-market.

How can we do that? By documenting our specialist domain knowledge and making it available in comprehensive, detailed and concise security guardrails. This can be accomplished through security policies, standards, architecture principles, design patterns, baselines, blueprints and guidelines that the teams can use to make informed decisions, without security department approval, following decision trees that we will also provide. Once we arm them with the right tools and appropriate knowledge, then we should step back and trust them to deliver. We should only ensure the guardrails are updated to reflect the evolving threat landscape, technology, industry best practices and organizational cyber risk appetite. Otherwise, we should follow a ‘laissez-faire’ approach that allows DevOps teams to continue on their journeys, while we manage by exception assuming an advisory role.

Does this 2nd line function role for the security organization in DevSecOps require a leap of faith? Not really, because we already have the necessary tools: we set the strategy with the guardrails, and we’ll complete our governance function with Continuous Monitoring, an inextricable part of DevSecOps. With this approach, we can move security governance closer to DevSecOps, further refining the granularity at which we can design and embed ‘built-in’ security. If we do our job correctly, it should enable the organization to achieve unprecedented time-to-value.

Admittedly, I sometimes have second thoughts about this, but upon reflection, I realize it’s the ‘old-school’ me that doesn’t want to let go. However, I have recognized the need to empower others while taking a step back into the role of an always-there, benevolent, trusted advisor. I hope this transition will make me not only a better security professional but also a more understanding and supportive father.


1 Not only are SAST/DAST/SCA incapable of identifying architectural/design flaws, but due to Rice’s Theorem (semantic properties of a non-trivial piece of code are undecidable) and a generalisation of Turing’s Halting Problem, it has been proven they cannot identify all vulnerabilities.