If you're an engineer, have you ever worked in an organisation where security requirements were endless spreadsheets of requirements and controls, dumped on your desk for you to implement before you'd get permission to go live? If you work in security, have you ever been that person who sends through that spreadsheet? This way of working has consequences for security culture and, therefore, security posture.
Now, of course, security does need at some point to have a list of requirements. At some point, you are going to need to put controls and other things in place to secure your system. But what I see today is that those are the centre of security in many organisations, rather than the output.
This is not just a presentation thing - the approach actually acts as a brake on security rather than an accelerator.
Let me explain.
If you're labelling "security" as a long list of technical controls, you disengage your stakeholders. Business leaders, project managers, product owners, users, legal, compliance, engineering teams and anyone else who has a stake in application security cannot directly understand the list, and so they cannot engage with it.
Engineers, who typically have to implement the majority of these controls, get drowned in the detail, and that hampers their productivity. This leads to security getting its reputation in some organisations as a chore that slows engineers down with no discernable benefit.
The controls also tend to be generic by design. This isn't itself a problem but does miss specific vulnerabilities in particular applications. Design flaws, broken RBAC models, inadequate monitoring or insecure integration between systems can all be things missed by this approach. Those gaps could mean you're missing some major vulnerabilities despite the comprehensiveness of your list of controls.
The conclusion is that running security using controls as the driver tends to lead to disinterest from those who ought to care most, engineers who cannot implement any of them and potentially-large gaps in coverage.
At this point, you are thinking that surely security must boil down to a list of requirements. How can we get around this basic fact?
I suggest looking at the problem differently and starting with business risks.
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 money? Building a view of these sorts of risks is crucial to understanding how to secure your applications.
It also makes clear which are worth spending time on: some applications will not carry many risks and so do not need as much time spent to secure them. A major bank I worked with recently implemented two separate applications - a public text-only self-help site giving customers information on how to use their other applications, and a payments system. The risk profiles of these two are entirely different, and therefore so should the approaches to securing them.
By focussing on risk rather than on controls, you change the conversation in a few important ways.
First, the business knows and understands why controls/mitigations are needed and it becomes a little easier to measure the potential cost of not implementing a particular control.
Second, prioritisation is incredibly easy - just look for the highest risks and ensure those are in place first.
Lastly, tweaking based on specific requirements, like developers being able to debug applications in a non-production environment, becomes less contentious because the method of decision-making is now much clearer, transparent and straightforward.
What this means is that all the work we did before with controls has not gone away, far from it. But now, controls are not the focus anymore, risk is.
How, then, can a system or technology stack be secured using a risk-driven approach? Where do we start?
Threat modelling is an approach that has been around for a while; Adam Shostack, former Microsoft, wrote his brilliant book on the subject some years ago. I'll show you how to adopt threat modelling for your applications now and in future to reduce your business risks. Not only that but you'll find it reduces the time your engineers spend on security requirements and its inclusive, open approach also boosts engineering security culture.
Watch this space. I'll be posting in the weeks to come on threat modelling as the way to kick-start a risk-driven approach to security in your business, and how you can gain all the benefits I've described above.
If you have a need to improve application security right now, get in touch.