Cyber-Security I: Massive Sicherheitslücken in deutschen Gesundheitsämtern – keinen interessiert es

Sicherheit (Pexels, allgemeine Nutzung)In deutschen Gesundheitsämtern gibt es massive Sicherheitslücken in den IT-Systemen, die zwar bekannt sind, bisher aber nicht geschlossen wurden. Konkret geht es um die dort eingesetzte Software Mikropro Health. Die Verantwortlichen belieben darüber hinweg zu sehen oder die Sicherheitsprobleme weg zu diskutieren. Auch der Landesdatenschutzbeauftragte von Rheinland-Pfalz siehe da vorerst kein Problem. Es ist also absehbar, dass es da früher oder später zu einem Datenskandal oder Cybervorfall kommt, von dem eventuell vertrauliche Gesundheitsdaten betroffen sind.


Anzeige

Mikropro Health ist eine Software der Mikroprojekt GmbH, die für Gesundheitsämter entwickelt wurde. Laut Webseite der Firma können Gesundheitsämter mit der Software sehr brisante persönliche Informationen wie Medizinalkarteien des Amtsärztlichen Diensts, Röntgen- und Tuberkuloseuntersuchungen, etc. speichern bzw. verwalten.

Mikropro Health

Daher sollte man davon ausgehen, dass diese Software besonders gesichert ist. Diese Annahme ist aber weit gefehlt, wie die Zeit aufdeckt (Artikel hinter einer Paywall). Golem hat die Kernaussagen in diesem Artikel zusammen gefasst.

Cybersicherheit in Gesundheitsämtern

Bei der Lektüre des Themas kristallisieren sich gleich mehrere Problemkreise in den Gesundheitsämtern heraus, die sich zum Sicherheitsrisiko summieren.

  • In den Kommunen, die als Träger der Gesundheitsämter fungieren, fehlt schlicht das Geld und das Wissen, um die hausinterne IT sicher zu betreiben. Also werden statt IT-Fachpersonal Verwaltungsfachangestellte mit der Betreuung der IT der Gesundheitsämter betraut.
  • Dieses Personal muss die in den Gesundheitsämtern eingesetzte einheitliche Plattform-Software Mikropro Health administrieren. Diese Software dient als einheitliche Datenverarbeitungsplattform, entspricht aber nicht mehr dem Stand der Technik und weist Schwachstellen auf.

Das mit den Sicherheitslücken hat eine externe Analyse der Software ergeben, die Mikropro Health gleich mehrere Schwachstellen attestiert. So werden die Zugangsdaten eines Benutzerkontos zur Ersteinrichtung aus dem Quellcode bezogen. Das Konto kann auf alle Daten (lesend und schreibend) zugreifen, weitere Konten erstellen und diesen umfassende Rechte zuweisen. Nur wenn der Administrator bei der Ersteinrichtung das Passwort geändert hat, ist diese Schwachstelle gestopft.

Die Software Mikropro Health speichere die Passwörter der Nutzer bei bestimmten Anwendungen standardmäßig im Klartext, heißt es weiter in der Analyse, und die in Mikropro benutzte Datenbank lässt in der Standardkonfiguration beliebige SQL-Abfragen zu. Eine Überprüfung, ob der Nutzer überhaupt dazu berechtigt sei, ist nicht vorgegeben. Benutzer mit Datenbankzugriff können also auf alle Daten zugreifen und diese auch ändern oder löschen. Ändern lässt sich dies vom Administrator, dem aber üblicherweise die dafür erforderlichen Kenntnissen fehlen.

Weiterhin ist das Berechtigungskonzept der Software schlicht kaputt, heißt es. Denn die Fachbereiche eines Gesundheitsamts können auf die Daten aller anderen Fachbereiche zugreifen und dieses Einsehen, heißt es bei Zeit Online.


Anzeige

Laut Bericht kann auch der Support des Herstellers (Mikroprojekt GmbH) auf alle Daten der Gesundheitsämter zugreifen. Zur Fehlersuche werde häufig die Übertragung der gesamten Datenbank in unverschlüsselter Form angefordert. Aus DSGVO-Gründen eigentlich unzulässig, aber Behörden droht dort keinerlei Strafe.

So ist der Datenschutzbeauftragte von Rheinland-Pfalz, wo die von Zeit Online zitierten Probleme festgestellt wurden, recht locker. Der rheinland-pfälzische Landesdatenschützer Dieter Kugelmann sieht laut Zeit Online keine Probleme. Der Behörde lägen keine Hinweise zu Schwachstellen vor, lässt er mitteilen, und hat bislang keinen Grund, datenschutzrechtliche Bedenken gegen die Digitalisierungsstrategie der Landesregierung zu äußern. Der Landesdatenschutzbeauftragte schiebt die Verantwortung für die Datensicherheit auf die Kreisverwaltungen ab, da diese für "die Datensicherheit verantwortlich" seien.

