EVB Informationssicherheit allgemein-mit Wartung V1.3.pdf

[Seite 1]

EVB Ergänzende Vertragsbedingungen/Cyber Security Bedingungen – Allgemein mit IT Betrieb, Wartungsvertrag etc. – Stand: 17.09.2021 Vertragsanlage

Zum Verbleib beim Auftragnehmer/Bieter bestimmt.

Ergänzende Vertragsbedingungen/Cyber Security Bedingungen – Allgemein mit IT Betrieb, Wartungsvertrag etc. – Stand: 17.09.2021

1. Allgemeine Bestimmungen: Schwachstelle: Die hier festgelegten Informationssicherheitsbestim- Schwachstelle ist der in Organisationen (Unternehmen, mungen werden integraler Bestandteil des Hauptvertra- Behörden) vorhandene organisatorische, prozessuale, ges. personelle oder systemische Mangel, die die angestreb- Der Auftragnehmer muss die Informationssicherheitsan- ten Ziele beeinträchtigen und Schäden verursachen kön- forderungen erfüllen und muss sicherstellen, dass sein nen. Personal oder seine Subunternehmer diese ebenfalls er- Secure Code Review: füllen. Ein Secure Code Review ist eine spezielle Form des allge- Die Einhaltung der Informationssicherheitsanforderun- meinen Code Reviews bei der mit Hilfe verschiedener gen muss zu jeder Zeit sichergestellt sein und regelmäßig Methoden noch bestehende Schwachstellen identifiziert seitens Lieferant auch für die Subunternehmer über- werden. wacht werden. (Auditrecht wird in Kapitel 11.4 geregelt) Security by Design: Security by Design beschreibt die Integration von Sicher-
2. Definitionen: heitsaspekten in den vollständigen Lebenszyklus eines Produktes (Software, Hardware, Dienstleistung) bereits Assets: in der Design-phase des Produktes. Wie in ISO/IEC 27005 definiert, Assets umfassen primäre und unterstützende Vermögenswerte. Service Level Agreement: Ein Service Level Agreement (SLA) ist Teil eines Service- Auftraggeber: vertrages. Zwischen Auftragnehmer und -geber werden Im Rahmen dieses Dokumentes ist hier primär der Be- verschiedenen Eigenschaften des Services, wie Umfang treiber Kritischer Infrastrukturen gemeint. Selbstver- Qualität und Verantwortlichkeiten, vereinbart. ständlich kann in diese Rolle auch jeder andere Betreiber unterhalb des Sicherheitsniveaus „Kritische Infrastruk- Security Level Agreement: tur“ einsteigen. Ein Security Level Agreement (SecLA) ist eine Sonder- form der SLA mit dem Fokus auf Securityaspekten. Auftragnehmer: Im Rahmen dieses Dokumentes ist der Hersteller und o- Schutzbedarfsanalyse: der Lieferant gemeint, der als Vertragspartner des Auf- Im Rahmen der Schutzbedarfsanalyse werden soge- traggebers auftritt. nannte Schutzobjekte (schützenswerte Daten, Hard- ware, Infrastruktur etc. von Unternehmen) erkannt und Fernzugang: mit einem realen Angriffsrisiko verknüpft. Zugang in das Netz des Auftraggebers – i.d.R. durch den Auftragnehmer. Vulnerability Management: Prozess zur Erkennung und Behebung von Schwachstel- Kritikalität: len. Ein wichtiges Kriterium dafür ist die Kritikalität als relati- ves Maß für die Bedeutsamkeit einer Infrastruktur in Be-
3. Vulnerability-Management: zug auf die Konsequenzen, die eine Störung oder ein Funktionsausfall für die Versorgungssicherheit der Ge- Der Auftragnehmer unterzieht den Produkten einer kon- sellschaft mit wichtigen Gütern und Dienstleistungen tinuierlichen Prüfung auf Schwachstellen, bspw. in Form hat. eines sogenannten Vulnerability-Managements, um in der Lage zu sein, auf neue Schwachstellen so schnell wie Penetrationstest: möglich zu reagieren. Es basiert auf der Transparenz der Ein Penetrationstest beschreibt die Prüfung der Sicher- Funktionalität, der technischen Architektur und von Un- heit möglichst aller Systembestandteile und Anwendun- terkomponenten einschließlich der Betriebssysteme, gen eines Netzwerks- oder Softwaresystems mit Mitteln Datenbanken, Server (z.B. Web, Telnet, SSH), Middle- und Methoden, die ein Angreifer anwenden würde, um ware und Bibliotheken. Diese wird verwendet, um neue unautorisiert in das System einzudringen (Penetration). Schwachstellen in Bezug auf die Kritikalität und die ge- Der Penetrationstest ermittelt somit die Empfindlichkeit schäftlichen Auswirkungen zu beurteilen. des zu testenden Systems gegen derartige Angriffe.

