Learning how to let go Learning how to let go Learning how to let go

In September, we took our daughter to university to start her first year: a day of mixed emotions. It was the day she was embarking on a journey of discovery, freedom and fulfilment of aspirations. She would face adversity, risks and disappointment, but I hoped that the knowledge and principles we had equipped her with would help her navigate challenges, make the right choices, and learn from her mistakes. Although I was proud she 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 current state of DevSecOps in their organization and how it could be improved. It struck me that there are many similarities between the journey I was taking as a father and the journey a corporate security organisation has to take to enable and empower DevSecOps to reach its true potential.

I moved into cybersecurity from software development 30 years ago — developing security/crypto middleware was my specialisation, and this led to a foray into secure software development, application security architecture and secure SDLCs (Systems Development Life Cycle). 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 activities. It set policies, developed 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.

The industry has since progressed, and nowadays everyone understands the importance of agility and the competitive advantage of the ability to react swiftly to rapidly-evolving market needs. 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? Admittedly, it should not slow down business, but it also should not be sacrificed in the name of a faster go-to-market. Has the way we deliver security within the enterprise aligned with, supported and empowered this new agile paradigm?

Indisputably, we have come a long way. We, security professionals, have contributed to securing DevOps CI/CD (Continuous Integration/Continuous Delivery-Deployment) pipelines by providing standards on system and network security and IAM (Identity and Access Management), 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 like micro-segmentation. We have spearheaded the automation of application security testing via SAST (Static Application Security Testing), SCA (Software Composition Analysis) and DAST (Dynamic Application Security Testing) tools.

However, despite relinquishing—through automation—our control over less challenging security tasks, there may be scope for greater progress. What about relinquishing our sole control over higher cognitive security functions by enabling DevSecOps to perform them without needing to constantly seek our approval? In that domain, we might have not done enough.

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 (Single Points of Contact), there is room for improvement. Given the worldwide skill shortages in cybersecurity, if we, security professionals, retain sole control over decisions, we will remain 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.

We can do this by documenting our specialist domain knowledge and making it available in comprehensive, detailed and concise security guardrails. This can be accomplished through drawing up security policies, standards, architecture principles, design patterns, baselines, blueprints, guidelines and code frameworks that agile teams can use to make informed decisions, without security department approval, following agreed-upon decision trees that security professionals will also provide.

Once we arm DevOps teams with the right tools and appropriate knowledge, we should step back and trust them to deliver. We should, of course, ensure the guardrails are updated to reflect the evolving threat landscape, technology, industry best practices and organisational cyber risk appetite. We should follow a ‘laissez-faire’ approach that allows DevOps teams to continue on their journeys, while we manage by exception and assume an advisory role.
Does this second line function role for the security organisation in DevSecOps require a leap of faith? Not really, because we already have the necessary tools: we set the parameters with the guardrails, and we can complete our governance function with continuous security control monitoring, an inextricable part of DevSecOps. With this approach, we can move security governance closer to DevSecOps, and implement security-by-design even further. If we do our job correctly, we can enable the organisation to achieve unprecedented time-to-value.

Admittedly, I sometimes have second thoughts about whether we are ready for this shift. However, upon further reflection, I realise it is the “old-school” me that does not want to let go. Nevertheless, I recognise the need to empower others while taking a step back into the role of an out-of-sight but omnipresent trusted advisor. I hope this cultural evolution will make me not only a better security professional but also a more understanding and supportive father.