Anhang VEleS Ziff. 24. Entwicklung und Wartung von Informationssystemen

[dune73]

Wortlaut der Vorlage

24. Entwicklung und Wartung von Informationssystemen

24.1 Entwicklung

24.1.1 Es wird ein Lebenszyklusmodell definiert. Das Lebenszyklusmodell:

• wird für die Entwicklung und Wartung der Software verwendet;
• sieht die notwendigen Kontrollen bei der Entwicklung und Wartung der Software vor;
• wird dokumentiert.

24.1.2 Es wird eine Liste der eingesetzten Entwicklungswerkzeuge sowie der Konfigurationsoptionen, die für den Einsatz der einzelnen Entwicklungswerkzeuge gewählt wurden, erstellt.

24.1.3 Die Dokumentation der Entwicklungswerkzeuge umfasst:

• eine Definition des Entwicklungswerkzeugs;
• eine Beschreibung aller Konventionen und Richtlinien, die bei der Implementierung des Entwicklungswerkzeugs verwendet werden;
• eine eindeutige Beschreibung der Bedeutung aller Konfigurationsoptionen für die Anwendung des Entwicklungswerkzeugs.

24.1.4 Es wird festgelegt, welche Implementierungsstandards angewendet werden.

24.1.5 Die Software wird so spezifiziert und implementiert, dass die Sicherheitsfunktionen nicht umgangen werden können.

24.1.6 Die Sicherheitsfunktionen werden so spezifiziert und implementiert, dass sie vor Manipulation geschützt sind.

24.1.7 Die Sicherheitsarchitektur der Software wird dokumentiert. Die Dokumentation:

• weist einen Detaillierungsgrad auf, welcher der Beschreibung der Sicherheitsfunktionen entspricht;
• beschreibt die Sicherheitsdomänen, auf die sich die Sicherheitsfunktionen richten;
• beschreibt, wie die Initialisierungsprozesse gesichert werden;
• weist die Erfüllung der Ziffern 24.1.5 und 24.1.6 nach.

24.1.8 Die funktionalen Spezifikationen werden dokumentiert. Die Dokumentation:

• bildet die gesamte Software ab;
• beschreibt den Zweck und die Anwendung aller Schnittstellen;
• identifiziert und beschreibt alle Parameter, die mit den Schnittstellen verbunden sind;
• beschreibt alle Aktionen, die mit Schnittstellen verbunden sind;
• beschreibt alle direkten Fehlermeldungen, die durch den Aufruf der einzelnen Schnittstellen entstehen können.

24.1.9 Die Nachvollziehbarkeit zwischen funktionalen Spezifikationen und Sicherheitsanforderungen wird bis auf die Ebene der Schnittstellen sichergestellt.

24.1.10 Alle Sicherheitsfunktionen sind im Quellcode implementiert.

24.1.11 Die Nachvollziehbarkeit zwischen dem gesamten Quellcode und den Spezifikationen der Sicherheitsfunktionen ist sichergestellt und deren Übereinstimmung ist erwiesen.

24.1.12 Die Sicherheitsfunktionen werden so konzipiert und implementiert, dass sie gut strukturiert sind. Die interne Struktur wird beschrieben und enthält eine Begründung, die:

• die Merkmale angibt, die zur Beurteilung von «gut strukturiert» und von «Komplexität» verwendet werden;
• aufzeigt, dass alle Sicherheitsfunktionen gut strukturiert und nicht zu komplex sind.

24.1.13 Die Spezifikationen umfassen folgende Aspekte:

• eine Beschreibung der Struktur der Software in Form von Teilsystemen;
• eine Beschreibung der Sicherheitsfunktionen als Module sowie für jedes Modul die Zielsetzung und eine Beschreibung, wie das Modul zu den anderen Modulen in Beziehung steht; die Beschreibung der sicherheitsrelevanten Module umfasst auch die verfügbaren Schnittstellen, die Rückgabewerte dieser Schnittstellen und die Schnittstellen der anderen Module, die sie zur Interaktion mit ihnen verwenden;
• eine Beschreibung aller Teilsysteme, die mit den Sicherheitsfunktionen zusammenhängen einschliesslich der möglichen Wechselwirkungen untereinander;
• eine Abbildung der mit Sicherheitsfunktionen verbundenen Teilsysteme auf ihre Module für den Nachweis, dass alle Schnittstellen dem in der Spezifikation beschriebenen Verhalten entsprechen.

