Microsoft über Intune SDK: Besser ein anderes MDM / MAM für iOS verwenden!

Microsoft bietet in der globalen Azure Infrastruktur auch ein MDM namens Intune an. Daher interessieren sich viele Kunden für Azue, da man augenscheinlich alles in einem Tenant hat: MDM, MAM, MCM, CA usw. Doch nun schreibt Microsoft öffentlich auf GitHub (mittlerweile gelöscht, aber GitHub hat eine Versionshistorie), dass man für den Schutz von mobilen Endgeräten, hier iOS, doch besser ein MDM / MAM von einem anderen Hersteller nutzen soll.

Jailbreaking / Rooting und Schutz gegen diese Anhebung der Nutzerrechte ist ein altes “Katz und Maus Spiel” und dies ist nicht neu, das weiß auch Microsoft (Anm. im folgenden Text nur noch MS). Folgerichtig steht dort auch, dass eine Kompromittierung des unteren Layers durch Jailbreaking auf iOS die Layer darüber nicht mehr geschützt sind.
MS setzt bei der Erkennung eines Jailbreaks auf Heuristik, wie z.B. nach Trustwave.

MS fehlt eine eigene Containerverschlüsselung. Auf iOS ist Microsoft demnach auf die Hardwarebasierende Verschlüsselung per keychain, welche durch einen Passcode geschützt ist. In der Minimumkonfiguration “schützt” ein vierstelliger Zahlencode Unternehmensdaten, Zugriffsschlüssel, Download-Richtlinien und Verschlüsselungsschlüssel.
Man könnte ein komplexes Passwort bei jedem Start / Öffnen einer App erzwingen, aber MS möchte dies aus UX Gründen nicht weiter verfolgen.

Es wird aber auch eine Systemschwäche von iOS erläutert. iOS hat nicht wie Android einen wirklichen Multi-User-Support, daher sind alle Daten gemeinsam in einer Enclave und werden nur anhand ihrer Quelle unterschieden. Eine Verschlüsselung auf einer dedizierten Hardware ist schneller und sicherer, möchte man aber eine zusätzliche Verschlüsselung muss dies per Software realisiert werden. Bei großen Anwendungen und Daten kann dies aber die Systemkapazitäten überfordern. Daher hat sich MS gegen eine zusätzliche Verschlüsselung entschieden.

Die Jailbreak-Erkennung von MS ist “zahnlos”, daher kann man auch keine Compliance-Richtlinien wie die Schließung von geschäftlichen Apps oder ein Gerätewipe durchführen. Einzig eine Manipulation des eigenen SDKs kann MS nachverfolgen und manipulierten Apps den Zugriff auf interne Daten verweigern. Eine eigene Lösung für AppScan wurde zwar erwogen, MS war aber nicht bereit dies zu finanzieren.

Auch MS sieht den gesteigerten Bedarf an MAM (Mobile Application Management) Lösungen, kann aber laut eigener Aussage den Sicherheitsbedenken der eigenen Kunden nicht nachkommen, zumindest nicht mit eigenen Produkten.

Dazu werden (hier verkürzt) folgende Gründe angegeben:

• Diese MDM-Drittanbieter sind in der Lage, Maßnahmen zu ergreifen, die wir nicht ergreifen können, was ihnen einen leichten Vorteil verschafft. (Anm durch die Entwicklung eigener Containerlösungen)
• MS MAM, Office und UX überwiegen die Sicherheitsbedenken der Kunden.
• Angreifer wrappen eine App mit SDK und können so Daten abgreifen.
• MS ist nicht bereit, finanzielle Mitteln für die Abwehr zu investieren.
• MAM ist nicht ausreichend. (Anm: Das sollte eigentlich alle IT Verantwortlichen klar sein, dass nur eine Komnbination von MDM, MAM, MCM, IAM, MTD, EDR, DLP hier einen Schutz aufbauen kann!)
• Keine Schutz vor Swizzle Angriffe, der letzte gezielte Angriff auf Outlook wurde durch Zufall auf reddit gesehen.

Fazit

Nur MAM, also die Verwaltung von Apps, reicht nicht aus und das gilt für alle Betriebssysteme. Es werden weitere Bausteine benötigt:

• MDM – Verwaltung der Endgeräte, heute bekannt als UEM (Unified Endpoint Management).
• DLP – Data Loss Prevention – Schutz der Daten unter anderem per DRM (Digital Rights Management).
• MTD – Mobile Threat Defense / EDR – Endpoint Defense und Response / EP – Endpoint Protection – Schutz vor Bedrohungen auf Geräte- und Anwendungsebene.
• IAM – Identity and Access Management – Wer hat von welchem Gerät aus Zugriff auf welche Daten.

Der GitHub Beitrag als PDF: