VdS-Richtlinien für rechnergestützte Informationssysteme

VdS-Richtlinien für rechnergestützte Informationssysteme Smart Device Applikationen Anforderungen und Prüfmethoden VdS 3169-1 1 Allgemeines... 2 1.1 Anwendungsbereich... 2 1.2 Gültigkeit... 3 2 Begriffe und Abkürzungen... 3 2.1 Begriffe... 3 2.2 Abkürzungen... 4 3 Normative Verweisungen... 5 4 Klassifizierung... 5 5 Anforderungen... 7 5.1 Basisschutzmaßnahmen... 7 5.1.1 Firewall... 7 5.1.2 Schutz vor Schadsoftware... 7 5.1.3 Nutzercode... 7 5.1.4 Länge und Zusammensetzung des Nutzercodes... 7 5.1.4.1 Klasse 2-Stern... 7 5.1.4.2 Klasse 3-Stern... 7 5.1.5 Verbindung zu Steuer- und Anzeigeeinrichtungen von sicherungstechnischen Anlagen... 7 5.1.6 Updatemanagement... 8 5.1.7 Managementsystem für Informationssicherheit (ISMS)... 8 5.2 Maßnahmen gegen Brute-Force-Angriffe... 8 5.2.1 Zeitkonstante... 8 5.2.2 Vollsperre... 9 5.3 Maßnahmen gegen Reverse Engineering... 9 5.3.1 Standard-Obfuskation... 9 5.3.2 Höherwertige Obfuskation... 9 5.4 Maßnahmen gegen Vertraulichkeitsverlust auf dem Übertragungsweg... 9 5.4.1 Online... 9 5.4.2 Offline... 10 5.5 Maßnahmen gegen Keylogger... 10 5.5.1 Individualtastatur... 10 5.5.2 Scramble-Individualtastatur... 10 5.6 Maßnahmen gegen Vertraulichkeitsverlust auf dem Smart Device... 10 Seite 1

5.6.1 Verschlüsselte Speicherung... 10 5.6.2 Schutz der Integrität... 11 5.6.3 Schutz durch Secure Element... 11 5.7 Maßnahmen gegen Root-Exploits... 11 6 Prüfmethoden... 12 6.1 Basisschutzmaßnahmen... 12 6.1.1 Firewall... 12 6.1.2 Schutz vor Schadsoftware... 12 6.1.3 Nutzercode... 13 6.1.3.1 Anforderungen an den Nutzercode Klasse 2-Stern... 13 6.1.3.2 Anforderungen an den Nutzercode Klasse 3-Stern... 13 6.1.4 Updatemanagement... 14 6.1.5 Managementsystem für Informationssicherheit (ISMS)... 14 6.2 Maßnahmen gegen Brute-Force-Angriffe... 15 6.2.1 Zeitkonstante... 15 6.2.2 Vollsperre... 15 6.3 Maßnahmen gegen Reverse Engineering... 15 6.3.1 Standard Obfuskation... 15 6.3.2 Höherwertige Obfuskation... 16 6.4 Maßnahmen gegen Vertraulichkeitsverlust auf dem Übertragungsweg... 16 6.5 Maßnahmen gegen Keylogger... 17 6.5.1 Individualtastatur... 17 6.5.2 Scramble-Individualtastatur... 17 6.6 Maßnahmen gegen Vertraulichkeitsverlust auf dem Smart Device... 17 6.6.1 Verschlüsselte Speicherung... 17 6.6.2 Schutz vor Integrität... 18 6.6.3 Secure Element... 18 6.7 Maßnahmen gegen Root-Exploits... 18 7 Anforderungen an die Softwarequalität... 19 7.1 Dokumentationspflicht des Herstellers... 19 7.2 Mindestanforderungen an das Smart Device und das Betriebssystem... 20 7.3 Installationsanleitung/Einrichtung der App... 21 7.4 Bedienungsanleitung... 21 7.5 Softwaredokumentation... 22 7.5.1 Version / Versionsschema... Fehler! Textmarke nicht definiert. 7.5.2 Entwicklungsdokumentation... 22 7.5.3 Prozessbeschreibung... 22 7.5.4 Programmdokumentation... 23 7.5.5 Maßnahmen gegen Angriffe von außen... Fehler! Textmarke nicht definiert. 1 Allgemeines 1.1 Anwendungsbereich Seite 2

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.01.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 HTML- Seite, die durch das Smart Device erkannt wird und für dieses 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. 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 Seite 3

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, um vertrauliche Informationen auszuspähen (bspw. Kennwörter) und diese dann 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. 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 PUK Abkürzungen Personal Unblocking Key Seite 4

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-S2 Richtlinien für das VdS-Übertragungsprotokoll für Gefahrenmeldungen, Version 2, Ergänzung S2: Protokollerweiterung zur Anschaltung an Netze der Protokollfamilie TCP 4 Klassifizierung Der Tabelle ist zu entnehmen, welche der nachfolgenden Anforderungen in welcher Klasse erfüllt sein müssen**. 1-Stern 2-Stern 3-Stern Basisangriffsvektor Firewall Angriffsvektor Maßnahme(n) Abschnitt Web-Application- Firewall 5.1.1 N/B N/B N/B N/B N/B N/B Virenschutz 5.1.2 N/B N/B N/B Nutzercode 5.1.3 N/B N/B Pairing-Verfahren 5.1.5 * * * Updatemanagement 5.1.6 N/B N/B N/B Brute-Force-Angriff Zeitkonstante 5.2.1 N/B N/B N/B Nutzercode-Länge 5.1.3 N/B N/B N/B Seite 5

