Applikationen und Daten: die schwächsten Glieder in der Security Journey

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. 

Warum tun sich Unternehmen mit dem Schutz und dem Management von Daten und Applikationen schwerer?

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:

• MFA aktivieren
• Legacy Auth abdrehen
• Risk-based Policies einschalten

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:

• Klassifizierung existiert höchstens als Vorgabendokument, nicht als gelebtes Verhalten
• Es fehlt ein gemeinsames Verständnis: Was ist vertraulich, was nicht?
• Niemand «besitzt» das Thema in der Linie, also bleibt es liegen

Applikationen: Die Gefahr im Keller

Wenn ich «Applikationen» sage, meine ich beides:

• SaaS wie Microsoft 365, CRM, Branchenlösungen, Cloud-Tools
• on-prem-Lösungen wie ERP, Fileserver, RDS/Terminalserver, Fachapplikationen

Weil die Applikationslandschaft eines jeden etablierten Schweizer KMUs historisch gewachsen ist, kommt es immer zu Challenges im Schutz und in der Verwaltung:

• Alte Auth-Verfahren, die ihr nicht einfach ersetzen könnt
• Service-Accounts und Sonderrechte, die niemand gerne anfasst
• RDS- und VPN-Zugriffe, die technisch funktionieren, aber mangelhaft konfiguriert sind

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.

Wenn die Lohnliste an ChatGPT übergeben wird

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. 

3 konkrete Werkzeuge, um Daten und Applikationen besser zu schützen

1. Mobile Device Management (MDM): Geräte in den Griff bekommen

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:

• Geräte-Enrolment (iOS/Android/Windows) inkl. zentralem Inventar und Gerätegruppen
• Konfigurationsprofile: WLAN/VPN, Zertifikate, E-Mail, Basis-Härtung
• Security erzwingen: PIN/Biometrie, Verschlüsselung, OS-Mindeststand, Root/Jailbreak-Block
• Updates & Compliance: Update-Ringe, Compliance-Regeln, Reporting/Alerts
• Zugriff & Incident: Conditional Access nur für compliant Devices, Remote Lock/Lost Mode/Full Wipe

Wenn ihr das als Teil eurer Workplace-Standardisierung angehen wollt:
https://www.firstframe.net/workplace-services

2. Mobile Application Management (MAM): Daten in der App absichern (auch BYOD)

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:

• App Protection Policies für Outlook/Teams/OneDrive/Office (auch BYOD)
• In-App-Schutz: App-PIN/Biometrie, Timeout, Verschlüsselung in der App
• Datenabfluss verhindern: Copy/Paste nur in «managed apps», kein Export in private Apps/Clouds
• Zugriff absichern: Conditional Access nur via «approved apps» plus aktiver App-Schutz
• Offboarding/Incident: Selective Wipe entfernt nur Firmen-Daten und Tokens, privat bleibt privat

Mein Kollege MIchael Hediger hat dem Thema MAM einen eigenen Blog gewidmet: https://blog.firstframe.net/mobile-application-management

3. Data Loss Prevention (DLP): Datenflüsse steuern, ohne den Betrieb zu blockieren

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:

1. 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».

2. 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.

3. 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.

4. 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:

   

5. 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.

Fazit: Auch Rom wurde nicht in einem Tag erbaut

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.