TMI newsletter 25 – Developer-driven threat modeling at OutSystems

Welcome

In this month’s newsletter, we gathered valuable advice from different sources on ways to continuously improve your threat modeling skills. Threat modeling through step-by-step approaches, updates, and add-ons, embedding it in the DevOps lifecycle… There are so many ways to find out why and how to threat model!  

Enjoy the read, and spread the threat modeling message! 

The TMI line-up for this month:

  • Developer-driven threat modeling at OutSystems, written by Rui Covelo
  • Book bites: “Threats: What Every Engineer Should Learn From Star Wars” by Adam Shostack
  • Threat Modeling talk by Sarah-Jane Madden: Introducing Threat Modeling to Established Teams
  • Threat Modeling Connect: A browse through the archives
  • Tips & tricks: Threat Modeling as Code with PyTM Written by Georges Bolssens and a new podcast on threat modeling!
  • An update on our upcoming training

Developer-driven threat modeling at OutSystems

We first started threat modeling at OutSystems when the whole R&D Team could fit in a large room. Now, the team is 10 times larger and spread around the world. Still, threat modeling remains part of our secure development lifecycle. Here is why we started threat modeling, how we still do it, and the bumpy but invaluable ride it has been.

Let’s start with the basics. Threat modeling is a structured, iterative approach to identifying, qualifying, and addressing security problems in a system or application based on a four-question framework (Shostack, 2014):

  • What are we building?
  • What can go wrong?
  • What can we do about it?
  • Have we done a good job?

The obvious choice for a growing problem

I joined OutSystems eight years ago. We had just launched our cloud offering in record time, and I was eager to bring in my systems engineering skills seasoned with a security mindset. The team was small, and we didn’t even have a security team, so I started to list what I would like to change on the security front. It was a big list.

I showed it to my manager and asked for a budget to “fix all the things.” As a small team doing a lot of work for our cloud offering, my manager had no choice but to ask me to prioritize and plan to implement the most critical security fixes first.

For me, someone who had barely scratched the surface of a career in security, this sounded outrageous. It’s security! Everything is important, right? Not really. This simple act of leadership from my manager turned out to be one of the most crucial turning points in my career. How do I prioritize security issues? What are the most critical issues?

Being new to the company, my first step was to get more information about everything to better understand the risks involved. Before I proposed solutions, I broke down each problem as simply as I could so that anyone could understand them. Then I offered solutions based on what I discovered — and that’s when it hit me. I was answering some very familiar questions:

  • What are we building?
  • What can go wrong?
  • What can we do about it?

We prioritized based on risk, selected the top ones, and planned the fixes. We could then answer the last remaining question:

Yes, I was threat modeling. The methodology caught the attention of a few leaders in the company, tired of endless debates around security, often leading to over-engineered solutions to fix minor problems. Threat modeling allowed Engineering teams to have structured conversations around security, identify relevant issues, and then focus on the most important ones first.

Now, all we had to do was have every team do it early in the development process to maximize the value of the methodology by hopefully finding problems before development starts. And that’s when the bumpy ride began.

Getting Buy-In From Developers

OutSystems was a very small company at the time. We didn’t have a security team and we had a single threat modeling champion (me). There was no way this would work without developers’ buy-in and help. The first bump you may encounter when implementing threat modeling is getting that buy-in from developers. To them, threat modeling will sound like yet another process to follow on the path to delivering software. A delay. An annoyance. And it will continue this way until developers see the methodology’s value.

You can help them do this by surprising the team with newfound problems they didn’t know they had or showing how threat modeling can help fix the problems they know they have. The absence of an established security team at the time worked to my advantage. The methodology sounded like an idea coming from one developer to another.

We started small, focusing on a few teams with clearly defined security issues, exposed assets, or other identified security concerns that needed prioritization. Then we rolled out the process to more teams. And the following feedback was consistent:

1. “We don’t know anything about security or how to do threat modeling.”

Not knowing about security or threat modeling is easy to tackle with documentation, guidelines, examples, and an introductory session. In no time, I saw developers chiming in with security problems that security-savvy engineers weren’t aware of. How do you create this mindset? I advise focusing on whatever can go wrong rather than trying to think like a hacker. Hackers invest in tools that we don’t have while using their creativity. So, instead, look at what impacts users, the company, and the business, and start from there. As soon as someone starts identifying one of these, the whole team usually chimes in, offering solutions and more things that can go wrong.

2. “We don’t have time to do threat modeling.”

Teaching How to Threat Model

Prioritizing Threats

When is Threat Modeling Relevant?

How We Do Threat Modeling at OutSystems

References

Bookbites

Adam Shostack: “Threats: What Every Engineer Should Learn From Star Wars” (Wiley, 2023) 

Adam Shostack writes: Yoda teaches us that “when 900 years old you are, forgotten what it was like to be a beginner, you will.” I may have the quote slightly wrong, but as experts in cybersecurity, it can be easy to forget that you had to learn about the relationship between authentication and identifiers, or the difference between authentication and authorization. When we combine this with the many paths people take into cybersecurity, there was a need for a standard text that people can read to learn about the threats we use in threat modeling. 

Threats: What Every Engineer Should Learn from Star Wars is my solution for this problem. Mixing clear technical descriptions with fun Star Wars stories, this book delivers on the promise of ‘what every engineer should learn from Star Wars. Available now as paperback, ebook, or audiobook, wherever fine books are sold.” 

Curated threat modeling content

Global AppSec Dublin: Introducing Threat Modeling To Established Teams – Sarah-Jane Madden

Global AppSec Dublin has provided us with a ton of great material such as this great video by Sarah-Jane Madden on the introduction of threat modeling in established teams. This is a topic we encounter frequently in our threat model coaching, so make sure to give it a watch!

Read more

Tips & Tricks

Threat modeling as Code with PyTM

written by Toreonite Georges Bolssens

One of the big challenges around threat modeling is keeping your threat model up-to-date, with an additional challenge being that your software design is changing all the time. This inevitably leads to ambiguity as to which code version a version of your threat model relates to. When employing the practice of “threat modeling as code”, a.k.a. “TMaC”, you can simply add your threat model to version control systems like Git, Mercurial, SVN, etc. that you already have available! In one of our next blog posts, we’ll be exploring “PyTM” so if you’re curious about TMaC, feel free to check out the GitHub repo https://github.com/izar/pytm. 

A new podcast on threat modeling: The Threat Modeling Podcast

Chris is going on a journey. A journey to understand threat modeling at the deepest levels. He thought he understood threat modeling but realized he could go deeper. Chris shares his findings and talks with some of the best-known experts in the space to experience continuous learning. Join along for the ride — you will learn something.

Listen to the first episode.

We aim to make this a community-driven newsletter and welcome your input or feedback. If you have content or pointers for the next edition, please share them with us.

Kind regards,
Sebastien Deleersnyder
CTO, Toreon

Book a seat in our upcoming trainings

  • Threat Modeling Practitioner training, hybrid online, hosted by DPI (cohort starting on 8 May, 2023)
  • Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, hosted by Black Hat USA, Las Vegas (5-8 August, 2023)

We also organize in-company training for groups as of 10 participants.

Start typing and press Enter to search

Shopping Cart