VdS-Richtlinien für rechnergestützte Informationssysteme

Smart Device Applikationen Anforderungen und Prüfmethoden

VdS 3169-1 : 2016-02 (02)

VdS 3169-1

Herausgeber und Verlag: VdS Schadenverhütung GmbH Amsterdamer Str. 172-174 50735 Köln Telefon: (0221) 77 66 0; Fax: (0221) 77 66 341 Copyright by VdS Schadenverhütung GmbH. Alle Rechte vorbehalten.

VdS 3169-1 : 2016-02 (02)

Smart Device Applikationen

VdS-Richtlinien für rechnergestützte Informationssysteme

Smart Device Applikationen Anforderungen und Prüfmethoden

Inhalt 1 1.1 1.2

Allgemeines ............................................................................................................. 5 Anwendungsbereich ............................................................................................. 5 Gültigkeit ............................................................................................................... 5

2 2.1 2.2

Begriffe und Abkürzungen ..................................................................................... 5 Begriffe .................................................................................................................. 5 Abkürzungen ......................................................................................................... 7

3

Normative Verweisungen ....................................................................................... 7

4

Klassifizierung ........................................................................................................ 8

5 Anforderungen ........................................................................................................ 9 5.1 Basisschutzmaßnahmen ...................................................................................... 9 5.1.1 Firewall .................................................................................................................. 9 5.1.2 Schutz vor Schadsoftware .................................................................................... 9 5.1.3 Nutzercode ............................................................................................................ 9 5.1.4 Länge und Zusammensetzung des Nutzercodes ................................................. 9 5.1.4.1 Klasse „2-Stern“ ................................................................................................ 9 5.1.4.2 Klasse „3-Stern“ ................................................................................................ 9 5.1.5 Verbindung zu Steuer- und Anzeigeeinrichtungen von sicherungstechnischen Anlagen ............................................................................................................... 10 5.1.6 Updatemanagement ........................................................................................... 10 5.1.7 Managementsystem für Informationssicherheit (ISMS)...................................... 10 5.2 Maßnahmen gegen Brute-Force-Angriffe ........................................................... 11 5.2.1 Zeitkonstante ...................................................................................................... 11 5.2.2 Vollsperre ............................................................................................................ 11 5.3 Maßnahmen gegen Reverse Engineering .......................................................... 11 5.3.1 Standard-Obfuskation ......................................................................................... 11 5.3.2 Höherwertige Obfuskation .................................................................................. 11 5.4 Maßnahmen gegen Vertraulichkeitsverlust auf dem Übertragungsweg............. 11 5.4.1 Online .................................................................................................................. 12 5.4.2 Offline .................................................................................................................. 12 5.5 Maßnahmen gegen Keylogger ........................................................................... 12 5.5.1 Individualtastatur ................................................................................................. 12 5.5.2 Scramble-Individualtastatur ................................................................................ 13 5.6 Maßnahmen gegen Vertraulichkeitsverlust auf dem Smart Device ................... 13 5.6.1 Verschlüsselte Speicherung ............................................................................... 13 5.6.2 Schutz der Integrität ............................................................................................ 13 5.6.3 Schutz durch „Secure Element“ .......................................................................... 13 5.7 Maßnahmen gegen Root-Exploits ...................................................................... 13

3

Smart Device Applikationen

VdS 3169-1 : 2016-02 (02)

6 Prüfmethoden ........................................................................................................ 14 6.1 Basisschutzmaßnahmen .................................................................................... 14 6.1.1 Firewall ................................................................................................................ 14 6.1.2 Schutz vor Schadsoftware .................................................................................. 14 6.1.3 Nutzercode .......................................................................................................... 14 6.1.3.1 Anforderungen an den Nutzercode – Klasse „2-Stern“ ................................... 15 6.1.3.2 Anforderungen an den Nutzercode – Klasse „3-Stern“ ................................... 15 6.1.4 Updatemanagement ........................................................................................... 15 6.1.5 Managementsystem für Informationssicherheit (ISMS)...................................... 16 6.2 Maßnahmen gegen Brute-Force-Angriffe ........................................................... 16 6.2.1 Zeitkonstante ...................................................................................................... 16 6.2.2 Vollsperre ............................................................................................................ 16 6.3 Maßnahmen gegen Reverse Engineering .......................................................... 17 6.3.1 Standard Obfuskation ......................................................................................... 17 6.3.2 Höherwertige Obfuskation .................................................................................. 17 6.4 Maßnahmen gegen Vertraulichkeitsverlust auf dem Übertragungsweg............. 17 6.4.1 Online .................................................................................................................. 18 6.4.2 Offline .................................................................................................................. 18 6.5 Maßnahmen gegen Keylogger ........................................................................... 18 6.5.1 Individualtastatur ................................................................................................. 18 6.5.2 Scramble-Individualtastatur ................................................................................ 18 6.6 Maßnahmen gegen Vertraulichkeitsverlust auf dem Smart Device ................... 19 6.6.1 Verschlüsselte Speicherung ............................................................................... 19 6.6.2 Schutz vor Integrität ............................................................................................ 19 6.6.3 Secure Element .................................................................................................. 19 6.7 Maßnahmen gegen Root-Exploits ...................................................................... 19 Anhang A Anforderungen an die Dokumentation ...................................................... 21 A.1 Dokumentationspflicht des Herstellers ............................................................... 21 A.2 Form und Qualität der Dokumentation................................................................ 21 A.3 Sprache der Dokumentation ............................................................................... 21 A.4 Sicherung der Dokumentationspflege................................................................. 21 Anhang B Inhaltliche Anforderungen an die Dokumentation ................................. 22 B.1 Betreiberdokumentation ...................................................................................... 22 B.1.1 Herstellerinformation und Listung von Fachunternehmen .................................. 22 B .1.2 Mindes tanforderungen an das S mart Device und das B etriebs s ys tem ........ 22 B.1.3 Dokumentation des Funktionsumfang der Applikation ....................................... 23 B.1.4 Installationsanleitung/Einrichtung der Applikation .............................................. 23 B.1.5 Bedienungsanleitung .......................................................................................... 23 B.1.6 Zertifikate, Prüf- und Anerkennungsnachweise .................................................. 23 B.1.7 Ratschläge, Fehleranalyse und Problembehandlung ......................................... 23 B.1.8 Frequently Asked Questions (FAQ) .................................................................... 24 B.1.9 Glossar ................................................................................................................ 24 B.2 Herstellerdokumentation ..................................................................................... 24 B.2.1 Entwicklungsdokumentation/Versionsschema ................................................... 24 B.2.2 Prozessdokumentation/Flussdiagramm.............................................................. 24 B.2.3 Programmdokumentation ................................................................................... 25 B.2.4 Quellcode-Listing ................................................................................................ 25

4

VdS 3169-1 : 2016-02 (02)

1

Allgemeines

1.1

Anwendungsbereich

Smart Device Applikationen

Smart-Device-Applikationen sind für eine Vielzahl von Anwendungen verfügbar. Oftmals entsteht ihr Nutzwert erst durch die Interaktion mit anderen computergestützten Informationseinrichtungen über öffentliche Netze. Bedingt durch den Informationsaustausch über öffentlich zugängliche Netze und Schnittstellen sowie die Mobilität und Verbreitung der Smart Devices entstehen in sicherheitskritischen Anwendungsbereichen nicht unerhebliche Risiken. Diese Richtlinien beschreiben die generellen Anforderungen und Prüfmethoden für die VdS-Anerkennung von Smart-Device-Applikationen. Ausgenommen sind Applikationen zum Einsatz in Verbindung mit brandschutztechnischen Anlagen. Hinweis: In Verbindung mit sicherungstechnischen Anlagen gelten zusätzlich die Richtlinien VdS 3169-2.

