"It's difficult to build security in later."

Ms Koziolek, you are investigating the question of how design decisions with a safety aspect can be modelled and documented appropriately. What do you mean by this?

Even before the first line of program code can be written, software developers have to deal with the requirements of a system. In the first step, they decide how the system should be built. On a rough level, we call this software architecture. Similar to an architect designing a building, we draw up a plan for the big picture. Then come the detailed designs. Here we determine, for example, what interfaces should look like, which classes the system should have and which objects interact with each other at runtime and in what way. A huge web of decisions is spanned in such a project. Many of these decisions also influence the security of the system. If I am later connected to the internet, for example, I have to think about security mechanisms: How should users authenticate themselves? What kind of encryption do I use in which places? Experience shows how difficult it is to build in such security-relevant mechanisms at a later stage because with each development step, as the dependencies between individual parts of the system grow, it becomes more and more complex. This also makes it more and more difficult to uncover possible security gaps afterwards. That is why it is important to consider security as a requirement from the very beginning. Then, for example, the design can already be created with lean interfaces. These have only the absolutely necessary functionality so that two modules can communicate with each other without errors. This is to prevent security gaps from occurring in the first place.

You pay special attention to the documentation of assumptions, which are also the basis of security proofs. Why is this important?

Without assumptions, I cannot evaluate the security of a system. When I think about security, I have to assume at least once that I can trust someone, for example, the user or the administrator who has access to the database with the passwords. And if I don't trust all the admins, at least I trust most of them. I also have to make assumptions about the environment of the system: What can happen there? What requests or messages can be sent to the system? We want to document this especially for the design, because security proofs are often only kept for individual parts of the system or only concern individual aspects. But it is important to know whether certain assumptions for one part of the system also fit the other parts. This is the only way to combine different aspects of safety into a consistent picture of a hopefully safe overall system. An example from the automotive industry shows what happens if this is not pursued consistently. Here, the communication between the control units runs via the CAN bus. In the past, no safety mechanisms were necessary. Because the devices were only networked by cable and they were safely stored in the car. So, no one could get to them from the outside. Over time, however, cars have gained more and more networked functionality. The original assumption that the CAN bus could not be accessed no longer applies today. Researchers have shown how this works in an American SUV. Using the car's internet-enabled radio, they were able to hack into the CAN bus from the network and control the car remotely to a certain extent. We don't know exactly what assumptions the car's developers were making, but they obviously misjudged or overlooked a point of attack here.

And this is where the documentation of assumptions you examined comes into play?

Correct. Once we have written down all the assumptions, we can already identify possible security gaps in the development phase. Moreover, we can refer back to the original assumptions when working on the system later. However, a long list for the entire system is difficult to work through later. That's why our approach is to link the assumptions to the individual design decisions, for example, for a specific interface or even for a single method of the system. The idea behind this is that if we look at this method again later, we will also find the assumptions we made in our development environment. In this way, I as a developer can check whether all previous assumptions remain valid. This helps enormously, for example, with future changes to the system. We are currently still researching how to model and link such assumptions. Our longer-term goal, however, is to actually build this functionality into a development environment.

With your research, you want to reconcile model-based software engineering with agile software development. Could you explain these two approaches in more detail?

Model-based development assumes that we humans need abstractions to deal with complex systems. This means that instead of looking at five million lines of source code, we always have to form models in order to be able to talk about such a software system at all. This abstraction is the core of model-based development. Agile software development is more–but not exclusively–code-centered. Here, the focus is on fast feedback cycles. Instead of first developing a plan and then implementing it step by step, a minimum viable product is created as quickly as possible. This is then presented to the customer in order to incorporate their feedback. Approaches such as extreme programming have taken agile software development to the extreme. Here the credo was: I only need the code as an artefact. Everything else around it; writing down requirements; making a draft; creating a nice document with diagrams; all that was unnecessary. It would only distract us from writing working code. To a certain extent this is true, because if you make these things an end in themselves, they are often not useful. Modelling must always serve the goal of writing working, high-quality software.

So, you want to combine the advantages of both approaches in a new one. What does that bring to software development in the future?

Exactly, in our research we are investigating the possibilities of combining the best of these two approaches. Modelling is still seen today as too much ballast that generates high costs. Often people still work on a whiteboard, which is photographed and the pictures then disappear in a filing cabinet. Rarely are computer-based models created and then maintained with the project. That's why we are looking at how we can reduce the costs of creating just such models. This makes it easier to keep models in computer-readable form and also to maintain them. One of our approaches is to derive software architecture models directly from the source code. With such a starting point, it then becomes possible to update the model entirely when the implementation changes. We can thus automate the maintenance of the models to a large extent. Our idea is to be able to provide tools that enable such a view of the system with little or even no additional effort. On the one hand, this reduces costs and on the other hand, it offers the advantage of being able to access the models. In this way, we can increase IT security.