Wenn technische Reports lügen

Welcher Datenschutzbeauftragte prüft schon, ob das stimmt, was auf dem ihm ausgehändigten IT-Sicherheitsreport steht? Welches Mitglied der Unternehmensführung kontrolliert nach, ob die Passwörter der Mitarbeiter wirklich gemäß der vorhandenen Richtlinie nach zu vielen Falscheingaben gesperrt werden? Und welcher IT-Dienstleister prüft wirklich jede Woche, ob die Sicherung funktioniert indem er die Sicherungsdateien tatsächlich von Hand prüft anstatt die Reports zu lesen?

Richtig. Niemand. Naja, fast niemand. Wir schon.

Wieso sollte man sich diese lästige Arbeit auch doppelt und dreifach machen, vor allem wenn man regelmäßig Hochglanz-Reports per E-Mail bekommt?

IT Automatisierung: Fluch und Segen

Automatisierung ist seit vielen Jahren das Zauberwort in der IT Branche. Die vermag viele Arbeitsschritte positiv zu beeinflussen, birgt aber genau so viele große Risiken. Alle Arbeitsschritte, die automatisiert werden, müssen wohldurchdacht und wohlüberlegt sein.

Viele Kontrollarbeiten kann man gut automatisieren.

Alle 60 Sekunden zu prüfen, ob genügend Speicherplatz auf einem Server vorhanden ist, lässt sich zuverlässig über ein vollautomatisches Monitoringsystem prüfen.

Andere Arbeitsschritte wiederum sind mit viel Vorsicht zu genießen.

Grenzen der Automatisierung

Ich erzähle aus einem echten Fall bei einem Neukunden, dem auch wir nicht helfen konnte. Er sah sich einem kompletten Datenverlust konfrontiert, weil er aus Kostengünden statt professionelle Hilfe zu suchen erst drei Wochen lang selbst versucht hat, an einem falsch konfigurierten Server nach Datenverlust die Reparatur durchzuführen.

Dies hätte sich vermeiden lassen, wenn man sich eben genau nicht auf die im Fehlerfall per E-Mail bereitgestellten Warnungen verlassen hätte.

Was war passiert?

Wie sich durch unsere Untersuchungen herausstellte, war die Sicherungssoftware so konfiguriert, dass diese jede Nacht automatisch Sicherungen erstellte. Diese wurden zunächst lokal als Imagedatei aufbereitet und dann auf externe USB Festplatten weggeschrieben.

Die externe Festplatte lief irgendwann voll. Normalerweise hätte die Software nun den Admin darüber informiert, dass die Sicherung nicht mehr funktioniert.

Leider hatte der Kunde aus Kostengründen den E-Mail-Provider gewechselt. Nach dem Umzug wurde nie kontrolliert, ob alle Systeme weiterhin E-Mails über den neuen Server senden können. Die Sicherungssoftware konnte das nicht mehr und so gab es keine Benachrichtigung mehr über die fehlgeschlagenen Sicherungen.

Es kam, wie es kommen musste. Billig-RAID Controller im Server, der eigentlich kein richtiger ist („fake raid). Warnungen die nicht funktionieren. Uralte Festplatten die sterben wie die Fliegen. Bis irgendwann der kritische Punkt erreicht ist. In diesem speziellen Fall war der leider schon erreicht, als eine einzige Festplatte im Server kaputt war. Selbst schuld. Mit der nächsten gab es es den Totalausfall.

Worauf ich hinaus will ist nicht der konkrete Fall als solches, sondern wie wichtig es ist, das Bewusstsein für die Tragweite der richtigen Datenquelle zu schärfen. „manpower“ kann auch in unserer IT Welt (heute noch) nicht vollständig ersetzt werden. IT Systeme sind nur so gut wie die Köpfe, die sie entwickelt haben. Und das sind heute leider meistens nicht unbedingt die Hellsten. Geschweige denn, irgendwann einmal programmieren richtig gelernt zu haben. Links oder rechts über den Tellerrand schauen Fehlanzeige, das steht nicht im Pflichtenheft.

Technische und rechtliche Folgenschwere

Besonders problematisch wird es technisch gesehen immer dann, wenn es sich um „kritische“ Systeme handelt. Also hier solche IT-Umgebungen, die entweder für das Unternehmen essentielle Dienste darstellen (z. B. Telefonanlage, Internetzugang oder auch E-Mail Server) oder aber deren Nicht-Verfügbarkeit nur im Bedarfsfall festgestellt wird und genau dann aber ein riesiges Problem darstellt (obiges Beispiel: Datensicherung).

Haftungsfrage

Zunehmend stelle ich mir aber auch die Frage, wer haftet eigentlich dafür, wenn sich auf falsche oder fehlerhafte Reports verlassen wird?

Nur durch einen ganz konkreten Praxisfall, der sicherlich in der Konstellation sehr „besonders“ ist, mussten wir eine Einschränkung herausfinden die uns sonst nie bewusst gewesen wäre. Und vermutlich auch den wenigstens anderen Admins bewusst sein dürfte.

Für die, die nicht so viel Zeit mit dem Lesen verbringen möchten – Spoileralarm – wenn eine MDM Lösung behauptet der Benutzer könne keine Apps mehr auf seinem Apple iOS Gerät installieren, dann muss das nicht der Wahrheit entsprechen.