24.1.14 Die Software wird mit einer eindeutigen Kennzeichnung versehen.

24.1.15 Die Dokumentation des Konfigurationsmanagements enthält:

• eine Beschreibung, wie Konfigurationselemente identifiziert werden;
• einen Konfigurationsmanagementplan, der beschreibt, wie das Konfigurationsmanagementsystem bei der Entwicklung der Software eingesetzt wird und welche Verfahren für die Übernahme von Änderungen oder neuen Elementen angewendet werden;
• einen Nachweis, dass die Verfahren für die Übernahme eine angemessene Prüfung der Änderungen für alle Konfigurationselemente vorsehen.

24.1.16 Das Konfigurationsmanagementsystem:

• identifiziert alle Konfigurationselemente eindeutig;
• stellt automatisierte Massnahmen bereit, damit nur autorisierte Änderungen an Konfigurationselementen vorgenommen werden;
• unterstützt die Entwicklung der Software durch automatisierte Verfahren;
• stellt sicher, dass die Person, die für die Abnahme des Konfigurationselements verantwortlich ist, nicht dieselbe Person ist, die es entwickelt hat;
• identifiziert die Konfigurationselemente, aus denen sich die Sicherheitsfunktionen zusammensetzen;
• unterstützt die Prüfung aller Änderungen an der Software mit automatisierten Verfahren, einschliesslich der Protokollierung des Verfassers sowie des Datums und der Uhrzeit der Änderung;
• stellt ein automatisiertes Verfahren zur Identifizierung aller Konfigurationselemente bereit, die von einer Änderung an einem bestimmten Konfigurationselement betroffen sind;
• kann die Version des Quellcodes identifizieren, auf dessen Basis die Software generiert wird.

24.1.17 Alle Konfigurationselemente werden im Konfigurationsmanagementsystem inventarisiert.

24.1.18 Das Konfigurationsmanagementsystem wird in Übereinstimmung mit dem Konfigurationsmanagementplan verwendet.

24.1.19 Es wird eine Konfigurationsliste erstellt, die die folgenden Elemente enthält:

• die Software;
• Nachweise der erforderlichen Überprüfungen zur Einhaltung der Sicherheit;
• die Teile, aus denen die Software besteht;
• den Quellcode;
• Berichte über Sicherheitsmängel und über den Stand der Behebung. Für jedes Element, das für Sicherheitsfunktionen relevant ist, wird die Entwicklerin oder der Entwickler genannt. Jedes Element wird eindeutig identifiziert.

24.1.20 Die Dokumentation zur Sicherheit der Softwareentwicklung umfasst:

• die Beschreibung der physischen, verfahrenstechnischen, personellen und sonstigen Sicherheitsmassnahmen, die zum Schutz und zur Integrität der Ausgestaltung und der Implementierung der Software in ihrer Entwicklungsumgebung erforderlich sind;
• den Nachweis, dass die Sicherheitsmassnahmen das erforderliche Schutzniveau bieten, um die Integrität der Software zu wahren.

24.2 Betrieb

24.2.1 Es wird ein Betriebshandbuch erstellt, das für jede Benutzerrolle folgende Aspekte enthält:

• eine Beschreibung der Funktionen, auf die die Benutzerin oder der Benutzer zugreifen kann, und der Berechtigungen, die in einer sicheren Umgebung kontrolliert werden müssen, einschliesslich entsprechender Warnungen; - eine Beschreibung, wie die verfügbaren Schnittstellen auf sichere Weise genutzt werden können;
• eine Beschreibung der verfügbaren Funktionen und Schnittstellen, insbesondere aller Sicherheitsparameter, die unter der Kontrolle der Benutzerin oder des Benutzers stehen unter Hervorhebung der für die Sicherheit relevanten Werte;
• eine präzise Darstellung aller Typen von Sicherheitsereignissen in Bezug auf die auszuführenden, für die Benutzerin oder den Benutzer zugänglichen Funktionen, einschliesslich der Anpassungen der Sicherheitseigenschaften von Elementen, die der Kontrolle der Sicherheitsfunktionen unterliegen;
• Beschrieb der Sicherheitsmassnahmen, die umzusetzen sind, um die betrieblichen Sicherheitsziele zu erreichen.

