prüfkonzept – konzept zur prüfung von apps / krite ... · male aus der app extrahiert und gegen...
Post on 06-Aug-2019
216 Views
Preview:
TRANSCRIPT
Prüfkonzept – Konzept zur Prüfung von Apps / Krite-
rienkatalog gemäß „certified app"
„certified app", das Prüf- und Zertifizierungsschema der datenschutz cert GmbH für mobile Anwendungen
datenschutz cert GmbH
18.12.2015
Seite 2
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Inhaltsverzeichnis
1. Über„certified app" ________________________________________________ 5
1.1 Das Prüfkonzept __________________________________________________ 5
1.2 Durch Tools unterstützte Prüfung ____________________________________ 6
1.3 Das Prüf- und Zertifizierungsschema _________________________________ 6
1.4 Automatisierte Validierung _________________________________________ 7
1.5 Was ist neu an „certified app"? ______________________________________ 7
1.6 Das Siegelstufenkonzept ___________________________________________ 8
2. Einordnung in den Gesamtkontext und mitgeltende
Dokumente ______________________________________________________________ 10
3. Einleitung zum Prüfkonzept gemäß „certified app“ _____________________ 12
4. Anforderungen an eine App ________________________________________ 14
4.1 Identifikation und Ist-Aufnahme des Funktionsumfangs
einer App ________________________________________________________ 14
4.2 Sicherheitsbedarf einer App _________________________________________ 17
4.3 Sicherheitserwartung ______________________________________________ 21
5. Darlegung der Sicherheitsfeatures der App ____________________________ 29
6. Prüfung einer App_________________________________________________ 30
6.1 Prüfungsarten ____________________________________________________ 30
6.2 Umgang mit Abweichungen ________________________________________ 36
6.3 Siegelstufen ______________________________________________________ 37
7. Zertifizierung einer App ____________________________________________ 41
7.1 Zwei-stufiges Verfahren ____________________________________________ 41
7.2 Laufzeit eines Zertifikates __________________________________________ 41
7.3 Maintenance und Re-Zertifizierung __________________________________ 41
7.4 Übersicht über Prüf- und –Zertifizierungsstellen für
„certified app“ ____________________________________________________ 41
7.5 Ansprechpartner und Kontakt (Selbstauskunft) ________________________ 43
7.6 Übersicht über den Zertifizierungsprozess _____________________________ 43
7.7 Zeitbedarf für Prüfung und Zertifizierung _____________________________ 46
7.8 Veröffentlichung der Zertifikate/ Validierungssystem ___________________ 46
7.9 Entzug eines Zertifikates ___________________________________________ 47
7.10 Ablauf eines Zertifikates ____________________________________________ 48
7.11 Kosten und Gebühren ______________________________________________ 48
Seite 3
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
7.12 Geschäftliche Bedingungen für die Durchführung von
Zertifizierungsdienstleistungen _____________________________________ 49
8. Annex zur Methodik _______________________________________________ 50
9. Referenzen ______________________________________________________ 59
9.1 Kriterienwerke, Normen und Standards _______________________________ 59
9.2 Dokumentation zu „certified app“ ___________________________________ 59
Seite 4
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Historie
Version Datum geänderte Kapitel Grund der Änderung geändert
durch
1.0 18.12.2015 alle Erstellung, Freigabe
initiale Version
Maseberg
Dokumenten-Überwachungsverfahren
Status: final Prozess-/ Dokumentbesitzer: Dr. Sönke Maseberg Version: 1.0
Seite 5
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
1. Über„certified app"
Smartphones und Tablets finden eine immer weitere Verbreitung sowohl im privaten
als auch im geschäftlichen Umfeld. Wesentlich für ihren Erfolg ist die Tatsache, dass
Nutzer mobile Anwendungen – also „Apps“ – einfach und bequem per Klick installie-
ren können. Mit den Chancen dieser Entwicklung gehen jedoch leider auch große Ri-
siken einher. Vor allem durch die wachsende Zahl von mobilen Anwendungen von
oft unbekannten Entwicklern. Hierdurch steigt die Gefahr der Verbreitung von
Schadsoftware, die sich beispielsweise als nützliche Anwendung tarnt. Zudem kön-
nen Schwachstellen in Apps von Angreifern als Einstiegspunkte genutzt werden, um
unberechtigten Zugriff auf Daten zu erhalten. Je weiter sich Apps verbreiten, desto
größer werden insofern die potentiellen Sicherheitsrisiken für den Nutzer.
Bei anderen IT-Produkten – etwa Kartenterminals, Firewalls oder Betriebssystemen –
haben sich längst Prüf- und Zertifizierungsverfahren etabliert, um mögliche Sicher-
heitsrisiken aufzuspüren und im Anschluss an eine Prüfung zu bestätigen, dass das
IT-Produkt „sicher“ ist. Zu nennen ist hier etwa die Evaluationsmethodik anhand der
Common Criteria (CC) mit dem Fokus auf die IT-Sicherheit eines IT-Produktes sowie
das Datenschutzgütesiegelverfahren des Unabhängigen Landeszentrums für Daten-
schutz (ULD) Schleswig-Holstein mit den Schwerpunkten Datenschutzrecht und Da-
tensicherheit.
Diese für IT-Produktprüfungen bekannten und nachhaltigen Prüfungs- und Zertifizie-
rungsverfahren sind durchaus übertragbar auf die Prüfung von mobilen Anwendun-
gen bzw. Apps. Allerdings sind die Verfahren zumeist sehr kostspielig für den App-
Anbieter und ziehen sich in der Regel über Monate hin. Ferner tragen allgemeine Kri-
terienkataloge zu Datenschutzrecht und IT-Sicherheit den spezifischen Anforderun-
gen an Apps nicht immer Rechnung. Damit hinken sie der schnellen Dynamik der
App-Entwicklung hinterher.
Ziel des Verbundprojekts „ZertApps – Zertifizierte Sicherheit für mobile Anwendun-
gen“, das vom Bundesministerium für Bildung und Forschung (BMBF) gefördert wur-
de, war daher, das Thema „Sicherheitsanalyse von mobilen Anwendungen“ grundle-
gend und umfassend zu bearbeiten. Hierfür wurde eine spezifische Prüf- und Zertifi-
zierungsplattform für Apps entwickelt. Dieses Prüf- und Zertifizierungsschema wird
nunmehr von der datenschutz cert GmbH angeboten als:
--- „certified app ".
Zunächst stehen hierbei Android-Apps im Fokus, da diese derzeit den größeren
Marktanteil an den gängigen Betriebssystemen für Smartphones und Tablets besit-
zen.
1.1 Das Prüfkonzept
Auf welche Daten darf eine App zugreifen? Wohin darf sie Daten schicken? Der Zu-
griff auf GPS-Daten beispielsweise mag bei einer Karten-App sinnvoll sein, bei der
Taschenlampen-App aber womöglich nicht. Da die Sicherheitserwartungen per se
nicht für alle Apps identisch sind, sieht „certified app“ zunächst einen strukturierten,
methodischen Ansatz vor, um für die zu prüfende App den Sicherheitsmaßstab fest-
zulegen. Der Sicherheitsmaßstab definiert, welche Daten verarbeitet werden, welche
Seite 6
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Funktionalitäten die App bietet und welche Sicherheitsziele verfolgt werden sollen.
Hieraus ergeben sich dann die Sicherheitsanforderungen, welche die App umsetzen
muss.
Das Vertrauen in eine Sicherheitsüberprüfung hängt zentral davon ab, wie tief und
welche Aspekte geprüft wurden. Im Hinblick auf Kosten und unterschiedliche Sicher-
heitserwartungen sieht „certified app“ vor, vier verschiedene Prüftiefen anzubieten:
Beginnend mit einer strukturierten, aussagekräftigen Herstellererklärung, über eine
mittels automatischer Tools unterstützte Prüfung sowie durch ergänzend manuell
durchgeführte Tests bis hin zur Überprüfung der Entwicklungs- und Produktionsum-
gebung von Apps werden dezidierte Maßnahmen zur Vertrauensbildung in diesem
Prüfkonzept beschrieben. Die durch Tools unterstütze Prüfung ist dabei ein Schwer-
punkt von „certified app“.
Die App-Entwicklung ist, wie bereits festgestellt, rasant, so dass Sicherheitsprüfun-
gen dieser Dynamik Rechnung tragen müssen. Deshalb umfasst das nachfolgende
Prüfkonzept ferner ein Maintenance-Verfahren, durch welches Updates und Patches
von Apps effektiv und effizient – und damit relativ kostengünstig – geprüft und re-
zertifiziert werden können. Hier soll ein möglichst hoher Automatisierungsgrad er-
reicht werden.
Im Fokus steht sowohl IT-Sicherheit als auch Datenschutz.
1.2 Durch Tools unterstützte Prüfung
Je nach Prüfstufe sieht das Prüfkonzept eine durch Tools unterstützte Prüfung von
Apps vor. Hierdurch sollen unter anderem die sehr aufwendigen und vor allem zeitin-
tensiven Quellcodeaudits so gut wie möglich substituiert werden.
Ergänzend zu den Prüfungen, die auf das Auffinden von Programmierfehlern in Apps
abzielen, werden Tools bereitgestellt, die mittels statischer und dynamischer Analy-
sen die Sicherheitsarchitektur von Apps automatisiert aus dem Quelltext wiederge-
winnen. Dies erlaubt einer Prüfstelle, schnell einen Überblick über die bereits in einer
App umgesetzten Sicherheitsmechanismen zu gewinnen, ohne ein Code-Review
durchführen zu müssen. Auf diese Weise kann ohne hohen Aufwand erkannt wer-
den, ob sicherheitskritische Daten, wie z.B. Passwörter, verschlüsselt auf dem Gerät
abgelegt werden oder die Verbindung mit einem Backend kryptographisch gesichert
ist.
1.3 Das Prüf- und Zertifizierungsschema
Das Prüf- und Zertifizierungsschema für Apps sieht – entsprechend internationaler
Standards – ein klassisches zwei-stufiges Verfahren vor: Eine Prüfstelle führt die Prü-
fung durch und eine Zertifizierungsstelle zertifiziert anschließend die App auf Grund-
lage der Prüfergebnisse.
Internationale Regelwerke für Prüf- und Zertifizierungsstellen – wie etwa ISO/IEC
17025 oder ISO/IEC 17065 – dienen als Vorlage, auf deren Basis ein schlanker Prozess
etabliert wurde. Sowohl die Kommunikation zwischen App-Anbieter und Prüfstelle
als auch zwischen Prüf- und Zertifizierungsstelle wird dabei durch Tools unterstützt,
die das Verfahren beschleunigen.
Seite 7
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
1.4 Automatisierte Validierung
IT-Produkte, die ein Zertifikat aufweisen, zeigen dies in der Regel durch ein vertrau-
ensbildendes und wiedererkennungsfähiges Symbol. Ein entsprechendes „Logo“ wird
häufig als Graphik beigefügt und verlinkt auf eine Zertifikatsliste, auf der die Prüfer-
gebnisse öffentlich eingesehen werden können.
Diese vom Prozess der Prüfung losgelösten Artefakte stehen für Apps zwar zur Ver-
fügung, aber nicht im Vordergrund. Vielmehr muss hier dem Anwender schnell und
direkt angezeigt werden, ob eine App ein gültiges Zertifikat gemäß „certified app"
aufweist. Deshalb ist ein Validierungssystem entstanden, das die Prüfung, ob eine
App ein gültiges Zertifikat aufweist oder nicht, automatisch durchführt: Die Cert-
Validation-App überprüft, ob die installierten Apps in der vorliegenden Version ge-
mäß „certified app“ zertifiziert sind oder nicht. Diese CertValidation-App stellt damit
als „Trust Anchor“ eine Art Vertrauensanker dar. Die CertValidation--App nutzt dabei
eine elektronische Zertifikatsliste.
1.5 Was ist neu an „certified app"?
Worin unterscheidet sich „certified app" von anderen Prüfungs- und Zertifizierungs-
verfahren für mobile Anwendungen?
--- Zunächst: Es wird nicht direkt gegen die App geprüft, sondern – wie bei in-
ternationalen Verfahren üblich – 3-stufig:
--- Der App-Anbieter beschreibt zunächst selbst die Sicherheitsfunktionali-
täten seiner App; allein dadurch, dass der App-Anbieter aufgefordert ist,
seine App auf strukturierte Art und Weise zu beschreiben und zu analy-
sieren, wird ein erster Prüfschritt durchgeführt. Denn hierdurch wird
beispielsweise bereits sichergestellt, dass die Sicherheitsfunktionalitä-
ten den tatsächlichen Schutzbedarf abdecken – und andersherum der
Schutzbedarf durch Sicherheitsfunktionalitäten abgedeckt wird. Außer-
dem werden rechtliche Anforderungen adressiert.
--- In zweiter Instanz führt eine unabhängige Prüfstelle mit entsprechen-
dem Know-How eine Prüfung gemäß Prüfschema durch.
--- Und zuletzt führt eine unabhängige Zertifizierungsstelle mit entspre-
chendem Know-How und Überblick über mehrere Zertifizierungsverfah-
ren eine Zertifizierung gemäß Zertifizierungsschema durch.
Es werden damit drei vertrauensbildende Maßnahmen zur Prüfung und
Zertifizierung von Apps durchgeführt.
--- Die verschiedenen Prüf-/Siegelstufen sehen verschiedene Prüfarten vor, die
jeweils verschiedene Nachweise darstellen – von der Selbstauskunft über
automatisierte Plausibilitätstests und automatisierte Tools bis hin zu Pe-
netrationstests, rechtlichen Prüfungen und einem Site Visit der Entwick-
lungs- und Produktionsumgebung.
--- Besondere Herausforderung der ersten Siegelstufe „Bronze“ (vgl. Ausfüh-
rungen in Abs. 1.6) ist, eine App relativ schnell und kostengünstig zu prüfen
und zu zertifizieren. Hier ist eine Interessenabwägung durchgeführt wor-
Seite 8
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
den, mit dem Ergebnis, dass ein Bronze-Zertifikat deutlich mehr als „kein
Zertifikat“ darstellt.
Anspruch von „certified app" ist es, das Bronze-Zertifikat – und das, wofür
es steht – transparent zu beschreiben. So wird dem geneigten Interessen-
ten klar, wofür es steht. Und wofür es nicht steht.
1.6 Das Siegelstufenkonzept
Die Siegelstufe gibt an, wie „tief eine Prüfung geht“, d.h. durch welche Vertrauens-
würdigkeitsmaßnahmen die App überprüft wird. „certified app“ sieht vier Siegelstu-
fen vor:
--- „Bronze“ – die Basisprüfung einer App;
--- „Silber“ – Basisprüfung, ergänzt um zusätzliche automatisierte Analysen;
--- „Gold“ – umfangreiche Prüfung samt weiterer automatisierter und händi-
scher Tests sowie einer rechtlichen Begutachtung, die die Basisprüfung er-
gänzt;
--- „Platin“ – „Platin“ ergänzt den „Gold“-Prüfungsumfang um einen Site Visit
der Entwicklungs- und Produktionsumgebung.
Basis aller Prüfstufen ist die Selbstauskunft, bei der der App-Anbieter seine zu zertifi-
zierende App exakt beschreibt und ihren Funktionsumfang darstellt. Ferner sichert
der App-Anbieter über diese Herstellererklärung rechtlich bindend Sicherheits- und
Datenschutzeigenschaften seiner App zu.
Bei der „Bronze“-Prüfung wird diese Selbstauskunft selber auf Vollständigkeit und
formale Korrektheit überprüft. Zusätzlich werden durch automatisierte Tools Merk-
male aus der App extrahiert und gegen die Selbstauskunft abgeglichen: die App sel-
ber mit Namen und Versionsnummer sowie die gesetzten Zugriffsrechte (Permissi-
ons).
Die „Silber“-Prüfung erweitert die „Bronze“-Prüfung um weitere automatisierte Ana-
lysen. Hierüber wird die globale PIN-Policy, der Aufruf der Krypto-API, hinterlegte
ULRs und IP-Adressen, die Verwendung von Standardprotokollen sowie die Imple-
mentierung überprüft und gegen die Angaben der Selbstauskunft verglichen.
Die „Gold“-Prüfung wiederum erweitert die „Silber“-Prüfung um eine manuelle Ana-
lyse der App, eine Datenfluss-Analyse und eine Analyse des Datensendungsverhal-
tens. Ferner wird die Implementierung weitergehend analysiert. Neben technischen
Aspekten wird eine datenschutzrechtliche Prüfung durchgeführt.
Die „Platin“-Prüfung erweitert schließlich die „Gold“-Prüfung um einen Site Visit der
Entwicklungs- und Produktionsumgebung, um sicherzugehen, dass die zertifizierte
App auch so ausgeliefert wird.
Beachten Sie bitte, dass die Siegelstufen stets das Maß an Vertrauen angeben, das
die Zertifizierungsstelle aufgrund der durchgeführten Prüfungen in die zugesicher-
ten Eigenschaften der geprüften App bestätigen, nicht aber das Maß an Sicherheit
oder Datenschutz der App: Eine höher zertifizierte App weist nicht zwingend mehr
Sicherheit oder mehr Datenschutz auf.
Seite 9
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Beachten Sie ferner, dass auch eine von uns zertifizierte App Schwächen oder Mängel
an IT-Sicherheit oder Datenschutz aufweisen kann. Eine Prüfung und Zertifizierung
reduziert zwar typischerweise das Risiko, schließt es aber nicht gänzlich aus. Wie zu-
vor ausgeführt, kann dieses Risiko durch eine tiefergehende Prüfung weiter reduziert
werden. Letztlich können wir als Zertifizierungsstelle nur den Prüfungsumfang in der
jeweiligen Siegelstufe bestätigen. Deshalb:
Prüfen Sie bitte bei Anerkennung eines „certified app“-Zertifikates, ob die
jeweilige Siegelstufe Ihren eigenen Erwartungen oder Standards genügt.
Weiteres zu den Siegelstufen ist beschrieben in Abschnitt 6.3.
Seite 10
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
2. Einordnung in den Gesamtkontext und mitgeltende Dokumente
Wie zuvor in Abschnitt 1 erläutert, wird das Prüf- und Zertifizierungsschema für mo-
bile Anwendungen in mehreren Dokumenten dargelegt:
--- datenschutz cert GmbH, „Prüfkonzept – Konzept zur Prüfung von Apps /
Kriterienkatalog für ‚certified app‘“, Version 1.0, 18.12.2015 [11];
--- datenschutz cert GmbH, „Prüfschema – Verfahrensbeschreibung zur Prü-
fung von Apps gemäß ‚certified app‘“, Version 1.0, 18.12.2015 (verfügbar für
Prüfstellen) [12];
--- datenschutz cert GmbH, „Zertifizierungsschema – Verfahrensbeschreibung
zur Zertifizierung von Apps gemäß ‚certified app‘“ (umgesetzt in der Zerti-
fizierungsstelle) [13];
--- datenschutz cert GmbH, „Prüfstelle – Anforderungen an eine Stelle zur Prü-
fung von Apps gemäß ‚certified app‘“, Version 1.0, 18.12.2015 (verfügbar für
Prüfstellen) [14];
--- datenschutz cert GmbH, „Zertifizierungsstelle – Anforderungen an eine
Stelle zur Zertifizierung von Apps gemäß ‚certified app‘“ (umgesetzt in der
Zertifizierungsstelle) [15].
Diese Dokumente definieren damit das Zertifizierungsprogramm, das unter dem Be-
griff
--- „certified app", Version 1
zusammenfassend bezeichnet wird.
Sie halten gerade das
--- datenschutz cert GmbH, „Prüfkonzept – Konzept zur Prüfung von Apps /
Kriterienkatalog für ‚certified app‘“, Version 1.0, 18.12.2015 [11]
in Ihren Händen, das den Anforderungen der Norm ISO/IEC 17067 [10] genügt.
Seite 11
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Die datenschutz cert GmbH ist der „Programmeigner“ für das Zertifizierungspro-
gramm „certified app", und damit u.a. für seine Entwicklung und Aufrechterhaltung
verantwortlich.
Bei Fragen oder Anregungen, freuen wir uns über Ihr Feedback:
------------------------------------ Dr. Sönke Maseberg datenschutz cert GmbH Konsul-Smidt-Str. 88a 28217 Bremen 0421/6966-3250 office@datenschutz-cert.de www.datenschutz-cert.de
Das Zertifizierungsprogramm „certified app" ist hervorgegangen aus dem Verbund-
projekts „ZertApps – Zertifizierte Sicherheit für mobile Anwendungen“, das vom
Bundesministerium für Bildung und Forschung (BMBF) gefördert wurde.
Seite 12
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
3. Einleitung zum Prüfkonzept gemäß „certified app“
Das Prüfkonzept beschreibt die
--- inhaltlichen Anforderungen an Apps sowie
--- das Prüfkonzept, damit sich ein Prüfer davon überzeugen kann, dass die
App die inhaltlichen Anforderungen erfüllt.
Das Prüfkonzept ist für Interessenten, App-Anbieter und Prüf- und Zertifizierungs-
stellen relevant; es beschreibt insgesamt, wie Apps geprüft und zertifiziert werden
sollen. Dazu enthält das Prüfkonzept Vorgaben, wie für eine zu prüfende App zu-
nächst der jeweils angemessene Sicherheitsmaßstab erstellt werden kann. Ferner
sind vier Siegelstufen angegeben.
Das Prüfkonzept ist wie folgt strukturiert:
--- Zunächst werden in Abschnitt 4 die Anforderungen an Apps zusammenge-
stellt. Diese Anforderungen können auf die verschiedenen Apps operatio-
nalisiert werden.
Ferner findet sich in diesem Abschnitt eine Liste von Einzelaspekten, wel-
che die Sicherheitserwartung nach aktuellem Stand der Technik darstellt.
Ein App-Anbieter kann diese Checkliste insbesondere nutzen, um sicherzu-
gehen, die wesentlichen Aspekte zur Sicherheit seiner App berücksichtigt
zu haben.
Die Sicherheitserwartung deckt Themen der IT und des Datenschutzes ab.
--- In einem Prüf- und Zertifizierungsverfahren muss der App-Anbieter des-
halb zunächst angeben, wie er der Sicherheitserwartung begegnet, d.h. es
ist darzulegen, wie die relevanten Aspekte dieser Checkliste in Form von Si-
cherheitsmaßnahmen umgesetzt werden; dieses Vorgehen wird in Ab-
schnitt 5 erläutert.
--- Abschnitt 6 befasst sich daran anschließend mit der Frage, wie Apps ge-
prüft werden können, bevor
--- in Abschnitt 0 die Zertifizierung einer App beschrieben wird.
--- Wie bereits angedeutet, lehnt sich das Prüfkonzept an anerkannte Kriteri-
enwerke an; ein Nachweis findet sich in Abschnitt 8.
--- Das Prüfkonzept wird schließlich in Abschnitt 9 mit dem Verzeichnis der
Referenzen beendet.
„certified app“ sieht die folgenden Rollen vor:
--- App-Anbieter: Bei dem Begriff des App-Anbieters handelt es sich zusam-
menfassend um die (juristische) Person, die die App verantwortlich anbie-
tet; typischerweise ist dies die juristische Person, die im App-Store und im
Impressum der App als Verantwortlicher genannt ist. Sofern der App-
Anbieter die App nicht selber entwickelt oder herstellt, muss der App-
Anbieter – als nach außen hin verantwortliche Instanz – Sorge dafür tra-
Seite 13
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
gen, die für die Zertifizierung benötigten Informationen zur Verfügung zu
stellen.
--- Zertifizierungsstelle für „certified app“: Anerkannte Zertifizierungsstelle,
die Apps gemäß des Zertifizierungsschemas [13] zertifiziert. Die Zertifizie-
rungsstelle erfüllt die Anforderungen aus [15].
--- Prüfstelle für „certified app“: Anerkannte Prüfstelle, die Apps gemäß des
Prüfschemas [12] prüft. Die Prüfstelle erfüllt die Anforderungen aus [14].
--- Evaluatoren oder Prüfer: Prüfer, die in einer anerkannten Prüfstelle tätig
sind.
--- Nutzer: Endanwender, welcher die App auf einem Smartphone oder Tablet
verwendet.
Seite 14
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
4. Anforderungen an eine App
Jede App ist anders! Die Sicherheitsanforderungen einer Taschenlampen-App sind
nicht zu vergleichen mit Anforderungen an eine Messenger-App. Deshalb ist zu-
nächst der Funktionsumfang der App zu identifizieren. An ihm orientiert sich der
spezifische Sicherheitsbedarf der App.
Sind Sicherheitsbedarf und mögliche Schwächen und Risiken geklärt, können daraus
spezifische Sicherheitsziele und -erwartungen abgeleitet werden, die schließlich den
Prüfmaßstab bilden.
Das Kapitel ist wie folgt strukturiert:
--- Abschnitt 4.1 thematisiert die App mit ihrem Funktionsumfang;
--- anschließend wird in Abschnitt 4.2 der Sicherheitsbedarf zusammenge-
stellt; hier werden Bedrohungen, rechtliche oder regulatorische Aspekte
sowie Annahmen an die Einsatzumgebung aufgenommen und Sicher-
heitszielen zugeordnet. Zusätzlich werden typische Sicherheitsschwächen
dargestellt, die dann wiederum in ergänzende Sicherheitsziele münden.
--- Diese Sicherheitsziele werden dann in Abschnitt 4.3 in Form einer Sicher-
heitserwartung abschließend dargelegt.
Wie oben bereits ausgeführt, deckt die Sicherheitserwartung Themen der IT und des
Datenschutzes ab.
4.1 Identifikation und Ist-Aufnahme des Funktionsumfangs einer App
Im ersten Schritt wird der Untersuchungsgegenstand – also die zu prüfende und zu
zertifizierende App – identifiziert und deren technische Details sowie der Funktions-
umfang in einer Ist-Aufnahme dargestellt.
4.1.1 Identifikation der zu zertifizierenden App
Dazu werden insbesondere die folgenden Informationen aufgenommen:
--- Identifikation der App:
--- Name der App;
--- Versionsnummer (android.versionName);
--- verantwortlicher App-Anbieter:
--- Name des Unternehmens;
--- Adresse (Straße/ Postfach, PLZ, Ort);
--- Kontaktdaten (Telefon, Fax, E-Mail, Webseite);
--- Identifikations-Daten (Umsatzsteuer-ID, Angaben zum Handelsregis-
ter), soweit vorliegend;
--- verantwortliche Entwickler:
--- Name;
Seite 15
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Kontaktdaten;
--- verantwortliche Ansprechpartner:
--- Name;
--- Kontaktdaten.
--- angestrebtes Prüfniveau:
--- Auswahl: Bronze, Silber, Gold, Platin, vgl. dazu Erläuterungen in Ab-
schnitt 6.3;
--- bei Re-Zertifizierung- oder Maintenance-Verfahren:
--- Angabe der bisherigen Zertifizierungs-ID (Zert-ID) „DSC.xxx“.
4.1.2 Ist-Aufnahme
Bei der Ermittlung technischer Details der App werden die folgenden Informationen
aufgenommen:
--- Bezugsquelle:
--- Auslieferungswege der App;
--- Betriebssysteme:
--- erforderliche Android-Versionen;
--- Bibliotheken:
--- Übersicht über die verwendeten Bibliotheken.
„certified app“ sieht das folgende Modell für eine Ist-Aufnahme der Funktionen einer
App vor:
--- Die zu zertifizierende App steht im Mittelpunkt der Betrachtung.
--- Typischerweise findet eine Datenverarbeitung innerhalb des Smartphones
oder Tablets statt, wobei die App auch Daten oder Ressourcen anderer
Apps oder des Betriebssystems nutzen kann. Ferner kann eine Datenüber-
mittlung an andere, externe Systeme erfolgen. Bezüglich einer Datenverar-
beitung oder -übermittlung ist zu beachten, ob personenbezogene Daten
im Sinne des Datenschutzrechts relevant sind.
--- Die App operiert auf einem Betriebssystem (nachfolgend auch Operating
System oder OS) und weist folgende logische Schnittstellen auf:
--- nach außen zu anderen Servern (etwa über das Internet via TCP/IP,
WLAN, NFC, Bluetooth etc.) oder zu anderen Geräten (beispielsweise in-
telligenten Zahnbürsten oder mobilen Gesundheitsmessgeräte);
--- intern zu anderen Apps;
--- intern zu anderen Ressourcen, etwa Kamera, Mikrophone, GPS-Daten,
Speicher, Gerätekennung, IMSI, IMEI etc.
Seite 16
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Ferner interagiert die App mit dem Nutzer über eine GUI (Graphical U-
ser Interface.
Abbildung 1 illustriert das Modell, das dem Prüfkonzept zugrunde liegt. Das Smart-
phone wird dabei auch stellvertretend für ein Tablet verwendet.
Abbildung 1: Modell
Bei der Ist-Aufnahme werden zur App die folgenden Informationen aufgenommen:
--- Art der App:
--- Beschreibung, um welche Art von App es sich handelt;
--- Funktionen:
--- Beschreibung des Funktionsumfangs;
--- verwendete Datenarten1:
--- Beschreibung der von der App verwendeten Datenarten2 samt Angabe
von: Name, Zweck, Speicherort sowie Datenkategorie. Es sind folgende
Datenkategorien/ Schutzbedarfs-Klassifikation vorgesehen:
1 Die identifizierten Datenarten werden durch Identifier gekennzeichnet, die mit „D“ beginnen. 2 Intention ist, dass unter „verwendete Datenarten“ angegeben wird, welche Arten von Daten die App verarbeitet, d.h. nutzt oder speichert. Bsp: Eine Taschenlampen-App wird vermutlich keine Daten verarbeiten, weil sie nur per Knopfdruck
Seite 17
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
DatKat01: keine Daten oder Daten ohne Schutzbedarf
DatKat02: Daten mit normalem Schutzbedarf
DatKat03: Daten mit hohem Schutzbedarf oder personenbezoge-
ne Daten
DatKat04: sensible personenbezogene Daten
Beispiele: IP-Adresse, Gerätekennungen, Name des Smartphones, Standort-
oder Audiodaten, Daten für biometrische Erkennungsverfahren, Informati-
onen über App-Nutzung.
Beispiele für DatKat04: Sensible personenbezogene Daten sind beispiels-
weise Angaben über rassische oder ethnische Herkunft, politische Meinun-
gen, religiöse oder philosophische Überzeugungen, Gewerkschaftszugehö-
rigkeit, Gesundheitsdaten.
--- verwendete Schnittstellen3:
--- Beschreibung der logischen Schnittstellen, welche die App unterstützt
oder benötigt (unter Berücksichtigung des o.g. Modells; Angaben: Name
der logischen Schnittstelle, Verwendungszweck, Ziel, relevante Daten
(als Auswahl aus den zuvor identifizierten Datenarten), Schutzbe-
darfskategorie (wird automatisch gefüllt), verwendetes Protokoll)
IntKat01: nach außen
IntKat02: intern zu anderen Apps
IntKat03: intern zu Ressourcen des Smartphones
IntKat04: GUI
--- Veränderungen seit letzter Prüfung (letzter ausgefüllter Selbstauskunft):
--- Beschreibung der Veränderungen an der App, die seit der letzten Prü-
fung/ Zertifizierung durchgeführt wurden. Die Beschreibung geht dabei
auf die Sicherheitsrelevanz der Veränderungen ein; nur relevant bei Re-
Zertifizierungs- und Maintenance-Verfahren.
Intention ist, dass der App-Anbieter diese Informationen in Form einer Selbstaus-
kunft angibt.
4.2 Sicherheitsbedarf einer App
Im nächsten Schritt wird der konkrete Sicherheitsbedarf zusammengestellt. Dies er-
folgt in mehreren Schritten. Zunächst werden erfasst:
--- Bedrohungen;
Licht „spendet“. Wird aus Sponsoring-Gründen zusätzlich dort Werbung eingeblendet, könnte die Datenart „Werbung“ definiert werden. Wird zusätzlich per GPS der Standort des Gerätes kommuniziert, um etwa standortbezogene Werbung darstellen zu können, könnte die weitere Datenart „Lokalisierungsdaten“ definiert werden. Wichtig: Datenarten sollen ei-ne Gruppe von Daten beschreiben, so dass nicht jedes Datenelement einzeln beschrieben werden muss, etwa Datenart „Adressdaten“, was Straße, Ort, Telefonnummer und E-Mail-Adresse umfassen kann. 3 Die identifizierten Schnittstellen (Interfaces) werden durch Identifier gekennzeichnet, die mit „I“ beginnen.
Seite 18
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- rechtliche oder regulatorische Anforderungen;
--- Annahmen an Betrieb und Einsatzumgebung.
Ausgehend von den Angaben der Ist-Aufnahme (insbesondere Art der Daten oder Ka-
tegorie der App) werden dazu typische Bedrohungen und grundsätzliche rechtliche
Anforderungen automatisiert vorgegeben. Diese automatisierten Vorbelegungen
lassen sich manuell korrigieren oder ergänzen, wobei entsprechende Begründungen
nachzutragen sind. Ferner können – falls relevant – auch Hinweise oder Auflagen an
den Benutzer angegeben werden.
Daraus werden Sicherheitsziele abgeleitet. Dies erfolgt automatisiert, lässt sich aller-
dings manuell korrigieren oder ergänzen, ebenfalls mit entsprechenden Begründun-
gen.
Zusätzlich werden Sicherheitsschwachstellen thematisiert. Zwar reichen grundsätz-
lich Maßnahmen zu den Sicherheitszielen aus, um den zuvor identifizierten Bedro-
hungen und rechtlichen Anforderungen hinreichend zu begegnen. Aus Erfahrung
lässt sich aber sagen, dass häufig Fehler in der Implementierung oder Schwachstel-
len in der Realisierung auftreten, etwa bezüglich der Umgebung von Sicherheits-
funktionalitäten. Aus diesem Grund werden hier auch Sicherheitsschwächen thema-
tisiert, um in konsolidierten Sicherheitszielen diese wichtigen Punkte adressieren zu
können.
Intention ist, dass der App-Anbieter diese Informationen in Form einer Selbstaus-
kunft validiert und ggf. ergänzt.
4.2.1 Bedrohungen
„certified app“ geht von folgenden Bedrohungen aus4:
B01: Nicht gerechtfertigte Nutzung von Ressourcen5, etwa die GPS-Funktionalität,
die Kamera, das Mikrophon oder den Datenspeicher, d.h. die App greift auf
Ressourcen zu, ohne dass hierfür eine hinreichende Rechtfertigung oder Be-
rechtigung (Permission) vorliegt.
B02: Nicht gerechtfertigter Zugriff auf andere Apps, d.h. die App greift auf andere
Apps zu, ohne dass hierfür eine hinreichende Rechtfertigung oder Berechti-
gung (Permission) vorliegt.
B03: Unberechtigter Nutzer greift auf die zu zertifizierende App zu.
B04: Eine andere App greift auf die zu zertifizierende App bzw. ihre Daten zu.
B05: Verlust der Vertraulichkeit der Kommunikation, d.h. die Kommunikation der
App nach außen kann mitgehört werden.
4 Grundsätzlich gilt hierbei, dass nur diejenigen Bedrohungen relevant sind, für die eine entsprechende Funktionalität vorhanden ist. 5 Ressourcen umfassen bspw. Kontakte im Telefonbuch, Anruflisten, Kalendereinträge, Adressbücher, E-Mails, Surfverhal-ten; gerätespezifische Daten (IMSI, IMEI), Bilder, Notizen, Audioaufzeichnungen, Finanzen (Prepaid-Guthaben), Schlüssel oder Standortdaten.
Seite 19
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
B06: Verlust der Authentizität der Kommunikation, d.h. die App kommuniziert mit
einem Server, der nicht der intendierte ist.
B07: Verlust der Integrität der Kommunikation, d.h. die Kommunikation der App
nach außen kann manipuliert werden.
B08: Es findet eine Kommunikation nach außen statt, ohne dass hierfür eine hinrei-
chende Rechtfertigung oder Berechtigung vorliegt.
B09: Ergänzende Bedrohungen, ausfüllbar durch App-Anbieter samt Begründung.
4.2.2 Rechtliche oder regulatorische Anforderungen
„certified app“ berücksichtigt folgende rechtlichen und regulatorischen6 Anforde-
rungen7:
R01: Werden personenbezogene Daten verarbeitet, sind regelmäßig datenschutz-
rechtlichen Bestimmungen einschlägig.
R02: Werden sonstige Daten verarbeitet, können spezielle rechtliche Bestimmun-
gen oder aber spezifische Richtlinien von Unternehmen, Behörden und Institu-
tionen einschlägig sein.
R03: Ergänzende Anforderungen, ausfüllbar durch App-Anbieter samt Begründung.
4.2.3 Annahmen an Betrieb und Einsatzumgebung
„certified app“ berücksichtigt folgende Annahmen an Betrieb und Einsatzumge-
bung8:
A01: Betriebssystem ist Android.
A02: Das Smartphone oder Tablet, auf dem die App betrieben wird, ist vertrauens-
würdig. Das Android-Betriebssystem wird als sicher angesehen.
A03: Erfolgt eine Kommunikation der App nach außen, ist der korrespondierende
Server vertrauenswürdig. Die Kommunikation zum Server wird betrachtet, der
Server aber selber nicht.
A04: Der Nutzer ist vertrauenswürdig.
A05: Die App unterstützt keinen dynamischen Code.
Das Nachladen dynamischen Codes, bei dem die zu zertifizierende App ledig-
lich die „Hülle“ aufweist – durch welche die eigentliche App dynamisch nach-
geladen wird –, enthält nicht die nach außen angegebene Funktionalität.
Dadurch kann der Endnutzer möglicherweise nicht zwischen einer App, die le-
6 Während für rechtliche Anforderungen ein Gesetz oder eine Verordnung die Grundlage bildet, können weitere regulato-rische Anforderungen gelten, die etwa aus Unternehmensrichtlinien resultieren. 7 Grundsätzlich gilt hierbei, dass nur diejenigen rechtlichen Anforderungen relevant sind, für die eine entsprechende Funktionalität vorhanden ist. Dabei wird in diesem Konzept davon ausgegangen, dass die rechtlichen Grundlagen solche der Rechtsordnung der Bundesrepublik Deutschland (BRD) sowie solche der Europäischen Union sind, sofern diese direkte Geltung in der BRD entfalten. 8 Hintergrund ist, dass die App typischerweise keine Möglichkeit hat, ihre Sicherheitsmechanismen vollumfänglich umzu-setzen, wenn diese Annahmen nicht eingehalten werden. Annahmen können entfernt werden, aber es können keine wei-teren Annahmen hinzugefügt werden.
Seite 20
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
diglich die Hülle simuliert, und einer App, welche die eigentliche Funktionalität
erbringt, unterscheiden. Von daher besteht die Gefahr, dass die zertifizierte
App, mit einer nicht zertifizierten Funktionalität verwechselt wird. Um Miss-
brauch auszuschließen, sind Apps mit dynamischem Code gegenwärtig daher
nicht zertifizierbar. Dies umfasst damit auch WebView.
A06: Die App ist durch automatische Tools testbar, d.h. sie weist insbesondere keine
Obfuskation, Härtung oder nativen Code auf.9
4.2.4 Sicherheitsschwächen
„certified app“ geht von folgenden Sicherheitsschwächen aus, die berücksichtigt
werden sollen:10
V01: Mängel in der Implementierung.11
V02: Übernahme von Benutzersitzungen.
4.2.5 Abgeleitete Sicherheitsziele
Ausgehend von den Bedrohungen und rechtlichen Anforderungen leitet „certified
app“ unter Berücksichtigung der Annahmen an Betrieb und Einsatzumgebung sowie
die genannten Sicherheitsschwächen die folgenden Sicherheitsziele ab:12
S01: Zugriffe/ Berechtigungen auf Ressourcen des Smartphones oder Tablets sind
hinreichend gerechtfertigt.
S02: Zugriffe/ Berechtigungen auf andere Apps sind hinreichend gerechtfertigt.
S03: Zugriff auf die App erfordert eine Authentisierung.
S04: Die App schützt sich bzw. ihre Daten selber aktiv vor fremden Zugriff.
S05: Vermeidung der Speicherung von Daten und Schlüsseln an öffentlich lesbaren
Orten (Quellcode, SD-Karte, etc.).
S06: Die Kommunikation der App mit Servern in der Außenwelt erfolgt verschlüs-
selt mit hinreichender Prüfung der Serveridentität (zur Sicherstellung von Ver-
traulichkeit, Integrität und Authentizität).
S07: Datenschutz-Anforderungen werden umgesetzt.
S08: Es wurde geprüft, ob – und wenn ja, welche – weiteren speziellen rechtlichen
oder regulatorischen Bestimmungen einschlägig sind.
9 Bei Siegelstufen Gold und Platin kann diese Annahme entfallen, da hier die App mit erweiterten Analysewerkzeugen, ggf. auch auf Quellcode-Basis, evtl. direkt beim Entwickler, geprüft werden kann. In einem solchen Fall ist die Zertifizie-rungsstelle zu Rate zu ziehen. 10 Wie oben bereits ausgeführt, reichen grundsätzlich Maßnahmen zu den Sicherheitszielen aus, um den zuvor identifi-zierten Bedrohungen und rechtlichen Anforderungen hinreichend zu begegnen. Aus Erfahrung lässt sich aber sagen, dass häufig Fehler in der Implementierung oder Schwachstellen in der Realisierung auftreten. Aus diesem Grund werden hier auch Sicherheitsschwächen thematisiert, um in konsolidierten Sicherheitszielen diese wichtigen Punkte adressieren zu können. 11 Diese Sicherheitsschwäche wurde im ZertApps-Verbundprojekt umfangreich analysiert – etwa zu Programmierschwä-chen im Android-Framework. Sodann wurden im ZertApps-Projekt hieraus ZertApps-Tools entwickelt, die diese Schwä-chen detektieren können, vgl. Sicherheitserwartung E13. Die Sicherheitsschwächen thematisieren dabei auch typische An-griffsszenarien auf das Android-Framework. 12 Grundsätzlich gilt, dass nur diejenigen Sicherheitsziele relevant sind, für die entsprechende Bedrohungen oder rechtli-che Anforderungen vorhanden sind.
Seite 21
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
S09: Anwendbare spezielle rechtliche oder regulatorische Bestimmungen werden
umgesetzt.
S10: Zugriffe auf die Außenwelt sind hinreichend gerechtfertigt.
S11: Ergänzende Sicherheitsziele aus ergänzender Bedrohung B09 oder ergänzen-
der rechtlichen Anforderung R03, ausfüllbar durch App-Anbieter samt Begrün-
dung.
S12: Nutzung vertrauenswürdiger Quellen zur Implementierung von Sicherheits-
funktionalitäten.
S13: Nutzung vertrauenswürdiger und authentischer Sourcen.
S14: Durchführung unabhängiger13 Tests, inklusive Penetrationstests.
S15: Durchführung von Code-Reviews und automatisierten Quellcodeprüfungen
nach bekannten Mustern (Implementierungsschwachstellen, Tracker).
S16: Beachtung von Entwickler-Guidelines und Sicherheitshinweisen (Security Ad-
visorys).
4.3 Sicherheitserwartung
Die Sicherheitserwartung gibt an, welche Features die zu zertifizierende App hin-
sichtlich Datenschutz und IT-Sicherheit aufweisen muss.14
Ausgehend vom Sicherheitsbedarf werden schließlich die Anforderungen an die App
extrahiert. Diese Sicherheitserwartung ergibt sich direkt aus dem Sicherheitsbedarf;
sie wird automatisiert vorgegeben, kann aber manuell korrigiert oder ergänzt wer-
den, jeweils mit entsprechenden Begründungen.
Intention ist, dass der App-Anbieter die Sicherheitserwartung in Form einer Selbst-
auskunft validiert und ggf. ergänzt.
Hinweis: Die Sicherheitserwartung orientiert sich am Funktionsumfang der zu zerti-
fizierenden App, den Sicherheitszielen sowie dem Prüfniveau.
4.3.1 E01 Zugriff auf Ressourcen und Apps
Alle Zugriffe/ Berechtigungen der App auf Ressourcen im Smartphone oder Tablet
sowie auf andere Apps sind
--- abschließend dargelegt und
--- nachweisbar plausibel begründet.
Diese Zugriffe sind restriktiv, d.h. für den originären Funktionsumfang der App abso-
lut notwendig; es sind keine Alternativen möglich.
13 Tests sollten insbesondere nicht vom Entwickler durchgeführt werden, um die Unabhängigkeit nicht zu gefährden. 14 Grundsätzlich gilt, dass nur diejenigen Aspekte der Sicherheitserwartung relevant sind, für die entsprechende Sicher-heitsziele vorhanden sind.
Seite 22
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Vorhandene Schnittstellen der Kategorien IntKat2 (intern zu anderen Apps) und
IntKat3 (intern zu Ressourcen des Smartphones oder Tablets) sind berücksichtigt.
Ferner wird Bezug genommen auf die verwendeten Datenarten.
4.3.2 E02 Authentisierung
Ein Nutzer muss sich an der App authentisieren.
4.3.3 E03 Kennwort-Policy
Die App setzt eine Kennwort-Policy durch, mit
--- mind. 8 Zeichen;
--- Sperrung bei Fehlauthentisierung.
4.3.1 E04 Selbstschutz
Die App schützt sich bzw. ihre Daten selber durch kryptographische Mechanismen,
etwa durch eigen-implementierte Mechanismen oder den Aufruf der Krypto-API.
Eingehende Daten und Nutzereingaben werden gefiltert.
4.3.1 E05 Sichere Datenablage
Daten und Schlüssel werden nicht an öffentlich lesbaren Orten (Quellcode, SD-Karte,
etc.) abgelegt.
4.3.2 E06 Kommunikation
Alle Zugriffe der zu zertifizierenden App auf externe Systeme15 außerhalb des Smart-
phone oder Tablets sind
--- abschließend dargelegt und
--- nachweisbar plausibel begründet.
Diese Zugriffe sind restriktiv, d.h. für den originären Funktionsumfang der App abso-
lut notwendig; es sind keine Alternativen möglich.
Vorhandene Schnittstellen der Kategorie IntKat1 (nach außen) sind berücksichtigt.
Ferner wird Bezug genommen auf die verwendeten Datenarten.
4.3.3 E07 Kryptographische Verfahren
Es werden geeignete kryptographische Verfahren verwendet. Hierbei gilt folgendes:
--- Es gibt eine Übersicht über
--- die eingesetzten kryptographischen Verfahren,
--- ihren Zweck,
--- die eingesetzten Parameter und Schlüssellängen sowie
--- den relevanten Standard.
15 Externe Systeme sind beispielsweise andere Server oder andere Geräten (etwa intelligenten Zahnbürsten oder mobile Gesundheitsmessgeräte.
Seite 23
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Die kryptographischen Verfahren mit ihren verwendeten Parametern sind
anerkannt sicher, d.h. von einer anerkannten Instanz empfohlen, etwa laut
Algorithmenkatalog der Bundesnetzagentur (BNetzA) [6] oder anhand der
TR-02102 des Bundesamtes für Sicherheit in der Informationstechnik (BSI)
[7].
4.3.4 E08 Kommunikationsprotokolle
Es werden geeignete Protokolle verwendet. Hierbei gilt folgendes:
--- Es gibt eine Übersicht über
--- die verwendeten Protokolle,
--- ihren Zweck sowie
--- die relevanten Standards.
--- Ferner wird der Nachweis der Eignung erbracht.
4.3.5 E09 Schlüsselmanagement
Das Schlüsselmanagement der App stellt sicher, dass zuverlässig mit den intendier-
ten Systemen kommuniziert wird, d.h. bei einer verschlüsselten Kommunikation zu
einem Server stellt die App sicher, dass der zugehörige Schlüssel sicher verwahrt
wird.
Darüber hinaus stellt die App bezüglich ihrer eigenen (Schlüssel-)Identität sicher,
dass ihre eigenen Schlüssel sicher verwahrt werden.
Die Schlüssel der App werden nicht an öffentlich lesbaren Orten gespeichert.
4.3.6 E10 Authentisierung
Werden zur Authentisierung ggü. Servern Credentials des Nutzers übermittelt – typi-
scherweise Benutzername und Passwort – wird sichergestellt, dass
--- die Kommunikation verschlüsselt erfolgt, und
--- das Passwort nicht im Klartext übermittelt wird.
Zur sicheren Übermittlung des Passwortes wird ein anerkanntes Verfahren einge-
setzt.
4.3.7 E11 Datenschutz
Standard-Anforderungen des Datenschutzes16 werden umgesetzt:
--- Die datenschutzrechtliche Zulässigkeit der Datenverarbeitung ist geprüft
worden. (Hinweis: Im Rahmen eines Prüfverfahrens wird nicht die Zuläs-
sigkeit einer App geprüft; es wird aber geprüft, ob der App-Anbieter die Zu-
lässigkeit geprüft hat.)
16 Grundsätzlich gilt hierbei, dass nur diejenigen rechtlichen Anforderungen relevant sind, für die eine entsprechende Funktionalität vorhanden ist. Dabei wird in diesem Konzept davon ausgegangen, dass die rechtlichen Grundlagen solche der Rechtsordnung der Bundesrepublik Deutschland (BRD) sowie solche der Europäischen Union sind, sofern diese direkte Geltung in der BRD entfalten.
Seite 24
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Die Datenverarbeitung ist datenschutzrechtlich zulässig; eine entspre-
chend aussagekräftige und nachvollziehbare Begründung liegt vor (Erfor-
derlichkeit der Datenverarbeitung).
--- Sofern zur Zulässigkeit der Datenverarbeitung eine Einwilligung des Nut-
zers eingeholt werden muss, ist dies rechtlich wirksam erfolgt. Einschlägige
rechtliche Kriterien sind umgesetzt worden. Der Nutzer kann seine Einwil-
ligung jederzeit rückgängig machen.
--- Datenschutzrechtliche Prinzipien werden beachtet und umgesetzt:
--- Grundsatz der Datenerhebung (beim Betroffenen);
--- Datenvermeidung;
--- Datensparsamkeit;
--- Zweckbindung;
--- Erforderlichkeit;
--- Transparenz;
--- anonyme und pseudonyme Nutzung;
--- „Privacy by Default“ für datenschutz-freundliche Voreinstellungen.
--- Nutzer können ihre Betroffenenrechte geltend machen (Nutzerrechte). Bei
widerrufener Einwilligung oder auf explizite Anforderung des Nutzers hin,
werden alle erhobenen Daten lokal und extern gelöscht, soweit dies nicht
gegen andere gesetzliche Bestimmungen verstößt.
--- Anbieterkennzeichnung (Impressum) und Informationen zur Datenverar-
beitung (Datenschutzerklärung) sind vorhanden und entsprechen den An-
forderungen, insbesondere denen des Telemediengesetzes.
--- Die App ist korrekt gekennzeichnet, d.h. bezeichnet die App (exakte Be-
zeichnung der App und Versionsnummer (android.versionName)) sowie
den App-Anbieter.
--- Kontaktmöglichkeiten sind gegeben.
--- Der Nutzer wird über die Datenverarbeitung angemessen informiert (Un-
terrichtung); die Informationen zur Datenverarbeitung umfasst alle ver-
wendeten Datenarten und alle implementierten Schnittstellen.
Spezielle datenschutzrechtliche Anforderungen werden – soweit relevant – umge-
setzt:
--- Der Nutzer wird vorab über Dienste Dritter, wie z.B. Tracker, Werbung, dem
Versenden von Debugging-Informationen oder der Erhebung von Statisti-
ken informiert.
Seite 25
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
4.3.8 E12 Spezielle Bestimmungen
Es wurde geprüft, ob – und wenn ja, welche – weiteren speziellen rechtlichen oder
regulatorischen Bestimmungen einschlägig sind; eine entsprechend aussagekräftige
und nachvollziehbare Begründung liegt vor.
Entsprechende rechtliche oder regulatorische Bestimmungen werden umgesetzt.
4.3.9 E13 Implementierung
Sofern eine Sicherheitsfunktionalität vom App-Anbieter entwickelt oder implemen-
tiert wird, müssen hierfür vertrauenswürdige Quellen genutzt werden.
Bei Einbindung anderer Sourcen muss sichergestellt sein, dass nur ein vertrauens-
würdiger, integrer und authentischer Code verwendet wird.
Entwickler-Guidelines und Sicherheitshinweise (Security Advisory) werden beachtet,
etwa Secure Coding Guide developer.android.com.
4.3.10 E14 Unabhängige Tests
Die App wird unabhängig, d.h. insbesondere nicht vom Entwickler, getestet. Die Tests
umfassen Penetrationstests.
Die Testergebnisse fließen in die App-Entwicklung ein.
4.3.11 E15 Code-Review
Die App wird einem Code-Review unterzogen. Es kommen automatisierte Quellcode-
prüfungen nach bekannten Mustern (Implementierungsschwachstellen, Tracker)
zum Einsatz.
Es werden statische und dynamische Analysemethoden durchgeführt.
Die Ergebnisse fließen in die App-Entwicklung ein.
4.3.12 E16 Entwicklungs-/ Produktionsumgebung
Der Entwicklungs-/ Produktionsprozess ist insgesamt geregelt. Dabei sind für die
Entwicklungs-/ Produktionsumgebung folgende Maßnahmen umgesetzt, um insbe-
sondere die Integrität und Authentizität der auszuliefernden App zu gewährleisten:
--- organisatorische und personelle Vorgaben;
--- technisch-organisatorische Maßnahmen;
--- Freigabeverfahren.
Für eine geeignete Entwicklungs- und Produktionsumgebung liegen anerkannte
Normen und Standards vor, die genutzt werden können, die „certified app“ jedoch
nicht zwingend vorschreibt. Als sinnvoll werden beispielsweise erachtet:
--- ein Informationssicherheits-Managementsystem (ISMS) gemäß ISO/IEC
27001 oder ISO 27001 auf der Basis von IT-Grundschutz;
--- ein IT-Service-Management auf Basis von ITIL gemäß ISO/IEC 20000-1;
--- ein Qualitäts-Managementsystem gemäß ISO/IEC 9001.
Seite 26
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Auch weitere, an die ISO/IEC 27001 angelehnte Managementsysteme, die besondere
Aspekte zur Anwendungssicherheit (Application Security) thematisieren – wie etwa
ISO/IEC 27034 – können sinnvollerweise vom App-Anbieter genutzt und herangezo-
gen werden; „certified app“ schreibt diese Normen jedoch nicht zwingend vor.
Sofern bereits ein Zertifikat vorliegt, kann auch auf diese Dokumentation und Zertifi-
kate verwiesen werden; dies kann den Prüf- und Zertifizierungsaufwand verkürzen.
Im Nachfolgenden sind typische Anforderungen für eine sichere Entwicklungs-und
Produktionsumgebung aufgeführt. Die Auflistung ist nicht abschließend und kann
selbstverständlich ergänzt und erweitert werden.
Für ein Prüf- und -Zertifizierungsverfahren in Siegelstufe „Platin“ wird erwartet, dass
mindestens zu den nachfolgenden Anforderungen Aussagen vom App-Anbieter ein-
gereicht werden – entweder direkt auf die Fragen oder in einer separaten Dokumen-
tation, etwa einem Sicherheitskonzept.
Die Anforderungen gelten für alle relevanten Standorte des App-Life-Cycles, d.h. an
allen Standorten, an denen die zu zertifizierende App entwickelt, produziert und aus-
geliefert wird.
Ist-Aufnahme: Im Rahmen der Ist-Aufnahme werden zunächst alle Zielobjekte identi-
fiziert, die für die Entwicklung und Produktion der zu zertifizierenden App relevant
sind:
--- Standorte mit Angabe der Relevanz für den App-Life-Cycle;
--- pro Standort:
--- Gebäude;
--- Räume;
--- Mitarbeiter;
--- IT-Systeme;
--- Anwendungen/ Verfahren.
--- Organigramm/ Organisationsstruktur.
Identifikation der zu schützenden Werte:
--- Identifizieren Sie bitte die zu schützenden Werte (Assets).
--- Angabe des Schutzbedarfs bzgl. der Schutzwerte Vertraulichkeit, Integrität,
Verfügbarkeit.
Umgesetzte Sicherheitsmaßnahmen: Beschreiben Sie bitte für alle o.g. Standorte die
angewendeten Sicherheitsmaßnahmen, insbesondere:
--- Zutrittskontrollen (Raum- und Gebäudesicherheit), z.B.:
--- Sicherung von Türen, Fenstern, Schlössern (ggf. Token)
--- Raumaufteilung (Gefahrenabschnitte, Unternehmensbereiche)
--- Alarmanlage
Seite 27
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Diebstahlsicherungen, z.B.:
--- Gerätesicherung
--- Schutzschränke (Dokumente / Datenträger / IT-Systeme)
--- Zutrittsregelungen (z.B. für Bereiche Entwicklung, Serverraum, Verteiler-
räume)
--- Besucherregelung
--- Sicherung von Türen und Fenstern während und außerhalb der Arbeitszei-
ten
--- Schlüsselverwaltung (ggf. inklusive Token)
--- Einarbeitung neuer Mitarbeiter
--- Zugangskontrollen (IT-Systemen/Anwendungen)
--- Geregelte Verfahrensweise beim Ausscheiden von Mitarbeitern (Entzug
von Zugriffsrechten einschließlich Schlüssel und ggf. Token)
--- Entnahme und sichere Aufbewahrung von Schutzwerten (Materi-
al/Information) aus der Entwicklungsumgebung, z.B. für:
--- Kundenberatung / -präsentation
--- Arbeit an anderen Plätzen (auf Reise, Heimarbeit)
--- Mobile Arbeitsplätze (PDA, Mobiltelefon, Laptop)
--- Ordnungsgemäße Entsorgung von schützenswerten Betriebsmitteln
--- Festlegung vom Rollen und Verantwortlichkeiten zur Sicherstellung der
fortlaufenden Anwendung der Sicherheitsmaßnahmen und zum Aufde-
cken von Sicherheitslücken
--- Regelungen bezüglich Arbeitsplatz und Arbeitsumgebung (einschließlich
mobiler Arbeitsplätze)
--- Geeignete Aufbewahrung dienstlicher Unterlagen und Datenträger
--- Reaktion / Dokumentation bei Sicherheitsvorfällen
--- Weiterbildung / Information aller Mitarbeiter (Programme, IT-
Sicherheitsmaßnahmen…)
--- Sicherheitsüberprüfung von neuem Entwicklungspersonal
--- Auswahl eines vertrauenswürdigen Administrators und Vertreters
--- Qualifizierte, geregelte Vertretung
--- Vertraulichkeitsvereinbarungen
--- Netzwerksicherheit
--- Datensicherung
--- Schutz vor schadhafter Software
Seite 28
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Entwicklungswerkzeuge
--- Outsourcing
--- Einsatz von Subunternehmen
Konfigurations-Management:
--- Die App muss eindeutig referenziert werden.
--- Prozessbeschreibung zur eindeutigen Versionierung von Apps:
--- Rollen und Verantwortlichkeiten
--- Freigabeprozeduren
--- Zugangs- und Zugriffskontrollprozeduren
--- Umgang mit gleichzeitigen Änderungen an Elementen der Konfigurati-
onsliste
Auslieferung:
--- Beschreibung, wie sichergestellt wird, dass die geprüfte und zertifizierte
App authentisch und unverändert ausgeliefert wird - etwa an den App-
Store.
Da die Selbstauskunft [17] vorrangig die App darstellt, soll die Darstellung der Ent-
wicklungs- und Produktionsumgebung separat dokumentiert werden.
4.3.13 E17 Weitere Sicherheitserwartungen
Unter E17 werden Sicherheitserwartungen ergänzt, die sich aus dem ergänzenden Si-
cherheitsziel S11 ergeben. Der App-Anbieter füllt diese Ergänzungen samt Begrün-
dung aus.
Seite 29
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
5. Darlegung der Sicherheitsfeatures der App
Welche Funktionalitäten sind in der zu zertifizierenden App implementiert? Welche
Sicherheitsfeatures der App decken die zuvor identifizierte Sicherheitserwartung ab?
Welche zusätzlichen Sicherheits-Funktionalitäten sind enthalten? Und warum?
Diese Fragen werden in diesem Kapitel beleuchtet.
Intention ist, dass der App-Anbieter
--- seine implementierten Sicherheitsfeatures beschreibt,
--- nachweist, dass alle Aspekte zur Sicherheitserwartung abgedeckt sind,
--- nachweist, dass auch etwaige rechtliche Aspekte begründet sind, sowie
--- erläutert, welche zusätzlichen Funktionalitäten aus welchem Grund ent-
halten sind.
Dazu soll der App-Anbieter zu allen o.g. Aspekten der Sicherheitserwartung Stellung
beziehen:
--- E01 Zugriff auf Ressourcen und Apps
--- E02 Authentisierung
--- E03 Kennwort-Policy
--- E04 Selbstschutz
--- E05 Sichere Datenablage
--- E06 Kommunikation
--- E07 Kryptographische Verfahren
--- E08 Kommunikationsprotokolle
--- E09 Schlüsselmanagement
--- E10 Authentisierung
--- E11 Datenschutz
--- E12 Spezielle Bestimmungen
--- E13 Implementierung
--- E14 Unabhängige Tests
--- E15 Code-Review
--- E16 Entwicklungs-/ Produktionsumgebung
--- E17 Weitere Sicherheitserwartungen
Seite 30
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
6. Prüfung einer App
Wie tief soll geprüft werden, ob die Sicherheitsfeatures der App zur Realisierung der
Sicherheitserwartung adäquat umgesetzt sind? Reicht eine Selbstauskunft? Muss ein
Evaluator den Source-Code untersuchen? Ist die Entwicklungsumgebung relevant,
um sicherzustellen, dass die geplanten Sicherheitsfeatures auch tatsächlich in die
auszuliefernden Apps implementiert wurden?
Die Antwort, welche Prüftiefe angemessen ist, hängt insbesondere von zeitlichen
und finanziellen Ressourcen, sowie dem Schutzbedarf der App ab. Deshalb sieht „cer-
tified app“ verschiedene Prüftiefen vor, in denen unterschiedliche Prüfungen kombi-
niert sind.
Im Nachfolgenden sind die verschiedenen Prüfungsarten sowie Siegelstufen aufge-
führt.
6.1 Prüfungsarten
Für „certified app“ kommen verschiedene Arten der Prüfung (auch Prüfungsmetho-
den) in Betracht.
6.1.1 Selbstauskunft
Eine erste Stufe der Prüfung ist eine Selbstauskunft des App-Anbieters zu allen rele-
vanten Aspekten. Intention der Selbstauskunft als Prüfungsart ist, dass der App-
Anbieter den Funktionsumfang der App, den Sicherheitsbedarf, die Sicherheitserwar-
tungen und die Sicherheitsfeatures in einer strukturierten Art und Weise darlegt und
diese rechtlich sanktionierbar garantiert, so dass sich der Prüfer hieraus ein eigenes
Bild von der Sicherheit der App verschaffen kann.
Bei der Selbstauskunft werden folgende Aspekte beschrieben:
--- Identifikation:
--- Identifikation der App, vgl. Abschnitt 4.1.1;
--- App-Anbieter, vgl. Abschnitt 4.1.1;
--- verantwortliche Entwickler, vgl. Abschnitt 4.1.1;
--- verantwortlicher Ansprechpartner, vgl. Abschnitt 4.1.1;.
--- angestrebtes Prüfniveau, vgl. Abschnitt 4.1.1;
--- Zert-ID bei Re-Zertifizierung, vgl. Abschnitt 4.1.1;
--- Ist-Aufnahme:
--- Beschreibung von technischen Details der App, vgl. Abschnitt 4.1.2:
Bezugsquelle: Auslieferungswege der App;
Betriebssystem: Android (fest vorgegeben);
Betriebssystem-Version: erforderliche Android-Versionen (derzeit sieht
„certified app“ nur Android als Betriebssystem vor);
Bibliotheken: verwendete Bibliotheken;
Seite 31
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Ist-Aufnahme der App, vgl. Abschnitt 4.1.2:
Art der App: Beschreibung, um welche Art von App es sich handelt;
Funktionen: Beschreibung des Funktionsumfangs;
Verwendete Datenarten: Beschreibung der verwendeten Datenarten
samt Angabe von: Name, Zweck, Speicherort sowie Datenkategorie. Es
sind folgende Datenkategorien/ Schutzbedarfs-Klassifikation vorgese-
hen:
DatKat01 keine Daten oder Daten ohne Schutzbedarf
DatKat02 Daten mit normalem Schutzbedarf
DatKat03 Daten mit hohem Schutzbedarf oder personenbezoge-
ne Daten
DatKat04 sensible personenbezogene Daten
Verwendete Schnittstellen: Beschreibung der logischen Schnittstellen,
welche die App unterstützt oder benötigt (Angaben: Name der logi-
schen Schnittstelle, Verwendungszweck, Ziel, relevante Daten, Schutz-
bedarfskategorie, verwendetes Protokoll)
IntKat01 zu anderen Systemen außerhalb des Smartphones oder
Tablets
IntKat02 intern zu anderen Apps
IntKat03 intern zu Ressourcen des Smartphones oder Tablets
IntKat04 GUI
Veränderungen seit letzter Prüfung (letzter ausgefüllter Selbstaus-
kunft): Beschreibung der Veränderungen an der App, die seit der letzten
Prüfung/ Zertifizierung durchgeführt wurden. Die Beschreibung geht
dabei auf die Sicherheitsrelevanz der Veränderungen ein; nur relevant
bei Re-Zertifizierungsverfahren.
--- Sicherheitsbedarf:
--- Ergänzungen hinsichtlich weiterer Bedrohungen, vgl. B09 in Abschnitt
4.2.1 (sofern anwendbar);
--- Ergänzungen hinsichtlich spezieller rechtlicher oder regulatorischer
Bestimmungen, vgl. R03 in Abschnitt 4.2.2 (sofern anwendbar);
--- Ergänzungen zu Sicherheitszielen, vgl. S11 in Abschnitt 4.2.5 (sofern an-
wendbar);
--- Sicherheitserwartung:
--- Ergänzung zu Sicherheitserwartung E17, vgl. Abschnitt 4.3.13 (sofern
anwendbar);
--- App-Sicherheitsfeatures:
Seite 32
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Darlegung, wie alle Aspekte der Sicherheitserwartung aus Abschnitt 4.3
umgesetzt werden, vgl. Abschnitt 5:
E01 Zugriff auf Ressourcen und Apps
E02 Authentisierung
E03 Kennwort-Policy
E04 Selbstschutz
E05 Sichere Datenablage
E06 Kommunikation
E07 Kryptographische Verfahren
E08 Kommunikationsprotokolle
E09 Schlüsselmanagement
E10 Authentisierung
E11 Datenschutz
E12 Spezielle Bestimmungen
E13 Implementierung
E14 Unabhängige Tests
E15 Code-Review
E16 Entwicklungs-/ Produktionsumgebung
E17 Weitere Sicherheitserwartungen
Die Selbstauskunft selber wird formal geprüft; und die Angaben werden inhaltlich
überprüft.
Um einen Missbrauch durch den App-Anbieter zu verhindern, wird die Selbstaus-
kunft daher rechtsverbindlich vom App-Anbieter erklärt. Um der damit ausgespro-
chenen Garantie des App-Anbieters eine verbindliche und rechtlich sanktionierbare
Wirkung zu verleihen, wird der App-Anbieter anhand von Allgemeinen Geschäftsbe-
dingungen (AGB) der Zertifizierungsstelle an die Garantiewirkung gebunden. Falsche
Angaben führen zu rechtlich durchsetzbaren Sanktionen, vgl. hierzu die AGB in Ab-
schnitt 7.12.
Der Umgang mit etwaigen Abweichungen wird in Abschnitt 6.2 thematisiert.
Die Selbstauskunft liegt vor: [17].
6.1.2 Plausibilitätstests
Intention des Plausibilitätstests ist es, durch einfache automatisierte Tests eine
grundsätzliche Plausibilität zu den Angaben der Selbstauskunft herzustellen.
Dazu lädt der App-Entwickler seine App über die in der Selbstauskunft angegebene
Bezugsquelle hoch.
Seite 33
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Durch den Plausibilitätstest mit automatisiertem Tool werden neben einer Validie-
rung der Selbstauskunft die folgenden Informationen aus der App gegen die Anga-
ben der Selbstauskunft verifiziert (via Extraktion von Daten aus der AndroidMani-
fest.xml-Datei):
--- T00: Validierung der Selbstauskunft:
--- Ist die Selbstauskunft vorhanden?
--- Basiert die Selbstauskunft auf einer aktuell gültigen Vorlage? Ist die
Funktionalität der Vorlage unverändert?
--- Liegt zu der Selbstauskunft eine rechtsverbindlich unterschriebene Er-
klärung bei?
--- Sind alle Fragen der Selbstauskunft hinreichend beantwortet?
--- T01: Identifikation der App:
--- Extraktion der Name der App (Android package).
--- Extraktion der Versionsnummer (Android versionCode und versionNa-
me).
--- Sind die Ergebnisse des Tools konsistent zu den Angaben der Selbstaus-
kunft?
--- T02: Permissions:
--- Extraktion der gesetzten Permissions.
--- Sind die Ergebnisse des Tools konsistent zu den Angaben der Selbstaus-
kunft?
Der Umgang mit etwaigen Abweichungen wird in Abschnitt 6.2 thematisiert.
6.1.3 Automatisierte Tests
Als eine weitere Prüfart wird durch automatisierte Tests eine Verifikation der Selbst-
auskunft und eine Prüfung der Implementierung hinsichtlich handwerklicher Fehler
durchgeführt. Dazu werden verschiedene Tools für die automatisierten Tests ge-
nutzt.
Die folgenden Fragestellungen werden mittels automatisierter Tests bearbeitet:
--- T03: globale PIN-Policy:
--- App fordert globale PIN-Policy des Gerätes an (Device Administrator
API); hierüber kann die Kennwort-Policy (E03) verifiziert werden;
--- T04: Aufruf Krypto-API:
--- Verifikation, dass Krypto-API zur Durchführung kryptographischer Ope-
rationen angesprochen wird; hierüber kann der Selbstschutz (E04) kon-
trolliert werden;
--- T05: URLs und IP-Adressen:
Seite 34
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Verifikation, dass die in der App implementierten URLs und IP-Adressen
den Angaben der Selbstauskunft entsprechen; verifiziert Aspekte aus
zur (E06).
--- T06: Protokolle:
--- Verifikation von Standardprotokollen, verifiziert Aspekte der Kommuni-
kationsprotokolle (E08).
--- T07: Implementierung:
--- Analyse einer App auf SSL/TLS-Schwachstellen, die sich aus der Verwen-
dung der Komponenten TrustManager, HostnameVerifier und
WebViewClient ergeben;
--- Verwendung korrekter Bibliotheken (Bouncy Castle, SSL/TLS, ...), d.h. ob
die Bibliotheken geeignet oder anfällig sind;
--- Fehler bei der Verwendung von Kryptographischen Primitiva;
--- Prüfung der Implementierung hinsichtlich „Erkennung von bekannten
Programmierschwächen“;
--- Verifikation, ob dynamischer Code nachgeladen wird.
Alle Testergebnisse werden mit den Angaben der Selbstauskunft verglichen.
Dazu sind die benötigten Tools verfügbar.
Der Umgang mit etwaigen Abweichungen wird in Abschnitt 6.2 thematisiert.
6.1.4 Penetrationstests
Eine weitere Prüfart stellen Penetrationstests (PenTests) dar, die noch stärker manu-
ell durch technische Experten durchgeführt werden und noch stärker die Angaben
der Selbstauskunft verifizieren. Geprüft wird dabei insbesondere das Sendeverhalten
der App.
Die folgenden Fragestellungen werden mittels Penetrationstests durchgeführt:
--- T08: manuell:
--- Verifikation des erwarteten Verhaltens durch händisches Testen der
App; hierüber kann insbesondere eine mögliche Kennwort-Policy (E03)
verifiziert werden oder eine Authentisierung ggü. einem Server (E10);
--- Verifikation der Eignung kryptographischer Algorithmen und Parameter
oder von Kommunikationsprotokollen, verifiziert E07 sowie E08;
--- T09: Datenfluss-Analyse:
--- Verifikation des erwarteten Verhaltens durch eine Analyse des Daten-
flusses; hierüber kann insbesondere kontrolliert werden, ob eine sichere
Datenablage (E05) korrekt realisiert ist;
--- T10: Datensendungsverhalten:
Seite 35
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Verifikation, dass Kommunikation zu Servern verschlüsselt erfolgt, vgl.
E10;
--- T11: Erweiterung Implementierung:
--- Free-Style-Auditierung.
Alle Testergebnisse werden mit den Angaben der Selbstauskunft verglichen.
Dazu stehen weitere Tools bereit; zusätzlich nutzt die Prüfstelle weitere als geeignet
eingestufte Tools.
Der Umgang mit etwaigen Abweichungen wird in Abschnitt 6.2 thematisiert.
6.1.5 Datenschutzrechtliche Prüfung
Ob die datenschutzrechtlichen Anforderungen angemessen erfüllt werden, lässt sich
nicht automatisiert durch ein Tool, sondern nur durch eine rechtliche Prüfung klären.
Aus diesem Grund ist die Prüfungsart „Datenschutzrechtliche Prüfung“ vorgesehen.
Im Rahmen dieser Prüfung wird untersucht, ob die Dokumentation der Selbstaus-
kunft zu den Prüfaspekten E11 „Datenschutz“ und E12 „Spezielle Bestimmungen“ vor-
liegt, plausibel und nachvollziehbar ist. Eine weitergehende rechtliche Prüfung wird
nicht vorgenommen:
--- T12: rechtliche Prüfung.
Der Umgang mit etwaigen Abweichungen wird in Abschnitt 6.2 thematisiert.
6.1.6 Site Visit
Ob die App-Sicherheitsfeatures auch so, wie beschrieben, in die App implementiert
und zur Auslieferung kommen, hat letztendlich auch etwas mit der Entwicklungs-
und Produktionsumgebung beim App-Anbieter zu tun.
Aus diesem Grund wird beim Site Visit die Entwicklungs- und Produktionsumgebung
vor Ort untersucht:
--- T13: Site Visit.
Der Site Visit umfasst alle relevanten Orte der Entwicklungs- und Produktionsumge-
bung insgesamt, dies können neben Standorten des App-Anbieters weitere Standor-
te von App-Entwickler oder -Hersteller sein.
Hierbei können anerkannte Standards für einen Site Visit herangezogen und ggf.
vorhandene Zertifizierungen anerkannt werden. Folgende Beispiele sind zu nennen:
--- Die Entwicklungs- und Produktionsumgebung wurde bereits gemäß Com-
mon Criteria dokumentiert, konform zur Verfahrensbeschreibung des BSI
[5];
--- Die Entwicklungs- und Produktionsumgebung umfasst ein Informationssi-
cherheits-Managementsystem (ISMS) gemäß ISO/IEC 27001 oder ISO 27001
auf der Basis von IT-Grundschutz.
Ein ISO 27001-Zertifikat wird selber nicht gefordert. Wenn allerdings ein
gültiges Zertifikat einer akkreditierten Zertifizierungsstelle für das ISMS der
Seite 36
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Entwicklungs- und Produktionsumgebung vorliegt, kann auf die Überprü-
fung verzichtet und das Zertifikat als Nachweis herangezogen werden.
Durch die Überprüfung im Rahmen von „certified app“ wird kein ISO 27001-
Zertifizierungsverfahren der Entwicklungs- und Produktionsumgebung
durchgeführt; dies ist zwar möglich, aber standardmäßig nicht vorgesehen.
--- Alternativ kann die Entwicklungs- und Produktionsumgebung auch ein IT-
Service-Management auf Basis von ITIL gemäß ISO/IEC 20000-1 oder ein
Qualitäts-Managementsystem gemäß ISO/IEC 9001 aufweisen.
Gleichfalls fordert „certified app“ kein solches Zertifikat, würde es aber im
Rahmen der Begutachtung entsprechend berücksichtigen.
Inhaltlich gefordert sind die Aspekte, die unter der Sicherheitserwartungen E14, E15
und E16 beschrieben sind; diese Punkte werden im Rahmen des Site Visits geprüft.
Der Umgang mit etwaigen Abweichungen wird in Abschnitt 6.2 thematisiert.
6.2 Umgang mit Abweichungen
Hervorzuheben ist, dass die Prüfung einem erfahrenen Evaluator in einer anerkann-
ten Prüfstelle (vgl. Abschnitt 7.4) unterliegen muss. Auch bei den toolunterstützten
Prüfungen bleibt der zuständige Evaluator verantwortlich. Insbesondere interpretiert
er die Ergebnisse der Tools und kann sie bei Bedarf auch „überstimmen“.
Werden im Rahmen der Prüfung der App Abweichungen vom Kriterienwerk festge-
stellt, ist folgendes Vorgehen vorgesehen:
--- ein „eindeutiger Fehler“ führt zum Durchfallen des Tests („fail“);
--- eine „Warnung“ führt ggf. zu Empfehlungen oder Verbesserungs-
vorschlägen („warning“);
--- „kein erkennbarer Fehler“ führt zum Bestehen des Testes („pass“);
--- falls keine Entscheidung getroffen werden kann, wird die Prüfung mit „in-
conclusive“ bewertet.
Die Entscheidung sieht eine hinreichende Dokumentation vor, so dass die Entschei-
dungen des Evaluators für die Zertifizierungsstelle nachvollziehbar sind.
Abweichungen werden dem Kunden mitgeteilt.
Werden im Rahmen eines Site Visits Abweichungen von den Anforderungen hin-
sichtlich der Entwicklungs- und Produktionsumgebung identifiziert, wird wie folgt
verfahren:
--- Zunächst erfolgt eine Bewertungen in den vier Abstufungen:
--- 1: Anforderungen sind erfüllt;
--- 2: Abweichung von einer Normanforderung, die in ihrer Geringfügigkeit
die Funktionsfähigkeit der Entwicklungs- und Produktionsumgebung
insgesamt nicht in Frage stellt (Verbesserungspotential);
Seite 37
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- 3: Abweichung von einer Normanforderung, die in ihrer Summe die
Funktionsfähigkeit der Entwicklungs- und Produktionsumgebung in
Frage stellt (Nebenabweichung/ Minor Non-Conformities);
--- 4: Abweichung von einer Normanforderung, die grundsätzlich die Funk-
tionsfähigkeit der Entwicklungs- und Produktionsumgebung in Frage
stellt (Hauptabweichung/ Major Non-Conformities).
--- Hauptabweichungen/ Major Non-Conformities müssen vor Erteilung eines
Zertifikates geschlossen sein. Hierzu ist ein Nachaudit notwendig mit Do-
kumentenprüfung und ggf. erneutem Site Visit.
--- Nebenabweichungen/ Minor Non-Conformities stehen der Erteilung eines
Zertifikats nicht im Wege, wenn
--- ein bewerteter und akzeptierter Korrekturmaßnahmenplan vorliegt –
welcher in diesem Fall als Korrekturmaßnahme gilt – und wenn
--- der Plan realistisch ist, nicht zu weit in die Zukunft reicht, Zwischen-
schritte abrufbar sind (eine Art Fortschrittkontrolle) und eine Frist der
Umsetzung formuliert ist.
--- Abweichungen werden wie zuvor beschrieben aufgenommen.
--- Bei Haupt- oder Nebenabweichungen wird ein Zeitraum zur Beseitigung
festgelegt und dem Kunden mitgeteilt.
6.3 Siegelstufen
Die Siegelstufe gibt an, wie „tief eine Prüfung geht“, d.h. durch welche Vertrauens-
würdigkeitsmaßnahmen die App überprüft wird. „certified app“ sieht vier Siegelstu-
fen vor, die wie folgt benannt sind:
--- Bronze;
--- Silber;
--- Gold;
--- Platin.
Die Siegelstufen sind aufsteigend sortiert, von einer Selbstauskunft mit Plausibili-
tätsprüfung bei Bronze über zusätzliche Tests mit automatisierten Tools bei Silber bis
hin zu ergänzenden Penetrationstests und einer rechtlichen Prüfung bei Gold. Soll
zusätzlich die Entwicklungs- und Produktionsumgebung dahingehend überprüft
werden, kann die Siegelstufe Platin herangezogen werden. Im Detail:
Für die Erst-Zertifizierung weisen die Siegelstufen die folgenden Prüfungen auf:
Tabelle 1: Prüfumfang Erst-Zertifizierung
Prüfaspekt Bronze Silber Gold Platin
zusätzlich zu
Bronze
zusätzlich zu
Silber
zusätzlich zu
Gold
Identifikation und Ist- Selbstauskunft - - -
Seite 38
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Prüfaspekt Bronze Silber Gold Platin
Aufnahme Plausibilitäts-
test
Sicherheitsbedarf Selbstauskunft - - -
Sicherheitserwartung Selbstauskunft - - -
App-Sicherheitsfeatures:
E01 Zugriff auf Ressour-
cen und Apps
Selbstauskunft
Plausibilitäts-
test
E02 Authentisierung Selbstauskunft
E03 Kennwort-Policy Selbstauskunft autom. Test PenTest
E04 Selbstschutz Selbstauskunft autom. Test
E05 Sichere Datenablage Selbstauskunft PenTest
E06 Kommunikation Selbstauskunft autom. Test
E07 Kryptogr. Verfahren Selbstauskunft manuell
E08 Kommunikationspro-
tokolle
Selbstauskunft autom. Test manuell
E09 Schlüsselmanage-
ment
Selbstauskunft
E10 Authentisierung Selbstauskunft PenTest
manuell
E11 Datenschutz Selbstauskunft rechtliche Prü-
fung
E12 Spezielle Bestim-
mungen
Selbstauskunft rechtliche Prü-
fung
E13 Implementierung Selbstauskunft autom. Test PenTest Site Visit
E14 Unabhängige Tests Selbstauskunft Site Visit
E15 Code-Review Selbstauskunft Site Visit
E16 Entwicklungs-/ Pro-
duktionsumgebung
Selbstauskunft Site Visit
E17 Weitere Sicherheits-
erwartungen
Selbstauskunft
Seite 39
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Für Maintenance- oder Re-Zertifizierungsverfahren, in denen überarbeitete Versio-
nen von Apps geprüft werden – wichtig bei Updates und Patches von Apps –, sind
abweichende Regelungen vorgesehen, vgl. dazu auch Abschnitt 7.3:
Tabelle 2: Prüfumfang Mainentance- und Re-Zertifizierungs-Verfahren
Prüfaspekt Bronze Silber Gold Platin
zusätzlich zu
Bronze
zusätzlich zu
Silber
zusätzlich zu
Gold
Identifikation und Ist-Aufnahme,
Sicherheitsbedarf, Sicherheitser-
wartung, App-
Sicherheitsfeatures (E01-E17)
identisch zu
Bronze in
Erst-
Zertifizierung,
vgl. Tabelle 1
identisch zu
Silber in Erst-
Zertifizierung,
vgl. Tabelle 1
grundsätzlich
identisch zu
Gold in Erst-
Zertifizierung,
vgl. Tabelle 1
identisch zu
Platin in Erst-
Zertifizierung,
vgl. Tabelle 1
Darlegung der Veränderungen,
bezüglich Identifikation und Ist-
Aufnahme, Sicherheitsbedarf,
Sicherheitserwartung und App-
Sicherheitsfeatures
abweichend
werden in Ab-
hängigkeit der
durchgeführten
Änderungen
individuelle
PenTests, ma-
nuelle Tests
und ggf. eine
rechtliche Prü-
fung durchge-
führt
abweichend
wird der Site
Visit nur dann
innerhalb der
2-Jahres-Frist
erneut durch-
geführt, wenn
sich hier Ver-
änderungen
ergeben haben
Seite 40
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Zusammenfassend stehen die vier Siegelstufen für folgendes Vertrauen:
--- „Bronze“: Bei der Siegelstufe „Bronze“ sichert der Hersteller in einer struk-
turierten, aussagekräftigen Herstellererklärung (Selbstauskunft) zu, dass
seine App die Sicherheitsfeatures aufweist, um die Sicherheitserwartun-
gen, die an seine App gestellt werden, erfüllt werden. Welche Sicherheits-
erwartungen dies sind, hängt vom Funktionsumfang der App und dem
Schutzbedarf der verwendeten Daten ab; diese Sicherheitserwartung wird
über die Selbstauskunft individuell als Maßstab festgelegt. Der Hersteller
sichert diese Sicherheitseigenschaften verbindlich zu.
Die Selbstauskunft selber wird von einer ZertApps-Prüfstelle auf Plausibili-
tät und Vollständigkeit hin überprüft. Ferner wird automatisiert überprüft,
ob der Zugriff auf Ressourcen und Apps korrekt implementiert ist.
--- „Silber“: Die Siegelstufe „Silber“ enthält die verbindliche Herstellererklä-
rung und die Plausiblitätstests der Prüfstelle aus der Siegelstufe „Bronze“.
Zusätzlich werden von der ZertApps-Prüfstelle weitere (automatisierte)
Tests durchgeführt, etwa zur Kennwort-Policy, zum Selbstschutz, zur
Kommunikation und den Kommunikationsprotokollen sowie zur Imple-
mentierung.
--- „Gold“: Die Siegelstufe „Gold“ umfasst die Vertrauensmaßnahmen aus
„Silber“. Zusätzlich werden von Experten der ZertApps-Prüfstelle durchge-
führt:
--- eine rechtliche Überprüfung der Angaben der Selbstauskunft zum The-
ma Datenschutz und weiteren speziellen Bestimmungen;
--- manuelle Tests der App zu kryptographischen Verfahren, den Kommu-
nikationsprotokollen und der Authentisierung;
--- Penetrationstest der App zur Kennwort-Policy, der sicheren Datenabla-
ge, der Authentisierung sowie der Implementierung.
--- „Platin“: Bei der Siegelstufe „Platin“ werden alle Vertrauensmaßnahmen
der Siegelstufe „Gold“ durchgeführt und zusätzlich wird die Entwicklungs-
und Produktionsumgebung einem Site Visit unterzogen.
Seite 41
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
7. Zertifizierung einer App
„certified app“ geht davon aus, dass nur der App-Anbieter Antragsteller einer Zertifi-
zierung ist. Denn er hat ein besonderes Interesse daran, die Qualität seiner App nach
außen hin durch ein Zertifikat zu belegen.
7.1 Zwei-stufiges Verfahren
„certified app“ sieht ein zwei-stufiges Zertifizierungsverfahren vor:
--- zunächst führt eine Prüfstelle die Prüfung einer App gemäß Prüfschema
[12] durch;
--- anschließend führt eine Zertifizierungsstelle die Zertifizierung dieser Prü-
fergebnisse der Prüfstelle gemäß Zertifizierungsschema [13] durch.
Zwei-stufige Verfahren haben sich international bewährt, weil hierdurch durch die
Zertifizierungsstelle eine Vergleichbarkeit zwischen den Prüfergebnissen einzelner
Prüfstellen gewährleistet werden kann.
7.2 Laufzeit eines Zertifikates
Ein Zertifikat gemäß „certified app“
--- gilt für eine exakt definierte Version der App und
--- ist zwei Jahre gültig.
Der erste Zertifizierungsprozess einer App wird Erst-Zertifizierung genannt.
7.3 Maintenance und Re-Zertifizierung
Erfahrungsgemäß unterliegen Software-Produkte – und insbesondere Apps – einem
regelmäßigen Update- und Patchprozess. „certified app“ sieht entsprechende Ver-
fahren vor, um Updates oder Patches einer zuvor zertifizierten App in einem ange-
messenen Rahmen erneut zu begutachten und somit das Zertifikat auch auf diese
neue Version der App ausweiten zu können. Hierbei sind zwei Verfahrensschritte zu
unterscheiden:
--- Maintenance: Maintenance liegt vor, wenn die App noch ein gültiges Zerti-
fikat aufweist, allerdings überarbeitet wurde, und das Zertifikat aufrecht-
erhalten bleiben soll.
--- Re-Zertifizierung: Eine Re-Zertifizierung wird durchgeführt, wenn nach Ab-
lauf der Gültigkeit das Zertifikat erneuert werden soll. Ist die App noch un-
verändert, muss dennoch ein Prüfprozess durchgeführt werden, um die
App gegen den aktuellen Stand des Kriterienkatalogs zu prüfen.
Maintenance- und Re-Zertifizierungsverfahren berücksichtigen die Ergebnisse der
vorangegangenen Prüfungen sowie den Umfang etwaiger Änderungen, um eine an-
gemessene Wiederholungsprüfung zu gewährleisten.
7.4 Übersicht über Prüf- und –Zertifizierungsstellen für „certified app“
„certified app“ sieht die folgenden Rollen vor:
--- Prüfstelle, die die Prüfung einer App gemäß Prüfschema [12] durchführt;
Seite 42
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Zertifizierungsstelle, die die Zertifizierung einer App gemäß Zertifizie-
rungsschema [13] durchführt.
Fachlich werden von einer Prüfstelle für die Durchführung der verschiedenen Prüfar-
ten Kompetenzen in drei Disziplinen erwartet:
--- „Technik“;
--- „Recht“;
--- „Managementsysteme“.
Prüfstellen müssen mindestens Kompetenzen in der Disziplin „Technik“ vorweisen;
die Disziplinen „Recht“ und „Managementsysteme“ sind notwendig, wenn die Prüf-
stelle Prüfungen der Siegelstufen „Gold“ oder „Platin“ durchführen möchte. Prüfstel-
len werden gemäß ihrer Kompetenzen für die Bereiche „Technik“ sowie optional
„Recht“ und „Managementsysteme“ zugelassen.
Dabei ist aus Gründen der Unabhängigkeit und Aussagekraft des Zertifikates sicher-
zustellen, dass Zertifizierung und Prüfung nicht von einer natürlichen Person ge-
meinsam durchgeführt werden. Dies kann z.B. über eine personelle Trennung her-
beigeführt werden. Grundsätzlich kann jedoch Prüf- und Zertifizierungsstelle durch
eine juristische Person gleichermaßen wahrgenommen werden – allerdings unter
strikter Trennung der jeweils ausführenden Personen.
Nachfolgend ist eine Übersicht über anerkannte Prüf- und -Zertifizierungsstellen zu
finden, wobei der aktuelle Stand auf den Webseiten der datenschutz cert GmbH zu
finden sein wird (vgl. www.datenschutz-cert.de).
Zum Verfahren der Anerkennung von Prüf- und -Zertifizierungsstellen sei auf separa-
te Dokumente verwiesen, vgl. [14] und [15].
7.4.1 Zertifizierungsstellen
datenschutz cert GmbH
Anschrift: Konsul-Smidt-Str. 88a, 28217 Bremen
Tel.: 0421/6966-3250
Mail: zertifizierungsstelle@datenschutz-cert.de
Internet: www.datenschutz-cert.de
Zertifikatsliste: www.datenschutz-cert.de/zertlisten
Kontakt: www.datenschutz-cert.de
N.N. (in Planung)
7.4.2 Prüfstellen
datenschutz cert GmbH
Anschrift: Konsul-Smidt-Str. 88a, 28217 Bremen
Tel.: 0421/6966-3250
Mail: pruefstelle@datenschutz-cert.de
Seite 43
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Internet: www.datenschutz-cert.de
N.N. (in Planung)
7.5 Ansprechpartner und Kontakt (Selbstauskunft)
Als zentraler Ansprechpartner für App-Anbieter, die ihre App zertifizieren lassen
möchten, ist:
--- Zertifizierungsstelle, vgl. Abschnitt 7.4.
Hier ist auch ein spezieller Kontakt angegeben, unter dem auch die Selbstauskunft
verfügbar ist.
7.6 Übersicht über den Zertifizierungsprozess
Nachfolgend ist der typische Ablauf zur Erst-Zertifizierung aus Sicht eines App-
Anbieters aufgeführt:
--- Der App-Anbieter strebt die Zertifizierung seine App an.
--- Der App-Anbieter wendet sich an die datenschutz cert GmbH als Zertifizie-
rungsstelle für „certified app".
--- Auf den Internetseiten der datenschutz cert GmbH findet er dazu alle be-
nötigten Informationen, inkl. der Selbstauskunft (z.Zt. realisiert als Excel-
Tabelle mit Makro-Unterstützung).
--- Der App-Anbieter stellt einen Antrag auf Zertifizierung bei der datenschutz
cert GmbH und übergibt ihr hierfür die für das Verfahren benötigten Daten
in der Selbstauskunft. Zusätzlich übergibt er die App in Form der APK-Datei.
Die Selbstauskunft wird vom App-Anbieter verbindlich erklärt.
Damit übergibt der App-Anbieter die folgenden Daten an die datenschutz
cert GmbH:
--- Selbstauskunft als ausgefüllte Excel-Tabelle;
--- schriftliche Beauftragung per Brief, Fax oder E-Mail, dazu sieht die
Excel-Tabelle einen Vordruck vor;
--- App in Form der APK-Datei.
Mit der Antragstellung auf Zertifizierung bei der datenschutz cert GmbH
kommt der Vertrag zu Stande und es entstehen die unten genannten Kos-
ten und Gebühren. Der Antrag auf Zertifizierung wird seitens der daten-
schutz cert GmbH geprüft. Der Antragsteller erhält eine Eingangsbestäti-
gung.
--- Die datenschutz cert GmbH legt das Verfahren im Zertifizierungs-
Managementsystem „CertMS“ an.
Die datenschutz cert GmbH sieht einen Zertifizierungsmanager für das
Projektmanagement aller Zertifizierungsverfahren vor, der den Fortgang
der Verfahren und die Kommunikation zwischen App-Anbieter und Prüf-
stelle koordiniert. Er teilt die Ressourcen ein und ist einheitlicher Ansprech-
partner.
Seite 44
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Der App-Anbieter gibt in der Selbstauskunft vor, welche Prüfstelle er mit
der Prüfung seiner App betrauen möchte. Sofern keine inhaltlichen oder
organisatorischen Gründe dagegen sprechen, beauftragt die datenschutz
cert GmbH die ausgewählte Prüfstelle und übergibt ihr die Selbstauskunft
samt APK-Datei der zu prüfenden App. Andernfalls kontaktiert die daten-
schutz cert GmbH den App-Anbieter und vereinbart eine alternative Prüf-
stelle.
--- Die Prüfstelle prüft die App und steht hierzu im direkten Dialog mit dem
App-Anbieter.
Die Prüfung erfolgt gemäß Siegelstufe, vgl. dazu Ausführungen in Ab-
schnitt 6 in diesem Prüfkonzept. Für die Prüfung nutzt die Prüfstelle die
gemäß Siegelstufe benötigten Tools.
Die Dokumentation der Evaluierung erfolgt innerhalb eines speziellen
Tools, dem „ZertApps-Evaluation Environment (ZEE)“. Final wird aus diesem
ZEE ein Extrakt/ Export erzeugt, in dem das Ergebnis der Prüfung doku-
mentiert ist.
Der Prüfungsmanager ist in der Prüfstelle für das Projektmanager aller Prü-
fungsverfahren zuständig; er teilt die Ressourcen ein und ist einheitlicher
Ansprechpartner.
--- Die Prüfstelle sendet anschließend der datenschutz cert GmbH das Ergeb-
nis ihrer Prüfung zu. Dazu nutzt die Prüfstelle das Extrakt bzw. den Export
aus dem ZertApps-Evaluation Environment (ZEE). Das Ergebnis kann lau-
ten: „pass“ für die Empfehlung zur Zertifizierung der App oder „fail“, falls
die App aus Sicht der Prüfstelle die Anforderungen nicht erfüllt und nicht
zertifiziert werden kann.
--- Sofern die Prüfstelle die Zertifizierung der App empfiehlt, führt die daten-
schutz cert GmbH die Zertifizierung der App durch; bei Rückfragen kontak-
tiert sie die Prüfstelle und nutzt ggf. ein Review-Protokoll.
Die datenschutz cert GmbH stellt keine Zeitpläne für individuelle Verfahren
zur Verfügung, stattdessen ist ein standardisierter Prozess etabliert:
--- Montags tagt der Zertifizierungsausschuss, in dem die Erteilung eines
Zertifikates erfolgen kann.
--- Damit ein Zertifizierungsverfahren dort behandelt werden kann, muss
der Prüfprozess abgeschlossen und vollständig der Zertifizierungsstelle
vorliegen, so dass die Zertifizierungsstelle am Mittwoch früh der Vor-
woche mit der Zertifizierung starten kann.
--- Rückfragen an die Prüfstelle können den Prozess verlängern. Für das
Zertifikat der Stufe Bronze kann ein beschleunigtes Verfahren ange-
wendet werden.
--- Sind alle Fragen geklärt und hält auch die Zertifizierungsstelle die App für
zertifizierbar, kann die Zertifizierung durch ein formales Verfahren (Zertifi-
zierungsentscheidung) durchgeführt werden.
Seite 45
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- Ist die Zertifizierungsentscheidung positiv erfolgt, wird das Validierungs-
system angesteuert, das die Veröffentlichung des Zertifikates der App
durch vier Mechanismen vorsieht:
--- Veröffentlichung der App in der Zertifikatsliste im Internet;
--- Ausdruck für den App-Anbieter;
--- automatisierte Auswertung mittels CertValidation-App, die als „Trust
Anchor“ checkt, ob eine App gemäß „certified app“ zertifiziert ist;
--- elektronische Abfrage der Zertifikatsliste.
--- Daneben wird der App-Anbieter für die Erteilung des Zertifikates infor-
miert; er erhält den Link auf die Zertifikatsliste im Internet, sein Zertifikat
und die Rechnung. Außerdem wird der App-Anbieter darauf hingewiesen,
wie er mit Veränderungen an seiner App im Hinblick auf das Zertifikat um-
zugehen hat.
Der Zertifizierungsprozess mitsamt der Prüfung ist in Abbildung 2 illustriert.
ZertApps-Zertifizierungsstelle
App-Anbieter Nutzer
ZertApps-
Prüfstelle
CertRequest
Tool 1
Validierungs-
system
Cert-
Management
Audit-
Management
Tool 2 Tool n
Abbildung 2: Zertifizierungsprozess
Seite 46
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Erfahrungsgemäß unterliegen Software-Produkte – und insbesondere Apps – einem
regelmäßigen Update- und Patchprozess (Erfahrungsgemäß gilt dies übrigens weni-
ger für zertifizierte Produkte). Von daher sieht „certified app“ einen entsprechenden
Maintenance- und Re-Zertifizierungsprozess vor, der im Prinzip ähnlich wie oben be-
schrieben für die Erst-Zertifizierung erfolgt, aber angepasst. Der Dialog zur Selbst-
auskunft sieht dies entsprechend vor.
7.7 Zeitbedarf für Prüfung und Zertifizierung
Je nach Siegelstufe und Mitarbeit/ Zulieferung von Informationen und Unterlagen
variiert der Zeitbedarf für die Prüfung und Zertifizierung. Die internen Verwaltungs-
verfahren in der datenschutz cert GmbH sind aber auf die dynamische Entwicklung
von Apps angepasst.
Unser Anspruch ist, die folgenden unverbindlichen Zeiten für die Prüfung und Zertifi-
zierung von Apps einzuhalten:
--- Bronze: 2 Tage;
--- Silber: 5 Tage;
--- Gold: 10 Tage;
--- Platin: 10 Tage zzgl. benötigte Zeit für Site Visit.
Wichtig zur Einhaltung dieser Zeitvorgaben ist eine gewisse Vorlaufzeit, damit sich
die Mitarbeiter der Prüfstelle auf die Tätigkeiten einstellen können.
7.8 Veröffentlichung der Zertifikate/ Validierungssystem
Die Veröffentlichung bzw. Publikation einer zertifizierten App erfolgt durch
--- Listung auf unserer Zertifikatsliste;
--- Ausdruck als „Artefakt“;
--- automatisierte Auswertung mittels CertValidation-App;
--- elektronische Abfrage der Zertifikatsliste.
7.8.1 Zertifikatsliste
Die datenschutz cert GmbH führt eine Liste der erteilten Zertifizierungen, die unter
www.datenschutz-cert.de verfügbar ist. Aus der Liste sind der Antragsteller (App-
Anbieter), die App mit exakter Angabe der Version, die Zertifikats-ID sowie die Gül-
tigkeit der Zertifizierung ersichtlich.
7.8.2 Ausdruck eines Zertifikates
Ganz klassisch wünschen sich Kunden typischerweise auch eine Art „Urkunde“ für
die Darstellung nach außen und innen.
Aus diesem Grund wird auch ein pdf eines klassischen Zertifikates automatisiert er-
stellt und zum Selbstausdruck zur Verfügung gestellt.
Seite 47
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
7.8.3 CertValidation-App
Zusätzlich wird eine CertValidation-App zur Verfügung gestellt. Diese überprüft, ob
die installierten Apps in der vorliegenden Version gemäß „certified app“ zertifiziert
sind oder nicht.
Diese CertValidation-App stellt damit als „Trust Anchor“ eine Art Vertrauensanker
dar. Die CertValidation--App ist so gestaltet, dass eine Abfrage der aktuellen Zertifi-
katsliste mit anschließender Validierung der installierten Apps über eine Schaltfläche
manuell gestartet werden kann.
Abbildung 3: CertValidation-App
Nach einer Betätigung der „Check Apps“-Schaltfläche ruft die CertValidation-App alle
im CertMS-Zertifizierungssystem hinterlegten Android-Apps ab (siehe Abs. 7.8.4) und
vergleicht sie mit allen auf dem entsprechenden Endgerät installierten Apps
Sofern eine installierte App in der Liste enthalten ist und mindestens ein Zertifikat
für diese App existiert, erfolgt die Darstellung des Listeneintrags in grüner Schrift. Es
wird nicht geprüft, welchen Status das Zertifikat besitzt bzw. ob das Gültigkeitsda-
tum bereits überschritten wurde. Die entsprechenden Felder werden allerdings an-
gezeigt.
7.8.4 Abfrage der Zertifikatsliste
Zum Auslesen der Zertifikatsliste stellt das CertMS-Zertifizierungssystem eine öffent-
lich (d.h. ohne vorangestellte Authentisierung) erreichbare REST-API zur Verfügung.
Zum Schutz der Vertraulichkeit sowie der Integrität der übermittelten Daten wird die
Abfrage per SSL/TLS abgesichert.
7.9 Entzug eines Zertifikates
Das Zertifikat wird entzogen, wenn der Antragsteller nachhaltig gegen die Zertifi-
zierungsvoraussetzungen verstößt. Ein solcher Verstoß liegt insbesondere vor, wenn
--- der zertifizierte Untersuchungsgegenstand (App) in der beschriebenen
Weise verändert wurde und der Anbieter keine Prüfung ermöglicht,
Seite 48
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
--- im Rahmen der Prüfung nicht die für die Vergabe des Zertifikats erforderli-
chen Voraussetzungen erfüllt werden,
--- der Antragsteller aufgrund drohender oder eingetretener Insolvenz einen
zuverlässigen Geschäftsbetrieb nicht mehr aufrechterhalten kann,
--- die Zertifizierungskosten nicht spätestens innerhalb von 4 Wochen nach
Abschluss der Zertifizierung gegenüber der Zertifizierungsstelle beglichen
werden.
Die Zertifizierungsstelle teilt dem Antragsteller die Gründe des Zertifikatsentzugs
mit. Im Falle des Entzuges wird das über die Zertifikatsliste der Zertifizierungsstelle
online veröffentlichte Zertifikat auf den Status als entzogen gesetzt und spätestens
nach 4 Wochen aus der Liste entfernt. Der Entzug des Zertifikates kann auch ander-
weitig veröffentlicht werden.
7.10 Ablauf eines Zertifikates
Soweit das Zertifikat nach Ablauf der Gültigkeit entfällt, hat der App-Anbieter dafür
zu sorgen, dass das Logo und sämtliche Hinweise auf eine gültige Zertifizierung aus
den genutzten Medien unverzüglich entfernt werden.
7.11 Kosten und Gebühren
Für die Zertifizierung Ihrer App inkl. Prüfung durch Zertifizierungs- und Prüfstelle
werden Kosten fällig und Gebühren erhoben.
Kosten und Gebühren variieren je nach Prüfumfang einer App. Aufgrund der in „cer-
tified app“ vorgesehenen Siegelstufen wird folgendes Kostenmodell angeboten, das
Zertifizierungsgebühren und Kosten für die Prüfung beinhaltet.
Erst-Zertifizierung bei
Laufzeit 24 Monate
Maintenance Re-Zertifizierung bei
Laufzeit 24 Monate
Einmal-
kosten
monatl.
Kosten
innerhalb
Laufzeit
jedes
weitere
Verfahren
Einmal-
kosten
monatl.
Kosten
Bronze 0 € 79 € 2x inkl. 300 € 0 € 79 €
Silber 500 € 79 € 2x inkl. 500 € 500 € 79 €
Gold 3.500 € 79 € 2x inkl. 1.500 € 2.500 € 79 €
Platin 10.000 €17 79 € 2x inkl. 4.000 €17 8.000 €17 79 €
Die Kosten verstehen sich zzgl. der jeweils geltenden Umsatzsteuer.
17 Die Einmalkosten bei Siegelstufe „Platin“ decken vor allem die Kosten für die Begutachtung der Entwicklungs- und Pro-duktionsumgebung (Site Visit) ab. Die genannten Kosten gehen dabei von folgenden Eckdaten ab: 1 Standort in Deutsch-land; nur max. eine Nachbesserung erforderlich; nur ein Audit innerhalb der 2-Jahres-Laufzeit. Sonstige Audits auf Anfra-ge.
Seite 49
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Das obige Kostenmodell sieht vor, dass alle Prüfschritte gemäß Siegelstufe einmalig
durchgeführt werden, d.h, dass die App die Kriterien erfüllt.
Falls die Prüfung ergibt, dass Ihre App nicht die Anforderungen des Regelwerkes „cer-
tified app" entspricht und daher nicht zertifiziert werden kann, kann der Anbieter
nachbessern und wieder in die Prüfung einsteigen. In diesem Fall erhöht sich der
Aufwand für die Prüfung. Mehraufwand wird dann zusätzlich zum obigen Kosten-
modell nach tatsächlichem Aufwand zum aktuellen Tagessatz der datenschutz cert
GmbH in Rechnung gestellt.
Falls die Prüfung oder Zertifizierung auf Wunsch des App-Anbieters abgebrochen
wird, werden Kosten anteilig fällig, mindestens aber bei den Siegelstufen Bronze und
Silber jeweils i.H.v. 1.280,- € , im Übrigen in Höhe der oben genannten Einmalkosten.
Die Kosten fallen an, sobald ein Antrag auf Zertifizierung bei der Zertifizierungsstelle
eingegangen ist. Sie wird von der Zertifizierungsstelle nach Abschluss der Zertifizie-
rung in Rechnung gestellt und ist spätestens zwei Wochen nach Rechnungserhalt
ohne Abzug zu zahlen.
7.12 Geschäftliche Bedingungen für die Durchführung von Zertifizierungs-dienstleistungen
Rechtliche Basis der Durchführung von Evaluierung und Zertifizierung einer App
gem. Prüfkonzept [11] sind die „Allgemeinen Geschäftsbedingungen und Zertifizie-
rungsvereinbarungen“, die auf den Webseiten der datenschutz cert GmbH unter
www.datenschutz-cert.de zur Verfügung gestellt werden.
Darüber hinaus gelten die „Vergabe- und Nutzungsbedingungen für ‚ certified app‘“
[16], die in der aktuellen Version online unter www.datenschutz-cert.de zur Verfü-
gung stehen.
Seite 50
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
8. Annex zur Methodik
Im Nachfolgenden wird nachgewiesen, dass die Ableitungen von Bedrohungen,
rechtlichen oder regulatorischen Anforderungen und Sicherheitsschwächen über Si-
cherheitsziele bis hin zu Sicherheitserwartungen korrekt ist, insbesondere unter Be-
rücksichtigung relevanter Schnittstellen und Datenarten.
Zunächst ist die Frage zu klären, ob Schnittstellen für die App in dem Sinne relevant
sind, dass hierüber Daten kommuniziert werden, und welche Datenarten verwendet
werden.
Gemäß Abschnitt 4.1.2 sind folgende Datenarten und Schnittstellen relevant:
--- Datenarten:
--- DatKat01: keine Daten oder Daten ohne Schutzbedarf
--- DatKat02: Daten mit normalem Schutzbedarf
--- DatKat03: Daten mit hohem Schutzbedarf oder Personenbezug
--- DatKat04: sensible personenbezogene Daten
--- Schnittstellen:
--- IntKat01: nach außen
--- IntKat02: intern zu anderen Apps
--- IntKat03: intern zu Ressourcen des Smartphones
--- IntKat04: GUI
Die nachfolgende Tabelle 3 gibt an, über welche Schnittstellen welche Daten kom-
muniziert werden (gekennzeichnet durch ‚X1‘, ‚X2‘, ‚X3‘, etc.).
Tabelle 3: relevante Datenarten und Schnittstellen
DatKat01 DatKat02 DatKat03 DatKat04
IntKat01 Bsp.: X1
IntKat02
IntKat03 Bsp.: X2
IntKat04
Die folgenden Bedrohungen werden als relevant erachtet (gekennzeichnet durch ‚ja‘,
wobei als Begründung die Zuordnung ‚X1‘, ‚X2‘, ‚X3‘ aus Tabelle 3 genutzt wird), vgl.
Tabelle 4.
Tabelle 4: relevanter Sicherheitsbedarf I
relevant?
B01 relevant, wenn Schnittstelle DatKat3 ausgewählt
B02 relevant, wenn Schnittstelle DatKat2 ausgewählt
Seite 51
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
relevant?
B03 relevant, wenn Daten verarbeitet werden, mit Schutzbedarf (d.h. nor-
mal, hoch/ Personenbezug oder sensibel personenbezogen)
B04 relevant, wenn Daten verarbeitet werden, mit Schutzbedarf (d.h. nor-
mal, hoch/ Personenbezug oder sensibel personenbezogen)
B05 relevant, wenn Schnittstelle DatKat1 ausgewählt
B06 relevant, wenn Schnittstelle DatKat1 ausgewählt
B07 relevant, wenn Schnittstelle DatKat1 ausgewählt
B08 relevant, wenn Schnittstelle DatKat1 ausgewählt
B09 kann App-Anbieter ausfüllen, sofern weitere Bedrohung relevant
Die folgenden rechtlichen Bestimmungen werden als relevant erachtet (gekenn-
zeichnet durch ‚ja‘, wobei als Begründung die Zuordnung ‚X1‘, ‚X2‘, ‚X3‘ aus Tabelle 3
genutzt wird), vgl. Tabelle 5.
Tabelle 5: relevanter Sicherheitsbedarf II
relevant?
R01 relevant bei Daten mit Personenbezug, d.h. Datenkategorie DatKat3
oder DatKat4
R02 relevant, wenn Daten verarbeitet werden, mit Schutzbedarf (d.h. nor-
mal, hoch/ Personenbezug oder sensibel personenbezogen)
R03 kann App-Anbieter ausfüllen, sofern weitere Anforderung relevant
Die folgenden Annahmen werden als relevant eingestuft:
Tabelle 6: relevanter Sicherheitsbedarf III
relevant?
A01 stets relevant, da nur „certified app“ nur für Android gilt
A02 stets relevant, weil die App sich nur eingeschränkt gegen ein korruptes
Betriebssystem oder Gerät schützen kann
A03 nur relevant, wenn Kommunikation nach außen stattfindet (IntKat1)
A04 stets relevant, weil die App sich nur eingeschränkt gegen mutwilligen
Missbrauch schützen kann
A05 stets relevant18
18 Das Nachladen dynamischen Codes, bei dem die zu zertifizierende App lediglich die „Hülle“ aufweist – durch welche die eigentliche App dynamisch nachgeladen wird –, enthält nicht die nach außen angegebene Funktionalität. Dadurch kann
Seite 52
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
relevant?
A06 nur relevant bei Siegelstufen Bronze und Silber, kann bei Gold oder
Platin entfallen19
Die Sicherheitsschwächen sind grundsätzlich relevant:
Tabelle 7: relevanter Sicherheitsbedarf III
relevant?
V01 stets relevant
V02 stets relevant
Ausgehend vom Sicherheitsbedarf aus Tabelle 4 werden anhand der nachfolgend
vorgegebenen Tabelle die Sicherheitsziele extrahiert.
Tabelle 8: Mapping Bedrohungen zu Sicherheitszielen
B01 B02 B03 B04 B05 B06 B07 B08 B09 R01 R02 R03 V01 V02
S01 X
S02 X
S03 X
S04 X
S05 X20 X20
S06 X X X
S07 X
S08 X
S09 X
S10 X
S11 X X
S12 X
der Endnutzer möglicherweise nicht zwischen einer App, die lediglich die Hülle simuliert, und einer App, welche die ei-gentliche Funktionalität erbringt, unterscheiden. Von daher besteht die Gefahr, dass die zertifizierte App, mit einer nicht zertifizierten Funktionalität verwechselt wird. Um Missbrauch auszuschließen, sind Apps mit dynamischem Code gegen-wärtig daher nicht zertifizierbar. 19 Unter Umständen ist eine Prüfung der App in der gewünschten Siegelstufe nicht durchführbar. Ein möglicher Grund könnte sein, dass bereits in der App implementierte Sicherheitsmechanismen eine Prüfung der App durch Tools verhin-dern – etwa bei Obfuskation oder Härtung. In einem solchen Fall ist die Zertifizierungsstelle zu Rate zu ziehen, da diese App dann vermutlich in einer höheren Siegelstufe mit erweiterten Analysewerkzeugen, ggf. auch auf Quellcode-Basis, evtl. direkt beim Entwickler, geprüft werden kann. 20 wenn Datenkategorie mit Personenbezug ausgewählt (DatKat3 oder DatKat4)
Seite 53
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
B01 B02 B03 B04 B05 B06 B07 B08 B09 R01 R02 R03 V01 V02
S13 X
S14 X20
S15 X20
S16 X
Final wird ausgehend von den Sicherheitszielen das Mapping zu den relevanten Si-
cherheitserwartungen hergestellt, vgl. Tabelle 9
Tabelle 9: Mapping Sicherheitszielen zu -erwartungen
S01 S02 S03 S04 S05 S06 S07 S08 S09 S10 S11 S12 S13 S14 S15 S16
E01 X X
E02 X
E03 X20
E04 X
E05 X
E06 X
E07 X
E08 X
E09 X
E10 X
E11 X
E12 X X
E13 X X X
E14 X
E15 X
E16 X
E17 X
Anzumerken ist, dass die Sicherheitsschwächen ganz bewusst oben im Abschnitt 4.2
zum Sicherheitsbedarf dargelegt werden. Die Common Criteria gehen hier metho-
disch etwas anders vor: Zunächst wird davon ausgegangen, dass die App-
Sicherheitsfeatures korrekt implementiert werden; Sicherheitsschwächen werden
methodisch erst später im Rahmen der Schwachstellenanalyse beleuchtet. Um den
Prüfaufwand zu reduzieren und App-Entwickler möglichst frühzeitig mit möglichen
Seite 54
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Schwächen zu konfrontieren – damit diese die Schwächen möglichst im Vorhinein
eliminieren – , geht „certified app“ bewusst anders vor.
Abschließend wird dargelegt, wie die verschiedenen Sicherheitserwartungen im
Rahmen der Prüfung und Zertifizierung verifiziert bzw. gegen die Selbstauskunft va-
lidiert werden.
Dazu sind folgende Prüfungsschritte vorgesehen:
--- T00 Validierung Selbstauskunft
--- T01 Name der App, Versionsnummer (android.versionName)
--- T02 gesetzte Permissions
--- T03 globale PIN-Policy des Gerätes
--- T04 Krypto-API
--- T05 URLs, IP-Adressen
--- T06 Protokolle
--- T07 Implementierung
--- T08 manuell
--- T09 Datenfluss-Analyse
--- T10 Datensendungsverhalten
--- T11 Erweiterung Implementierung
--- T12 rechtl. Prüfung
--- T13 Site Visit
Siegelstufe Bronze Silber21 Gold21 Platin21
Prüfart Selbst-
auskunft
Plausibi-
litäts-
test
autom.
Test
PenTest manuell rechtl.
Prüfung
Site Visit
21 zusätzlich zu vorheriger Siegelstufe
Seite 55
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Siegelstufe Bronze Silber21 Gold21 Platin21
Prüfart Selbst-
auskunft
Plausibi-
litäts-
test
autom.
Test
PenTest manuell rechtl.
Prüfung
Site Visit
Identifikation Selbst-
auskunft
T00
Validie-
rung
Selbst-
aus-
kunft
T01
Name
der App
Versions
onsnum
num-
mer
Ist-Aufnahme Selbst-
auskunft
Sicherheitsbe-
darf
Selbst-
auskunft
Sicherheitser-
wartung
Selbst-
auskunft
App-Sicherheitsfeatures
E01 Zugriff auf Res-
sourcen und
Apps
Selbst-
auskunft
T02
gesetzte
Permis-
sions
E02 Authentisierung Selbst-
auskunft
E03 Kennwort-Policy Selbst-
auskunft
T03
globale
PIN-
Policy
des Ge-
rätes
T08
manuell
Seite 56
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Siegelstufe Bronze Silber21 Gold21 Platin21
Prüfart Selbst-
auskunft
Plausibi-
litäts-
test
autom.
Test
PenTest manuell rechtl.
Prüfung
Site Visit
E04 Selbstschutz Selbst-
auskunft
T04
Krypto-
API
E05 Sichere Daten-
ablage
Selbst-
auskunft
T09
Daten-
fluss-
Analyse
E06 Kommunikation Selbst-
auskunft
T05
URLs, IP-
Adres-
sen
E07 Kryptogr. Ver-
fahren
Selbst-
auskunft
T08
manuell
E08 Kommunikati-
onsprotokolle
Selbst-
auskunft
T06
Proto-
kolle
T08
manuell
E09 Schlüsselma-
nagement
Selbst-
auskunft
E10 Authentisierung Selbst-
auskunft
T10
Daten-
sendungs
dungs-
verhalten
T08
manuell
E11 Datenschutz Selbst-
auskunft
T12
rechtl.
Prüfung
E12 Spezielle Best-
immungen
Selbst-
auskunft
T12
rechtl.
Prüfung
Seite 57
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Siegelstufe Bronze Silber21 Gold21 Platin21
Prüfart Selbst-
auskunft
Plausibi-
litäts-
test
autom.
Test
PenTest manuell rechtl.
Prüfung
Site Visit
E13 Implementie-
rung
Selbst-
auskunft
T07
Imple-
mentie-
rung
T11
Erweite-
rung
Imple-
mentie-
rung
T13
Site Visit
E14 Unabhängige
Tests
Selbst-
auskunft
T13
Site Visit
E15 Code-Review Selbst-
auskunft
T13
Site Visit
E16 Entwicklungs-/
Produktionsum-
gebung
Selbst-
auskunft
T13
Site Visit
E17 Weitere Sicher-
heitserwartun-
gen
Selbst-
auskunft
Die Prüfungsschritte werden durch folgende Tools und Techniken unterstützt:
Prüfungsschritte mögliche Tools und Techniken
T00 Validierung Selbstauskunft manuelle Bewertung der Selbst-
auskunft mit Dokumentation der
Prüfung (Auditprotokoll)
T01 Name der App, Versionsnummer Tool TZI (Uni Bremen)22
ZertApps-XML-Framework T02 gesetzte Permissions
T03 globale PIN-Policy des Gerätes Appicaptor (FhG-SIT) 23
FlowDroid (FhG-SIT)
Codeinspect (FhG-SIT)
ZertApps-XML-Framework
T04 Krypto-API
T05 URLs, IP-Adressen
T06 Protokolle
22 Das Technologie-Zentrum Informatik und Informationstechnik (TZI) der Universität Bremen ist Partner im ZertApps-Verbundprojekt. 23 Das Fraunhofer-Institut für Sichere Informationstechnologie (FhG-SIT) ist Partner im ZertApps-Verbundprojekt.
Seite 58
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
Prüfungsschritte mögliche Tools und Techniken
T07 Implementierung
T08 manuell manuelle Bewertung der App mit
Dokumentation der Prüfung (Au-
ditprotokoll)
T09 Datenfluss-Analyse Tools der Prüfstelle mit Dokumen-
tation der Prüfung (Auditproto-
koll);
genutzt werden können dazu auch
die o.g. Tools der Uni Bremen und
von FhG-SIT, die weitere Funktio-
nalitäten zur Analyse von Apps
bereitstellen
T10 Datensendungsverhalten
T11 Erweiterung Implementierung
T12 rechtl. Prüfung rechtliche Bewertung der Selbst-
auskunft mit Dokumentation der
Prüfung (Auditprotokoll)
T13 Site Visit Prüfung und Bewertung der Ent-
wicklungs- und Produktionsum-
gebung samt Dokumentation
(Auditprotokoll)
Seite 59
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
9. Referenzen
9.1 Kriterienwerke, Normen und Standards
[1] Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and general model.
[2] Common Criteria for Information Technology Security Evaluation, Part
2: Security functional components.
[3] Common Criteria for Information Technology Security Evaluation, Part
3: Security assurance components.
[4] Common Methodology for Information Technology Security Evaluation,
Evaluation methodology.
[5] Bundesamt für Sicherheit in der Informationstechnik, „Anwendungs-
hinweise und Interpretationen zum Schema, AIS 1: Durchführung der
Ortsbesichtigung in der Entwicklungsumgebung des Herstellers“.
[6] Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und
Eisenbahn, „Bekanntmachung zur elektronischen Signatur nach dem
Signaturgesetz und der Signaturverordnung (Übersicht über geeignete
Algorithmen)“.
[7] Bundesamt für Sicherheit in der Informationstechnik, „BSI – Technische
Richtlinie, Kryptographische Verfahren: Empfehlungen und Schlüssel-
längen“, BSI TR-02102.
[8] Unabhängiges Landeszentrum für Datenschutz (ULD) Schleswig-
Holstein, „Anforderungskatalog v 2.0, 28.11.2014
[9] Düsseldorfer Kreis, „Orientierungshilfe zu den Datenschutzanforderun-
gen an App-Entwickler und App-Anbieter“, 16.06.2014
[10] DIN EN ISO/IEC 17067, „Konformitätsbewertung – Grundlagen der Pro-
duktzertifizierung und Leitlinien für Produktzertifizierungsprogramme“
9.2 Dokumentation zu „certified app“
[11] datenschutz cert GmbH, „Prüfkonzept – Konzept zur Prüfung von Apps /
Kriterienkatalog für ‚certified app‘“, Version 1.0, 18.12.2015
[12] datenschutz cert GmbH, „Prüfschema – Verfahrensbeschreibung zur
Prüfung von Apps gemäß ‚certified app‘“, Version 1.0, 18.12.2015 (verfüg-
bar für Prüfstellen)
[13] datenschutz cert GmbH, „Zertifizierungsschema – Verfahrensbeschrei-
bung zur Zertifizierung von Apps gemäß ‚certified app‘“ (umgesetzt in
der Zertifizierungsstelle)
[14] datenschutz cert GmbH, „Prüfstelle – Anforderungen an eine Stelle zur
Prüfung von Apps gemäß ‚certified app‘“, Version 1.0, 18.12.2015 (verfüg-
bar für Prüfstellen)
Seite 60
Prüfkonzept – Konzept zur Prüfung von Apps / Kriterienkatalog gemäß „certified app": 18.12.2015
[15] datenschutz cert GmbH, „Zertifizierungsstelle – Anforderungen an eine
Stelle zur Zertifizierung von Apps gemäß ‚certified app‘“ (umgesetzt in
der Zertifizierungsstelle)
[16] datenschutz cert GmbH, „Vergabe- und Nutzungsbedingungen für ‚cer-
tified app‘“, Version 1.0, 18.12.2015
[17] datenschutz cert GmbH, „Selbstauskunft gemäß ‚certified app‘“, Excel-
Tabelle für App-Anbieter, Version 1.0
top related