Now, in part 4, our threat-model comes together. We have (business) use cases that give us the different roles accessing our system (part 1), we have an attack surface (part 2) and we have the technologies used in the different components of the application(s) we are modeling. Now we will use STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) to help us to determine the possible security risks. We will prioritize the risks and we will determine how we are going to handle the risk.

Of course this list can be really extensive; depending on how detailed you are modeling. Just like in part 1 – 3 I will not go in to much detail. This is just to show the techniques of modeling. The table below only applies to the web-shop component. If you are creating your own model, you should make a table like this for every component from the attack surface you’ve drawn.

The priority of the threat can have 3 values (of course if you need more, you are able to): high medium low. When determining the priority you have to keep two things in mind: the possibility of this threat being real and the business impact if this threat becomes reality. If the risk is low, because of different layers of security or because it is terribly difficult with little result, but the business impact is high (it would be terrible if all the customer data was freely available on the streets) the priority still is medium or high.

With mitigation we will determine the action we will take to mitigate this vulnerability. Possible actions are: mitigate, accept, transfer. Of course you must use the comments to elaborate on the specific actions that must be taking. If you mitigate you will take action to mitigate the vulnerability, for example check the input. If you accept the vulnerability you know it is there, but the risk and the business impact are low that your business is willing to accept this vulnerability and the risk it carries. If you choose to transfer, the mitigation is already in place in a different component or the architecture of the infrastructure you are using.

Web-shop

Of course this list isn't nearly complete, but I think you'll get the picture. Be pragmatic while modeling. If you get in to every detail, it will be unreadable. Different people must be able to understand the measures that need to be taken. The designer, developer, business analyst, etc. all need to know the risks and what they need to do to mitigate any threats.