Der Lieferant und/oder Service Provider gewährleistet den Stand der Technik der Informationssicherheit in allen seinen Produkten und Dienstleistungen. Er hat den Stand der Technik bei bestehenden Wartungsverträgen in angemessenen Wartungszyklen stets anzupassen.

Funktionsumfang und damit die Anzahl vorhandener Programme, Software-Module, Dienste und Netzwerkprotokolle auf Komponenten sind auf das für den Systembetrieb nötige Minimum reduziert. Alle nicht explizit benötigten Dienste sind standardmäßig deaktiviert.

Jede Komponente und jeder Benutzer hat standardmäßig nur die Rechte, die für die Ausführung einer Aktion nötig sind. So werden z. B. Anwendungen und Netzwerk-Dienste nicht mit Administratorprivilegien, sondern nur mit den minimal nötigen Systemrechten betrieben. (Least privilege principle)

Verwendete Kommunikations- und Anwendungsprotokolle müssen dokumentiert sein und begründen, wie die Integrität, Authentizität und Vertraulichkeit der Kommunikation ausreichend gewährleistet wird.

Die sichere Grundkonfiguration der Systeme bzw. Komponenten ist dokumentiert.

Der Lieferant muss eine Aussage zur Verfügbarkeit seines Systems machen (Mean time to failure, mean time to repair).

Das gesamte System mit all seinen Komponenten, d.h. inkl. Erweiterungen und Verbesserungen, muss patchfähig sein, damit bekannt gewordene Sicherheitslücken beseitigt werden können. Dies umfasst neben Betriebssystem und Firmware auch Applikationen und Hilfskomponenten. Software, die von Dritten bezogen wird (sogenannte 3rd-Party-Software), soll sich ebenfalls in den Patch- bzw. Updateprozess einbinden lassen. Der Software/Firmwarestand der austauschbaren Komponenten muss im laufenden Betrieb überprüfbar sein.

Sensible Daten (zB. Credentials) dürfen im System nur verschlüsselt gespeichert bzw. übertragen werden.

Es dürfen nur anerkannte Verschlüsselungs-Verfahren und Schlüsselmindestlängen benutzt werden, die nach aktuellem Stand der Technik auch in Zukunft als sicher gelten. Selbstentwickelte Verschlüsselungs-Algorithmen sind nicht erlaubt.

Bei der Implementierung der Verschlüsselungs-Verfahren wird auf anerkannte Verschlüsselungs-Bibliotheken zurückgegriffen werden, um Implementierungsfehler zu vermeiden.

Bei der Schlüsselgenerierung müssen sichere Schlüssel generiert werden. Die sichere Speicherung der Schlüssel muss unterstützt werden.

Die Applikation ist in verschiedene Module (z. B. Präsentations-, Anwendungs- und Datenschicht) zu trennen. Gegebenenfalls sind diese Module auf verschiedene Server zu verteilen.

Die verschiedenen Komponenten und Prozesse sind mit den minimal möglichen Rechten zu betreiben, sowohl auf Anwendungs- als auch auf Systemebene.

Sämtliche Parameter, die vom Anwender (bzw. seinem Web-Browser) an die Web-Anwendung gesendet werden sind genau auf Gültigkeit, maximale Länge sowie auf korrekten Typ und Wertebereich hin zu überprüfen. Dies gilt auch für Parameter, die von der Web-Anwendung selbst in einem vorhergehenden Schritt zum Anwender geschickt wurden. Dabei ist insbesondere auf sog. XSS- und Injection-Sicherheitslücken zu achten, über die ein Angreifer eigene Kommandos ausführen kann.

Es ist besonders auf sicheres Session-Management zu achten, z. B. durch verschlüsselte oder signierte Session-IDs und zeitbeschränkte Sessions. Die Übertragung von Session-IDs ist durch SSL-Verschlüsselung zu schützen. Session Timeouts müssen einstellbar sein.

