Wie immer spannend die Grafiken von asymco.com. Finde ich korrekt von RIM, Apple und HTC, dass sie verkaufte Geräte ausweisen und nicht nur Shipments

Was sofort auffällt, wenn man vorher nur Samsungs und HTCs verwendete, ist die neue Ice Cream Sandwich Oberfläche:

Mir gefällt die Oberfläche mit dem dunklen Hintergrund und den weissen und blauen Highlights sehr gut. Wie vielfach geschrieben, wirkt die Oberfläche aufgeräumter und weniger verspielt als die bisherigen Android Versionen. Spontan erinnert es mich ziemlich an die Oberfläche des Blackberry 5 OS (sorry für den crappy Screenshot):

Auch Windows Phone 7 ähnelt mit dem dunklen Hintergrund und der strikten Farbgebung diesem Stil (Trolle, sattelt eure Pferde noch nicht. Ich werfe hier kein Plagiat vor). Mir gefallen jedenfalls alle drei Oberflächen sehr gut. Doch was hat das mit Standard zu tun. Wir kommen dazu.

Einer der grössten Kritikpunkte an Android ist die Fragmentierung des Systems. Viele Versionen sind im Umlauf. Gerätehersteller und Netzbetreiber machen alle ihre Anpassungen am Aussehen und dem Funktionsumfang von Android. Einige mit guten Absichten, da sie denken ihre eigene Oberfläche sei tatsächlich einfacher/schöner/besser zu bedienen, andere aber auch mit zweifelhaften Absichten indem sie Bloat- und Spyware installieren.

Was die Oberflächen und Anpassungen aber immer verursachen sind höhere Aufwände bei der Aktualisierung auf eine neue Android Version. Die Anpassungen müssen nämlich angepasst und wieder getestet werden. In Vergangenheit interessierte das die Hersteller weniger. Das Gerät ist ja schon verkauft. Die Tatsache zeigt dieser Beitrag hier ziemlich eindrücklich auf. An der letztjährigen Google-Entwicklerkonferenz wurde das Thema dann auch aufgegriffen und eine “Update Alliance” mit den grossen Herstellern gebildet. Während mindestens 18 Monaten sollten Geräte die neueste OS-Version erhalten. Die Ernüchterung ist allerdings zum Ende des letzten Jahres gekommen. Keiner spricht mehr von der Update Alliance oder hätte etwas davon gehört. So laufen heute noch 40% der Android-Geräte mit sehr alten Versionen (max 2.2 – immerhin im Dezember 2010 durch 2.3 abgelöst worden). Die aktuelle Version 4.x, immerhin im Oktober 2011 verfügbar, verwenden lediglich 0.6% der Geräte (besagte Galaxy Nexus und Nexus1 sind auch die einzigen die momentan auf Android 4 laufen).

Was sind die Probleme dieser vielfältigen Versionen? Zum einen ist es grundsätzlich ein Problem, wenn alte Software im Einsatz ist. Allfällige Sicherheitslücken werden nicht mehr gefixt, Funktionen können nicht verwendet werden, Unterstützungssoftware ist allenfalls nicht mehr mit alten Versionen kompatibel etc. Das ist dem Privatanwender vermutlich bis auf die funktionalen Erweiterungen relativ egal, ein Unternehmen muss sich der Frage aber sicherlich stellen. Ein weiteres Problem von vielfältigen Versionen ist der Betrieb einer Geräteflotte. Jedes Gerät, jede Oberfläche muss evaluiert, getestet und supported werden. Gerade bei Smartphones wird viel Support dem Anwender übergeben und dieser muss sich oft auf Anweisungen oder Anleitungen verlassen. Diese Aufwände explodieren, wenn mehr als eine Oberfläche im Betrieb ist. Von unterschiedlichem Funktionsumfang gar nicht zu reden. Auch für den Anwender ist Android oftmals etwas verwirrlich. Anwendungen lösen ihre Oberflächen jeweils selber. Der Anwender ist so oft mit unterschiedlichen Betriebskonzepten konfrontiert. Alles Gewöhnungssache möchte man denken. Doch zu bedenken ist es.

