The Road Goes Ever On And On: Our Journey To And Through Secure Development
The journey to secure development isn’t a sprint – it’s an endless marathon, a Red Queen’s Race where we often find ourselves needing to advance just to stay in the same place. Over the last seven years I’ve been at the heart of Liberty Mutual’s journey, and this talk is about how we’re running our race.
This journey began when we implemented an improved online billing system and found that working with the security team to understand how to implement it safely took us a lot longer than we’d thought it would. Security teams had limited space in their calendars, and when we finally got an hour to speak with them we spent half the time explaining our problem. Then we’d run out of time in the meeting, and by the time we got another slot to meet with them we had to start over from scratch again.
In order to try to solve this and make things easier for everyone we began using threat modelling – ensuring that the development teams did the work in advance that let them speak intelligently to the security teams about the important aspects of their projects, focusing on the relevant aspects and picking off the low-hanging fruit in advance.
This led to our secure development program, where we made threat modelling a required part of our design phases, improved developer education through mitigation-focused security training, concentrated our institutional knowledge in a Secure Development Kit and pushed for every team to have a Security Champion. For a while things seemed good.
Then the ground moved under our feet. Agile transformations and feature-based development took away the “design phase” as a concept, while devops and continuous delivery forced us to rethink how we handled security and development. Teams needed to own their security, in a way that they never had before. To meet this challenge we had to change.
- We evolved our threat modelling practices to ensure that they were feature and process driven with an emphasis on creating tests to prove out mitigations in the pipeline.
- We used exploratory testing practices to both find security defects and to educate developers on where they could be found.
- We shifted from Security Champions to Security Guilds – cross-team structures that allowed business ownership of security.
- We focused on building deployment pipelines with automated security as defense in depth – not just SAST or DAST but a full toolkit to give us a solid foundation to stand on.
- We replaced our centralised Secure Development Kit with a Secure Development Community of Practice – living institutional knowledge, with an emphasis on getting people involved.
- And we made sure to hang on tight to what was still good – mitigation-focused training and a solid core of people enthusiastic about security challenges.
This is a race that we’re still running. There is no pot of gold at the end of the rainbow, and we know that the world will change us as much as we change it. But we understand that there’s value in the race, and in helping fellow runners over the hurdles on the way. And we know that the only way to stay good is to keep on striving for perfect.