Reports für DSB fehlerhaft sobald es um iPhones geht

Anders ausgedrückt: Wenn der DSB sicherstellen will, dass Mitarbeiter keine eigenen Apps auf deren Firmenhandys installieren können, dann muss er das von Hand prüfen. Im Ergebnis muss die Firma dann wohl einfach auf Apple Geräte verzichten, weil im Moment – bzw. seit Herbst 2019 – bei Apple einfach nichts mehr auch nur ansatzweise zuverlässig funktioiniert¹⁾https://www.itk-security.de/preise/#Mehraufwand_durch_schlecht_programmierte_Software.

Der Sachverhalt im konkreten Beispiel

Auslöser des Ganzen war die Vorabeinrichtung von zwei nagelneuen iPhones in unserer Werkstatt für einen Kunden. Beide Geräte wurden exakt identisch eingerichtet. Eines lag links und eines lag rechts vor mir. Ja, ich habe die Einrichtung selbst durchgeführt, weil die Anforderungen des betreffenden Kunden sehr anspruchsvoll sind und ich die ziemlich absurde „ABM“ Einrichtung keinem meiner Mitarbeiter zumuten kann.

Nach diversem Wundern, Rückfragen bei Herstellern von Gerätesoftware und MDM Lösung, sowie weiteren eigenen Tests steht wieder einmal fest: Apple ist Müll. Für geschäftlichen Einsatz völlig ungeeignet.

Sowohl der allowUIAppInstallation als auch der allowAppInstallation MDM Payload erfordern ab iOS 13 ein supervised Device. Und da liegt der Hund begraben. Es ist nicht so, dass Apple das nicht auch so veröffentlichen würden. Nachzulesen ist das durchaus, und zwar auf den Apple Developer Seiten die jeder IT Admin natürlich jeden Abend vor dem Einschlafen komplett durcharbeitet und auswendig lernt: https://developer.apple.com/documentation/devicemanagement/restrictions²⁾https://developer.apple.com/documentation/devicemanagement/restrictions.

Die Hersteller von MDM Lösungen empfehlen normalerweise, Neugeräte über den Apple Business Manager³⁾https://www.apple.com/business/docs/site/Apple_Business_Manager_Getting_Started_Guide.pdf zu verwalten und darüber an die MDM anzubinden. Nur ist der Aufwand, so etwas für einen Kunden mit fünf bereits vorhandenen iPhones erstmalig aufzusetzen, exorbitant. Und ob das dann dauerhaft Besserung bringt sei mal ganz in den Raum gestellt nachdem Apple ja sogar schafft Updates zu veröffentlichen, die die Hardware zerstören⁴⁾https://www.itk-security.de/preise/.

Und zahlen will das sowieso keiner. Oder sind Sie etwa bereit, rund 50,- € monatlich dafür zu berappen, dass ihr iPhone richtlinienbasiert verwaltet wird?

Falsche Reports und keiner merkts

Zurück zum eigentlichen Problem. Apple ändert das Verhalten, wie die iPhones funktioinieren. MDM Hersteller sind nicht in der Lage, das auf deren Plattform (so schnell oder überhaupt) umzusetzen. Was dann passiert ist meines Erachtens ein Unding: Die Plattform zeigt weiterhin alles „grün“ an, obwohl es Einstellungen möglicherweise überhaupt nicht mehr gibt weil Apple diese entfernt hat.

Reports, die man über solche Plattformen generieren kann, sind demnach dann ebenfalls falsch. Nicht fragwürdig, sondern die Sicherheitsreports sind schlicht und ergreifend falsch. Arbeitet der DSB damit, so stimmen die Berichte des DSB in der Folge auch nicht. Ist das Grundlage für Wirtschaftsprüfer, so kann auch das Ergebnis der Unternehmensprüfung infrage gestellt werden.

Wieder einmal zurück zur Technik. Die Aussage manch MDM Herstellers dazu, dass die deaktivierten Funktionen gar nicht mehr gehen sollten, kann ich widerlegen. Ich habe ihm heute vier Praxisbeispiele schicken können von Kundengeräten, die eine iOS 13 Version aufgespielt haben und dennoch keinen App Store sehen (das war das Problem im konkreten Anwendungsfall). Weil das eben bisher auch immer funktioniert hat fiel auch nicht auf, dass die Funktion überhaupt fehlerbehaftet sein könnte.

Und so stelle ich wieder die bereits in den Raum gestellte Frage: wer haftet da eigentlich? Verantwortlich fühlt sich niemand:

1. IT Dienstleister: verlässt sich auf technische Konsole, die falsche Angaben zeigt
2. MDM Hersteller sagt: Apple ist schuld
3. Apple sagt: steht doch alles auf unserer Webseite⁵⁾https://developer.apple.com/documentation/devicemanagement/restrictions
4. DSB: verlässt sich auf Reports, die falsche Inhalte haben
5. Wirtschaftsprüfer verlassen sich auf die (fehlerhafte) Auswertung des DSB

Frage in den Raum an alle Datenschutzbeauftragten (DSBs) da draußen: habt ihr euch schon einmal ein Handy eines x-beliebigen Mitarbeiters geben lassen und tatsächlich versucht, eine kostenlose App zu installieren? Ging das oder ging das nicht?

Schönen Feiertag euch allen.