Advertorial The Vectra Masked CISO series gives security leaders a place to expose the biggest issues in security and advise peers on how to overcome them.
Agile is about as buzzy as IT buzzwords get. From a well-meaning effort to enhance software quality and delivery speed, it’s been increasingly mis-sold over the past two decades as a panacea to cure all IT ills. The methodology prioritises autonomy, speed of delivery and a “move fast, fail fast” ethos, which is enough to make any CISO grimace.
As the Agile dogma continues to spread, it’s our job as dispassionate security leaders to push back.
Agent of change or agent of doom?
Agile has its uses. As an iterative approach to software development, it can help teams speed time-to-market and remove roadblocks. It can be particularly effective for small organisations and teams. But it doesn’t scale well, and it doesn’t like complex heterogeneous environments. It certainly won’t turn a failed delivery team into an effective one.
Yet Agile is increasingly being adopted as a technology wide operating model—to drive transformation everywhere, from helpdesks to datacentres. Evangelising CIOs are egged on by a business that doesn’t understand its nuances. It’s said around half of businesses have been using Agile practices for transformation for at least three years. But is it always appropriate?
Just say no
I’ve worked with numerous FTSE 100 CIO teams in the past who say: “We’re going Agile”. They really mean: “We’re autonomous now so we don’t need to interact with security and are opting out of corporate governance.”
Another classic request: “Can you give me a risk acceptance/security exception?” which could more accurately be translated as: “Can you compromise security to help me to meet my Agile delivery objectives?”
An appropriate response from the CISO would be: “Of course, as long as you’re prepared to take full responsibility when it hits the fan.”
Security must be accepted as a mandatory functional requirement of any project. We all know building it in by design at the outset is cheaper, easier, and safer than retrofitting. Yet it’s astonishing how many Agile projects have “security approval” as the last task in the sprint which inevitably causes delays.
Basic regulatory compliance is virtually irrelevant in today’s threat landscape. Instead, we need to test with capable tools and, where appropriate, independent red teams. CISOs need tools that can closely monitor environments, mistakes, and misconfigurations to mitigate risk effectively. The wider business must realise that a product is not complete until all security requirements are met.
The reality is that, as CISOs, we are the conscience of the organisation. For Agile projects to succeed, we may need to slow things down a bit and ask some difficult questions. Sometimes we need to question the dogmatic faith of many CIOs and their teams.
It’s OK to be the bad guy. Say no to Agile when better common-sense approaches exist.
Sponsored by Vectra