Scaling Security

The Scene

You’re a new CISO at a rapidly scaling technology company with 50 engineers, looking to double engineering within 12 months. The company is trying to maintain its agility and rapid delivery, but you’re hitting a point where the security cowboy nature has presented too great a risk to be ignored any longer.

Tasked with imporving the security posture across the board, you’re worried that the developers and product owners don’t care about security. You haven’t quite won an S3 bucket negligence award but after reviewing the AWS setup, you’re worried that it’s a matter of when not if.

What options do you have to instill good practice throughout the company in a way that is both effective and cost efficient? How can you shift security left and deliver secure software without compromising velocity?

Option 1 - Grow the Security Team

The development teams are using scrum, they have the ceremonies you would expect, e.g. daily standups, fortnightly showcases and retrospectives. If you grow the team you can have security personnel attending these ceremonies, looking to bring a security point of view to the proceedings. You can drop tickets into Jira, push for them to get prioritised, and see some progress being made.

However, your goals are orthogonal to that of the product owner and the development team, they’re trying to maximise reward, you’re trying to minimise risk. You can look to source Security Champions as a scaling mechanism, have them be the voice and face of the security movement, and this will make some headway towards your goal.

But there is an upper bound to the effectiveness of this approach, you are reliant on finding motivated employees to carry your message, when push comes to shove security will often lose out in a battle for prioritisation. In this model, doing things securely is not the default modus operandi, it’s extra effort, time and money. Security mandate is something that comes down from on high, from people who have very little skin in the game as the developer sees it.

How can we change the game such that security is the default? Make it the simplest, easiest and fastest choice?

Option 2 - Add Development Capability To Security

Google scaled their operations through SRE, you must do the same with security. Software is the force multiplier of the 21st century. Hyperscaling startups, for all their faults, show how you can have huge impact per person through code. With this leverage you can scale security in a more effective and more cost efficient way than growing the security team with non-coders ever could.

DevSecOps Pipelines

DevSecOps is the natural evolution of DevOps, but unfortunately the effort of adding security tools to pipelines is non-zero, which means it falls into the good old fashioned priority queue. CircleCI has a great template with orbs, making it trivially easy for people to add extra capabilities to their pipelines. The security team can bring reusable templates to the build pipelines across the organisation by doing the complex work up front, reducing the barrier to entry for development teams and expediting adoption.

Another benefit is giving the security a way of uniformly building standards across the whole swathe of development. As a new standard are mint, you can add a capability to warn development teams that they’re in breach, and actually cause failed builds if the concerns are not addressed in time. By building in a rapid and consistent feedback loop into the process, better security behaviours will result.

Improved Base Infrastructure

Infrastructure in the cloud is a composition of foundational components, and for better or worse the default posture on most resources is open. Historically, building secure cloud applications was something that took significant expertise and the paying of something akin to a blood-debt to unlock the arcanery of YAML templating. However, we now have the tools to enable secure by default and to empower all developers to deliver fit for purpose architectures.

Through constructing a repository of secure by default components, the security team can change the underlying foundation of all architectures. By enabling the delivery teams to frictionlessly adopt secure components, the security posture will organically improve as the delivery teams are better served by the provided templates.

The Decision

Given a blank slate, both options will be beneficial to an organisation. By adopting option 1 you will bring greater security awareness and will hopefully build up champions within the development team to drive secure practices. However, this approach maintains silos and can potentially result in high levels of animosity between development and security.

By adopting option 2 along with the advocacy portion of option 1, you have a solution where security outputs drive engineering outcomes, which drive security outcomes. This flow provides a more consistent adoption curve and promotes sybmiosis over silos.