Verordnung der BK
über die elektronische Stimmabgabe
(VEleS)

1. Begriffsbestimmungen

Zusätzlich zu Artikel 2 bedeuten die folgenden Ausdrücke:

• 1.1 Wahrung des Stimmgeheimnisses: Situation, wenn keiner Person oder Komponente folgende Daten vorliegen:

  • 1.1.1 abgegebene Stimmen oder Daten, die auf den Inhalt abgegebener Stimmen schliessen lassen,

  • 1.1.2 Daten, die es erlauben, die stimmenden Personen zu identifizieren (Daten über die stimmberechtigten Personen), und

  • 1.1.3 Daten, die es erlauben, die Daten über die stimmberechtigten Personen den abgegebenen Stimmen zuzuordnen;

• 1.2 Ausschluss von vorzeitigen Teilergebnissen: Situation, wenn keiner Person oder Komponente die abgegebenen Stimmen oder Daten, die auf die abgegebenen Stimmen schliessen lassen, vorzeitig vorliegen;

• 1.3 Verifizierungsreferenz: eine mit dem Stimmmaterial zugestellte Grundlage, damit die stimmberechtigten Personen nach Artikel 5 Absatz 2 in Verbindung mit Ziffer 2.5 des Anhangs prüfen können, ob ihre Stimme korrekt abgegeben wurde (z. B. eine Liste, auf der für jede Antwortmöglichkeit ein Code aufgeführt ist);

• 1.4 externer Angreifer: Person oder Gruppe von Personen, die nicht mit der Entwicklung und dem Betrieb des Systems vertraut ist, die über durchschnittliche Ressourcen und Fachkenntnisse verfügt und von der ein Angriff ausgeht; ihre Beweggründe können Aktivismus oder finanziellen Gewinn umfassen;

• 1.5 interner Angreifer: Person oder Gruppe von Personen, die an der Entwicklung oder am Betrieb des Systems beteiligt ist und von der ein Angriff ausgeht; ihre Beweggründe können Aktivismus, finanziellen Gewinn oder die Absicht, ihrem Arbeitgeber zu schaden, umfassen;

• 1.6 feindliche Organisation: Gruppe von Personen, die über umfangreiche Ressourcen und überdurchschnittliche Fachkenntnisse verfügt und von der ein Angriff ausgeht; sie kann dabei auch von einem Staat unterstützt werden; ihre Beweggründe können das Erlangen von Daten zu Profiling-Zwecken, die Störung eines Urnengangs oder die Beeinflussung der Ergebnisse des Urnengangs sein;

• 1.7 Angreifer: eine Person, Gruppe von Personen oder Organisation nach den Ziffern 1.4–1.6;

• 1.8 elektronische Urne: ein Speicherbereich, in dem die abgegebenen Stimmen bis zur Entschlüsselung und Auszählung gespeichert werden können;

• 1.9 Systemprotokoll: Protokoll, das von den Bestandteilen der Infrastruktur erstellt wird, um den Betrieb des Systems zu überwachen und Vorfälle zu untersuchen.

2 Anforderungen an das kryptografische Protokoll für die vollständige Verifizierbarkeit (Art. 5)

• 2.1 Systemteilnehmende

Das kryptografische Protokoll regelt die Aufgaben der folgenden abstrakten Systemteilnehmenden:

• – stimmberechtigte / stimmende Person

• – Benutzerplattform

• – Setup-Komponente

• – nicht vertrauenswürdiges System (beliebige Komponenten unter Ausschluss der übrigen in dieser Ziffer aufgelisteten Komponenten; NV-System)

• – Druckkomponente

• – eine oder mehrere Gruppen von Kontrollkomponenten

• – Prüferinnen und Prüfer

• – technisches Hilfsmittel der Prüferinnen und Prüfer

• 2.2 Kommunikationskanäle

Das kryptografische Protokoll kann die folgenden Kommunikationskanäle zum Austausch von Nachrichten zwischen den Systemteilnehmenden vorsehen:

• – stimmberechtigte / stimmende Person ↔ Benutzerplattform

• – Benutzerplattform ↔ NV-System

• – Setup-Komponente ↔ NV-System

• – Kontrollkomponente ↔ NV-System

• – NV-System → Druckkomponente

• – NV-System → technisches Hilfsmittel der Prüferinnen und Prüfer

• – Druckkomponente → stimmberechtigte / stimmende Person

• – Setup-Komponente → technisches Hilfsmittel der Prüferinnen und Prüfer

• – Prüferinnen und Prüfer ↔ technisches Hilfsmittel der Prüferinnen und Prüfer

• – bidirektionale Kanäle für die Kommunikation zwischen den Kontrollkomponenten

• 2.3 Angreifer

• 2.3.1 Das kryptografische Protokoll muss vor einem Angreifer Schutz bieten, der versucht, missbräuchlich auf die Stimmen und das Ergebnis einzuwirken, das Stimmgeheimnis zu brechen oder Teilergebnisse vorzeitig zu erheben (Ziff. 2.5–2.8).

• 2.3.2 Es muss die Annahme getroffen werden, dass ein Angreifer über folgende Fähigkeiten verfügt:

  • – Er kann sämtliche nicht vertrauenswürdigen Systemteilnehmenden (vgl. Ziff. 2.4) unter seine Kontrolle bringen, so dass sie alle geheimen Daten mit ihm teilen und uneingeschränkt nach seinen Anweisungen handeln.

  • – Er kann sämtliche Nachrichten, die auf nicht vertrauenswürdigen Kanälen ausgetauscht werden, mitlesen und unterdrücken sowie selbst beliebige Nachrichten einspeisen.

• 2.4 Vertrauenswürdige und nicht vertrauenswürdige Systemteilnehmende und Kommunikationskanäle

• 2.4.1 Systemteilnehmende und Kommunikationskanäle gelten entweder als «vertrauenswürdig» oder als «nicht vertrauenswürdig». Die zulässigen Vertrauensannahmen für die einzelnen Systemteilnehmenden sind in Ziffer 2.9 geregelt.

• 2.4.2 Vertrauenswürdige Systemteilnehmende und Kommunikationskanäle werden als gegen Angreifer geschützt betrachtet. Für das kryptografische Protokoll darf namentlich von folgenden Annahmen ausgegangen werden:

  • – Vertrauenswürdige Systemteilnehmende halten vertrauliche Daten unter Verschluss und führen ausschliesslich jene Operationen durch, die durch das kryptografische Protokoll vorgegeben sind.

  • – Vertrauenswürdige Kommunikationskanäle halten die übertragenen Nachrichten unter Verschluss und schützen sie vor Manipulation.

• 2.5 Anforderung an das kryptografische Protokoll: individuelle Verifizierbarkeit

Die stimmberechtigte Person erhält Beweise nach Artikel 5 Absatz 2 in Verbindung mit Artikel 6 Buchstaben a und b zur Bestätigung, dass ein Angreifer:

• – bis zur Registrierung als eine systemkonform abgegebene Stimme keine Teilstimme der stimmberechtigten Person verändert oder unterschlagen hat;

• – nicht im Namen der stimmberechtigten Person missbräuchlich eine Stimme abgegeben hat, die in der Folge als systemkonform abgegebene Stimme registriert und gezählt worden ist.

• 2.6 Anforderung an das kryptografische Protokoll: universelle Verifizierbarkeit

Die Prüferinnen und Prüfer erhalten Beweise nach Artikel 5 Absatz 3 Buchstabe a in Verbindung mit Artikel 6 Buchstaben a und c zur Bestätigung, dass ein Angreifer:

• – nachdem die Stimmen als systemkonform abgegeben registriert worden sind, bis zur Berechnung des Ergebnisses keine Teilstimmen verändert oder unterschlagen hat;

• – keine nicht systemkonform abgegebenen Stimmen oder Teilstimmen eingefügt hat, die bei der Berechnung des Ergebnisses berücksichtigt wurden.

• 2.7 Anforderungen an das kryptografische Protokoll: Wahrung des Stimmgeheimnisses und Ausschluss von vorzeitigen Teilergebnissen

• 2.7.1 Es muss sichergestellt sein, dass ein Angreifer weder das Stimmgeheimnis brechen noch Teilergebnisse vorzeitig erheben kann, ohne zusätzlich die stimmberechtigten Personen oder deren Benutzerplattformen unter seine Kontrolle zu bringen.

