Cyber UK 2017 Conference – Part 2: Embedding security expertise in the delivery team
In my first blog post about the Cyber UK conference, I talked about the first big idea which resonated with me: that security is everyone’s responsibility and there’s little value in punishing individuals for any failures.
So how do you start to implement this in practice? The second big idea from the conference was that software delivery teams should…
Take cross-functional teams one step further
It is well-established that when trying to deliver software quickly and effectively, there are big advantages to having ‘cross-functional’ or multidisciplinary teams. These are composed of individuals with expertise in architecture, back-end, front-end, design, even operations, all working together as one unit.
Hand-offs between single-function design, build and test teams – common in Waterfall development – introduce bottlenecks which slow everything down, and knowledge gets lost in translation, which increases the risk of delivering the wrong thing. Cross-functional teams avoid this by reducing or eliminating hand-off steps.
But even in organisations that work this way, security often remains as a separate function: a team whose job is to get in the way of the delivery team, slow them down and cause them pain (or so it can seem sometimes). This needs to change if we’re going to get better at delivering secure software quickly and effectively.
As Ahana Datta from the Ministry of Justice said:
“Stop perpetuating the security silo: it’s everybody’s problem”
The tail wagging the dog
A sentiment stated several times at the conference was that currently security is most often driven by accreditation. In the same way that the education system sometimes feels like it’s more about passing exams than actually learning, security can feel like it’s more about satisfying the accreditors than actually making a system more resilient to attack.
And just like an exam, accreditation usually happens right at the end after development work is mostly complete. This encourages a culture of ‘cramming for the exam’. In a panel discussion about security and Agile, Michæl Brunton-Spall, Head of Cybersecurity at the Government Digital Service said that “trying to accredit a system just before it goes live feels like a mistake”.
How might this look different if teams included security experts?
Continuous accreditation
For a start, we’d try to achieve the often-stated but rarely-attained goal of baking secure design into projects from the beginning. We’d make fewer decisions early on which end up getting pushed back on later by accreditors. We’d also manage security risks throughout the process, as we already do for delivery risks: undertaking assurance work little and often, and learning as we go.
Accreditation would then become less painful because we’d have been doing it continuously, not in one big rush at the end. In well-run agile projects, sign-off of completed stories should be a formality: because the client has been involved in the process of designing and delivering it throughout. We think accreditation could become a formality in the same way, because accreditors would be able to see and develop confidence in a long-term, consistent approach.
We left CyberUK brimming with ideas that’ll help our practice and make our work more secure. We’re looking forward to returning next year to share what we find, and to learn more from others tackling the same challenges.