Das Thema ist nicht auf Rheinland-Pfalz beschränkt, sondern betrifft auch Gesundheitsämter in anderen Bundesländern. Zeit Online schreibt, dass die eingesetzte Technik veraltet sei und die Verantwortlichen vor Sicherheitslücken gewarnt worden waren. "Sie wussten von ihnen – und änderten dennoch nichts an ihren Plänen", heißt es.

Artikelreihe:
Cyber-Security I: Massive Sicherheitslücken in deutschen Gesundheitsämtern – keinen interessiert es
Cyber-Security II: IT-Planungsrat empfiehlt Kommunal-IT von NIS-2-Richtlinie auszunehmen

Ähnliche Artikel:
Stillstand nach Cyberangriffen auf Kommunen in Südwestfalen und Parkhäuser in Osnabrück
Cyberangriff auf Südwestfalen IT trifft mindestens 103 Kommunen
Neues zum Cyberangriff auf Südwestfalen IT


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

9 Antworten zu Cyber-Security I: Massive Sicherheitslücken in deutschen Gesundheitsämtern – keinen interessiert es

  1. Norddeutsch sagt:

    Moin. Wer von Euch hat Detailwissen über den "Bericht", wer hat auditiert? Gibt es den irgendwo online, zB Informationsfreiheitsgesetz?
    Oder ist das lediglich der "Bericht" von "Zeit" hinter Paywall?

    • Günter Born sagt:

      Obige Zitate beziehen sich auf den Zeit Online-Bericht. Aber es gibt den Bericht des hessischen Datenschutzbeauftragten, der der gegenüber dem hessischen Landtag diesen Datenschutzbericht von 2004 (man höre und staune) vorgelegt hat. Sucht man nach "Micropro healt", wird man auf Seite 51 fündig. Gibt dort zwar noch Aussagen zu anderen Programmen – aber was oben zu Problemen wie Initial-Passwort oder Datenbankabfragen geschrieben wurde, findet sic im Bericht aus Hessen ebenfalls – zumindest nach meiner Lesart.

  2. R.S. sagt:

    Eigentlich sollte man den Landesdatenschutzbeauftragten fristlos feuern!
    Er macht seinen Job nicht.
    "Kein Problem" in den Sicherheitslocken zu sehen ist schlicht Arbeitsverweigerung!
    Und wenn diese Sicherheitsprobleme seit 2004, also seit satten 19 Jahren, bekannt sind, hätte man den Softwareanbieter schon sehr lange zur Schließung der Lücken zwingen müssen anstatt diese Software weiter zu nutzen.

    Und was die Strafen angeht:
    Könnte man evtl. die Mitarbeiter der Behörden bestrafen, die die Datenbank unverschlüsselt an den Softwareanbieter senden?

    • Norddeutsch - Amt! Pass ja uf use Omas Daten uff! sagt:

      … das ist ein "wenig" komplexer als "feuern" & "bestrafen" (auch wenn ich den verzweifelten Ansatz nachvollziehen kann).
      Bin kein Verwaltungsrechtler – mir fallen Ansätze ein wie "Verletzung einer Dienstpflicht" oder " Überprüfung von Zweckmäßigkeit + Rechtmäßigkeit". Damit landet man fix bei Fachaufsichts- (siehe Wiki) oder Dienstaufsichts-Beschwerde (Wiki hier).
      Da im öff.Dienst die Rechtsfolgen eher intransparent (für Beschwerdeführer) sind wär der "Hebel" wohl als Skandal oder öffentliche Hilfe+Awareness in der Stadtzeitung größer…

      Interessanter wäre mE der Ansatz bei privatwirtschaftlichen Unternehmen vom SW-Lieferanten bis zum Dienstleister anzusetzen [ Buzzwords: AG, GmbH, DSGVO, Hoster, mittels Presse agieren: Das Gesundheitsamt kann Omas, Babies und Weihnachten zerstören (Insiderironie aus anderem Thread ].

      • Joe sagt:

        Moin,
        es ist sehr schön erklärt, wozu diese Arten von "Beschwerden" genutzt werden könnten, allerdinsg fehlt eine grundlegende Voraussetzung: der ergangene Verwaltungsakt.

        Zur Erläuterung:
        "Verwaltungsakt ist jede Verfügung, Entscheidung oder andere hoheitliche Maßnahme, die eine Behörde zur Regelung eines Einzelfalls auf dem Gebiet des öffentlichen Rechts trifft und die auf unmittelbare Rechtswirkung nach außen gerichtet ist."

        Man kann sich jetzt aussuchen, welche der dort beschriebenen Aktivitäten der Behörde (hier Gesundheitsamt) alle nicht zugetroffen haben, da nicht bekannt ist, ob ein VA erlassen wurde und welchen Inhalt dieser VA hatte und wer für diesen VA die Verantwortung übernommen bzw. diesen unterzeichnet hat.

        Gesetzt den Fall, man hat den Mitarbeiter bzw. Sachbearbeiter der Kommune ausfindig gemacht, dann ist der sofort aus der Sache "Bestrafung" raus, da er in seinem Sachgebiet zwar selbständig arbeiten darf, aber die Aufgaben immer "im Auftrag" des Dienstvorgesetzten erledigt. Klettert man jetzt die Stufen der Vorgesetzten hinauf, so findet man dort (falls vorhanden) eine Abteilungsleiter, einen Fachbereichsleiter, einen Dezernenten und schlußendlich den Amtsleiter. Eigentlich wäre hier jetzt Schluß (für den Bereich Gesundheitsamt), aber da die Aufgabe "Gesundheitsdienst" eine Aufgabe der Kreisverwaltung ist, geht das Treppensteigen weiter über einen Dezernenten zum stellv. Landrat und zuletzt zum Landrat. Und soweit der nichts anderes angeordnet bzw. verfügt hat (VA), arbeiten alle Positionen unter ihm "im Auftrag", sind also von der Zuständigkeit her freigestellt.

        Man sieht, es ist zwar einfach, nach "Bestrafung" zu rufen, aber man muß auch sehen, daß man den Reiter und nicht den Esel trifft.

        Was ich in dem Zusammenhang nicht verstehe:
        "Laut Bericht kann auch der Support des Herstellers (Mikroprojekt GmbH) auf alle Daten der Gesundheitsämter zugreifen."
        Wenn der Support doch Zugriff auf die Daten aller Gesundheitsämter hat, warum kann der nicht direkt auf die Daten zugreifen, sondern muß die in unverschlüsselter Form anfordern?

        Ein andere Punkt ist:
        "Benutzer mit Datenbankzugriff können also auf alle Daten zugreifen und diese auch ändern oder löschen. Ändern lässt sich dies vom Administrator, dem aber üblicherweise die dafür erforderlichen Kenntnissen fehlen."
        Also der lokale Admin hat keine Kenntnisse, wie er die Rechte für Benutzer mit Datenbankzugriff ändern kann, soll aber den Datenbestand von "verschlüsselt" in "nicht verschlüsselt" ändern, damit der so an den Support geliefert werden kann? (Ich hab jetzt mal den Admin als dafür zuständigen Mitarbeiter vorausgesetzt, wer sonst sollte das machen (können)?).

        • Norddeutsch sagt:

          @Joe – Danke für die sehr fundiert begründete Ergänzung. Genau in diesem Reiter/Esel-Umfeld scheint mir Verantwortlichkeit und Haftung im öff.Dienst schon lang verbesserungswürdig. Weiss nun, warum ich Verwaltungsrecht und VA nicht mag :-)

          Deine Frage "..Daten..muß die in unverschlüsselter Form anfordern?": Ist mE operatives Managementdefizit, schlechte Praxis der Software (Abk.:SW); gepaart mit defizitärer Modellierung von SW + DBs.
          Kenne dies zigfach bei Individualsoftware und "Fachanwendungen", es ergibt sich oft folgende Kette:
          1. OK: SW + Datenbestand wird genutzt, macht mal Probleme
          2. OK: Organisation ruft nach Support
          3. GUT: SW ist oft lokal, nicht (permanent) connected/online
          4. KRITISCH: Support fordert Logfiles oder DB an
          5. FAIL: Organisation o. Mitarbeiter liefert Daten zu Problem: Genutzt wird Email, USB Stick bis zu Vollzugriff auf einen Server. Daten werden dadurch mehrfach instanziiert, ausgeleitet oder nicht mehr konform managebar. Recht? Data Governance? Komplett ausser Kraft gesetzt.

          Dein Thema "Ein andere Punkt ist…Datenbankzugriff"
          Hier vermischt sich mE Deine Sicht von "lokalem IT-Management" mit dem "Rechte-Rollen-Konzept".
          1. Ein falsch ausgerolltes o. konfiguriertes Rechtemanagement erlaubt dem User aus organisatorischer und rechtlicher Sicht oft unzulässig viel: Weil es nicht existiert, verstanden wurde oder "zu anstrengend" in Implementierung ist.
          2. Verschlüsselung alleine ist mE hier nicht die Frage. Verschlüsselung ist neben Dingen wie Zugriffs-, Ausleitungs oder Modifikationsrecht nur ein Teilaspekt der Datenhaltung und -verarbeitung sowie Data LifeCycleManagement.
          3. Die Organisation und die Admins benötigen eigentlich mehrere Dinge, um sauber o. Rechtskonform agieren zu können: Von implementierter SW-Option oder Vorgehensweise bei Datenausleitung hin zum Support (Neudeutsch einem "Prozess") … bis zum vernünftig umsetzbaren und auf die Organisation adaptierten Rechtekonzept.

          Auflösen lässt sich dies imho nur durch saubere Konzepte für { | Rechte | Rollen | Modellierung | Use-Cases | Pflichtenheft | Administration | }

          Somit zeigen sich hier Defizite bei: Planung, Implementierung, Einführung, Betrieb und Organisation.

          Welcome to "Digitalisierung per Dekret" im besten Deutchland aller Zeiten.

          • R.S. sagt:

            Mir scheint auch, so wie sich die Software darstellt, das die Software ein über 20-30 Jahre gewachsenes Produkt ist.
            Und damals hat man sich überhaupt gar keine Gedanken um Zugriffsrechte o.Ä. gemacht.
            Das war bei der Softwareentwicklung gar kein Thema und auch die damalige IT kannte so etwas kaum.
            Software lief z.B. auf PCs mit FAT/FAT32-Dateisystem, das so etwas wie Berechtigungen etc. gar nicht kennt.
            Und wenn Unix o.Ä. eingesetzt wurde, dann hat man sich um die Rechte nicht gekümmert oder um "Problemen" aus dem Weg zu gehen, die Rechte gleich auf 777 gesetzt.
            Auch von Haus aus waren die Systeme damals ziemlich unsicher (ich habe da z.B. bei diversen Unix-Systemen eine von Usern beschreibbare etc/passwd gefunden, was sämtliche Sicherheitseinstellungen komplett aushebelt).
            Und wenn man solche Software dann mit der alten Codebasis nur weiterentwickelt, fehlt es eben auch an Sicherheitssystemen.
            Um da so etwas wie ein Sicherheitssystem rein zu bekommen, müsste man bei 98% aller derartig alter Softwarebasis von 0 neu anfangen das zu programmieren und die alte Codebasis wegwerfen.
            Ein Sicherheitssystem lässt sich in derart gewachsener Software nämlich so gut wie gar nicht nachträglich einbauen.

          • Joe sagt:

            Moin,
            ich hab das von Dir Angemerkte extra mal außen vorgelassen, da man dazu die genauen Umstände wissen müßte, wer wie was angeordnet und/oder zugestimmt hat und wer von den potentiellen Verantwortlichen einen
            Auftrag für eine sog. "Auftragsdatenverarbeitung" unterschrieben und welche Modalitäten dort vereinbart wurden.
            Vom Grundsatz hast du natürlich Recht, daß es von vorne herein eine Regelung geben muß, wer wann was wo und wie auszuführen hat und wer schlußendlich die Verantwortung dafür übernimmt oder übertragen bekommt.
            Nur dann stellt sich da auch wieder die Frage, wer hat da den Durchblick?

            In welcher Kommunalverwaltung gibt es heute noch einen "hauptamtlichen" Admin, also jemanden, der sich nur und ausschließlich um die EDV und alles was damit zusammenhängt, kümmert? Bei den kleinen Verwaltungen (ich schätze mal so in der Größe von 20.000 – 25.000 Einwohner)
            ist das meist ein Angestellter, der seinen EDV-Job aber neben seiner eigentlichen Aufgabe wahrnehmen muß. Ob der nur entsprechende Kenntnisse auf dem Gebiet hat, oder nur dahin gekommen ist, weil er "schonmal einen PC aufgeschraubt hat", überlaß ich der Phantasie des geneigten Lesers. Und nach oben hin in der Hierarchie ist immer weniger "Wissen" aus dem EDV-Bereich vorhanden, denn "dafür hat man ja seine Leute". Davon ausgenommen sind die Art von Vorgesetzten, die mit einem "Pseudo-Wissen" der Art "das geht zu Hause mit meinem PC aber …" aufwarten.
            Es klemmt also nicht nur oben in der Hierarchie, sondern zieht sich durch alle Verantwotlichkeitsstufen nach unten durch.

  3. Erwecker sagt:

    Meine persönlichen Erfahrungen mit dem Landesdatenschutzbeauftragten (m/w/d) von RP:

    – Glänzt durch Untätigkeit und genehmt man sich doch tätig zu werden: Absolut Inkompetent

    Scheint hier bestätigt zu sein.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.