• 2.7.2 Es besteht keine Pflicht, Angriffe zu verhindern, durch die die Anzahl der ausgezählten Stimmen so beschränkt wird, dass alle Teilstimmen für eine Abstimmungsfrage, Liste oder kandidierende Person gleich lauten.

• 2.7.3 Es muss sichergestellt sein, dass ein Angreifer die Benutzerplattformen nicht unbemerkt unter seine Kontrolle bringen kann, indem er die Software für die Benutzerplattformen auf dem Server manipuliert. Die stimmende Person muss die Möglichkeit haben zu prüfen, ob ihre Benutzerplattform vom Server die korrekte Software mit den korrekten Parametern, insbesondere dem öffentlichen Schlüssel zur Verschlüsselung der Stimme, erhalten hat.

• 2.8 Anforderung an das kryptografische Protokoll: wirksame Authentisierung

3. Anforderungen an vertrauenswürdige Komponenten nach Ziffer 2 und an deren Betrieb

• 3.1 Der Betrieb der Setup-Komponente und mindestens einer Kontrollkomponente der Gruppe, die einen Teil des Schlüssels zur Entschlüsselung der Stimmen enthält, gehört in die direkte Zuständigkeit des Kantons und muss in dessen Infrastruktur erfolgen. Die Auslagerung an einen privaten System­betreiber ist unzulässig.

• 3.2 Für die Wahl von Zufallswerten namentlich für Setup-Komponenten und Kontrollkomponenten ist die Verwendung von genügend Entropie sicherzustellen.

• 3.3 Prüferinnen und Prüfer müssen die Beweise nach Ziffer 2.6 mindestens einmal prüfen und dazu ein technisches Hilfsmittel nach Ziffer 2 einsetzen.

• 3.4 Die betrieblichen Anforderungen für Setup-Komponenten nach Ziffer 3 gelten auch für technische Hilfsmittel der Prüferinnen und Prüfer. Die Prüferinnen und Prüfer können im Rahmen ihrer Verantwortung, die durch das kantonale Recht festgelegt wird, Abweichungen vorsehen.

• 3.5 Der Kanton kann mit Ausnahme der unter den Ziffern 3.1 und 3.3 genannten Komponenten den Betrieb beliebiger Teile des Systems, einschliesslich der Kontrollkomponenten sowie der Druckkomponente, an private Dienstleister delegieren. Ein privater Betreiber der Druckkomponente darf ausschliesslich betriebliche Aufgaben wahrnehmen, die für die Aufbereitung, Verpackung und Zustellung eine Voraussetzung bilden.

• 3.6 Vertrauenswürdige Komponenten (Setup-Komponenten, Druckkomponenten, technische Hilfsmittel der Prüferinnen und Prüfer sowie Kontrollkomponenten) müssen in einem beobachtbaren Prozess aufgesetzt, aktualisiert, konfiguriert und abgesichert werden.

• 3.7 Vor der Installation einer Software ist für sämtliche Programme anhand einer offiziellen vertrauenswürdigen Grundlage zu prüfen, ob es sich bei den Dateien um die korrekte und unverfälschte Version handelt.

• 3.8 Bei der Installation elektronischer Zertifikate anderer Systemteilnehmender muss die Authentizität gewährleistet sein. Dazu ist ein manueller Prozess vorzusehen, bei dem Personen die elektronischen Zertifikate via einen physischen Datenträger nach Ziffer 3.13 von einer Maschine zur anderen bringen.

• 3.9 Der Zeitpunkt für die Aktualisierung der gesamten Software von vertrauenswürdigen Komponenten ist so zu wählen, dass die dadurch erwarteten Vorteile gegenüber den möglichen Gefahren überwiegen.

• 3.10 Setup-Komponenten, Druckkomponenten und technische Hilfsmittel der Prüferinnen und Prüfer, die in irgendeiner Form an der Bearbeitung von kritischen Daten beteiligt sind, müssen während der gesamten Rechenzeit und bis zur Löschung allfälliger kritischer Daten oder bis zur sicheren Aufbewahrung im Vieraugenprinzip physisch überwacht werden. Sie dürfen höchstens über sichtbare physische Kabel untereinander verbunden sein, damit bis zur Vernichtung der vertraulichen Daten möglichst ersichtlich ist, dass keine weiteren Maschinen auf sie zugreifen können.

• 3.11 Für die Installation oder die Aktualisierung von Software dürfen vertrauenswürdige Komponenten nicht mit dem Internet verbunden werden.

• 3.12 Im Grundsatz müssen kritische Daten nach ihrer Verwendung vernichtet werden. Beim Vorliegen guter Gründe ist als Alternative auch eine sichere Aufbewahrung des Datenträgers erlaubt.

• 3.13 Datenträger für den Datenaustausch oder die Aufbewahrung von Daten, wie USB-Sticks, müssen nach dem Aufspielen der Daten in die vertrauenswürdige Komponente entfernt werden und dürfen vor der Vernichtung der Daten nur dann wiederverwendet werden, wenn sich auf der vertrauenswürdigen Komponente vor dem Aufspielen der Daten keine kritischen Daten befunden haben.

• Datenträger für den Datenaustausch müssen vor der Verwendung mithilfe einer Komponente, die entsprechend den Anforderungen an vertrauenswürdige Komponenten betrieben wird, neu formatiert und allfällige Daten darauf müssen vernichtet werden.

• 3.14 Es darf kein logischer Zugriff auf oder physischer Zugang zu vertrauenswürdigen Komponenten oder Datenträgern mit kritischen Daten möglich sein, ohne dass eine andere Person dies bemerkt, beispielsweise indem sie für die Gewährung des Zugriffs mitwirken muss (strenges Vieraugenprinzip).

• 3.15 Ein geglückter unerlaubter Zugriff auf eine Kontrollkomponente soll möglichst keinen Vorteil beim Versuch verschaffen, auf eine weitere Kontrollkomponente unbemerkt zuzugreifen. Zusätzlich zu den übrigen Anforderungen nach Ziffer 3 gelten dahingehend die folgenden Anforderungen:

  • − Hat eine Person einen physischen oder logischen Zugriff auf eine Kontrollkomponente, so darf sie keinen Zugriff auf eine andere Kontrollkomponente haben.

  • − Die Hardware, die Betriebssysteme und die Überwachungssysteme der Kontrollkomponenten sollen sich möglichst unterscheiden.

  • − Die Kontrollkomponenten sollen an unterschiedliche lokale Netzwerke angeschlossen sein.

  • − Eine Kontrollkomponente muss durch ein physisches Gerät realisiert werden. Die Virtualisierung über mehrere physische Geräte ist nicht zulässig.

• 3.16 Kontrollkomponenten müssen darauf ausgerichtet sein, unerlaubte Zugriffe zu erkennen und die verantwortlichen Personen zu alarmieren. Die verantwortlichen Personen sollen externe Überwachungsmassnahmen vorsehen, wie beispielsweise die Überwachung und die manipulationsresistente Protokollierung des Netzverkehrs oder die physische Überwachung mit Kameras, die ihrer Kontrolle unterliegen. Die verantwortlichen Personen müssen als besonders vertrauenswürdig und zuverlässig gelten.

• 3.17 Vertrauenswürdige Komponenten dürfen ausschliesslich die vorgesehenen Operationen durchführen.

• 3.18 Die Software des technischen Hilfsmittels der Prüferinnen und Prüfer muss von einem anderen Systementwickler bezogen werden als jenem, der den grössten Teil der Software der übrigen Systembestandteile entwickelt hat. Die Publikation der Software des technischen Hilfsmittels unter einer Lizenz, die die Kriterien nach Open Source Software³ erfüllt, kann eine Ausnahme begründen. Bringen Prüferinnen und Prüfer mehrere technische Hilfsmittel zum Einsatz, so gilt diese Bestimmung für mindestens eines der Hilfsmittel.

• 3.19 Alle Abläufe im Umgang mit vertrauenswürdigen Komponenten müssen schriftlich und für die betroffenen Personen leicht verständlich dokumentiert sein.

• 3.20 Jeder Zugriff und jede Verwendung einer vertrauenswürdigen Komponente oder eines Datenträgers mit kritischen Daten müssen protokolliert werden.