Die Integrität und Plausibilität von Daten muss bei der Eingabe, Verarbeitung und Ausgabe überprüft werden (beispielsweise auf Plausibilität, korrekte Syntax, CRC und Wertebereich) und Abweichungen oder Inkonsistenzen aufgezeigt werden. Die verwendeten Methoden sind zu dokumentieren.

Das System muss Benutzeraktionen sowie sicherheitsrelevante Aktionen, Vorkommnisse und Fehler in einem zur nachträglichen und zentralen Auswertung geeignetem Format protokollieren. Es werden Datum und Uhrzeit (sekundengenau und mit Zeitzone), involvierte Benutzer und Systeme (Name, IP-Adresse) sowie das Ereignis und Ergebnis für einen konfigurierbaren Mindestzeitraum aufgezeichnet.

Das Logging von Events ist konfigurierbar und modifizierbar.

Sicherheitsrelevante Events werden in den Systemlogs als solche markiert werden, um eine automatische Auswertung zu erleichtern.

Die zentrale Speicherung der Logdateien an einem frei konfigurierbarem Ort wird unterstützt.

Das Logfile muss gegen spätere Modifikation geschützt sein.

Bei Überlauf des Logfiles werden die älteren Einträge überschrieben, das System muss bei knapp werdendem Logging-Speicherplatz warnen.

Es muss möglich sein, sicherheitsrelevante Meldungen in ein vorhandenes Alarmmanagement (SIEM) zu integrieren (Standard Formate).

Jedes System muss über eine einheitliche Systemzeit verfügen und die Möglichkeit zur Synchronisation dieser Systemzeit mit einer externen Zeitquelle bieten, so dass eine Sekundengenauigkeit erreicht wird. Die Zeitzonen sind zu unterstützen mit automatischem Wechsel zwischen Winter und Sommerzeit.

Anwendungen müssen eine personenspezifische Identifizierung und Authentifizierung vornehmen können.

Serviceaccounts dürfen nicht für interaktiven Logon verwendet werden können. Die Credentials von Serviceaccounts müssen vom Betreiber änderbar sein.

Der Betreiber muss in der Lage sein, Accounts eigenständig zu managen (anlegen, ändern, löschen).

Ohne erfolgreiche Benutzer-Authentifizierung darf das System keinerlei Aktionen erlauben. Zugriffe auf Daten und Variablen sind nur nach einer erfolgreichen Authentisierungs- und Autorisierungsprüfung möglich sein.

Bei Verwendung von PWD muss das System Passwörter (Password-Policies) mit vom Auftraggeber definierbarer Stärke und Gültigkeitsdauer erzwingen (siehe 1.10).

Bei fehlgeschlagenen Anmeldeversuchen müssen Mechanismen eine Brute-Force Attacke verhindern.

Das System soll bei fehlgeschlagenen Anmeldeversuchen keinen Hinweis geben, welcher Teil der Authenfizierung fehlgeschlagen ist (UID oder PWD).

Das System soll vor der Anmeldung keine Usernamen vorschlagen (auch zB gecached).

Es muss möglich sein, erfolgreiche und fehlgeschlagene Anmeldeversuche zu protokollieren.

Der administrative Zugriff auf Komponenten soll zusätzlich durch geeignete Maßnahmen (sichere Authentifizierungsverfahren, Session Timeouts, gesicherte Protokolle, etc.) geschützt werden können.

Passworte und andere Authentisierungsinformationen dürfen nur kryptographisch gesichert übertragen und im System gespeichert werden.

Die erforderliche Passwortkomplexität muss durch den Anwendungsadministrator konfigurierbar sein. Zu definierende Parameter umfassen zumindest:

• minimale Passwortlänge
• die maximale Passwortlänge soll mind. 128 Zeichen betragen
• minimale Anzahl von bestimmten Zeichen/Zeichengruppen, z.B. Groß- und Kleinbuchstaben, Ziffern, Sonderzeichen inkl. Leerzeichen, etc.
• minimale und maximale Gültigkeitsdauer
• Verhinderung der Nutzung eines vorherigen Passwortes beim Passwortwechsel
• maximale Anzahl von Passwortänderungen pro Zeiteinheit (z.B. pro Tag)

