Viele KMU haben Identitäten und Geräte inzwischen recht gut im Griff. Doch sobald es um Daten und Applikationen geht, kippt die Realität: Klassifizierung wird nicht gelebt, Application-Owners fehlen, und Shadow-IT, insbesondere KI-Tools werden zum Abflusskanal. In diesem Beitrag zeige ich, warum genau diese zwei Bereiche in der Security Journey oft die schwächsten Glieder sind und wie ihr mit MDM, MAM und DLP Gegensteuer geben könnt.
In vielen Firmen sieht Security mehr oder weniger ordentlich aus, solange man über Identitäten spricht.
MFA? Meistens aktiv.
Conditional Access? Kommt vor.
Geräte? Mehrheitlich verwaltet.
Und dann kommt der Moment, in welchem jemand fragt: «Welche sind eigentlich unseren sensiblen Daten und wie verhindern wir deren Abfluss über Shadow-IT-Tools?». Ja dann sieht die Sache anders aus.
Applikationen und Daten sind oft jene Handlungsfelder in der Security Journey, in denen die Praxis hinter der Theorie her hinkt.
In unserem Security Journey-Bewertungsmodell kombinieren wir die Prozesssicht (NIST CSF) mit der Architektursicht des CISA Zero Trust Maturity Models. Dies ermöglicht eine 360-Grad-Rundumsicht auf den Reifegrad der eigenen IT-Sicherheit.
Im Modell gibt es die fünf Architektur-Ebenen: Identitäten, Geräte, Netzwerke, Applikationen und Daten.
Das ist schön trennscharf gezeichnet, aber in der Praxis überlappen diese Bereiche stark.
Dazu ziehe ich wieder den Vergleich mit den Benutzeridentitäten heran. Identitäten haben einen natürlichen «Owner»: die IT. Da gibt es Prozesse, Rollen, Berechtigungen, Offboarding. Und es gibt Massnahmen mit sofort sichtbarem Effekt:
Das fühlt sich direkt nach Security an. Und es ist in einem Team sauber verortet.
Daten entstehen hingegen im Business: Angebote, Verträge, Kundendaten, HR-Dossiers, Export-Listen, Projektordner, Teams-Chats. Und dort passiert oft folgendes:
Wenn ich «Applikationen» sage, meine ich beides:
Weil die Applikationslandschaft eines jeden etablierten Schweizer KMUs historisch gewachsen ist, kommt es immer zu Challenges im Schutz und in der Verwaltung:
In der Praxis treffe ich es immer wieder an, dass Legacy-on-prem-Applikationen im gefährlichen Niemandsland hängen: Es gibt keinen klaren Application-Owner und Patches und Upgrades werden nicht konsequent eingespielt aus Angst vor Ausfällen, oder im Extremfall sogar aufgeschoben.
Ob ihr wollt oder nicht: Mitarbeitende nutzen KI-Tools. Manchmal offiziell, manchmal im Browser, manchmal «nur schnell». Und genau hier wird das Thema Datenklassifizierung plötzlich sehr konkret.
Stellt euch vor: Eine Person in einer Assistenzposition wird gebeten, die aktuelle Lohnliste abzugleichen mit den Lohnempfehlungen des Branchen-Dachverbandes. Anstatt das komplizierte PDF Seite für Seite zu lesen und die Lohnwerte im Excel Zeile für Zeile zu prüfen, werden beide Dateien in eine ChatGPT-Konversation hochgeladen und der Task an die KI ausgelagert. Und schon ist es passiert: schützenswerte Personendaten sind zu OpenAI abgeflossen.
MDM heisst: Geräte zentral verwalten, Mindeststandards erzwingen, Zugriff auf die Unternehmens-IT nur für «gesunde» Devices erlauben.
Das Hauptwerkzeug ist Microsoft Intune, was wir typischerweise umsetzen:
Wenn ihr das als Teil eurer Workplace-Standardisierung angehen wollt:
https://www.firstframe.net/workplace-services
MAM schützt eure Firmen-Daten innerhalb der App, selbst wenn das Gerät privat ist. Das ist oft der Weg aus der «entweder wir kontrollieren alles oder gar nichts»-Falle.
Auch hier ist Intune das Werkzeug, was wir typischerweise damit umsetzen:
Mein Kollege MIchael Hediger hat dem Thema MAM einen eigenen Blog gewidmet: https://blog.firstframe.net/mobile-application-management
Mit Microsoft Purview können Schutzmechanismen für Daten und Informationen definiert und bis hinunter auf das Level der Netzwerkaktivität durchgesetzt werden.
Dadurch kann die Nutzung von LLM-Chats nach wie vor zugelassen werden, aber es wird verhindert, dass sensitive Daten abfliessen.
Am Beispiel der Lohnliste würde ein Vorgehen wie folgt umgesetzt werden:
Schutzbedarf definieren: Die Lohnliste wird als klar schützenswert eingestuft (Personendaten). In Purview wählt ihr dafür passende «Sensitive Information Types» (z.B. AHV-Nummern, IBAN, Personalnummern) und ergänzt das Ganze idealerweise mit einem Label wie «Vertraulich».
Regeln bauen (DLP-Policy): Ihr definiert eine DLP-Policy für die relevanten Kanäle (Exchange, SharePoint, OneDrive, Teams, Browser). Beispiel: Wenn Personendaten erkannt werden, dann wird das Teilen nach extern blockiert oder mindestens mit einer harten Warnung und Begründungspflicht versehen.
Abflusswege absichern: Ihr bildet die typischen Wege ab, wie so eine Datei typischerweise das Haus verlässt: Mail an extern, Teilen per Link, Gastzugriffe, Download/Sync, Copy/Paste aus M365-Apps, Upload in Browser-Tools. Für legitime Prozesse definiert ihr bewusst und gezielt die Ausnahmen.
Coaching oder Hammer: Je nach Sicherheitsstufe und Vertrauenswürdigkeit der Information kann mit der Policy lediglich eine Warnung angezeigt werden oder die Aktivität wird direkt blockiert. Am Beispiel der Lohnliste wird direkt blockiert:
Betrieb und Tuning: Ihr überwacht Alerts und Reports, reduziert False Positives, erkennt Hotspots (welche Teams, welche Workflows) und definiert einen klaren Incident-Prozess: Wer prüft, wer eskaliert, wer entscheidet, und wie wird dokumentiert.
Die Journey-Matrix arbeitet mit Reifestufen von 1 bis 5. Das Ziel ist es nicht, von jetzt auf Stufe 5 zu springen. Wichtig ist, die Journey zu starten und Stufe für Stufe eine höhere Cyberresilienz aufbauen zu können. Das muss zwingend auch die «unbequemen» Handlungsbereiche der Daten und Applikationen umfassen. Mit Mobile Device Management, Mobile Application Management und Data Loss Prevention habt ihr drei wirkungsvolle Werkzeuge an der Hand, um die IT-Sicherheit massgeblich zu verbessern.