© Irina Tischenko, 123RF.com

Obwohl sie keinen Zugriff auf die Endgeräte haben, tragen Administratoren für Smartphones und Tablets auf Android- und I-OS-Basis viel Verantwortung. Die kleinen Touchdevices erweisen sich als schwächstes Element der Sicherheitskette und lassen sich nur unzureichend in die eigene IT-Verwaltung integrieren.

Smartphones und Tablets haben aktuellen Studien zufolge das Auto als liebstes Statussymbol abgelöst, zumindest bei jungen, urbanen Deutschen [1]. Das sorgt nicht nur für Freude, denn dem Administrator in der Firma stehen schnell die Haare zu Berge, wenn er den dringlichen Anwenderwunsch [2] erfüllen und so einem “Spielzeug” den Zugang ins abgesicherte WLAN der Firma gestatten soll. Erschwerend kommt hinzu, dass die speziell auf Smartphones ausgerichteten Bedrohungsszenarien über Trojaner, Viren und Backdoors zunehmen [3].

Sichere Endgeräte

Plattformen wie Android, aber auch das proprietäre I-OS leiden unter den vielen Möglichkeiten, die sie ihren Benutzern geben. Weil aber gerade darin auch der Erfolg der smarten Geräte liegt, wollen die Benutzer es sich auch nicht nehmen lassen, Apps auszuprobieren oder am System herumzubasteln. Verstärkt wird dies noch durch die Update-Politik der Smartphone-Verkäufer: Selbst Googles Patch für die WLAN-Lücke vom Mai dieses Jahres beispielsweise (siehe Artikel auf Seite 40) lässt für fast alle Androiden auf sich warten, weil sich Hersteller und Provider auf die neuen Smartphones in ihren Shops konzentrieren.

Research in Motion und T-Systems, die Hersteller von Blackberrys und der Simko-Telefone, gehen da andere Wege. Hier hat der Hersteller vollen Zugriff auf ein in Eigenregie entwickeltes oder gehärtetes Betriebssystem. Anders als bei I-OS oder Android können die Anbieter umfangreiche Funktionen Server-seitig vorgeben, inklusive vollständiger Konfigurationen und umfassender Device-Policies. Apple verspricht zwar ähnliche Sicherheitsfeatures, doch wie der Abschnitt zu Active Sync (unten) zeigt, lassen sich diese relativ einfach über Jailbreaks aushebeln.

Simko2

Ein “sicheres Endgerät” kann derzeit, glaubt man dem Hersteller T-Systems, nur das zertifizierte “Merkel-Phone” Simko2 bieten (Abbildung 1, [5]). Bei ihm haben die Entwickler vom Bootloader bis zur Oberfläche das komplette System nach Sicherheitsgesichtspunkten entworfen. Selbst das Booten eines alternativen ROM ist laut Hersteller unmöglich. Die verwendete Software arbeitet wie ein Zustandsautomat, der beispielsweise den Zustand “Greife auf den Speicherbereich XY zu” nicht kennt. So verhindern die Entwickler den Zugriff auf einen Key oder ein Zertifikat, die funktionsbedingt im Arbeitsspeicher ohne Verschlüsselung bereitstehen müssen.

Abbildung 1: Das auf Sicherheit optimierte Simko2-Telefon basiert auf Windows Mobile, am Nachfolger auf Android-Basis arbeitet T-Systems bereits.

Ob diese Vorgehensweise gegen Hardcore-Angriffe etwa auf Prozessorebene hilft, sagt der Hersteller nicht, denkbar wäre ein derartiger Angriff aufgrund der verwendeten Hardware doch. Dennoch verspricht die BSI-Zertifizierung der Simko-Geräte deutlich mehr Sicherheit als bei allen Konkurrenten, klassifiziert sie die Telefone doch als tauglich für sichere Umgebungen.

Die nächste Simko-Version soll auf Android aufbauen, zusammen mit einem Dualboot-System, bei dem der Anwender schon beim Einschalten des Smartphones zwischen seiner privaten und der sicheren Firmenumgebung wählt. Glaubt man dem Hersteller, dann integriert sich Simko sehr einfach mit Open-Source-Software im Backend: Problemlos soll etwa die Anbindung an die drei großen freien Groupwares Kolab, Zarafa und Open-Xchange funktionieren.

