You might be tasked with enhancing security at your organisation. Communicating this effectively and ensuring teams build sufficiently secure software is challenging. Some may suggest a policing approach, but this is neither realistic nor sustainable. There are many many engineers and so few security experts.
When faced with this challenge, I instead chose to build a rising tide that would encourage security by design and default.
In this article I'll be talking about the three steps we took to get our engineers able to deliver on this through education, Paved Paths and risk assessments.
Elevating Security Knowledge
To have a baseline standard of security in all our products, our engineers needed to understand security better. Through engineer self-assessments, we could see that many of our engineers had gaps in security knowledge. With this in mind, we provided both general and company specific training.
Training for all
Self-assessment data made it easy to make a case to budget to hire an external trainer to deliver training. Our selected trainer delivered two days of modules for our engineers to attend. We allowed our engineers to select what modules were right for them, by aligning the training to information from the self assessment. Almost every engineer attended the training, with some wanting to attend all modules.
Insights from within
We invited our internal experts on external risk and compliance to walk us through security and compliance risks. They first spent time with the engineering security team, teaching us through content, chat and questions. The engineering security team worked as advisors and editors, honing the material into key points that could be delivered and consumed by all teams.
Talking risk and consequences
We backed up this training with stories from the news where companies had been hacked.
We encouraged discussion and digging into how these serious issues happened. Sometimes scary stories are useful to motivate, if they are honestly told.
Our key move was to treat security as a platform that could be provided to our engineers. And through that provide a default Paved Path, that when followed would result in good-enough security 'by default'.
A modern name for this might be an Internal Developer platform. The visible parts were a guide that gave our engineers advice, and provided, like a Highway Code, a clear set of MUSTs and SHOULDs for all our projects.
The guide was more than just words. It presented a Paved Path for teams to use to deliver. We had identified a practice to support. Some of these were industry standards, or operated from well known third party libraries. Others used internal tools or standards built by engineers or the infrastructure platform team.
This collection of technologies and practices standardised how we solved the most critical risks to our systems, paving the path to production, and providing a default way to deliver securely.
Tailored Security: Advanced Paved Paths for Complex Challenges
Some of our teams had complex data security needs. They handled and held data that demanded additional attention and security. Our default Paved Path could not serve these needs. Raising our standard expectations would require additional work from all teams. It would be an over-reaction: at best it would waste time and effort; worst case, we would lose engineers' support by over-demanding.
We chose to be selective. To present a second, more demanding Paved Path, and help teams choose a good path for their needs. Rather than raising every boat, we could build a lock to raise selected boats up to the level needed.
Again we used our security guide to provide this. In it we helped present a guide to help them grade their data and select a path; a second set of directives and more practices that provided suitable controls.
Security by design.
Our higher risk route pushed our teams to consider security careful in the design phases, running threat modelling sessions as they built their software. It also added additional constraints and expectations to data storage and 3rd party library management; as well as expecting a higher level of security as standard.
Impact
Teams made better choices, and prioritised security outcomes much better. The estate got smaller, less flabby and more secure in many ways. Old code got killed or revamped. Higher risk data was separated and held to higher standards. Sensitive data on the move though our systems was better controlled. Staff cared more about security all the way to the Board.
A quote from an engineer sums up the success:
"Everyone knows where to go and engineers are empowered to use secure by design in everyday work"
The journey to enhancing security within an organisation is about more than just policing, policies and procedures; it's about creating an environment where security is ingrained in the culture. When you want to have big impact, build a system that will support your engineers to make great decisions when you are not there.
When we build a platform that will support every engineer, we build a resilient organisation where security is a shared responsibility, and every engineer is equipped to make informed, secure decisions.
You can read more about the STAN - our Secure by default guide - in a previous blog post.