Das Problem mit den unterschiedlichen Oberflächen hat man jetzt mit Android 4.0 ein wenig entschärft:

In Android 4.0, Holo is different. We’ve made the inclusion of the unmodified Holo theme family a compatibility requirement for devices running Android 4.0 and forward. If the device has Android Market it will have the Holo themes as they were originally designed.

Will ein Hersteller also mit der neuesten Version von Android auf Dienste wie Google Market, etc. zugreifen, ist er verpflichtet die Standardoberfläche zumindest auf dem Gerät zu belassen. Anwendungsentwickler können somit die Elemente dieser Oberfläche verwenden. Ein Unternehmen könnte, zur Vereinfachung des Supports und der Erstellung von Anleitungen, eben auf diese Oberfläche zurückgreifen. Wie dies  möglich ist, muss bei den ersten Geräten ohne Standard-Android geprüft werden. 

Es ist aus Sicht von Standardisierungsfreunden jedenfalls ein Licht im Tunnel. 

Für den User sicher einerseits komfortabel. Andererseits finde ich es zuweilen sogar schade nicht explizit zu wissen was Updates für neue Funktionen bringen. Das weil ich relativ schnell im Apple Appstore Anwendungen aktualisiere. Die Zusatzfunktionen finde ich dann jeweils eher zufällig oder weil ich im Netz darüber las.

Warum aber problematisch? Android hat ja keine Qualitätskontrolle was den Code angeht, sondern setzt auf die Kontrolle durch die Community. Obwohl das Prinzip ebenfalls seine Berechtigung hat, ist es weniger zeitnah als eine vorgelagerte Kontrolle wie es Apple und Microsoft machen. So kann es vorkommen, dass Anwendungen schädlichen Code enthalten (Daten ausspähen, verteilen, etc.) und das erst durch News publik wird. Google kann dann diese Applikationen von den Geräten entfernen. bis dahin können aber schon Daten abgeflossen sein. Der andere Fall ist das Update. Es kann eine Anwendung in den Market kommen, und eine einfache Funktion erfüllen (bsp. Ringtones, Wallpapers, etc.) Lässt man nun Autoupdates zu, kann diese Applikation zu einem späteren Zeitpunkt ihren Zweck völlig ändern und die Anpassung wird automatisch im Hintergrund installiert.

Das Risiko ist definitiv erhöht, auch wenn natürlich das bewusste Updaten durch den Anwender nicht viel sicherer ist, da in der Beschreibung des Updates nicht stehen wird: “Von nun an lesen wir ihre SMS aus und senden sie an einen russischen Server”

via t3n.de

Anbei ein kurzer Überblick, was gemäss meinen Beobachtungen neu hinzugekommen ist. Die Policies sind im iPCU in Payloads unterteilt:

Restrictions-Payload:

Gerätefunktionalität:

- Siri erlauben

- Benutzer muss für alle Einkäufe das iTunes Store-Kennwort eingeben (verhindert wohl Apps innerhalb eines gewissen Zeitraums ohne PW-Eingabe zu installieren)

- Game Center Einstellungen: Mehrspielermodus erlauben

- Game Center Einstellungen: Hinzufügen von Game Center-Freunden zulassen.

iCloud

- Backup erlauben

- Synchronisierung von Dokumenten erlauben

- Fotostream erlauben (Nichterlauben kann zu Datenverlust führen, da die im Fotostream gespeicherten Bilder gelöscht werden)

Sicherheits- und Datenschutzrichtlinien erzwingen:

 - Diagnosedaten dürfen an Apple gesendet werden

- Benutzer dürfen nicht vertrauliche TLS-Zertifikate annehmen

- Verschlüsselte Backups erzwingen (Was ich noch nicht getestet habe, ist ob dies auch für die iCloud Backups gilt)

 

VPN-Payload

 - Für alle Daten (Somit kann der ganze Netzverkehr über die VPN-Verbindung geschickt werden, und damit im Unternehmen über einen Proxy kontrolliert werden)

E-Mail Payload