4. Stimmvorgang

• 4.1 Die stimmende Person erklärt, dass sie die Regeln der elektronischen Stimmabgabe und ihre Verantwortlichkeit zur Kenntnis genommen hat.

• 4.2 Die stimmende Person wird, bevor sie ihre Stimme abgibt, darauf aufmerksam gemacht, dass sie damit am Urnengang teilnimmt, wie wenn sie brieflich oder persönlich an der Urne abstimmen würde. Die stimmende Person kann ihre Stimme erst abgeben, nachdem sie bestätigt hat, dies zur Kenntnis genommen zu haben.

• 4.3 Die stimmende Person wird bei der Stimmabgabe aufgefordert, die Beweise nach Ziffer 2.5 anhand der Verifizierungsreferenz zu prüfen und allfällige Zweifel an deren Korrektheit beim Kanton zu melden.

• 4.4 Vor der definitiven elektronischen Stimmabgabe kann die stimmberechtigte Person ihre Stimme weiterhin über einen konventionellen Stimmkanal abgeben.

• 4.5 Das clientseitige System, wie es sich der stimmenden Person präsentiert, beeinflusst diese nicht in ihrer Entscheidungsfindung.

• 4.6 Die Benutzerführung verleitet nicht zu einer übereilten oder unüberlegten Stimmabgabe.

• 4.7 Das System bietet der stimmenden Person keine Funktion zum Ausdrucken oder Abspeichern der Stimme.

• 4.8 Der stimmenden Person wird nach Abschluss der Stimmabgabe keinerlei Information zum Inhalt der abgegebenen verschlüsselten Stimme angezeigt.

• 4.9 Einer stimmberechtigten Person, die keine Stimme abgeben kann, weil Drittpersonen unter missbräuchlicher Verwendung ihres Stimmmaterials eine Stimme abgegeben haben, kann der Kanton die Stimmabgabe weiterhin ermöglichen, indem er die missbräuchlich abgegebene Stimme für nichtig erklärt. Das Stimmgeheimnis nach Ziffer 2.7 ist zu wahren.

• 4.10 Für eine stimmberechtigte Person mit einer Behinderung dürfen Erleichterungen zur Überprüfung der Beweise vorgesehen werden. Ausschliesslich in einem solchen Fall darf von den Anforderungen nach Ziffer 2.9.1 abgewichen werden.

• 4.11 Solange das System keine Bestätigung der definitiven elektronischen Stimmabgabe registriert hat, kann eine stimmberechtigte Person ihre Stimme weiterhin über einen konventionellen Stimmkanal abgeben.

• 4.12 Die Verwendung eines von der elektronischen Stimmabgabe unabhängigen Authentisierungsmittels ist erlaubt. Auswirkungen auf die Integrität der Stimmrechtsprüfung sowie die Wahrung des Stimmgeheimnisses sind im Rahmen der Risikobeurteilung vertieft zu prüfen.

5. Vorbereitung des Urnengangs

• 5.1 Werden die Stimmregisterdaten aus einem Drittsystem importiert, das sich ausserhalb der Kontrolle des Kantons befindet, so müssen die Daten verschlüsselt und signiert werden. Die Signatur muss bei Erhalt solcher Daten überprüft werden. Für die Zustellung an die Druckerei gehen die Bestimmungen nach Ziffer 7 vor.

• 5.2 Die Daten, die für die Prüfung der Beweise nach Ziffer 2.6 notwendig sind, werden an die Prüferinnen und Prüfer übergeben.

6. Anforderungen an die Stimmrechtsausweise

• 6.1 Die Stimmrechtsausweise sind nach Möglichkeit so auszugestalten, dass sie Stimmberechtigten mit einer Behinderung einen barrierefreien Zugang zur elektronischen Stimmabgabe erlauben.

• 6.2 Sicherheitselemente auf dem Stimmrechtsausweis (z. B. Rubbelfelder) dürfen nur verwendet werden, wenn ein Nachweis vorliegt, dass die verdeckte Information gut vor unerlaubtem Lesen geschützt ist.

• 6.3 Wird auf die Verwendung von Sicherheitselementen zum Schutz vertraulicher Informationen auf dem Stimmrechtausweis verzichtet, so müssen Organisationsabläufe zur Gewährleistung der Sicherheit vorhanden sein.

7. Anforderungen an Druckereien

• 7.1 Die Druckdaten zur Produktion der Stimmrechtsausweise werden verschlüsselt und signiert zugestellt. Alternativ kann auch ein Datenträger mit den entsprechenden Daten persönlich überbracht werden. In diesem Fall erfolgt die Übergabe des Datenträgers an die Druckerei, einschliesslich des Transports, durch zwei Personen und wird von diesen gemeinsam überwacht (Vieraugenprinzip).

• 7.2 Die Verschlüsselung muss den Anforderungen aus dem eCH-Standard 0014⁴, Kapitel 7.5 genügen. Bei symmetrischer Verschlüsselung wird das Geheimelement zur Entschlüsselung den Verantwortlichen der Druckerei auf einem sicheren Zweitweg zugestellt.

• 7.3 Die Verantwortlichen der Druckerei, die den Datenträger entgegennehmen, unterschreiben eine Empfangsbestätigung.

• 7.4 Für den Datenträger mit den Druckdaten, die Komponente, auf der die kritischen Daten entschlüsselt werden, sowie alle Komponenten, die die kritischen Daten verarbeiten, gelten die Bestimmungen nach Ziffer 3 an die Druckkomponente.

• 7.5 Die Verantwortlichen der Druckerei nehmen eine Material­mengenkontrolle vor.

• 7.6 Nach dem Drucken der Stimmrechtsausweise vernichtet die Druckerei die erhaltenen Daten.

• 7.7 Nimmt die Druckerei auch die Verpackung und den Versand der Stimmrechtsausweise vor, so sind diese unverzüglich nach dem Druck zusammen mit dem Stimmmaterial zu verpacken.

• 7.8 Die Vertrauenswürdigkeit des Kanals zwischen der Druckerei und den stimmberechtigten Personen darf nur dann als gegeben erachtet werden, wenn die nach kantonalem Recht zuständigen Stellen das verpackte Stimmmaterial den stimmberechtigten Personen brieflich zustellen oder die persönliche Übergabe sicherstellen.

8. Informationen und Anleitungen

• 8.1 Die auf kantonaler Ebene verantwortliche Stelle erstellt ein Konzept zur Information der Bürgerinnen und Bürger über die elektronische Stimmabgabe.

• 8.2 Das Konzept gewährleistet, dass die Informationen von den zuständigen Gremien autorisiert werden.

• 8.3 Auf dem Internet finden sich Ratschläge und Anleitungen zur Stimmabgabe sowie Informationen zur Verantwortlichkeit der stimmberechtigten Personen. Diese wirken einer überstürzten oder unüberlegten Handlungsweise entgegen.

• 8.4 Den stimmberechtigten Personen werden die Verifizierbarkeit, weitere Sicherheitsmassnahmen sowie das Vorgehen bei Anomalien auf zugängliche Weise erklärt.

• 8.5 Den stimmberechtigten Personen wird erklärt, worauf sie achten müssen, damit sie ihre Stimme sicher abgeben können.

• 8.6 Den stimmberechtigten Personen wird erklärt, wie die Stimme in der zur Stimmeingabe verwendeten Benutzerplattform nach der Stimmabgabe auf allen Speichern gelöscht werden kann.

• 8.7 Die stimmberechtigten Personen können bei Fragen zur elektronischen Stimmabgabe Unterstützung anfordern.

• 8.8 Die stimmberechtigten Personen werden aufgerufen, falsch angezeigte Beweise nach Ziffer 2.5, wie Prüfcodes, oder weitere Prüfungen mit negativem Ergebnis bei der auf kantonaler Ebene verantwortlichen Stelle zu melden. Dieser Aufruf wird auch mit dem Stimmmaterial verbreitet.

• 8.9 Die stimmberechtigten Personen werden aufgerufen, das Stimmmaterial mit den Sicherheitselementen, die in Erfüllung von Ziffer 2.5 stehen, bis zur definitiven Stimmabgabe oder bis zum Abschluss des Urnengangs unter Verschluss zu halten.