1.2

Gültigkeit

Diese Richtlinien können ab dem 01.02.2016 für die Prüfung und VdS-Anerkennung verwendet werden.

2

Begriffe und Abkürzungen

2.1

Begriffe

Browsergestützte Applikation Eine Applikation, die grundsätzlich nichts anderes ist als eine speziell programmierte HTMLSeite, die durch das Smart Device erkannt wird und für diese optimiert dargestellt wird. Brute-Force Angriff Ein Angriff auf einen kryptografischen Algorithmus, welcher versucht durch systematisches Ausprobieren aller Möglichkeiten den Algorithmus zu knacken. Certification Authority (CA) Eine Stelle, die die Identität einer Person oder Organisation prüft und dies mit einem Zertifikat belegt. Beim Kommunikationsaufbau zweier Parteien können dann die jeweiligen Zertifikate des Anderen von der CA geprüft und bestätigt werden. Somit wird für die Kommunikationspartner die Identität des jeweils anderen authentifiziert. Die CA fungiert dabei als unabhängige und glaubwürdige dritte Partei. Checksum-Funktion Eine Funktion, die eine Prüfsumme aus den Ausgangsdaten berechnet und somit mindestens einen Bitfehler bei der Datenübertragung erkennt. Mit einer Prüfsumme lässt sich leicht die Integrität der Daten überprüfen. Client In diesem Zusammenhang ist das mobile Endgerät (Smart Device) mit der Applikation zur Verbindung mit der sicherungstechnischen Anlage gemeint. 5

Smart Device Applikationen

VdS 3169-1 : 2016-02 (02)

Diffie-Hellman Schlüsselaustausch Verfahren zur Erzeugung und Austausch eines digitalen Schlüssels, ohne dass der Schlüssel jemals selbst über ein unsicheres Medium übertragen werden muss. (Root)-Exploit Eine systematische Möglichkeit, die bei der Programmierung einer Anwendung u. U. entstandenen Schwachstellen auszunutzen, um einem Angreifer den möglichen Zugriff auf geschützte Bereiche zu ermöglichen. Der Root-Exploit bezeichnet dabei den Versuch administrative Zugriffsrechte auf das Betriebssystem des Smart Device zu erlangen. Die Schwachstellen können dabei bspw. durch Fehlfunktionen von Programmbefehlen hervorgerufen werden. Keylogger Eine Hard- oder Software, die die Eingaben des Benutzers über die Tastatur im Hintergrund protokolliert. Oftmals dienen Keylogger dazu, vertrauliche Informationen auszuspähen (bspw. Kennwörter) und diese an unberechtigte Personen zu versenden. Master In diesem Zusammenhang ist die Zentraleinheit der sicherungstechnischen Anlage bzw. der Webserver bei browsergestützten Applikationen gemeint. Native Applikation Eine Applikation, die speziell für ein Betriebssystem (z. B. iOS, Android etc.) programmiert wurde und ausschließlich nur auf diesem lauffähig ist. Nutzercode Als Nutzercode wird eine vom Benutzer beliebig gewählte Zeichen-/Buchstabenfolge bezeichnet, die vor der Benutzung der Applikation durch Unberechtigte schützt. Der Nutzercode ist nicht mit dem Sperrcode gleichzusetzen und wird zu diesem als zusätzliche Sicherheitsmaßnahme eingesetzt. Pairing Kopplung zweier Kommunikationspartner unter Zuhilfenahme einmaliger Identifikationsmerkmale wie MAC-Adresse oder IMEI (Pairing Information). Für den Master ergibt sich eine 1:n-Struktur. Er akzeptiert nur Verbindungsanfragen von ihm bekannten Clients. Personal Unblocking Key (PUK) Ein elektronischer Schlüssel, mittels dessen eine Entsperrung einer vorher erkannten Fehlbedienung aufgehoben werden kann. In den vorliegenden Richtlinien sind damit bspw. die Entsperrung der Applikation oder die Initialisierung eines Re-Pairings gemeint. Secure Element Durch die Verknüpfung mit einem hardwareseitig eingebauten Sicherheitsmodul im Smart Device (Secure Element) kann durch kryptografische Verfahren ein zusätzlicher Schutz von sensiblen Daten erreicht werden. Dieses Secure Element kann in Form einer speziellen SIM-Karte, einer Mikro-SD-Karte oder eines implementierten Chips im Smart Device realisiert werden.

6

VdS 3169-1 : 2016-02 (02)

Smart Device Applikationen

Smart Device Tragbares Kommunikationsgerät, typischerweise Smartphone, Tablet oder ähnliches, auf dem die Applikation gestartet wird. Sperrcode Als Sperrcode wird eine vom Benutzer beliebig gewählte Zeichen-/Buchstabenfolge bezeichnet, die vor der Benutzung des Smart Device durch Unberechtigte schützt. Je nach Betriebssystem und VdS-Klasse kann die Länge und Komplexität des Sperrcodes variieren. Web-Application-Firewall Ein Verfahren oder Maßnahmen, die vor Angriffen mittels HTTP-Protokoll auf der Anwendungsebene schützen soll.

2.2

Abkürzungen

PUK

Personal Unblocking Key

AES

Advanced Encryption Standard

DH

Diffie-Hellman-Schlüsselaustausch

ISMS

Informations-Sicherheits-Management-System

CA

Certificate Authority oder Certification Authority

ISO

International Organization for Standardization

ISMS

Information Security Management System

CA

Certificate Authority

URL

Uniform Resource Locator

3

Normative Verweisungen

Diese Richtlinien enthalten datierte und undatierte Verweise auf andere Regelwerke. Die Verweise erfolgen in den entsprechenden Abschnitten, die Titel werden im Folgenden aufgeführt. Änderungen oder Ergänzungen datierter Regelwerke gelten nur, wenn sie durch Änderung dieser Richtlinien bekannt gegeben werden. Von undatierten Regelwerken gilt die jeweils letzte Fassung. VdS 2465

Richtlinien für das VdS-Übertragungsprotokoll für Gefahrenmeldungen

7

Smart Device Applikationen

4

VdS 3169-1 : 2016-02 (02)

Klassifizierung

Der Tabelle ist zu entnehmen, welche der nachfolgenden Anforderungen in welcher Klasse erfüllt sein müssen**.

Angriffsvektor

Maßnahme(n)

Abschnitt

Firewall

Basisangriffsvektor

Brute-Force-Angriff

Reverse Engineering Vertraulichkeitsverlust auf dem Übertragungsweg Keylogger

Vertraulichkeitsverlust auf dem Smart Device Root-Exploit

2-Stern

3-Stern

N/B

N/B

N/B

N/B

N/B

N/B

N/B

N/B

N/B

N/B

N/B

Web-ApplicationFirewall

5.1.1

Virenschutz

5.1.2

Nutzercode

5.1.3

Pairing-Verfahren

5.1.5

*

*

*

Updatemanagement

5.1.6

N/B

N/B

N/B

Zeitkonstante

5.2.1

N/B

N/B

N/B

Nutzercode-Länge

5.1.3

N/B

N/B

N/B

Vollsperre

5.2.2

Standard Obfuskation

5.3.1

Höherwertige Obfuskation

5.3.2

N/B N/-

N/N/-

Verschlüsselung (Online/Offline)

5.4

Individualtastatur

5.5.1

ScrambleIndividualtastatur

5.5.2

im Gerät verschlüsselt gespeichert

5.6.1

Integritätsschutz

5.6.2

N/B

Secure Element

5.6.3

N/B

Verhindern/Detektion

5.7

Tabelle 4-1: Klassifizierung *) wenn anwendbar, siehe jeweiliger Abschnitt **) N für native Apps, B für browsergestützte Apps

