.jpg)
In our latest digital event (and first ever DevSecOps event) we bought together a panel of security leaders to share some tried and tested methods and approaches for building a positive security culture within your technology function. From communicating security and risk effectively to non-security colleagues, creating a low-friction security experience and supporting Developers to become more security aware, we’ve shared a round-up of the key questions and advice below.
A huge thank you to our panel for sharing their insight:
Paul Lewis, Senior Director Cloud Security @ Elsevier
Jennifer Salisbury Jones, Senior Security Engineer @ Improbable
Greg Smith, Product Security Lead @ GoCardless
Veroniki Stamati-Koromina, Information Security & Privacy Engineering Lead @ Skyscanner
Watch the full recording here.
How can you communicate risk effectively to non-security professionals?
Utilise a scenario-based approach to help explain in language that is relevant to Developers/Product Managers/DevOps Engineers. Bring potential exploitations to life by explaining what impact the weakness could have regarding their service or domain. Reframe potential issues in a context relevant to individual teams by explaining how it will affect them, their roadmap, and their goals. For example:
Skyscanner use the risk management framework FAIR. FAIR promotes the concept that risk is uncertain and organisations should instead focus on how probable it is that an event will occur before moving to decision making. Listen to Veroniki explaining the FAIR methodology in more detail here.
Trust the expertise of the teams, particularly when dealing with mature senior engineering teams, and work to augment their knowledge and teach them as they go, guiding them through the process rather than doing it for them.
How do you approach a situation when you might need to say ‘no’ as a Security professional?
You’ve got to really understand the problem, the context, and the risk appetite of the business. If you think a risk needs to be escalated, before reporting it to the C-Level, speak to the Engineers and ask:
-‘Is there anything that will mitigate this that I haven’t understood?’
-‘Let’s test it if we can.’
-‘Does this have the impact we think it does?’
Make sure you’ve taken the time to understand the perspectives that the teams are coming from and what they've considered doing. It may just be that they haven't considered a particular security approach that you can help them with.
If the problem does need to be escalated, make sure you prepare what you're going to say by asking yourself the following questions:
-What are the three talking points you'll need when you're speaking to the C-Suite?
-What questions might they ask you and what responses should you have?
You need to be very secure in your own knowledge and your own abilities to say no, as you don’t want to harm your credibility.
You can have a higher tolerance to risk if you've got good observability, good recovery strategies and good incident handling; because you’re able to recover quickly from something going wrong. If you’ve got good trust with your Engineering teams and accept the fact that they know what they’re doing and how their systems and services work, you can feel more confident in taking those more measured risks and not having to say no.
Limiting the number of languages that you use across your services means that you've got a better chance at defending them, but also building a paved road for securities is useful. GoCardless worked closely with their infrastructure team to build standardised patterns about how to go about deploying services.
By putting the guardrails in place and giving people the standardised patterns and configuration, they can choose to build something that's off that path, but they need to look at what risks are associated to it and understand it's a slightly higher friction path to go down.
Are there any techniques you’ve used to provide good quality, timely advice to Development teams or squads when necessary?
Most of what security teams do is delivery through others. So, if you're able to set good product roadmaps with the teams and work with them when they're doing their planning, you can help pre-empt some of the potential security pitfalls that may come up and try and assign those out earlier on. Build good checklists into your GitHub pipeline so that when you've got code that’s been changed (that will be higher risk) you've got triggers in place to help make sure you've got the engagement there when you need it. So, you can prioritise where you put your effort.
Recruit security advocates or ‘champions’ – people from Engineering teams with an interest in security – and build a relationship with them to support them and help develop their security interests. These people can become your eyes and ears in the team and can raise potential bugs or issues that you might miss. Get your security engaged Engineers on pen test calls and keep them involved. You’re helping the career development of engineers who might end up being security engineers down the line, whilst also recruiting security advocates around the business.
Try gamifying security and giving scores to tribes and squads to drive engagement. Each tribe gets a security maturity score and there’s a leader board where people can see where they sit.
Secondments are another successful initiative that Skyscanner have utilised. Take some security engineers and second them into a particular tribe or squad where there might be risk. The engineers are embedded in their day-to-day meetings and stand-ups and work closely together to learn from each other. You can also do the reverse and take a developer with an interest in security and bring them into the security team for a quarter/six months. They then take all the knowledge and bring it back to their tribes once they've completed their secondment.
Building a culture around blameless post-mortems helps with this as well. If you've got a good culture in terms of investigating why an incident happened, or why something went wrong, you can quite often get to the bottom of it fairly simply. Making these post-mortems blameless is key. You've got to be trusting and collaborative with your engineers, not on a witch hunt for who did the incorrect code.
What one piece of advice would you give on how to approach DevSecOps & Cloud security in general?
Jen: Get the boring stuff done first. There’s always exciting stuff to do but do your asset management first. Eat your vegetables before your dessert.
Greg: Getting the basics right is really important. Get some good checks and balances and a sensible flow about how your developers are reviewing their code and make sure they've got a good understanding of the services they use in the cloud to avoid common misconfigurations.
Make sure you're building maturity across the board rather than deep diving into one area, and that you've got good observability from the start.Veroniki: Build relationships with Engineers by training and engaging with them in a way that it makes security interesting and fun. If you make it fun, you’ll manifest an open culture where people can come and ask for help and support.
***
To catch up on the full conversation including discussion around managing secrets in IaC, outsourcing your development, the security of storing intellectual property in the cloud (and more), recap with the full event recording here.
A huge thank you to our excellent panel for what was a hugely interesting discussion. Highlighting the importance of human relationships and mutual trust, support, and respect across tech functions, paired with technical knowledge and expertise, to create an efficient and positive security culture.
