Wie bereits in meinem letzten Blog mitgeteilt möchte ich auch dieses Mal auf die von mir durchgeführte Umfrage eingehen und die Fragen beleuchten, welche Endgeräte eingesetzt werden.
Um den Umfang der Nutzung und die Akzeptanz noch weiter zu spezifieren, wurden Fragen bezüglich der eingesetzten Endgeräte gestellt. Auch hier wurde wieder unterteilt nach Teilnehmer, bei denen IT Consumerization eingesetzt wird, und denen bei denen es nicht eingesetzt wird. Zunächst die Auswertung der Befragten, die ByoD tatsächlich einsetzen bzw. einsetzen dürfen
Die Auswertung zeigt, dass in knapp 80% der Unternehmen Smartphones genutzt werden dürfen, in rund der Hälfte der Unternehmen dürfen auch Notebooks bzw. Netbooks eingesetzt werden. Allerdings wird IT Consumerization nicht auch gleichermaßen genutzt. Lediglich gut 60% der Befragten nutzen ihr privates Smartphone auch tatsächlich beruflich. Das sind knapp 20% als weniger diejenigen, die es nutzen dürften. Bei den Notebooks / Netbooks sind es noch weniger, nur knapp 30%, was etwa die Hälfte derjenigen ist, die das private Notebook tatsächlich geschäftlich nutzen dürften.
Durch die Differenz sieht man, dass die Akzeptanz nicht bei allen Endgeräten gleich ist, es ist allerdings auch zu bedenken, dass nicht jeder Arbeitnehmer privat ein Notebook / Netbook oder Smartphone besitzt. Die meisten Mitarbeiter sind auch mit der Auswahl der Endgeräte, die sie nutzen dürfen zufrieden. Nur gut 10% der Befragten würde sich wünschen weitere Endgeräte nutzen zu dürfen.
Von der Gruppe der Teilnehmer, die kein ByoD nutzen, würden gut 40% auch gerne auf Bring your own Device verzichten. Von den restlichen Teilnehmern würden knapp 70% private Smartphones und gut die Hälfte Notebooks / Netbooks oder Tablets nutzen wollen. Dies sind ähnliche Werte, wie die von den Nutzern, die ByoD bereits einsetzen.
Wichtig für die Frage, ob bestimmte Endgeräte akzeptiert werden ist auch die Frage, ob Einstellungen seitens des Unternehmens am privaten Endgerät vorgenommen worden sind. Bei dieser Frage antworteten etwa 44%, dass dies der Fall sei. Bei etwa 2/3 dieser Gruppe wurde Software installiert (ausgenommen Officeprodukte und Firewalls / Virenscanner), bei etwa einem Drittel wurden eine Firewall oder ein Virenscanner installiert. Die Zahl der Anwender bei denen keine Einstellung vorgenommen worden sind liegt bei gut 55%. Dies zeigt, dass in vielen Unternehmen keine Vorsichtsmaßnahmen bezüglich der IT Sicherheit vorgenommen werden.
Die Teilnehmer ohne ByoD wurden gefragt, ob sie Einstellungen überhaupt vornehmen lassen würden und wenn ja, welche. Rund 40% der Personen antworteten, dass sie keine vornehmen lassen würden. Da mehr als die Hälfte der Unternehmen mit Bring your own Device keine Einstellungen vornehmen, gibt es an dieser Stelle vermutlich keine Probleme bei der Akzeptanz durch die Mitarbeiter. Installation von Officeprodukten, Firewalls / Virenscanner und sonstiger Software würden etwa 1/3 Anwender vornehmen lassen. Dies zeigt, dass Anwender Software installieren lassen würden, die ihnen privat auch Vorteile verschaffen kann, wie bspw. Officeprodukte. Da die Softwarearten bei der Kategorie „Installation von Software“ jedoch nicht kleinschrittig aufgeteilt ist, ist allerdings nicht erkennbar, welche konkrete Software die Anwender installiert bekommen haben, bzw. installieren lassen würden. Unter diese Art könnte somit auf der einen Seite Software stehen, die dem Anwender Vorteile bringt, auf der anderen Seite könnte allerdings auch Software gemeint sein, die Nachteile, wie „Überwachung des Arbeitnehmers“ beinhaltet.
Technische Freigaben wiederholbar gestalten. Formulieren Sie wenige überprüfbare Anforderungen an Geräte und Zugänge. Testen Sie, ob eine zweite zuständige Person anhand derselben Kriterien zur gleichen Freigabeentscheidung kommt.
{tmamazon asin="B0HCK3HKX1" layout="compact" 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"}
Vertiefung: Bring your own Device - verhindern, dulden oder aktiv steuern? - Teil 2
Die damalige Beobachtung zu „Bring your own Device - verhindern, dulden oder aktiv steuern? - Teil 2“ wird hier nicht ersetzt, sondern praktisch weitergedacht. Im Fokus stehen bei Gerätevertrauen überprüfbare Voraussetzungen, erkennbare Grenzen und ein im Alltag belastbarer Umgang.
BYOD steuern – Teil 2 – Ausnahmen praktisch fassen
Für die belastbare Anwendung von „BYOD steuern – Teil 2“ muss aus der Beobachtung ein prüfbarer Arbeitsauftrag werden: Es ist zu klären, wann eine Abweichung vertretbar ist und wann sie beendet werden muss. Beim Schwerpunkt „BYOD steuern – Teil 2“ 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 „Protokollierung“. Ein vorschneller Schluss würde diese Grenze ignorieren: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „Patchstand“. Im Regelbetrieb wird folgender Punkt verankert: Eigentümer, Begründung, Kompensation und Ablaufdatum festlegen; für „Sperrprozess“ ist das Ergebnis gesondert festzuhalten. Die Dokumentation hält zwei Dinge fest – ein befristetes Ausnahmeregister mit Wiedervorlage; zusätzlich sichtbar wird: Zeit bis zur Erkennung (hier bezogen auf „Angriffsszenario“), Anteil konformer Geräte, offene Schwachstellen und Dauer bis zur Sperrung. Der Diskussionsaspekt „klare Zuständigkeiten und Entscheidungsrechte“ ergänzt die Betrachtung sinnvoll, weil er „Reaktionszeit“ mit der tatsächlichen Anwendung verknüpft.
Mindeststandard als Konsequenz aus „Reaktionszeit“
Der konkrete Nutzen von „Reaktionszeit“ zeigt sich erst, wenn eine offene Annahme überprüft wird: Es ist zu klären, welche unverzichtbaren Bedingungen jede zulässige Variante erfüllen muss. Beteiligt sind hier vor allem Informationssicherheit, IT-Betrieb, Datenschutz, Anwendungsverantwortliche und Nutzende; ihre Perspektiven treffen beim Aspekt „Sperrprozess“ unmittelbar aufeinander; die Umsetzung wird dabei an „Protokollierung“ gespiegelt. Die gewählte Lösung muss auch dann tragen, wenn ein kompromittiertes oder ungepatchtes Gerät trotz formaler Freigabe auf geschäftliche Daten zugreift – betrachtet im Kontext „Wiederanlauf“; im Fokus steht dabei „Patchstand“. Ein schlanker, aber wirksamer Ansatz lautet: wenige klare Basiskriterien mit automatischer oder manueller Prüfung formulieren; bezogen auf „Konfigurationsbaseline“ ist die konkrete Ausprägung separat zu entscheiden. Überprüfbar wird der Schritt durch folgendes Ergebnis: eine prüfbare Baseline samt begründetem Ausnahmeweg; bezogen auf „Wiederanlauf“ ist die konkrete Ausprägung separat zu entscheiden. Relevant bleibt dabei: der Zusammenhang zwischen „Reaktionszeit“ und „Sperrprozess“. Beim Aspekt „Sperrprozess“ ist nicht die Menge der Aktivitäten entscheidend, sondern die erkennbare Veränderung des Ergebnisses; „Angriffsszenario“ liefert dafür den praktischen Anwendungsfall.
Priorisierung: Zugriffsschutz
Für die belastbare Anwendung von „Zugriffsschutz“ muss aus der Beobachtung ein prüfbarer Arbeitsauftrag werden: Es ist zu klären, welche Lücke zuerst behandelt werden muss und warum. Als belastbare Grundlage dienen Gerätezustand, Patchstand, App-Herkunft, Identitätsprüfung, Protokolle und getestete Reaktionswege; für den Aspekt „Zugriffsschutz“ muss ihre Herkunft nachvollziehbar bleiben. Die Entscheidung über „Konfigurationsbaseline“ sollte deshalb ausdrücklich festhalten, welches Vertrauensniveau ein Gerät oder eine App vor dem Zugriff nachweisen muss – betrachtet im Kontext „Konfigurationsbaseline“; der konkrete Prüfmaßstab wird aus „Angriffsszenario“ abgeleitet. Operativ folgt daraus: Kritikalität, Exposition, Umsetzbarkeit und Abhängigkeiten gemeinsam gewichten. Der Prüfpfad endet nicht beim Dokument; die Umsetzung wird dabei an „Schwachstellenlage“ gespiegelt. Als Verbindung zwischen Nachweis und Messung dienen: eine begründete Reihenfolge statt einer unverbundenen Maßnahmenliste; die beobachtbare Veränderung beim Aspekt „Tests und Lernen aus erkannten Abweichungen“. Die bisherige Diskussion liefert mit „Tests und Lernen aus erkannten Abweichungen“ einen zusätzlichen Prüfstein; er sollte mit „Konfigurationsbaseline“ verbunden und nicht isoliert bewertet werden.
Befähigung als Konsequenz aus „Gerätevertrauen“
Beim Aspekt „Gerätevertrauen“ 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; „Identitätsprüfung“ liefert dafür den praktischen Anwendungsfall. Die alltagstaugliche Übersetzung für „Gerätevertrauen“ lautet: Zugriff wird an überprüfbare Bedingungen gebunden und bei relevanten Abweichungen automatisch begrenzt – betrachtet im Kontext „BYOD steuern – Teil 2“. 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 „Angriffsszenario“. Operativ folgt daraus: Schulung an realen Situationen statt an abstrakten Verbotslisten ausrichten. Überprüfbar wird der Schritt durch folgendes Ergebnis: kurze Fallsimulationen mit nachvollziehbarer Entscheidung; im Fokus steht dabei „Reaktionszeit“. Relevant bleibt dabei: Zeit bis zur Erkennung (hier bezogen auf „App-Herkunft“), Anteil konformer Geräte, offene Schwachstellen und Dauer bis zur Sperrung. Im Managementdialog muss beim Aspekt „Gerätevertrauen“ erkennbar bleiben, welche Unsicherheit akzeptiert und welche aktiv reduziert wird.
Ausstieg ohne blinden Fleck bei „BYOD steuern – Teil 2“
Der nächste sinnvolle Schritt für „Sperrprozess“ trennt Aussage, Voraussetzung und Konsequenz voneinander: Es ist zu klären, wie Daten, Rechte, Geräte und Verpflichtungen am Ende bereinigt werden. Besondere Aufmerksamkeit verdient das Szenario, in dem 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 „Sperrprozess“ daher einen vorab geklärten Entscheidungsweg; für den Aspekt „Zugriffsschutz“ wird daraus ein eigener Prüfschritt. Im Regelbetrieb wird folgender Punkt verankert: Rückgabe, Entzug, Export, Löschung und Bestätigung zusammenführen; der Prüfkontext ist hier „Gerätevertrauen“. Ob der Ansatz trägt, wird an folgendem Ergebnis geprüft: ein abgeschlossener Austritts- oder Rückbau-Nachweis. Die Ergebnisbeobachtung richtet sich auf: der Zusammenhang zwischen „Sperrprozess“ und „BYOD steuern – Teil 2“. Die bisherige Diskussion liefert mit „Messbarkeit und nachgewiesene Wirkung“ einen zusätzlichen Prüfstein; er sollte mit „BYOD steuern – Teil 2“ verbunden und nicht isoliert bewertet werden.
Nachweis ohne blinden Fleck bei „Gerätevertrauen“
Im Mittelpunkt von „Protokollierung“ steht weniger das Schlagwort als die damit verbundene Entscheidung: Es ist zu klären, welches Arbeitsergebnis Ausführung und Ergebnis glaubhaft belegt. Folgende Messperspektive zeigt, ob sich der Aspekt „Protokollierung“ 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 „Gerätevertrauen“ bleibt dabei verbindlich: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „Schwachstellenlage“. Ein schlanker, aber wirksamer Ansatz lautet: Nachweise möglichst im normalen Prozess entstehen lassen; die Bewertung erfolgt hier aus der Perspektive „Patchstand“. Die Dokumentation hält zwei Dinge fest – eine datierte Spur aus Soll, Ausführung, Ergebnis und Abweichung; zusätzlich sichtbar wird: die beobachtbare Veränderung beim Aspekt „klare Zuständigkeiten und Entscheidungsrechte“. Beim Aspekt „Gerätevertrauen“ ist nicht die Menge der Aktivitäten entscheidend, sondern die erkennbare Veränderung des Ergebnisses.
Der Praxistest für Zugriffsschutz bleibt bewusst einfach: Die Regel zu Gerätevertrauen muss im Normalbetrieb verständlich, beim Aspekt Sperrprozess im Ausnahmefall entscheidbar und nach einer Änderung erneut prüfbar sein. Fehlt eine dieser Eigenschaften, besteht bei Protokollierung weiterer Handlungsbedarf.