- Bewegen erlauben: Zwingt die Accounts in den Sandbox-Modus (damit werden für viele Anwender Drittlösungen wie ehemals MobileOffice eigentlich obsolet, wenn es lediglich darum geht die E-Mail-Daten in einer Sandbox zu speichern. Verhindert ebenfalls den Abfluss von Informationen ohne diese über einen Server verschicken zu müssen.)

- Gleiche Einstellung auch in Exchange möglich

 - Zusätzlich lassen sich Zertifikate oder SCEP-Settings für die Signierung/Verschlüsselung von Mails definieren.

 

Was nicht direkt im iPCU ersichtlich ist, ist das Verhalten von Anwendungen die über ein MDM verteilt werden. Wir verteilen bspweise eine App die als Quickguide die Services erklärt. Dies aus dem Grund, dass der Anwender das Gerät am MDM provisioniert, und auf diesem Weg direkt die notwendigen Anleitungen erhält. Nun konnte der Anwender die Kontrolle des MDM immer deinstallieren, hatte dann aber auch die Einstellungen und Zertifikate nicht mehr. Somit konnte man verhindern, dass der Anwender weiterhin auf Unternehmensressourcen zugreifen kann, wenn er kein MDM mehr installiert hat. Anders verhielt es sich mit den Applikationen die man verteilt hat. Diese blieben auf dem Gerät. Mit iOS 5 ändert dies nun. Applikationen werden, wenn über MDM verteilt, automatisch zu “managed Applications”. Wenn also die MDM-Kontrolle entfernt wird, werden auch die Applikation und deren Daten gelöscht. Somit könnte man kritischere Applikationen entwickeln und verteilen.

Ben-Itzhak rejects the idea that the vulnerability of computers could be reduced if they were locked down to a restricted set of applications.
The only reason that Operating Systems like Apple’s OS X and iOS haven’t seen much malware is because their limited market share means that it isn’t worth developing the attack tools.

Quelle zdnet

Nun ja. Im Fall von Mac OS X glaube ich das ja sogar auf einer hohen Ebene. Im Fall von iOS sollte der Marktanteil (17% Smartphone; >80% Tablets) doch reichen um einen Angriff lohnend zu machen. Könnte es nicht sein, dass der Genehmigungsprozess von Apple doch ein bisschen zu gut wirkt um es lohnend zu machen Malware zu entwickeln?

Wenn man sich aber für eine MDM-Lösung entscheiden muss, wird es schwierig. Da Apple Standards anbietet, unterscheiden sich die Hersteller auch nicht gross. Eine doch gute Übersicht hat enterpriseios.com

erstellt.

Immer öfter sind die Leute mit der gesamtheitlichen Erfassung von Ausgangslagen überfordert. Ist mir gerade wieder bewusst geworden als ich die Kommentare zu der Ankündigung des EAS Siegels las:

The reason we would like to see this is there are short comings to the Windows Phone 7 and even the iPhone 4 implementations of the ActiveSync policy settings. It’s tough to push back against iPhone users now with this logo is out there, but for example our security folks believe we need full device encryption (including storage card) which Windows Phone 7 and iPhone 4 do not support.

 

Nun könnte man meinen das sei eine legitime Anforderung der “Security Folks” und des Admins der hier kommentiert. Sind doch Speicherkarten noch einfacher entfernbar und nicht durch ein Passwort geschützt. Ist das iPhone und das Windows Phone aber unsicherer weil sie keine Speicherkartenverschlüsselung haben? Unwahrscheinlich. Sie haben nämlich auch keine Speicherkartenslots…

Um diesem Dilemma zu begegnen hat Microsoft diese Woche das “Exchange Activesync Logo Programm” angekündigt. Um mit diesem Logo werben zu können, verpflichten sich Hersteller zur Unterstützung eines Grundsets an Policies die den Einsatz von Mobilgeräten sicher machen. Wenig überraschend ist die Liste der bisher “zertifizierten” EAS Logo Programm Mitglieder:

• Apple iOS 4
• Nokia mit Mail for Exchange
• Windows Phone 7
• Windows Mobile 6.5 (für Industriegeräte zuweilen noch interessant )