8

1-Stern

N/B

N/B

N/B

N/B N/B N/B

N/B

N/B

N/B

N/B

VdS 3169-1 : 2016-02 (02)

5

Anforderungen

5.1

Basisschutzmaßnahmen

5.1.1

Firewall

Smart Device Applikationen

Der Betreiber der Applikation muss in der Dokumentation darauf hingewiesen werden, dass für einen VdS-konformen Betrieb, sofern technisch möglich, eine Firewall auf dem Smart Device und dem Master verwendet werden muss. Weiterhin wird der Betreiber darauf hingewiesen, dass die Software der Firewall durch einen geeigneten Prozess automatisch und regelmäßig zu aktualisieren ist. Wenn der Master über ein öffentliches Netz erreichbar ist, gilt zusätzlich: Der Betreiber der Applikation muss in der Dokumentation darauf hingewiesen werden, dass für einen VdS-konformen Betrieb, sofern technisch möglich, eine Application Firewall auf dem Master verwendet werden muss. Weiterhin wird der Betreiber darauf hingewiesen, dass die Software der Application Firewall durch einen geeigneten Prozess automatisch und regelmäßig zu aktualisieren ist.

5.1.2

Schutz vor Schadsoftware

Der Betreiber der Applikation muss in der Dokumentation darauf hingewiesen werden, dass für den VdS-konformen Betrieb, die Nutzung eines geeigneten Schutzprogramms vor Schadsoftware auf dem Smart Device, dem Master und ggf. erforderlicher Server erforderlich ist. Weiterhin muss eine regelmäßige Überprüfung auf Schadsoftware und die automatische Aktualisierung der Signaturdatenbankempfohlen werden. Weiterhin muss der Betreiber darauf hingewiesen werden, dass er dafür Sorge zu tragen hat, dass im Falle einer Infektion durch Schadprogramme, der Virenfund vom Schutzprogramm dokumentiert und durch geeignete Maßnahmen behoben wird.

5.1.3

Nutzercode

Die Applikation darf nur durch Berechtigte gestartet werden können. Die Berechtigung muss durch die Eingabe eines Nutzercodes oder eines anderen, gleichwertigen Identifikationsmerkmals (z. B. Fingerabdruck) nachgewiesen werden. Der Nutzercode ist nicht gleichzusetzen mit dem Sperrcode des Smart Device. Für 1-/2-Stern gilt: Die vorgenannten Anforderungen entfallen, wenn durch die Applikation softwareseitig sichergestellt wird, dass ein Sperrcode im Betriebssystem verwendet wird. Der Nutzer ist in der Dokumentation auf die Wichtigkeit der Auswahl eines sicheren Nutzerund Sperrcodes hinzuweisen.

5.1.4

Länge und Zusammensetzung des Nutzercodes

5.1.4.1

Klasse „2-Stern“

Der Nutzercode muss eine Mindestlänge von 4 Zeichen haben und aus Kleinbuchstaben, Großbuchstaben oder Ziffern zusammengesetzt werden. 5.1.4.2

Klasse „3-Stern“

Der Nutzercode muss eine Mindestlänge von 8 Zeichen haben und aus Klein- und Großbuchstaben sowie Ziffern zusammengesetzt werden. Der Nutzer muss in regelmäßigen Abständen automatisch aufgefordert werden, seinen Nutzercode zu ändern.

9

Smart Device Applikationen

5.1.5

VdS 3169-1 : 2016-02 (02)

Verbindung zu Steuer- und Anzeigeeinrichtungen von sicherungstechnischen Anlagen

Es sind die zusätzlichen Anforderungen der weiteren Teile dieser Richtlinien zu erfüllen, soweit anwendbar.

5.1.6

Updatemanagement

Der Betreiber der Applikation muss in der Dokumentation darauf hingewiesen werden, dass es für einen VdS-konformen Betrieb erforderlich ist, stets die aktuelle Softwareversion der, für den ordnungsgemäßen Betrieb der Applikation erforderlichen Programme, auf dem Smart Device, dem Master und ggf. erforderlicher Server zu verwenden. Dies schließt vor allem auch die Applikation selbst und die jeweiligen Betriebssysteme der vorgenannten Hardwarekomponenten ein. Kann ein Update eines Masters bzw. ggf. erforderlicher Server nur durch einen Errichter erfolgen, hat der Betreiber dafür Sorge zu tragen, dass die Systemsoftware zeitnah vom Errichter aktualisiert wird. Es muss ein softwareseitiges Updatemanagement vorhanden sein, das dafür sorgt, dass die Applikation stets aktuell ist. Die Applikation muss bei jedem Aufruf durch den Nutzer (bei mehrfachem Aufruf pro Tag mindestens einmal) nach Updates suchen und den Nutzer informieren, sobald ein Update verfügbar ist (Hinweis). Der Nutzer hat dann noch eine gewisse Karenzzeit, die sich ab Kenntniserlangung durch die Applikation über die Verfügbarkeit eines Updates berechnet und aus Tabelle 5-1: Updatemanagement ergibt, um das Update der Applikation durchzuführen. Bei Überschreitung dieser Zeit darf die Applikation nicht mehr genutzt werden können (Zwangssperre). Wenn sowohl Master als auch Smart Device ohne Internetverbindung betrieben werden, ist die Anforderung an die Zwangssperre nicht relevant. Hinweis: Das Updatemanagement kann auch durch ein drittes Programm, z. B. ® ® App Store , Google play etc. realisiert werden. Klasse

Hinweis

Zwangssperre

1-Stern

sofort

nein

2-Stern

sofort

nach 30 Tagen

3-Stern

sofort

nach 7 Tagen

Tabelle 5-1: Updatemanagement

5.1.7

Managementsystem für Informationssicherheit (ISMS)

Sind für den ordnungsgemäßen Betrieb der Applikation ein oder mehrere Server, auf denen anlagenspezifische Daten gespeichert oder verwaltet werden, außerhalb des Einflussbereichs des Betreibers der Applikation notwendig, muss der Betreiber der Server (dritte Partei) für einen VdS-konformen Betrieb der Applikation über ein geeignetes und zertifiziertes ISMS nach anerkannten Standards (bspw. VdS 3475, ISO 27001 o. ä.) verfügen. Der Hersteller der Applikation muss das ISMS-Zertifikat der dritten Partei in der Dokumentation verzeichnen und über Art und Umfang der Datenverarbeitung und -speicherung hinweisen.

10

VdS 3169-1 : 2016-02 (02)

5.2

Maßnahmen gegen Brute-Force-Angriffe

5.2.1

Zeitkonstante

Smart Device Applikationen

Wird ein falscher Nutzercode eingegeben, ist durch eine Zeitverzögerung sicherzustellen, dass der nächste Eingabeversuch erst nach Ablauf einer bestimmten Zeit erfolgen kann. Die Zeit t berechnet sich in Abhängigkeit der Fehlversuche n nach t = 2n Sekunden.

5.2.2

Vollsperre

Werden nacheinander zehn Falscheingaben des Nutzercodes getätigt, ist das Starten der Applikation vollständig zu blockieren. Um die Vollsperre aufzuheben, muss ein PUK abgefragt werden. Wird der PUK dreimal hintereinander falsch eingegeben, so sind alle auf diese Applikation bezogenen hinterlegten Informationen zu löschen. Der Betreiber der Applikation ist in der Dokumentation auf die vollständige Löschung der Daten hinzuweisen.

5.3

Maßnahmen gegen Reverse Engineering

5.3.1

Standard-Obfuskation

Bei Applikationen der Klassen 1-Stern oder 2-Stern muss der Quellcode mittels standardmäßig vom Entwicklungssystem angebotener Verschleierungsmechanismen (Obfuskation) gegen Reverse Engineering geschützt sein.

5.3.2

Höherwertige Obfuskation

Bei 3-Sterne Applikationen muss der Quellcode mittels hochwertiger Verschleierungsmechanismen (Obfuskation) gegen Reverse Engineering geschützt sein. Die standardmäßig vom Entwicklungssystem angebotenen Obfuskationsverfahren sind nicht (ausschließlich) zu verwenden.

5.4

Maßnahmen gegen Vertraulichkeitsverlust auf dem Übertragungsweg

Die Vertraulichkeit und Integrität der Daten, die über Datennetze übermittelt werden, sind sicherzustellen. Dies muss durch geeignete Verfahren und Algorithmen (z. B. HTTPSVerbindungen mit aktuellen Verschlüsselungsverfahren und Nutzung von ChecksumFunktionen) erfolgen. HTTPS-Verbindungen sind mindestens mit einem SHA-256 Bit Zertifikatunterzeichnungsalgorithmus zu erstellen. Um die HTTPS-Verbindungen nicht zu gefährden sollten Protokolle • TLS 1.0 verwendet werden. Veraltete Protokolle < TLS 1.0 dürfen nicht angeboten werden. Der Hersteller muss die angewendeten Verfahren und Algorithmen in der Herstellerdokumentation aufführen. Zertifikate müssen auf ihre Gültigkeit hin überprüft werden. Nur gültige Zertifikate dürfen verwendet werden. Hinweis: Grundsätzlich sind immer hohe und aktuelle Verschlüsselungsprotokolle und Checksum-Funktionen zu verwenden, die in den Richtlinien für das VdSÜbertragungsprotokoll für Gefahrenmeldungen, Version 2, Ergänzung S2: Protokollerweiterung zur Anschaltung an Netze der Protokollfamilie TCP, VdS 2465 beschrieben oder 11

Smart Device Applikationen

VdS 3169-1 : 2016-02 (02)

sich an den Empfehlungen zur Informationssicherheit öffentlicher Behörden und Organisationen (z. B. Bundesamt für Sicherheit in der Informationstechnik (BSI) oder Internationale Organisation für Normung (ISO)) orientieren.

5.4.1

Online

Wenn die Kommunikation der Applikation über HTTPS erfolgt, sind die folgenden Zertifikatsklassen vorgeschrieben. Klasse

Zertifikatsklasse

Symmetrische Schlüsselstärke

Asymmetrische Schlüsselstärke

1-Stern

Domain-Validierung

• 1024 Bit

• 128 Bit

2-Stern

OrganisationValidierung

• 2048 Bit

• 256 Bit

3-Stern

Extended-Validation

• 4096 Bit

• 256 Bit

Wenn in der Applikation der oder die Master und ggf. weitere erforderliche Server festgelegt sind und diese nicht geändert sowie über allgemein verfügbare Browser aufgerufen werden können und weiterhin das Zertifikat der vertrauenswürdigen CA vom Hersteller integriert ist und nicht geändert werden kann, dürfen auch selbst ausgestellte Zertifikate verwendet werden, die aus dieser vertrauenswürdigen CA abgeleitet sind, Die Anforderungen an Schlüsselstärke und verwendete Algorithmen bleiben davon unberührt.

5.4.2

Offline

Wenn der Master nicht über ein öffentliches Netz erreichbar ist, gilt: Klasse

Zertifikatsklasse

Symmetrische Schlüsselstärke

Asymmetrische Schlüsselstärke

1-Stern

selbst signiert *

• 1024 Bit

• 128 Bit

2-Stern

selbst signiert *

• 2048 Bit

• 256 Bit

3-Stern

selbst signiert *

• 4096 Bit

• 256 Bit

*) Durch den Hersteller selbst signierte oder durch ein vom Hersteller vorgegebenes Verfahren signierte Zertifikate müssen durch ein geeignetes Verfahren beim Verbindungsaufbau authentifiziert werden. Das Zertifikat muss auf einem sicheren Weg in den Client gelangen, z. B. indem es in der Applikation „ab Werk“ integriert ist.

5.5

Maßnahmen gegen Keylogger

5.5.1

Individualtastatur

Um einen Schutz gegen das Mitschreiben der Tastatureingaben (Keylogger) zu gewährleisten, dürfen nicht die angebotenen Standard-Programmbibliotheken der Entwicklungsumgebung für Tastaturen verwendet werden. Es ist eine Tastaturfunktion zu implementieren, bei der die Informationen der Tasteneingaben nur innerhalb der Applikation erzeugt und verarbeitet werden, sodass Tasteneingaben nicht über eine Schnittstelle vom Betriebssystem in die Applikation eingespeist oder ausgelesen werden können. Hinweis: Die vorgenannten Anforderungen gelten nur, wenn nicht der Sperrcode des Betriebssystems verwendet wird.

12

VdS 3169-1 : 2016-02 (02)

5.5.2

Smart Device Applikationen

Scramble-Individualtastatur

Um einen hinreichenden Schutz gegen das Mitschreiben der Tastatureingaben (Keylogger) auch für Applikationen höherer Klassen (siehe Tabelle 4-1: Klassifizierung) zu gewährleisten, muss eine Individualtastatur (Abschnitt 5.5.1) eingesetzt werden, die zusätzlich die Anordnung der Button zufällig neu berechnet (Scramble-Funktion).

5.6

Maßnahmen gegen Vertraulichkeitsverlust auf dem Smart Device

5.6.1

Verschlüsselte Speicherung

Die Vertraulichkeit der Daten, die auf dem Smart Device für die betreffende Applikation gespeichert werden, ist sicherzustellen. Der Hersteller der Applikation muss dies durch die Verwendung speziell geschützter Speicherbereiche oder einer geeigneten Verschlüsselung der Daten (z. B. AES) sicherstellen. Grundsätzlich gilt: Die Speicherung von Daten auf dem Smart Device sollte sich an dem Grundsatz ausrichten, dass so wenig wie möglich und nur so viel wie gerade nötig gespeichert wird. Alle Daten die auf dem Master abgerufen werden können, dürfen auch nur dort gespeichert werden. Der Hersteller muss in der Herstellerdokumentation die verwendeten Speicherbereiche sowie das verwendete Verschlüsselungsverfahren dokumentieren.

5.6.2

Schutz der Integrität

Bei Klasse 3-Stern gilt: Die Integrität der Applikationsdaten, die auf dem Smart Device gespeichert oder übertragen werden, ist sicherzustellen. Dies muss durch die Verwendung einer geeigneten und aktuellen Prüfsummenfunktion der Daten erfolgen. Nicht integre Daten dürfen nicht durch die Applikation verarbeitet und müssen verworfen werden. Zu der Eignung und Aktualität der zu verwendenden Prüfsummenfunktion ist der Hinweis in 5.4 zu beachten.

5.6.3

Schutz durch „Secure Element“

Bei Klasse 3-Stern gilt: Die Applikationsdaten sind, sofern technisch möglich, in einem Secure-Element zu speichern. Der Hersteller muss den Betreiber der Applikation in der Betreiberdokumentation darauf hinweisen, dass die Verwendung eines Secure-Elements im Smart Device einen Mehrwert an Sicherheit bietet und die Verwendung eines geeigneten Smart Device empfehlen.

5.7

Maßnahmen gegen Root-Exploits

Der Betreiber der Applikation muss in der Dokumentation darauf hingewiesen werden, dass für einen VdS-konformen Betrieb, sofern technisch möglich, geeignete Maßnahmen zum Schutz des Smart Device vor (Root-)Exploits zu ergreifen sind und dass er sich bei Bekanntwerden eines Exploits umgehend beim Hersteller zu informieren hat, ob ein behebendes Softwareupdate verfügbar ist. Ist dies der Fall liegt es in seinem Verantwortungsbereich dies zu installieren. Die Applikation muss zuverlässig erkennen, wenn der Betreiber die Applikation mit administrativen Berechtigungen ausführt oder diese während der Nutzung erlangt. In diesem Fall muss die Applikation augenblicklich beendet werden und gegen Neustart gesichert werden. 13

Smart Device Applikationen

6

Prüfmethoden

6.1

Basisschutzmaßnahmen

6.1.1

Firewall

VdS 3169-1 : 2016-02 (02)

Es wird geprüft, ob der Hersteller in der Betreiberdokumentation darauf hinweist, dass für den VdS-konformen Betrieb der Applikation eine Firewall auf dem Smart Device bzw. auf dem Master betrieben werden muss und entsprechende Maßnahmen für die automatische und regelmäßige Aktualisierung der Firewall Software empfiehlt. Annahme-/Zurückweisungskriterien: Das vorgenannte Prüfkriterium ist bestanden, wenn die Betreiberdokumentation einen entsprechenden Hinweis zum Betrieb einer Firewall auf dem Smart Device bzw. auf dem Master und Maßnahmen zur automatischen und regelmäßigen Aktualisierung enthält. Es wird geprüft, ob der Master über ein öffentliches Netz erreichbar ist. Ist dies der Fall wird geprüft ob der Hersteller in der Betreiberdokumentation darauf hinweist, dass für den VdS-konformen Betrieb der Applikation eine Application-Firewall auf dem Master betrieben werden muss und entsprechende Maßnahmen für die automatische und regelmäßige Aktualisierung der Application-Firewall Software empfiehlt. Annahme-/Zurückweisungskriterien: Das vorgenannte Prüfkriterium ist bestanden, wenn die Betreiberdokumentation einen entsprechenden Hinweis zum Betrieb einer Application-Firewall auf dem Master und Maßnahmen zur automatischen und regelmäßigen Aktualisierung enthält.

6.1.2

Schutz vor Schadsoftware

Es wird geprüft, ob der Hersteller in der Betreiberdokumentation darauf hinweist, dass für den VdS-konformen Betrieb der Applikation ein aktuelles Schutzprogramm vor Schadsoftware auf dem Smart Device, dem Master und ggf. weiterer Server betrieben werden muss und eine regelmäßige Überprüfung und automaische Aktualisierung der Signaturdatenbank empfiehlt. Annahme-/Zurückweisungskriterien: Das vorgenannte Prüfkriterium ist bestanden, wenn die Betreiberdokumentation einen entsprechenden Hinweis zur Nutzung eines Schutzprogramms vor Schadsoftware auf dem Smart Device, dem Master und ggf. weiterer Server enthält und eine regelmäßige Überprüfung und automatische Aktualisierung der Signaturdatenbank empfiehlt. Es wird geprüft, ob der Hersteller in der Betreiberdokumentation darauf hinweist, dass für den VdS-konformen Betrieb der Applikation, der Betreiber dafür Sorge zu tragen hat, dass im Falle einer Infektion durch ein Schadprogramm der Virenfund vom Schutzprogramm dokumentiert und durch geeignete Maßnahmen behoben wird. Annahme-/Zurückweisungskriterien: Das vorgenannte Prüfkriterium ist bestanden, wenn die Betreiberdokumentation einen entsprechenden Hinweis enthält, dass der Betreiber dafür Sorge zu tragen hat, dass im Falle einer Infektion durch ein Schadprogramm der Virenfund vom Schutzprogramm dokumentiert und durch geeignete Maßnahmen behoben wird.

6.1.3

Nutzercode

Es wird geprüft, ob das Starten der Applikation die Eingabe eines Nutzercodes gemäß Abs. 5.1.3 oder den Nachweis eines anderen, gleichwertigen Identifikationsmerkmals (z. B. Fingerabdruck) voraussetzt. 14

VdS 3169-1 : 2016-02 (02)

Smart Device Applikationen

Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn beim Starten der Applikation ein entsprechendes Identifikationsmerkmal abgefragt wird. Für 2-Stern gilt: Es wird geprüft, ob beim Starten der Applikation die Einrichtung eines Sperrcodes im Smart Device überprüft wird. Ist dies der Fall, entfallen die genannten Anforderungen an den Nutzercode. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn die Applikation die Einrichtung eines Sperrcodes im Smart Device erfolgreich überprüft. Es wird geprüft, ob die Bedienungsanleitung für den Betreiber der Applikation einen Hinweis über die Wichtigkeit der Auswahl eines sicheren Nutzer- und Sperrcodes enthält. Annahme-/Zurückweisungskriterium: Die Prüfung ist bestanden, wenn die Bedienungsanleitung einen entsprechenden Hinweis über die Wichtigkeit der Auswahl eines sicheren Nutzer- und Sperrcodes enthält. 6.1.3.1

Anforderungen an den Nutzercode – Klasse „2-Stern“

Es wird geprüft, ob die Mindestanforderungen an den Nutzercode nach 5.1.4.1 erfüllt werden. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn verschiedene und zufällig erstellte Nutzercodes abgelehnt werden, die den Mindestanforderungen nach 5.1.4.1 nicht entsprechen. 6.1.3.2

Anforderungen an den Nutzercode – Klasse „3-Stern“

Es wird geprüft, ob die Mindestanforderungen an den Nutzercode nach 5.1.4.2 erfüllt werden. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn verschiedene und zufällig erstellte Nutzercodes abgelehnt werden, die den Mindestanforderungen nach 5.1.4.2 nicht entsprechen. Es wird geprüft, ob der Nutzer in regelmäßigen Abständen automatisch auffordert wird seinen Nutzercode zu ändern. Annahme-/Zurückweisungskriterium: Die Prüfung ist bestanden, wenn der Nutzer in regelmäßigen Abständen automatisch aufgefordert wird, seinen Nutzercode zu ändern. Hinweis: Der Nachweis kann z. B. durch das Vorhandensein einer entsprechenden Routine im Quellcode erbracht werden.

6.1.4

Updatemanagement

Es wird geprüft, ob der Hersteller in der Betreiberdokumentation darauf hinweist, dass für den VdS-konformen Betrieb stets die aktuelle Softwareversion aller, für den ordnungsgemäßen Betrieb der Applikation, erforderlichen Programme auf dem Smart Device, dem Master und ggf. erforderlicher Server verwendet werden müssen. Die Applikation selbst und die jeweiligen Betriebssysteme der vorgenannten Hardwarekomponenten müssen ebenfalls explizit erwähnt werden. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn die Betreiberdokumentation einen entsprechenden Hinweis zur Nutzung der aktuellen Softwareversion aller für den ordnungsgemäßen Betrieb der Applikation erforderlichen Software auf dem Smart Device, dem Master und ggf. erforderlicher Server enthält, sowie 15

Smart Device Applikationen

VdS 3169-1 : 2016-02 (02)

ein Hinweis auf Nutzung der aktuellen Betriebssystemversionen der vorgenannten Hardwarekomponenten und der Applikation selbst. Es wird geprüft, ob die Applikation bei jedem Starten (bei mehrfachem Aufruf pro Tag mindestens einmal) nach Updates sucht und den Betreiber informiert, sobald ein Update verfügbar ist. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn ein entsprechender Hinweis den Betreiber bei Vorliegen eines Updates informiert bzw. diese Funktionalität anhand des Quellcodes nachvollzogen werden kann. Es wird geprüft, ob sich die Applikation nicht mehr starten lässt, wenn seit der Kenntniserlangung der Applikation über das Vorhandensein eines Updates die in 5.1.6 definierte Karenzzeit überschritten ist. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn sich die Applikation nach der definierten Karenzzeit nicht mehr starten lässt bzw. diese Funktionalität anhand des Quellcodes nachvollzogen werden kann.

