Im Rahmen des Enterprise Mobility Managements liegt ein besonderer Fokus auf der Verwaltung von (mobilen) Endgeräten. Mit Microsofts AzureAD und Intune aus Enterprise Mobility + Security lassen sich die Mindeststandard des BSI für Mobile Device Management sowohl aus technischer als auch organisatorischer Sicht erfüllen.
Erfüllt Ihr Mobile Device Management (MDM) den Mindeststandard?
Enterprise Mobility + Security ist ein Paket aus verschiedenen Clouddiensten, die EMM-Funktionalitäten zur Identitätsverwaltung (Azure AD), Application & Device Management (Intune) sowie Schutz von Informationen bzw. Dateien (Azure RMS) bieten. Mittlerweile integriert in Microsoft 365 umfassen diese Sicherheitsdienste notwendige Funktionen zur Absicherung von Clouddiensten aller Art und auch eigenen OnPremise Infrastrukturen. Dieser Artikel zitiert den Mindeststandard des BSI für Mobile Device Management nach § 8 Absatz 1 Satz 1 BSIG – Version 1.0 vom 11.05.2017 und zeigt auf, ob und mit welchem Dienst sich die Anforderungen des Bundesamt für Sicherheit in der Informationstechnik erfüllen lassen.
Veto: Dies ist keine juristische Feststellung oder Garantie, kann jedoch gern als Orientierung zur rechtlich abgesicherten Bewertung herangezogen werden.
Fazit und Empfehlung
Da die Tabellen ein wenig mehr Platz als Üblich einnehmen, ziehe ich meine Schlussworte diesmal nach oben. Da man alle Geräteklassen als mobile Geräte ansehen kann, ist ein entsprechendes Management unabdingbar. Der Mindeststandard des BSI ist hierbei ein sehr guter Leitfaden, um ein solches Management unter Beachtung notwendiger Eckpunkte einzuführen.
Manche Punkte halte ich jedoch, unter Betracht neuer Technologien und Funktionen, für diskutabel.
- Muss sich ein Gerät wirklich im Werkszustand befinden, wenn ich es mit einem MDM übernehme?
- Ist ein MDM überhaupt notwendig, wenn meine Unternehemensanwendungen via Mobile Application Management – Without Enrollment (MAM-WE) schütze?
- Muss ich die Geräteschnittstellen auf das vom Unternehmen genutzte nötigste reduzieren oder erhalte ich mir die Flexibilität und schütze meine Unternehmensdaten durch MAM und ein Mobile Content Management (MCM)?
Das Ziel sollte dabei immer die maximale Sicherheit und effiziente Nutzbarkeit der Geräte sein. Dies steht nicht entgegen der Anforderungen des BSI, die Konformität hiernach kann ja sogar noch unter den eigenen Ansprüchen liegen.
In der Praxis zeigt sich der isolierte Blick auf ein reines MDM als zu beschränkt und es ist schade, wenn ein Smartphone seine “smartness” und effiziente Anwendungsmöglichkeiten verliert, da man Funktionen ohne Risikobewertung und einen Blick in verschiedenen Sicherheitsaspekte (IAM,MAM,MCM) deaktiviert. In einigen Projekten haben wir, in Abstimmung mit Betriebsräten, unsere Best Practices gefunden, mit denen wir modernen Ansprüchen gerecht werden. Ich freue mich auf Fragen und Anregungen hierzu.
Nun aber zu den Anforderungen:
Funktionale Sicherheitsanforderungen an das MDM
Funktionale Sicherheitsanforderungen sind durch das MDM zu erfüllen.
MDM.01: Nutzdaten Anfallende Nutzdaten des MDM müssen innerhalb der IT-Infrastruktur des Betreibers verbleiben. Nutzdaten sind insbesondere Konfigurationsprofile, PIN’s, Schlüssel sowie Anwendernamen und andere persönliche Identitätsmerkmale (z. B. International Mobile Subscriber Identity (IMSI), Rufnummern). |
✅ |
MDM.02: Cloud-Dienste Wird das MDM ganz oder auch nur teilweise von einem externen Cloud-Anbieter bezogen, sind zusätzlich die Anforderungen aus dem Mindeststandard des BSI zur “Nutzung externer Cloud-Dienste” einzuhalten. |
✅ Standard Compliance-Bedingungen für Microsoft Online Services |
MDM.03: Mandantentrennung Werden mehrere Mandanten auf einem MDM verwaltet, so muss eine wirksame Trennung der Mandanten sichergestellt sein. |
✅ Bei Nutzung von Intune befindet man sich selbst in einem Mandanten. Die eigene Bereitstellung weiterer Mandanten obliegt dem Partnerstatus als Cloud Solution Provider. Weiter folgt die Trennung den Standard Compliance-Bedingungen für Microsoft Online Services |
MDM.04: Kompromittierte mobile Endgeräte Zum Schutz des MDM und der Konfiguration müssen kompromittierte verwaltete mobile Endgeräte (z. B. Jailbreak und Rooting) zeitnah erkannt und vom MDM sowie der Infrastruktur der Stelle des Bundes ausgeschlossen werden. Hierfür müssen die Schutzmaßnahmen sicherstellen, dass Sicherheitsvorfälle dem Administrator in geeigneter Weise angezeigt werden. Stellt das MDM hierfür keine wirksamen Schutzmaßnahmen bereit, sind zusätzliche technische und/oder organisatorische Maßnahmen zu ergreifen. |
✅ Intune |
MDM.05: Berechtigungsmanagement im MDM Das MDM muss über ein Rechtemanagement verfügen, so dass das Berechtigungskonzept vollständig umgesetzt werden kann. Über das Rechtemanagement müssen Zugriffsrechte zuverlässig zugeordnet werden können, so dass Benutzergruppen und Administratoren nur über Berechtigungen verfügen, die für die Aufgabenerfüllung notwendig sind (Minimalprinzip). |
✅ Intune & AzureAD |
MDM.06: SIM-Karten Das MDM muss die notwendigen Informationen bereithalten, um eine Sperrung der SIM-Karte veranlassen zu können. |
✅ ➡ Identifikation: Intune Sperrung: Mobilfunk-Provider |
MDM.07: Verteilung von Applikationen Eine zentrale Verteilung von Applikationen muss möglich sein. Diese muss den Anforderungen des geplanten Einsatzszenarios genügen (z. B. rollen- oder gruppenbasierte Verteilung). Die Deinstallation von Applikationen und das Verteilen von Updates müssen durch den Administrator auch aus der Ferne erzwingbar sein (z. B. Over-The-Air (OTA)). Werden Sicherheitsprobleme einer Applikation bekannt, so muss es möglich sein, diese Applikation zeitnah von allen mobilen Endgeräten zu deinstallieren. Dieser Vorgang muss durch das MDM erzwungen werden können, sobald eine Verbindung zwischen MDM und mobilem Endgerät besteht. |
✅ Intune |
MDM.08: MDM-Client Stellt das MDM einen MDM-Client auf den mobilen Endgeräten bereit, so sollte eine Deinstallation des MDM-Clients durch den Benutzer nicht möglich sein. Kann eine Deinstallation durch den Benutzer nicht unterbunden werden, so muss das MDM den Administrator darauf hinweisen (siehe hierzu auch Anforderung MDM.37). |
✅ Intune |
Audit
MDM.09: Protokollierung Der Lebenszyklus einschließlich Konfigurationshistorie eines mobilen Endgerätes muss ausreichend protokolliert und zentral abrufbar sein. Bei Bedarf muss der aktuelle Status der verwalteten Endgeräte durch den Administrator ermittelt werden können (Device Audit). |
✅ Intune, sowie die für das Geräteobjekt abrufbaren Protokolle im Azure AD |
Sichere Konfiguration der mobilen Endgeräte
MDM.10: Konfigurationsprofile Konfigurationsprofile (VPN-Verbindungen, WLAN-Einstellungen, usw.) dürfen nicht durch den Nutzer manuell verändert oder rückgängig gemacht werden können (siehe hierzu auch Anforderung MDM.37 ) |
✅ Intune |
MDM.11: Sichere Erstinstallation Für die Erstinstallation der mobilen Endgeräte muss das MDM eine sichere Schnittstelle bereitstellen. |
✅ Standard Compliance-Bedingungen für Microsoft Online Services |
MDM.12: Kennwörter und Gerätecodes Die Einrichtung und wirksame Durchsetzung komplexer Kennwörter und Gerätecodes auf den mobilen Endgeräten muss zentral konfigurierbar sein. Die Vorgabe, nach wie vielen Fehleingaben das Endgerät gesperrt oder gelöscht wird, muss zentral konfigurierbar sein. Ein Reset von Kennwörtern und Gerätecodes zum Entsperren des Endgeräts muss durch den Administrator auch aus der Ferne (z. B. OTA) möglich sein. Komponenten außerhalb des Einflussbereichs des MDMs (z.B. Smartcards) sind hiermit nicht gemeint. |
✅ Intune |
MDM.13: Fernlöschung (Remote-Wipe) und Außerbetriebnahme Das MDM muss sicherstellen, dass sämtliche Daten auf dem mobilen Endgerät, einschließlich Zugangsdaten und Zertifikate, auch aus der Ferne gelöscht werden können (Remote-Wipe bei bestehender Netzwerkverbindung). Werden in dem mobilen Endgerät externe Speicher genutzt, muss geprüft werden, ob diese bei einem Remote-Wipe ebenfalls gelöscht werden sollen und ob dies vom MDM unterstützt wird. Der Prozess zur Außerbetriebnahme des mobilen Endgerätes (Unenrollment) muss sicherstellen, dass keine sensitiven Daten auf dem mobilen Endgerät oder eingebundenen Speichermedien verbleiben. Dies gilt insbesondere dann, wenn das Unenrollment aus der Ferne ausgeführt wird. |
✅ Intune |
MDM.14: Automatische Sperre und Gerätesperrung (Remote-Lock) Die Einrichtung und wirksame Durchsetzung einer automatischen Sperre des mobilen Endgerätes nach Zeitvorgabe muss zentral konfigurierbar sein. Eine Gerätesperrung muss durch den Administrator auch aus der Ferne möglich sein (Remote-Lock). Kann der Remote-Lock auf dem mobilen Endgerät nicht ausgeführt werden, muss dies vom MDM in geeigneter Weise angezeigt werden können. |
✅ Intune |
MDM.15: Administration von Schnittstellen und Funktionen Schnittstellen müssen zentral über das MDM administrierbar sein. Unter Schnittstellen sind insbesondere Bluetooth, Infrarot, WLAN, SMS, MMS, GPS, NFC, RFID und USB zu verstehen. Gleiches gilt für Funktionen wie z. B. Kameras, Mikrofone, Sprachsteuerungen und Ortungsdienste. Ein Koppeln oder Verbinden mit anderen Geräten (z. B. via Apple AirPlay oder AirDrop) zum Datenaustausch oder zur Datenweitergabe muss unterbunden werden können. |
✅ Intune |
MDM.16: Verschlüsselung des Speichers Die systemeigene Verschlüsselung des mobilen Endgerätes von nichtflüchtigem Speicher muss vom MDM zuverlässig aktiviert und durchgesetzt werden können. Die Verschlüsselung muss auch schützenswerte Daten auf externen Speichermedien (z.B. SD-Karte) umfassen. |
✅ Intune Hinweis: Manche Android-Geräte unterstützen keine Verschlüsselung externer Medien. Es wird ein Austausch des Geräts empfohlen, anstatt diese Richtlinie, ggf. durch weitere Tools, zu erzwingen. |
MDM.17: Zertifikate Zertifikate zur Nutzung von Diensten (z. B. Email, ActiveSync, VPN, WLAN und Websites) auf dem mobilen Endgerät müssen zentral installiert, deinstalliert, aktualisiert und angezeigt werden können. Die Installation von nicht vertrauenswürdigen und nicht verifizierbaren (Root-) Zertifikaten durch den Benutzer muss verhindert werden können. Das MDM muss Mechanismen zur Überprüfung der Gültigkeit von Zertifikaten (z.B. OCSP) unterstützen. Die Ungültigkeit eines Zertifikates muss vom MDM in geeigneter Weise angezeigt werden. |
✅ Intune, ggf. in Kombination mit der eigenen PKI |
Vertrauenswürdige Kommunikation
MDM.18: Administrations- und Self-Service-Portale Zur Gewährleistung der Authentizität der Teilnehmer sowie Vertraulichkeit und Integrität der übertragenen Inhalte ist sämtliche Kommunikation zwischen MDM und Administrations- und Self-Service-Portalen dem Schutzbedarf entsprechend abzusichern. Die Transportverschlüsselung muss die Sicherheitsanforderungen nach Mindeststandard des BSI für den Einsatz des SSL/TLS-Protokolls6 erfüllen. VPN-Verbindungen müssen den IT-Sicherheitsrichtlinien für VPN-Verbindungen der Stelle des Bundes entsprechen. |
✅ Intune Unternehmensportal-App (Windows, iOS, Android & Web) |
MDM.19: Mobile Endgeräte Die Kommunikation zwischen MDM und mobilem Endgerät muss über einen sicheren Kanal erfolgen. Hierfür muss die Stärke der Schlüssel (Schlüssellänge und -verfahren) den IT-Sicherheitsrichtlinien der Stelle des Bundes entsprechen. Liegt dem sicheren Kanal eine Transportverschlüsselung nach TLS zu Grunde, dann muss diese dem Mindeststandard des BSI für den Einsatz des SSL/TLS-Protokolls genügen. Wird eine VPN-Verbindung genutzt, muss diese den IT-Sicherheitsrichtlinien für VPN-Verbindungen der Stelle des Bundes entsprechen. |
✅ Standard Compliance-Bedingungen für Microsoft Online Services |
Nicht-funktionale Sicherheitsanforderungen an das MDM
Nicht-funktionale Anforderungen sind durch den jeweiligen MDM-Anbieter zu erfüllen
MDM.20: Dokumentation des MDM Das MDM sowie entsprechende Aktualisierungen müssen vollständig und nachvollziehbar dokumentiert sein. Die Dokumentation umfasst: |
✅ Standard Compliance-Bedingungen für Microsoft Online Services sowie die Microsoft Intune-Dokumentation |
MDM.21: Support Supportleistungen des Anbieters müssen den Anforderungen des jeweiligen Einsatzszenarios entsprechen. Dies gilt insbesondere für: |
✅ Standard Bedingungen & SLAs für Microsoft Online Services |
MDM.22: Aktualisierungen des MDM Der Anbieter muss den Prozess zur Bereitstellung von Aktualisierungen des MDM (Updates und Patches) darstellen und zusichern. |
✅ Standard Bedingungen für Microsoft Online Services |
Sicherheitsanforderungen an den Betrieb
Die Wirksamkeit von Sicherheitsmechanismen hängt auch vom jeweiligen Betrieb ab. Der Betreiber hat daher nachfolgende technische und organisatorische Maßnahmen umzusetzen.
Technische Maßnahmen
MDM.23: Datensicherungen des MDM Es müssen wirksame Mechanismen für das Backup aller Daten und Einstellungen des MDMs existieren, so dass dieser im Bedarfsfall funktionsfähig wiederhergestellt werden kann. |
✅ Standard Bedingungen & SLAs für Microsoft Online Services |
MDM.24: Fernzugriff auf das MDM Fernzugriffe auf das MDM müssen auf einem kryptographisch abgesicherten Kanal erfolgen (vertraulich, integer, authentisch). Die Vorgaben der technischen Richtlinie TR-02102-1 „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“8 müssen beachtet werden. Liegt eine Transportverschlüsselung nach TLS zu Grunde, dann muss diese dem Mindeststandard des BSI für den Einsatz des SSL/TLS-Protokolls9 genügen. |
✅ Standard Bedingungen & SLAs für Microsoft Online Services sowie eigene Zugangsbeschränkungen (z.B. ADFS, Conditional Access, VPN) |
MDM.25: Erstinstallation der mobilen Endgeräte Alle mobilen Endgeräte sind in dem MDM zu verwalten. Vor Verteilung der Grundkonfiguration muss sich das mobile Endgerät im Werkszustand befinden. Nicht konfigurierte mobile Endgeräte dürfen keinen Zugriff auf die Infrastruktur der Stelle des Bundes haben. |
✅ Azure AD Join, Conditional Access, Apple Device Enrollment Program & Android for Work |
MDM.26: Verschlüsselung des Speichers Die systemeigene Verschlüsselung des mobilen Endgerätes von nichtflüchtigem Speicher muss aktiviert sein. Schützenswerte Daten auf externen Speichermedien (z.B. SD-Karten) sind zu verschlüsseln. |
✅ Intune Hinweis: Manche Android-Geräte unterstützen keine Verschlüsselung externer Medien. Es wird ein Austausch des Geräts empfohlen, anstatt diese Richtlinie, ggf. durch weitere Tools, zu erzwingen. |
MDM.27: Monitoring und Diagnose Falls Funktionen zur Übermittlung von Monitoring- und Diagnose-Informationen an Dritte vorhanden sind, sind diese zu deaktivieren. |
✅ Intune |
MDM.28: Kennwörter und Gerätecodes Die mobilen Endgeräte müssen durch Kennwörter oder Gerätecodes geschützt sein. Die Stärke von Kennwörtern und Gerätecodes (minimale Länge, Beschaffenheit, Komplexität und Gültigkeitsdauer) muss der IT-Sicherheitsrichtlinie der Stelle des Bundes entsprechen. Dies gilt für Zugriffe auf das MDM (Server und Administrationsportale) und mobile Endgeräte gleichermaßen. Der Prozess zur Zurücksetzung eines Kennwortes oder Gerätecodes muss etabliert sein. Die Anzahl der maximal möglichen Fehlversuche für die Eingabe des Gerätecodes muss festgelegt und technisch umgesetzt werden. Die Anzahl der möglichen Fehlversuche darf 10 nicht überschreiten. Nach Überschreitung der Grenze müssen alle auf dem Gerät gespeicherten Daten automatisch gelöscht werden. |
✅ Intune & AzureAD & Möglichkeit für eigene Zugriffsbeschränkungen |
MDM.29: Automatische Sperre und Gerätesperrung Die automatische Sperre des mobilen Endgerätes muss genutzt und zentral vorgegeben werden. Die Gerätesperrung muss sich bereits nach einer angemessenen Phase von Inaktivität einschalten. Die Frist muss den Vorgaben der IT-Sicherheitsrichtlinien der Stelle des Bundes entsprechen, darf aber einen Zeitraum von 10 Minuten nicht überschreiten. |
✅ Intune |
Organisatorische Maßnahmen
Kommentar (Tim Dorbandt): Administratoren, die wissen was sie tun, sollten eine Grundvoraussetzung zum Betrieb aller IT-Dienste sein. Was die Sicherheit von Unternehmensdaten betrifft, so wird meist die Sensibilisierung der Benutzer am stärksten vernachlässigt. Gerade hier findet sich jedoch die größte Schwachstelle eines Sicherheitskonzepts, das auf Verständnis, Vertrauen und Loyalität beruht. Warum sollte ein Anwender den Daten seines Unternehmens eine gleiche oder gar größere Gewichtung zukommen lassen als zum Beispiel seinen eigenen Fotos, Finanz- und Gesundheitsdaten?
MDM.30: Administration des MDM Das MDM muss von geschulten Administratoren bedient werden. |
✅ |
MDM.31: Sensibilisierung der Benutzer Benutzer von mobilen Endgeräten müssen über Sinn und Zweck der Sicherheitsmaßnahmen sensibilisiert werden. Dies gilt insbesondere, wenn eine Veränderung der Konfigurationsprofile technisch nicht verhindert werden kann. In diesem Fall müssen die Benutzer entsprechend verpflichtet werden, diese nicht zu verändern. |
✅ |
MDM.32: Dokumentation Die Sicherheitsmechanismen und -einstellungen für mobile Endgeräte müssen festgelegt und nachvollziehbar beschrieben sein (z. B. PIN-Code-Verfahren, automatische Sperre, Regeln für die Deinstallation von Konfigurationsprofilen, usw.) |
✅ |
MDM.33: Regelmäßige Überprüfungen Konfigurationsprofile und Sicherheitseinstellungen müssen regelmäßig überprüft werden. Hierbei sind insbesondere die Vorgaben dieses Mindeststandards sowie Vorgaben aus den eigenen IT-Sicherheitsrichtlinien der Stelle des Bundes zu berücksichtigen. Sollen neue Betriebssystemversionen der mobilen Endgeräte eingesetzt werden, ist vorab zu prüfen, ob die Konfigurationsprofile und Sicherheitseinstellungen weiterhin wirksam und ausreichend sind. Abweichungen müssen korrigiert werden. Die vom MDM erzeugten Protokolle müssen regelmäßig auf ungewöhnliche Einträge überprüft werden. Die zugeteilten Berechtigungen für Benutzer und Administratoren sind mindestens halbjährlich hinsichtlich ihrer Angemessenheit zu überprüfen (Minimalprinzip). |
✅ |
MDM.34: Umgang mit Sicherheitsvorfällen Für den Umgang mit Sicherheitsvorfällen muss ein angemessener Prozess etabliert sein. Dieser muss insbesondere folgende Szenarien abdecken: |
✅ |
MDM.35: Aktualisierung der Betriebssysteme Es müssen Arbeitsprozesse geplant, getestet und angemessen dokumentiert sein, damit sicherheitsrelevante Patches und Updates unverzüglich eingespielt werden können. Werden sicherheitskritische Aktualisierungen nicht innerhalb von vier Wochen nach der Veröffentlichung eingespielt, ist dies gesondert zu begründen und zu dokumentieren. MDMs und mobile Endgeräte für die keine sicherheitsrelevanten Aktualisierungen mehr bereitgestellt werden, sind aus dem Betrieb zu nehmen. |
✅ |
MDM.36: Konfigurationsprofile und MDM-Client Kann eine unautorisierte Löschung von Konfigurationsprofilen oder des MDM-Clients technisch nicht verhindert werden (z.B. durch Passwortschutz), sind organisatorische Maßnahmen (z. B. Belehrung und Sensibilisierung des Nutzers) zu ergreifen. |
✅ |
MDM.37: Endgerätenamen Namen der mobilen Endgeräte dürfen keine Merkmale enthalten, die Rückschlüsse auf den Benutzer oder die Stelle des Bundes ermöglichen. |
✅ |
MDM.38: Bereitstellung von Applikationen Es muss sichergestellt sein, dass ausschließlich sicherheitsgeprüfte Applikationen bereitgestellt werden. Dies kann durch einen definierten Freigabeprozess mit geeigneten Bewertungskriterien sichergestellt werden. Die Nutzung von vorinstallierten Applikationen und Online-Diensten, insbesondere von externen cloudbasierten Diensten muss bewertet und im Bedarfsfall systemseitig verhindert werden. |
✅ Option zum Black- und Whitelisten |
MDM.39: Nutzung von Schnittstellen und Funktionen Die Freischaltung von Schnittstellen und Funktionen ist zu regeln und auf das dienstlich notwendige Maß zu reduzieren. |
✅ Intune |
MDM.40: Push-Nachrichten Es müssen Regelungen für das Anzeigen von Push-Nachrichten auf dem Sperrbildschirm der mobilen Endgeräte getroffen werden. Diese sind insbesondere vom jeweiligen Schutzbedarf abhängig. Die Benutzer sind entsprechend zu sensibilisieren. |
✅ Intune |