Seite 1 / 7

Vorsitzender des Verwaltungsrats: Oberbürgermeister Marcus König | Vorstand: Prof. Dr. Achim Jockwig (Vorsitzender), Dr. Andreas Becke, Sabine Beßler Kommunalunternehmen – Anstalt des öffentlichen Rechts | Sitz: Nürnberg | Registergericht: Nürnberg, HRA 14190 | Bankverbindung: Sparkasse Nürnberg IBAN: DE18 7605 0101 0001 0009 44, BIC: SSKNDE77XXX

[Seite 2]

EVB Ergänzende Vertragsbedingungen/Cyber Security Bedingungen – Allgemein mit IT Betrieb, Wartungsvertrag etc. – Stand: 17.09.2021 Vertragsanlage

Sind vom Auftragnehmer entwickelte Software-, Firm- ware- oder Hardware-Komponenten betroffen, ist der Auftragnehmer verpflichtet, umgehend die Schwachstel- len an den Auftraggeber zu melden. 3.1 Methodik und Umfang: Jede Schwachstelle muss vom Auftragnehmer an den

JAeudfetr aSgcghewbaecrh gsetemlleel dmetu ussn dv obmzg l.A mufötrgaligcnheehr mfuenrk taionn daleenr Stellt eine Schwachstelle gleichzeitig eine Störung nach und sicherheitsrelevanter Auswirkungen bewertet wer- dem Hauptvertrag dar, so gelten für die Mängelbeseiti- den. gung die Reaktions- und Wiederherstellungszeiten des Der Umfang des Vulnerability-Managements umfasst Hauptvertrages. jede potenzielle Schwachstelle, die möglicherweise Ein- 3.4 Kommunikation: fluss auf die Verfügbarkeit, Integrität und Vertraulichkeit Jegliche Kommunikationswege werden mit dem Auftrag- der Vermögenswerte (materielle oder immaterielle) o- nehmer bzgl. Art und Form vereinbart. Kryptographische der auf eine beim Auftraggeber operierende Dienstleis- Techniken nach dem neuesten Stand der Technik müs- tung des Auftragnehmers nehmen kann. sen zur Geheimhaltung und Integrität für die Übermitt- 3.2 Vulnerability-Assessment: lung dieser Mitteilungen verwendet werden. Der Auftragnehmer ist verpflichtet, kontinuierlich Quel- len für Sicherheitsempfehlungen zu sichten und diese in 4. Patch-Management: Bezug auf die an den Auftraggeber gelieferten Assets zu 4.1 Patch-Umfang: bewerten. Sollte eine Komponente von der Sicherheits- lücke betroffen sein, wird von dem Auftragnehmer er- Der Patch-Umfang muss das gesamte System, wie vom wartet, die Einstufung der Kritikalität und die zeitliche“ Auftraggeber akzeptiert, umfassen. Dazu gehören das Bewertung durchzuführen (siehe Hinweise in Abschnitt Betriebssystem, alle Softwarepakete und Services des 10). Betriebssystems, alle Tools und Applikationen des Her- stellers zu Betriebs- und Wartungszwecken, die Zielapp- Der Auftraggeber zeigt Verständnis dafür, dass die Infor- likation (Servicelogik) und alle für den Service genutzten mationen über die umliegende Infrastruktur oder an- Middleware-Application-Layer, Datenbanken, Access-, dere einflussnehmende Umstände nicht vollständig sein Monitoring- oder Applikationsserver. können und dass das bestmögliche Ergebnis auf Basis 4.2 Patch-Level während der Systemabnahme: des Wissens in dem Branchenumfeld des Auftragneh- mers beruht. Der Auftragnehmer hat sicherzustellen, dass alle Sys- Es sind mit dem Aufragnehmer Kriterien für Schwach- teme vor der Abnahme gepatcht und aktualisiert wer- stellen zu vereinbaren, bei denen der Auftraggeber vom den. Der Patch-Level sollte dabei nicht älter als sechs Auftragnehmer oder Hersteller informiert werden muss Monate ab dem Tag der Systemabnahmeerklärung sein. Der Auftragnehmer muss alle öffentlich verfügbaren und und wie dieses erfolgen sollte. durch den Auftraggeber freigegebenen Patches als Teil 3.3 Behebung von Schwachstellen: der Lieferung installieren. Die folgende Tabelle definiert die Kritikalität der Sicher- 4.3 Patch-Management nach der Systemabnahme: heitslücken und die erwartete Zeit zur Implementierung 4.3.1 Patch-Management-Lifecycle: einer Lösung: • Finale Lösungszeit = Zeit benötigt für den Patch / die Der Auftragnehmer verpflichtet sich, mindestens zwei- mal pro Jahr Updates und Patches bereitzustellen. Für Wartungsfreigabe / die korrekte Installation der Lö- sung; Zeitraum, in dem auf den Service aus öffentli- die Bereitstellung durch den Auftragnehmer gelten die in chen / externen Netzwerken zugegriffen werden Abschnitt 4.3 festgelegten Zeitrahmen. kann. Der Auftragnehmer verpflichtet sich für jede im • Zeit zur Neutralisierung = Zeit für eine vorläufige Lö- Patchzyklus adressierte Schwachstelle einen detaillier- ten Bericht zu erstellen und dem Auftraggeber zur Ver- sung oder einen Workaround für den Fall, dass der Patch nicht innerhalb eines bestimmten Zeitrah- fügung stellen. mens verfügbar ist. Vom Auftragnehmer wird er- 4.3.2 End of Life: wartet, dass eine Lösung mit einem Best-Effort-An- Kündigt ein Drittanbieter eines Betriebssystems oder ei- satz und nach bestem Wissen erarbeitet wird. Die ner anderen Komponente (Software, Datenbanken, An- Zeitzählung beginnt mit der Benachrichtigung über wendungen, etc.) das Ende des Lifecycles an, so kommu- die Schwachstelle.