6.1.5

Managementsystem für Informationssicherheit (ISMS)

Nachfolgende Kriterien müssen geprüft werden, wenn für den ordnungsgemäßen Betrieb der Applikation ein oder mehrere Server, auf denen anlagenspezifische Daten gespeichert oder verwaltet werden, außerhalb des Einflussbereichs des Betreibers der Applikation notwendig sind. Es wird geprüft, ob der Hersteller ein allgemein anerkanntes ISMS-Zertifikat des Serverbetreibers in der Herstellerdokumentation verzeichnet hat. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn ein Zertifikat vorliegt, dass der Betreiber der Server ein geeignetes ISMS nach anerkannten Standards implementiert hat. Es wird geprüft, ob ein entsprechender Hinweis in der Betreiberdokumentation über Art und Umfang der Datenverarbeitung und -speicherung vorhanden ist Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn die Betreiberdokumentation einen entsprechenden Hinweis enthält, der den Betrieb von ein oder mehreren Servern außerhalb des Einflussbereichs des Betreibers und über Art und Umfang der Datenverarbeitung und -speicherung informiert.

6.2

Maßnahmen gegen Brute-Force-Angriffe

6.2.1

Zeitkonstante

Es wird geprüft, ob bei Eingabe eines falschen Nutzercodes der nächste Eingabeversuch durch eine Zeitkonstante nach 5.2.1 verzögert wird. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn der nächste Eingabeversuch des Nutzercodes nach vorheriger Fehleingabe um die Zeit t nach 5.2.1 verzögert wird.

6.2.2

Vollsperre

Es wird geprüft, ob nach zehnfacher Falscheingabe des Nutzercodes das Starten der Applikation vollständig blockiert ist.

16

VdS 3169-1 : 2016-02 (02)

Smart Device Applikationen

Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn nach zehnfacher Falscheingabe des Nutzercodes das Starten der Applikation blockiert ist. Es wird geprüft, ob die Vollsperre durch die Eingabe eines PUK deaktiviert werden kann. Annahme-/Zurückweisungskriterium: Die Prüfung ist bestanden, wenn die Vollsperre durch die Eingabe des richtigen PUK aufgehoben ist. Es wird geprüft, ob nach dreimaliger Falscheingabe des PUK alle anwendungsbezogenen Informationen gelöscht werden. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn nach dreimaliger Falscheingabe des PUK alle anwendungsbezogenen Daten gelöscht sind. Es wird geprüft, ob der Hersteller in der Betreiberdokumentation darauf hinweist, dass nach dreimaliger Falscheingabe des PUK alle anwendungsbezogene hinterlegte Daten vollständig gelöscht werden. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn die Betreiberdokumentation einen entsprechenden Hinweis auf vollständige Löschung der Daten nach dreimaliger Falscheingabe des PUK enthält.

6.3

Maßnahmen gegen Reverse Engineering

6.3.1

Standard Obfuskation

Es wird geprüft, ob der Quellcode der (1- oder 2-Stern) Applikation grundlegend obfuskiert ist. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn der Quellcode, durch standardmäßig einfache Obfuskationsmethoden verschleiert ist.

6.3.2

Höherwertige Obfuskation

Es wird geprüft ob der Quellcode der 3-Sterne Applikation hochwertig obfuskiert ist. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn der Quellcode, durch hochwertige Obfuskationsmethoden verschleiert ist und nicht (ausschließlich) standardmäßig einfache Obfuskationsmethoden verwendet sind.

6.4

Maßnahmen gegen Vertraulichkeitsverlust auf dem Übertragungsweg

Es wird geprüft, ob der Hersteller geeignete Verfahren zur Sicherung von Daten bei der Übermittlung über Datennetze einsetzt (z. B. HTTPS) und die genannten Anforderungen nach 5.4 mindestens erfüllt. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn die Anforderungen hinsichtlich der Sicherungsverfahren für Daten bei der Übermittlung nach 5.4 mindestens erfüllt. Es wird geprüft, ob der Hersteller die verwendeten Verfahren und Algorithmen zur Sicherung von Daten bei der Übermittlung in der Herstellerdokumentation aufführt. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn die verwendeten Verfahren und Algorithmen in der Herstellerdokumentation aufgeführt sind.

17

Smart Device Applikationen

VdS 3169-1 : 2016-02 (02)

Es wird geprüft, ob bei der Übermittlung von Daten nur gültige Zertifikate verwendet und akzeptiert werden. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn die ausschließliche Verwendung von gültigen Zertifikaten bei der Datenübermittlung gesichert ist. Dies kann durch Verwendung mehrerer ungültiger Zertifikate bestätigt werden.

6.4.1

Online

Es wird geprüft, ob bei der Kommunikation zwischen Smart Device, Master und ggf. weiterer Server eine Verschlüsselung eingesetzt wird und die Schlüsselstärke der entsprechenden Zertifikatsklasse nach 5.4.1 entspricht. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn eine Abfrage aller möglichen Schlüsselstärken auf dem Master und ggf. verwendeter Server mindestens die Anforderungen der entsprechenden Zertifikatsklasse nach Tabelle 5.4.1 erfüllt.

6.4.2

Offline

Es wird geprüft, ob bei der Kommunikation zwischen Smart Device, Master und ggf. weiterer Server eine Verschlüsselung eingesetzt wird und die Schlüsselstärke der entsprechenden Zertifikatsklasse nach 5.4.2 entspricht. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn eine Abfrage aller möglichen Schlüsselstärken auf dem Master und ggf. verwendeter Server mindestens die Anforderungen der entsprechenden Zertifikatsklasse nach Tabelle 5.4.2 erfüllt.

6.5

Maßnahmen gegen Keylogger

6.5.1

Individualtastatur

Es wird geprüft, ob in der Applikation bei fehlendem Sperrcode auf dem Smart Device eine herstellereigene Individualtastatur wirksam implementiert ist. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn anhand des Quellcodes nachvollzogen werden kann, dass eine herstellereigene Tastaturfunktion wirksam implementiert ist.

6.5.2

Scramble-Individualtastatur

Es wird geprüft, ob in der Applikation eine herstellereigene Individualtastatur wirksam implementiert ist. Zusätzlich soll bei jedem Aufruf die Anordnung der Button verwürfelt werden (Scramble-Funktion). Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn anhand des Quellcodes nachvollzogen werden kann, dass eine herstellereigene Tastaturfunktion wirksam implementiert ist. Zusätzlich muss bei jedem Aufruf der Tastatur die Anordnung der Button verwürfelt (Scramble-Funktion) werden.

18

VdS 3169-1 : 2016-02 (02)

Smart Device Applikationen

6.6

Maßnahmen gegen Vertraulichkeitsverlust auf dem Smart Device

6.6.1

Verschlüsselte Speicherung

Es wird geprüft, ob Daten in speziell gesicherten Speicherbereichen oder verschlüsselt auf dem Smart Device abgelegt werden. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn die Daten in speziell gesicherten Speicherbereichen oder verschlüsselt auf dem Smart Device abgelegt werden. Es wird geprüft, ob der Hersteller den Ablageort der Daten oder das verwendete Verschlüsselungsverfahren in der Herstellerdokumentation aufgeführt hat. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn der verwendete Ablageort oder das Verschlüsselungsverfahren in der Herstellerdokumentation aufgeführt ist.

6.6.2

Schutz vor Integrität

Es wird geprüft, ob Prüfsummen der übertragenen Daten erzeugt und von der Applikation geprüft werden. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn eine Veränderung mehrerer Prüfsummen von zu verarbeitenden Daten von der Applikation verworfen werden.

6.6.3

Secure Element

