This month’s newsletter provides you with some more content that not only goes into the why but also the how of threat modeling: why you should get into it, places and tools that help you get into it, and give directions for constant improvements of your threat modeling practice. Dive into the read and enjoy!

The TMI line-up for this month:

• A deep dive into the 2023 Threat Modeling Connect Hackathon, written by Luis Servin
• Threat Modeling talks by Izar Tarandach and Kim Wuyts
• Toreon blog post: The added benefit to early threat modeling that nobody talks about by Georges Bolssens
• Tips & tricks, what are repudiation attacks? Written by Winsey Fong
• An update on our upcoming training

Threat modeling is trending. Standards are requesting it. Thus, many people are trying to get into it, which is great, because a lot more vulnerabilities will be found early on and products will be better in the long run.

There is a caveat though: how do you start threat modeling? If you’re trying to get into this practice, you need to try it out in a safe environment to test your understanding and figure out which methodology feels right for you. It’s like learning martial arts, you need to do “katas” to build muscle memory for the different offensive and defensive techniques.

There are great kata resources for system architects, like coding dojo or Neal Ford’s architectural katas. But there aren’t that many systems that serve the purpose of threat modeling training. If you book a training, you will get some, of course, but they come at a price which might not allow everyone to attend them.

Since there aren’t that many well-described systems in which to exercise when you’re training your threat modeling skills, how do you improve or find your style? There is nothing more intimidating than facing a white page or whiteboard and having the developers who created a system, aka the experts, and not knowing where to start. There might be a strong feeling of being an impostor, as you don’t know anything about the system and you’re not sure how to threat model.

It is great that there are now hackathons or threat modeling competitions in which to get some exposition to other styles of threat modeling and to systems that are well described. In March 2023, there was a threat modeling competition at threat modeling connect. This is a report of my experience in the competition.

The competition was open to anyone and had no cost. The participants were randomly assigned to a team. I’m not sure how many participants were in each team, mine had between 5-7 in the beginning. The event was spread over 20 days and there were three deliverables: two checkpoints separated by a week and a final deliverable on the 20th. There are participants from all over the world, thus time zones could get in the way of collaboration.

The kick-off consisted of a threat-modeling “theory” session and a practical session. Afterward, we had access to the system description and we could log into our team area, within threatmodelconnect’s platform. We could chat and work collaboratively on the deliverables, using Google’s docs and sheets.

The Target of Evaluation

The system in question was called *RideShare* and is a SaaS mobility solution where drivers, aka partners, are matched with riders, aka customers, in an optimized way to reduce ETA, waiting time, and driving distance. There were no architectural diagrams of the solution. We know it runs the Backend/APIs in some cloud. The descriptions of the architecture were, I suppose, left intentionally vague, perhaps to allow teams to show their understanding (modeling) of the system and how they elicit threats.

In my team, I proposed using the C4modeling technique to describe the system. I find it to be very useful to break the complexity of the target of evaluation and to be able to understand the system in its context (users, third-party systems, etc) before diving into the details. This breaks a bit with the “simple” diagrams usually taught while threat modeling (circles for processes, parallel lines for storage, directed lines for data flows) but it adds more context to better understand the components and keeps you from going back and forth between the description and the diagram when threat hunting. Here’s the diagram we came up with:

We identify the riders, and drivers using their apps, and the respective backends/APIs they communicate with. We also see that there is a “Dispatch System” making the matches between riders and drivers. We can see the data types being exchanged.

We then went on to create so-called *container diagrams*. They show deployable units, not docker containers.  Creating one from the description of the Mobile App was not difficult. But creating one from the description of the Different backend APIs was incredibly difficult because of the vagueness of the description.

This is part of the description given for the *Dispatch Service* architecture.

• All the active cabs keep on sending the location to the server once every 4 seconds through a web application firewall and load balancer. The accurate GPS location is sent to the data center through Kafka’s Rest APIs once it passes through the load balancer. Here we use Apache Kafka as the data hub.
• The location (state machine/latest location of cabs) will be sent to the database and to the dispatch optimization to keep the latest location updated.

We can identify that Kafka, a load balancer, a WAF, and a database are in use. We then want to understand which databases are in use and this is the description we receive:

• Redis for both caching and queuing. Some are behind Twemproxy (which provides scalability of the caching layer). Some are behind a custom clustering system.
• Ride Share uses schemaless (built in-house on top of MySQL), Riak, and Cassandra. Schemaless is for long-term data storage. Riak and Cassandra meet high-availability, low-latency demands.

So, which database is used for what? We have three possible databases and a vague description of how they could possibly fit into this picture. We spice that with Kafka and now the question is how is Kafka connected to the DB.

Now if we look at the *Analytics* component, the description is likewise intriguing:

• For log analysis, Ride Share uses multiple Kafka clusters. Kafka takes historical data along with real-time data. Data is archived into Hadoop before it expires from Kafka. The data is also indexed into an Elastic search stack for searching and visualizations. Elastic search does some log analysis using Kibana/Graphana.

Interesting questions arise here from the use of topics in Kafka and whether they are matched to an individual user or not.

There were several pages of description about ETA calculation, map region definition and building, and how the *Dispatch service* matches riders and drivers. Without knowing how this data flows within the components that make up this or the other services, it was hard to come up with many threats to them.

In my team we couldn’t really figure out the architecture beyond the high-level view already shown. This is something that could be improved upon for a future hackathon version.

There were no details on how the software is created and deployed, which can also lead to many serious vulnerabilities and by consequence threats.

We identified three threat actors within the context diagram:

• Internal to rideShare,
• Man in the middle, and
• one that directly probes the APIs:

For the mobile apps, we identified these bad actors:

• one jamming or otherwise interfering with GPS signals,
• one within the phone (process or physical access to mobile device), and
• man in the middle.

The Feedback

We had two intermediate checkpoints to show how we answered the typical threat modeling questions:

• What are we building?
• What could go wrong?
• What can we do about it?
• Did we do a good job?

Each checkpoint’s feedback was provided by a different mentor. The feedback was structured so that there was a general comments section and a section that structured points to consider. The structured points show the criteria by which threat models would be judged. This is the list of structured points of evaluation:

• The depth and breadth of details in the system model created
• The range and variety of threats identified
• The relevance of threats identified
• The comprehensiveness of the threats identified
• The effectiveness of the threat prioritization
• The range and variety of solutions identified and the feasibility of the implementation plan
• The comprehensiveness of the reflection process
• The presentation of the deliverable and the message clarity in the threat model document

The quality of the feedback provided in the general comments was really good, even if a bit contradictory with regard to the scope of analysis. As many details about the application, its development, and its operation were missing, we made some assumptions. The first reviewer suggested reducing the scope of analysis, thus we set some items like the development process out of scope. the second reviewer, in turn, advised us to reconsider what we were leaving out of scope and rather include it as controls that should be there.

We were also advised to show where the threat actors may find themselves, and thus we added diagrams with them to our deliverable.

The Platform

It is fantastic that a platform to exchange information on threat modeling has been created. We need to applaud Iriusrisk for providing such a platform free of cost. There are general topics where comments and questions can be written and where the community interacts. So far the only place where such exchanges happened was the OWASP #Threatmodeling channel in Slack.

For the hackathon private groups were created. One per team and one for all participants. Presentation slides, use cases, and general resources were made available. The private groups allow members to post questions and comments. This is how we, as participants and teammates, interacted with each other.

Conclusion

The hackathon was an interesting challenge. It was an interesting system to analyze, which could have benefited from some level of architectural diagramming from the creators or some better descriptions of the relationships between logic and the components it runs in or stores data into.

The organization of the event was really good. It started with the basics and a quick workshop to get a taste of threat modeling. The system we were presented with was challenging enough for all levels of expertise. The feedback quality was excellent and the comments were very helpful.

The platform itself is good for some level of communication between teammates, but perhaps setting up slack channels would be more efficient and foster more engagement.

It would be great if the use case and the winning threat model were made publicly available to serve their purpose as kata for anyone who couldn’t participate in the hackathon.

Threat Modeling in and for your organization, a Threat Modeling talk by Izar Tarandach

Watch this great talk “Threat modeling in and for your organization” by Izar Tarandach at Global AppSec Dublin who references and uses OWASP SAMM Threat Modeling stream as a maturity model (starts at around 20′)