• 8.10 Die stimmberechtigten Personen erhalten die nötigen Angaben, um die Authentizität der zur Stimmabgabe benutzten Internetseite, des Servers und der Software zu kontrollieren. Die Aussagekraft einer erfolgreichen Kontrolle muss durch den Einsatz kryptografischer Mittel gemäss besten Praktiken unterstützt werden.

• 8.11 Die für die sichere Stimmabgabe wesentlichen Informationen werden mit dem Stimmmaterial verschickt. Den stimmberechtigten Personen wird erklärt, dass sie sich im Zweifelsfall an die Informationen des Stimmmaterials halten sollen und nicht an die Informationen, die auf der Benutzerplattform angezeigt werden.

• 8.12 Den stimmberechtigten Personen wird erklärt, durch welche Vorkehrungen die Wahrung des Stimmgeheimnisses sichergestellt ist.

• 8.13 Bekannte Mängel und der mit ihnen verbundene Handlungsbedarf werden transparent kommuniziert.

• 8.14 Die Prüferinnen und Prüfer werden zu Prozessen, denen die Korrektheit des Ergebnisses, die Wahrung des Stimmgeheimnisses und den Ausschluss von vorzeitigen Teilergebnissen unterliegen (beispielsweise Schlüsselgenerierung, Druck des Stimmmaterials, Entschlüsselung und Auszählung), angemessen informiert und geschult. Sie sind in der Lage, die Vorgänge und ihre Bedeutung in den Kernpunkten zu verstehen.

9. Öffnen und Schliessen des elektronischen Stimmkanals

10. Konformitätskontrolle und Ablage endgültig abgegebener Stimmen

11. Auszählung der elektronischen Urne

• 11.1 Die Entschlüsselung der Stimmen und deren Auszählung dürfen frühestens am Abstimmungs- oder Wahlsonntag beginnen.

• 11.2 Der Kanton führt die Entschlüsselung und die Auszählung in der eigenen Infrastruktur durch.

• 11.3 Der Kanton sorgt für die Protokollierung der Entschlüsselung der Stimmen und deren Auszählung. Die Freigabe des Protokolls erfolgt durch die auf kantonaler Ebene verantwortliche Stelle.

• 11.4 Von der Entschlüsselung der Stimmen bis zur Übermittlung des Ergebnisses des Urnengangs erfolgt jeder Zugriff auf das System oder auf eine seiner Komponenten durch mindestens zwei Personen gemeinsam; er wird schriftlich aufgezeichnet und muss von den Prüferinnen und Prüfern kontrolliert werden können.

• 11.5 Werden die Ergebnisdaten an ein Drittsystem übermittelt, das sich ausserhalb der Kontrolle des Kantons befindet, werden die Daten verschlüsselt und signiert.

• 11.6 Das System ermöglicht es, dass anhand des Stimmrechtsausweises festgestellt werden kann, ob jemand eine elektronische Stimme abgegeben hat.

• 11.7 Bei der Entschlüsselung und Auszählung sind Prüferinnen und Prüfer anwesend. Die Kantone können zusätzlich Prüfarbeiten aus der Ferne ermöglichen.

• 11.8 Sind Komponenten, die zur Auszählung der Stimmen verwendet werden, nach Ziffer 2.4 nicht vertrauenswürdig, so gelten für diese dieselben Anforderungen wie für Setup-Komponenten nach Ziffer 3.

• 11.9 Die Prüferinnen und Prüfer nehmen bei der Prüfung der Beweise nach Ziffer 2.6 ihre Verantwortung nach Massgabe des kantonalen Rechts wahr.

• 11.10 Die auf kantonaler Ebene verantwortliche Stelle unterbreitet den Prüferinnen und Prüfern sämtliche relevanten Indikatoren für die Korrektheit des Ergebnisses. Dazu gehören nebst den Beweisen nach Ziffer 2.6 insbesondere auch die Zahl und die Art von Anomalien, die durch stimmberechtigte Personen beim Kanton gemeldet wurden.

• 11.11 Der Kanton antizipiert allfällige Anomalien und erstellt dahingehend in Absprache mit den betroffenen Stellen einen Notfallplan, der das jeweilige Vorgehen festlegt. Er schafft Transparenz gegenüber der Öffentlichkeit.

• 11.12 Zur Plausibilisierung des Ergebnisses sollen statistische Methoden eingesetzt werden, soweit sie verfügbar sind und soweit die Datenbasis dies erlaubt.

12. Vertrauliche Daten

• 12.1 Es ist sichergestellt, dass weder Mitarbeitende noch externe Personen Daten kennen, die einen Bezug zwischen der Identität der stimmenden Person und ihrer Stimme zulassen.

• 12.2 Es ist sichergestellt, dass weder Mitarbeitende noch externe Personen vor dem Zeitpunkt der Entschlüsselung der Stimmen Daten kennen, die die vorzeitige Erhebung von Teilergebnissen erlauben.

• 12.3 Der Kanton darf seinen Teil des Schlüssels zur Entschlüsselung der Stimmen, der ihm nach Ziffer 3.1 auf der von ihm betriebenen Kontrollkomponente vorliegt, nicht an private Unternehmen weiterleiten.

• 12.4 Der Kanton behandelt die Ergebnisse des Urnengangs zwischen dem Zeitpunkt der Entschlüsselung der Stimmen und dem Zeitpunkt der Publikation vertraulich.

• 12.5 Der Kanton sorgt dafür, dass Daten vertraulich behandelt werden, die es erlauben festzustellen, ob eine stimmberechtigte Person auf dem elektronischen Weg eine Stimme abgegeben hat.

• 12.6 Der Kanton behandelt die einzelnen Stimmen nach der Auszählung vertraulich.

• 12.7 Der Kanton sorgt dafür, dass Abstimmungs- und Wahlergebnisse kleiner Wahlkreise vertraulich behandelt werden.

• 12.8 Nach der Erwahrung werden gemäss einem vorgegebenen und dokumentierten Prozess sämtliche Daten vernichtet, die im Rahmen des elektronischen Urnengangs angefallen sind, in Bezug zu den einzelnen eingegangenen Stimmen stehen und als vertraulich klassifiziert sind.

13. Bedrohungen

• 13.1 Die in den Ziffern 13.3–13.40 aufgelisteten Bedrohungen sind allgemeiner Art und bilden eine Grundlage, die zu ergänzen ist. Sie beziehen sich auf die Sicherheitsziele und sind bei der Identifizierung von Risiken zu berücksichtigen. In Abhängigkeit der identifizierten Schwachstellen des Systems und bei der Risikobeurteilung der verschiedenen Stellen ist die Liste entsprechend der konkreten Konstellation und in Abhängigkeit der spezifischen Bedrohung zu konkretisieren und zu ergänzen.

• 13.2 Als mögliche Bedrohung gelten:

  • – versehentlich oder absichtlich verursachte Bedrohungen, die von internen oder externen Akteurinnen und Akteuren ausgehen, die elektronische oder physische Mittel einsetzen;

  • – Bedrohungen, die auf eine Fehlfunktion des Systems oder der systemunterstützenden Elemente zurückzuführen sind.

14. Feststellung und Meldung von Sicherheitsereignissen und

• 14.1 Ein Monitoringsystem der Infrastruktur erkennt die Zwischenfälle, die die Sicherheit, einschliesslich der Verfügbarkeit, des Systems gefährden könnten, und alarmiert das zuständige Personal. Das Personal behandelt Zwischenfälle gemäss vordefinierten Verfahren. Krisenszenarien und Rettungspläne dienen als Leitlinie (darin inbegriffen ist ein Plan, der gewährleistet, dass die auf den Urnengang bezogenen Aktivitäten weitergeführt werden können) und kommen bei Bedarf zur Anwendung.

• Fehler bei der Registrierung der Stimme in den Kontrollkomponenten und in der Urne müssen erkannt werden. Dabei müssen weitere Informationen im Zusammenhang mit dem Fehler verfügbar sein, um die Ursache zu erkennen und zu beheben. Festgestellte Vorfälle sind der auf kantonaler Ebene verantwortlichen Stelle zu melden.

