Threat Modeling

In the traditional software development cycle, measures to increase the security level are usually implemented only shortly before delivery – but often only after the software has been delivered. Since about half of all security vulnerabilities are due to design flaws, security measures must be implemented and verified before or during the design phase. Threat Modeling helps to identify security vulnerabilities.

Threat Modeling supports the methodical development of a trustworthy system design and architecture in the design phase of software development (security design) – the cost of fixing errors is still very low in this development phase. In addition, existing system designs and architectures can be reviewed to identify, assess, and correct security risks.

At each stage of the process, the corresponding actions are performed; This is to more accurately indicate the threat model and advance their further development.

Used technique/method

Vulnerability identification begins with an analysis of available documentation – particularly security design – and an examination of program flowcharts and use cases.

From the analysis, (input) interfaces, resources to be protected, trust boundaries, as well as external entities (potential attackers, administrators, normal users, other systems, ...) accessing the system are systematically identified. With this information, the data flows of the system under investigation are visualized with data flow diagrams (DFDs). This allows all security-relevant data flows to be graphically traced up to a resource worth protecting in the system under investigation.

Through a systematic and complete analysis of the DFDs, potential threats are fully identified.

A threat always targets a resource to be protected (password, personal or business document, photo, ...). For example, an identified threat could be "An attacker can read a password from the system's database".

The identified threats are mitigated as far as possible using information from the available documentation. This is done, for example, by noting in the documentation that passwords are stored in an encrypted database and implementing this accordingly in the development process. This would mitigate the threat of password theft.

However, an incorrectly implemented encryption algorithm could be cracked or the key used could be guessed using brute force techniques, for example. Thus, an attack path of non-mitigated threats is created step by step. Non-mitigated threats represent a vulnerability that can be exploited by attackers and are represented in attack trees in the form of attack paths.

Threat Modeling supports the construction of a complete security architecture with an appropriate level of security, helping to minimize the attack surface of the system under investigation.

Do you want to be sure that your system is protected from attacks, then contact us!