Vollsperre 5.2.2 N/B Reverse Engineering Standard Obfuskation 5.3.1 N/- N/- Höherwertige Obfuskation Verschlüsselung (Online/Offline) 5.3.2 N/- 5.4 N/B N/B N/B Keylogger Individualtastatur 5.5.1 N/B Vertraulichkeitsverlust auf dem Smart Device Vertraulichkeitsverlust auf dem Übertragungsweg Scramble- Individualtastatur im Gerät verschlüsselt gespeichert 5.5.2 N/B 5.6.1 N/B N/B N/B Integritätsschutz 5.6.2 N/B Secure Element 5.6.3 N/B Root-Exploit Verhindern/Detektion 5.7 N/B N/B Tabelle 4-1: Klassifizierung *) wenn anwendbar, siehe jeweiliger Abschnitt **) N für native Apps, B für browsergestützte Apps Seite 6

5 Anforderungen 5.1 Basisschutzmaßnahmen 5.1.1 Firewall 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 und eine regelmäßige Überprüfung auf Schadsoftware und die automaische Aktualisierung der Signaturdatenbank empfehlen. 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 Nutzer- und 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. 5.1.5 Verbindung zu Steuer- und Anzeigeeinrichtungen von sicherungstechnischen Anlagen Es sind die zusätzlichen Anforderungen der weiteren Teile dieser Richtlinien zu erfüllen, soweit anwendbar. Seite 7

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 VdSkonformen 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 den Betreiber der Applikation in der Dokumentation darauf hinweisen. 5.2 Maßnahmen gegen Brute-Force-Angriffe 5.2.1 Zeitkonstante 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 = 2 n Sekunden. Seite 8

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. HTTPS-Verbindungen mit aktuellen Verschlüsselungsverfahren und Nutzung von Checksum-Funktionen) 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-S2 beschrieben oder 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 Organisation-Validierung >=2048 Bit >= 256 Bit 3-Stern Extended-Validation >=4096 Bit >= 256 Bit Seite 9

