Thread Modelling

From Embedded Lab Vienna for IoT & Security
Revision as of 18:40, 17 February 2020 by Sprochazka (talk | contribs) (Methodologies)
Jump to: navigation, 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.

Methodologies

STRIDE

STRIDE is the threat modeling methodology from Microsoft that aligns with their Trustworthy Computing directive of January 2002. It mainly helps Microsoft Windows software developers assure the security during the design phase. The goal is that the application meets the CIA (Confidentiality, Integrity and Availability) security properties and as well Authorization, Authentication and Non-Repudiation. The six threat categories are:

  • Spoofing identity: assuming or taking on the identity of another person to accomplish a certain goal.

Example: Using another person’s username and password to login.

  • Tampering with data: The malicious modification of data.

Example: The unauthorized changes to persistent data and alteration of data in a dataflow.

  • Repudiation: Users who deny performing an action without other parties having any way to prove otherwise.

Example: An illegal action of a user in a system without the possibility to trace the operation.

  • Information disclosure: The exposure of information to unauthorized individuals.

Example: If a user can read files, he should not have access to or if an attacker can read transit between computers where he is not supposed to.

  • Denial of service: A DoS attack denies service to a valid user.

Example: Making a Webserver unavailable by creating a lot of fake requests.

  • Elevation of privilege: An unprivileged user gains enough privileged access to destroy the entire system.

Example: An Attacker has effectively penetrated system defense to the point where he becomes part of the trusted system.

OCTAVE

OCTAVE stand for “Operationally Critical Threat, Asset and Vulnerability Evaluation and is developed at the Carnegie Mellon University´s Software Engineering Institute (SEI) and is heavy weighted on assessing organizational risks that result from data asset breaches. It was one of the first specifically for cybersecurity developed threat modeling methods. Since it is mostly used in companies, it is normally performed in small teams composed of people from the business unit as well as from the IT department to address the security needs. It is driven by the operational risks more than by the theology risks and allows an organization to direct and manage information security risk assessments, communicate key security information as well as focus on protecting key information and to find the best practice and decisions based on the unique risk of their department and thus provides a highly customizable security option.

There are eight processes that are broken in three (or four with phase 0) phases:

Phase 0: Exploratory phase that determine criteria used.

Phase 1: Develop initial security strategies

Phase 2: Technological view to identify infrastructure vulnerabilities

Phase 3: Risk analysis to develop security strategy and plans

Trike

The Trike Threat Modeling is an open source process that provides a risk-based approach and risk modeling processes. It is based on a requirement model which ensures that the assigned levels of risk are acceptable to the stakeholders. This means that the modeling process is focused on satisfying the security auditing process from a cyber management perspective. There are two attack types in the Trike model, an elevation of privilege attack or a denial of service attack and the actions taken are divided into one of four groups called CRUD: Create, Read, Update, Delete. The threats are rated in a rating chart that shows the risk of either attack type to a five-point scale for each CRUD action. Trike starts with the creation of a requirements model and continues with the creation of a DFD, a Data Flow Diagram. From this point on the risk values are assigned to the threats and an attack graph is created. The Trike model requires a view of the entire system, therefore it can be hard to scale it for larger systems.

References

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

https://threatmodeler.com/threat-modeling-methodologies-overview-for-your-business/

https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee823878(v=cs.20)?redirectedfrom=MSDN

https://technology.ku.edu/octave-method-security-assessment

"Introducing OCTAVE Allegro:Improving the Information Security Risk Assessment Process"; Richard A. Caralli