Securing WebApps with Elevation of Privilege Game

Organizational Culture as a way to gender equality

Usually when a company starts a new software project they don’t include a security mindset in any of the stages of the SDLC and if they do these events take place at the end of project. This approach is a recipe for disaster. As everyone in the software development business know making design changes in the middle or at the end of a project is expensive.

Around 50% of the security incidents are due to design failures. In order to tackle these situations from scratch we must embrace the concept of Secure by Design and include it in our SDLC. 👏👏.

Introduction

Secure by Design concept entails that the software is developed from the ground up to be secure. In order to do this the general recommendation is to include seven specific events in the different steps of the SDLC of the organization. The Image Below reflects this events.

In order to reduce design failures in our software project Risk Analysis event is of paramount importance. These event takes place during the arquitecture and design of the system in which a Threat Modeling process takes place in order to find and address threats on the System and after that a validation process must take place in order to validate all the controls defined to address threats.

Threat Modeling

Threat Modeling is the process of findining security problems on the system you are building. As defined in the books Threat Modeling consist on four key questions and is a Knowledge Intesive process that brings better results as you have more experience, like playing a musical instrument 🎸 .

Threat Modeling is a process that focus on answering the four following questions:

What are you building?
The starting point of this process is to understand what are you building, the different component the system has, to which other entities your system communicates and how data flows between them. It is really important to have good general understanding of the system in a forest-level perspective, a good way to this is describe the system using Data Flow Diagrams (DFD) . The image below represents a good example.

A good advice is to represent the different Trust Boundaries of your system in this diagrams since usually when the control changes accross of these boundaries the threats that appears are usually important ones to address.
Trust Boundary
A Trust Boundary is a sub-system or a context where each component trust each other. In Computer Security it is used to describe a boundary where data or a process excecution change its level of trust and it presents a good insight of who controls what in your system.
Examples of Trust Boundaries are:
- Interacting with external entities (Web Services, APIs, etc..)
- Increase of user privileges
- Data flow accross networks of different owners

What can go wrong?
Once we have a forest-level diagram of the system we are developing we need to start thinking about the Threats. This is when the Elevation Privilege 🃏 game comes in, this game is based in a Threat classification system using the STRIDE acronym where each of the categories is related to a security property that your system should contemplate.

1. The categories of STRIDE are the following:
  - Spoofing : this is the act of impersonating another user and is an atack against the Authentication security property.
  - Tampering : is when an unauthorized user modifies data in rest or in transit, it is an attack against the Integrity security property.
  - Repudiation : is when a user can claim it didn’t do something, regardless if it is true or not. It focus in abusing the system incapacity of tracing system operations, it atacks the no-repudiation security property.
  - Information Disclousure : is when a user can read data or a resource which is not authorized too. It is an attack against Confidentiality security property.
  - Denial of Service : is an attack that prevents the system from providing service. This kinds of attacks affects Availability security property.
  - Elevation of Privilege : allow a user to do something he is not allowed to do. This types of attacks attempt against the Authorization security property.
  When you play Elevation of Privilege Game you use STRIDE to list the things that can go wrong on your system. The purpose is to think of possible threats to your system and enumerate them, in a later stage you will think about the specific mechanism of the attack and possible mitigations to develop.
  During the game it might happen that someone thinks of an attack that could have a mitigation in place, if that is the case it is also important to enumarte this attack because that mitigiation is a testable feature that must have a test case in place.
  As we already mention this game is based in STRIDE categories, during the game and specially the first times you play it you will be forced in trying to fit the attacks in some of the possible attack categories. For example if during the game you bring the attack someone can access information being exchanged between two systems because they are using plain HTTP to communicate, this attack can go under Information Disclousure category because the attacker is able to read information in transit, but it can also go under the Tampering category, because the user can receive the package modify its content and send it to the destination since there is no integrity control in place. For the purpose of the game both answers are correct and one mitigation (Always use SSL 😎) might solve the problem for each of the categories, remember that the objective of the game is to help you think about possible Threats of your system and not wasting time on trying to fit the attack on a category, the objective of this category is to provide guidance and being a starting point when you start thinking about possible attacks.
  Tips to find threats
  – Start focusing on the Trust Boundaries, usually in this sections of the diagrams is when the most important threats are present, for example if there is data flowing across those boundaries you should check for example Information Disclousure or Tampering Issues.
  – Focus on real threats and don’t waste time with threats that exceeds your project.
  – Use inspiration resources to start thinking about threats, I recommend the following ones: OWASP TOP 10, CVE or CAPEC.
  You can find the Elevation of Privilege Game Rules here
2. What should you do about those things that can go wrong?
  Now you should have a sanitized list of threats to your system so it’s time define how are you going to address them. In order to address threats the possibilites are:
  - Mitigating Threats
  - Eliminating Threats
  - Transferring Threats
  - Accepting the Threats
  By default you should always choose to mitigate threats, this is usually the best approach for the system and your customers. Mitigating implies to define and develop security controls in your system that should be included as user stories in your product backlog, and this security features must have a test case developed to guarantee the feature integration.
1. Did you do a decent job of analysis?
  Now that we have in place a list of threats for our system with a possible mitigation defined for each item on the list, we should proceed to validate our model.
  - Did we develop what was defined in our diagrams?
  - Did we address all the Threats found ?
  - Did we defined a test case for each security feature developed?
Conclusion
Threat Modeling is a good way to start addressing security issues early in your project and it helps dev teams figure out situtations that they might not think without Threat Modeling. The first times you Threat Model yous should seek for different sources of inspiration that might help you tackle down common security issues. Addressing the threats you found is a delicate process and is important to have a test case in place for each security feature you develop. Threat Modeling is also an iterating process along a software project development that must have several iterations as your projects evolves.
I hope you find these post usefull and I whish you a Happy Threat Modeling! 🙌🙌
References
- Elevation of Privilege Game
- Threat Modeling (Desinging for Security) – Adam Shostack