Auch Google hat das Problem der sicheren Plattform erkannt und schickt mit seinen Device Policy Apps for Android [5] eine eigene Anwendung ins Rennen. Die setzt einen kostenpflichtigen Google-Apps-Account voraus, bietet aber nicht viel: Die Sicherheitsrichtlinien, die sich erzwingen lassen, umfassen gerade mal sichere PINs und Passwörter, automatisches Sperren des Bildschirms und den Remote Wipe, also das Löschen eines verlorenen oder gestohlenen Gerätes.

Anders als die meisten Anbieter mobiler Sicherheitssoftware – in der Regel die gleichen Firmen, die auch den Windows-Desktop abzusichern versprechen, zum Beispiel Juniper [6], Kaspersky [7] oder Symantec [8] – bietet Googles Device-Policy-Software aber auch ein API, das andere Apps nutzen können, um die Sicherheit des Geräts sicherzustellen, etwa bevor das Firmen-VPN online geht.

Die Antivirenhersteller konzentrieren sich auf ihr Kerngeschäft: Den Scan von Daten nach den Signaturen bekannter Malware. Zwar bieten auch sie Funktionen wie Remote Wipe, doch die allein rechtfertigt die Installation nicht, bieten dies doch bereits viele Provider oder Hersteller ihren Kunden [9].

Aber auch wer sich der Thematik aus der Richtung des Device- und Policy-Managements via Active Sync [10] nähert, erlebt einige Überraschungen. Die Open-Source-Implementierung Z-Push [11] ist in weiten Teilen kompatibel mit Microsofts Active-Sync-Protokoll und erlaubt dem Admin Workarounds bei Inkompatibilitäten. Aber wie alle Synchronisationstools ist auch Active Sync von der Umsetzung und Interpretation auf den Geräten abhängig, und dort finden sich gravierende Unterschiede.

Weil die Betriebssysteme das Einhalten dieser Regeln sehr unterschiedlich sicherstellen, ist Active Sync im direkten Vergleich etwa den Blackberrys unterlegen. RIM hat mit seinem eigenen Betriebssystem alle Möglichkeiten in der Hand, das Regelwerk Server- und Client-seitig zu implementieren.

Active Sync

Bei Active Sync dagegen kennt jedes Gerät, OS und sogar jede einzelne Version eigene Features oder Subsets von Funktionen. Besonders die Android-Versionen sind hier sehr unterschiedlich, die Hersteller verändern die ROMs, sodass ein Android 2.3.3 auf einem HTC andere Funktionalitäten aufweist als ein Samsung mit 2.3.3. Microsoft hat für Active Sync eine Übersicht veröffentlicht, in der sich die Verschiedenheit als echtes Problem erweist [9]. Selbst zwischen Windows Mobile 6.5 und 7 gingen viele sicherheitsrelevante Funktionen verloren.

I-OS-Policies

Auch in I-OS finden sich spezielle Probleme. Grundlegende Policies, zum Beispiel das Erzwingen eines Passworts, funktionieren zwar und gestatten minimale Sicherheit für den Firmenzugriff. Die Policy, die das Benutzen des Browsers untersagt, sorgt zwar dafür, dass Safari verschwindet, aber Apps mit integriertem Browser oder Alternativen wie Opera sind nicht betroffen.

Im freien I-OS-App-Store Cydia (verfügbar auf Geräten mit Jailbreak) ist vom “Exchange Unlock” die Rede, einer einfachen Möglichkeit, die Passwort-Policies auszuhebeln. Und wer das Active-Sync-Profil löscht, hat sofort alle verbotenen Funktionen wieder verfügbar. Prinzipiell sind damit zwar auch alle Daten auf dem Gerät gelöscht, doch ist eine Wiederherstellung mit Forensik-Tools denkbar (siehe Artikel auf Seite 40). Beim Remote-Wipe jedoch wird wohl die gesamte Datenpartition formatiert.

Für Active Sync ist aber ein Server nötig, von dem aus der Admin die Einstellungen verwaltet. In der Regel ist das ein Exchange-Server, aber auch Kolab, Open-Xchange oder Zarafa unterstützen das Protokoll via Z-Push.

