Christian Neumann, d-NRW: OZG in Administrations

Christian Neumann: The implementation of the OZG requires a high degree of coordination and communication between the authorities involved at the federal, state and municipal levels. A very important task here is communication among each other, so that everyone is on the same level of information and the overall project can run as smoothly as possible. Among other things, a coordination concept regulates the individual responsibilities of those involved, and we take on the coordination and preparation of an overall plan. For example, we support the Ministry of Economics in distributing the centrally provided OZG funds. But we also accompany concrete implementation projects as one provider among several. At the state level, we implement, among other things, essential portals such as the service, construction or business and trade service portals.

Technology and standardization are essential tasks for us, along with planning, coordination and communication. Together with the Ministry of Economics, IT.NRW and the umbrella organization of municipal IT service providers KDN, we are defining how the principle of "one for all" can be implemented. In other words, standards are being defined that standardize the use of the same basic services, such as the form management service, in all portals.

This is exactly what d-NRW is supposed to prevent, and after almost two years of working on the OZG implementation, I can say that it is working excellently. The OZG has led to a rethink - also nationwide. Saarland, Rhineland-Palatinate and Hesse even founded a cross-state OZG association in November 2020. The willingness to agree on joint solutions has grown significantly. That's why, for example, there will be a central municipal portal in NRW with all essential online services. Here, each municipality can decide whether it wants to use certain online services there or set up a new service itself. It has been shown that this service has been very well received by the municipalities.

In the case of digital administrative services, we are mostly dealing with personal data. In this respect, we have to do everything we can to make OZG services secure for data protection reasons alone. This applies both to access security and to the overall architecture of the systems. We separate the front-end from the back-end systems. This means, for example, that the input form in which citizens enter their data is separate from the actual specialized procedures in the back end, where the data is processed. So, according to all the risks we currently know, it is not possible to gain access to the back-end systems via the front end.

The backend is located in the protected internal network area of our service provider. The frontend is connected to this backend only via a secure connection and only for data transmission. This separation of the network areas is relatively complex and expensive, but it fulfills one of the essential security requirements for the system. Virtually no data storage takes place in the actual service portals. Actually, only during the time a user is entering data there for an application. If the user interrupts the input and wants to temporarily store the application until the next day, the data remains in the front end, but is stored in encrypted form. Only when the application is sent does the data go via the secure networks of the state of North Rhine-Westphalia to the relevant authority, where it is processed in the specialized procedure.

This is precisely the reason for separating the systems. If an attacker were to manage to gain access to the front end of the service portal, he would not find any data there. At most a few cached applications, but these would also be encrypted. Our goal is therefore to keep as little data as possible in the application form. By encrypting the cached data and the dispatch, we achieve end-to-end encryption. The data is only decrypted for processing in the specialized procedure.

To check whether the systems are secure, IT.NRW has penetration tests carried out. Both initially for the services of the service portal and later with each update. This attack simulation allows gaps and vulnerabilities to be identified and, if they exist, subsequently closed in a targeted manner. At least the types of attack known to us can be defended against with this procedure.

In addition, the individual services are split into a kind of microservice architecture. In other words, they are encapsulated from one another. This prevents a successful attacker from directly accessing all of a citizen's data.

Basically, this is a matter of weighing user-friendliness against the level of security. First, the misuse of Corona assistance was nowhere near as great as was initially claimed, and second, there were fewer gaps in the NRW portal than fake websites that applicants fell into. Nevertheless, this example shows well what online services are all about: How can we ensure that applicants actually submit an application themselves. This has a lot to do with the criticality level of an online procedure and the trust level that goes with it. It then depends on how users have to authenticate themselves to the system.

Exactly that. And the more precise the verification process, the less user-friendly it is. If someone makes an appointment online for a fake bulky waste pickup, that's still acceptable if they use a false identity. But if someone applies for and receives funding illegally, that is much more critical. So our standard approach is to ask ourselves what the trust level needs to be for processing an online application. How much damage can someone do by submitting online applications with a false identity. If the damage would be high, the trust level must also be higher. Then I can't log in with a service number, password and user name, but have to put my ID card on a reader. That doesn't necessarily lead to a rush of acceptance among many users.

At the moment, this is still the case as a rule. However, modern smartphones now offer such functions for reading ID cards as an app. However, users also have to set this up. But in the end, I have to make sure that the person making the request is actually sitting at the screen. We are particularly concerned about the medium, or substantial, trust level. Are there intermediate steps between the levels, i.e., simple login via user name and password on the one hand and ID card scanning on the other? We don't have a solution for that yet. Therefore, we will not be able to get past the ID card reading function at the moment. So far, it has not been worthwhile for citizens to have a reader for online procedures, because there are hardly any procedures that can really be handled completely online. However, this will change with the implementation of the OZG.

We are now massively entering the implementation phase. While we have created and set many concepts, foundations and standards so far, we will now think about implementation management and the right resources in the right places. But I am very optimistic that we will be through with the crucial services in NRW by the end of 2022.

Christian Neumann is responsible for the subject area OZG and online applications at d-NRW AöR. In the area of OZG, d-NRW AöR operates the OZG coordination office NRW, coordinates the implementation of the Portalverbund.NRW, develops the Serviceportal.NRW and provides the central data access node for the Portalverbund with the Verwaltungssuchmaschine NRW. Before joining d-NRW AöR, he worked as an IT and project management consultant for well-known consulting firms.