Doch wie kommt man zu dem “Gütesiegel”? Gemäss dieser Liste sind folgende Policies zu unterstützen:

1. Must be current EAS licensee –> Eigentlich noch logisch
2. Use EAS v14 or later –> ansonsten könnten die Policies Backendseitig gar nicht gesetzt werden
3. Direct Push email, contacts & calendar –> Qualitätsgrösse für Anwender. Wer will schon manuell synchronisieren im 2011?
4. Accept, Decline & Tentatively Accept meetings –> siehe oben
5. Rich formatted email (HTML) –> txt-e-Mails sind tot! Lang leben Fett und Kursiv um seinem E-Mail Gewicht zu verpassen.
6. Reply/Forward state on email –> Ich will doch wissen ob ich morgens im Halbschlaf eine Mails schon beantwortet habe.
7. GAL Lookup –> Man möchte ja auch Leute adressieren die man nicht im persönlichen Adressbuch hat.
8. Autodiscover –> Auch für den Benutzer bei Ersteinrichtung sehr hilfreich.
9. ABQ strings provided: device type and  device model –> Hier sind speziell die grünen Roboter Geräte nicht sehr gesprächig was die Massnahmen basierend auf OS etwas schwierig gestaltet.
10. Remote Wipe –> Grundvoraussetzung für ein mobiles Gerät finde ich.
11. Password Required –> siehe oben!!
12. Minimum Password Length –> Hier wird es langsam spannend. Das können die meisten heute nicht.
13. Timeout without User Input –> Das Passwort ist auch nur so hilfreich wie es verlangt wird wenn das Gerät nicht verwendet wird.
14. Number of Failed Attempts –> kennt jeder der sein iPhone mal an einem Apero hat liegen lassen (Löschen nach 10 Fehlversuchen et al)

Ich kann aus persönlicher und leidlicher Erfahrung berichten wie viele einfacher ein solches Siegel Geräteevaluationen machen kann. Wird dieses Grundset von Policies auch vom Unternehmen als Grundset zur Unterstützung verwendet, kann in Zukunft nur noch auf das Siegel verwiesen werden.

Update: Der belesene User wird sich fragen warum die Verschlüsselungspolicy keine Voraussetzung ist? Ratet welches zeitgemässe Device keine Verschlüsselung supported? Genau Windows Phone 7. Das eigene Ross aus so einem Stall auszuschliessen wäre ja dann auch blöd

Das ist natürlich nicht die Meinung. Um zu erklären wieso ich Smartphone Viren für vernachlässigbar halte, muss man vielleicht ein paar Begriffe klären. Was ist so ein Virus eigentlich? Wir alle haben ja schon von Computerviren gehört. Im Bereich Viren und PC Security hört man immer wieder drei Begriffe. Malware, Virus und Trojaner. Folgende Grafik soll das etwas aufzeigen:

Als Malware (gemäss Wikipedia ein Kofferwort aus malicious & software) wird Software mit bösartiger Absicht bezeichnet. Also ähnlich wie Microsoft Office. Viren und Trojaner sind dann Unterarten die sich nur in der Verteilung unterscheiden. Ein Virus kann sich, wie sein medizinisches Pendant, selbstständig verteilen. Dies über Internet, Bluetooth, etc. Ein Trojaner ist Malware die ihre böse Absicht versteckt. Meist werden harmlos scheinende Spiele oder kleine Systemtools verwendet um dann bösen Code einzuschleppen. Trojaner sind aber auf den Einlass in die eigenen Gefilde durch den Anwender angewiesen (analog Trojanisches Pferd und woher wohl der Name kommt).

Nun zu Smartphones. Viren könnten sich sehr einfach über die ständig laufenden Datenverbindungen GSM, WI-FI und Bluetooth verteilen. Dafür wurden die Betriebssysteme aber vorbereitet. Anders als bei den PC-Pendants sind Smartphone-Betriebssysteme sehr reduziert im Funktionsumfang und bieten daher weniger Angriffsfläche. Malware im allgemeinen und Trojaner im speziellen sind aber sehr wohl eine Gefahr wie die letzte Woche eindrücklich zeigte:

http://mashable.com/2011/03/01/android-malware-apps/ und 100+ weitere Links. Was ist passiert:

Eine Gruppe von Applikationsentwicklern bot Applikationen an welche einer bereits populären Applikation stark glichen resp. zum Teil 1:1 die gleichen Funktionen boten. Mit diesen Applikationen wurde aber Code installiert der eine Android 2.2 Schwachstelle ausnützt welche zum einen Daten auslesen und versenden, und zum anderen, weit schlimmeren, weiteren Code aus dem Internet installieren lässt. Durch den Benutzer unbemerkt (eine weitere Verteilungsart genannt Backdoor). Google reagierte rasch gemäss ihren Market-Policies und sperrte die Applikationen (um die 50), deren Entwickler und deinstallierte die Applikationen auf den betroffenen Geräten (mind. 50’000! Update 260’000!!). Google hat hier den selben Mechanismus den auch Apple in iOS hat um ungewünschte Software nachträglich von Geräten zu entfernen. Apple wurde hier noch kritisiert, da dahinter hauptsächlich die Zensur-Vorwürfe vermutet wurden. Aktuelles Beispiel zeigt aber eindrücklich wie wichtig/nützlich der Mechanismus sein kann. Was Google allerdings nicht weiss und demnach nicht entfernen kann, ist der Code der durch die Applikation eingeschleppt wurde.

Dem Anwender der von dieser Malware betroffen war, bleibt eigentlich nur eins. Sein Gerät auf Werkseinstellungen zurücksetzen. Unschön und immer mit Aufwand und dem Risiko von Datenverlust verbunden. Google selber hat den Fix für die Sicherheitslücke ja bereits in den neueren OS-Versionen behoben. Für die 2.2er-Geräte stellt Google ebenfalls einen Fix zur Verfügung, diesen zu verteilen ist aber in Verantwortung von Geräteherstellern und Netzbetreibern. Diese zeigen sich unterschiedlich bereit OS-Updates zu verteilen, da verkaufte Geräte verkauft sind und sich mit diesen kein Gewinn mehr machen lässt (so tickt diese Industrie leider schon länger).

Auch an diesem Beispiel zeigen sich wieder die Unterschiede der zwei Herangehensweisen für einen App-Store/-Market. Der Google Weg ist der offene. Applikationen werden kaum geprüft. Das hat zur Folge das Schadsoftware ziemlich einfach im Android Market angeboten werden kann. Genau wie auch Software die geistiges Eigentum stiehlt in dem es eine 1:1 Kopie ist, doch das ist eine andere Geschichte. Wie Google in diesem Beispiel zeigte, reagieren sie sehr schnell auf Meldungen der Community der die Prüfung eigentlich delegiert wird. Genau wie Wikipedia soll die Community schlussendlich zum guten Ergebnis führen. Apple geht den anderen Weg. Applikationen werden einem, oft kritisierten Prüfprozess unterzogen in dem diverse Punkte geprüft werden. Einer dieser Punkte ist auffälliges Verhalten das Schadsoftware auszeichnet. Mir persönlich ist kein Beispiel bekannt wo eine Applikation sich bösartig verhielt die nicht über einen Jailbreak installiert werden musste. Schwachstellen im Betriebssystem wie die PDF-Schwäche von iOS vor 4.x gibt und wird es immer und bei allen Anbietern geben. Wie damit umgegangen wird ist entscheidend. Schlussendlich muss der Anwender für sich entscheiden mit wie viel Risiko er leben will. Vom Android Benutzer wird eher erwartet sich mit der App-Landschaft sehr aktiv auseinander zu setzen um früh von Schadsoftware etc. zu erfahren. Bei Apple kann man mit einer gewissen Grundsicherheit im Rücken entspannter an das Thema herangehen, hat aber den Nachteil keine System-”Beschleunigungs”-Tools und Homescreen-Anpassungen vornehmen zu können.

