Risikoanalyse des Android Betriebssystems

Aus Winfwiki

Wechseln zu: Navigation, Suche

Hausarbeit

Hochschule: Hochschule für Oekonomie & Management
Standort: Düsseldorf
Studiengang: Bachelor Wirtschaftsinformatik
Veranstaltung: IT-Infrastruktur
Betreuer: Dipl-Inf. (FH) Christian Schäfer
Typ: Hausarbeit
Themengebiet: IT-Infrastruktur
Autor(en): Markus Frielingsdorf
Studienzeitmodell: Abendstudium
Semesterbezeichnung:
Studiensemester: 7
Bearbeitungsstatus: in Arbeit
Prüfungstermin: 31.01.2011
Abgabetermin: 30.01.2011


Inhaltsverzeichnis


1 Abkürzungsverzeichnis

AbkürzungBedeutung
APIApplication Programming Interface
APPApplication
DVMDalvik Virtual Machine
IPInternetprotokoll
ITInformationstechnologie
ITKInformationstechnologie und Telekommunikation
PINPersönliche Identifikationsnummer
SDKSoftware Development Kit
WLANWireless Local Area Network

2 Abbildungsverzeichnis

Abb.-Nr.AbbildungQuelle
1Android Systemarchitekturhttp://developer.android.com/images/system-architecture.jpg
2Risikoportfolio
3Risikoportfolio nach der Risikobewertung

3 Tabellenverzeichnis

Tabelle Nr.Bedeutung
1Zuordnung der Risikofälle zu einem Buchstaben
2Risikomatrix
3Bedeutung der Buchstaben im Risikoportfolio

4 Einleitung

Der Smartphonemarkt wächst immer weiter und gerade das Android-Betriebssystem hat in den letzten Jahren viele Marktanteile dazugewonnen.[1] Dabei ist es nicht nur für Privatanwender ein interessantes Betriebssystem sonder auch für den geschäftlichen Bereich. Doch gerade hier spielt die Sicherheit und das Risiko eine bedeutende Rolle. So ist es für Privatpersonen vielleicht nicht sehr schlimm wenn Smartphone mal defekt geht oder Daten verloren gehen. Für den geschäftlichen betrieb hingegen kann ein Dienstausfall oder der Verlust bzw. Diebstahl von Daten schwerwiegende Folgen haben. Die Folgen reichen von kurzzeitiger Einschränkung in der täglichen Arbeit bis hin zu hohen finanziellen Verlusten.
Welche Risiken es bei dem Einsatz des Android-Betriebssystem gibt, wird auf den folgenden Seiten beschrieben.

5 Abgrenzung / Einschränkung des Themas

In dieser Hausarbeit soll dargestellt werden welche Risiken das Android Betriebssystem speziell im beruflichen Einsatz birgt. Dazu wird eine Risikoanalyse durchgeführt, welche sich auf einen vorher definierten Kontext bezieht. Dabei werden nicht nur Risiken aufgezeigt welche das Android-Betriebssystem bietet, sondern auch Risiken, die von außen auf das Betriebssystem einwirken.

6 Grundlagen

6.1 IT-Sicherheit

6.1.1 Schutzbedarf

Um Schutzmaßnahmen wirksam aufzubauen ist es wichtig möglichst genau zu wissen welche Bestandteile eines IT(Informationstechnologie)-Systems besonders wertvoll sind und welche Bedrohungen existieren beziehungsweise denkbar erscheinen. Fast unmöglich bzw. nur mit sehr hohem Aufwand verbunden ist es komplexe IT-Systeme unpriorisiert zu betrachten. Wenn hingegen bekannt ist welche Teile des Systems eine genauere Betrachtung bedürfen, lassen sich die Anstrengungen zur Sicherung des IT-Systems sehr zielgenau ausrichten und verhältnismäßig schnell und wirksam abschließen. Das Ergebnis dieser Betrachtung wird als Schutzbedarf bezeichnet.[2]
Um den individuellen Schutzbedarf zu ermitteln, werden zuerst Anforderungen an das IT-System und alle seine Bestandteile definiert. Zu den Anforderungen gehören z.B. Verfügbarkeit oder Performance. Die Anforderungen werden in einem Anforderungskatalog gesammelt und bilden die Grundlage zur Bewertung und Gewichtung der Konsequenzen eventueller Verletzungen. Anschließend werden Konsequenzen aus der Verletzung der definierten Anforderungen dargestellt und abschließend nach ihrer Relevanz und Schwere bewertet und gewichtet. Aus dieser Bewertung und Gewichtung erfolgt dann die Festlegung des jeweils tatsächlichen Schutzbedarfs.[3]

6.1.2 Schutzziele

Schutzziele werden auf Basis der Ergebnisse der Schutzbedarfsermittlung abgeleitet. Die Schutzziele beschreiben die Eigenschaften oder Attribute von Systemen, Komponenten, Applikationen usw. deren Einhaltung durch geeignete Schutzmaßnahmen gewährleistet werden soll. Je konkreter und spezifischer die Schutzziele definiert werden, desto einfacher ist es die passende technische Implementierung dafür zu finden oder selbst zu errichten.[4]
Schutzziele lassen sich in unterschiedliche Kategorien einordnen. Dazu gehören Integrität, Verfügbarkeit, Vertraulichkeit, Authentizität und Verbindlichkeit.[5]
Bei der Zielsetzung der Integrität von Systemen oder Informationen wird deren Unveränderlichkeit beschrieben. Systeme oder Informationen erfüllen dieses Schutzziel, wenn sie zuverlässig nicht verändert wurden oder deren Änderungen erkennbar und nachvollziehbar durchgeführt wurden. Die Herstellung und Beibehaltung erfordert geeignete Maßnahmen zur Verhinderung unerkannter Veränderungen. Die Integrität ist eine absolute Zielsetzung, da Abstufungen nicht möglich sind.[6]
Die Verfügbarkeit bezieht sich auf den Zugang und den Zugriff auf Ressourcen, Systeme und Informationen. Ein System oder eine Information gilt dann als Verfügbar, wenn sie erreicht, eingesehen und verändert werden kann. Um eine Verfügbarkeit zu erreichen, werden Maßnahen benötigt, die Ereignisse vermeiden, die in Konsequenz zu Beeinträchtigungen oder gar Unterbrechungen der Verfügbarkeit führen. Die Verfügbarkeit ist eine relative Zielsetzung, da sie anteilig oder absolut bemessen werden kann.[7]
Das Schutzziel Vertraulichkeit von Systemen und Informationen beschreibt deren Exklusivität. Vertraulichkeit ist gegeben, wenn sichergestellt ist, dass Zugang und Zugriff auf Systeme und Daten ausschließlich dem dafür bestimmten Benutzerkreis möglich ist. Auch hier benötigt es zur Herstellung und Beibehaltung Maßnahmen zur Sicherstellung der Exklusivität in Zugang und Zugriff auf Informationen und Systeme. Vertraulichkeit ist ein absolutes Schutzziel, bei dem es keine Abstufungen gibt.[8]

6.1.3 Schutzmaßnahmen

Schutzmaßnahmen bestehen in der IT im Wesentlichen aus den Komponenten Konfiguration, Überwachung, Alarmierung und Reaktion. Dabei basieren Überwachung und Reaktion neben einer korrekten Konfiguration immer auf bekannten Informationen.[9]
Die Konfiguration hat den Zweck, die Grundlage für eine ordnungsgemäße und anforderungskonforme Funktion der jeweiligen Komponenten einzeln und ggf. auch im Verbund sicherzustellen. Ein Leistungsspektrum lässt sich nur ungenau definieren, da es stark von der eingesetzten Technologie abhängig ist. Grundsätzlich sollten Konfigurationen aber von zentraler Stelle aus verteilt beziehungsweise angepasst werden können und die dazu genutzten Mechanismen den Grundbedürfnissen der Schutzziele genügen.[10]
Die Überwachung dient dazu definierte Normalzustände zu kontrollieren und abweichende Zustände zu erkennen und so weit wie möglich zu qualifizieren. Dazu werden im allgemeinen in bestimmten zeitlichen Abständen Informationen der zu überwachenden Systeme und Komponenten abgerufen und die erhaltenen Werte anhand festgelegter Kriterien einer Bewertung unterzogen. Eine wirksame Überwachung bildet den wichtigsten Grundstein für die weitere Behandlung von unerwarteten und unerwünschten Ereignissen.[11]
Um ein Ereignis als Angriff beziehungsweise Verletzung der Sicherheitsrichtlinie einzustufen, reicht eine reine Erkennung und ggf. automatische Qualifizierung nicht aus. Häufig benötigt es einer individuellen Begutachtung von qualifiziertem Fachpersonal. damit dies geschehen kann, muss das Auftreten zu behandelnder Ereignisse bekannt sein . Dies ist Aufgabe der Alarmierung. Dazu werden geeignete Benachrichtigungen an einen oder mehrere Empfängerkreise versandt. Dabei muss der Empfänger nicht zwangsläufig eine natürliche Personen sein. In jedem Fall erfolgt im Anschluss an den Empfang einer entsprechenden Benachrichtigung eine weiter gehende Behandlung durch den Empfänger.[12]
Die Behandlung erkannter und gemeldeter Ereignisse ist Hauptaufgabe der Reaktion. Dazu gehören beispielsweise Maßnahmen zur Verhinderung von unerwünschten Systemzuständen oder zur Schadensbegrenzung beim Erreichen eines kritischen Zustandes. Wichtig dabei ist, dass die Reaktionsmaßnahmen an die Überwachungs- und Alarmierungssysteme angeschlossen werden, da die Reaktion auf Ereignisse nur dann erfolgen kann, wenn vorher der Ereigniseintritt auch bekannt gemacht wurde. Bei der Reaktion muss auf die Angemessenheit der Maßnahme geachtet werden, damit die getroffene Maßnahme nicht schlimmstenfalls das Gegenteil der eigentlich beabsichtigten Wirkung erzielt.[13]

6.2 Bedrohungen

6.2.1 Prinzipielle Bedrohungen

Es gibt eine Vielzahl möglicher Bedrohungen. Dazu zählt z.B. Feuer oder technischer Defekt. Durch Abstraktion und Konzentration auf die Auswirkungen können diese eingeschränkt und überschaubar dargestellt werden. Zur Früherkennung, Vermeidung oder Wiederherstellung müssen die Bedrohungen zwar einzeln begutachtet werden, können aber zu Bedrohungsgruppen zusammengefasst werden, gegen welche gleiche oder weitestgehend gleiche Maßnahmen ergriffen werden können. Die auf unterschiedlichen Auslösern und/oder Bedrohungen basierenden Auswirkungen werden als prinzipielle Bedrohungen bezeichnet.[14]
Dazu gehören:

  • Ausfall oder Einschränkung von Ressourcen
    • (externe) Versorgungseinrichtungen, z.B. Strom, Gas, Wasser, Kommunikation (Ursache z.B. technische Defekte oder Beschädigung bei Bauarbeiten)
    • externe Dienstleister, z.B. Lieferanten, Software-Häuser, Service-Geber (Ursache z.B. Insolvenz oder Ausfall der Haustechnik)
    • Gebäude oder Räumlichkeiten (Ursache z.B. Brand oder Rohrbruch)
    • Gebäude-, Raum-Infrastruktur und Haustechnik (Ursache z.B. Explosion oder Überspannung)
    • ITK(Informationstechnologie und Telekommunikation)-Infrastruktur (Ursache z.B. Fehlbedienung oder Software-Fehler)
    • Personal (Ursache z.B. Lebensmittelvergiftung oder blockierte Anfahrt zur Arbeit)
  • Blockade
    • Kommunikationsanbindung (Ursache z.B. Denial-of-Service-Attacken)
    • Gebäudezutritt (Ursache z.B. Streik oder Demonstration)
  • Beschädigung oder Verlust, z.B. von Einrichtungsgegenständen, Computer-Equipment, Akten, Verträgen, Dokumenten, Dateien, Datenbeständen (Ursache z.B. Einbruch oder Vandalismus)
  • Verfälschung, z.B. von Daten (Ursache z.B. Fehleingabe aufgrund von Tippfehlern oder Software-Fehler)
  • Täuschung durch Vorspiegelung einer falschen Identität (z.B. Vortäuschung einer falschen Benutzeridentität oder Vortäuschung einer falschen IP(Internetprotokoll)-Absenderadresse)
  • unzulässige Informationsgewinnung, z.B. über Betriebsgeheimnisse, geheime Forschungsergebnisse, Kundendaten, Lieferkonditionen (Ursache z.B. Abhören von Übertragungen oder Spionage)
  • unzulässige Nutzung der Unternehmensinfrastruktur, z.B. von ITK-Systemen, Telefon oder Kopierer[15]


Die jeweiligen Bedrohungen können nach Eintrittswahrscheinlichkeit kategorisiert werden und bieten so ein Indiz mit welcher Priorität Schutzmaßnahmen unter Kosten-Nutzen-Erwägungen ergriffen werden sollten. Dabei darf nicht vergessen werden, dass Bedrohungen mit einer sehr geringen Eintrittswahrscheinlichkeit dennoch sehr kurzfristig auftreten können.[16]

6.2.2 Motivation der Angreifer

Bei der Konzeption von Schutzmaßnahmen ist es hilfreich zu wissen warum und mit welchem fachlichen Hintergrund Angriffe geplant und durchgeführt werden. Ein Angreifer, der es gezielt auf bestimmte Daten abgesehen hat, wird wahrscheinlich anders vorgehen als einer, der Schaden an Teilen oder sogar der gesamten IT-Struktur anrichten will. Durch die Kenntnisse über die spezifischen Eigenheiten der unterschiedliche motivierten Angriffe lassen sich zielgerichtete Schutz-, Abwehr- und Reaktionsmaßnahmen konzipieren und umsetzen. Da es sehr schwierig ist detaillierte Gliederungen und Charakteristiken der Angreifertypen zu erstellen, werden zumindest die häufigsten und markantesten Merkmale der unterschiedlichen Motivationen herausgefiltert.
Im Wesentlichen wird zwischen fünf unterschiedlichen Motivationen unterschieden:[17]

  • Habgier: Angriffe werden durchgeführt, um einen persönlichen, materiellen Gewinn daraus zu erzielen
  • Neugier: Angriffe werden durchgeführt, um die persönliche Neugier zu stillen
  • Spionage: Angriffe werden durchgeführt, um gezielt in den Besitz bestimmter Informationen zu kommen
  • Vergeltung: Angriffe werden durchgeführt, um gezielt und zur Befriedigung persönlicher Emotionen Schäden zu erzeugen
  • Konspiration: Angriffe werden durchgeführt, um eventuelle Verfolger auf falsche Fährten zu locken


Für die Konzeption und Entwicklung von vorbeugenden und erkennenden Maßnahmen sind die jeweiligen Eigenschaften der unterschiedlichen Motivationstypen. Um diese Eigenschaften nutzbringend zu verwenden benötigt es keine detaillierten Analysen, es reichen durch Erfahrungen aus dem Alltag gewonnene Erkenntnisse.
Wenn aus Habgier versucht wird eine IT-Struktur anzugreifen, wird vorrangig darauf geachtet werden, dass der Angriff schnell durchgeführt werden kann und möglichst wenig, wenn nicht gar keine Spuren oder Beweise zurückzulassen. Angriffe aus Habgier lassen sich nur im Vorfeld wirksam verhindern. Dazu muss der Angreifer von seinem Zielobjekt ferngehalten werden oder die Dauer bis zum Erreichen des Ziels ist erkennbar lang, sodass eine Entdeckung und unmittelbare Reaktion offensichtlich ist. Dadurch wird ein Angreifer von seinem Vorhaben abgebracht.[18]
Bei der Neugier hat der Angreifer die Vorstellung nichts schlimmes oder verbotenes zu machen sondern nur aus Lust am Wissen zu handeln. Die bei dem Angriff eingesetzten Mittel und Methoden variieren in Abhängigkeit von den individuellen Kenntnissen und dem Ehrgeiz des Angreifers. Die Angriffe erfolgen meist ohne konkrete Zielsetzung und beruhen nicht auf einer Planung und Vorbereitungszeit. So ist es dem Angreifer auch nicht daran gelegen seinen Angriff in einer möglichst kurzen Zeit durchzuführen. Solange er unerkannt und ungestört bleibt, versucht er immer mehr Informationen aus dem System zu entnehmen. Ein weiteres Merkmal ist, dass die angegriffenen Systeme in der Regel nicht bewusst beschädigt oder in ihrer Funktionsweise beeinträchtigt werden. Durch den Einsatz bestimmter Werkzeuge des Angreifers kann dies aber vorkommen. Ähnlich verhält es sich mit den Informationen, auf die zugegriffen wird. Normalerweise erfolgt der Zugriff nur lesend, wobei es aber auch hierbei zu Beschädigungen kommen kann. Angreifer aus Neugier lassen sich also vorher als auch während des Angriffes davon abhalten bzw. unterbrechen. Wichtig ist hierbei eine gut funktionierende Erkennung und Benachrichtigung, da ansonsten solche Angriffe auf lange Zeit unerkannt bleiben.[19]
Bei der Spionage wird versucht Informationen für einen Auftraggeber zu sammeln, auszuwerten und gegebenenfalls zu manipulieren. Das Ziel ist meistens bestimmte Informationen zu beschaffen oder zu manipulieren. Dabei ist es dem Angreifer wichtig zu jeder Zeit unerkannt zu bleiben. Je nach eingesetzten Mitteln und Methoden verändert sich die Dauer und Auffälligkeit des Angriffes und beeinflussen den Erfolg oder Misserfolg des Angriffes. Bei solchen Angriffen spielt die Zeit eine untergeordnete Rolle. Vielmehr wird auf eine sorgfältige Planung wert gelegt. Die Angreifer verfügen meist über eine gute Ausstattung von Ressourcen jeder Art. Spionageangriffe erfolgen mit Vorbereitungszeit über einen sehr langen Zeitraum, wobei die eigentliche Attacke sehr gut vorbereitet und von weit reichenden Kenntnissen über das Opfer gestützt wird. Für die Entdeckung solcher Angriffe können sämtliche technischen und organisatorischen Maßnahmen wirksam werden. Insbesondere die Auswertung von Logs oder Mitschnitten über einen längeren Zeitraum hinweg können bei der Entdeckung solcher Angriffe hilfreich sein.[20]
Angriffe aus Vergeltung/Sabotage verursachen wahrscheinlich den gravierensten Schaden. Sie dienen der Befriedigung des Angreifers und haben das Ziel möglichst großen Schaden anzurichten. Oftmals geschehen diese Angriffe in Reaktion auf vorhergehende Aktionen des Opfers, durch die sich der Angreifer so betroffen fühlt, dass er darauf nur noch mit der Beschädigung oder Zerstörung von Eigentum des Opfers reagieren kann. Primär geht es dem Angreifer darum willkürlich Schaden zu verursachen. Was davor oder danach passiert ist eigentlich egal. Da es dem Angreifer darum geht möglichst großen Schaden zu verursachen, egal wie und egal wo, lässt er weder bei der Vorbereitung, noch bei der Durchführung größere Sorgfalt oder Vorsicht walten. Diese Art von Angriffen ist leicht zu erkennen. Allein die erzeugten Schäden sind meist nicht zu übersehen. Beim Schutz und der Abwehr von solchen Angriffen kommt es also hauptsächlich auf eine effektive und zeitnahe Erkennung und Benachrichtigung an. Nur so kann der Angreifer abgewehrt und weitere Schäden vermieden werden.[21]
Meist versuchen Angreifer Hinweise auf ihre Identität zu unterdrücken oder sie zu verschleiern. Dazu werden unter anderem Rechner genommen, welche durch einen vorherigen Angriff nicht mehr unter der vollen Kontrolle des Besitzers stehen. Der Angreifer meldet sich zunächst auf ihnen an und führt anschließend von dort seinen Angriff aus. Möglich sind auch Kaskaden solcher Rechner. Da nach einem erfolgten Angriff der benutzte Rechner durch Fahndungsmaßnahmen erkannt wird, ist der Rechner für den Angreifer nicht länger nutzbar. Daraus resultiert ein ständiger Bedarf an neuen Mitteln für den Angreifer. Auf der Suche nach konspirativ zu nutzenden Systemen oder Komponenten wird der Angreifer äußerste Vorsicht walten lassen, da er nicht vorzeitig erkannt werden will. Effektive Maßnahmen gegen solche Art von Angriffen fällt meist auf Grund der durch den Angreifer an den Tag gelegten Sorgfalt schwer. Hier helfen im Wesentlichen nur ähnliche Maßnahmen, wie sie beim Schutz vor Spionageangriffen eingesetzt werden: Logfile-Analyse über einen größeren Zeitraum und eine effektive Benachrichtigung. In diesem Zusammenhang fällt es besonders schwer zwischen unschuldig und böswilligen Aktionen zu unterscheiden.[22]

6.3 Android

Android ist ein Software-Stack für mobile Geräte, welcher ein Betriebssystem, Middleware und wichtigen Anwendungen enthält. Das Android SDK (Software Development Kit) bietet Tools und APIs (Application Programming Interface) die erforderlich sind, um mit der Entwicklung von Anwendungen auf der Android-Plattform mit Hilfe der Programmiersprache Java zu beginnen. [23]

6.3.1 Architektur

Android Systemarchitektur

Abbildung 1: Android Systemarchitektur

Die Abbildung 1 zeigt die Android Systemarchitektur. Die Basis bildet dabei der Linux Kernel, welcher die erforderlichen Hardwaretreiber zur Verfügung stellt und somit die die Grundlage für das Betriebssystem bildet.[24] Der Kernel dient außerdem als Abstraktionsebene zwischen der Hardware und dem Rest des Software-Stacks.[25]

Die DVM (Dalvik Virtual Machine) ist Bestandteil der Android Runtime. Jede Android-Anwendung wird in einem eigenen Prozess ausgeführt mit einer eigenen Instanz der DVM. Dies verbraucht zwar mehr Ressourcen, bietet aber mehr Sicherheit und eine erhöhte Verfügbarkeit, da sich die Anwendungen keinen gemeinsamen Speicher teilen und ein abgestürzter Prozess nur Auswirkung auf eine Anwendung hat.[26] Android enthält eine Reihe von Kern-Bibliotheken, die die meisten Funktionen in den Kern-Bibliotheken der Programmiersprache Java zur Verfügung stellt.[27]

Android enthält eine Reihe von C/C++-Bibliotheken, die von verschiedenen Komponenten des Android-System verwendet werden. Die Bibliotheken stellen alle zum Betrieb von Android-Anwendungen erforderlichen Funktionalitäten bereit. Dazu gehören unter anderen Datenbanken, Webzugriff oder Oberflächengestaltung.[28]

Android stellt verschiedene Programmierschnittstellen im Application Framework bereit, die eine Kommunikation zwischen einzelnen Anwendungen sowie zwischen Endanwender und Anwendung realisieren.[29] Die Entwickler haben vollen Zugriff auf das gleiche Framework-API, welches von der Kern-Anwendungen verwendet wird. Die Applikations-Architektur wurde entwickelt, um die Wiederverwendung von Bauteilen zu vereinfachen. Jede Anwendung kann seine Funktionen veröffentlichen und jede andere Anwendung kann diese dann nach erfolgreicher Sicherheitsüberprüfung nutzen.[30]

Auf der Ebene Applications befinden sich die Android-Anwendungen. Dabei kann es sich um Eigenentwicklungen oder die von Google mitgelieferten Standardanwendungen handeln. Hier findet die Kommunikation zwischen Mensch und Maschine sowie die Interaktion zwischen Anwendungen statt. Jede Anwendung bedient sich dabei der darunterliegenden Programmierschnittstelle.[31]

6.3.2 Sicherheit

6.3.2.1 Sandbox

Programme ohne spezielle Berechtigungen werden in einer Sandbox ausgeführt. Dabei handelt es sich um einen eingeschränkten Bereich des Gesamtsystems in dem das Java-Programm laufen darf. Den Zugriff auf Ressourcen und Bestandteile des Betriebssystem wird dabei von der Sandbox selbst geregelt. Zu den Ressourcen gehören unter anderem der Arbeitsspeicher, andere Anwendungen oder Telefonfunktionen. Damit ein Programm die Sandbox verlassen kann, benötigt es explizite Berechtigungen, welche innerhalb der Anwendung vergeben werden. Ohne diese Berechtigungen kann das Programm die Sandbox auch nicht verlassen und somit auch keine sicherheitsrelevanten Aktionen durchführen.[32]

6.3.2.2 Signieren von Anwendungen

Das Android-System verlangt, dass alle installierten Anwendungen digital mit einem Zertifikat signiert werden. Das Zertifikat wird als Mittel verwendet um den Urheber der Anwendung zu identifizieren und zur Herstellung von Vertrauensbeziehungen zwischen den Anwendungen. Das Zertifikat wird nicht verwendet, um festzulegen welche Anwendungen der Benutzer installieren darf. Das Zertifikat muss nicht von einer Zertifizierungsstelle signiert werden. Es ist vollkommen zulässig für Android-Anwendungen selbst signierte Zertifikate zu verwenden.[33]

6.3.2.3 Berechtigungen

Über Berechtigungen erlangen Anwendungen Zugriff auf Systemfunktionen und Ressourcen außerhalb der Sandbox. So ist es einer Anwendung zum Beispiel nicht möglich ohne explizite Berechtigungen eine SMS zu versenden oder eine Internetverbindung aufzubauen. Jede Berechtigung muss vom Android-Entwickler in einem Manifest aufgelistet werden damit die Berechtigungen zum Zeitpunkt der Installation sichtbar sind und der Nutzer entscheiden kann ob er das Programm mit den aufgeführten Berechtigungen installieren möchte.[34]

6.4 Risikomanagement

6.4.1 Kontextdefinition

Zu Beginn des Risikomanagement-Prozesses wird der Bereich, das System und die Objekte festgelegt, über die das Risikomanagement durchgeführt wird. Dazu gehört die Abgrenzung, unter anderem Nennung von Gegenständen, die nicht zum Betrachtungs-Gebiet gehören oder auch wichtige Einschränkungen und Rahmenbedingungen werden festgelegt. Außerdem wird festgelegt, wessen Risiken zur Behandlung anstehen. Wichtig ist auch die Beschreibung wesentlicher Aspekte der externen und internen Umgebung des betrachteten Gegenstandes.[35]

6.4.2 Risikoanalyse

Die Risikoanalyse unterteilt sich in zwei hauptsächliche Aktivitäten, der Risikoidentifikation und der Risikoeinschätzung.
Bei der Risikoidentifikation werden alle Gefahrenquellen und Risikoobjekte im betrachteten Gebiet erfasst und die Bedrohungen ausfindig gemacht.[36] Dazu wird zunächst die die für den Analyse-Zweck und -Gegenstand zu betrachtenden Risikoarten definiert werden. Anschließend werden pro Risikoart die auf die einzelnen Objekte einwirkenden Bedrohungen identifiziert und den Objekte zugeordnet.[37]
Nach der Identifizierung der Risiken erfolgt die Risikoeinschätzung mit der Wahrscheinlichkeit und Konsequenz ihres möglichen Eintretens, welche die Ergebnisse aus der Risikoidentifikation bilden.[38] Die Risikoeinschätzung erfolgt in drei Schritten. Zunächst wird die Häufigkeit des Eintritts eines Schaden analysiert. Im zweiten Schritt werden die voraussichtlichen Schäden identifiziert und im dritten Schritt werden die Risiken anhand der ermittelten Häufigkeitswerte und Schadenswerte bestimmt.[39]
Für die Risikoeinschätzung können verschieden Hilfsmittel herangezogen werden. Eines davon ist die Risikomatrix. Mit ihr werden die identifizierten Risiken mit den Häufigkeitswerten und den Schadenswerten in einer Matrixdarstellung festgehalten. Die Matrix kann dann dazu benutzt werden um die Risiken im Unternehmen einzuschätzen.[40]
Ein weiteres Hilfsmittel ist das Risikoportfolio. In diesem werden die Risiken in einer zweidimensionalen grafischen Darstellung übersichtlich aufgelistet. Die Darstellung eignet sich um über die Risiken nach strategischen Gesichtspunkten eine Übersicht zu bekommen und sie nach Wahrscheinlichkeit und Tragweite kommunizieren zu können. Zusätzlich kann die Risikoakzeptanzlinie dargestellt werden, oberhalb derer keine Risiken akzeptiert werden dürfen.[41]

6.4.3 Risikobewertung

Die in der Risiko-Analyse gefundenen Risiken bedürfen einer Interpretation und Bewertung mit ihren Werten für Wahrscheinlichkeit, Schadensausmaß und Risiko. Die dafür benötigten Kriterien können zum einen dem Kontext entnommen werden, zum anderen müssen sie aufgrund der Erkenntnisse aus der Risiko-Analyse neu definiert werden. So muss zum Beispiel geklärt werden ob die Häufigkeit, das Schadenspotential oder beides reduziert werden kann.[42]

7 Risikomanagement

7.1 Kontextdefinition

Ein Beratungsunternehmen mit 100 Mitarbeitern wird für seine Berater Smartphones mit dem Android Betriebssystem anschaffen, mit dessen Hilfe die Berater vor Ort bei den Kunden auf Firmeninterne Daten zugreifen können. Für den Zugriff auf das eigene Unternehmen wird eine selbstgeschriebene Software eingesetzt, mit der sich jeder Berater mit einer eigenen Benutzerauthentifizierung am internen Netzwerk anmelden kann. Neben den Zugriff auf Daten haben die Berater zusätzlich die Möglichkeit Kundenbezogene Daten oder auch beim Kunden entwickelte Dokumente über das Smartphone zu pflegen. Die eingegebenen Daten werden über das Internet im eigenen Unternehmen gespeichert. Neben der beruflichen Nutzung des Smartphones, wird es von den Beratern auch für private Zwecke eingesetzt.
Für die Risikoanalyse wird das Android-Betriebssystem auf Schwachstellen und mögliche Bedrohungen begutachtet, als auch das dazugehörige Smartphone. Auch Einflüsse, die von außen auf das Smartphone und das Betriebssystem Einfluss nehmen werden berücksichtigt.

7.2 Risikoanalyse

7.2.1 Risikoidentifikation

Zunächst werden alle möglichen Risiken identifiziert. Dazu werden sie in den Schutzzielen Integrität, Verfügbarkeit und Vertraulichkeit zusammengefasst.

  • Verlust Integrität
    • Manipulieren von Informationen durch Dritte. Zum Beispiel durch andere Anwendungen, die auf dem Gerät installiert wurden, welche Berechtigungen haben um auf bestehende Datenbestände zuzugreifen und die zu verändern. Ein anderes Beispiel ist die Manipulation von Daten durch unbefugte Nutzer des Smartphones wenn das Gerät unbeaufsichtigt abgelegt wurde oder gestohlen wurde.
    • Fehleingabe des Benutzers. Hier kann es passieren, dass durch Fehler des Anwenders aus Versehen Daten gelöscht werden oder fehlerhafte Informationen eingegeben werden. Ursache dafür kann das Mitführen des Smartphones bei ausgeschalteter Tastensperre sein.
    • Fehlfunktion der Software. Durch fehlerhafte Software können Daten ungewollt gelöscht oder verändert werden.


  • Verlust Verfügbarkeit
    • Defekt der Hardware, sodass sich das Smartphone nicht mehr einschalten lässt zum Beispiel durch Sturz- oder Feuerschäden. Eine weitere Möglichkeit ist ein Defekt der Speicherkarten, welche wichtige Informationen enthält und sich nicht mehr lesen lässt oder das Display ist defekt und deswegen besteht keine Verfügbarkeit.
    • Defekt der Software durch zum Beispiel schädliche Programme, welche auf dem Gerät installiert wurden. Dabei kann es sich um Software handeln, die absichtlich auf dem Gerät installiert wurde oder um Schadsoftware, die unbeabsichtigt auf das Gerät gespielt wurde. So können zum Beispiel Viren dazu führen, dass Programm eder Teile der Software nicht mehr zur Verfügung stehen. Oder ein installiertes Programm schränkt als Nebeneffekt die Verfügbarkeit des Systems ein.
    • Technische Problem wenn zum Beispiel der Akku des Gerätes leer ist und keine Möglichkeit besteht das Gerät aufzuladen oder kein Ladegerät zur Verfügung steht.
    • Einschränkungen bei der Netzverfügbarkeit durch Fehler beim Netzanbieter oder beim Arbeiten in Gegenden, in denen eine sehr schwache oder gar keine Netzabdeckung verfügbar ist.
    • Einschränkung der Verfügbarkeit von firmeninternen Servern, die für die Verbindung auf benötigte Daten wichtig sind. Zum Beispiel durch bösartige und absichtliche Angriffe wie Denial of Service Attacken.
    • Nach Aktualisierung der Android-Version funktioniert das Programm nicht mehr um auf das Firmennetzwerk zuzugreifen.


  • Verlust Vertraulichkeit
    • Abhören von Informationen zum Beispiel beim surfen im Internet über öffentliche und ungesicherte WLAN (Wireless Local Area Network) Netze.
    • Maskerade einer Benutzer- oder Systemidentität. Zum Beispiel durch das Abfangen oder Erspähen von Zugangsdaten mit welchen sich ein unbefugter Benutzer am System anmeldet und so Zugriff auf vertrauliche Daten bekommt. Oder durch das unbefugte Anmelden am Smartphone mit dem PIN (Persönliche Identifikationsnummer) des Besitzers.


7.2.2 Risikoeinschätzung

Für die Risikoeinschätzung werden die identifizierten Risiken zusammengefasst. Dadurch werden die Risiken übersichtlicher dargestellt und können besser eingeschätzt werden.
Die Risikoeinschätzung erfolgt in drei Schritten. Nach der näheren Erläuterung des Risikos erfolgt im ersten Schritt eine Einschätzung über die Häufigkeit des Eintritts eines Schaden. Im zweiten Schritt wie der voraussichtliche Schaden abgeschätzt und im letzten Schritt erfolgt die Bestimmung der Risiken eines Objekts mit Hilfe einer Risiko-Matrix und eines Risiko-Portfolios.
Für die Bewertung der Häufigkeit des Eintritts eines Schaden sind folgende Kategorien festgelegt:

  • unwahrscheinlich (1 mal in mehr als 30 Jahren)
  • sehr selten (1 mal in 30 Jahren)
  • selten (1 mal in 10 Jahren)
  • oft (1 mal im Jahr)
  • sehr oft (10 mal pro Jahr)

Für die Bewertung der Schadenshöhe sind folgende Kriterien festgelegt:

  • klein - bis 10 T. €
  • mittel - 10-500 T. €
  • groß - 0,5-3 Mio. €
  • sehr groß - 3-10 Mio. €
  • katastrophal - über 10 Mio. €


Schaden durch heruntergeladene APP
Bei der Entwicklung einer APP muss der Entwickler für alle Funktionen seiner Anwendung, die außerhalb der Sandbox laufen sollen, die nötigen Berechtigungen in ein Manifest eintragen. Nachdem der Anwender die APP heruntergeladen hat, bekommt er vor der Installation die benötigten Berechtigungen des Programms angezeigt und nur wenn er diese bestätigt, wird die Anwendung installiert. Der Anwender bekommt so eine Übersicht auf welche Teile des Systems das Programm zugreift und kann selber entscheiden ob er das Programm installieren möchte oder nicht. Wenn ein APP heruntergeladen und installiert wurde, welches auf die die lokalen Daten des Smartphones und das Internet zugreifen darf, können Daten ausspioniert werden und über Internet versendet werden.
Ca. 12% der Programme im Android Market greifen auf persönliche Daten wie SMS, Kalender-, Kontakt- und Benutzerdaten zu.[43] Davon sind aber nicht alle Programme bösartig und die Anzahl der Programme, die von den Beratern heruntergeladen wird variiert. Zusätzlich bekommt der Anwender vor der Installation noch eine Übersicht über die verlangten Berechtigungen, sodass davon ausgegangen wird, dass ein schädliches Programm selten, also 1 mal in 10 Jahren heruntergeladen und installiert wird.
Wenn das Programm Kontaktdaten von Kunden ermittelt, weitersendet und anschließend verkauft und/oder veröffentlicht werden entsteht zum einen ein Imageschaden für das Unternehmen und zum anderen besteht die Gefahr, dass sich Kunden ein anderes Beraterunternehmen suchen. Deswegen wird hier von einem großen Schaden ausgegangen.

Aktualisierung der Android-Version
In regelmäßigen Abständen wird eine neue Version des Android-Betriebssystem verbreitet. Dabei kann es vorkommen, dass installierte Programme nicht mehr kompatibel zur aktuellen Version sind und sich so nicht mehr ausführen lassen.
Im Februar 2009 wurde die erste Version verbreitet.[44] Die aktuelle Version ist die siebte, welche im Dezember 2010 erschienen ist.[45] Es werden also pro Jahr drei bis vier neue Versionen verbreitet. Dazu kommt, dass nicht jede neue Version Auswirkungen auf die Software des Beratungsunternehmen hat und die neuen Versionen vor dem Erscheinen angekündigt und getestet werden können. Deswegen wird davon ausgegangen, dass eine Beeinträchtigung des Programms durch eine neue Betriebssystemversion sehr selten, also 1 mal in 30 Jahren stattfindet.
Wenn sich das Programm durch eine neue Version nicht mehr starten lässt, behindert dies die Berater stark bei der Ausführung ihrer Arbeit, da sie nicht mehr auf wichtige Daten zugreifen können. Dem Kunden gegenüber entsteht ein Imageschaden, welche im schlimmsten Fall ein anderes Beratungsunternehmen suchen werden. Aus diesen Gründen wird von einem sehr großen Schadenspotential ausgegangen.

Schaden durch einen Exploit
Durch einen Exploit können Angreifer eigenen Programmcode auf dem Zielgerät ausführen oder nicht gewünschte Funktionen ausführen.[46] Dabei kann es schon reichen wenn der Anwender eine manipulierte Website ansurft.
Nach einer Studie des Sicherheitsanalysten Coverity gab es im November 2010 88 kritische Sicherheitslücken im Android Betriebssystem.[47] Die Wahrscheinlichkeit, dass einer der Berater durch eine dieser Lücken Opfer eines Angriffes wird ist bei häufiger Benutzung des Smartphones oft, also 1 mal im Jahr.
Angreifer könne zum einen wichtige Daten abgreifen und diese zum Beispiel veröffentlichen oder auch Daten Manipulieren welche zu fehlerhaften Informationen führen. Es kann ein Imageschaden entstehen und auch Kunden abspringen und sich ein andere Beraterunternehmen suchen. Zusätzlich kann Zeit- und Arbeitsaufwand entstehen um beschädigte oder gelöschte Daten erneut zu erfassen oder aus einer Sicherung zurückzuspielen. Das Schadenspotential wird sehr groß eingestuft.

Risiko beim surfen über ungesichertes WLAN
Da die Berater zu Kunden reisen und somit viel Zeit an Bahnhöfen und Flughäfen verbringen, besteht gerade dort die Möglichkeit über öffentliche und ungesicherte WLAN-Netze zu surfen. Hinzu kommt, dass die Smartphones auch im privaten Bereich eingesetzt werden und auch dort über ungesicherte oder nur sehr schlecht gesicherte WLAN-Netze gesurft werden kann.
Die Wahrscheinlichkeit, dass die Berater über ein ungesichertes Netz ins Internet einwählen und dort Opfer von Datenklau werden wird als oft, also 1 mal im Jahr eingestuft.
Dabei können zum Beispiel Benutzerdaten und Passwörter geklaut werden, mit denen sich die Berater am Firmennetzwerk anmelden. Um sich dort aber anzumelden wird auch die Software benötigt. Auch die Zeit, die sich ein Berater in ungeschützten Netzen aufhält ist begrenzt und somit auch die mögliche Menge an Daten, die geklaut werden können. Aus diesen Gründen wird das Schadenspotential als klein eingestuft.

Defekt des Smartphone
Es gibt viele Gründe, aus denen ein Smartphone kaputt gehen kann. Zum Beispiel durch einen Sturz oder stark verkratzte Displays. Auch Wasserschäden sind denkbar. Die Smartphones der Berater werden alle 2 Jahre durch ein neues Modell ausgetauscht.
Die Wahrscheinlichkeit dass ein Gerät defekten geht liegt bei mehreren Beratern und häufiger Nutzung sehr hoch, also 10 mal pro Jahr.
Da die Geräte im Unternehmen vorrätig sind, kann ein Austausch des defekten Gerätes bereits am nächsten tag erfolgen. Deswegen wird das Schadenspotential als klein eingestuft.

Diebstahl des Smartphones
Zum einen kann es passieren, dass das Smartphone gezielt gestohlen wird oder durch zum Beispiel den Diebstahl eines Koffers das Smartphone mit gestohlen wird.
Da Diebstähle an öffentlichen Plätzen und Einrichtungen mit vielen Menschen wahrscheinlicher ist und die Berater sich regelmäßig an Flughäfen, Bahnhöfen oder auch auf Messen aufhalten, wird die Wahrscheinlichkeit eines Diebstahles auf oft, also 1 mal im Jahr eingestuft.
Ausgeschaltete Smartphones sind durch einen PIN geschützt und erschweren es dem Dieb den Zugriff auf die Daten zu erlangen. Da Smartphones aber die meiste Zeit über eingeschaltet sind, hat der Dieb vollen Zugriff auf die Daten des Smartphones. Deswegen wird das Schadenspotential als mittel eingestuft.

Verfügbarkeit Firmennetzwerk
Mit dem Firmennetzwerk verbinden sich die Berater um auf wichtige Daten zugreifen zu können. Das Firmennetzwerk soll 22 Stunden am Tag erreichbar sein und in der Nacht für 2 Stunden zur Sicherung ausgeschaltet sein. Durch diverse Fehler kann es aber dazu führen, dass das Netzwerk außerplanmäßig nicht erreichbar ist.
Der Zugriff auf das firmeninterne Netzwerk wird durch mehrere Server gesichert, die redundant laufen. Selbst wenn ein Server nicht mehr erreichbar sein sollte, funktioniert der Zugriff über einen anderen Server weiterhin. Deswegen wird die Wahrscheinlichkeit mit selten, also 1 mal in 10 Jahren bewertet.
Bei einem Ausfall der Server wird die Wiederherstellung der Verfügbarkeit innerhalb von 24 Stunden geleistet durch das Aufspielen der letzten Sicherung auf alternative Hardware. Da es sich um einen Ausfall der Verfügbarkeit um maximal 24 Stunden handelt, wird das Schadenspotential als mittel eingestuft.

Netzverfügbarkeit
Zum größten Teil werden die Berater bei den Kunden über das Handynetz ins Internet gehen. Daher ist es wichtig eine hohe Netzabdeckung innerhalb von Deutschland zu haben.
Die Kunden haben ihre Büros alle in großen deutschen Städten, welche über eine sehr gute Netzabdeckung verfügen. Deswegen wird die Wahrscheinlichkeit auf unwahrscheinlich, also 1 mal in mehr als 30 Jahre eingestuft.
Falls kein Handynetz zur Verfügung steht, hat der Berater noch die Möglichkeit über das Netzwerk des Kunden sich ins Internet einzuwählen. Das Schadenspotential ist klein.

7.2.2.1 Risikomatrix

Die Häufigkeitswerte und die Schadenswerte werden im folgenden in eine Risikomatrix übertragen. Dafür werden zunächst die einzelnen Risikofälle durchnummeriert:

Tabelle 1: Zuordnung der Risikofälle zu einer Zahl
Zahl Risikofall
1 Schaden durch heruntergeladene APP
2 Aktualisierung der Android-Version
3 Schaden durch einen Exploit
4 Risiko beim surfen über ungesichertes WLAN
5 Defekt des Smartphone
6 Diebstahl des Smartphones
7 Verfügbarkeit Firmennetzwerk
8 Netzverfügbarkeit


In der Risikomatrix werden alle Risikofälle übersichtlich dargestellt und für jeden Fall die Schadenshöhe und die Häufigkeit aufgelistet.

Tabelle 2: Risikomatrix
Schadenshöhe pro Fall 1
groß 		2
sehr groß 		3
sehr groß 		4
klein 		5
klein 		6
mittel 		7
mittel 		8
klein
Häufigkeit der Fälle
sehr oft (10 mal pro Jahr) klein klein mittel mittel sehr groß mittel klein sehr klein
oft (1 mal im Jahr) mittel klein groß groß groß groß mittel sehr klein
selten (1 mal in 10 Jahren) groß mittel mittel mittel mittel mittel groß sehr klein
sehr selten (1 mal in 30 Jahren) mittel groß klein klein klein klein mittel klein
unwahrscheinlich (1 mal in mehr als

30 Jahren)

klein mittel sehr klein sehr klein sehr klein sehr klein klein mittel

7.2.2.2 Risikoportfolio

Um die Risiken übersichtlich darzustellen und um eine strategische Entscheidungshilfe zu bekommen welche Risiken minimiert werden sollten, werden die Risikofälle in einem Risikoportfolio dargestellt.
Innerhalb des Risikoportfolios gibt es eine Akzeptanzlinie. Alle Risikofälle, die sich rechts bzw. oberhalb dieser Linie befinden werden vorrangig behandelt.
Die Buchstaben A - F haben dabei folgende Bedeutung:

Tabelle 3: Bedeutung der Buchstaben im Risikoportfolio
Buchstabe Bedeutung
A Bagatell-Risiko
B Klein-Risiko
C Mittleres-Risiko
D Groß-Risiko
E Überlebens-Risiko
F Katastrophen-Risiko


Android Risikoportfolio
Abbildung 2: Risikoportfolio

Wie die Abbildung 2 zeigt, liegen bis auf Fall 3 (Schaden durch einen Exploit) alle Risiken links und unterhalb der Akzeptanzlinie. Im nächsten Schritt, der Risikobewertung, muss geprüft werden mit welchen Maßnahmen das Risiko abgeschwächt werden kann.

7.3 Risikobewertung

Um den Fall 3 (Schaden durch einen Exploit) auf die andere Seite der Akzeptanzlinie zu bekommen, wird versucht die Häufigkeit des Risikos zu beeinflussen, das Schadensausmaß zu minimieren oder eine Mischung aus beiden.
Zum einen wird die Anzahl der kritische Sicherheitslücken im Android Betriebssystem zurückgehen, da das System ständig weiterentwickelt wird und dabei auch Sicherheitslücken geschlossen werden. Dadurch verringert sich die Wahrscheinlichkeit des Eintretens des Risikos auf selten, also 1 mal in 10 Jahren.
Zum anderen können zusätzliche Sicherheitsmaßnahmen innerhalb des Programms getroffen werden, was das Schadenspotential senkt. So kann zum Beispiel das Speichern der Anmeldedaten rausgenommen werden. Das hat zur Folge, dass sich die Berater mit jeder Verbindung erneut anmelden müssen aber auch dass Angreifer nicht so einfach auf das Firmennetzwerk zugreifen können. Des weiteren können wichtige Daten verschlüsselt auf dem Smartphone abgelegt werden, was es einem Angreifer schwieriger macht an diese Informationen zu gelangen. Auch das regelmäßige Austauschen des Passwortes senkt die Gefahr eines erfolgreichen Angriffes. So kann das Schadenspotential von sehr groß auf groß reduzieren lassen.
Dadurch verändert sich das Risikoportfolio wie folgt:
Android Risikoportfolio nach der Risikobewertung
Abbildung 3: Risikoportfolio nach der Risikobewertung

Wie in Abbildung 3 zu sehen ist, liegen jetzt alle Risiken unterhalb der Akzeptanzlinie. Wenn jetzt eines der Risiken eintritt, kann entweder damit umgegangen werden oder der angerichtete Schaden ist so gering, dass er ignoriert werden kann. Weiterführend könnten jetzt noch die anderen Risiken begutachtet werden und auch für diese Maßnahmen ergriffen werden, welche die Eintrittswahrscheinlichkeit oder das Schadenspotential senken. Hier ist aber zu beachten ob sich der Aufwand für die Firma lohnen würde.

8 Fazit

Für den Einsatz von Smartphones mit dem Android-Betriebssystem im geschäftlichen Bereich gibt es viele Risiken, die auf das Unternehmen bzw. das Smartphone einwirken. Manche sind so groß, dass sie nicht akzeptiert werden können. Allerdings können durch entsprechende Maßnahmen alle Risiken so weit minimiert werden, dass ein Einsatz für Unternehmen in Frage kommt. Hinzu kommt, dass das Betriebssystem über die Zeit immer weiterentwickelt wird und so an Sicherheit hinzugewinnt. Dies wirkt sich positiv auf drohende Risiken aus. Um die Geräte in einem Unternehmen einzuführen bedarf es eine genau Analyse für den Aufgabenbereich und welche Risiken dabei entstehen. Ohne entsprechende Maßnahmen ist ein bedenkenloser Einsatz nicht möglich.

9 Fußnoten

  1. ↑ Vgl. Flosi (2010), Weblink: http://www.comscore.com
  2. ↑ Vgl. Eschweiler, Psille (2006), S. 26 f.
  3. ↑ Vgl. Eschweiler, Psille (2006), S. 27 f.
  4. ↑ Vgl. Eschweiler, Psille (2006), S. 28
  5. ↑ Vgl. Eschweiler, Psille (2006), S. 29
  6. ↑ Vgl. Eschweiler, Psille (2006), S. 30
  7. ↑ Vgl. Eschweiler, Psille (2006), S. 30
  8. ↑ Vgl. Eschweiler, Psille (2006), S. 31
  9. ↑ Vgl. Eschweiler, Psille (2006), S. 32 f.
  10. ↑ Vgl. Eschweiler, Psille (2006), S. 33
  11. ↑ Vgl. Eschweiler, Psille (2006), S. 33 f.
  12. ↑ Vgl. Eschweiler, Psille (2006), S. 35 f.
  13. ↑ Vgl. Eschweiler, Psille (2006), S. 39
  14. ↑ Vgl. Müller (2008), S. 132
  15. ↑ Vgl. Müller (2008), S. 132 ff.
  16. ↑ Vgl. Müller (2008), S. 135
  17. ↑ Vgl. Eschweiler, Psille (2006), S. 49 f.
  18. ↑ Vgl. Eschweiler, Psille (2006), S. 50 f.
  19. ↑ Vgl. Eschweiler, Psille (2006), S. 51 f.
  20. ↑ Vgl. Eschweiler, Psille (2006), S. 52 f.
  21. ↑ Vgl. Eschweiler, Psille (2006), S. 53 f.
  22. ↑ Vgl. Eschweiler, Psille (2006), S. 54 f.
  23. ↑ Vgl. o.V. (2011a), Weblink: http://developer.android.com
  24. ↑ Vgl. Becker, Pant (2009), S. 15
  25. ↑ Vgl. o.V. (2011a), Weblink: http://developer.android.com
  26. ↑ Vgl. Becker, Pant (2009), S. 15 f.
  27. ↑ Vgl. o.V. (2011a), Weblink: http://developer.android.com
  28. ↑ Vgl. Becker, Pant (2009), S. 16
  29. ↑ Vgl. Becker, Pant (2009), S. 16
  30. ↑ Vgl. o.V. (2011a), Weblink: http://developer.android.com
  31. ↑ Vgl. Becker, Pant (2009), S. 16
  32. ↑ Vgl. Becker, Pant (2009), S. 23
  33. ↑ Vgl. o.V. (2011b), Weblink: http://developer.android.com
  34. ↑ Vgl. Becker, Pant (2009), S. 24 f.
  35. ↑ Vgl. Königs (2006), S. 29
  36. ↑ Vgl. Königs (2006), S. 30
  37. ↑ Vgl. Königs (2006), S. 33
  38. ↑ Vgl. Königs (2006), S. 30
  39. ↑ Vgl. Königs (2006), S. 33
  40. ↑ Vgl. Königs (2006), S. 14
  41. ↑ Vgl. Königs (2006), S. 17
  42. ↑ Vgl. Königs (2006), S. 41
  43. ↑ Vgl. Vennon, Stroop (2010), Weblink: http://threatcenter.smobilesystems.com
  44. ↑ Vgl. o.V. (2009), Weblink: http://developer.android.com/
  45. ↑ Vgl. o.V. (2010), Weblink: http://developer.android.com/
  46. ↑ Vgl. Rey, Thumann, Baier (2005), S. 81
  47. ↑ Vgl. o.V. (2010), Weblink: http://blog.coverity.com

10 Literatur- und Quellenverzeichnis

Becker, Pant (2009) Becker, Arno; Pant, Marcus: Android Grundlagen und Programmierung, 1. Auflage, dpunkt.verlag, Heidelberg 2009
Eschweiler, Psille (2006) Eschweiler, Jörg; Psille, Daniel E.: Security@Work Pragmatische Konzeption und Implementierung von IT-Sicherheit mit Lösungsbeispielen auf Open-Source-Basis, Springer-Verlag, Berlin Heidelberg 2006
Flosi (2010), Weblink: http://www.comscore.com Flosi, Stephanie Lyn: comScore Reports September 2010 U.S. Mobile Subscriber Market Share, 2010, http://www.comscore.com/Press_Events/Press_Releases/2010/11/comScore_Reports_September_2010_U.S._Mobile_Subscriber_Market_Share/%28language%29/eng-US, Zuletzt abgerufen am 29.01.2011 um 21:15
Königs (2006) Königs, Hans-Peter: IT-Risiko-Management mit System, 2. korrigierte Auflage, Friedr. Vieweg & Sohn Verlag, Wiesbaden 2006
Müller (2008) Müller, Klau-Rainer: IT-Sicherheit mit System, 3. Auflage, Friedr. Vieweg & Sohn Verlag, Wiesbaden 2008
o.V. (2011a), Weblink: http://developer.android.com/ o.V.: What is Android?, 2011, http://developer.android.com/guide/basics/what-is-android.html, Zuletzt abgerufen am 25.01.2011 um 11:11
o.V. (2011b), Weblink: http://developer.android.com/ o.V.: Signing Your Applications, 2011, http://developer.android.com/guide/publishing/app-signing.html, Zuletzt abgerufen am 25.01.2011 um 16:13
o.V. (2009), Weblink: http://developer.android.com/ o.V.: Android 1.1 Version Notes, 2009, http://developer.android.com/sdk/android-1.1.html, Zuletzt abgerufen am 29.01.2011 um 10:44
o.V. (2010), Weblink: http://developer.android.com/ o.V.: Android 2.3 Platform, 2010, http://developer.android.com/sdk/android-2.3.html, Zuletzt abgerufen am 29.01.2011 um 10:55
o.V. (2010), Weblink: http://blog.coverity.com o.V.: Launch of the Coverity Scan 2010 Open Source Integrity Report, 2010, http://blog.coverity.com/open-source/launch-of-the-coverity-scan-2010-open-source-integrity-report, Zuletzt abgerufen am 29.01.2011 um 11:51
Rey, Thumann, Baier (2005) Rey, Enno; Thumann, Michael; Baier, Dominick: Mehr IT-Sicherheit durch Pen-Tests, 1. Auflage, Friedr. Vieweg & Sohn Verlag, Wiesbaden 2005
Vennon, Stroop (2010), Weblink: http://threatcenter.smobilesystems.com Vennon, Troy; Stroop, David: Threat Analysis of the Android Market, 2011, http://threatcenter.smobilesystems.com/wp-content/uploads/2010/06/Android-Market-Threat-Analysis-6-22-10-v1.pdf, Zuletzt abgerufen am 28.01.2011 um 21:00
Von „http://winfwiki.wi-fom.de/index.php/Risikoanalyse_des_Android_Betriebssystems“
Persönliche Werkzeuge