• 14.2 Auf der Infrastruktur werden Protokolle erstellt, deren Erfassung, Übertragung und Speicherung gegen Manipulationen resistent sind (Systemprotokolle). Die Protokolle sind untereinander konsistent und ermöglichen bei der Untersuchung von vermuteten Manipulationen oder Fehlern die Rückverfolgung der relevanten Ereignisse. Sie dienen als Belege für die vollständige, unverfälschte und ausschliessliche Berücksichtigung systemkonform abgegebener Stimmen sowie für die Wahrung des Stimmgeheimnisses und den Ausschluss von vorzeitigen Teilergebnissen.

• Der Inhalt der Protokolle umfasst mindestens die folgenden Ereignisse:

  • – Start und Ende der Audit-, Identifizierungs- und Authentisierungsprozesse

  • – Start, Neustart und Ende der Abstimmungs- oder Wahlphase

  • – Start der Auszählung mit der Ergebnisermittlung

  • – Durchführung und Ergebnisse allfälliger Selbsttests

  • – festgestellte Störungen in den Elementen der IT-Infrastruktur, die die Betriebsfähigkeit beeinträchtigen

• Von jedem Ereignis werden das Datum und die Uhrzeit, die Art des Ereignisses, der mögliche Verursacher und das Ergebnis im Sinne von Misserfolg oder Erfolg dokumentiert.

• Die Systemprotokolle werden der auf kantonaler Ebene verantwortlichen Stelle so zur Verfügung gestellt, dass diese die Informationen interpretieren kann.

• 14.3 Das Monitoring und die Erfassung von Systemprotokollen unterliegen einem ständigen Verbesserungsprozess. Der Verbesserungsprozess beinhaltet einen offenen Dialog zwischen den beteiligten Akteurinnen und Akteuren sowie eine regelmässige und objektive Beurteilung der Wirksamkeit der eingesetzten Instrumente und Prozesse. Die Ergebnisse dieser Evaluationen werden dabei berücksichtigt.

• 14.4 Das Monitoring und die Erfassung von Systemprotokollen beeinträchtigen die Wirksamkeit der Massnahmen zur Wahrung des Stimmgeheimnisses in keiner Weise.

• 14.5 Es ist gewährleistet, dass im Falle einer Panne die Stimmen und die Daten, die ein reibungsloses Funktionieren des Verfahrens bei der Auszählung der Stimmen belegen, unversehrt auf der Infrastruktur gespeichert werden.

• 14.6 Nach einer Panne des Systems oder einem Ausfall von Kommunikations- oder Speichermedien geht das System in einen Wartungsmodus über, in dem die Möglichkeit besteht, in einen sicheren Zustand zurückzukehren. Begonnene Stimmvorgänge werden unterbrochen. Die stimmende Person kann die Stimmabgabe erst dann wieder aufnehmen, wenn sich das System wieder in einem sicheren Zustand befindet.

• 14.7 Es ist möglich, mit Hilfe von Authentisierungsmerkmalen Kontrollstimmen abzugeben, die keiner stimmberechtigten Person zugewiesen sind. Der Inhalt dieser Kontrollstimmen wird protokolliert. Die Auszählung der Kontrollstimmen wird mit den Protokollen verglichen.

• Es ist sichergestellt, dass die Kontrollstimmen möglichst ähnlich gehandhabt werden wie systemkonform abgegebene Stimmen, gleichzeitig ist sichergestellt, dass sie nicht gezählt werden.

• 14.8 Die Verfügbarkeit der Infrastruktur wird in gewählten Zeitabständen überprüft und protokolliert.

• 14.9 Durch einen vorgegebenen und dokumentierten Prozess werden alle Teile des Systems regelmässig aktualisiert, um bekanntgewordene Schwachstellen zu eliminieren.

• 14.10 Die Massnahmen für das Monitoring und zur Protokollierung der Systembenutzung, der Tätigkeiten von Administratoren und zur Störungsprotokollierung werden detailliert beschrieben, umgesetzt, überwacht und überprüft.

15. Einsatz von kryptografischen Massnahmen und Schlüsselverwaltung

• 15.1 Elektronische Zertifikate werden nach besten Praktiken verwaltet.

• 15.2 Zur Sicherstellung der Integrität von Datensätzen, der die Korrektheit des Ergebnisses sowie die Geheimhaltung kritischer Daten unterliegt, einschliesslich der Identifikations- und Authentifizierungsdaten der Behörden, kommen wirksame kryptografische Massnahmen zum Einsatz, die dem Stand der Technik entsprechen.

• 15.3 Zur Sicherstellung der Geheimhaltung kritischer Daten kommen in der Infrastruktur wirksame kryptografische Massnahmen zum Einsatz, die dem Stand der Technik entsprechen. Solche Daten werden auf Datenträgern immer verschlüsselt abgespeichert.

• 15.4 Kryptografische Grundkomponenten kommen nur dann zur Anwendung, wenn die Schlüssellängen und Algorithmen den gängigen Standards entsprechen (z. B. NIST, ECRYPT, ZertES). Die elektronische Signatur erfüllt die Anforderungen an eine fortgeschrittene elektronische Signatur nach dem Bundesgesetz vom 18. März 2016⁹ über die elektronische Signatur (ZertES). Die Verifikation der Signatur erfolgt mittels eines elektronischen Zertifikats, das von einem nach dem ZertES anerkannten Anbieter von Zertifizierungsdiensten ausgestellt wird.

16. Sicherer elektronischer und physischer Informationsaustausch

• 16.1 Sämtliche Komponenten der Infrastruktur werden in einer separaten Netzwerkzone betrieben. Diese Netzwerkzone wird durch eine angemessene Routingkontrolle gegenüber dem übrigen Netzwerk geschützt.

• 16.2 Die elektronische Stimmabgabe ist von sämtlichen anderen Anwendungen grundsätzlich klar getrennt.

17. Tests des Systems

• 17.1 Die Funktionen, die für die Sicherheit des Systems relevant sind (Sicherheitsfunktionen), werden getestet. Die Tests werden mit Testplänen sowie mit erwarteten und tatsächlichen Testergebnissen dokumentiert.

• Der Testplan:

  • – legt die auszuführenden Tests fest;

  • – beschreibt die Szenarien für jeden Test, einschliesslich allfälliger Abhängigkeiten von den Ergebnissen anderer Tests.

• Die erwarteten Ergebnisse müssen die Ergebnisse aufzeigen, die bei erfolgreicher Testausführung erwartet werden.

• Die tatsächlichen Ergebnisse müssen mit den erwarteten Ergebnissen übereinstimmen.

• 17.2 Es wird eine Analyse der Testabdeckung erstellt. Diese umfasst den Nachweis, dass:

  • – die in der Testdokumentation definierten Tests und die funktionalen Spezifikationen der Schnittstellen übereinstimmen;

  • – alle Schnittstellen vollständig getestet wurden.

• 17.3 Es wird eine Analyse der Testtiefe durchgeführt. Diese umfasst den Nachweis, dass:

  • – die in der Testdokumentation definierten Tests und die Teilsysteme, die sich auf Sicherheitsfunktionen und Module beziehen, die eine Rolle bei der Gewährleistung der Sicherheit spielen, übereinstimmen;

  • – alle Teilsysteme, die mit den in den Spezifikationen genannten Sicherheitsfunktionen zusammenhängen, getestet wurden;

  • – alle Module, die bei der Gewährleistung der Sicherheit eine Rolle spielen, getestet wurden.

18. Organisation der Informationssicherheit

• 18.1 Alle Rollen und Verantwortlichkeiten für den Betrieb des Systems werden präzise definiert, zugeordnet und kommuniziert.

• 18.2 Die initiale Konfiguration der Infrastruktur, sei es in Bezug auf die Hardware, die Software oder die Zugriffsrechte, sowie jede Änderung müssen vorher genehmigt werden.

• 18.3 Die Risiken im Zusammenhang mit Dritten (Auftragnehmer wie Lieferanten und Dienstleister) werden identifiziert und über angemessene vertragliche Vereinbarungen soweit nötig reduziert. Die Einhaltung der Vereinbarungen wird während ihrer Laufzeit angemessen überwacht und überprüft.

19. Verwaltung der immateriellen und materiellen Ressourcen