Sebastian Kummer, Z-Push-Entwickler bei Zarafa, sagt dazu im Gespräch mit dem Linux-Magazin: “Z-Push orientiert sich am Active-Sync-Protokoll und wir planen alle angebotenen Policies zu unterstützen. Aber es ist eine schwierige Aufgabe, den Administrator genau zu informieren, welche Auswirkungen einzelne Policies je nach Gerät haben. Prinzipiell unterscheiden wir zwischen Aktionen, die ein Benutzer selbst ausführt, wie zum Beispiel Remote-Wipe (Abbildung 2), und Funktionalitäten, die dem Systemadministrator vorbehalten sind.”

Abbildung 2: Remote Wipe steht für das aus der Ferne angestoßene Löschen aller Daten auf dem Smartphone – eine Active-Sync-Funktion, die auch die Open-Source-Groupware Zarafa umsetzt.

Der Remote-Wipe, erzählt Kummer, sei neben dem GUI auch über ein CLI-Tool möglich, das in Zukunft auch Policies setzen oder Geräteklassen (“Alle Smartphones mit Android 2.X vom Hersteller XY.“) und Benutzergruppen mit individuellen Vorgaben verwalten wird.

Das hat jedoch Grenzen. Beispielsweise wird es allgemeingültige Black- und Whitelists für verbotene und erlaubte Apps wahrscheinlich nie geben, weil die Systeme zu unterschiedlich mit solchen Werten hantieren. Experten sprechen von “Broken by Design” (Kummer), weil es keine Möglichkeit gibt, eine App plattformübergreifend zu identifizieren. Die Hersteller haben eher die Vermarktung via Market und Store im Fokus, nicht primär die Sicherheit der Anwender.

Sichere Datenübertragung

Viele Entwickler glauben ohnehin eher daran, dass sich der Trend zu Thin-Client-Endgeräten durchsetzen wird. Eine Idealvorstellung vieler Sicherheitsarchitekten ist ein schlankes Gerät, das nur noch einen Bildschirm für die Inhalte darstellt. Eine SAP-App beispielsweise läuft dann nicht auf dem unsicheren Device, sondern auf der Serverfarm in der privaten Wolke. Dabei muss der SAP-Server – wie alle anderen Dienste – über ein Plugin verfügen, dass die Darstellung für das jeweilige Endgerät optimiert.

Analog zu individuellen CSS-Stylesheets kämen dann die Daten in einer eigenen, angepassten Darstellungsform auf das Smartphone. Je nach Bildschirmauflösung und Eingabegerät zeigt sich so dem Nutzer eine andere Ansicht und die Sicherheit des Clients ließe sich auf sichere Verbindungen beschränken.

Geht die Hoffnung der Smartphone- und Tablet-Hersteller auf, dann naht das Ende des PC-Desktops. Doch damit erwächst auch ein großes Problem. War es in den letzten Jahrzehnten Sache der Firmen-IT, dafür zu sorgen, dass der Arbeitsplatz eine sichere Plattform für den Zugriff auf die Unternehmensdaten ist, hat der Admin heute (fast) keinen Einfluss mehr auf die Endgeräte (siehe Kasten “Kommentar: Kontrollverlust”).

Während Simkos und Blackberrys mit großem Aufwand dafür sorgen, verlässliche Kommunikationsplattformen zur Verfügung zu stellen, stellt sich die Situation bei Apple und Android anders dar. Die Funktionalität der einschlägigen Security-Software reduziert sich auf Malware-Protection, Remote-Wipe und Funktionen, die schon die Provider anbieten. Auch Googles Device-Policy-API vermag es bis heute nicht, Zustand und Anzahl der installierten Apps auf dem Gerät zu reglementieren.

Obwohl mit Active Sync und Z-Push vieles möglich ist, macht auch hier der Wildwuchs an Implementierungen Herstellern und Admins zu schaffen. Sehr wahrscheinlich bleibt den IT-Abteilungen in Unternehmen gar nichts anderes übrig, als die Zugriffswege und die Informationen selbst abzusichern. Sichere Endgeräte gibt es auf Basis von Android und iPhone auf absehbare Zeit erst mal nicht.