What Could (Possibly) Go Wrong? - Designing Threat Modeling with a Card Game

What could (possibly) go wrong? - This is a question that should be asked as early as possible during the development of an application, because some vulnerabilities can only be removed with great effort in a late stage of development. Some decisions are even so deeply anchored in the system that they must be considered already in the architecture. Therefore, security should be considered far in advance, before the first line of code is written, in the planning and architecture phase: Security by Design. The goal is to consider as many threats to the application as possible and plan countermeasures. This is done in so-called Threat Modeling.

Threat Modeling

In threat modeling, threats are identified and a risk assessment is carried out in order to develop prioritized countermeasures with the greatest possible effectiveness. Depending on the use case, the methodology can take very different forms: for example, the dangers for an entire company or smaller components such as a single module of a web application can be considered. In the following, we will use the threat modeling of a web application as an example. Due to several security vulnerabilities in applications for corona test centers, which threatened the health data of many people during the pandemic, such an application should be developed with a better security standard.

Although it is practically impossible to find all potential vulnerabilities of an application, frameworks have been developed in the past to ensure that at least the most important vulnerabilities are considered during threat modeling. One of these frameworks is the STRIDE mnemonic developed by Microsoft. STRIDE is an acronym for the categories of various attack techniques on applications and systems and stands for:

• Spoofing (faking identities)
• Tampering with Data (manipulation of data)
• Repudiation (preventing traceability)
• Information Disclosure (disclosure of information)
• Denial of Service (restriction of availability)
• Elevation of Privilege (bypass of access controls)

This mnemonic is intended to support teams during threat modeling and, in particular, to ensure that no category of attack techniques is overlooked. The framework itself does not claim to be complete. Despite the standardization of the methodology, individual circumstances must always be considered and every framework can be reasonably modified. In addition, attack techniques are constantly evolving, and thus the frameworks are also evolving. In addition to STRIDE, there is a number of other models and frameworks for threat modeling such as Kill Chains, Attack Trees, PASTA, etc.

Gamification

To avoid implementing the threat modeling process only as a "necessary evil" for the fulfillment of compliance checklists and to make it more effective at the same time, the approach of gamification has existed for some time. By using playful elements, the motivation of those involved can increase and a more sustainable result can be achieved. Several card games have already been developed in the past that aim at different areas. Examples of this are Elevation of Privilege by Microsoft and Cornucopia by OWASP. Further security-relevant games can be found here.

In order to ideally cover the requirements for aramido's threat modeling projects with a focus on web applications, our own card game was developed.

The Card Game

The card game consists of 39 cards, each representing a specific attack. The cards have the following structure:

• STRIDE category: The STRIDE category to which the attack is assigned. The cards are grouped by this category.
• Attack title: The title of the specific attack.
• Attack description: A short description of the attack.
• CVSSv3 score: The CVSSv3 score of the card estimates the dangerousness of an attack. This score is also used in the classification of vulnerabilities, more on this below. In the card game, this number primarily serves to put the cards of a category in an order.
• Card number: A unique number for each card, which is not relevant for the course of the game.

The Joker is the only card with the threat of an unknown zero-day exploit, has a CVSS score of 10 and thus outranks all other cards.

Gameplay

1. The card game was designed to make threat modeling for a real application playful. Therefore, at the beginning, the architecture of the application should be represented graphically, for example by a diagram. This facilitates the discussion and traceability for all participants in the following.
2. The cards are shuffled and dealt to the players. All players should receive roughly the same number of cards. Since threat modeling can practically be extended indefinitely, it is important to determine a maximum playing time.
3. In clockwise order, a card is played and then read aloud.
4. Together, it is considered whether the already planned or implemented protective measures sufficiently deflect the attack. In doing so, the card should be adapted as much as possible to the application and organization without changing the essence of the threat. In this discussion, hypotheses and trade-offs can and should be made in order to develop a as creative attack as possible.
5. If the attack cannot be safely deflected, the card remains open on the table. If the attack is impossible, the card is turned over and placed on a pile.
6. The open card can now be trumped in turn by all players by playing a card of the same category with the same or higher CVSS score. If the attack is not possible, the card is turned over and the trump round continues with the next person. As long as the attack cannot be deflected, the card may be placed openly on top of the already lying card. There is no obligation to play a card; cards may be kept strategically. The trump round ends when no one can or wants to trump the top card anymore. The person who placed the top card with the highest CVSS score may take the entire open stack and add it to their points.
7. After the end of the trump round, the game continues in the original order, as if there had been no trump round. A card of any category may now be played.
8. The Joker can be played regardless of the current category and trumps all other playing cards.
9. The game is over when all cards have been played or when the playing time has expired.
10. The winner is the one who was able to collect the most points.

The focus should clearly be on the discussion of the feasibility of the different attacks, countermeasures, and the exchange with each other.