• 19.1 Alle immateriellen und materiellen Ressourcen im Sinne des Begriffs Asset in der Norm ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements¹⁰, die im Zusammenhang mit der elektronischen Stimmabgabe relevant sind (Organisation als Ganzes, insbesondere die Organisationsprozesse und die in diesen Prozessen bearbeiteten Informationen, Datenträger, Einrichtungen zur Informationsverarbeitung der Infrastruktur und Räumlichkeiten der Infrastruktur) werden in einem Inventar erfasst. Über das Personal wird eine Liste geführt. Das Inventar und die Personalliste sind aktuell zu halten. Jeder immateriellen und materiellen Ressource wird eine Person zugewiesen, die dafür die Verantwortung übernimmt.

• 19.2 Der zulässige Gebrauch von immateriellen und materiellen Ressourcen wird definiert.

• 19.3 Für Informationen werden Klassifizierungsleitlinien erlassen und kommuniziert.

• 19.4 Für die Kennzeichnung und Handhabung von Informationen werden Verfahren eingerichtet.

20. Vertrauenswürdigkeit des Personals

• 20.1 Zur Gewährleistung der Vertrauenswürdigkeit des Personals vor, während und nach Beendigung der Anstellung oder bei Rollenwechseln werden angemessene Richtlinien und Verfahren eingerichtet und kommuniziert.

• 20.2 Für die Gewährleistung der Vertrauenswürdigkeit des Personals übernehmen die Personalverantwortlichen die volle Verantwortung.

• 20.3 Das gesamte Personal verfügt über ein ausgeprägtes Informationssicherheitsbewusstsein. Dazu wird ein aufgabengerechtes Ausbildungs- und Trainingsprogramm eingerichtet und betrieben.

21. Physische und umgebungsbezogene Sicherheit

• 21.1 Die Sicherheitsperimeter der verschiedenen Räumlichkeiten der Infrastruktur sind klar definiert.

• 21.2 Für den physischen Zugang zu diesen verschiedenen Räumlichkeiten der Infrastruktur werden Zugangsberechtigungen definiert, eingerichtet und angemessen kontrolliert.

• 21.3 Zur Gewährleistung der Sicherheit von Geräten innerhalb und ausserhalb der Räumlichkeiten der Infrastruktur werden angemessene Richtlinien und Verfahren definiert und deren Einhaltung überwacht und überprüft.

• 21.4 Sämtliche Daten werden ausschliesslich in der Schweiz bearbeitet und insbesondere aufbewahrt.

22. Management der Kommunikation und des Betriebs

• 22.1 Pflichten und Verantwortlichkeitsbereiche werden so aufgeteilt, dass die mit dem Betrieb und der Kommunikation verbundenen Risiken personellen Ursprungs auf Restrisiken reduziert werden, die mit den Risikoakzeptanzkriterien kompatibel sind.

• 22.2 Zum Schutz vor Schadsoftware werden angemessene Massnahmen getroffen.

• 22.3 Es wird ein detaillierter Plan für die Datensicherung erstellt und umgesetzt. Die korrekte Funktion der Datensicherung wird regelmässig überprüft.

• 22.4 Es werden angemessene Massnahmen zum Schutz des Netzwerks vor Bedrohungen, die in der Risikobeurteilung nach Artikel 4 in Verbindung mit Ziffer 13 ausgewiesen werden, und zur Sicherheit von Netzwerkservices definiert und umgesetzt.

• 22.5 Die Verfahren zur Handhabung von Wechseldatenträgern und zur Entsorgung von Datenträgern werden detailliert geregelt.

23. Zuteilung, Verwaltung und Entzug von Zugangs- und Zugriffsrechten

• 23.1 Es ist gewährleistet, dass während des Urnengangs jede nachträgliche Änderung von Zugangs- und Zugriffsrechten nur mit der Zustimmung der auf kantonaler Ebene verantwortlichen Stelle erfolgt.

• 23.2 Der Zugang zu und der Zugriff auf die Infrastruktur und die Software werden auf der Basis einer Risikobeurteilung detailliert geregelt und dokumentiert. In Hochrisikobereichen sowie für alle manuellen Operationen im Zusammenhang mit der elektronischen Urne (z. B. Öffnung des Stimmkanals, Schliessung des Stimmkanals, Start der Auszählung) gilt das Vieraugenprinzip.

• Manuelle Operationen im Zusammenhang mit der elektronischen Urne (z. B. Öffnung des Stimmkanals, Schliessung des Stimmkanals, Start der Auszählung) werden explizit authentifiziert.

• 23.3 Es ist gewährleistet, dass Informationen auf der Website zur elektronischen Stimmabgabe und diesbezügliche Informationsseiten nicht ohne Berechtigung geändert werden können.

• 23.4 Während des Urnengangs sind sachfremde Zugriffe jeglicher Art auf die Infrastruktur ausgeschlossen.

• 23.5 Es ist sichergestellt, dass keines der Elemente der clientseitigen Authentisierungsmerkmale bei der Zustellung systematisch abgefangen, verändert oder umgeleitet werden kann. Zur Authentisierung kommen Massnahmen und Technologien zum Einsatz, die das Risiko des systematischen Missbrauchs durch Dritte hinreichend minimieren.

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, der 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 ersichtlich.

• 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 «komplex» 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 übersichtliche Darstellung der mit Sicherheitsfunktionen verbundenen Teilsysteme für den Nachweis, dass alle Schnittstellen dem in der Spezifikation beschriebenen Verhalten entsprechen; die Darstellung muss einen Detaillierungsgrad mindestens bis zu den Modulen aufweisen.

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

  • – die Commit-History¹¹;

  • – 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 Sicherheits­funktionen unterliegen;

  • – eine Beschreibung der Sicherheitsmassnahmen, die umzusetzen sind, um die betrieblichen Sicherheitsziele zu erreichen.

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

• 24.2.3 Das Betriebshandbuch ist präzise und zweckmässig.

• 24.3 Zuverlässige und nachvollziehbare Kompilierung und zuverlässiges und nachvollziehbares 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 der 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 wird eine zuverlässige und überprüfbare Kompilierung mit angemessenen Sicherheitsmassnahmen durchgeführt, die sicherstellt, dass der ausführbare Code eine überprüfbare und getreue Darstellung des Quellcodes ist, der einer öffentlichen Kontrolle und unabhängigen Überprü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 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 wird ein zuverlässiges und überprüfbares Deployment mit angemessenen Sicherheitsmassnahmen durchgeführt, das sicherstellt, dass:

  1. der produktiv eingesetzte Code eine überprüfbare und getreue Darstellung des Quellcodes ist, der einer öffentlichen Kontrolle und unabhängigen Überprüfungen unterzogen wurde; und

  2. dass die Produktionsumgebung mit derjenigen übereinstimmt, die der öffentlichen Kontrolle und unabhängigen Überprü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 bekanntzumachen;

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

25 Qualität Quellcode und Dokumentation

Der Quellcode und die Dokumentation erfüllen mindestens die folgenden Qualitätskriterien:

• 25.1 Nachvollziehbarkeit

• 25.1.1 Unter Nachvollziehbarkeit wird die Stringenz von den Anforderungen bis hin zur Implementierung verstanden.

• 25.1.2 Alle Anforderungen an das kryptografische Protokoll sind über sämtliche Arbeitsergebnisse im Zusammenhang mit dem Softwareentwicklungsprozess hinweg nachvollziehbar.

• 25.1.3 Für die Verbindung zwischen den rechtlichen Anforderungen und dem kryptografischen Protokoll, den Spezifikationen sowie der Dokumentation der Architektur gibt es eine Beschreibung.

• 25.2 Vollständigkeit

• 25.2.1 Unter Vollständigkeit wird die vollständige Umsetzung der geforderten Funktionen verstanden.

• 25.2.2 Die Software enthält keine mehrdeutigen Verweise (Input, Funktion, Output). Wird dasselbe Element referenziert, wird dazu immer die gleiche Bezeichnung verwendet.

• 25.2.3 Alle referenzierten Daten und alle verwendeten Funktionen sind in den Spezifikationen definiert.

• 25.2.4 Es werden alle in den Spezifikationen definierten Funktionen verwendet.

• 25.2.5 Für jeden Entscheidungspunkt (z. B. bedingte Ausführung) sind die möglichen Alternativen in den Spezifikationen definiert.