Administration, Wartung und Konfiguration aller Komponenten muss auch über ein Out-of-Band-Netz, zum Beispiel Zugriff lokal, via serielle Schnittstelle, Netzwerk oder direkter Steuerung der Eingabegeräte, möglich sein.

Das System muss eine Authentifizierung für Fernwartung über Zweifaktor-Authentifizierung unterstützen.

Das System soll ein Aufzeichnen der Fernwartungssession ermöglichen (KRITIS).

Der Lieferant und/oder Service Provider stellt seine für das Produkt bzw. die Dienstleistung relevanten Richtlinien der Informationssicherheit zur Verfügung. Der Leiferant/Provider hat eine gültige Sicherheitszertifizierung im relevanten Anwendungsbereich (Entwicklung, Produktion) vorzuweisen (z.B. ISO 27001 oder equivalent).

Der Lieferant und/oder Service Provider stellt Methoden zur Verfügung, mit denen die Authentizität und Integrität des Systems, insbesondere der Softwarekomponenten, der Hardwarekomponenten und der Konfigurationsdaten verifizierbar ist. Dieser Verifikationsprozess soll im laufenden Betrieb ohne Unterbrechung, automatisch und mit minimaler Systemlast stets wiederholbar durchgeführt werden können.

Der im Punkt 3 verlangte Integritätsverifikationsprozess muss auf Herstellerseite bis zur Authentizität des verwendeten Source Codes und der verwendeten Softwarebibliotheken eindeutig rückführbar sein, so dass das gelieferte Produkt oder zur Verfügung gestellte Service aus dem Quellcode identisch und überprüfbar reproduzierbar ist.

Der Lieferant und/oder Service Provider verpflichtet sich, seine Produkte und Dienstleistungen frei von Malware, Spyware, verstecktem Code, nicht-dokumentierten Hintertüren oder sonstigen verborgenen Funktionen (wie zB. nicht-authorisierten Datenweiterleitungen) zu halten, die geeignet sind, die Informationssicherheit des Systems oder des Services zu kompromittieren.

Der Auftragnehmer muss über einen dokumentierten Prozess verfügen, um Sicherheitslücken zu behandeln. Innerhalb dieses Prozesses muss es allen Beteiligten, aber auch Außenstehenden möglich sein, tatsächliche oder potentielle Sicherheitslücken zu melden (Responsible disclosure).

Bei Bekanntwerden sehr kritischer Schwachstellen (entsprechend CVE Ratings) ist der Hersteller verpflichtet, zeitnah und auf seine Kosten zu überprüfen, ob sein Produkt davon betroffen ist und seine Kunden entsprechend zu verständigen.

Der Lieferant und/oder Service Provider garantiert während des gesamten Betriebszeitraums, dass entdeckte Schwachstellen im System oder Service rasch und zeitnah und auf eigene Kosten (im Rahmen bestehender Wartungsverträge) behoben werden oder zumindest bis zur endgültigen Behebung ein brauchbares Compensating Measure anbieten.

Falls der Lieferant im System eine Standardsoftware mit einer Version einsetzt, für die eine Sicherheitswarnung veröffentlicht wurde und für die bereits ein offizieller Patch vom Hersteller veröffentlicht wurde, so hat der Lieferant in seinem System so rasch als möglich, jedenfalls binnen 1 Woche nach Veröffentlichung diesen Patch einzubringen oder in anderer wirksamer Weise das durch die Schwachstelle verursachte Sicherheitsrisiko zu reduzieren.

Der Lieferant und/oder Service Provider garantiert vertraglich einen Mindestproduktlebenszyklus ab Produkteinführung, innerhalb dessen jederzeit Sicherheitsupdates (siehe Punkte 6 "Reaktion auf Schwachstellen") und Support erbracht werden.

