A few years ago, around 2017, a German government backed initiative was aimed at making doctor’s practices more secure by adding proper segmentation through hardware firewalls and smart card based authentication. After a few needless fails and pitfalls, the system has entered a Post-Secure state by making things . . . worse . . .

Where we’re Coming From

As described in two blogposts here and here, I’ve gotten to play with a few doctor’s practices networks. Even though I didn’t like the equipment and documentation and practical implementation, I very much enjoyed the concept.
The core component is a hardware VPN router, which establishes a tunnel to a central, virtual network connecting doctor’s practices, health insurances, chemists hospitals and other institutions required for billing and invoicing. The central network is operated by certified operators, the router are certified, the access provider are certified, so perfect on paper.
The initial VPN connection is authenticated based on a physical smart card (SMC-KT), in physical card reader, which the doctors require in anyway to read the patient’s health cards, in combination with a manufacturer inserted certificate within the VPN router. Then follows a further authentication layer, based on the practice’s ID (SMC-B) to allow access to specific services. Above that, for secure communications between doctors and other institutes, the doctor’s doctor ID contains a digital certificate able to both encrypt and sign messages.
The other smart design aspect was, that the hardware VPN router could be used to add segmentation to the practice’s network: Everything working with medical data would be >behind< the router, everything else, in front of it! This way even using a typical home router, as many small practices do, was compensated for.
From a Security perspective, well, probably too complex, but at least pretty hard to hack.

Security Issues

The overall setup had multiple flaws, which were documented over the last few years including the possibility to request smart cards without actually being a doctor or having a practice and the possibility to extract and replace certificate on some of the hardware router models. Fun reads, but not part of this post!

Operational Issues

Having worked with some of the VPN routers myself, the system isn’t fun to use. Configuration is often unnecessarily complex, next to impossible to the medical professionals for whom they were actually made. Debugging / error analysis close to impossible and documentation is sparse.
The worst part though is, the VPN back-ends were in parts so unstable, that at some point chemists, who have the largest availability requirement (they can only fetch prescriptions, when the system is working), got the recommendation to buy multiple VPN routers with multiple subscriptions. And, just for the notes, the router is over 2k€, a subscription over 150€ / month.
Who, as a system operator, wouldn’t like to out-source redundancy to the client side, right?

Post-Security Solution

Now, the overall concept is being revised to resolve the stability issues: The hardware VPN routers are being centralised and virtualised! And all this by not reducing Security! (Officially)
Central service providers now seemingly operate redundant VPN routers in their central locations, which also host virtual instances of the hardware VPN routers, which used to be in the doctors offices. To allow this, a typical software VPN, like Wireguard is installed onto the doctor’s local PC, with static, key-based authentication. Additionally a proxy/router component is installed, which allows the local physical card reader to proxy through the doctor’s PC to the virtual VPN node, which does the authentication.
As such, adding a wonderful breaking point into the overall setup and removing the complete segmentation within the practice’s network the physical VPN router had added.

And Now?

Well, I openly said don’t even now how to comment this, thus lets just lean back and wait for upcoming Security incidents.