GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
Eine gemeinsame Studie von IBM und dem Ponemon Institut kommt zum Ergebnis, dass mobile Applikationen und Geräte gravierende Sicherheitsmängel aufweisen. Fast 40 Prozent der größeren Unternehmen, darunter viele aus der Fortune-500-Liste, kümmern sich zu wenig um die notwendigen Sicherheitsvorkehrungen bei der Entwicklung mobiler Apps für ihre Kunden. Zudem sind sowohl die unternehmenseigenen mobilen Geräte wie auch private Geräte der Mitarbeiter, die für Geschäftszwecke genutzt werden, zu wenig geschützt. Sie bieten damit ideale Einfallstore für Cyberattacken auf Unternehmens-, Kunden- und private Nutzerdaten.
Die Anzahl von Cyberattacken wächst auch auf mobile Endgeräte kontinuierlich. Zu jedem beliebigen Zeitpunkt werden weltweit über 11,6 Millionen mobile Geräte infiziert. Das Ponemon Institut hat daher gemeinsam mit IBM die Sicherheitspraktiken in über 400 großen Unternehmen untersucht. Mit dem Ergebnis, das ein durchschnittliches Unternehmen weniger als die Hälfte seiner Apps auf Sicherheitsmängel prüft. Etwa ein Drittel testet die Sicherheit ihrer Apps überhaupt nicht. Auch ein Ergebnis der Studie: Die Hälfte der befragten Unternehmen plant bisher keinerlei Budget für Maßnahmen zur mobilen Sicherheit.
Nach Rademann von IBM Security „fehlt (es) in den Unternehmen bisher das Bewusstsein dafür, Sicherheit auch in mobile Applikationen einzubauen. Damit wird Cyberkriminellen Tür und Tor geöffnet. Unternehmen müssen dringend lernen, mit vergleichbar effektiven Waffen zurückzuschlagen, mit denen sie heute attackiert werden." Hacker nutzen mit Vorliebe unsichere mobilen Apps sowie öffentliche WLAN-Netzwerke, um auf Daten zuzugreifen, die immer häufiger direkt auf den mobilen Geräten abgelegt werden. Oder sie nutzen Apps als Einfallstor, um in das vertrauliche interne Netzwerk der Unternehmen vorzudringen. Um sich gegen solche Angriffe besser zur Wehr setzen zu können, wurde die Expertise von IBM Security-Spezialisten in die mobile Welt übertragen.
Bring Your Own Device (BYOD), die Nutzung privater mobile Geräte, wird nicht nur immer populärer, sondern für viele Unternehmen sogar unverzichtbar. Dies wird immer dann zu einer Herausforderung, wenn Mitarbeiter sich mit unsicheren Netzwerken verbinden oder schlecht geschützte Apps von unsicheren Quellen herunterladen, die das Gerät verwundbar machen. Aber selbst große, bekannte Unternehmen und Organisationen, deren Apps scheinbar über jeden Zweifel erhaben sind, können enorme Risiken bergen, wie die Untersuchung zeigt.
Laut der Studie sind die meisten Mitarbeiter der befragten Unternehmer intensive Nutzer von mobilen Geräten und Apps, dennoch sagen weit über die Hälfte (55 Prozent), das ihre Unternehmen keinerlei Richtlinien für den Einsatz am Arbeitsplatz vorgegeben hat. Über zwei Drittelt (67 Prozent) lassen zudem das Herunterladen auch nicht Sicherheits-überprüfter Apps auf mobile Arbeitsgeräte zu. Nochmal gut die Hälfte (55 Prozent) unterbinden nicht das Herunterladen von Geschäftsanwendungen auf eigene private Geräte (BYOD).
Den Befund auf den eigenen Anwendungssatz beziehen. Nutzen Sie die historische IBM-Studie als Anlass, die tatsächlich zugelassenen Apps und deren Datenzugriffe zu prüfen. Priorisieren Sie die Anwendungen mit geschäftlichen Informationen und unklarer Updateversorgung. Der konkrete Befund im eigenen Bestand ist für Maßnahmen hilfreicher als eine allgemeine Prozentzahl.
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.
Von Dr. Markus Groß
Die damalige Beobachtung zu „Neue IBM Studie: zu viele Sicherheitslücken in mobilen Apps und Geräten“ wird hier nicht ersetzt, sondern praktisch weitergedacht. Im Fokus stehen bei Wiederanlauf überprüfbare Voraussetzungen, erkennbare Grenzen und ein im Alltag belastbarer Umgang.
Praktisch relevant wird „Neue IBM Studie“ dort, wo Verantwortung und Ergebnis zusammenkommen: Es ist zu klären, wie Komponenten, Schnittstellen und Vertrauensgrenzen zusammenspielen. Beim Schwerpunkt „Neue IBM Studie“ geht es um die Sicherheit mobiler Geräte, Anwendungen und Zugänge sowie um den Bezug zu „Angriffsszenario“; zu entscheiden ist, welches Vertrauensniveau ein Gerät oder eine App vor dem Zugriff nachweisen muss – betrachtet im Kontext „Sperrprozess“. Die Gegenprobe lautet deshalb: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „Identitätsprüfung“; als Bezugspunkt dient „Wiederanlauf“. Für den nächsten Review wird vereinbart: Datenweg, Identität, Administration und Ausfallverhalten als Gesamtbild prüfen; „Patchstand“ liefert dafür den praktischen Anwendungsfall. Überprüfbar wird der Schritt durch folgendes Ergebnis: eine freigegebene Architektur mit getesteten Annahmen; der Belastungstest erfolgt mit Blick auf „Sperrprozess“. Relevant bleibt dabei: Zeit bis zur Erkennung (hier bezogen auf „App-Herkunft“), Anteil konformer Geräte, offene Schwachstellen und Dauer bis zur Sperrung; „Sperrprozess“ liefert dafür den praktischen Anwendungsfall. Die bisherige Diskussion liefert mit „Tests und Lernen aus erkannten Abweichungen“ einen zusätzlichen Prüfstein; er sollte mit „Angriffsszenario“ verbunden und nicht isoliert bewertet werden.
Für die belastbare Anwendung von „Angriffsszenario“ muss aus der Beobachtung ein prüfbarer Arbeitsauftrag werden: Es ist zu klären, welches Arbeitsergebnis Ausführung und Ergebnis glaubhaft belegt. Beteiligt sind hier vor allem Informationssicherheit, IT-Betrieb, Datenschutz, Anwendungsverantwortliche und Nutzende; ihre Perspektiven treffen beim Aspekt „Patchstand“ unmittelbar aufeinander. Das relevante Negativszenario entsteht, wenn ein kompromittiertes oder ungepatchtes Gerät trotz formaler Freigabe auf geschäftliche Daten zugreift – betrachtet im Kontext „Gerätevertrauen“; der Prüfkontext ist hier „Identitätsprüfung“. Im Regelbetrieb wird folgender Punkt verankert: Nachweise möglichst im normalen Prozess entstehen lassen; im Fokus steht dabei „Protokollierung“. Der Prüfpfad endet nicht beim Dokument; im Fokus steht dabei „Gerätevertrauen“. Als Verbindung zwischen Nachweis und Messung dienen: eine datierte Spur aus Soll, Ausführung, Ergebnis und Abweichung; der Zusammenhang zwischen „Angriffsszenario“ und „Patchstand“. Im Managementdialog muss beim Aspekt „Angriffsszenario“ erkennbar bleiben, welche Unsicherheit akzeptiert und welche aktiv reduziert wird.
Der Beitrag gewinnt beim Aspekt „Konfigurationsbaseline“ an Aktualität, sobald sein Kerngedanke in eine heutige Entscheidung übersetzt wird: Es ist zu klären, welche unverzichtbaren Bedingungen jede zulässige Variante erfüllen muss. Als belastbare Grundlage dienen Gerätezustand, Patchstand, App-Herkunft, Identitätsprüfung, Protokolle und getestete Reaktionswege; für den Aspekt „Konfigurationsbaseline“ muss ihre Herkunft nachvollziehbar bleiben. Die Entscheidung über „Protokollierung“ sollte deshalb ausdrücklich festhalten, welches Vertrauensniveau ein Gerät oder eine App vor dem Zugriff nachweisen muss – betrachtet im Kontext „Protokollierung“. Operativ folgt daraus: wenige klare Basiskriterien mit automatischer oder manueller Prüfung formulieren. Für Audit und Führung reicht Aktivität nicht aus; der Belastungstest erfolgt mit Blick auf „Schwachstellenlage“. Benötigt wird folgender Nachweis: eine prüfbare Baseline samt begründetem Ausnahmeweg; bewertet wird außerdem: die beobachtbare Veränderung beim Aspekt „Messbarkeit und nachgewiesene Wirkung“. Der Diskussionsaspekt „Messbarkeit und nachgewiesene Wirkung“ ergänzt die Betrachtung sinnvoll, weil er „Protokollierung“ mit der tatsächlichen Anwendung verknüpft.
Eine nüchterne Fortführung trennt bei „Wiederanlauf“ den damaligen Anlass von der bleibenden Organisationsfrage: Es ist zu klären, wann eine frühere Entscheidung ihre Grundlage verlieren kann. Die alltagstaugliche Übersetzung für „Wiederanlauf“ lautet: Zugriff wird an überprüfbare Bedingungen gebunden und bei relevanten Abweichungen automatisch begrenzt – betrachtet im Kontext „Neue IBM Studie“. Damit wird zugleich die Grenze beim Aspekt „Zugriffsschutz“ sichtbar: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „App-Herkunft“. Für den nächsten Review wird vereinbart: Zeitpunkt und ereignisbasierte Auslöser miteinander kombinieren; für den Aspekt „Neue IBM Studie“ wird daraus ein eigener Prüfschritt. Der vorgesehene Nachweis lautet: eine terminierte Neubewertung mit benannten Eingangsdaten; als Bezugspunkt dient „Angriffsszenario“. Als Messperspektive dient: Zeit bis zur Erkennung (hier bezogen auf „Reaktionszeit“), Anteil konformer Geräte, offene Schwachstellen und Dauer bis zur Sperrung; im Fokus steht dabei „Angriffsszenario“. Der gewählte Weg sollte sich außerdem umkehren lassen, falls die Annahmen zu „Zugriffsschutz“ später nicht mehr tragen.
Für die heutige Einordnung von „Patchstand“ ist zunächst eine Unterscheidung entscheidend: Es ist zu klären, welche Zusage technisch, vertraglich oder nur marketingseitig besteht. Ein realistischer Belastungstest betrachtet den Fall, dass ein kompromittiertes oder ungepatchtes Gerät trotz formaler Freigabe auf geschäftliche Daten zugreift – betrachtet im Kontext „Schwachstellenlage“. Für die beteiligten Rollen – Informationssicherheit, IT-Betrieb, Datenschutz, Anwendungsverantwortliche und Nutzende – braucht der Aspekt „Patchstand“ daher einen vorab geklärten Entscheidungsweg. Der nächste Arbeitsschritt lautet: Supportdauer, Updateweg, Export und Wechseloption vor Auswahl bewerten; für den Aspekt „Wiederanlauf“ wird daraus ein eigener Prüfschritt. Überprüfbar wird der Schritt durch folgendes Ergebnis: eine Abhängigkeitsübersicht mit realistischem Ausstiegsszenario; der Belastungstest erfolgt mit Blick auf „Patchstand“. Relevant bleibt dabei: der Zusammenhang zwischen „Patchstand“ und „Neue IBM Studie“. Für den Dialog unter dem Beitrag ist „Mindestanforderungen und befristete Ausnahmen“ der passende Belastungstest: Gerade beim Aspekt „Neue IBM Studie“ muss die Regel im Alltag tragen.
Beim Aspekt „Sperrprozess“ hilft ein enger Blick auf Entscheidung und Betriebswirkung: Es ist zu klären, welche Entscheidung Nutzende und Führungskräfte selbst sicher treffen müssen. Folgende Messperspektive zeigt, ob sich der Aspekt „Sperrprozess“ tatsächlich verbessert oder nur formell bearbeitet wurde: Zeit bis zur Erkennung (hier bezogen auf „Angriffsszenario“), Anteil konformer Geräte, offene Schwachstellen und Dauer bis zur Sperrung. Für „Wiederanlauf“ bleibt dabei verbindlich: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „Schwachstellenlage“. Für den nächsten Review wird vereinbart: Schulung an realen Situationen statt an abstrakten Verbotslisten ausrichten. Die Dokumentation hält zwei Dinge fest – kurze Fallsimulationen mit nachvollziehbarer Entscheidung; zusätzlich sichtbar wird: die beobachtbare Veränderung beim Aspekt „Tests und Lernen aus erkannten Abweichungen“. Im Managementdialog muss beim Aspekt „Sperrprozess“ erkennbar bleiben, welche Unsicherheit akzeptiert und welche aktiv reduziert wird.
Als Abschluss für Neue IBM Studie genügen drei verbindliche Antworten zu Angriffsszenario: Wer entscheidet über Konfigurationsbaseline, woran wird Wirkung bei Wiederanlauf erkannt und welcher Auslöser führt zur erneuten Prüfung? Sind diese Punkte geklärt, wird aus dem historischen Impuls zu Patchstand eine belastbare Arbeitsgrundlage.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Deine Bewertung hilft bei der Einordnung der Inhalte.
Interessant für dein Netzwerk? Teile den Beitrag direkt.
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.
Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern. Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.
Kommentare 21
Den Punkt würde ich gern vertiefen. Welche Annahmen sollte man prüfen, bevor man solche Ergebnisse auf die eigene Organisation überträgt?
Die Ausgangslage und die untersuchte Gruppe sind entscheidend. Ich würde zunächst vergleichen, ob die Rahmenbedingungen wirklich ähnlich sind.
Welche Beobachtung wäre bei der Übertragung auf die eigene Organisation ein ausreichender Anlass, die Entscheidung noch einmal aufzumachen? Damit ließe sich Wirkung von bloßer Aktivität besser unterscheiden. Für den ersten Durchlauf würde dafür eine knappe Festlegung genügen.
Mich interessiert besonders, woran sich der praktische Nutzen des beschriebenen Vorgehens zuerst erkennen lässt. Welches erste Signal wäre dafür im Alltag wirklich aussagekräftig?
Ich würde zunächst einen konkreten Ablauf auswählen und dort Ausgangslage, Entscheidung und Ergebnis gegenüberstellen. Sonst bleibt die Bewertung leicht abstrakt.
Zusätzlich sollte erkennbar sein, welche Quelle maßgeblich ist. Unterschiedliche Datenstände können sonst schon vor der eigentlichen Bewertung zu Scheingenauigkeit führen.
Der Pilot ist aus meiner Sicht sinnvoll, wenn er nicht nur die formale Durchführung prüft. Entscheidend ist, ob anschließend eine bessere oder schnellere Entscheidung möglich ist.
Gerade der feste Termin zur erneuten Bewertung ist wichtig. Andernfalls wird aus einer vorläufigen Annahme schnell ein dauerhafter Status.
Wie stark hängt die Aussage der Studie von der Auswahl der befragten Unternehmen ab? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Das ist ein wichtiger Punkt. Ich würde die Ergebnisse zunächst auf die untersuchte Gruppe beziehen. Unternehmensgröße, Branche und Region können bei einer Übertragung auf den eigenen Betrieb viel ausmachen. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Das klingt nachvollziehbar, aber der Aufwand ist damit noch nicht geklärt. Welchen Teil würdest du zuerst angehen? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Für mich müsste sich zunächst erklären lassen, welche Entscheidung verbessert werden soll. Daraus würde ich den notwendigen Umfang ableiten, statt mit der maximalen Dokumentation anzufangen. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Da kommen wir näher zusammen. Ein gemeinsamer Ablauf wäre überzeugender als zwei Verfahren, die im Ernstfall unterschiedliche Antworten geben. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Den Nutzen sehe ich. Trotzdem würde ich vermeiden, jede Ausnahme sofort mit einer weiteren Richtlinie zu beantworten.
Welche Annahme sollte bei Auswahl und Größe der Stichprobe nach einer größeren Veränderung erneut geprüft werden?
Ich würde die Annahmen hinter der bisherigen Entscheidung sichtbar machen. Ändert sich eine wesentliche Voraussetzung, braucht es eine erneute Bewertung ihrer Auswirkungen. Für Auswahl und Größe der Stichprobe würde ich den ersten Prüfschritt bewusst klein halten.
Wie würdet ihr Auswahl und Größe der Stichprobe konkret prüfen, wenn die Maßnahme bereits auf dem Papier abgeschlossen ist?
Für diesen Fall wäre mein Ansatz: die Umsetzung an einem konkreten Fall nachvollziehen und dabei das tatsächliche Ergebnis prüfen. Damit bleibt sichtbar, was entschieden wurde und was noch offen ist. Bei Auswahl und Größe der Stichprobe sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Ich würde eine nachvollziehbare und im Alltag tragfähige Umsetzung zunächst an einem kritischen, aber überschaubaren Fall testen. Dann lassen sich Aufwand und Nutzen vergleichen.
Wird hier die tatsächliche Nutzung gemessen oder eher die Absicht, etwas künftig einzuführen? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Bei eine nachvollziehbare und im Alltag tragfähige Umsetzung würde ich nicht nur die Durchführung betrachten. Aussagekräftig wird es erst, wenn auch die Wirkung sichtbar bleibt.