Es wird geprüft, ob das Secure Element verwendet wird und die Daten dort gespeichert werden. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn anhand des Quellcodes oder eines Einblicks in das Dateisystem des Smart Device nachvollzogen werden kann, dass die Daten der Applikation in einem Secure Element gespeichert werden. Es wird geprüft, ob der Hersteller den Betreiber in der Betreiberdokumentation auf den zusätzlichen Schutz durch ein Secure-Element hinweist und die Verwendung eines geeigneten Smart Device empfiehlt. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn entsprechende Hinweise in der Betreiberdokumentation vorhanden sind.

6.7

Maßnahmen gegen Root-Exploits

Es wird geprüft, ob in der Betreiberdokumentation ein Hinweis enthalten ist, dass der Betreiber für einen VdS-konformen Betrieb dafür Sorge zu tragen hat, dass Maßnahmen zum Schutz vor (Root-)Exploits ergriffen werden und dass er bei Bekanntwerden entsprechender Exploits sich umgehend bei dem Hersteller zu informieren hat, ob ein behebendes Softwareupdate verfügbar ist. Wenn ein Update vorhanden ist, wird er verpflichtet dies zu installieren. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn entsprechende Hinweise in der Betreiberdokumentation vorhanden sind.

19

Smart Device Applikationen

VdS 3169-1 : 2016-02 (02)

Es wird geprüft, ob in der Applikation zuverlässig erkennt wird, dass ein Betreiber administrative Berechtigungen auf dem Smart Device (erlangt) hat. Ist dies der Fall muss die (weitere) Ausführung der Applikation augenblicklich unterbunden werden. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn eine Ausführung der Applikation mit administrativen Rechten auf dem Smart Device die Applikation augenblicklich beendet und gegen Neustart sichert.

20

VdS 3169-1 : 2016-02 (02)

Anhang A A.1

Smart Device Applikationen

Anforderungen an die Dokumentation

Dokumentationspflicht des Herstellers

Der Hersteller der Applikation muss zum Zeitpunkt der Auslieferung mindestens eine Hersteller- und eine Betreiberdokumentation vorlegen. In der Betreiberdokumentation sind relevante Informationen für den Betreiber zu hinterlegen und dem Betreiber spätestens mit Auslieferung der Applikation zur Verfügung zu stellen. Es steht dem Hersteller frei dem Betreiber ebenfalls die Herstellerdokumentation auszuhändigen. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn dem VdS-Prüflabor eine Betreiber- und eine Herstellerdokumentation der Applikation vorliegen. Hinweis: Die Dokumentationen sollten zur Prüfung in elektronischer Form (möglichst als pdf) bereitgestellt werden.

A.2

Form und Qualität der Dokumentation

Die Dokumentation der Applikation ist grundsätzlich an keine vordefinierte Form gebunden, muss aber eine durchgängig hohe Qualität aufweisen. Hierbei bilden die Dokumente zusammenhängende Sätze von Informationen, aus denen die geforderten Inhalte eindeutig nachweisbar hervorgehen. Hinweis: Qualitative Anforderungen an eine Dokumentation sind im Hinblick auf die Konsistenz, Aktualität, Richtigkeit, Vollständigkeit, Verständlichkeit, Relevanz, Umfang, Nachvollziehbarkeit und der Aussagekraft der Beschreibungen zu beachten.

A.3

Sprache der Dokumentation

Die Betreiberdokumentation ist in der jeweiligen Amtssprache des Vertriebslandes abzufassen und dem Betreiber entsprechend zur Verfügung zu stellen. Die Herstellerdokumentation ist mindestens in der Amtssprache des Herstellers zu verfassen. Hinweis: Für eine Prüfung durch die VdS-Laboratorien sind beide Dokumentationen in der deutschen Sprache abzufassen. Wird die Applikation ausschließlich in nicht deutschsprachigen Ländern vertrieben, reicht eine Anfertigung beider Dokumentationen in englischer Sprache. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn Betreiber- und Herstelldokumentation in der deutschen oder englischen Sprache vorliegen.

A.4

Sicherung der Dokumentationspflege

Der Hersteller muss ein Verfahren implementieren welches gewährleistet, dass die Dokumentation ständig auf aktuellem Stand gehalten wird und mit Auslieferung der Applikationsversion übereinstimmt. Ebenfalls muss das Verfahren Maßnahmen gegen absichtliche und unabsichtliche Falscheinträge enthalten. Das Verfahren muss vom Hersteller dokumentiert sein. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn der Hersteller das Verfahren zur Sicherung der Dokumentationspflege dokumentiert hat und dies vom VdS-Prüflabor als geeignet angesehen wird.

21

Smart Device Applikationen

Anhang B B.1

VdS 3169-1 : 2016-02 (02)

Inhaltliche Anforderungen an die Dokumentation

Betreiberdokumentation

Die Betreiberdokumentation muss alle Dokumente aus den Anforderungen dieser Richtlinien enthalten. Darüber hinaus müssen die nachfolgenden Beschreibungen enthalten sein.

B.1.1

Herstellerinformation und Listung von Fachunternehmen

In der Betreiberdokumentation ist der Hersteller der Applikation und dessen Kontaktmöglichkeit eindeutig aufzuführen. Dieser setzt sich mindestens aus einer postalischen Anschrift, einer Telefonnummer und einer E-Mail-Adresse zusammen. Ist für Rückfragen des Betreibers ein vertretendes Unternehmen oder eine Einrichtung zuständig, so ist diese Kontaktmöglichkeit ebenfalls aufzuführen. Außerdem ist in der Betreiberdokumentation ein Hinweis auf die Beachtung aktueller Produktinformationen des Herstellers enthalten. Die Produktinformationen sind einer Webseite (Angabe der URL) des Herstellers zu entnehmen. Ist die Einrichtung, der Betrieb oder die Wartung der Applikation nur durch herstellerseitig anerkannte Fachunternehmen möglich, so sind diese ebenfalls in der Betreiberdokumentation oder ein Hinweis auf eine ersetzende Quelle (bspw. URL im Internet) verfügbar zu machen. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn in der Betreiberdokumentation der Hersteller mit Kontaktmöglichkeit aufgeführt ist. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn in der Betreiberdokumentation der Hinweis auf Beachtung aktueller Produktinformationen mit Angabe der URL enthalten ist. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn in der Betreiberdokumentation, insofern notwendig, eine Listung von Fachunternehmen oder ein Hinweis auf eine ersetzende Quelle erfolgt.

B .1.2

Mindes tanforderungen an das S mart Devic e und das B etriebs s ys tem

Folgende Informationen müssen in der Betreiberdokumentation aufgeführt sein: 1. Mindestanforderungen an die unterstützende Hardware (bspw. Prozessorleistung, benötigte Kommunikationsmodule, Speicheranforderungen, etc.) 2. Welche Betriebssysteme werden von der Applikation unterstützt. 3. Welche unterstützende Software ggf. auf dem Smart Device noch benötigt wird (bspw. VPN Client, etc.). Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn o. g. Informationen in der Betreiberdokumentation enthalten sind.

22

VdS 3169-1 : 2016-02 (02)

B.1.3

Smart Device Applikationen

Dokumentation des Funktionsumfang der Applikation

Der Hersteller muss eine Listung mit aussagekräftiger Kurzbeschreibung aller durch den Betreiber bedienbarer Funktionen der Applikation vornehmen. Hinweis: Es steht dem Hersteller frei auch implizite Funktionen zu beschreiben. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn in der Betreiberdokumentation alle Funktionen, die durch den Betreiber bedient werden können, mit einer aussagekräftigen Kurzbeschreibung aufgeführt sind.

B.1.4

Installationsanleitung/Einrichtung der Applikation