• 25.2.6 Alle Parameter sind in den Spezifikationen definiert und validiert (keine implizite Parameterübergabe).

• 25.2.7 Alle schwerwiegenden, gemeldeten Fehler werden behoben, bevor mit dem nächsten Schritt im Entwicklungszyklus fortgefahren wird.

• 25.2.8 Das kryptografische Protokoll, die Spezifikation, das Design und der Quellcode sind aufeinander abgestimmt.

• 25.3 Kohärenz

• 25.3.1 Unter Kohärenz wird die Verwendung einheitlicher Verfahren und Notationen bei der Konzeption und der Implementierung verstanden.

• 25.3.2 Die Darstellungen in der Dokumentation entsprechen einer Konvention, die die Softwareentwicklerin oder der Softwareentwickler erstellt hat.

• 25.3.3 Die Funktionen und die Variablen entsprechen einer Namenskonvention, die die Softwareentwicklerin oder der Softwareentwickler erstellt hat.

• 25.3.4 Input und Output von Funktionen werden nach einer Konvention behan­delt, die die Softwareentwicklerin oder der Softwareentwickler erstellt hat.

• 25.3.5 Fehler werden nach einer Konvention behandelt, die die Software­entwickle­rin oder der Softwareentwickler erstellt hat.

• 25.3.6 Die verwendeten Variablentypen sind kohärent.

• 25.4 Einheitlichkeit der Kommunikation

• 25.4.1 Unter Einheitlichkeit der Kommunikation wird die Verwendung von standar­disierten Protokollen und Schnittstellenroutinen verstanden.

• 25.4.2 Die Regeln für die Kommunikation mit anderen Systemen sind definiert.

• 25.4.3 Die Kommunikation basiert auf standardisierten Kommunikations-methoden.

• 25.5 Einheitlichkeit der Daten

• 25.5.1 Unter Einheitlichkeit der Daten wird die Eigenschaft, die die Verwendung einer standardisierten Darstellung der Daten ermöglicht, verstanden.

• 25.5.2 Die Standarddarstellung der Daten für die Kommunikation mit anderen Systemen wird formell festgelegt.

• 25.5.3 Für Konvertierungen zwischen den verschiedenen Darstellungen werden Standards festgelegt.

• 25.5.4 Die Konvertierungsfunktionen sollten in einem Modul zentralisiert werden.

• 25.6 Erlernbarkeit

• 25.6.1 Unter Erlernbarkeit wird die Eigenschaft der Software, die es den Benutzerinnen und Benutzern ermöglicht, sich die Bedienung der Software leicht anzueignen, verstanden.

• 25.6.2 Personen, die das System betreiben und anwenden, werden geschult und mit der notwendigen Dokumentation bedient.

• 25.6.3 Die Schulung beinhaltet die Möglichkeit, an einem dafür vorgesehenen System zu trainieren.

• 25.6.4 Hilfestellungen zur Bedienung sind leicht zugänglich.

• 25.7 Bedienbarkeit

• 25.7.1 Unter Bedienbarkeit wird die Nutzungsqualität bei der Interaktion mit dem System verstanden.

• 25.7.2 Die Software ist benutzerfreundlich. Die Benutzerführung richtet sich nach allgemein bekannten Schemen.

• 25.7.3 Das clientseitige System, wie es sich der stimmenden Person präsentiert, entspricht mit Ausnahme der Anforderungen an alternative Kommunikationsformen in Kapitel 2.4 dem Accessibility Standard eCH-0059¹². Die Kantone sorgen dafür, dass dies durch eine fachkompetente Stelle belegt wird.

• 25.8 Fehlertoleranz

• 25.8.1 Mit der Fehlertoleranz wird die Weiterführung des Betriebs unter Ausnahmebedingungen ermöglicht.

• 25.8.2 Fehler werden erkannt und behandelt, damit das Programm ohne Unter­brechung weiterlaufen kann.

• 25.8.3 Die Fehlerbehandlung, einschliesslich der Erfassung im Protokoll, erfolgt auf derjenigen Ebene, die für die Weiterführung des Betriebs am relevan­testen ist. Ein Fehler, der in einer Ebene nicht bearbeitet werden kann, wird in die nächsthöhere Ebene übertragen.

• 25.8.4 Für die Inputparameter werden Gültigkeitsbedingungen definiert.

• 25.8.5 Alle Inputparameter werden vor Beginn der Ausführung überprüft.

• 25.9 Modularität

• 25.9.1 Unter Modularität wird die Eigenschaft der Software, die eine Struktur von hochgradig unabhängigen Modulen bietet, verstanden.

• 25.9.2 Die Aufgabe der einzelnen Module wird klar definiert.

• 25.9.3 Die Aufgabe der einzelnen Module sollte eng und fokussiert sein. Die Aufgaben zweier Module sollten sich nicht überschneiden.

• 25.9.4 Die Module teilen keine Daten über einen gemeinsamen volatilen Speicher (z. B. globale Variable).

• 25.10 Einfachheit

• 25.10.1 Unter Einfachheit wird die Implementierung der Funktionen auf die verständ­lichste Art verstanden. Im Allgemeinen bedeutet dies, dass Praktiken vermieden werden, die die Komplexität erhöhen.

• 25.10.2 Im Design wird ein Top-Down-Ansatz (hierarchische Struktur) gewählt.

• 25.10.3 Das Design sieht keine Verdoppelung von Funktionen zwischen den Modulen vor.

• 25.10.4 Das Design sieht keine globalen Daten vor, d. h. keine Daten, die von allen verwendet werden können, ohne als Parameter übergeben zu werden.

• 25.10.5 Komplizierte boolesche Kombinationen im Quellcode werden so weit als möglich vermieden.

• 25.10.6 Im Quellcode werden keine Variablen für andere als die ursprünglich vorgesehenen Zwecke wiederverwendet.

• 25.10.7 Im Quellcode wird die Anzahl von Verschachtelungen so weit wie möglich beschränkt.

• 25.10.8 Die zyklomatische und kognitive Komplexität im Quellcode wird so weit wie möglich beschränkt.

• 25.11 Prägnanz

• 25.11.1 Unter Prägnanz wird die Implementierung der Funktionen mit einem Minimum an Instruktionen im Quellcode verstanden.

• 25.11.2 Die Software enthält keine überflüssigen Abschnitte im Quellcode (soge­nannter «Dead Code»).

• 25.11.3 Der Quellcode enthält keine überflüssigen Variablen.

• 25.11.4 Der Quellcode sollte keine Wiederholungen enthalten.

• 25.12 Verständlichkeit

• 25.12.1 Unter Verständlichkeit wird der Umstand verstanden, dass die Adressatin­nen und Adressaten die Ziel­setzung, die Annahmen, die Einschränkungen, den Input und Output, die Komponenten und den Status der Software erkennen können.

• 25.12.2 Klassen, Funktionen und komplexe Verarbeitungsschritte werden im Quell­code nach einer von der Softwareentwicklerin oder dem Softwareentwickler festgelegten Konvention kommentiert.

• 25.12.3 Variablen und Funktionen werden mit aussagekräftigen Namen bezeichnet.

• 25.12.4 Eine Anweisung sollte nur eine einzige Zeile umfassen, sofern die Lesbarkeit nicht durch die Verteilung auf mehrere Zeilen erhöht wird. Mehrere Anweisungen pro Zeile sind zu vermeiden.

• 25.13 Instrumentierung

• 25.13.1 Unter Instrumentierung wird eine Eigenschaft der Software, die es erlaubt, ihre Nutzung zu messen oder Fehler zu erkennen, verstanden.

• 25.13.2 Die Unit-Tests¹³ decken alle möglichen Pfade und die Grenzen zwischen zulässigen und unzulässigen Werten der Inputparameter ab.

• 25.13.3 Die Integrationstests decken alle Module ab.

• 25.13.4 Die Softwaretestszenarien decken alle Module ab.

• 25.13.5 Fehler und notwendige Informationen werden in Logs protokolliert.

26. Prüfkriterien für die Systeme und ihren Betrieb

• 26.1 Prüfung des kryptografischen Protokolls (Art. 10 Abs. 1 Bst. a)

