Guideline - Sichere Apps - Version 1.53 Erstellt für: Mit Inhalten von
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Guideline - Sichere Apps
Version 1.53
Erstellt für:
Mit Inhalten von:
Bearbeiter:
Wulf Bolte 01.11.2013 - 26.05.2014
Klaus Rodewig 26.05.2014
Dominik Neubauer 26.05.2014
Udo Kalinna 27.06.2014Vorwort Heutzutage ist es eine Selbstverständlichkeit, mit Smartphones und Tablets fast jederzeit und überall online gehen zu können. Einer der Erfolgsfaktoren des Smartphones sind die Anwendungsprogramme, die sich der Nutzer durch Apps herunterladen kann. Das Angebot wächst rasant: Allein in Deutschland sollen 3,4 Milliarden Apps im Jahr 2014 heruntergeladen werden. Auch der wirtschaftliche Faktor ist nicht zu unterschätzen, so sollen in diesem Jahr in Deutschland 717 Millionen Euro mit Apps umgesetzt werden. Aus Perspektive der IT-Sicherheit bieten beim Smartphone die Apps die größte Angriffsfläche. Zusätzlich ergeben sich durch die vielfältigen Einsatz- zwecke der Apps Fragen der Informationssicherheit: Wie werden meine Daten von den Apps verarbeitet? Welche Daten werden erhoben? Kann ich als Nutzer die Sicherheitseigenschaften einer App erkennen? Sogar für IT-Experten ist es oftmals eine Herausforderung, die einzelnen Verarbeitungsschritte innerhalb der Prozesse von Apps nachzuvollziehen. Die Unternehmen ifAsec, mediaTest digital, und TÜV Trust IT, haben sich in der Arbeitsgruppe 4 "Vertrauen, Datenschutz und Sicherheit im Internet" des Nationalen IT-Gipfels 2014 zusammengeschlossen, um die Programmierung si- cherer Smartphone-Apps zu unterstützen. Das Ziel ist, die Sicherheitsaspekte möglichst früh im Entwicklungsprozess einer App zu berücksichtigen. Hierfür wurde ein Werkzeug erarbeitet, das dem Programmierer auf sein Vorhaben zu- geschnittene sicherheitstechnische Empfehlungen erstellt. Die bisher erzielten Ergebnisse unterstreichen Sicherheit als zentrales Quali- tätsmerkmal von Smartphone-Apps und bieten Entwicklern Hilfestellung, Si- cherheit von Anbeginn zu integrieren. Michael Hange Präsident Bundesamt für Sicherheit in der Informationstechnik
Anleitung zum Dokument Dieses Dokument fungiert als Richtlinie für App-Entwickler und gilt als Orientie- rung bei der Entwicklung mobiler Apps um umfassende Datensicherheitsstandards zu gewährleisten. Das Dokument ist so formuliert, dass es sowohl Einsteigern und fortgeschrittenen Entwicklern als auch Entscheidern und Nichttechnikern als Grund- lage bei der Planung, Entwicklung und dem Erstellen von Ausschreibungen in App-Projekten dient. Im Anhang befindet sich eine Kurzfassung dieses Dokuments in Form einer Checkliste. Weiterführende Informationen zu den einzelnen Punkten sind in den jeweiligen Textkörpern enthalten. Das Glossar enthält Erklärungen zu Fachbe- griffen sowie eine Link-Liste zu weiterführenden Informationen. Glossarbegriffe werden im Fließtext mit einem „→“ gekennzeichnet. Im Folgenden werden die Begriffe MÜSSEN, KÖNNEN und SOLLEN i.S. des RFC 2199 verwendet. Der Anwender dieser Richtlinie erhält Hinweise darauf, welche Verhaltensweisen oder Eigenschaften einer App, bzw. der App (-Nutzung) zugrunde liegender Dokumente (bspw. AGB und Datenschutzerklärungen), Einfluss auf die Einstufung in Black- bzw. Whitelists haben. Eine Verhaltensweise oder Eigenschaft MUSS eine bestimmte Bedingungen erfüllen, um die Einstufung für die → „Whitelist“* zu erhalten. Es besteht kein Ermessensspielraum. Beim Verstoß gegen diese Bedingung erfolgt eine automatische Einstufung in die → „Blacklist“*. Eine Verhaltensweise oder Eigenschaft SOLL eine bestimmte Bedingung erfüllen, um die Einstufung in die „Whitelist“ zu erhalten. In der Regel ist die Erfüllung der Bedin- gung erforderlich, es besteht im Einzelfall Ermessensspielraum. Beim Verstoß gegen diese Bedingung erfolgt i.d.R, aber nicht zwingend, eine Einstufung in die „Blacklist“. Eine Verhaltensweise oder Eigenschaft KANN eine bestimmte Bedingung erfüllen. Um die Einstufung für die „Whitelist“ zu erhalten ist die Erfüllung der Bedingung vorteilhaft, es besteht jedoch vollständiger Ermessensspielraum. Es kann allerdings zu nachträglicher Abstufung kommen, sollten die Bewertungskriteri- en verschärft werden. BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps
Inhalt
1 Datenschutz & Datensparsamkeit.........................................................1
1.1 Datenschutzerklärung implementieren...............................................................1
1.2 AGB und Datenschutzerklärung -konformes Verhalten.........................................1
1.3 „Privacy by Design“* vs. „Failure by Design“*......................................................1
1.3.1 Gerätespezifische Informationen
1.3.2 Zugriff auf Daten
1.4 Löschen von Daten..............................................................................................3
2 Schutz der Datenübertragung..............................................................4
2.1 Verschlüsselte Kommunikation............................................................................4
2.1.1 Zertifikatsvalidierung
2.2 Standardisierte und aktuelle Protokolle „State of the Art“...................................4
3 Schutz der Datenspeicherung...............................................................5
3.1 Lokale Datenspeicherung.....................................................................................5
3.2 Einverständnis zur Speicherung in der Cloud.......................................................5
4 Einbindung externer Dienste................................................................6
4.1 Drittanbietermodule auf Sicherheit überprüfen...................................................6
4.1.1 Werbemodule „Ad-Tracking“
4.1.2 Entwicklungsmodule und „SDKs“
4.2 Sicherheit der Implementierung..........................................................................7
4.3 Cloud-Anbindung................................................................................................. 7
4.3.1 Cloud-Speicherung
4.3.2 Cloud-Anbieter-Kontaktdaten
4.4 Update-Funktionen...............................................................................................8
5 Nutzerinteraktion................................................................................9
5.1 App-Konfiguration „secure by default“.................................................................9
5.2 Barrierefreiheit..................................................................................................... 9
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps Inhaltsverzeichnis5.3 Passwort-Policies................................................................................................ 10
5.3.1 Passwortlänge
5.3.2 Zeichenvorrat
5.3.3 Passwortstärke
5.3.4 Passwort-Lebensdauer
5.3.5 Passwortwechsel
5.3.6 Passwortverwaltung
5.4 Serverdienste..................................................................................................... 13
5.5 Plattformspezifische Besonderheiten.................................................................13
6 Anhänge............................................................................................ 14
6.1 Literaturliste & Referenzen................................................................................14
6.2 Stichwortverzeichnis.......................................................................................... 15
6.3 Checkliste.......................................................................................................... 18
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps Inhaltsverzeichnis1 Datenschutz & Datensparsamkeit
1.1 Datenschutzerklärung implementieren
Sofern eine App → personenbezogene Daten* verarbeitet, MUSS eine Daten-
schutzerklärung (DS) implementiert werden.
In der DS MÜSSEN folgende Punkte erläutert werden:
• Auf welche → schützenswerte Daten* wird aus welchen Gründen zugegrif-
fen?
• Wie werden die Daten verwendet? (Verarbeitung, Übertragung auf Server
usw.)
• Wie werden die Daten aufbewahrt? (Klartext, verschlüsselt, → gehashed*
usw.)
• Welche Dritte bekommen unter welchen Bedingungen Zugriff auf die Daten?
• Eine Erklärung des Herstellers, die gesammelten Daten zu schützen.
• Wer ist der Datenschutzbeauftragte und wie kann ich Ihn erreichen?
• Erhält der Nutzer die Möglichkeit, seine gesammelten und aufbewahrten Da-
ten vollständig einzusehen und ggf. vollständig, d.h. Auch auf den Servern
des Dienstleisters, entfernen zu lassen?
Die Datenschutzerklärung MUSS im jeweiligen App Store einsehbar und über die
App selber aufrufbar sein.
1.2 AGB und Datenschutzerklärung -konformes Verhalten
Das Verhalten einer App MUSS dem in der AGB/DS dargelegten Verhalten ent-
sprechen. Wenn neue Funktionen hinzukommen, die über den bisherigen Rahmen
der in den AGB und DS festgelegten Bereiche hinaus gehen, MUSS die DS angepasst
werden. Desweiteren MUSS der Nutzer über die Änderung informiert werden. Hier-
bei SOLLTE nicht nur auf allgemeine Änderungen der AGB/DS hingewiesen werden,
sondern der geänderte Bereich direkt dem Nutzer zur Verfügung gestellt werden.
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 11.3 „Privacy by Design“* vs. „Failure by Design“*
Apps MÜSSEN dem Grundsatz → „Privacy by Design“* entsprechen. Dies bedeu-
tet, dass alle datenschutzrelevanten Aspekte im Sinne des Endverbrauchers abgesi-
chert und konfigurierbar sein müssen. Eine Vorkonfiguration aller Optionen auf ein
datenschützendes Verhalten ist dabei unabdingbar.
Die Infrastruktur MUSS auf Design-Fehler hin geprüft werden, die ein systemati-
sches nicht entfernbares Verhalten vermeiden. Bsp. "Whatsapp": hier wird die Au-
thentifizierung der Nutzer anhand der Telefonnummern durchgeführt. Dies ist an
sich schon ein personenbezogenes Datum und darf somit nicht ohne das Einver-
ständnis des Inhabers an fremde Server übertragen werden. Da aber auch die Tele-
fonnummern von Personen, die Whatsapp nicht nutzen, an diese Server übertragen
werden, ist eine DS-konforme Nutzung der App ausgeschlossen.
1.3.1 Gerätespezifische Informationen
Der Zugriff auf gerätespezifische Informationen (z.B. IMEI, MAC-Adressen usw.)
MUSS durch ein Opt-In* des Benutzers erlaubt werden und darf nur in einem zwin-
gend erforderlichen Umfang geschehen.
Viele Hersteller von Apps argumentieren mit einer „Anonymisierung“ der Geräte-
IDs durch die Verwendung von Hashwerten o.ä.. Da dies keine Anonymisierung, son-
dern lediglich eine Pseudonymisierung ist, liegen die Hersteller hier falsch. Es liegt
kein Grund vor, auf diese IDs zur Erkennung von Verbrauchern zurückzugreifen.
Anders sieht es bei den von den Geräteherstellern extra hierfür ins Leben gerufe-
nen „Tracking-IDs“ aus (IDFA (iOS), Advertising ID (Android)). Diese MÜSSEN ver-
schlüsselt übertragen werden und auch das Opt-In wird in Zukunft obligatorisch sein
MÜSSEN. Der unterschiedliche Entwicklungsstand der Datenschutzstandards bei
den mobilen Betriebssystemen macht keine einheitliche Bewertung möglich. Unter
iOS ist es dabei seit Version 6.0 möglich, die IDFA zu ändern oder der Nutzung zu wi-
dersprechen – hier liegt es im Verantwortungsbereich des Programmierers, diesen
Wunsch zu respektieren. Unter Android kann die Advertising ID ebenfalls dynamisch
neu generiert werden; Nur bei Apps, welche die gerätespezifische AndroidID ver-
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 2wenden, ist eine Änderung ohne die Installation eines → „Custom-Roms“* oder eines
→ „Jailbreaks“* weiterhin nicht möglich.
1.3.2 Zugriff auf Daten
Der Zugriff auf Daten (z.B. PIM, Medien, usw.) MUSS unter dem Aspekt der Daten-
sparsamkeit erfolgen. Die Daten dürfen ohne Opt-In des Nutzers nicht an Dritte wei-
tergegeben werden. Der Zugriff auf Daten SOLLTE dem Benutzer erläutert werden
(Warum benötigt die Applikation diesen Zugriff und was funktioniert nicht, wenn ich
diesen Zugriff nicht gewähre?).
1.4 Löschen von Daten
Eine App MUSS ein Verfahren zum Löschen von Daten implementieren, die im
Kontext der App erzeugt worden sind (dies bezieht sich sowohl auf Accounts, lokale
Daten als auch auf Daten auf Servern des App-Anbieters bzw. in der Cloud).
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 32 Schutz der Datenübertragung
2.1 Verschlüsselte Kommunikation
Schützenswerte Daten MÜSSEN nach einem → „dem aktuellen Stand der Technik
entsprechenden“* Verfahren während ihrer Übermittlung vor unbefugter Kenntnis-
nahme und Manipulation geschützt werden. Standard für die Anwendungs krypto-
grafischer Maßnahmen ist die Veröffentlichung TR-02102 des BSI.
2.1.1 Zertifikatsvalidierung
Die Identität der Kommunikationspartner SOLLTE verifiziert werden (→ „Certifica-
te Pining“*).
2.2 Standardisierte und aktuelle Protokolle „State of the Art“
Apps SOLLTEN zur Kommunikation auf standardisierte Protokolle zurückgreifen
(z.B. JSON, XML, XMPP). Dabei ist darauf zu achten, dass die für ihre Nutzung einge-
setzten Bibliotheken eine nach dem aktuellen Stand der Technik sichere Implemen-
tierung gelten.
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 43 Schutz der Datenspeicherung
3.1 Lokale Datenspeicherung
Eine App MUSS Speicherort und Speicherart anhand des in diesem Zusammen-
hang bestehenden Schutzbedarfs der zu speichernden Daten wählen. Bei besonders
schützenswerten Daten ist der vom Betriebssystem zur Verfügung gestellte „siche-
re“ Speicher zu verwenden. Weiterhin ist ein Verschlüsselungsverfahren zum Schutz
der Daten zu implementieren. Bei der Nutzung von Verschlüsselung MUSS auf die
Verwendung sicherer Betriebsmodi geachtet werden. ausreichende Initialisierungs-
vektoren und die Nutzung von → „salt“* beim Erstellen von Schlüsseln geachtet
werden.
Unter iOS MUSS für das Speichern sensibler Daten wie Passwörter, Schlüssel und
Zertifikate die Keychain verwendet werden. Es MUSS dabei eine angemessene
Schutzklasse für die Daten gewählt werden.
Für das Speichern personenbezogener oder sensibler Daten auf einem iOS-Gerät
MUSS die Schutzklasse (NSFileProtection) verwendet werden, die den bestmöglichen
Schutz der Daten gewährleistet.
3.2 Einverständnis zur Speicherung in der Cloud
Vor der Nutzung von Cloud-Diensten MUSS das Einverständnis des Nutzers einge-
holt werden. Auch MUSS der Nutzer auf die datenverarbeitenden Unternehmen und
Standorte hingewiesen werden. Des weiteren MUSS der Nutzer über die Art der
übertragenen Daten aufgeklärt werden. (Dies gilt auch bei der zwangsweisen Ab-
hängigkeit der App von einem bestimmten Cloud-Dienst).
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 54 Einbindung externer Dienste
4.1 Drittanbietermodule auf Sicherheit überprüfen
Bei der Nutzung und Einbindung von Drittanbietermodulen, -Erweiterungen u.ä.
ist deren genaues Verhalten zu testen. Diese Module MÜSSEN beim Umgang mit Da-
ten auf die Einhaltung des BDSG (Bundesdatenschutzgesetz) und der in diesem Do-
kument definierten Richtlinien geprüft werden.
4.1.1 Werbemodule „Ad-Tracking“
Bei der Verwendung von Werbemodulen MUSS der Benutzer auf diese hingewie-
sen werden. Es DÜRFEN keine personenbezogenen Daten an Werbeunternehmen
übertragen werden. Das Werbetracking SOLLTE Opt-In sein und MUSS wenigstens
Opt-Out haben (dies kann auch im Kauf eines „Werbefrei“ Add-Ons realisiert wer-
den).
Zur Identifikation der Nutzer DARF nur die vom jeweiligen System vorgesehene
Werbe-ID genutzt werden (siehe → 1.3.1 Gerätespezifische Informationen).
Nutzerstatistiken „Performance Tracking“
Hierbei greifen die gleichen Regeln wie beim Werbetracking, wobei durch den an-
deren Fokus des „Trackings“ nicht das Durchleuchten des Nutzers, sondern eher das
Nutzerverhalten im Umgang mit der App im Vordergrund steht, was eine Übertra-
gung von personenbeziehbaren Daten nicht notwendig macht.
4.1.2 Entwicklungsmodule und „SDKs“
Es gibt weitere Bereiche mit Zusatzmodulen oder ganzen Entwicklungsumgebun-
gen, die sich um die Quellcodepflege oder um die Erstellung des Quellcodes küm-
mern. In diesen Bereichen MUSS im Vorfeld geklärt werden, dass keine Dinge, die
dieser Richtlinie widersprechen, in die Applikationen integriert werden.
Es SOLLTE in diesem Fall ein Quellcodereview des erstellten Codes durchgeführt
werden, der ein besonderes Augenmerk auf ungewollte bzw. versteckte Funktionen
legt (z.B. Tracking, die Übertragung von gerätespezifischen bzw. personenbeziehba-
ren Informationen, Backdoors u.ä.).
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 64.2 Sicherheit der Implementierung
Der zum Übersetzen des Quelltextes verwendete Compiler MUSS so eingestellt
sein, dass er bestmögliche Überprüfung des Quelltextes vornimmt. Compiler-War-
nungen müssen als Fehler behandelt und vor dem Release der App aus dem Quell -
text entfernt werden.
Für iOS sind die entsprechenden Compiler-Schalter (llvm) die folgenden:
-Wall
-Werror
Überdies MÜSSEN vor dem Release einer iOS-App der Quelltext einer Analyse
durch clang unterzogen und die Meldungen im Quelltext angemessen adressiert
werden.
4.3 Cloud-Anbindung
Bei Applikationen, deren primäre Funktion nicht die Cloud-Anbindung ist, DARF
die Nutzung von Cloud-Diensten NICHT verpflichtend sein. Bei der Einbindung von
Cloud-Diensten MUSS mit dem Cloud-Anbieter ein Vertrag zur → Auftragsdatenverar-
beitung* geschlossen werden.
4.3.1 Cloud-Speicherung
Übermittlung und Speicherung bei externen Diensten MÜSSEN entsprechend des
Schutzbedarfs der Daten abgesichert werden. Das heißt, dass sie nach einem dem
aktuellen Stand der Technik entsprechenden Verfahren verschlüsselt aufbewahrt
werden MÜSSEN.
Unter iOS SOLLTEN personenbezogene oder sensible Daten mit entsprechenden
Dateisystemattributen vom Backup in der iCloud ausgeschlossen und der Benutzer
über diesen Umstand informiert werden, wenn eine angemessene Verschlüsselung
nicht möglich ist.
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 74.3.2 Cloud-Anbieter-Kontaktdaten Dem Benutzer MÜSSEN alle für den Datenschutz relevanten Anbieterdaten zu- gänglich gemacht werden. Es SOLLTE möglich sein, einen direkten Kontakt zum Clouddienstleister aufzubauen und das komplette Löschen der Cloud-Daten zu ver- anlassen (siehe → 1.4 Löschen von Daten). 4.4 Update-Funktionen Die Apps DÜRFEN nur solche Updates eigenständig einspielen, die die Grundfunk- tion nicht verändern. Apps dürfen ohne ein Update ihr grundsätzliches Verhalten ohne Hinweis an den Nutzer nicht ändern. Updates MÜSSEN vom Benutzer bestätigt werden. Die Änderungen MÜSSEN dem Benutzer verständlich und barrierefrei (siehe → 5.2 Barrierefreiheit) kommuniziert werden. Dies SOLLTE unbedingt bei → „Anti- Features“* praktiziert werden. BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 8
5 Nutzerinteraktion
5.1 App-Konfiguration „secure by default“
Beim Erstellen der App sollten nicht nur unbedarfte Nutzer berücksichtigt, son-
dern auch Konfigurationsmöglichkeiten für versierte Nutzer zur Verfügung gestellt
werden. Auch wenn eine Applikation durch das Verbieten des Zugriffs z.B. auf Kon-
taktdaten an Funktionsumfang verliert, sollte dies dem Nutzer möglich gemacht
werden. Bei erstmaliger Nutzung solcher Funktionen SOLLTE eine Genehmigung des
Nutzers eingeholt werden, was auch zur Sensibilisierung beiträgt. In diesem Dialog
SOLLTE es möglich sein, das Abfrageverhalten zu deaktivieren, um unbedarfte Nut-
zer nicht zu „belästigen“. Dies ermöglicht eine Vorkonfiguration aller Optionen auf
ein datenschützendes Verhalten, ohne den Verlust von Funktionalität in Kauf neh-
men zu müssen.
5.2 Barrierefreiheit
AGB und Datenschutzerklärung MÜSSEN → barrierefrei* zur Verfügung gestellt
werden. Darüber hinaus SOLLTEN diese Erklärungen zur erhöhten Lesbarkeit auch
als Link auf Online-Versionen zur Verfügung gestellt werden.
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 95.3 Passwort-Policies
Die Guideline Sichere Apps wäre ohne eine Erläuterung zur Passwortsicherheit
nicht vollständig. Beim Berücksichtigen der nachfolgenden Kriterien kann die Pass-
wortsicherheit erhöht und ein optimaler Schutz erreicht werden.
5.3.1 Passwortlänge
Aus den Grundschutzkatalogen des BSI werden mindestens acht Zeichen für al-
phabetische Passwörter empfohlen. Unter alphabetischen Passwörtern versteht man
Passwörter aus dem kleinen und großen Alphabet, also 26∗2=52 Zeichen. Die
Passwortlänge ergibt sich dann aus der Summe der einzelnen Zeichen.
5.3.2 Zeichenvorrat
Neben der Passwortlänge ist der Zeichenvorrat ein noch wichtiges Merkmal der
Sicherheit von Passwörtern. Der Zeichenvorrat gibt die Anzahl der zu Verfügung ste-
henden Zeichen wieder. Neben den Klein- und Großbuchstaben, kommen dann noch
die Zahlen 0 – 9 und alle Sonderzeichen wie z.B. !, ?, (, [,Nun stellt sich die Frage:
Was ist sicherer, ein größer Zeichenvorrat oder längere Passworte?
Werden die Passwortkombinationen mit veränderter Passwortlänge und Zeichen
berechnet, ist deutlich zu erkennen, dass ein um eins längeres Passwort die Anzahl
der maximalen Kombinationen wesentlich mehr beeinflusst als ein um eins erhöhter
Zeichenvorrat.
l 4 (l +1) 5
( I ) C max =(nc +1) =27 =531.441 ( II ) C max=nc =26 =11.881.376
Fazit: Die Sicherheit eines Passwortes hauptsächlich von der Länge des Passwor-
tes abhängt und weniger von der Anzahl des Zeichenvorrates.
5.3.4 Passwort-Lebensdauer
Das wichtigste Kriterium für sichere Passworte liegt allerdings in der Lebensdauer
des Passwortes.
Der Passwort-Rechner auf der Internetseite der ifAsec berechnet unter der Einga-
be von vier Werten die Lebensdauer eines Passworts ( https://ifasec.de/leistungen/for-
schung-entwicklung/passwortrechner/). Neben der Anzahl aller möglichen Passwörter
wird die Lebensdauer des Passworts in Jahren, Monaten, Tagen, Stunden, Minuten
und Sekunden genau angezeigt.
Beispielsweise benötigt ein handelsüblicher PC mit den Parametern Zeichenvor-
rat „kleines Alphabet“ und Passwortlänge „16 Zeichen“ immerhin rund 27.000 Jahre,
um das Passwort zu knacken.
5.3.5 Passwortwechsel
Häufige Passwortwechsel führen bei den Nutzern nicht zu mehr Sicherheit, son-
dern verleiten die Nutzer dazu, Wege zu finden, sich zu einfache Passworte zu mer-
ken. In fast allen Unternehmen ist eine Passwort-Policy (Richtlinie) nicht nach den
hier vorgestellten Kriterien abgeleitet worden. Am Beispiel eines mittelständischen
Unternehmens werden die Kosten einer falschen Passwort-Policy aufgezeigt. Neh-
men wir an, ein mittelständiges Unternehmen mit 1.000 Arbeitsplätzen hat die Re-
gelung, einmal im Quartal die Passworte wechseln lassen. Alle diese PCs müssen
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 11durch Passworte geschützt werden. Die Kosten eines Passwortwechsels lassen sich
direkt angeben. Ein Büroangestellter, der ein Bruttogehalt von ca. 2.500 Euro ver-
dient, kostet einen Unternehmer unter Betrachtung der Vollkostenrechnung (Neben-
kosten, Infrastruktur, etc.) ungefähr das Doppelte (hier 5.000 Euro p.M. = 60.000
Euro p.a.). Bei 220 Arbeitstagen kostet der Mitarbeiter rund 34 Euro die Stunde. Ein
Mitarbeiter benötigt für das gesamte Procedere (Passwort ausdenken, nochmaliger
Blick in die Passwort Policy, Eingabe in das System, abmelden und wieder anmelden
zur Absicherung der einwandfreien Funktion seines neuen Passwortes) im Durch-
schnitt 7 Minuten. Das entspricht 4 Euro pro Passwort. Hochgerechnet auf unser Bei-
spiel mit 1.000 Angestellten und quartalsweisem Wechsel sind das immerhin 16.000
Euro.
50% - 75% dieser Kosten lassen sich mit einer vernünftigen Passwort-Policy nach
oben genannten Kriterien einsparen. Hier sind das immerhin 8.000 – 12.000 Euro!
5.3.6 Passwortverwaltung
Im Allgemeinen bestehen drei Möglichkeiten der Passwortverwaltung. Die Erste
ist, sich alle zu merken. Das ist wohl der sicherste Weg, doch wird es sehr schwierig,
sich die unterschiedlichen und genügend langen Passworte zu merken. Der Zweite
ist, sich auf die Passwort-Speicherfunktion des Webbrowsers zu verlassen und der
Dritte, einen Passwort-Manager zu benutzen, der hier näher beschrieben wird.
Passwort-Manager können im Internet heruntergeladen werden (z.B. KeePass bei
heise.de oder chip.de). Sie erzeugen pro Dienst, den Sie aufrufen, ein zufälliges
Passwort. Zudem kann bestimmt werden, aus wie vielen und aus welchem Zeichen-
vorrat sich das Passwort zusammensetzen soll. Durch eine so genannte Auto-Fill-In
Funktion setzt der Passwort-Manager bei jedem Aufruf einer Web-Seite mit Login
und Passwort sofort die richtigen Daten in die Web-Seite. Da es sich in der Regel bei
der Erstellung von Passworten nicht um lexikalische Wörter mit Zahlenkombinatio-
nen handelt, ist eine hohe Lebensdauer der Passworte vorerst gesichert. Sie geben
dazu einen guten Überblick über Zugänge und Passworte.
Welche Schwachstellen haben aber die Passwort-Manager? Zumindest für die
Verwaltung der Datenbank muss sich das Master-Passwort gemerkt werden. Dieses
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 12ist eine Schwachstelle von Passwort-Managern. Das Master-Passwort gehört nicht auf das System - niemals! Sollte das System kompromittiert sein, so kann der An- greifer über das Master-Passwort Zugriff auf die Passwort-Datenbank haben. Aber auch Passwort-Manager legen alle erzeugten Passwörter in eine verschlüsselte Da- tenbank ab und die liegt in der Regel auf dem System. Ein weiterer Schutz ist die Auslagerung dieser Passwort-Datenbank, z.B. auf einen externen USB-Stick oder ein externes Laufwerk. 5.4 Serverdienste Lokale Serverdienste DÜRFEN nur auf expliziten Wunsch geöffnet werden und MÜSSEN mit adäquaten Maßnahmen gegen unbefugten Zugriff geschützt werden (siehe → 2.1 Verschlüsselte Kommunikation). Serverdienste MÜSSEN von allen Stan- dardpasswörtern, Remote-Administrations- und Testzugängen befreit werden und dürfen nicht automatisch lokal gehaltene Dateien zum Download ohne Authentifizie- rung anbieten. 5.5 Plattformspezifische Besonderheiten Die App MUSS plattformspezifische Besonderheiten berücksichtigen und ange- messen adressieren. Das ist unter Android z.B. der fehlende Zugriffsschutz beim Speichern von Daten auf der SD-Karte. Unter iOS ist eine plattformspezifische Be- sonderheit das automatische Anfertigen von Screenshots durch das Betriebssystem beim Beenden einer App. Hier muss der Programmierer dafür sorgen, dass das Be- triebssystem keinen Screenshot personenbezogener oder sensibler Daten anfertigt. BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 13
6 Anhänge
6.1 Literaturliste & Referenzen
• TR-02102-1 „Kryptographische Verfahren: Empfehlungen und Schlüssellän-
gen“, BSI 2013
• TR-02102-2 „Verwendung von Transport Layer Security (TLS)“, BSI 2013
• www.allianz-fuer-cybersicherheit.de
• „Leitfaden Apps & Mobile Services“, BITKOM 2013
• „Sichere Softwareentwicklung unter Android v1.0“, Allianz für Cybersicher-
heit 2012
• „Apps programmieren für iPhone und iPad“, Rodewig, Wagner, Galileo Press
2013
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 146.2 Stichwortverzeichnis
0 Anleitung zum Dokument..........................................................................................
Blacklist
bezeichnet das Gegenteil von → Whitelist und beschreibt das NICHT erfüllen
der von uns angelegten Sicherheitsstandards. Blacklists werden von Unterneh-
men als Filter für installierbare Applikationen auf zentral gemanageten Gerä-
ten genutzt
Whitelist
bezeichnet eine Liste von Applikationen, die unseren definierten Sicherheits-
merkmalen genügen. Whitelists werden von Unternehmen als Filter für instal-
lierbare Applikationen auf zentral gemanageten Geräten genutzt
1 Datenschutz & Datensparsamkeit.............................................................................
Auftragsdatenverarbeitung
dient dazu, das Outsourcing von Datenverarbeitung datenschutzrechtlich ab-
zusichern. Dabei verbleibt die Verantwortung für die ordnungsgemäße Daten-
verarbeitung beim Auftraggeber.
→ http://de.wikipedia.org/wiki/Auftragsdatenverarbeitung
Custom-ROM (benutzerdefiniertes Read-Only-Memory)
ist ein alternatives, auf die Nutzerbedürfnisse zugeschnittenes Betriebssyste-
mabbild, das sich auf Smartphones installieren lässt und eine tiefere Konfugu-
ration ermöglicht als die Hersteller-ROMs.
Failure by Design
ist ein Kunstbegriff, der das Gegenteil von "Privacy by Design" beschreibt. Er
umschreibt also grundsätzliche Fehler, die bei der Konzeptionierung von Infra-
strukturen ein Datenschutzkonformes Verhalten grundsätzlich verhindern.
Hashfunktion
werden im Allgemeinen verwendet, um den Inhalt von übertragenen Daten zu
verifizieren. Oft werden Hash-Werte auch genutzt, um anhand einer "Quersum-
me" eines Datums nicht das Datum selbst, sondern nur einen wiedererkennba-
ren Wert zu übertragen. Damit soll die Wiedererkennbarkeit gewährleistet sein
und dennoch nicht das Datum selbst zur Verfügung gestellt werden
→ http://de.wikipedia.org/wiki/Hashfunktion
Opt-In
beschreibt, dass es erforderlich ist, den Nutzer in die Entscheidung zwingend
einzubeziehen. Der Nutzer MUSS aktiv seine Einwilligung abgeben.
personenbezogene Daten
sind nach §3 Abs. 1 Bundesdatenschutzgesetz (BDSG) „Einzelangaben über
persönliche oder sachliche Verhältnisse einer bestimmten oder bestimmbaren
natürlichen Person“ also Daten, durch deren Inhalt auf die Person geschlossen
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 15werden kann. Nach §3 Abs. 9 BDSG gibt es auch „besondere Arten personen-
bezogener Daten“. Hierzu zählen Gesundheitsdaten, Informationen über die
rassische oder ethnische Herkunft, politische, religiöse, gewerkschaftliche oder
sexuelle Orientierung.
→ https://de.wikipedia.org/wiki/Personenbezogene_Daten
Privacy by Design
ist ein Kunstbegriff, mit dem "das Beachten von Datenschutz" bei der Produkt-
entwicklung gemeint ist. Dadurch soll auf die unproblematische Implementie-
rungsmöglichkeit aller Datenschutzrelevanten Themen hingewiesen werden,
wenn dies von Anfang an berücksichtigt wird. Das nachträgliche implementie-
ren von Datenschutz ist nachweislich kostenintensiver und aufwändiger. Meist
lässt dadurch die Nutzbarkeit und Qualität grundsätzlich nach.
Pseudonymisierung
beschreibt ein Datenschutzverfahren, bei dem z.B. der Name durch ein Pseud-
onym (eine Buchstaben- oder Zahlenkombination) ersetzt wird, um die Identifi-
zierung des Betroffenen wesentlich zu erschweren. Im Gegensatz zur Anony-
misierung bleiben bei der Pseudonymisierung Bezüge verschiedener Datensät-
ze, die auf dieselbe Art pseudonymisiert wurden, erhalten.
→ http://de.wikipedia.org/wiki/Pseudonymisierung
Schützenswerte Daten
siehe → Personenbezogene Daten
Jailbreak / Rooten
bezeichnet das Erweitern der Rechte des Nutzers auf dem Endgerät. Ähnlich
einem herkömmlichen PC liegen nach einem Jailbreak die Administrationsrech-
te beim Nutzer und nicht mehr beim Hersteller, was dem Nutzer das Entfernen
von Nutzungsbeschränkungen, das Schließen von Sicherheitslücken oder das
Deinstallieren von unerwünschten, vorinstallierten Applikationen ermöglicht.
→ http://de.wikipedia.org/wiki/Jailbreak_%28iOS%29
2 Schutz der Datenübertragung...................................................................................
Certificate Pining
beschreibt das Vergleichen von Serverzertifikaten mit einer eigenen Zertifikat-
stabelle, um Manipulationen der Root-Zertifikate auszuschließen.
→ https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
dem aktuellen Stand der Technik entsprechende Verschlüsselung
ist eine stetig in Evolution befindliche Bezeichnung des Sicherheitsniveaus von
Verschlüsselungsverfahren. Aktuelle Zusammenfassung (Stand 31.10.2013):
RC4 - nicht ausreichend; AES - nicht optimal, aber mit AES 256Bit vertrauens -
würdig; Twofish oder Salsa20 sind gute Alternativen; CBC & Hamac – nicht aus-
reichend; RSA - nur mit mindestens 2048Bit-Schlüssel; sicherer sind 4096DSA
- Schlüssel mindestens 2048Bit, im Zweifel RSA vorziehen; Elliptische Kurven -
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 16wurde von der NSA mitentwickelt (dadurch potentielle Schwachstellen); Hash-
Verfahren: SHA2 empfohlen, MD5 und SHA1 nicht empfohlen.
→ http://animeelite.de/cmswp/verschluesselung-aktuelle-stand-technik/
→ http://de.wikipedia.org/wiki/Verschl%C3%BCsselung
4 Einbindung externer Dienste.....................................................................................
Anti-Features
sind Funktionen, die für den Nutzer keinen Gewinn darstellen, sondern den ge-
genteiligen Effekt haben. Tracking-Funktionen, Werbung, Abhängigkeiten von
Drittmodulen, die u.U. unfrei sind, oder der Verlust von Funktionen werden im
Allgemeinen als Anti-Features bezeichnet.
Salt
bezeichnet in der Kryptographie eine zufällig gewählte Zeichenfolge, die an
einen gegebenen Klartext vor der Verwendung als Eingabe einer Hashfunktion
angehängt wird, um die Entropie der Eingabe zu erhöhen.
→ http://de.wikipedia.org/wiki/Salt_%28Kryptologie%29
5 Nutzerinteraktion......................................................................................................
barrierefrei
beschreibt in diesem Fall das zur Verfügung stellen von Informationen in einer
Weise, dass sie von Menschen mit Behinderung und älteren Menschen in der
selben Weise wahrgenommen werden kann, wie von Menschen ohne diese
Einschränkungen.
→ http://de.wikipedia.org/wiki/Barrierefrei
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 176.3 Checkliste
1 Datenschutz & Datensparsamkeit:
Datenschutzerklärung implementieren
AGB und Datenschutzerklärung -konformes Verhalten
„Privacy by Design“
Gerätespezifische Informationen geschützt
Zugriff auf Daten eingeschränkt (Datensparsamkeit)
Löschfunktion von Daten zur Verfügung gestellt
2 Schutz der Datenübertragung
Verschlüsselte Kommunikation
Zertifikatsvalidierung
Standardisierte und aktuelle Protokolle „State of the Art“
3 Schutz der Datenspeicherung
Lokale Datenspeicherung abgesichert
Einverständnis zur Speicherung in der Cloud eingeholt
4 Einbindung externer Dienste
Drittanbietermodule auf Sicherheit überprüft
Werbemodule „Ad-Tracking“ geprüft
Nutzerstatistiken „Performance Tracking“ geprüft
Entwicklungsmodule und „SDKs“ geprüft
Cloud-Anbindung deaktivierbar
Cloud-Speicherung sicher
Cloud-Anbieter Kontaktdaten hinterlegt
Update-Funktionen transparent
5 Nutzerinteraktion
App-Konfiguration „secure by default“
Barrierefreiheit gewährleistet
Fehlermeldungen sind aussagekräftig (und beinhalten keine zu tiefen Infos?)
Bildschirmsperre (input fehlt)
Passwordpolicies (input fehlt)
Musik Medien und AV-Steuerung (iput fehlt)
Serverdienste optional
Plattformspezifische Besonderheiten
BSI – ifAsec - mediaTest digital - TÜV TRUST IT Guideline - Sichere Apps 18Sie können auch lesen
