6 mins read
The key to a successful workshop lies as much in its planning as much as its execution. It is about ensuring that the right people are in the room and that you are prepped with as much background as possible. It is also about you being comfortable and energized with the task of getting all teams aligned in thinking about security. We have managed to hone the core process to be comprehensive, thorough, time-efficient, and sometimes even enjoyable.
Identify stakeholders from across the business
This should include technical teams – including development and design – but also teams from across the wider business who can provide context for how this project fits into broader business goals and objectives.
Book a room for two hours with a whiteboard
There are two important considerations in the above statement. One, limit your agenda to two hours. It is a short amount of time considering the ground that needs to be covered, but it will help attendees keep focused whilst feeling that their time is not being wasted. It really helps to get your attendees together, as well; remote conferencing facilities are possible, but don’t work as well.
For the whiteboard, we’re talking old school style – no digital versions here. Our experience shows nothing has yet replaced the process of writing tasks and issues on Post-Its, sticking them on a board, and moving them around as a group.
Prompt invitees to bring along any diagrams
You will get greater buy-in from stakeholders if you factor in their processes. Encourage them to bring diagrams they’re working with, including data flow and application architecture. It will give you the chance to start to see the entire project workflow, enabling you to identify where and how security can be integrated.
Research the threat landscape
You may well find yourself justifying why you’ve called the session. Whilst there have been many vulnerabilities found and breaches reported, it can really help to find good examples that are close to home. Come armed with that research into how similar applications and organizations have been compromised, by whom, and if known, the financial impact on the targeted business. If you can, have someone with a threat intelligence specialty contribute.
Choose your methodologies
There are a number of different methodologies and frameworks that can be used for identifying and prioritizing threats. A well-known example is STRIDE. The choice of methodology is largely inconsequential, but it needs to be one that you are comfortably communicating and applying in your workshop. Simplicity is often the key. Your methodology of choice needs to be explained at the start of your workshop – this will ensure everyone is aligned with the processes of the session, but also gives stakeholders the chance to raise issues or concerns.
Know your outputs
What do you absolutely need from the workshop? Answers may vary, but most importantly you need to define your outputs so you can ensure you achieve them. For us, these tend to be a canonical diagram that illustrates the system, a list of risks and threats, requirements or defects, questions to action, and – most importantly – a group that leaves with a better awareness of security.
The day has arrived. How should you structure your session?
Warm up by making the case for security
Explain why you’re there, why security matters, and how this process will help. Treat it as a warm-up. Have everyone introduce themselves, explain their respective roles, and draw their “usual system diagram” so that everyone can see each other’s process. A successful workshop is one that leaves all attendees excited, aligned and empowered.
Explain your methodology
As we said above, for a first threat modelling session it doesn’t matter which methodologies you choose, but explain these at the outset so people know what to expect. Be aware that discussions over the choice of methodology can often turn into a protracted debate, which is best avoided.
Agree diagram and scope boundaries
Define your scope by drawing an agreed boundary around the things that the team can control or influence. Threat modelling is no easy task and agreement on how this is done is essential. There may be elements that are out of scope given parameters and timelines – these need to be demarcated at the outset as time in the workshop is constrained to generate a sense of urgency.
Use your methodology – but be flexible
While it is important to know your methodology, it is also important that you have a plan if discussions aren’t quite working.
Your main objective should be to keep people talking and there are different ways you can draw information out. For example, you could follow specific user journeys or add in different environments, such as pre-production. Have a few pointed questions in your back pocket, such as “How does that database know that this request is coming from the right machine?” or“What’s on this diagram you MOST care about?” Most importantly, keep it positive, keep it moving and avoid tangents or panic.
Capture, prioritize, assign
You’ve done a lot of hard work, so now make sure you’ve captured it. From photos of your whiteboard to recording your session so that no words are lost, it is especially important that all findings are agreed, articulated, prioritized, and actioned. Make sure everyone leaves the room knowing what they’re supposed to do and by when. Where possible, the results should end up in the same tools that the developers use to track their work. With more advanced stakeholders, threats should end up as security outline test cases.
Book follow-up session
It is crucial to keep momentum building. Booking a follow-up session will keep motivation high while enabling you to check in on progress. Take feedback and improve the process to encourage agility amongst all teams.
‘Designing security in’ is – in our experience – the most thorough and cost-effective way to integrate security into every project. One size does not fit all, so do make it your own. Like most things, the ability to be open and adaptable will suit the process well.