If you are an engineer, you may recognise this scene. Security requirements arrive as an extensive spreadsheet of controls, dropped on your desk for implementation before a system can go live. If you work in security, you may have been the person who sends that spreadsheet. This approach has real consequences for security culture and, ultimately, for security outcomes.
The problem with controls-first security
Security does need requirements. At some point you will need to put controls in place to secure a system. The problem is when those controls become the centre of security rather than the output of a more thoughtful process.
Putting a long list of technical requirements at the core of your security programme disengages nearly everyone who has a stake in the outcome. Business leaders, product owners, project managers, legal teams, compliance, engineers and end users cannot engage directly with a technical controls list. They cannot understand it well enough to make decisions with it.
Engineers, who typically have to implement most of those controls, get buried in the detail. This creates a drag on productivity and contributes to security getting its reputation in some organisations as a chore that slows things down with no visible benefit.
Controls lists are also generic by design. That is not inherently a problem, but it means they miss specific vulnerabilities in particular applications. Design flaws, broken role-based access control models, inadequate monitoring, insecure integrations between systems: all of these can slip through despite a comprehensive controls checklist. Those gaps could mean significant vulnerabilities remain in place even after a thorough compliance exercise.
The result: disengagement from the people who should care most, engineers who cannot make sense of the requirements, and potentially serious gaps in actual coverage.
What changes when you start with risk
The alternative is to begin with business risk.
Every application you build poses a set of risks to its users and operators. If it is compromised, will private customer data be leaked? Will the business lose revenue? Building a picture of those risks is foundational to understanding how to secure the application.
A risk-first view also makes clear where to invest effort. Some applications carry very little risk and do not need much security work. Others carry significant risk and warrant serious attention. A major bank recently deployed two very different applications: a public text-only self-help site and a payments system. The risk profiles are entirely different and so the approaches to securing them should be too.
Starting from risk changes the conversation in three important ways.
First, the business understands why controls are needed. The connection between the security requirement and the business consequence of not having it is visible.
Second, prioritisation becomes simple. Focus on the highest risks first. The order of work is clear and defensible.
Third, decisions about specific requirements, such as allowing developers to debug applications in a non-production environment, become less contentious. The decision-making process is transparent and based on understood risk trade-offs rather than policy edicts.
Controls do not disappear from this picture. They are still how you actually secure the system. But they are no longer the starting point. They become the output of a risk assessment, chosen to address specific, understood threats.
How to get started
Threat modelling is the method that puts this into practice. It has been around for a long time. Adam Shostack, formerly of Microsoft, wrote the definitive book on the subject. The approach translates well to modern cloud-based systems and bespoke applications.
A risk-driven threat modelling approach reduces the time engineers spend wading through security requirements, produces more accurate coverage because it targets your specific system rather than a generic checklist, and builds security culture in the process. The open, collaborative nature of the work means engineers come away with a better understanding of why security matters for the thing they are building.
Threat modelling is how to kick-start a risk-driven approach to security in your business, and how to realise the benefits described here in practice.
Jonny founded Threatplane in 2017. With a background in offensive security, he has spent 15+ years helping organisations across defence, financial services, healthcare, and manufacturing understand and manage their technology risks.
Full bio →