Threat Modeling Hackathon Finalist 2023: Threat Model 02

Description

This threat model is the deliverable of one of the finalists of our Spring 2023 Hackathon.

The team is tasked with threat modeling a rideshare app based on this use case. They used the ATASM as the primary framework.

Creators

Abhishek Goel
Luis Servin
Rene Zubcevic
Vanina Yordanova

Summary

Threat modeling framework(s) used and why:

ATASM (Architecture, threats, attack surface, mitigations) from Brook Schoenfield for the analysis but diagrams inspired in the c4model methodology from Simon Brown.

Diagramming or thinking tool(s) used and why:

We used graphviz with some templates to create the diagram. This has the advantage that the source can be kept as source code and anyone can read and understand and modify it. The biggest challenge with DFDs consists on having the security person do them and redo them on every opportunity rather than the diagrams living with code, as code, and being owned by the development team.

What is the scope of the threat model?

We created two views, based on the c4 methodology. First, the context view, where the system is seen in the context of its users. Then we “zoom” into the mobile app, for which we create a container diagram. The backend components were not well enough described as to be able to create a container diagram of them, beyond their names (demand, offer, dispatch). We then enhanced the views to include the threat actors in each trust boundary.

What are the top 3 threats you identified? What are the mitigation plans?

• Insufficient Object Level Authorization at the API: this is the #1 threat in the OWASP API top 10 threats. Many APIs suffer from this, and it’s not trivial to identify during development and less trivial to manage adequately during operations
• Insufficient authentication mechanism to the production environment in the CSP: As recently demonstrated by famous data breaches abusing MFA fatigue, if access to the production environment is not adequately secured, it will be possible for adversaries to gain access to the platform and access users’ data or bring down the service.
• Instant cash-out business logic vulnerability: The service depends on partners (drivers) to exist. If it is possible for drivers to exploit the cashout service, the viability of the service is endangered since it could drain the company’s earnings. On the other hand, if the vulnerability leads to drivers losing their money in phishing schemes or through the first vulnerability, then the service will lose drivers and eventually not be able to meet the demand.

How the threats are prioritized for mitigation?

The threat scenarios we prioritized had to do with their business impact. We chose the three scenarios with the biggest impact.

Threat model

https://drive.google.com/file/d/1iQHAzyNGJxBuJ2V7Kx-QZ1HC4dYONquv/view?usp=share_link

‍

Retrospective

How did you evaluate your threat model?

We evaluated the different components that make up the threat model: the system model, the analysis of its vulnerabilities and corresponding threat scenarios, and the mitigations proposed.

The system model is good, but since many details were not clear about the architecture, it was very difficult to dive deeper into the backend system. This could be improved.

The analysis covers development, operation, and the App/Backend itself. In all of these elements, we were able to find vulnerabilities and create threat scenarios.

Mitigations for all threat scenarios were created. Some include links to further resources to improve on them.

If you were to give this threat model to the developer team, what do you think their reaction would be? How valuable do you think they’d find it?

The developers would definitely be able to profit from the diagram and take ownership of it. Since the diagram was created as code, it could “live” together with the code, thus lowering the barrier to keeping them up to date. The diagram’s code is graphviz, thus the images can be created in the CI pipeline, and thus the documentation could stay up-to-date with minimal effort.

The findings were created using “Gherkin”, just as BDD does, to help them better understand them. For example, we considered that coupons and promotion codes will be provided to users. If there is insufficient business logic validation in the backend (vulnerability) this threat scenario could arise: GIVEN coupons or promotion codes are in use AND they don't have a uniqueness guarantee OR single use guarantee WHEN a user attempts to use them multiple times or to guess possible values THEN it is possible to get rides for free or at a discount.

To help developers get more value out of this threat model, the findings would be made available as tickets in their ticketing engine and the criteria for closing them would be implementing the countermeasures.