Seite 2 / 7

Vorsitzender des Verwaltungsrats: Oberbürgermeister Marcus König | Vorstand: Prof. Dr. Achim Jockwig (Vorsitzender), Dr. Andreas Becke, Sabine Beßler Kommunalunternehmen – Anstalt des öffentlichen Rechts | Sitz: Nürnberg | Registergericht: Nürnberg, HRA 14190 | Bankverbindung: Sparkasse Nürnberg IBAN: DE18 7605 0101 0001 0009 44, BIC: SSKNDE77XXX

[Seite 3]

EVB Ergänzende Vertragsbedingungen/Cyber Security Bedingungen – Allgemein mit IT Betrieb, Wartungsvertrag etc. – Stand: 17.09.2021 Vertragsanlage

niziert der Auftragnehmer dies dem Auftraggeber so früh 5.5 Backdoors: wie möglich, spätestens 6 Monate vor dem „End of Life“. Der Auftragnehmer muss im Rahmen seiner Möglichkei- Der Auftragnehmer aktualisiert entweder die Kompo- ten sicherstellen, dass seine Lösungen frei von „Back- nente auf die aktuellste neuere Version, setzt eine adä- doors“ sind, die die verwendeten Sicherheitsmechanis- quate Alternative ein oder stellt einen erweiterten Sup- men umgehen können. port von Sicherheitspatches für die ältere Version ver- 5.6 Kontrolle und Audit der in diesem Kapitel genannten traglich mit dem Drittanbieter sicher. Konditionen: 4.3.3 Lieferanten von reinen Anwendungen oder Funktiona- Der Auftragnehmer verpflichtet sich, dass er hinsichtlich litäten: seiner Produkte mit geeigneten Maßnahmen und Proto- In Fällen, in denen der Auftragnehmer nur Anwendun- kollen, die mit dem Auftraggeber abzustimmen sind, gen und/oder andere Funktionalitäten liefert und der nachweist, dass alle in diesem Kapitel genannten Anfor- Auftraggeber oder sonstige Drittanbieter in seinem Na- derungen eingehalten werden. men für das Update-Management auf den darunterlie- genden Schichten wie Betriebssystem verantwortlich ist, 6. Fernzugang für Drittanbieter: muss der Auftragnehmer eine kontinuierliche Funktions- fähigkeit seiner gelieferten Leistung auch bei Patches der Fernzugänge von Drittanbietern zum Netzwerk des Auf- darunterliegenden Systemplattform gewährleisten. traggebers und/oder dessen zugehörigen Unternehmen wird unter den folgenden Bedingungen gestattet. Pro- zess und Funktion dieses Zugriffs werden allein vom Auf- 5. Systemhärtung: traggeber definiert. Der Auftragnehmer verpflichtet sich, die von ihm gelie- 6.1 Allgemeine Erwartungen: ferten Systeme zu härten, um die Auswirkungen poten- zieller Sicherheitsrisiken zu minimieren. Dies muss vor Der Auftragnehmer muss sicherstellen, dass bei Fernzu- der Deklaration einer Systemabnahme durch den Auf- gängen die Vertraulichkeit, Verfügbarkeit und Integrität traggeber geschehen sein. der Assets und Services des Auftraggebers gewährleistet sind. Dies beinhaltet auch die nachträgliche Verwendung 5.1 Minimale Installationsprinzipien: von Informationen, von denen der Auftragnehmer wäh- Es wird von dem Auftragnehmer erwartet, folgende rend eines Fernzugriffes Kenntnis erlangt hat. Er ist für Komponenten des Betriebssystems oder anderer Soft- alle Aktionen der Benutzerkonten mit Fernzugangsfunk- ware zu installieren: tion auf Systemen des Auftraggebers verantwortlich. A. Jede Softwarekomponente, die für die Anwendung 6.2 User-Account-Management: oder nach der Logik des Dienstes benötigt wird. Es wird allgemein erwartet, dass jeder Nutzer ein eigenes B. Jede aus der Integration mit anderen Services resul- Nutzerkonto bereitgestellt bekommt. Der Auftraggeber tierende andere Anwendung oder Softwarekompo- zeigt Verständnis für Ausnahmen, sollten Umstände auf- nente. treten (Unternehmen mit mehreren Supportcentern und C. Jede aus Betriebs- und Wartungsanforderungen re- einer großen Anzahl an Personal), die dies erschweren. sultierende Softwarekomponente. Solche Ausnahmen müssen vorab dokumentiert und in Jede andere Software darf nur in Abstimmung mit dem einem SLA (Service Level Agreement) festgehalten wer- Auftraggeber installiert werden. den. In diesem Fall wird der Auftragnehmer die kom- 5.2 Netzwerkdienste (Netzwerkzugänge): plette Rückverfolgbarkeit der Nutzung eines Accounts (wer, wann) festhalten (im besten Fall revisionssicher) Jeder nicht benötigte Netzwerkzugang (TCP/IP- oder und diese dem Auftraggeber auf Verlangen aushändigen. UDP-Port) muss deaktiviert sein. Die Nutzung jedes Zu- gangs muss in der Dokumentation des Auftragnehmers Sollte die Situation auftreten, dass der Auftragnehmer erläutert werden. ein Nutzerkonto nicht mehr benötigt, muss der Auftrag- geber darüber unverzüglich informiert werden, so dass 5.3 Konfigurationsstandards: das entsprechende Konto gesperrt werden kann. Der Der Auftragnehmer stellt sicher, dass die vom Auftragge- Auftraggeber kann durch eine Betriebsfunktion oder ber vorgegebenen allgemeinen Konfigurationsstandards eine alternative Service-Management-Funktion reprä- und Sicherheitsvorschriften eingehalten werden. sentiert werden. Derartige Kontakte sind im SLA zu defi- 5.4 Standardpasswörter: nieren. Der Auftragnehmer stellt sicher, dass jedes Standard- Es wird vom Auftragnehmer erwartet, Nutzerkonten mit passwort in allen mögl. Fällen geändert werden kann. Fernzugangsfunktion alle sechs Monate zu überprüfen

