Muss ich mich schämen, Software-Architekt zu sein?

Inhaltsverzeichnis

Software-Entwicklung ist voller spannender Herausforderungen, und es gibt immer etwas Neues zu lernen: Software ist schließlich eine der komplexesten Dinge, die von Menschen gebaut wird. Aber die Ergebnisse in der Realität sind manchmal mehr als enttäuschend – sie sind beschämend.

In der aktuellen c't ist ein Artikel, dessen Untertitel eigentlich schon der erste Aufreger sein könnte: Es geht um "typische" Datenlecks in Software für die Test- und Impfterminvergabe. Mit anderen Worten: Software in diesem Bereich ist so unsicher, dass es typische Fehler gibt – und diese Software ist auch in Produktion. Die im Artikel diskutierte Software ist medizinische Software. Nehmen wir an, wir würden über andere Medikamente sprechen. Wäre es akzeptabel, dass es "typische" vermeidbare Sicherheitsprobleme bei Medikamenten gäbe, die auch tatsächlich verordnet und eingenommen werden?

Im Übrigen ist die c’t in diesem Bereich nicht alleine. Die Gruppe zerforschung beschäftigt sich auch intensiv mit der Sicherheit solcher Lösungen und schreibt: “Wir haben mittlerweile das vierte Testzentrums-Datenleck in drei Monaten gefunden und sind einfach nur noch genervt.” Was würden wir sagen, wenn es das vierte Problem in drei Monaten mit verschiedenen Medikamenten gäbe? Und Experten anschließend von der Sicherheit der Medikamente “einfach nur noch genervt” sind?

Der Vergleich zwischen Software und Medikamenten scheint auf den ersten Blick weit hergeholt zu sein. Mittlerweile ist es vielen gleichgültig, wo überall Daten leaken. Es passiert einfach so häufig, und bestimmte Unternehmen leben von dem Ausspionieren ihrer Kunden. Aber eine Schnelltest-Software machte es sehr einfach Testergebnisse zu fälschen. Solche Testergebnisse werden verlangt, um Personen vor einer Ansteckung durch Kontakt mit Infizierten zu schützen. Wenn die Testergebnisse gefälscht werden können, stellt das ein Gesundheitsrisiko dar – wie ein fehlerhaftes Medikament auch. Die Luca App zur Kontaktverfolgung konnte sogar zu Angriffen auf Gesundheitsämter genutzt werden. Über die Konsequenzen eines erfolgreichen Angriffs will ich nicht spekulieren.

Zeitschriften fixen Sicherheitsprobleme?

Die Einleitung des sehr lesenswerten c’t Artikels berichtet dann, dass bei der c't eine Vielzahl von Meldungen über Datenlecks bei Software für Test- und Impfterminvergabe eingegangen ist. Die c't verfolgt die Probleme und informiert die Hersteller. Hier ist der nächste Aufreger: Die c't, zerforschung und viele andere machen sicher einen super Job – aber offensichtlich muss eine Zeitschrift oder eine Gruppe von Expert:innen sich dieser Probleme annehmen. Nehmen wir als Analogie wieder Medikamente. Wäre es akzeptabel, wenn eine Zeitschrift routinemäßig über mögliche Probleme mit Medikamenten informieren würde, und diese Zeitschrift dann anschließend die Fälle näher untersucht und den Herstellern mit Rat und Tat zur Seite steht – und nur so die Probleme wirklich behoben werden? Sicher gibt es vereinzelt Medikamenten-Skandale, die über die Presse bekannt werden, und Fachzeitschrift, die wissenschaftliche Studien über Medikamente verbreiten. Aber eklatante Probleme mit Medikamenten sind eben nicht Routine. Und in der Branche und bei den Behörden sind Maßnahmen etabliert, damit das so bleibt.

Nutzer:innen sollen Sicherheit bewerten