Zartbesaitete sollten nicht nach Smartphone Virus auf Google suchen. Die schiere Anzahl an Weltuntergangsszenarien die vom kleinen Computer in der Jackentasche ausgehen soll ist überwältigend. Solange ich mich mit mobilen Lösungen privat oder beruflich beschäftige hing immer das Damokles-Schwert von Smartphone-Viren über dem Thema. Klar klingt ja auch logisch. Die kleinen Dinger werden immer mächtiger und tragen immer mehr “sensible” Daten auf sich. Es musste also so kommen wie beim Aufstieg des Personal Computers der heute ungepatcht und ungesichert nur wenige Minuten im Internet überlebt. Hersteller von Antiviren-Softwarehersteller waren ganz uneigennützig an der Speerspitze dieser Berichterstattung und boten gleich den Schutz vor der Gefahr an. AV-Software auf Handies habe ich persönlich aber noch nie im grossen Einsatz gesehen. Zu limitiert sind die Ressourcen (CPU, Speicher, BATTERIE) und zu gross die Einschränkungen beim Einsatz von AV-Software.

Und trotzdem. Wer kennt gerade einen grossen Fall von Virenbefall auf Smartphones? Das einzige was man liest sind Einzelfälle wo es gelang eine Schwachstelle für PDF auszunützen oder eine Malware zu installieren die Adressbuchdaten ausliest und weiterleitet. Aber immer ist eine Aktion des Anwenders notwendig. Da liegt auch einer der grundsätzlichen Unterschiede von Smartphones zu PCs der “Frühzeit”. Während bei Windows früher jeder Anwender automatisch mit priviligierten Rechten (Admin) unterwegs war, ist dies bei Smartphone-OS nicht so. Jede Installation bedingt die Eingabe von Userdaten oder Bestätigen von Hinweisen. Ein Virus der sich im Hintergrund installiert ist so schon sehr effektiv bekämpft. Weiter gehen die OS mit verschiedenen Ansätzen.

Apple pflegt mit dem App-Store und dessen Genehmigungsprozess den nicht unumstrittenen “walled garden” in den nur geprüfte und für unkritisch befundene Applikationen gelangen. Android ist da viel offener und lässt sehr viele, teils auch schadhafte Applikationen in seinen Market. Dem User wird aber bei Installation mehr oder weniger kryptisch aufgezeigt welche Zugriffe die Applikation auf Daten hat. Bei Admins-Liebling Blackberry geht man einen ähnlichen Weg. Genau wie Android sind Blackberrys in der Installation nicht auf den Blackberry-Store/-Market/-Marketplace/-whatever limitiert, sondern können auch Applikationen aus Fremdstores oder dem Netz installieren. Blackberry User haben aber sehr feine Möglichkeiten den Applikationen Zugriff zu genehmigen und diesen nachträglich auch anzupassen. Microsoft folgt mit Windows Phone 7 momentan dem Apple Ansatz und limitiert den Zugang zum Marketplace sehr stark.

So ist denn auch dieses Zahlenbeispiel nicht überraschend:

Derzeit allerdings gibt es nur 539 bekannte Viren für alle Mobil-Betriebssysteme, in der PC-Welt werden dagegen Zehntausende neue Mutanten losgelassen – pro Tag. via aiciti.ch

So ist es sicherlich an der Zeit den befürchteten Gefahren den Rücken zuzuwenden und nur noch ab und zu einen kontrollierenden Blick über die Schulter zu werfen, und den effektiven Gefahren der immer leistungsfähigeren und mobileren Geräten die Aufmerksamkeit zu schenken. Die Geräte müssen nämlich vor Verlust geschützt werden. Unternehmen sollten ihre Zugriffe aufs Unternehmensnetzwerk schützen, sicherstellen das Daten verschlüsselt abgelegt werden können, der Anwender sich der Gefahren bewusst ist und sein Gerät im Verlustfall sperren/löschen kann, etc. Diese Denke schleicht sich nun langsam auch bei AV-Softwareherstellern ein und sie bieten mehr Lösungen für Mobile Device Management als klassische Antiviren-Software. Es bleibt zu hoffen das sich der Trend auch bei Security-Abteilungen und -Frameworks abzeichnet