Seite 3 / 7

Vorsitzender des Verwaltungsrats: Oberbürgermeister Marcus König | Vorstand: Prof. Dr. Achim Jockwig (Vorsitzender), Dr. Andreas Becke, Sabine Beßler Kommunalunternehmen – Anstalt des öffentlichen Rechts | Sitz: Nürnberg | Registergericht: Nürnberg, HRA 14190 | Bankverbindung: Sparkasse Nürnberg IBAN: DE18 7605 0101 0001 0009 44, BIC: SSKNDE77XXX

[Seite 4]

EVB Ergänzende Vertragsbedingungen/Cyber Security Bedingungen – Allgemein mit IT Betrieb, Wartungsvertrag etc. – Stand: 17.09.2021 Vertragsanlage

und den Auftraggeber über notwendige Änderungen zu tionstests sollen dem Auftraggeber (zumindest für informieren. Diesbezüglich sind Authentisierungsverfah- die finale Version des Produktes) zur Verfügung ge- ren mit dem Auftraggeber zu vereinbaren. stellt werden. Bei den physischen Einrichtungen sind die gesetzlichen Regelungen bezüglich Datenschutz und IT-Sicherheitsge- 8. Einsatz der kryptographischen Lösungen: setz zu berücksichtigen. Um sicherzustellen, dass keine veralteten und als unsi- cher bekannten Kryptographielösungen in den Produk- 7. Anforderungen an die Softwareentwicklungsprozesse: ten verwendet werden, soll der Auftragnehmer eine Die Berücksichtigung der Sicherheit in Entwicklungspro- schriftliche Richtlinie etablieren und mit dem Auftragge- zessen (Security by Design) ist in vielen Fällen ein effizi- ber abstimmen, die die zulässigen Kryptographiealgo- enterer Weg, um ein sicheres Softwareprodukt herzu- rithmen definiert. Diese Richtlinie sollte sich an einen In- stellen, als das nachträgliche Patching und Ausrollen in dustriestandard halten und regelmäßig überprüft wer- der Produktion. Die Softwareentwicklungsprozesse des den. Auftragnehmers müssen so ausgelegt sein, dass der Si- Wenn eine Kryptographielösung in der Industrie als nicht cherheit der entwickelten Software angemessene Be- mehr sicher bekannt wird, muss die Richtlinie angepasst achtung in allen wichtigen Entwicklungsphasen ge- werden. Wenn eine solche Kryptographielösung in dem schenkt wird und die Prozesse sich an den allgemein an- bereits beim Auftraggeber eingesetzten Produkt ver- erkannten Industriestandards orientieren. wendet wird, muss der Auftragnehmer sie im Rahmen Insbesondere sollen folgende Punkte berücksichtigt wer- vom Vulnerability-Management-Prozess (s. Abschnitt 3) den: als Schwachstelle bewerten und melden. Der Lieferant hat Vorschläge zur Umgehung der Schwachstelle zu un- • Vorhandene Standards der sicheren Softwarearchi- terbreiten. tektur. Der Auftragnehmer muss sicherstellen, dass der Einsatz • Die Entwickler müssen sich an vorhandene Stan- der kryptographischen Absicherung der Kommunikation dards zur sicheren Programmierung halten, um und Ablage überall erfolgt, wo es notwendig ist, um die Schwachstellen vorzubeugen. Diese Standards müs- Grundsätze der sicheren Softwarearchitektur zu unter- sen dokumentiert werden und den Entwicklern z. B. stützen. Der Einsatz der kryptographischen Absicherung in Schulungen bekannt gemacht werden. der Kommunikation ist insbesondere notwendig, wenn • Secure-Code-Reviews als Teil der Qualitätssiche- Daten mit hohem Schutzbedarf (z.B. Steuerungsdaten rung und Testing. (Zum Beispiel müssen die eigen- der Kritischen Infrastruktur oder vertrauliche Daten) entwickelten Webapplikationen, die für den Betrieb über öffentliche oder als nicht ausreichend sicher gel- in nicht geschützten Netzen vorgesehen sind, ein tende Netzwerke übertragen werden. Code-Review nach einem Industriestandard wie O- WASP durchlaufen.) 9. Dokumentation: • Benutzung der Open-Source-Komponenten, ange- Es wird vom Auftragnehmer erwartet, dass dieser jegli- messene Konfiguration, Dokumentation und War- che Dokumentation zur Verfügung stellt, die die Nutzung tung dieser Komponenten. der angebotenen Lösung erleichtert. Der gebräuchliche • Die Testverfahren beim Auftragnehmer sollen die Umfang einer derartigen Dokumentation, wenn auch implementierten Sicherheitsmechanismen und - nicht auf diese beschränkt, inkludiert die folgenden funktionen (Verschlüsselung, Zugriffskontrollen, Punkte: Authentisierung und andere) explizit beinhalten. • Liste der Hardware Der Auftragnehmer stellt zu jeder Lieferung und zu jedem Update dem Auftraggeber die notwendige • Liste der Software (inklusive Betriebssystem und Menge von funktionalen Testfällen und -skripten Patch-Level) zur Verfügung, die zum sicheren Funktionsnachweis • Überblick über die Systemarchitektur (kann Teil der benötigt werden. Designdokumentation sein) • Sicherheitsüberprüfungen entsprechend den vorge- • Kommunikationsmatrix sehenen Betriebsumgebungen, z.B. unabhängige • Existierende Benutzerkonten und Rollen sowie de- Penetrationstests für die Systeme, die aus den ex- ren Berechtigungen ternen bzw. nicht abgesicherten Netzen erreichbar • Beschreibung von proprietären (nicht in der Indust- sein sollen. rie standardisierten) Sicherheitsmechanismen (Er- • Ergebnisse der Secure-Code-Reviews bzw. Penetra-

Seite 4 / 7

Vorsitzender des Verwaltungsrats: Oberbürgermeister Marcus König | Vorstand: Prof. Dr. Achim Jockwig (Vorsitzender), Dr. Andreas Becke, Sabine Beßler Kommunalunternehmen – Anstalt des öffentlichen Rechts | Sitz: Nürnberg | Registergericht: Nürnberg, HRA 14190 | Bankverbindung: Sparkasse Nürnberg IBAN: DE18 7605 0101 0001 0009 44, BIC: SSKNDE77XXX

[Seite 5]

EVB Ergänzende Vertragsbedingungen/Cyber Security Bedingungen – Allgemein mit IT Betrieb, Wartungsvertrag etc. – Stand: 17.09.2021 Vertragsanlage

wartung, die Prinzipien und Implementierung einer -senen Schutz der Assets, die in Bezug zu dem Informati- solchen Lösung zu verstehen) onssystem des Auftraggebers stehen, verantwortlich. • Weitere Dokumentationen, spezifiziert als Teil des Die beim Auftragnehmer gespeicherten Daten müssen in Liefergegenstandes oder Auftrages, die die Sicher- dessen Besitz verbleiben (besonders Kundeninformatio- heit der Lösung gewährleisten nen), da er für die Daten haftet, z.B. im Falle von Daten- Sollten Änderungen an der gelieferten Lösung durchge- verlust. führt werden, wird vom Auftragnehmer erwartet, diese 11.3 Human-Resources-Security: in die Dokumentation einzupflegen. Jeder, der im Namen des Auftragnehmers agiert, der ent- fernten oder lokalen Zugriff auf das Informationssystem 10. Benachrichtigung über sicherheitsrelevante Vorfälle: des Auftraggebers haben muss, muss Informationen zu • Der Auftragnehmer ist verpflichtet, Sicherheitsvor- seiner Identität bereitstellen. Der Auftragnehmer stellt fälle in seiner Organisation, die potenziell einen ne- sicher, dass in seinem Namen kein Zugang missbraucht gativen Effekt auf materielle und immaterielle gelie- wird und er die volle Verantwortung übernimmt, sollte ferte oder auf dem Informationssystem gespei- sich herausstellen, dass dieser Fall eintritt. cherte Vermögenswerte haben könnten, umgehend Sollte der Auftragnehmer mit Subunternehmern zusam- ohne Zeitverzug dem Auftraggeber zu melden. Dies menarbeiten, um den Vertrag mit dem Auftraggeber zu könnten z.B. auch Industriespionage oder eine Si- erfüllen, muss der Auftragnehmer diesen ausdrücklich cherheitslücke im Source-Code sein. als Subunternehmer identifizieren und er muss sicher- • Der Auftragnehmer wird im Falle eines Vorfalls auf stellen, dass der Subunternehmer die gleichen Anforde- Nachfrage des Auftraggebers Ressourcen zur Min- rungen erfüllt. derung und/oder Beseitigung des Vorfalles sowie Auf Verlangen des Auftraggebers ist der Auftragnehmer den finalen Korrekturbericht bereitstellen. verpflichtet, nur überprüftes Sicherheitspersonal, z.B. geprüft von nationalen Behörden, zum Umgang mit sen- 11. Nicht-technische Sicherheit: siblem Equipment einzusetzen, sowohl vor der der In- tegration in das Netzwerk des Auftraggebers als auch für 11.1 Organisation der Informationssicherheit: die Wartung des sensiblen Equipments während der ge- Der Auftragnehmer hat dem Antrag des Auftraggebers samten Betriebsphase. Relevante Informationen (insbe- nachzukommen, Informationen seiner Sicherheitsorga- sondere die Identifizierung und Bestimmung des sensib- nisation offenzulegen, auf dessen Basis der Auftraggeber len Equipments) müssen schriftlich vereinbart werden. eine Auftragnehmerbewertung durchführen kann. Diese Die von den lokalen gesetzlichen Bestimmungen festge- Einschätzung ist ein interner Prozess, der den Auftragge- legten Ausnahmen sind zu beachten (so müssen z.B. für ber dabei unterstützt, die Metriken und Reife der Sicher- Auftraggeber in anderen Regionen, wie Afrika, Asien, heitsorganisation des Auftragnehmers zu beurteilen. Nordamerika sonstige Anforderungen entsprechend der Der Auftragnehmer soll, falls vorhanden, ein ISO 27001- örtlichen Gesetze geachtet werden). Zertifikat oder Äquivalente (Historie und Umfang) bereit- Der Auftragnehmer beauftragt nur Personen, die über stellen, sowie weitere Dokumente wie Berichte und Vor- entsprechende Kenntnisse und Fähigkeiten bzgl. Installa- schriften etc. in diesem Kontext. tion, Soft- oder Hardware, Wartung oder Betrieb der Lö- 11.2 Asset-Management: sung verfügen. Der Auftragnehmer hat alle Assets in seinem Informati- 11.4 Auditrecht: onssystem zu identifizieren und zu dokumentieren, die Der Auftragnehmer stimmt zu, dass der Auftraggeber o- einen Bezug zum Informationssystem des Auftraggebers der ein anderer beauftragter Dritter im Auftrag des Auf- zwecks Wartung oder Betriebszugang haben können. Die traggebers die Organisation in Bezug auf die Informati- Verantwortung für die Aufrechterhaltung der entspre- onssicherheit des Auftragnehmers auditieren darf. Dies chenden Sicherheitskontrollen dieser Assets muss zuge- kann einmal oder mehrmals geschehen. Die Prüfungen wiesen werden. Die Assets sind zu dokumentieren. Diese werden auf der Grundlage der von dem Auftragnehmer Dokumentation ist möglicherweise Teil des Audits (Ab- zur Verfügung gestellten Dokumentation durchgeführt. schnitt 11.4), demnach werden alle Unterlagen vom Auf- Der genaue Umfang, die Dauer und die Organisation tragnehmer schriftlich gepflegt. werden jeweils einvernehmlich vereinbart. Zum Schutz der Assets kann der Auftragnehmer die An- Zusätzlich muss der Auftragnehmer die Abweichungen wendung spezifischer Sicherheitsmaßnahmen delegie- von den vereinbarten Sicherheitsanforderungen mel- ren, jedoch bleibt der Auftragnehmer für den angemes- den.

