Prüfkonzept – Konzept zur Prüfung von Apps / Krite ... · male aus der App extrahiert und gegen die Selbstauskunft abgeglichen: die App sel- ber mit Namen und Versionsnummer sowie

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


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


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


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


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


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


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


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


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


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 [email protected] 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


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


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


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


--- 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


--- 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


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


--- 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


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


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


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


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


--- 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


--- 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


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


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


--- 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


--- 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


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


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


--- 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


--- 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


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?


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


--- 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.


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


--- 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.


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.


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


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.


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


--- 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



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


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


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


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


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


--- 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


Anschrift: Konsul-Smidt-Str. 88a, 28217 Bremen

Tel.: 0421/6966-3250

Mail: [email protected]

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


Anschrift: Konsul-Smidt-Str. 88a, 28217 Bremen

Tel.: 0421/6966-3250

Mail: [email protected]

Seite 43


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


--- 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


--- 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


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


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


--- 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


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


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


Seite 51


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-






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-


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


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


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


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üfart Selbst-

auskunft

Plausibi-

litäts-

test

autom.

Test


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üfart Selbst-

auskunft

Plausibi-

litäts-

test

autom.

Test


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üfart Selbst-

auskunft

Plausibi-

litäts-

test

autom.

Test


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ü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


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


[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

Documents

Prüfkonzept – Konzept zur Prüfung von Apps / Krite ... · male aus der App extrahiert und gegen die Selbstauskunft abgeglichen: die App sel- ber mit Namen und Versionsnummer sowie