Security teams and devs don’t get along. The piles of tickets for vulnerabilities compete with business needs and often end up ignored. Does this sound familiar?
It’s a mantra that we, as an industry, sometimes just accept. But, luckily, there’s a better way of doing things.
Let’s enable and empower businesses rather than block them. Can we be friends and make security assurance fun? Of course!
Find out how from this insightful conversation between long-time Chaleit client and collaborator Troy Cunningham, Head of Cyber Security Compliance at Criteo, and Ankit Prateek, VP of Technical Services at Chaleit.
Troy: “What’s important for security is not always important for application owners.”
I create an environment where you know something about the application before running the tests. That knowledge informs decisions about which problems are more important. The nuance is that discovering and defining a problem is a lot of work. Therefore, defining risks and deciding how to manage them takes a lot of effort.
Everybody in the security field is trying to identify and mitigate security gaps as much as possible. The problem is that we often compete with other business priorities and needs. What’s important for security is not always important for application owners.
That’s why I ask: How do I give this security assurance consultancy without getting in the way? I recognise an application owner has other priorities. I want to tell them what I believe the security problems are and offer a set of security priorities in a context where they can prioritise and decide how to deal with them.
For that to happen, you need a risk management framework that collaborates across the whole business. Everybody must speak the same language. When you do that, you create a separate channel for security. And this is what’s different from how things are usually done.
Security assurance, as I’m approaching it, is identifying the things that a business should worry about and deprioritising the things that aren't as important.
We’re constantly saying that security must get in the chain and shift left. That’s hard to do. You can do it regarding code and automated testing, let’s say. But for us, it’s not always possible. That’s why threat modelling is so tough.
Businesses are not really looking for a set of vulnerabilities to fix. They don’t need a long list of problems. They want to know what will happen. What should they fear? This is what security should be doing: telling people what they should worry about.
Security assurance, as I’m approaching it, is identifying the things that a business should worry about and deprioritising the things that aren’t as important.
Ankit: “Security as a shared responsibility”
The transparency of the process motivated me. Product owners and security teams can meet somewhere in the middle without getting in each other’s way.
Let’s say you want to create a risk register. Typically, you have a group call with multiple product and business owners and start a brainstorming session to identify risks. This goes on until everyone is exhausted, and the process fades away. Nothing happens.
But using Troy’s approach, everything is connected, and it works for everyone, from the product owners and the internal security team to an external security auditor as well.
Security becomes a shared responsibility. With this model, it wasn’t difficult to convince and work with a product owner – somebody who’s not supposed to do security. They would ask: why? They were busy adding features and meeting the business requirements, so why bother with this? Here’s the magic: We already had all the answers. You went to the Confluence pages, and every single thing was documented.
Documentation is not useless or boring. When done right, it makes it super easy to connect the dots.
This process allows me to tell application owners: “I’m not here to criticise your work and say there’s no security, validation, and all that. You’ve done a decent job. Now, let’s talk about security.”
To do this, you must get the fundamentals right. People think documentation is boring. Anybody who comes from a traditional pen test background knows that techies hate writing reports. Architecture diagrams – who takes pride in that? No one.
Documentation is not useless or boring. When done right, it makes it super easy to connect the dots.
Ankit: “I felt proud to see security teams and devs get along.”
I don’t just say to clients on day one: “Let’s do security 101.” I want us to understand each other and where we are coming from. It’s important to let them know we are in this together so they don’t get burdened. The fun part is that product owners have told me we should do this more often. “Can we get on a call every week?” Getting on the first call was super difficult, but it was shared responsibility from there.
This made me super happy because security teams and devs never get along. They just criticise each other’s work. But doing it differently and getting this feedback gave me incredible pride.
You have context, and nobody’s criticising or competing. It’s like, “You don’t have to prove yourself, guys”.
Troy: “The key is ensuring security is not taking away agency.”
It’s about empowering business owners and their teams.
In the risk assessment and risk management cycle, you’re basically asking them to discover their own problems. But it should also be about empowering them.
You must have policies and standards for doing things while giving them both ends of the power spectrum. Based on the information they provide, you identify problems. Do they want your help to resolve them? It’s their application, after all. When they have that agency, they are happier clients. Making sure that security is not taking away agency is key.
Security is always there, like, “No, you can’t do this, or you must deal with this risk”. If that’s the position all the time, you’re not helping or enabling the business. You’re just the “no” team, blocking stuff.
When you’re not the “no” team, when you’re there alongside people to help them discover and deal with things at a pace that works for them, that’s when you get good security working with the business.
When you're not the “no” team, when you're there alongside people to help them discover and deal with things at a pace that works for them, that's when you get good security working with the business.
Maybe it’s not super hardcore or the most stringent security, but it’s good people-workable security where you always improve things in a constructive environment.
Curious to find out more? Read Troy’s Fundamental beliefs about Security.
Also, be sure to read and watch the first part of the series, Redefining Cybersecurity Investments, for an introduction to this new approach to systematic security assurance.
The conversation continues, so stay tuned! This blog post is part two of a three-part series in which Ankit and Troy unpack all it takes to build a systematic, scalable approach to cyber security.
Ready for a risk management framework that collaborates across the whole business?