Seite 5 / 7

Vorsitzender des Verwaltungsrats: Oberbürgermeister Marcus König | Vorstand: Prof. Dr. Achim Jockwig (Vorsitzender), Dr. Andreas Becke, Sabine Beßler Kommunalunternehmen – Anstalt des öffentlichen Rechts | Sitz: Nürnberg | Registergericht: Nürnberg, HRA 14190 | Bankverbindung: Sparkasse Nürnberg IBAN: DE18 7605 0101 0001 0009 44, BIC: SSKNDE77XXX

[Seite 6]

EVB Ergänzende Vertragsbedingungen/Cyber Security Bedingungen – Allgemein mit IT Betrieb, Wartungsvertrag etc. – Stand: 17.09.2021 Vertragsanlage

12. Sicherheitsanforderungen für den IT-Betrieb: Zutritt zu Bereichen mit Informationen oder Systemen 12.1. Informationssicherheitsprozesse/ISMS: mit Schutzbedarf müssen auf den autorisierten Perso- nenkreis beschränkt werden. Dazu gehören auch die Zu- Der Auftragnehmer muss Informationssicherheitsma- trittsschutzmaß-nahmen für Rechenzentren inklusive nagementprozesse (ISMS) nach einem anerkannten Si- Überwachung der kritischen Bereiche, Zutrittsprotokoll cherheitsstandard aufsetzen. Diese Prozesse sowie ent- und Sicherung gegen Einbruch u. a. sprechende Rollen und Verantwortlichkeiten müssen als Teil seiner Informationssicherheitsrichtlinien dokumen- 12.6 Netzwerksicherheit und operationelle Sicherheit: tiert sein. Die Richtlinien müssen seiner Belegschaft be-  Netzwerksegmente mit unterschiedlichem Schutz- kannt sein und regelmäßig auf Aktualität und Richtigkeit bedarf und Sicherheitsstufen müssen (z.B. durch überprüft werden. Firewalls) voneinander getrennt werden. Netz- 12.2 Zugriffsschutz und Berechtigungsvergabe: werkperimeter müssen einen Firewallschutz haben. Firewallregeln müssen einen dokumentierten Frei- Prozesse und Kontrollen zum Zugriffsschutz und zur Be- gabeprozess durchlaufen. rechtigungsvergabe müssen implementiert werden:  Authentisierungsmerkmale (Passwörter, PINs) dür-  Dokumentierte Freigabeprozesse für Berechtigun- fen nur verschlüsselt über das Netzwerk übermittelt gen auf Systemen und Informationen werden.  Prozesse zur zeitnahen Löschung von Zugriffsrech-  Aus dem Internet erreichbare administrative Zu- ten bei Austritt oder Abteilungswechsel gänge oder Netzwerkports für den technischen Zu-  Definierte und angemessene Passwortkomplexität griff müssen abgeschaltet oder angemessen abgesi- und -gültigkeit chert werden (z.B. durch 2-Faktor-Authentisierung).  Bildschirmsperre nach Inaktivität  Netzwerkverbindungen, Systemzugriffe und admi- 12.3 Asset-Management: nistrative Tätigkeiten werden zur Nachvollziehbar- keit von Angriffen oder Fehlbedienungen protokol- Zusätzlich zu den im Abschnitt „Nicht-technische Sicher- liert. Die Aufbewahrung der Protokolle richtet sich heit - Asset Management“ definierten Anforderungen, nach den geltenden gesetzlichen, geschäftlichen müssen Standards zur sicheren Löschung der Daten / und Anforderungen des Auftraggebers. Zerstörung von Datenträgern definiert werden, um zu vermeiden, dass die gelöschten Daten von Dritten unau-  Virenschutz (für Server, Workstations sowie andere torisiert wiederhergestellt werden. IT-Komponenten mit Zugriff auf die Informationen oder Systeme mit Schutzbedarf) muss implemen- 12.4 Personalsicherheit (HR-Security): tiert und aktuell sein. Zusätzlich zu den im Abschnitt „Nicht-technische  Datensicherungs- und Wiederherstellungsprozesse Sicherheit – Human-Resources-Security“ definierten An- sind etabliert. Datenwiederherstellungstests wer- forderungen, müssen beim IT-Betrieb durch den Auftrag- den regelmäßig durchgeführt. nehmer folgende Punkte beachtet werden:  Sicherer physischer Transport von Speichermedien  Security-Awareness-Trainings für die Mitarbeiter (Verschlüsselung, physische Absicherung). müssen periodisch durchgeführt werden. Die In- halte der Schulungen müssen entsprechend den ak-  Software-Change-Prozesse für Produktivumgebun- tuellen Erkenntnissen regelmäßig aktualisiert wer- gen sind etabliert und werden befolgt. den.  Prozesse zu regelmäßigen Schwachstellenscans und 12.5 Physische Sicherheit und Zutrittsschutz: Behebung von Schwachstellen sind etabliert und werden befolgt. Der Auftragnehmer muss angemessene Vorkehrungen zur physischen Sicherheit und zum Zutrittsschutz treffen.  Wenn drahtlose Netzwerke benutzt werden, müs- Insbesondere sollen Maßnahmen zum/zur sen sie kryptographisch abgesichert sein (s. auch den Abschnitt „Einsatz der kryptographischen Lö-  Schutz gegen Feuer und Wasser, sungen“). Es muss sichergestellt werden, dass die  Schutz vor bzw. Vermeidung von extremen Tempe- Systeme sich nicht mit unautorisierten Access- raturen (Klimaanlage), Points verbinden können bzw. dass keine unautori-  Notstromversorgung sierten Netzwerke aufgebaut werden. implementiert sein.

