CyberKsen Blog

We saw in part 3  what STRIDE is, now we are going to apply a two-step process to list the vulnerabilities for the assets in-scope as described in part 5 . Keeping always in mind that the threat model should be useful both to the development team, to perform security analysis and understand what can go wrong, as well as other stakeholders, to document and give awareness of the security status, rationale and risks of the system. For our methodology example, the system is a simple e-commerce website with a database containing products and user.customer identities, the same architecture used previously: Two Step process for listing vulnerabilities Listing all the identified vulnerabilities and their associated mitigations could be a rather complex and long task. As usual, we divide a complex task into smaller, easier steps. My Advice is a two-step process. STEP 1 consists of associating threats in the taxonomy (in our case STRIDE) to assets. The second is to detail the vari

The major threat for a threat mode (pls excuse me for the wording game) is to feel lost on the vast "sea" of things that can go wrong, and how to prioritize them. This feeling of vastness, or the opinion that everything needs to go inside the TM, is the first enemy or getting the TM done. So, don't panic and get the thing done...so, where to start? A good place to start is the highest diagram of the architecture of the system itself. It is not something meant to be used to TM but is useful as a starting point for the analysis. You also have limited time, let's focus on the most important things and prioritize them. It is often the case that teams perform threat modeling after the design phase, or when the system is already in production. In this case, this practice could be considered technical debt, and you might find out that already many mitigations and countermeasures are in place to defend against threat agents. In this case, bear in mind that the threat is pre

Threat model can be done at different levels of abstraction and in different phases of the SDLC. If the more consolidated techniques are about creating a Threat model in the design phase (before implementation). Nowadays needs are often to integrate TM inside a maintained (production) system that may also have an Agile methodology of development; new features coming in all the time. When we want to approach a design level TM we most likely will use architectural, design, and data flow diagrams (DFD). Security architects and engineers will apply a more rigorous framework (e.g. STRIDE) create a TM document and maintain it. The TM is on a whole application scope. When delivering a single feature (Story or Epic in Agile terminology) we should also apply TM techniques that imply adversarial mindset, delivers mitigations, improve implementation and show documentable security efforts. In this case is advisable to follow a different modus operandi, much lighter, and agile developer or