Das Fazit ist dann der nächste Aufreger: "Ärzte und Apotheker sollten sich die Software sehr gewissenhaft ansehen (oder einen unabhängigen IT-Experten zu Rate ziehen)." Man kann kaum ernsthaft von Ärzt:innen und Apotheker:innen die Kompetenz verlangen, die Sicherheit einer Software zu bewerten. Ich arbeite im Bereich Software-Entwicklung und würde mir das selber nicht wirklich zutrauen. Vor kurzem bin ich privat um Rat in Bezug auf ein Sicherheitsthema gebeten worden und habe auch einen Rat gegeben. Allerdings bleibt das schlechte Gefühl, dass ich gegebenenfalls ein Detail übersehen habe, das am Ende dann doch große Auswirkungen hat. Daher ist der Hinweis, Expert:innen zu Rate zu ziehen, auch sehr sinnvoll. Aber auch hier bemühe ich den Vergleich zu einem Medikament: Kann man von einem Patienten verlangen, sich selber mit der Sicherheit eines Medikaments zu beschäftigen? Ich erwarte eigentlich, dass Medikamente, die ich in der Apotheke kaufe oder die mir ein Arzt verordnet, sicher sind. Üblicherweise werde ich sogar von Apotheker:innen und Ärzt:innen über die Details und mögliche Probleme proaktiv beraten.

Die Verantwortung für den Datenschutz auf die Nutzer:innen zu verlagern, kann desaströse Konsequenzen haben. Einige Lehrer:innen, die auf Eigeninitiative Videokonferenz-Lösungen in der Pandemie für ihren Unterricht genutzt haben, mussten die Sicherheit und den Datenschutz dieser Lösungen selber bewerten, weil sie oft dazu keine klaren Produktempfehlungen bekommen haben. Am Ende müssen die Lehrer:innen mit den Konsequenzen leben, wenn ihre Beurteilung falsch war – oder sie unterlassen es, sich dem Risiko auszusetzen und machen eben keinen Unterricht per Videokonferenz. Beide Konsequenzen sind nicht akzeptabel.

Aber die Empfehlung, sich die Lösungen anzuschauen, ist skurrilerweise sinnvoll: Tatsächlich können c't -Leser:innen meiner Einschätzung nach die geschilderten Herausforderungen nachvollziehen und auch Software auf diese Schwächen untersuchen. Dann sind diese Probleme aber auch für Software-Entwickler:innen nachvollziehbar – und das wirft die Frage auf, warum sie in Software überhaupt vorhanden sind. Mit anderen Worten: Wir sprechen nicht über subtile Herausforderungen, sondern solche, die man nach dem Studium einiger Seiten einer Zeitschrift verstehen kann und vermutlich auch abstellen können müsste – und daran scheitern die Hersteller dieser Software-Lösungen.

Wie unprofessionell sind wir eigentlich?

Es ist gut, dass die c’t und viele Sicherheitsforscher:innen und Expert:innen sich kümmern. Aber es ist erschreckend, dass unsere Branche der Softwareentwicklung solche fehlerhaften Produkte auf den Markt bringt. Als Ergebnis gibt es keinen Aufschrei, sondern eben einen Artikel, der davon handelt, wie Nutzer:innen sich mit der Situation arrangieren können und wie sie selber herausfinden können, ob die Software ausreichend sicher ist. Sind wir so abgestumpft, dass wir diesen Zustand akzeptieren? Ist unsere Branche wirklich so unprofessionell, dass sich Nutzer:innen eben mit diesen Mängeln unserer Produkte arrangieren müssen? Ist es unser Qualitätsanspruch, das unserer Produkte Fehler haben, die man als interessierter Laie nach dem Lesen einiger Seiten in einer Zeitschrift diagnostizieren kann?