Seite 6 / 7

Vorsitzender des Verwaltungsrats: Oberbürgermeister Marcus König | Vorstand: Prof. Dr. Achim Jockwig (Vorsitzender), Dr. Andreas Becke, Sabine Beßler Kommunalunternehmen – Anstalt des öffentlichen Rechts | Sitz: Nürnberg | Registergericht: Nürnberg, HRA 14190 | Bankverbindung: Sparkasse Nürnberg IBAN: DE18 7605 0101 0001 0009 44, BIC: SSKNDE77XXX

[Seite 7]

EVB Ergänzende Vertragsbedingungen/Cyber Security Bedingungen – Allgemein mit IT Betrieb, Wartungsvertrag etc. – Stand: 17.09.2021 Vertragsanlage

12.7 Security-Incident-Management Prozesse zur Reaktion auf Sicherheitsvorfälle, sowie die dazugehörigen Rollen und Verantwortlichkeiten müssen definiert sein. Zur Meldung der Sicherheitsvorfälle s. den Abschnitt „Benachrichtigung über sicherheitsrelevante Vorfälle“. 12.8 Sicherheit in Auslagerungsprozessen Wenn der Auftragnehmer Teile der Betriebsleistung o- der anderer Dienstleistungen für den Auftraggeber an weitere Dienstleister auslagert, müssen Sicherheitsan- forderungen in den Vereinbarungen mit den Dienstleis- tern berücksichtigt werden. Die Sicherheitsanforderun- gen mit den Dienstleistern müssen so definiert werden, dass die Sicherheitsstandards für die Daten des Auftrag- gebers und Leistungen für den Auftraggeber in jedem Fall eingehalten werden können und dass der Auftrag- nehmer in der Lage ist, eigene Verpflichtungen zur Si- cherheit gegenüber dem Auftraggeber vollumfassend zu erfüllen. Eine transparente Darstellung der durchgehen- den Lieferkette einschließlich Subunternehmer ist ge- genüber dem Auftraggeber nachzuweisen. Der Auftrag- nehmer muss den Auftraggeber im Vorfeld von Entschei- dungen über die Auslagerung von Betriebs- oder Dienst- leistungen informieren.

Seite 7 / 7

Vorsitzender des Verwaltungsrats: Oberbürgermeister Marcus König | Vorstand: Prof. Dr. Achim Jockwig (Vorsitzender), Dr. Andreas Becke, Sabine Beßler Kommunalunternehmen – Anstalt des öffentlichen Rechts | Sitz: Nürnberg | Registergericht: Nürnberg, HRA 14190 | Bankverbindung: Sparkasse Nürnberg IBAN: DE18 7605 0101 0001 0009 44, BIC: SSKNDE77XXX