Eine aktuelle, von der IT-Sicherheitsfirma Webroot durchgeführte, Untersuchung zum Themenkomplex Sicherheit beim BYOD-Einsatz beschreibt die Sicherheitssicht der Verbraucher, die ihre privaten mobilen Geräte im beruflichen Kontext nutzen. Die Studie zeigt deutlich, dass viele Mitarbeiter nicht die erforderlichen Vorkehrungen treffen um die kritischen Unternehmenswerte zu schützen und den gesetzlichen und regulatorischen Anforderungen nachzukommen. Diese Schwäche kann zu einer kritischen und kostenintensiven Sicherheitsstörung für das Unternehmen werden. Daneben liefert die Studie auch BYOD-Richtlinie, die die Lücke zwischen den Wünschen der Mitarbeiter und den Sicherheitsanforderungen der Organisationen überbrücken soll.
Die wichtigsten Erkenntnisse der BYOD Mobile-Studie sind:
- Mehr als doppelt so viele Arbeitnehmer geben an, ihre private Devices statt der vom Arbeitgebern zur Verfügung gestellten Endgeräte zu nutzen
- 60 Prozent der Personen mit einem mobilen Gerät haben entweder gar keine Sicherheitdienste oder nur die einfachen Standardschutzfunktionen auf dem Telefon installiert
- Rund die Hälfte der Befragten geben an, dass sie aufhören würden, ihr Gerät(e) für berufliche Tätigkeiten einzusetzen, wenn es die Unternehmenspolitik vorschreiben würde entsprechende Sicherheit-App auf privaten Endgeräten
- Hierbei wurde auch festgestellt, dass rund 62 Prozent der Mitarbeiter offen für Sicherheits-Software auf ihren Endgeräten wären, würden diese Anforderungen von den Arbeitgebern klar kommuniziert würde.
- Das der eigene Arbeitgeber in der Lage wäre auf persönliche Daten der Mitarbeiter zugreifen, erwies sich hierbei als die überwiegend größte Sorge
- 73 Prozent stimmen zu, dass die Mitarbeiter ein gewisser Einfluss auf die Software-oder Sicherheitstools haben müssen, die auf den privaten Geräten für aus beruflichen Anforderungen installiert wird
Die Ergebnisse der Untersuchung basierend auf den Aussagen von mehr als 2.000 Berufstätigen in den USA, die strukturiert befragt wurden. Während der Einsatz von mobilen (privaten) Endgeräten auf der einen Seite für die Organisation einen echten Geschäftsvorteil bietet, stehen auf der anderen Seite den erhöhten Risiken, wenn solche Geräte ungeschützt auf Unternehmensdaten zugreifen, gegenüber. Hauptrisiken werden in Sicherheitsbedrohungen durch Phishing-Attacken, Malware, und Browser-Hijacking gesehen. Das Ergebnis wurde in der folgenden Infografik anschaulich zusammengefasst:
Vertiefung: Ungesicherte private Geräte überwiegend beim mobilen Unternehmenseinsatz
„Ungesicherte private Geräte überwiegend beim mobilen Unternehmenseinsatz“ bleibt als zeitbezogene Einordnung erhalten. Die folgende Ergänzung betrachtet den Schwerpunkt mit Blick auf Protokollierung aus heutiger Organisations- und Betriebssicht, ohne damalige Zahlen oder Produktversprechen stillschweigend fortzuschreiben.
Mindeststandard: Ungesicherte private Geräte überwiegend beim mobilen Unternehmenseinsatz
Der konkrete Nutzen von „Ungesicherte private Geräte überwiegend beim mobilen Unternehmenseinsatz“ 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. Beim Schwerpunkt „Ungesicherte private Geräte überwiegend beim mobilen Unternehmenseinsatz“ geht es um die Sicherheit mobiler Geräte, Anwendungen und Zugänge sowie um den Bezug zu „Protokollierung“; zu entscheiden ist, welches Vertrauensniveau ein Gerät oder eine App vor dem Zugriff nachweisen muss – betrachtet im Kontext „Schwachstellenlage“. Die Gegenprobe lautet deshalb: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „App-Herkunft“. Statt einer neuen Parallelstruktur genügt zunächst: wenige klare Basiskriterien mit automatischer oder manueller Prüfung formulieren. Der Prüfpfad endet nicht beim Dokument; der konkrete Prüfmaßstab wird aus „Schwachstellenlage“ abgeleitet. Als Verbindung zwischen Nachweis und Messung dienen: eine prüfbare Baseline samt begründetem Ausnahmeweg; Zeit bis zur Erkennung (hier bezogen auf „Sperrprozess“), Anteil konformer Geräte, offene Schwachstellen und Dauer bis zur Sperrung. Für den Dialog unter dem Beitrag ist „Tests und Lernen aus erkannten Abweichungen“ der passende Belastungstest: Gerade beim Aspekt „Protokollierung“ muss die Regel im Alltag tragen.
Identität und Zugriff: Protokollierung
Im Mittelpunkt von „Protokollierung“ steht weniger das Schlagwort als die damit verbundene Entscheidung: Es ist zu klären, wie Person, Gerät und Berechtigung vor einem Zugriff zusammen bewertet werden. Beteiligt sind hier vor allem Informationssicherheit, IT-Betrieb, Datenschutz, Anwendungsverantwortliche und Nutzende; ihre Perspektiven treffen beim Aspekt „Angriffsszenario“ unmittelbar aufeinander. Besondere Aufmerksamkeit verdient das Szenario, in dem ein kompromittiertes oder ungepatchtes Gerät trotz formaler Freigabe auf geschäftliche Daten zugreift – betrachtet im Kontext „Wiederanlauf“. Der nächste Arbeitsschritt lautet: Zugriff an Identität, Kontext und Gerätezustand koppeln. Überprüfbar wird der Schritt durch folgendes Ergebnis: Protokolle über Erteilung, Nutzung, Entzug und Ausnahme. Relevant bleibt dabei: der Zusammenhang zwischen „Protokollierung“ und „Angriffsszenario“. Eine brauchbare Gegenprobe ist die Frage, ob dieselbe Entscheidung bei einer Störung rund um „Protokollierung“ noch nachvollziehbar wäre.
Befähigung im Blick: Konfigurationsbaseline
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. Als belastbare Grundlage dienen Gerätezustand, Patchstand, App-Herkunft, Identitätsprüfung, Protokolle und getestete Reaktionswege; für den Aspekt „Gerätevertrauen“ 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 nächste Arbeitsschritt lautet: Schulung an realen Situationen statt an abstrakten Verbotslisten ausrichten. Ob der Ansatz trägt, wird an folgendem Ergebnis geprüft: kurze Fallsimulationen mit nachvollziehbarer Entscheidung. Die Ergebnisbeobachtung richtet sich auf: die beobachtbare Veränderung beim Aspekt „klare Zuständigkeiten und Entscheidungsrechte“; der konkrete Prüfmaßstab wird aus „Identitätsprüfung“ abgeleitet. Der Diskussionsaspekt „klare Zuständigkeiten und Entscheidungsrechte“ ergänzt die Betrachtung sinnvoll, weil er „Konfigurationsbaseline“ mit der tatsächlichen Anwendung verknüpft.
Ausstieg: Zugriffsschutz
Der Ausgangspunkt dieses Beitrags führt beim Aspekt „Zugriffsschutz“ zu einer klaren Prüffrage: Es ist zu klären, wie Daten, Rechte, Geräte und Verpflichtungen am Ende bereinigt werden. Die alltagstaugliche Übersetzung für „Zugriffsschutz“ lautet: Zugriff wird an überprüfbare Bedingungen gebunden und bei relevanten Abweichungen automatisch begrenzt – betrachtet im Kontext „Ungesicherte private Geräte überwiegend beim mobilen Unternehmenseinsatz“. Damit wird zugleich die Grenze beim Aspekt „Patchstand“ sichtbar: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „Sperrprozess“. Für die belastbare Umsetzung gilt als Auftrag: Rückgabe, Entzug, Export, Löschung und Bestätigung zusammenführen. Für Audit und Führung reicht Aktivität nicht aus; im vorliegenden Abschnitt wird dies an „Protokollierung“ konkretisiert. Benötigt wird folgender Nachweis: ein abgeschlossener Austritts- oder Rückbau-Nachweis; bewertet wird außerdem: Zeit bis zur Erkennung (hier bezogen auf „Reaktionszeit“), 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 „Patchstand“ später nicht mehr tragen.
Angriffsszenario – Wirksamkeit praktisch fassen
Der Ausgangspunkt dieses Beitrags führt beim Aspekt „Angriffsszenario“ zu einer klaren Prüffrage: Es ist zu klären, ob die Maßnahme das beabsichtigte Risiko oder Ergebnis tatsächlich verändert. Die Schwachstelle liegt nicht im Schlagwort selbst, sondern dort, wo ein kompromittiertes oder ungepatchtes Gerät trotz formaler Freigabe auf geschäftliche Daten zugreift – betrachtet im Kontext „Identitätsprüfung“. Für die beteiligten Rollen – Informationssicherheit, IT-Betrieb, Datenschutz, Anwendungsverantwortliche und Nutzende – braucht der Aspekt „Angriffsszenario“ daher einen vorab geklärten Entscheidungsweg. Für die belastbare Umsetzung gilt als Auftrag: Design, Ausführung und Wirkung getrennt beurteilen. Ob der Ansatz trägt, wird an folgendem Ergebnis geprüft: eine Wirkungsprüfung mit Gegenbeispiel und Folgemaßnahme; für den Aspekt „Angriffsszenario“ wird daraus ein eigener Prüfschritt. Die Ergebnisbeobachtung richtet sich auf: der Zusammenhang zwischen „Angriffsszenario“ und „Ungesicherte private Geräte überwiegend beim mobilen Unternehmenseinsatz“. Die Leserperspektive auf „Kosten, Aufwand und eine faire Verteilung“ schärft den Blick dafür, ob „Ungesicherte private Geräte überwiegend beim mobilen Unternehmenseinsatz“ nur beschrieben oder tatsächlich gesteuert wird.
Wiedervorlage im Blick: Zugriffsschutz
Beim Aspekt „Schwachstellenlage“ hilft ein enger Blick auf Entscheidung und Betriebswirkung: Es ist zu klären, wann eine frühere Entscheidung ihre Grundlage verlieren kann. Folgende Messperspektive zeigt, ob sich der Aspekt „Schwachstellenlage“ tatsächlich verbessert oder nur formell bearbeitet wurde: Zeit bis zur Erkennung (hier bezogen auf „Protokollierung“), Anteil konformer Geräte, offene Schwachstellen und Dauer bis zur Sperrung. Für „Zugriffsschutz“ bleibt dabei verbindlich: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „Identitätsprüfung“. Im Regelbetrieb wird folgender Punkt verankert: Zeitpunkt und ereignisbasierte Auslöser miteinander kombinieren. Für Audit und Führung reicht Aktivität nicht aus; die Bewertung erfolgt hier aus der Perspektive „Konfigurationsbaseline“. Benötigt wird folgender Nachweis: eine terminierte Neubewertung mit benannten Eingangsdaten; bewertet wird außerdem: die beobachtbare Veränderung beim Aspekt „Tests und Lernen aus erkannten Abweichungen“. Beim Aspekt „Zugriffsschutz“ ist nicht die Menge der Aktivitäten entscheidend, sondern die erkennbare Veränderung des Ergebnisses.
Ausnahmen im Blick: App-Herkunft im Kontext Patchstand
Für die heutige Einordnung von „App-Herkunft“ ist zunächst eine Unterscheidung entscheidend: 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 „Identitätsprüfung“. Die Grenze der Betrachtung bleibt eindeutig: Ein installiertes Sicherheitsprodukt ersetzt weder einen vertrauenswürdigen Zustand noch eine geübte Reaktion – betrachtet im Kontext „Reaktionszeit“. Operativ folgt daraus: Eigentümer, Begründung, Kompensation und Ablaufdatum festlegen. Für Audit und Führung reicht Aktivität nicht aus; der konkrete Prüfmaßstab wird aus „Patchstand“ abgeleitet. Benötigt wird folgender Nachweis: ein befristetes Ausnahmeregister mit Wiedervorlage; bewertet wird außerdem: Zeit bis zur Erkennung (hier bezogen auf „Gerätevertrauen“), Anteil konformer Geräte, offene Schwachstellen und Dauer bis zur Sperrung. Der Diskussionsaspekt „Messbarkeit und nachgewiesene Wirkung“ ergänzt die Betrachtung sinnvoll, weil er „App-Herkunft“ mit der tatsächlichen Anwendung verknüpft.
Der Praxistest für Gerätevertrauen bleibt bewusst einfach: Die Regel zu Zugriffsschutz muss im Normalbetrieb verständlich, beim Aspekt Angriffsszenario im Ausnahmefall entscheidbar und nach einer Änderung erneut prüfbar sein. Fehlt eine dieser Eigenschaften, besteht bei Schwachstellenlage weiterer Handlungsbedarf.