Besonders bedenklich ist, dass diese Anwendungen personenbezogene Gesundheitsdaten verwalten. Diese Daten sind sehr sensibel und besonders schützenswert. Auch die Luca App zur Kontaktverfolgung geht mit Gesundheitsdaten um, weil über die App ja gerade infizierte Personen verfolgt werden soll. Dazu muss der Infektionsstatus bekannt sein – und das sind Gesundheitsdaten. Auch für diese App gibt es sehr viel Kritik und Sicherheitslücken bis hin zu den schon erwähnten möglichen Angriffen auf Gesundheitsämter. Dazu hat der Sicherheitsexperten Marcus Mengs zunächst ein Dokument mit fast 21.000 Wörtern geschrieben und dann die Arbeit an der Luca App eingestellt. Der Grund steht im Dokument: “Der Hersteller gibt mir keine Zeit die Zusammenhänge zu dokumentieren, welche zu Sicherheitslücken im Code führen und patcht stattdessen ständig Code mit neuen Fehlern nach.”

Mit mindestens 25 Mio € Einnahmen muss man die Luca App einen kommerziellen Erfolg nennen. Und die App hat bekanntermaßen prominente Unterstützung durch den Musiker Smudo. Seine Band “Die fantastischen Vier” ist “begeistert” von dem Produkt und sieht sich als Teil des Teams. Das zeigt eine Erklärungsmöglichkeit für den Zustand unserer Branche: Wenn der Applaus der Prominenz und der kommerzielle Erfolg von der Sicherheit der Anwendungen entkoppelt ist, dann ist es unlogisch, sich mit Sicherheit zu beschäftigen, weil sie für den Erfolg egal ist – außer man hat ethische Prinzipien, die dem Ignorieren entgegenstehen.

Die Spitze der Absurdität ist aber das immer wieder zu hörende Argument, dass der Datenschutz einer effektiven und effizienten IT im Wege steht. Der "Datenschutz", der in dem c’t-Artikel beschrieben wird oder der bei der Luca App “umgesetzt” wurde, kann damit zumindest nicht gemeint sein. So ist der Datenschutz auf der einen Seite nicht gewährleistet, kann aber gleichzeitig als Entschuldigung für weitere Mängel unserer Branche dienen.

Es ist ja nicht alles schlecht

Aber es gibt auch Lichtblicke. Ich war an Softwareprojekten beteiligt, die unter anderem auch personenbezogene Gesundheitsdaten verwaltet haben. Dort war sehr präsent, dass diese Daten besonders geschützt werden müssen und dementsprechend wurden diese Herausforderungen adressiert. Auch in vielen anderen Kontexten habe ich beispielsweise die Anforderungen durch die Datenschutzgrundverordnung DSGVO als wesentlich für Architektur-Diskussionen erlebt. Und natürlich gibt es für die Kontaktverfolgung-Anwendungen wie die Corona-Warn-App, die so konsequent auf Datenschutz ausgerichtet ist, dass sogar der Chaos Computer Club sie lobt. Und den bereits erwähnten Sicherheitsexpert:innen und vielen anderen, die hier gar nicht erwähnt werden, ist die Situation offensichtlich nicht egal, sondern sie arbeiten aktiv daran sie zu verbessern - wofür ich mich an dieser Stelle bedanken möchte.

Am Ende bleibt aber die unangenehme Frage, ob unsere Branche im Vergleich zu anderen Branchen verantwortungsloser handelt. So oder so sollten wir uns alle anstrengen, in Zukunft Sicherheitsprobleme in Software zu vermeiden. Das ist besser, als sich zu schämen. Und das Studium des Artikels in der c't oder die Werke der Sicherheitsexpert:innen kann ein guter erster Schritt sein, um Sicherheitslücken kennenzulernen und zukünftig zu vermeiden. Vielleicht wird unsere Branche dann endlich erwachsener und verantwortungsvoller.

tl:dr

Leider ist die Qualität von Software-Lösungen oft mehr als schlecht. Sich dafür zu schämen ist aber nicht so effektiv, wie die Situation zu verbessern.

Vielen Dank an Anja Kammer, Tammo van Lessen, Tanja Maritzen, Joachim Praetorius, Max Schröter, Stefan Tilkov und Jan Seeger für die Kommentare zu einer früheren Version des Artikels.

()