24.2.2 Das Betriebshandbuch muss alle möglichen Betriebsarten der Software aufzeigen, dies einschliesslich der Wiederaufnahme des Betriebs nach der Entdeckung von Fehlern sowie der Beschrieb der Folgen und Auswirkungen von Fehlern auf die Aufrechterhaltung des sicheren Betriebs.

24.2.3 Das Betriebshandbuch muss präzise und zweckmässig sein.

24.3 Zuverlässige und nachvollziehbare Kompilierung und Deployment

24.3.1 Der Vorbereitungsprozess beschreibt alle Schritte, die notwendig sind für:

• eine sichere Abnahme der Systembestandteile in Übereinstimmung mit dem Verfahren für die Bereitstellung;
• eine sichere Aufbereitung der Betriebsumgebung in Übereinstimmung mit den betrieblichen Sicherheitszielen;
• eine sichere Installation der Software in der Betriebsumgebung.

24.3.2 Die Bereitstellung des Software oder von Teilen des Systems wird dokumentiert und umfasst alle Prozesse, die zur Aufrechterhaltung der Sicherheit bei der Bereitstellung der Software erforderlich sind.

24.3.3 Es ist eine zuverlässige und überprüfbare Kompilierung mit angemessenen Sicherheitsmassnahmen durchzuführen. Damit ist sichergestellt, dass der ausführbare Code eine überprüfbare und getreue Darstellung des Quellcodes ist, der einer öffentlichen Kontrolle und unabhängigen Prüfungen unterzogen wurde. Die Kompilierung erlaubt es, eine Beweiskette für die Überprüfung der Software anzulegen, und umfasst insbesondere:

• den Nachweis, dass die Kompilierumgebung so ausgestaltet ist, wie sie auf der öffentlichen Plattform beschrieben ist (Gesamtheit der Werkzeuge mit der jeweiligen Version, Betriebssystem und allfälligen Konfigurationen); allfällige Abweichungen sind zu dokumentieren und zu begründen;
• den Nachweis, dass die Software gemäss den auf der öffentlichen Plattform verfügbaren Anweisungen kompiliert wurde; wird bei der Kompilierung ein Mangel in den Instruktionen festgestellt, so ist dieser zu protokollieren und die Dokumentation anschliessend anzupassen;
• den Nachweis, dass der zur öffentlichen Kontrolle vorgelegte und geprüfte Quellcode tatsächlich derjenige ist, der zur Kompilierung verwendet wurde;
• den Nachweis, dass keine anderen als die in den Instruktionen vorgesehenen Elemente eingeführt wurden;
• den Nachweis, dass alle kryptografischen Signaturen der Abhängigkeiten gegen eine bewährte, öffentliche und vertrauenswürdige Referenz (z. B. Maven Central Repository) verifiziert wurden;
• den Nachweis, dass eine Analyse der Schwachstellen in Bezug auf Abhängigkeiten durchgeführt wurde und dass, sofern für die Software relevante Schwachstellen vorhanden sind, diese die Software nicht angreifbar machen;
• den Nachweis, dass die allenfalls eingeführten Parameter das System nicht angreifbar machen.

24.3.4 Es ist ein zuverlässiges und überprüfbares Deployment mit angemessenen Sicherheitsmassnahmen durchzuführen. Damit ist sicherzustellen, dass:

1. der produktiv eingesetzte Code eine überprüfbare und getreue Darstellung des Quellcodes ist, der einer öffentlichen Kontrolle und unabhängigen Prüfungen unterzogen wurde; und
2. dass die Produktionsumgebung mit derjenigen übereinstimmt, die der öffentlichen Kontrolle und unabhängigen Prüfungen unterzogen wurde. Das Deployment erlaubt es, eine Beweiskette für die Überprüfung der Software anzulegen, und umfasst insbesondere:
   • den Nachweis, dass die Produktionsumgebung mit derjenigen übereinstimmt, die der öffentlichen Kontrolle und unabhängigen Überprüfungen unterzogen wurde; allfällige Abweichungen (Firmware-Version, Konfigurationsdateien usw.) sind zu dokumentieren und zu begründen;
   • den Nachweis, dass die in der Produktionsumgebung eingesetzte Software tatsächlich diejenige ist, die im zuverlässigen und überprüfbaren Kompilierungsverfahren erstellt wurde;
   • den Nachweis, dass die allenfalls eingeführten Parameter das System nicht angreifbar machen.

