In practice, it is not an easy task for manufacturers to continuously integrate a strong security mindset into complex software projects. In our blog series, Stephan Neumann, Head of usd HeroLab, and Torsten Schlotmann, Head of PCI Security Services, talk about practicable approaches and ways to still effectively improve software security.
- Part 1: Reasons for more Security
- Part 2: Anchoring Security in the Corporate Culture
- Part 3: Requirement and Threat Analysis
- Part 4: Static Code Analysis
- Part 5: Dynamic Code Analysis and Vulnerability Management
After describing the concept of Security Champions in Part 2, in Part 3 our experts talk about the Requirement and Threat Analysis, its benefits and why a change of perspective can be so important.
Torsten Schlotmann: "Security should be considered and integrated into the software development lifecycle from the very beginning - even before the first line of code is written. In the design phase, for example, Threat Modeling, also known as Threat Analysis, plays an important role. Threat Modeling is a conceptual analysis technique that has proven its worth in identifying potential threats and risks in development at an early stage and deriving measures accordingly. This results in the following advantages: Unfavorable or wrong architectural decisions can be avoided from the beginning. Security requirements for the system or software can be fully understood in advance. And these requirements can then be integrated into the code at an early stage.
To successfully implement a threat analysis, asset management is the first prerequisite at the outset. One must ask oneself: What is my protection-worthy data? Where is it located in the software? And above all, what protection goals do I have for it? These can differ greatly in terms of confidentiality, availability or integrity. After identifying all data worth protecting, the next step is to determine input and output interfaces, trust boundaries and the actors involved: What type of user is working with the data and what operations should be allowed to occur through them? The answer to this question should include the "normal" user as well as administrators, other systems and applications, and potential attackers. With this information collected, data flow diagrams can then be created. These make it possible to visualize security-relevant data flows and help to understand how and where sensitive data is processed by the software and what happens to it. By systematically analyzing the diagrams, potential threats can be identified.
Defined methodologies for classifying and categorizing threats can be helpful here. One model that I recommend to our customers is the STRIDE model, which was originally developed by Microsoft and specifies a total of six different threat categories:
- Spoofing
- Tampering
- Repudiation
- Information Disclosure
- Denial of Service
- Elevation of Privilege
After gaining an overview of the potential threats, the next step is to prioritize the threats or their corresponding countermeasures. We often receive the question how such an assessment is supposed to be done. Again, there are many different approaches. However, especially at the beginning, I recommend keeping it as simple as possible and, for example, classifying both probability of occurrence and possible impact into the categories "Low", "Medium", "High" and "Critical" to determine the risk. Then you work down these from the top, starting with the greatest potential risk.
My final tip is to perform a Threat Analysis not only initially at the beginning of a project, but also when changes are made to the existing architecture, as well as major changes and new features within upcoming releases. This ensures that any new risks that may arise can be identified and addressed accordingly, or that the threat model is always kept up to date."
Stephan Neumann: "As Torsten already mentioned, we are often asked about how we, as developers, know what can possibly go wrong and where the best place at which to start is. This is where I'd like to add that it's not about doing everything perfectly and identifying every potential vulnerability - because that's not possible. It's about taking your time and looking at the software from a different perspective. Namely, from the perspective of an attacker. I have a nice analogy for this: usually, everyone feels safe at home. But if you lock yourself out and find yourself in front of a locked door, you have to get creative and think about possible ways to get back in. "Weak spots" such as a window left open, will become visible, allowing "intrusion" into the house. And it is precisely this change of perspective that I recommend to everyone in order to discover possible weak points and to be able to derive measures.
Returning to the question of possible starting points for software security, I would like to talk about the Requirement Analysis. For me personally, this is a very important topic, because as pentesters we quite often see after identifying vulnerabilities that this was not done in advance. In a Requirement Analysis, one proceeds as follows: First, all functional requirements should be explicitly documented. For example, a customer wants his users to be able to edit their respective profile pages. Now these requirements must be analyzed in a security context. In our example, this would mean that we have to ensure that everyone can only edit their own page. This requirement must also be explicitly defined as a requirement, because otherwise it can quickly be forgotten in further processes. When it comes to a cross-check of the requirements later, perhaps no one can remember the initial thought. That is why it is important to define non-functional IT security goals in addition to functional goals. In this case, I would write down the functional goal 'A user should be able to change his profile page' and the non-functional IT security goal 'A user should only be able to change his profile page'.
In summary, this means: take the time, recall the example I gave with the house, take a step back and think about what can possibly go wrong, and document it accordingly.
