Thread Modelling

From Embedded Lab Vienna for IoT & Security
Revision as of 08:39, 17 February 2020 by Sprochazka (talk | contribs) (Created page with "== Summary == Thread modelling is a process used to systematically identify potential threats to products, applications or any other system. It helps to figure out the possib...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Summary

Thread modelling is a process used to systematically identify potential threats to products, applications or any other system. It helps to figure out the possible vulnerabilities of a system that are most desired by attackers. There is hardly any product which who threat modeling can´t be used. It helps with the security of software, applications, networks, IoT, business processes and many more.

The reasons to use threat modeling are mainly to build secure design and to document threats and mitigations. It helps to identify threats and compliance requirements and to evaluate their risks to the system as well as is helps to efficient invest given resources. An important part is to document the threats and mitigations found.

The methodology mostly always includes a description, design or model of the potential problem, a list of assumptions that can be checked or challenged and of potential threats, a list of actions to be taken against this threats and a way of validating the output and the action taken.

When to perform

It is never to late to perform Threat Modelling actions but the earlier the better. It is to consider that, if the systems architecture isn´t changing, there are no new processes or dataflows and no changes to the data structure than it is unlikely that there will be new threats that are to be considered. But if some of them change, it is useful to examine what could go wrong in the current change. If something has already happened, it is important to have a look again at the system and check the threat models to find out what was going wrong and what was left out.

The four questions

What are we building? This includes the scope of the Threat Model and requires an understanding of the subject to be tested. For that purpose, it can help to have a look at or make yourself a architecture diagram, dataflow transitions or data classifications.

What can go wrong? Manly the research activity to find the main threats that appear to the system or the application. It helps to use a structure to think it through or to brainstorm about the possibilities.

What are we going to do about it? Turn the findings to action using the most fitted method.

Did we a good enough job? Check the quality, feasibility, progress and the planning of the process you developed. If not satisfied, start everything again with a better concept.

References

https://owasp.org/www-community/Application_Threat_Modeling