24.3.5 Die Qualität der Nachweise der zuverlässigen und überprüfbaren Kompilierung und des zuverlässigen und überprüfbaren Deployments wird durch die Anwesenheit von mindestens zwei Zeuginnen oder Zeugen verschiedener Institutionen oder durch technische Verfahren zur Feststellung des Wahrheitsgehalts nach dem Stand der wissenschaftlichen Erkenntnisse und Erfahrungen bestätigt.

24.3.6 Die Nachweiskette der zuverlässigen und überprüfbaren Kompilierung und des zuverlässigen und überprüfbaren Deployments wird öffentlich zugänglich gemacht.

24.4 Systematische Behebung von Mängeln

24.4.1 Es werden Prozesse zur Behebung von Mängeln definiert. Die Prozesse umfassen:

• eine Dokumentation dieser Prozesse, insbesondere im Hinblick auf die Rückverfolgbarkeit von Mängeln für alle Versionen der Software sowie der Methoden, die verwendet werden, damit die Systembenutzerinnen und -benutzer über die
• Informationen über die Mängel, die Korrekturen und zu möglichen Korrekturmassnahmen verfügen;
• die Pflicht, die Art und die Auswirkungen aller Sicherheitsmängel, Informationen zum Stand der Arbeiten zur Lösungsfindung sowie die beschlossenen Korrekturmassnahmen zu beschreiben;
• eine Beschreibung der Instrumente, mit denen die Systembenutzerinnen und -benutzer die Möglichkeit erhalten, den Softwareentwicklerinnen und - entwicklern Berichte und Anfragen zu vermuteten Mängeln in der Software bekanntmachen zu können;
• ein Verfahren, das eine zeitnahe Reaktion und ein automatischer Versand von Berichten über Sicherheitsmängel und entsprechenden Korrekturen an registrierte Systembenutzerinnen und -benutzer, die vom Mangel betroffen sein könnten, erfordert.

24.4.2 Es wird ein Prozess für die Behandlung der gemeldeten Mängel definiert. Dieser Prozess stellt sicher, dass alle gemeldeten und bestätigten Mängel behoben werden und dass die Prozesse zur Behebung den Systembenutzerinnen und -benutzern mitgeteilt werden. Er sieht Vorkehrungen vor, die sicherstellen, dass eine Behebung von Sicherheitsmängeln keine neuen Sicherheitsmängel nach sich zieht.

24.4.3 Es werden Richtlinien für die Einreichung und die Behebung von Mängeln definiert. Diese umfassen:

• eine Anleitung, wie Systembenutzerinnen und -benutzer vermutete Sicherheitsmängel an die Entwicklerin oder den Entwickler melden können;
• eine Anleitung, wie sich Systembenutzerinnen und -benutzer bei der Entwicklerin oder beim Entwickler registrieren können, um Berichte über Sicherheitsmängel und die Behebungen zu erhalten;
• die Angabe von spezifischen Kontaktstellen für alle Berichte und Anfragen zu Sicherheitsfragen, die die Software betreffen.

24.5 Qualitätssicherung

Es wird regelmässig und objektiv geprüft, ob die durchgeführten Abläufe sowie die dazugehörenden Arbeitsprodukte mit der Beschreibung der umzusetzenden Abläufe, Normen und Prozesse übereinstimmen. Abweichungen werden bis zu ihrer Behebung weiterverfolgt.

Referenzen

• Bericht der Bundeskanzlei, S. 29-30:

Ziff. 24 Entwicklung und Wartung von Informationssystemen Die Qualität von E-Voting-Systemen muss während des gesamten Entwicklungsprozesses sichergestellt werden. Um die Qualitätssicherung zu stärken, wurden die Anforderungen mit folgenden Zielen präzisiert:

