Gerade im Hinblick auf die compliancerelevante Informationssicherheit müssen Unternehmen große Sorgfalt wallten lassen. Firmen müssen die Verfügbarkeit, Vertraulichkeit und Integrität ihrer Daten jederzeit nicht nur auf Grund gesetzlicher Vorgaben sicherstellen. Dies kommt insbesondere bei Initiativen wie dem Bring your own Device (BYOD) zum tragen, wenn Unternehmen der Zugriff auf die Daten teilweise aus der Hand genommen wird.
Dabei spielt es prinzipiell kaum eine Rolle, welche Smartphones für den Unternehmenszweck ausgewählt werden oder welche Smartphones Mitarbeiter mit ins Unternehmen bringen und ins Netzwerk schleusen. Gefährdet sind alle Geräte, unabhängig vom laufenden Betriebssystem. Ein Lieblingsangriffsziel der Datendiebe hat sich jedoch heraus kristallisiert: Smartphones mit Googles Betriebssystem Android.Was man bisher nur von stationären PCs und Noteboks kannte, Viren, Würmer, Trojaner (Malware allgemein) wird zunehmend auch für Smartphone-Besitzer zum Problem. Besonders beim Unternehmenseinsatz mobiler Geräte stellt dies die hiesigen IT vor völlig neue Herausforderungen. Nicht nur das Mobile Device Management verlangt eine eingehende Auseinandersetzung mit dem Thema, auch die Gewährleistung der Datensicherheit mit möglichst geringer Benutzereinschränkung auf den privaten Geräten muss hierbei das Ziel sein. Richteten sich frühere Malware-Angriffe vorzugsweise per SMS oder Bluetooth primär auf eine Sabotage des mobilen Systems durch Blockieren oder Abstürzen, liegt der heutige Fokus der Malware-Programmierer auf dem Ausspähen von Daten und dem Entwenden von (Betriebs)Geheimnissen.
Für gewöhnlich gelangen die Viren per App-Download auf das private Smartphone. Apps bei Googles Androids "Play Sore" werden nicht direkt geprüft , bevor sie in den Store aufgenommen werden, sind diese Smartphones deutlich mehr gefährdet als Apples iPhone, Blackberry oder Microsofts Windows Phone. Bei diesen Betriebssystemen können nur Apps über die hauseigene Download-Portale installiert werden, welche vor Aufbahme überprüft werden. Somit gibt es für diese Plattformen keine Viren sondern (wenn überhaupt möglich) lauert die Gefahr in als nützliche (oft kostenlose) Anwendung, die im Hintergrund ansich geschützte Daten an den Programmierer senden.
Eine Lösung für dieses Problem ist ein Black- bzw. Whitelisting der zugelassenen und vom Unternehmen geprüften Apps. Beim Blacklisting werden alle Apps aufgeführt, die nicht erlaubt sind, wohingegen beim Whitelisting die Apps aufgeführt sind die explizit erlaubt sind. Letzteres ist für das Unternehmen deutlich leichter, bringt allerdings auch im BYOD Konzept die meisten Einschränkungen für die privaten Smartphones mit sich.
Eine Sicherheitsanforderung am Testgerät nachweisen. Prüfen Sie beispielsweise, ob ein gesperrtes oder verlorenes Smartphone noch geschäftliche Informationen preisgibt. Halten Sie das Ergebnis zusammen mit Konfiguration, Systemstand und erforderlicher Folgemaßnahme fest.
{tmamazon asin="B0HCK3HKX1" layout="card" align="none" label="ISO27001 – Alles was man wissen muss" text="Eine umfassende Auseinandersetzung mit ISO/IEC 27001 und ihrem Einsatz zur systematischen Informationssicherheitssteuerung. Im Vordergrund stehen ein wirksames ISMS, die Zuordnung von Verantwortung und belastbare Nachweise." shorttext="Eine umfassende Auseinandersetzung mit ISO/IEC 27001 und ihrem Einsatz zur systematischen Informationssicherheitssteuerung." image="images/mg-publikationen/cover/buch-iso27001-alles-was-man-wissen-muss-system-nachweis-wirksamkeit.jpg" book="1" note="Von Dr. Markus Groß" price="0" rating="0" count="0" features="0" disclosure="1"}
Den vollständigen Mobile Threat Report Q4 2012 (aus der auch die Grafiken stammen) gibt es hier.
Vertiefung: Sicherheit bei Smartphones
Aus „Sicherheit bei Smartphones“ lässt sich mehr gewinnen als eine Momentaufnahme. Die nachfolgende Vertiefung ordnet für Sperrprozess ein, welche Annahmen geprüft und welche Konsequenzen organisatorisch sauber umgesetzt werden sollten.
Identität und Zugriff als Konsequenz aus „Sicherheit bei Smartphones“
Der konkrete Nutzen von „Sicherheit bei Smartphones“ zeigt sich erst, wenn eine offene Annahme überprüft wird: Es ist zu klären, wie Person, Gerät und Berechtigung vor einem Zugriff zusammen bewertet werden. Beim Schwerpunkt „Sicherheit bei Smartphones“ geht es um die Sicherheit mobiler Geräte, Anwendungen und Zugänge sowie um den Bezug zu „Reaktionszeit“; zu entscheiden ist, welches Vertrauensniveau ein Gerät oder eine App vor dem Zugriff nachweisen muss – betrachtet im Kontext „Angriffsszenario“. Dabei bleibt folgende Grenze maßgeblich: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „App-Herkunft“. Die praktische Konsequenz heißt: Zugriff an Identität, Kontext und Gerätezustand koppeln. Ob der Ansatz trägt, wird an folgendem Ergebnis geprüft: Protokolle über Erteilung, Nutzung, Entzug und Ausnahme. Die Ergebnisbeobachtung richtet sich auf: Zeit bis zur Erkennung (hier bezogen auf „Patchstand“), Anteil konformer Geräte, offene Schwachstellen und Dauer bis zur Sperrung. Die bisherige Diskussion liefert mit „Tests und Lernen aus erkannten Abweichungen“ einen zusätzlichen Prüfstein; er sollte mit „Reaktionszeit“ verbunden und nicht isoliert bewertet werden.
Herstellerabhängigkeit im Blick: Sperrprozess
Für die belastbare Anwendung von „Reaktionszeit“ muss aus der Beobachtung ein prüfbarer Arbeitsauftrag werden: Es ist zu klären, welche Zusage technisch, vertraglich oder nur marketingseitig besteht. Beteiligt sind hier vor allem Informationssicherheit, IT-Betrieb, Datenschutz, Anwendungsverantwortliche und Nutzende; ihre Perspektiven treffen beim Aspekt „Sperrprozess“ unmittelbar aufeinander. Das relevante Negativszenario entsteht, wenn ein kompromittiertes oder ungepatchtes Gerät trotz formaler Freigabe auf geschäftliche Daten zugreift – betrachtet im Kontext „Zugriffsschutz“. Der nächste Arbeitsschritt lautet: Supportdauer, Updateweg, Export und Wechseloption vor Auswahl bewerten. Für Audit und Führung reicht Aktivität nicht aus; der Belastungstest erfolgt mit Blick auf „Zugriffsschutz“. Benötigt wird folgender Nachweis: eine Abhängigkeitsübersicht mit realistischem Ausstiegsszenario; bewertet wird außerdem: der Zusammenhang zwischen „Reaktionszeit“ und „Sperrprozess“. Beim Aspekt „Sperrprozess“ ist nicht die Menge der Aktivitäten entscheidend, sondern die erkennbare Veränderung des Ergebnisses.
Ausstieg: Wiederanlauf
Beim Aspekt „Wiederanlauf“ hilft ein enger Blick auf Entscheidung und Betriebswirkung: Es ist zu klären, wie Daten, Rechte, Geräte und Verpflichtungen am Ende bereinigt werden. Als belastbare Grundlage dienen Gerätezustand, Patchstand, App-Herkunft, Identitätsprüfung, Protokolle und getestete Reaktionswege; für den Aspekt „Wiederanlauf“ muss ihre Herkunft nachvollziehbar bleiben. Die Entscheidung über „Schwachstellenlage“ sollte deshalb ausdrücklich festhalten, welches Vertrauensniveau ein Gerät oder eine App vor dem Zugriff nachweisen muss – betrachtet im Kontext „Schwachstellenlage“. Für den nächsten Review wird vereinbart: Rückgabe, Entzug, Export, Löschung und Bestätigung zusammenführen. Der vorgesehene Nachweis lautet: ein abgeschlossener Austritts- oder Rückbau-Nachweis. Als Messperspektive dient: die beobachtbare Veränderung beim Aspekt „wirksame Sicherheit unter realen Arbeitsbedingungen“. Die bisherige Diskussion liefert mit „wirksame Sicherheit unter realen Arbeitsbedingungen“ einen zusätzlichen Prüfstein; er sollte mit „Schwachstellenlage“ verbunden und nicht isoliert bewertet werden.
Nachweis ohne blinden Fleck bei „Identitätsprüfung“
Der nächste sinnvolle Schritt für „Konfigurationsbaseline“ trennt Aussage, Voraussetzung und Konsequenz voneinander: Es ist zu klären, welches Arbeitsergebnis Ausführung und Ergebnis glaubhaft belegt. Die alltagstaugliche Übersetzung für „Konfigurationsbaseline“ lautet: Zugriff wird an überprüfbare Bedingungen gebunden und bei relevanten Abweichungen automatisch begrenzt – betrachtet im Kontext „Sicherheit bei Smartphones“. Damit wird zugleich die Grenze beim Aspekt „Identitätsprüfung“ sichtbar: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „Patchstand“. Statt einer neuen Parallelstruktur genügt zunächst: Nachweise möglichst im normalen Prozess entstehen lassen. Die Dokumentation hält zwei Dinge fest – eine datierte Spur aus Soll, Ausführung, Ergebnis und Abweichung; zusätzlich sichtbar wird: Zeit bis zur Erkennung (hier bezogen auf „Protokollierung“), Anteil konformer Geräte, offene Schwachstellen und Dauer bis zur Sperrung. Der gewählte Weg sollte sich außerdem umkehren lassen, falls die Annahmen zu „Identitätsprüfung“ später nicht mehr tragen.
Befähigung als Konsequenz aus „Sperrprozess“
Aus dem historischen Befund entsteht für „Sperrprozess“ eine praktische Steuerungsfrage: Es ist zu klären, welche Entscheidung Nutzende und Führungskräfte selbst sicher treffen müssen. Das relevante Negativszenario entsteht, wenn ein kompromittiertes oder ungepatchtes Gerät trotz formaler Freigabe auf geschäftliche Daten zugreift – betrachtet im Kontext „Gerätevertrauen“. Für die beteiligten Rollen – Informationssicherheit, IT-Betrieb, Datenschutz, Anwendungsverantwortliche und Nutzende – braucht der Aspekt „Sperrprozess“ daher einen vorab geklärten Entscheidungsweg. Statt einer neuen Parallelstruktur genügt zunächst: Schulung an realen Situationen statt an abstrakten Verbotslisten ausrichten; für den Aspekt „Konfigurationsbaseline“ wird daraus ein eigener Prüfschritt. Die Dokumentation hält zwei Dinge fest – kurze Fallsimulationen mit nachvollziehbarer Entscheidung; zusätzlich sichtbar wird: der Zusammenhang zwischen „Sperrprozess“ und „Sicherheit bei Smartphones“. Für den Dialog unter dem Beitrag ist „belastbare Nachweise statt bloßer Dokumentenfülle“ der passende Belastungstest: Gerade beim Aspekt „Sicherheit bei Smartphones“ muss die Regel im Alltag tragen.
Was „Angriffsszenario“ für Architektur bedeutet
Der nächste sinnvolle Schritt für „Angriffsszenario“ trennt Aussage, Voraussetzung und Konsequenz voneinander: Es ist zu klären, wie Komponenten, Schnittstellen und Vertrauensgrenzen zusammenspielen. Folgende Messperspektive zeigt, ob sich der Aspekt „Angriffsszenario“ tatsächlich verbessert oder nur formell bearbeitet wurde: Zeit bis zur Erkennung (hier bezogen auf „Reaktionszeit“), Anteil konformer Geräte, offene Schwachstellen und Dauer bis zur Sperrung. Für „Konfigurationsbaseline“ bleibt dabei verbindlich: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „Gerätevertrauen“. Für die belastbare Umsetzung gilt als Auftrag: Datenweg, Identität, Administration und Ausfallverhalten als Gesamtbild prüfen. Der vorgesehene Nachweis lautet: eine freigegebene Architektur mit getesteten Annahmen. Als Messperspektive dient: die beobachtbare Veränderung beim Aspekt „Tests und Lernen aus erkannten Abweichungen“; als Bezugspunkt dient „Schwachstellenlage“. Eine brauchbare Gegenprobe ist die Frage, ob dieselbe Entscheidung bei einer Störung rund um „Angriffsszenario“ noch nachvollziehbar wäre.
Ausnahmen im Blick: App-Herkunft
Im Mittelpunkt von „App-Herkunft“ steht weniger das Schlagwort als die damit verbundene Entscheidung: Es ist zu klären, wann eine Abweichung vertretbar ist und wann sie beendet werden muss. Beim Schwerpunkt „App-Herkunft“ geht es um die Sicherheit mobiler Geräte, Anwendungen und Zugänge sowie um den Bezug zu „App-Herkunft“; zu entscheiden ist, welches Vertrauensniveau ein Gerät oder eine App vor dem Zugriff nachweisen muss – betrachtet im Kontext „Gerätevertrauen“. Als fachliche Leitplanke gilt: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „Protokollierung“. Für den nächsten Review wird vereinbart: Eigentümer, Begründung, Kompensation und Ablaufdatum festlegen. Die Dokumentation hält zwei Dinge fest – ein befristetes Ausnahmeregister mit Wiedervorlage; zusätzlich sichtbar wird: Zeit bis zur Erkennung (hier bezogen auf „Wiederanlauf“), Anteil konformer Geräte, offene Schwachstellen und Dauer bis zur Sperrung. Die bisherige Diskussion liefert mit „klare Zuständigkeiten und Entscheidungsrechte“ einen zusätzlichen Prüfstein; er sollte mit „App-Herkunft“ verbunden und nicht isoliert bewertet werden.
Für Reaktionszeit sollte am Ende kein umfangreiches Zusatzdokument stehen, sondern eine klare Entscheidung mit Eigentümer, Nachweis und Wiedervorlage für Wiederanlauf. Genau daran lässt sich erkennen, ob die Vertiefung zu Konfigurationsbaseline praktische Wirkung entfaltet.