Background Knowledge: CVSSv3 Score

The CVSS score is a metric used to classify the severity of vulnerabilities. Essentially, two components flow into its calculation: impact and exploitability. On the one hand, the impacts of a vulnerability are evaluated, i.e., the damage that can occur if a successful exploitation takes place. For example, the impacts are significantly greater if arbitrary program code can be executed on the system (Remote Code Execution) than if attackers are only able to read individual usernames from the database. The second component is the exploitability, i.e., how easy it is to use the vulnerability. A vulnerability that can be exploited from the public internet has a higher exploitability than one that is only possible with physical access to the server on site.

From these two components, a value between zero and ten is calculated. The higher the score, the higher the risk of the vulnerability and the more important it is to find countermeasures against it.

Let's Play

To play the game as an example, the scenario from the beginning is picked up again. Alice, Bob, and John are web developers at the Musterfirma GmbH. They are currently developing a web application for a corona test center. Since they want to operate the application securely, they carry out threat modeling and decide to use the card game to make the process playful.

The Application

The application is an ordinary application, already known to many, for arranging appointments for corona tests and retrieving the results. It has the following properties:

la Arten von Benutzern:

• Admin (creates test centers)
• Testing staff (enters master data and test results)
• Patients (book appointments, retrieve results)

Funktionen der Anwendung:

• Appointment planning and booking
• Providing test results via email
• Reporting to the health office via email

Alice, Bob, and John have already identified the most important protection goals and carried out a prioritization. This is intended to help them better assess the criticality of possible vulnerabilities in connection with their application.

To simplify the discussion, the developers have visualized the infrastructure architecture with a diagram:

The application is hosted in a modern cloud environment with the following properties:

• Database for texts and non-binary content (users, passwords, master data for test centers, ...)
• Blob Storage for files (test results as PDF)
• Email delivery service
• Application:
• Web server (nginx)
• Web application: React in the frontend, Java backend
• External Users:
• Test centers (shared account for each test center, PW sticks under the keyboard)
• Patients (no real accounts, authentication only for test results: PDF is encrypted with date of birth)
• Internal Users:
• Admins who create new test stations

The Game

Alice, Bob, and John sit together at a table in the meeting room and project the diagram of the application onto the large screen. Then the cards are shuffled by Bob and distributed as evenly as possible to all three players. For a start, the players agree to limit the playing time to one hour and set a timer. After consultation with the others, Alice begins, plays the first card, and reads it aloud:

Together, the players now discuss whether an overload of the application by calling a computationally intensive function is possible. Alice thinks that the PDF generation is an expensive function. So far, a link to the PDF is sent via email and the PDF is generated anew with the result from the database for each call of the link. An attacker could use this to call the link automatically very often and thus overload the application. Bob agrees with Alice and immediately presents a possible solution to the problem. By generating the PDF only once and then saving it, the computationally intensive PDF generation for each link call is eliminated. John confirms this and presents another possible solution. Instead of sending a link with the email, the PDF could be sent encrypted as an attachment directly. To prevent the problem, it is a common practice. la la the problem of overloading the application is removed. Since he doesn't have a higher CVSS score than 7.5 in his hand, he cannot trump the card. Alice gets the two cards and two points.

Now it is Bob's turn to play a card. Since Bob only holds a single card of the Denial of Service category, which also has a lower CVSS score than the card previously played by Alice, he decides to start with a low CVSS score and plays the following card on the table:

John thinks that the cloud instance has a firewall and therefore no scan of the application is possible. Bob contradicts this and points out that while there is a firewall, it is not configured to automatically detect vulnerability scans (Intrusion Detection System) but so far only filters network traffic based on ports. Alice agrees with Bob and also John sees that he was wrong with his initial claim. The three add the configuration of the IDS function on the firewall to their list.

John then decides to trump Bob's card and plays:

All are in agreement that the shared accounts of the test centers represent a problem. Thus, it cannot be traced which employee in the test center added or changed a test result. The card is therefore placed on the previously played card.

Now Alice has the opportunity to trump the card. She sees that almost an hour has passed since the start of the game and therefore decides to play the Joker now. The Joker trumps the card with an unknown zero-day exploit and Alice gets the three cards and three points.

Since the hour is now over, the three decide to end the threat modeling for today and would like to transfer the notes as tickets into the project management system. Alice won the game with three points before John with two points. Since they all consider the insights from the game to be very beneficial, they plan to carry out a somewhat more extensive threat modeling of three hours' duration again with the help of the card game next week.

Conclusion

Providing secure, automatic software updates is not a trivial problem. It is part of a secure software development process. aramido GmbH helps you implement security according to the principle of Security-by-Design along the entire software lifecycle . The security experts from aramido look forward to advising you on your software development project.