If you’re not getting value out of risk management, it’s not attached to reality, explains long-time Chaleit client and collaborator Troy Cunningham, Head of Cyber Security Compliance at Criteo.
In a three-part dialogue with Ankit Prateek, VP of Technical Services at Chaleit, Troy describes his methodology for threat modelling and driving interactivity with asset owners.
Read on to discover a realistic and grounded approach that helps improve assets meaningfully.
The security assurance process involves finding information, reading documents, and identifying risks and vulnerabilities. Realistically, you don’t need a tool to do that – you can use Jira tickets or Word files. You need tools to do specific stuff, such as code review or penetration testing.
You need a tool when you want to do security assurance at scale and in a helpful way in the medium to long term.
Can you remember the results if you do security assurance for several applications? Or do you have to reread the reports? How about tracking questions and the information you’re gathering? What about the metadata? This is where the GRC (Governance, Risk and Compliance) tool comes into its own.
You need a tool when you want to do security assurance at scale and in a helpful way in the medium to long term.
You ask questions that help you make decisions about problems or risks. I codify the answers into attributes or fields as metadata about the application. Taking this data and persisting it means I can measure and have a reference point. And it can also make life easier for the business owner.
For example, if you want to recertify an application, would you rather ask all the same questions again or just re-verify and check what has changed?
I don’t investigate every application or individual document when I get a question. The tool gives me the aggregate. From there, I drill down to see the details. I’m giving the client specific, useful information without having to go back and read multiple reports.
Being able to persist information about applications is a subtle benefit. It’s subtle excellence.
The tool is open to everyone. An internal security team, an external security team, a vendor, and a product owner can all see the dashboard themselves. All the questions and answers are there.
As a pen tester, I know where the problems are just by looking at those questions. I don’t have to break something just to validate it. I already have answers, and I’m having a dialogue with the product owner.
The dashboards provide transparency, which solves the friction that typically occurs between different teams. Collaboration becomes easy.
We are maturing our security posture. Instead of starting from scratch, we simply go back and check if something has changed or not. As a traditional pen tester, this platform now makes me a risk manager. The same goes for product owners who have gone through the exercise. They can just click a link, access all the documentation, and see how everything connects.
The dashboards provide transparency, which solves the friction that typically occurs between different teams. Collaboration becomes easy.
Security becomes complex when the dev team and the product owner are not incentivised to participate. If, as a security person, I go and take total responsibility for the process and assume others don’t know anything about it, it’s just ego. It’s not going to work out.
I learned not to go and immediately get into validating and revalidating issues. Start with validating the person and their efforts first.
When talking to a product owner, let them talk about what they built and take pride in it. This dashboard gives you so much context and lets you start by first validating the good things they’re doing.
Learning through this process is so much fun. I love the interactions and dialogues we are having. Asset and risk management becomes fun.
I learned not to go and immediately get into validating and revalidating issues. Start with validating the person and their efforts first.
In our previous chat, I said I’m reversing the process. I’m not thinking about the vulnerabilities and problems first. I ask: What does this application do? As a result of its value proposition, what kind of problems could arise? In that context, I look into what forms it.
Here’s an analogy. A book is made out of paper and ink, but the story and the content of that book are the words, the thoughts, and its meaning. Most of the time, the content is more important than the format.
I don't have the approach of we have to close everything. It's not realistic because you will always find a problem.
Think about the meaning first and then about the form. Finally, connect them to discover problems that are grounded in reality. You uncover meaningful risks to a business owner, not blown out of proportion but proportional to what you’re dealing with.
As a result, you decide what amount of effort you spend on each problem. So you don’t spend time on the stuff that is low value.
I don’t have the approach of we have to close everything. It’s not realistic because you will always find a problem.
As security people, we are trained to find something wrong and solve it. But you have a finite amount of time and resources. The security assurance process is in itself a triage process. The risk management process is the triage process for the business owner.
I enjoy the GRC space because of this ground-up approach. In my role, I’m responsible for things in a transversal way. I have to be realistic and grounded when talking to executives and stakeholders. At the same time, I still have conversations with technical people or clients and tell them what they should care about.
If you're not getting value out of risk management, it means it's not attached to reality. It's boring, disconnected, and useless.
My governance, risk and compliance style allows me to have far more confidence and certainty in the security of my business. That’s key. If you do it correctly, you can maximise your business.
If you’re not getting value out of risk management, it means it’s not attached to reality. It’s boring, disconnected, and useless.
But if you do it the other way round, as we’ve been describing it, you get actionable results from security, which you use to improve applications in meaningful ways.
Curious to find out more? Check out part 1 and part 2 of the conversation and read Troy’s article: Madness: The Art of Not Caring