Es ist eine Anleitung zur Installation und Konfiguration der Applikation zur Verfügung zu stellen. Ist vom Hersteller eine Standard-Konfiguration mit der Applikation ausgeliefert worden, so ist diese, sowie die Auswirkung einer möglichen Änderung durch den Betreiber, zu erläutern. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn in der Betreiberdokumentation eine vollständige Anleitung zur Installation und Konfiguration der Applikation vorhanden ist. Gegebenenfalls muss die ausgelieferte StandardKonfiguration beschrieben sein.

B.1.5

Bedienungsanleitung

Der Hersteller muss eine aussagekräftige und in der Problemwelt des Betreibers verfasste Bedienungsanleitung zur Verfügung stellen. Dabei ist die Bedienungsanleitung in der Amtssprache des jeweiligen Vertriebslandes zu verfassen. Hinweis: Für eine Prüfung durch die VdS-Laboratorien ist die Bedienungsanleitung in der deutschen Sprache abzufassen. Wird die Applikation ausschließlich in nicht deutschsprachigen Ländern vertrieben, reicht eine Anfertigung in englischer Sprache. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn eine Bedienungsanleitung vorhanden ist, welche die Bedienung der Applikation verständlich und mindestens in deutscher und/oder englischer Sprache beschreibt.

B.1.6

Zertifikate, Prüf- und Anerkennungsnachweise

Sind im Sinne der Anforderungen aus 5.1.7 dieser Richtlinien Zertifikate und Prüfnachweise anderer Hersteller erforderlich, sind diese in einer aussagekräftigen Kurzdarstellung mit dem jeweiligen Geltungsbereich aufzuführen. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn in der Betreiberdokumentation, insofern notwendig, Zertifikate und Prüfnachweise anderer Hersteller aussagekräftig und mit entsprechendem Geltungsbereich vorhanden sind.

B.1.7

Ratschläge, Fehleranalyse und Problembehandlung

Der Hersteller muss in der Betreiberdokumentation bekannte Fehler der Applikation oder mögliche Probleme des Betreibers bei der Bedienung aufführen und eine kurze Fehleranalyse mit geeigneten und für den Betreiber verständlichen Gegenmaßnahmen darstellen. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn die Betreiberdokumentation bekannte Fehler und Bedienprobleme der Applikation, sowie eine Fehleranalyse mit Gegenmaßnahmen enthält.

23

Smart Device Applikationen

B.1.8

VdS 3169-1 : 2016-02 (02)

Frequently Asked Questions (FAQ)

Die Betreiberdokumentation muss eine Auflistung der häufigsten Fragen zur Installation, Konfiguration und Bedienung der Applikation durch den Betreiber und eine entsprechende Beantwortung der Fragen in einer übersichtlichen Darstellungsweise enthalten. Hinweis: Die FAQ sollten alle Funktionsbereiche der Applikation abdecken. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn die Betreiberdokumentation eine FAQ zu allen Funktionsbereichen der Applikation enthält.

B.1.9

Glossar

Der Hersteller hat fachspezifische Begriffe der Betreiberdokumentation in einem Glossar zu erläutern. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn die Betreiberdokumentation einen Glossar mit allen in der Dokumentation vorkommenden fachspezifischen Begriffen enthält.

B.2

Herstellerdokumentation

Die Herstellerdokumentation muss alle technischen Unterlagen enthalten, die für eine Entwicklung, Umsetzung und für die Qualitätssicherung der Applikation relevant sind. Anhand der Technischen Unterlagen muss es dem Hersteller möglich sein im Falle von Personalwechseln (bspw. Wechsel des programmierenden Personals) oder anderweitigen Änderungen im Unternehmen die Applikation samt der dafür notwendigen Infrastruktur weiterhin betreiben und weiterentwickeln zu können. Die Herstellerdokumentation muss dem Betreiber nicht zugänglich gemacht werden und dient lediglich der Sicherung und Fortführung der Applikationsentwicklung. Zu den technischen Unterlagen gehören nachfolgend beschriebene Dokumente.

B.2.1

Entwicklungsdokumentation/Versionsschema

Der Hersteller muss eine Entwicklungsdokumentation vorhalten, die regelmäßig gepflegt wird. In der Entwicklungsdokumentation ist ein festes Versionsschema eindeutig zu erkennen. In der Dokumentation sind die verschiedenen Entwicklungsstände der Applikation und Änderungen zu den Vorversionen hinsichtlich Umfang und Auswirkung von Modifikationen an der Applikation beschrieben. Zu jedem Versionsstand ist dokumentiert welche Entscheidungsgrundlage zu der Applikationsversion geführt hat und welche Personengruppen oder Organisationseinheiten an der Entscheidung beteiligt waren. Annahme-/Zurückweisungskriterien: Das vorgenannte Prüfkriterium ist bestanden, wenn in der Herstellerdokumentation ein Versionsschema eindeutig zu erkennen ist. Annahme-/Zurückweisungskriterien: Das vorgenannte Prüfkriterium ist bestanden, wenn in der Entwicklungsdokumentation alle Stände der Applikationsversionen und deren Änderungen zu Vorversionen beschrieben sind. Außerdem müssen zu jedem Versionsstand die Entscheidungsgrundlage und die beteiligten Personengruppen oder Organisationseinheiten aufgeführt sein.

B.2.2

Prozessdokumentation/Flussdiagramm

Der Hersteller muss alle Prozesse und Funktionen der Applikation in einer geeigneten Weise darstellen und eindeutig bezeichnen. Aus der Dokumentation muss der Programmfluss erkennbar sein. Zu jedem Prozess muss eine kurze Beschreibung erfolgen

24

VdS 3169-1 : 2016-02 (02)

Smart Device Applikationen

welche Aufgaben der Prozess ausführen soll, welche Eingangs- und Ausgangsinformation vorliegen und welche Vorgänger- bzw. Nachfolgeprozesse vorhanden sind. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn alle Prozesse und Funktionen der Applikation in der Herstellerdokumentation in nachvollziehbarer Weise mit o. g. Angaben dargestellt sind.

B.2.3

Programmdokumentation

Der Programmcode weist einen klar strukturierten, modularen Aufbau auf. Zu den Programmmodulen ist jeweils eine detaillierte Beschreibung vorhanden mit nachfolgenden Angaben: a) Eindeutige Bezeichnung des Moduls, b) Kurzbeschreibung der auszuführenden Aufgabe, c) einer Beschreibung, aus der die Art des Zusammenwirkens, die Abhängigkeit und die Wechselwirkung mit anderen Modulen und Objekten hervorgeht, d) Eine Beschreibung der Schnittstellen einschließlich der Art des Datentransfers, des gültigen Wertebereiches und der gültigen Input- und Outputparameter, e) Angabe der Art, in welcher das Modul aufgerufen wird, f) Angabe von welchen Prozessen und Funktionen das Modul aufgerufen wird, g) einer Darstellung der allgemeinen Programmhierarchie. Hinweis: Die Modulbeschreibungen liegen nicht nur im Quellcode vor – wichtige Module oder Aufrufe müssen aber mit einem eindeutigen Kommentar versehen sein. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn in der Herstellerdokumentation alle Programmmodule mit o. g. Angaben detailliert beschrieben sind.

B.2.4

Quellcode-Listing

Die Herstellerdokumentation muss ein Quellcode-Listing einschließlich aller globalen und lokalen Variablen, Konstanten und Labels sowie einen ausreichenden Kommentar enthalten, so dass der Programmfluss erkannt werden kann. Annahme-/Zurückweisungskriterium: Das vorgenannte Prüfkriterium ist bestanden, wenn anhand von mindestens 5 Stichproben die Modulbeschreibungen aus B.2.3 mit dem Quellcode-Listing verglichen und als korrekt und konsistent erachtet wird.

25