Zu Risiken und Nebenwirkungen ...

... lesen Sie die Packungsbeilage und fragen Sie Ihren Arzt oder Apotheker – so besagt es die schöne Theorie und aufwendige Praxis bei Medikamenten. Und so mancher wünscht sich eine vergleichbare Regelung auch für Soft- und Hardware sowie IT-Dienstleistungen. Wissen zu können, wer dahinter und was darin steckt, wäre auch bestimmt nicht verkehrt. Schließlich käme man damit versteckten Bedrohungen in der Lieferkette leichter auf die Spur – etwa aufgrund vererbter Gefahren durch Bibliotheksfunktionen, verkappter Geschäftsinteressen oder Eingriffsmöglichkeiten nationalstaatlicher Akteure.

Ich selbst habe mir auch schon oft ein Standardformat gewünscht, das zu jeder IT-Komponente zumindest dokumentiert, wann die mit wem warum welche Daten austauscht. Dann müsste man nicht hinterher im Einsatz aufwendig überwachen, recherchieren und organisatorisch und technisch reglementieren, was man davon bereit ist, zu akzeptieren, und was nicht – mit dem Risiko der Überregulierung, die dazu führt, dass nicht nur die „Werbetelemetrie“, sondern auch erwünschte Funktionen, etwa für Securitypatches, unterbunden werden. Das andere Extrem wäre ein quasi unbeschränktes Vertrauen, das im Sinne von „Post-Privacy“ (oder auch „Post-Security“?) einem einmal gewählten Anbieter mehr oder minder alles zugesteht, weil man „das ja eh nicht mehr kontrollieren kann“. Die maschinenlesbare Version des kommunikativen Beipackzettels würde immerhin einen automatischen Abgleich der Interessen von Anbietern und Nutzern ermöglichen – na ja, zumindest in meiner idealen Wunschwelt. In der ganz realen Welt gäbe es da noch „die eine oder andere“ Hürde zu nehmen. Erinnert sich eigentlich noch jemand an das „Platform for Privacy Preferences Project (P3P)“, das schon 2002 als W3C-Standard einen ähnlichen Ansatz für den Austausch personenbezogener Daten auf Webseiten verfolgt hat?

Selbst bei Medikamenten, wo der Wert einer strikten Regulierung und engmaschigen wissenschaftlichen Überwachung wohl unbestritten ist, führt der Beipackzettel beim „Anwender“ oft nur zu Schockstarre und Verweigerung angesichts der möglichen Folgen einer Einnahme – oder zum pragmatischen „Wegschauen“, denn der eigene Arzt wird schließlich schon wissen, was uns guttut. Eine Packungsbeilage im IT-Umfeld wäre noch dazu ein ungleich komplexeres Monster und äußerst dynamisch, denn die „Zutaten“ und ihre Interaktionen ändern sich ja mit jedem Update nicht nur der betrachteten Komponente selbst, sondern auch bei Aktualisierungen jedes eingebundenen Stücks Code oder verbundenen Services.

Bliebe noch, sich an „Arzt oder Apotheker“ zu wenden – doch wer soll diese Rolle übernehmen? Das BSI wäre in der Analogie eher das Gesundheitsamt – eine wichtige Stelle, aber dass im staatlichen Gesundheitswesen teils auch Pragmatismus und politische Interessen mitspielen (müssen?), dürfte spätestens angesichts der jüngsten Pandemiebekämpfung offenbar geworden sein. Consultants, unabhängige Prüfer und/oder die/der eigene IT-SiBe, CISO (oder wie auch immer eine solche Position heißen mag) kämen dem womöglich noch am nächsten – aber Moment: Was wäre dann anders als bisher? Transparenz zu fordern, ist sicher gut und richtig. Allerdings wird sich kaum jemand wünschen, diese Transparenz durch einen bürokratischen Zulassungsprozess strikt umzusetzen. Und damit bleiben wir letztlich doch wieder bei Selbstregulation von Markt und Community sowie einem gewissen Maß an (hoffentlich nicht blindem) Vertrauen, oder?

Ernüchterte Grüße aus Hannover

Norbert Luckhardt