• 26.1.1 Gegenstand: Es wird geprüft:

  • – ob die Anforderungen in Artikel 5 in Verbindung mit den Artikeln 6–8 und Ziffer 2 des Anhangs erfüllt sind; diese Beurteilung erfolgt insbesondere anhand der kryptografischen und symbolischen Konformitätsbeweise;

  • – ob und inwiefern sich das kryptografische Protokoll auf existierende und bewährte Protokolle und Bausteine abstützt;

  • – welche Vertiefungen und Verbesserungen zu einer Stärkung der Sicherheit beitragen könnten.

• 26.1.2 Zuständigkeiten: Die Prüfung erfolgt durch Expertinnen und Experten aus der Kryptografie. Die Bundeskanzlei gibt die Prüfung in Auftrag und kontrolliert die auftragsgemässe Erfüllung.

• 26.1.3 Zeitpunkt der Prüfung:

  • – Eine komplette Überprüfung erfolgt vor der ersten Inbetriebnahme.

  • – Die Prüfung wird nach zwei bis drei Jahren erneut durchgeführt.

  • – Die Prüfung findet erneut statt:

    • – bei jeder Änderung des kryptografischen Protokolls; und

    • – bei relevanten neuen Erkenntnissen der Forschung bezüglich der Sicherheit von verwendeten kryptografischen Elementen und der Bedrohungslage.

• 26.2 Prüfung der Software des Systems (Art. 10 Abs. 1 Bst. b)

• 26.2.1 Gegenstand: Es wird geprüft:

  • – ob das nach Ziffer 26.1 geprüfte kryptografische Protokoll umgesetzt ist; die korrekte Umsetzung von Funktionen vertrauenswürdiger Komponenten wird besonders eingehend geprüft;

  • – ob die Software des Systems die Anforderungen dieser Verordnung erfüllt und die vorgegebenen Zielsetzungen adäquat unterstützt;

  • – ob das clientseitige System, wie es sich der stimmenden Person präsentiert, gemäss Ziffer 25.7.3 mit dem Standard eCH-0059 konform ist; die Prüfung kann sich auf ein gültiges Zertifikat oder einen gültigen Prüfbericht stützen, das von einer von der Bundeskanzlei anerkannten Institution ausgestellt wurde und die Konformität mit dem Standard belegt.

• 26.2.2 Zuständigkeiten: Die Prüfung erfolgt durch Expertinnen und Experten aus der Kryptografie und der Softwareentwicklung. Die Prüfung wird von der Bundeskanzlei in Auftrag gegeben.

• 26.2.3 Zeitpunkt der Prüfung:

  • – Eine komplette Überprüfung erfolgt vor der ersten Inbetriebnahme.

  • – Die Prüfung wird nach zwei bis drei Jahren erneut durchgeführt.

  • – Die Prüfung findet bei jeder wesentlichen Änderung erneut statt, insbesondere:

    • – nach jeder Änderung am kryptografischen Protokoll;

    • – bei jeder Änderung am Quellcode der Funktionen, deren Vertrauenswürdigkeit für die Stichhaltigkeit der im Rahmen der Verifizierbarkeit vorgesehenen Beweise massgeblich sind;

    • – bei relevanten neuen Erkenntnissen der Forschung bezüglich der Sicherheit von verwendeten kryptografischen Elementen und der Bedrohungslage;

    • – beim Verzicht oder bei wesentlichen Anpassungen an Mechanismen, die dem sicheren Einsatz von vertrauenswürdigen Komponenten nach Ziffer 2 dienen.

• 26.3 Prüfung der Sicherheit von Infrastruktur und Betrieb (Art. 10 Abs. 1 Bst. c)

• 26.3.1 Gegenstand: Es wird geprüft, ob:

  • – das System und sein Betrieb beim Kanton, beim Systembetreiber und bei der Druckerei die Anforderungen dieser Verordnung erfüllen und die vorgegebenen Zielsetzungen adäquat unterstützen;

  • – die Basiskomponenten, wie die Software, die dem sicheren und unabhängigen Einsatz von Kontrollkomponenten dient, die eingesetzten Betriebssysteme oder die eingesetzten Server erwiesenermassen besten Standards entsprechen.

• 26.3.2 Zuständigkeiten: Die Prüfung erfolgt durch Expertinnen und Experten aus der Kryptografie und dem Betrieb von hochsicheren Systemen. Die Prüfung wird von der Bundeskanzlei in Auftrag gegeben.

• 26.3.3 Zeitpunkt der Prüfung:

  • – Eine komplette Überprüfung erfolgt vor der ersten Inbetriebnahme.

  • – Die Prüfung wird nach zwei bis drei Jahren erneut durchgeführt.

  • – Die Prüfung findet bei jeder wesentlichen Änderung erneut statt, insbesondere:

    • – nach einer Änderung am kryptografischen Protokoll;

    • – beim Verzicht auf oder bei wesentlichen Anpassungen an Mechanismen, die dem sicheren Einsatz von vertrauenswürdigen Komponenten nach Ziffer 2 dienen;

    • – bei einer wesentlichen Änderung der Prozesse oder der Infrastruktur.

  • – Werden neue Versionen von Basiskomponenten eingesetzt (neue Server, Patches zum Betriebssystem oder zur Software, die dem sicheren und unabhängigen Einsatz von vertrauenswürdigen Komponenten nach Ziffer 2 dienen), muss keine neue Kontrolle erfolgen, sofern die Basiskomponenten weiterhin erwiesenermassen besten Standards entsprechen.

• 26.4 Prüfung des Schutzes gegen Versuche, in die Infrastruktur einzudringen (Art. 10 Abs. 1 Bst. d)

• 26.4.1 Gegenstand: Es wird geprüft, ob es den Expertinnen und Experten im Auftrag der Bundeskanzlei gelingt, im Rahmen eines Tests in die Infrastruktur des Online-Systems einzudringen und sich Zugang zu wichtigen Daten zu verschaffen oder die Kontrolle über wichtige Funktionen zu übernehmen.

• Die Tests werden auf der Grundlage von potenziellen Schwachstellen durchgeführt, die nach einer methodischen Analyse der öffentlich zugänglichen Unterlagen, insbesondere nach Artikel 11, entdeckt wurden.

• 26.4.2 Zuständigkeiten: Die Prüfung erfolgt durch Sicherheitsexpertinnen und
  

  -experten. Die Prüfung wird von der Bundeskanzlei in Auftrag gegeben.

• 26.4.3 Zeitpunkt der Prüfung:

  • – Eine komplette Überprüfung erfolgt vor der ersten Inbetriebnahme.

  • – Die Prüfung wird nach zwei bis drei Jahren erneut durchgeführt.

  • – Die Prüfung findet bei jeder wesentlichen Änderung der Infrastruktur erneut statt.

  • – Die Prüfung findet bei relevanten neuen Erkenntnissen bezüglich der Sicherheit der eingesetzten Betriebsmittel und der Bedrohungslage statt.

• 26.5 Prüfung des Informationssicherheitsmanagement-Systems (Art. 10 Abs. 2)

• 26.5.1 Gegenstand: Es wird geprüft, ob das ISMS des Systembetreibers mit der Norm ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements konform ist. Der Geltungsbereich des ISMS umfasst alle Organisationseinheiten des Systembetreibers, die rechtlich, administrativ und betrieblich für das System verantwortlich sind.

• 26.5.2 Zuständigkeiten: Die Zertifizierungsstelle ist durch die Schweizerische Akkreditierungs­stelle für die Durchführung von Audits nach der Norm ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements akkreditiert. Die Prüfung wird vom Kanton oder vom Systembetreiber in Auftrag gegeben; der Kanton sorgt für die Durchführung der Prüfung.

• 26.5.3 Dauer der Gültigkeit eines Belegs: Wiederholungsaudits werden in den durch die Norm ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements festgelegten Abständen durchgeführt. Ein gültiges Zertifikat und die entsprechende «Statement of Applicability» liegt bei jedem Einsatz des Systems vor. Wird eine neue Version des Standards ISO/IEC 27001, 2013, Information technology – Security techniques – Information security management systems – Requirements publiziert, so ist spätestens nach Ablauf der Übergangsfrist der Nachweis einer gültigen Zertifizierung des ISMS nach der neuen Version zu erbringen. Der Geltungsbereich des ISMS darf dabei nicht reduziert werden.