Wenn in der Applikation der oder die Master bzw. 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 oder durch ein vom Hersteller vorgegebenes Verfahren selbst 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. 5.5.2 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 anordnet (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. Seite 10

Alle Daten die auf dem Master abgerufen werden können, sollten 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. Seite 11

6 Prüfmethoden 6.1 Basisschutzmaßnahmen 6.1.1 Firewall 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 VdSkonformen 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 Schutzprogramms 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. Seite 12

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

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. 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 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. 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. 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. 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 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 Ein- Seite 14

flussbereichs 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. 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. 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. 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. 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. 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. Seite 15

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. 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. 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. Das vorgenannte Prüfkriterium ist bestanden, wenn die verwendeten Verfahren und Algorithmen in der Herstellerdokumentation aufgeführt sind. Es wird geprüft, ob bei der Übermittlung von Daten nur gültige Zertifikate verwendet und akzeptiert werden. 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. 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. Seite 16

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. 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. 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). 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. 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. 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. Das vorgenannte Prüfkriterium ist bestanden, wenn der verwendete Ablageort oder das Verschlüsselungsverfahren in der Herstellerdokumentation aufgeführt ist. Seite 17

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. 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. 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 Verwednung eines geeigneten Smart Device empfiehlt. 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. Das vorgenannte Prüfkriterium ist bestanden, wenn entsprechende Hinweise in der Betreiberdokumentation vorhanden sind. 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. 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. Seite 18

Anhang - Anforderungen an die Dokumentation A Allgemeine Anforderungen an die Dokumentation A.1 Dokumentationspflicht des Herstellers Der Hersteller der Applikation muss zum Zeitpunkt der Auslieferung der Applikation 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 der Auslieferung der Applikation zur Verfügung zu stellen. Es steht dem Hersteller frei dem Betreiber ebenfalls die Herstellerdokumentation auszuhändigen. 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. 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. 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. Seite 19

B Inhaltliche Anforderungen an die Dokumentation B.1 Betreiberdokumentation Die Betreiberdokumentation muss alle Dokumente aus den Anforderungen dieser Richtlinien enthalten. Darüber hinaus müssen die nachfolgenden Dokumentationen 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. Das vorgenannte Prüfkriterium ist bestanden, wenn in der Betreiberdokumentation der Hersteller mit Kontaktmöglichkeit aufgeführt ist. Das vorgenannte Prüfkriterium ist bestanden, wenn in der Betreiberdokumentation der Hinweis auf Beachtung aktueller Produktinformationen mit Angabe der URL enthalten ist. 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 Mindestanforderungen an das Smart Device und das Betriebssystem Folgende Informationen müssen in der Betreiberdokumentation aufgeführt sein: Mindestanforderungen an die unterstützende Hardware (bspw. Prozessorleistung, benötigte Kommunikationsmodule, Speicheranforderungen, etc.) Welche Betriebssysteme werden von der Applikation unterstützt. Welche unterstützende Software ggf. auf dem Smart Device noch benötigt wird (bspw. VPN Client, etc.). Das vorgenannte Prüfkriterium ist bestanden, wenn o.g. Informationen in der Betreiberdokumentation enthalten sind. B.1.3 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. Seite 20

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. 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 Standard-Konfiguration 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. 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. 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. Das vorgenannte Prüfkriterium ist bestanden, wenn die Betreiberdokumentation bekannte Fehler und Bedienprobleme der Applikation, sowie eine Fehleranalyse mit Gegenmaßnahmen enthält. B.1.8 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. Seite 21

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. 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 welche Aufgaben der Prozess ausführen soll, welche Eingangs- und Ausgangsinformation vorliegen und welche Vorgängerbzw. Nachfolgeprozesse vorhanden sind. 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. Seite 22

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. 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. Das vorgenannte Prüfkriterium ist bestanden, wenn anhand von mindestens 5 Stichproben die Modulbeschreibungen aus B.2.3 mit dem Quellcode-Listing verglichen wird und als korrekt und konsistent erachtet wird. Seite 23