• Hardware 3 Jahre
• Anwendungssoftware und Datenbanken 5 Jahre
• Betriebssysteme 8 Jahre

Das Ende des Produktlebenszyklus muss mindestens 18 Monate vor Einstellung des Supports erstmalig angekündigt werden. Geeignete Maßnahmen zur Weiterführung des Betriebs bzw. der Migration auf andere Produkte/Services müssen dem Kunden vorgeschlagen werden.

Falls der Lieferant im System eine Standardsoftware verwendet (z.B. Betriebssystem, Datenbank), so hat er die Installation von Sicherheitssoftware, die für diese Standardsoftware vom Betreiber gewählt und dafür lizensiert ist, zu erlauben und deren Integration zu ermöglichen ohne dadurch Gewährleistungsansprüche auf das Lieferanten-System zu verlieren. Übliche Sicherheitssoftware ist z.B. Software für Inventory, Malware Defense, Identity Management, SIEM, Intrusion Detection, DLP, Vulnerability Detection, etc.

Der Betreiber hat das Recht, das System oder den Service professionellen Sicherheitsüberprüfungen, kontrollierten Attacken und Schwachstellenanalysen jederzeit und beliebig oft zu unterziehen. Diese Sicherheitstests können im Auftrag des Betreibers auch von Dritten durchgeführt werden. Für solchermaßen identifizierte Schwachstellen gilt Punkt 6 "Reaktion auf Schwachstellen".

Dem Auftraggeber muss eine Gesamtdokumentation über das Design des Gesamtsystems zur Verfügung gestellt werden. Darin beschrieben sind der Aufbau des Systems und die Interaktionen aller beteiligten Komponenten. In dieser Dokumentation wird besonders auf die sicherheitsrelevanten oder schützenswerten Systemkomponenten sowie ihre gegenseitigen Abhängigkeiten und Interaktionen eingegangen. Außerdem werden sicherheitsspezifische Implementierungsdetails aufgelistet und in hinreichender Tiefe fachlich beschrieben (siehe auch Punkt 1, z.B. verwendete Verschlüsselungsstandards).

Der Hersteller hat nachweislichen einen Prozess zur sicheren Softwareentwicklung, mit entsprechenden Richtlinien für Threat Modeling, Secure Coding, Qualitätssicherungsmaßnahmen und -controls (wie etwa Peer Group Reviews, manueller oder automatisierter Source Code Review, externe Audits u.ä.) eingerichtet.

Vor Produktionsfreigabe jeder Release ist ein Anwendungspenetrationstest durchgeführt und kritische Fehler behoben worden.

Der Anbieter weist plausibel nach, dass er (inkl. allfällige dem Anbieter gegenüber weisungsberechtigte Konzern-Gesellschaften) und alle von ihm im Rahmen der Leistungserbringung beigezogenen Subunternehmer keiner rechtlichen oder sonstigen Pflicht unterliegen, Daten und Informationen an Dritte, insbesondere an ausländische Staaten herauszugeben.

Der Anbieter akzeptiert, dass alle Verträge mit der Vergabestelle die Rechtswahl EU-Recht und einen europäischen Gerichtsstand vorsehen. Er bestätigt zudem, dass er in allen für die Leistungserbringung relevanten Verträgen mit Subunternehmern die Rechtswahl EU-Recht und einen europäischen Gerichtsstand vorsehen wird. Der Anbieter legt die vorgesehenen Subunternehmer und auf Verlangen die entsprechenden Vertragsabschnitte in den zugehörigen Verträgen offen. Ein Wechsel bei den Subunternehmern ist nur mit vorgängiger Genehmigung der Vergabestelle zulässig.

Wenn die Datenspeicherung bzw. -Verarbeitung und Übertragung nicht ausschließlich im Land des Betreibers stattfindet so hat der Hersteller der Lösung eine vollständige (und laufend zu aktualisierende) Liste der Länder bekanntzugeben, in denen Übertragung, Speicherung oder Verarbeitung stattfinden.