• Anpassungen im System müssen nachvollzogen und überprüft werden können.
• Die Nachvollziehbarkeit zwischen den einzelnen Elementen der Dokumentation (Protokoll, Spezifi-kation, Architektur, etc.) und dem Quellcode muss laufend und in beide Richtungen sichergestellt werden können.
• Die Ergebnisse von Prüfprozessen fliessen in die Entwicklungsarbeiten ein.
• Die Konformität mit den rechtlichen Anforderungen wird während des gesamten Lebenszyklus sichergestellt und aufrechterhalten. Insbesondere werden die Anforderungen der Common Criteria Stufe EAL 4, die bisher für Kontrollkomponenten galten, auf das gesamte System ausgeweitet. Zusätzlich wurden sie mit Anforderungen aus Common Criteria über EAL 4 ergänzt, wenn dies einen wesentlichen Beitrag zu den Sicherheitszielen leistet und im Sinne der obengenannten Ziele ist.

Ziff. 24.1: Die hier berücksichtigten Entwicklungswerkzeuge sind die Werkzeuge, die für die Sicherheit der Softwareentwicklung wichtig sind. Dazu gehören IDEs, Build-Tools und Konfigurationsmanagement-Tools. Ebenso handelt es sich um Konfigurationsoptionen, die einen Einfluss auf die Sicherheit der Entwicklung haben können.

Wie in Ziffer 17.2 werden unter «Schnittstellen» die Elemente verstanden, die es der Software ermögli-chen, Informationen mit der Umgebung auszutauschen. Dies können grafische Oberflächen, Befehlszeilen oder technische Schnittstellen (API) sein.

Eine Konfigurationsliste ist eine einheitliche Zusammenstellung von Konfigurationselementen, die den Zustand der Software und ihrer Dokumentation zu einem bestimmten Zeitpunkt darstellt. Idealerweise ermöglicht sie, eine vergangene Version der Software zu rekonstruieren.

Ziff. 24.3: Es muss eine korrekte Bereitstellung des Systems aus dem Quellcode bis zu seiner Installation in der Produktion (Build- und Deployment) sichergestellt werden. Dazu ist vom Systemanbieter eine be-währte und nachvollziehbare Build- und Deployment-Methode einzusetzen, mit der die folgenden Ziele erreicht werden:

• Die Build- und Deployment-Methode erlaubt es, sicherzustellen, dass die eingesetzte Software mit der publizierten, geprüften und zugelassenen Version übereinstimmt.
• Zusätzlich zu dieser Nachvollziehbarkeit soll die Build- und Deployment-Methode Manipulationen der Systembestandteile so weit als möglich verhindern.
• Es muss verhindert werden, dass mit den eingesetzten Entwicklungsinstrumenten und Bibliotheken für die Software relevante Schwachstellen eingeführt werden, die das System angreifbar machen würden.

Dazu wurden neue Anforderungen eingeführt. Sie basieren auf den Richtlinien des US-Bundesstaates Colorado für die Verwendung elektronischer Wahlsysteme,10 der von GitHub herausgegebenen Trusted-Build-Dokumentation11 und der Reproducible-Builds-Dokumentation12 des gleichnamigen Projekts.

Ziff. 24.4: Als Benutzende werden alle Personen verstanden, die mit der Software in irgendeiner Weise in Berührung kommen. Dazu können Mitarbeitende des Kantons, Stimmberechtigte, Testerinnen und Tester und letztlich alle gehören, die am System interessiert sind. Damit der Entwickler Mängelberichte angemessen behandeln und in diesem Bereich effektiv kommunizieren kann, ist es wichtig, dass die Benutzenden wissen, wie sie Mängelberichte an den Entwickler über-mitteln können und wie sie sich beim Entwickler registrieren können, um entsprechende Informationen zu erhalten.

Eine möglichst umfangreiche Sammlung von vermuteten Schwachstellen und deren systematische Be-handlung soll zur Verbesserung der Systemsicherheit beitragen. Diese Anforderungen sind komplementär zur Offenlegung des Quellcodes (Art. 11-12 E-VEleS) und zum Bug-Bounty-Programm (Art. 13 E-VEleS).

[melchl]

24.1.19: Hier fehlt die Commit-History. Ausserdem ist mir nicht klar, was der letzte Abschnitt bedeutet, wenn mehrere Entwickler kollaborieren.