4.10 Leistungsbeschreibung IT-Sicherheit_V0.7.docx

IT-Sicherheit

Einleitung

Dieser Anhang dient als Ergänzung der Anforderungen zur Informationssicherheit. Er spezifiziert die Ausführungen der „Erweiterten Vertragsbedingungen Informationssicherheit“ (EVB IS) und den Anhang 4 der EVB IS zur „Leit- und Sicherungstechnik und Telekommunikation Infrastruktur“ (EVB IS LST/TK) für den Rahmenvertrag iBS. Diese Anmerkungen beziehen sich auf die jeweils aktuellsten Versionen der benannten Dokumente.

Die Ergänzungen orientieren sich an den Kapiteln der EVB IS und den Kapiteln des Anhang 4 zur EVB IS LST/TK. Die Kapitel, die nicht kommentiert sind, bilden die erforderlichen Anforderungen der IT-Sicherheit angemessen ab.

Der Begriff Sicherheit ist in diesem Anhang immer als IT-Sicherheit, nicht als Safety, zu verstehen. Gleiches gilt auch für den Begriff Sicherheit in den EVB IS und EVB IS LST/TK. Unter IT-Sicherheit in dieser Anlage wird die OT-Sicherheit subsumiert, insofern diese nicht explizit aufgeführt wird.

Die Anlage 4.10 und die Anforderungen gemäß EVB IS und EVB IS LST/TK gelten für alle Systeme und Komponenten, die im Rahmenvertrag enthalten sind, sowie für Weiterentwicklungen der Systeme und Komponenten, die durch diesen Rahmenvertrag abgedeckt sind bzw. im Rahmen von Vertragserweiterungen und Neuentwicklungen abgedeckt sein werden.

Der Schutzbedarf der betrachteten Assets ist als „Sehr hoch“ eingestuft.

Übersicht Änderungen EVB IS und EVB IS LST/TK

Die Kapitel der EVB IS und EVB IS LST/TK mit Änderungen können den Tabellen entnommen werden.

Änderungen der EVB IS:

Tabelle 1: Änderungsübersicht EVB IS

Änderungen der EVB IS LST/TK:

Tabelle 2: Änderungsübersicht EVB IS LST/TK

Ergänzungen zur EVB IS

Ergänzung zu 2.2 - Rollen und Ansprechpartner

Die Ansprechpartner seitens Auftraggeber gegliedert nach Kategorie, sofern im Einzelauftrag nicht anders benannt:

Ansprechpartner Regelkommunikation:

Verantwortliche Bauartbetreuung der DB InfraGoAG

Melden von Informationssicherheitsvorfällen

Bei Auffälligkeiten in E-Mails bzw. in BKU-Systemen:

E-Mail: DB.Systel.Helpdesk@deutschebahn.com

Tel.: +49 (0)361 430 8200

Bei Auffälligkeiten in Systemen der DB InfraGo AG:

E-Mail: soc-dbn@deutschebahn.com

Tel.: +49 (0)69 265 41111

(24/7 Erreichbarkeit)

Änderungen werden durch die DB InfraGo AG bekannt gegeben.

Der Auftragnehmer stellt sicher, dass die Ansprechpartner und Kontaktinformationen auf Auftragnehmerseite je Kommunikationskategorie (Regelkommunikation und Notfallkommunikation und Koordination Informationssicherheit) für jeden Einzelauftrag festgelegt sind und bei Änderungen dem SOC der DB InfraGo AG und, falls notwendig, den entsprechenden verantwortlichen Bauartbetreuungen unverzüglich mitgeteilt werden.

Anfragen zu potenziell IT-sicherheitskritischen Aspekten sind durch den Auftragnehmer qualifiziert zu bearbeiten und zu beantworten. Die Reaktionszeiten sind in der EVB IS geregelt (Ril 114.0240A03). Die Lösungszeit beschreibt die Dauer zwischen der Aufnahme einer Störung, eines Incidents oder Schwachstellenmeldung und deren Lösung und ist abhängig vom Schutzbedarf des betroffenen Assets. Soweit im Einzelvertrag nicht anders vereinbart, orientiert sich die Lösungszeit an der Schwere der Schwachstelle und orientiert sich an den Zeiten aus Kapitel 5.1 - Erreichbarkeiten“ sowie an Ril 114.0240A03, und unterliegt den Anforderungen, die sich aus dem Schutzbedarf von „Sehr Hoch“ ergeben.

Dies gilt für erkannte Schwachstellen bei Hard- und Softwarekomponenten des Lieferanten für die bereits im Einsatz befindlichen Systeme und Komponenten, wie auch für noch nicht im Einsatz befindlichen Systeme und Komponenten. Dabei ist darauf zu achten, Schwachstellen entsprechend der vorhandenen Releasestände zu dokumentieren und zu kommunizieren. Siehe dazu auch „Ergänzung zu 5.10 – Patchfähigkeit“ sowie Anlage 7.5 (2) Hotline-Service des Rahmenvertrags iBS.

Der Auftragnehmer hat hierzu eine Verbindungsstelle zu benennen, falls diese von den oben beschriebenen Kategorien abweicht.

Ergänzung zu 2.4 – Statusbericht

Adressat auf Seiten des Auftraggebers ist das SOC der DB InfraGo AG.

Der Auftraggeber kann jederzeit nach Bedarf weitere Personen benennen, die den Statusbericht empfangen sollen.

Der Statusbericht ist vertraulich zu behandeln und muss auf einem sicheren Kommunikationskanal übertragen werden. Siehe dazu Kapitel 2.8 der EVB IS.

Ergänzung zu 2.6 – Verpflichtung Nachunternehmer

Neben der ISO 27001 müssen die einschlägigen Sicherheitsvoraussetzungen, die bei der DB InfraGo AG und der DB AG zur Anwendung kommen, berücksichtigt werden. Weitere Regelungen werden, falls notwendig, zu Vertragsbeginn im Einzelvertrag zwischen den Vertragsparteien abgestimmt und festgelegt.

Ergänzung zu 2.10 – Löschung von Daten

Der Auftragnehmer ist verpflichtet sämtliche im Zusammenhang mit einem Einzelvertrag stehenden nicht personenbezogenen Daten der Stufen „DB Vertraulich“ und „DB Streng Vertraulich“ sowie sämtliche im Zusammenhang mit einem Einzelvertrag stehenden personenbezogenen Daten an allen primären und sekundären Standorten des Auftragnehmers und seiner Nachunternehmer bei Beendigung des Vertrags unverzüglich und sicher zu löschen und zu vernichten, so dass diese nicht wiederhergestellt werden können. Vorstehendes gilt nicht für Daten, zu deren Aufbewahrung der Auftragnehmer gesetzlich verpflichtet ist oder dies vertraglich geregelt wurde. Der Auftragnehmer weist dies auf Verlangen dem Auftraggeber nach.

Ergänzung zu 2.11 – Endgeräte

Vor Vertragsabschluss sind dem Auftraggeber die vom Auftragnehmer auf auftragnehmereigenen Endgeräten insbesondere zur Erfüllung vereinbarter Dienstleistungen eingesetzten IT-Tools, die unter Hacking-Tools fallen, aufzuzeigen und mit dem Auftraggeber abzustimmen.

Zu den in 2.11 erwähnten Hacking-Tools sind insbesondere

• Netzwerk- und Port-Scanner (Bsp. NMAP, Masscan etc.),
• Vulnerability-Scanner (Bsp. Nessus, OpenVAS etc.),
• Sniffing-Tools (Bsp. Wireshark, tcpdump etc.),
• Fuzzing-Tools (Bsp. ffuf, AFL etc.),
• Password-Cracker (Bsp. hashcat, John the Ripper etc.),
• Exploitation-Frameworks (Bsp. metasploit, ISF etc.),
• diverse Exploits und PoC-Exploits (Bspw. für Privilege Escalation, zum Auslesen von Hashes etc.),
• Reverse-Engineering-Tools (Bsp. Ghidra, radare2 etc.)
• Remote-Access-Tools (TeamViewer, Connectwise, Screenconnect etc.)
• Pentest-Tools sowie
• weitere Tools mit vergleichbaren Funktionalitäten

zu zählen.

Der AG führt eine Überprüfung von Wechseldatenträgern vor Einbringung in das System auf Schadsoftware durch. Daher dürfen nur die folgenden Wechseldatenträgertypen und Datenformate für alle Endgeräte verwendet werden:

Tabelle 3: Zugelassene Wechseldatenträgertypen und Datenformate

Nicht benötigte Datensicherungen sind sicher zu löschen. Ist eine sichere Löschung nicht möglich, ist der Datenträger gemäß dem Schutzbedarf der Informationen angemessen zu vernichten. Für die sichere Entsorgung von Datenträgern nach den Normen DIN 66399 und EN 15713 sind geeignete Geräte zu verwenden oder zertifizierte Dienstleister/Nachunternehmer zu beauftragen.

Abweichungen hiervon sind vor deren Einführung mit dem AG abzustimmen.

Eine durch den Auftragnehmer oder seine Nachunternehmer herbeigeführte Netzkopplung der Datennetze des Auftraggebers und der mit diesem verbundenen Unternehmen mit anderen Datennetzen ist ohne vorherige Zustimmung des Auftraggebers unzulässig.

Ausnahmeregelungen können für bestimmte Anwendungsfälle im Einzelvertrag zwischen Auftragnehmer und Auftraggeber nach entsprechenden regelwerkskonformen Risikoübernahme durch AG vereinbart werden.

Ergänzung zu 2.12 – Meldung Sicherheitsvorfälle

Bei einer Datenschutzverletzung gemäß Art. 33 DSGVO ist der Datenschutz-beauftragte der DB InfraGo AG zu informieren.

Der Auftragnehmer meldet die Datenschutzverletzung der verantwortlichen Bauartbetreuung der DB InfraGo AG. Der Vorfall wird von der verantwortlichen Bauartbetreuung in das Meldeformular zur Datenschutzverletzung eingetragen und an den Datenschutz der DB InfraGo AG (datenschutz.dbinfrago@deutschebahn.com) zur weiteren Bearbeitung weitergeleitet.

Der Auftragnehmer ist verpflichtet, IT/OT-Sicherheitsvorfälle und -verdachtsfälle unverzüglich dem AG zu melden, siehe dazu auch Ziffer 2.2. OT-Sicherheitsvorfälle und -verdachtsfälle müssen durch den Auftragnehmer unverzüglich an das SOC der DB InfraGo gemeldet werden, siehe dazu auch Ziffer 2.2.

Ergänzung zu 2.14 – Zugriffe

Bei den Zugriffen muss es sich um personalisierte und eindeutige Zugänge handeln.

Die Zugriffe dürfen nur auf die dafür vorgesehenen Systeme in Abstimmung mit AG und AN erfolgen und müssen rückwirkungsfrei auf alle übrigen Systeme der Anlage erfolgen. Die Zugriffe sind entsprechend durch den Auftragnehmer zu protokollieren.

Bei Zugriffen auf Daten von Diagnosesystemen sind eine Identifizierung und Authentifizierung sowie die entsprechende Protokollierung auf geeignete Art festzuhalten und dem Auftraggeber auf Verlangen auszuhändigen.

Die DB InfraGo AG behält sich vor, für Zugriffe auf Diagnosesysteme bei Verwendung einer sicheren Umgebung, z.B. in Form einer VPN-Umgebung, von den genannten Zugriffsanforderungen abzuweichen.

Es wird darauf hingewiesen, dass bei technischen Lösungen der DB AG zur Fern-Zugriffsgewährung für Dritte eine umfassende Aufzeichnung aller Aktivitäten und zugehöriger Metadaten für die Dauer des Zugriffs erfolgen kann.

Siehe dazu auch Anlage 7.5 (2) Hotline-Service des Rahmenvertrags iBS.

Ergänzung zu 3.1 – Informationen der Sicherheitsorganisation

Seitens des Auftraggebers ist das SOC der DB InfraGo AG und jede weitere vom Auftraggeber benannte Person anforderungs- und empfangsberechtigt für Informationen der Sicherheitsorganisation des Auftragnehmers.

Der Personenkreis kann auf Wunsch des Auftraggebers jederzeit geändert werden.

Ergänzung zu 3.2 – Audit

Ansprechpartner seitens Auftraggeber ist die für Security-Audits zuständige Stelle innerhalb der DB InfraGo AG. Kontaktinformationen sind über die Regelkommunikation in Erfahrung zu bringen.

Der Auftraggeber behält sich das Recht vor, zukünftig regelmäßige Lieferantenaudits durchzuführen.

Ergänzungen zur EVB IS LST/TK

Ergänzung zu 5.1 – Erreichbarkeiten

Folgende Ansprechpartner sind seitens Auftraggeber festgelegt:

Regelkommunikation: Bauartverantwortliche der DB InfraGo AG

Notfallkommunikation: IT: Helpdesk DB Konzern

OT: SOC DB InfraGo AG

Siehe dazu auch: Ergänzung zu 2.2.

Ergänzung zu 5.4 – Sicherheitsdokumentation

Es handelt sich bei dem Begriff Sicherheit um IT-Informationssicherheit. Dies ist ebenfalls in der Sicherheitsdokumentation zu berücksichtigen.

Ergänzung zu 5.6 – Netzwerkarchitektur und -betrieb

Die Anforderungen aus Kapitel 5.6, Satz 1 sind zu berücksichtigen und im Einzelvertrag genauer zu spezifizieren – abhängig vom zu beschaffenden IT/OT-Asset.

Ergänzung zu 5.8 – Kryptographie

Zum Schutz der Informationssicherheitsziele Vertraulichkeit, Authentizität und Integrität, sind in geeigneter und angemessener Weise kryptographische Verfahren und Maßnahmen umzusetzen. Der aktuelle Stand der Technik kann u.a. den Standards des BSI zum Thema Kryptographie entnommen werden: BSI TR-02102 Kryptographische Verfahren: Empfehlungen und Schlüssellängen.

Sollten bereits eingesetzte Verfahren und Systeme nicht dem Stand der Technik entsprechen, ist dies durch den Auftragnehmer zu dokumentieren und sind dem Auftraggeber zur Risikominimierung mitigierende Maßnahmen anzuzeigen. Der Auftragnehmer ist verpflichtet, eine Lösung zur Umsetzung der mitigierenden Maßnahmen unter Berücksichtigung der aktuellen Zulassung zur Verfügung zu stellen, mit dem Auftraggeber abzustimmen und zu realisieren.

Ergänzung zu 5.9 – Entwicklung und Test

Maßgeblich für Tests im Rahmen der Entwicklung sind die in Anlage 4.7 „Durchführung von Tests und Abnahmen“ definierten Festlegungen und Anforderungen.

Die Anforderungen beziehen sich konkret auf die Entwicklung und Tests im Umfeld der IT/OT-Security. Der Auftraggeber kann bei Bedarf Einsicht in die Testprotokolle verlangen.

Zusätzlich behält sich der Auftraggeber das Recht vor, weitere Tests in Auftrag zu geben.

Informationssicherheitsanforderungen und deren Umsetzung durch den Auftragnehmer sind bei Weiter- oder Neuentwicklungen mit dem Auftraggeber zu konkretisieren, fortlaufend abzustimmen und umzusetzen.

Sind Ergänzung der fachtechnischen Abnahmen um IT-Sicherheitsanteile sowohl beim Hersteller und deren Support durch weitere Hersteller sowie weitere Anteile nach der Herstellung der Funktionsfähigkeit (HdF) notwendig, sind diese durch den Auftragnehmer umzusetzen und entsprechend zu dokumentieren.

Der Auftragnehmer bindet bei Themen der Entwicklung und Tests die verantwortliche Bauartbetreuung seitens des Auftraggebers ein.

Penetrationstests sind grundsätzlich zum Abschluss der Produktentwicklung, insbesondere im Zusammenhang mit der fachtechnischen Abnahme des Auftraggebers durchzuführen. Der Auftragnehmer ermöglicht die Durchführung der Penetrationstests durch qualifizierte Mitarbeiter des Auftraggebers bzw. von ihm beauftragten Dritten in der Entwicklungs- und Testumgebung des Auftragnehmers. Sind seitens des Auftragnehmers ebenfalls Penetrationstests geplant, ist eine gemeinsame Durchführung bzw. Begleitung der Tests durch qualifiziertes Personal des Auftraggebers unter der Bedingung, dass die gesamte Durchführungs- und Ergebnisdokumentation der Penetrationstest dem Auftraggeber übergeben wird, zu prüfen. Die abschließende Festlegung, ob durch den AG zusätzlich eigene Penetrationstests erforderlich sind und durchgeführt werden, obliegt dem AG.

Im Hinblick auf die nach den EVB IS, EVB IS – LST/TK und dieser Anlage 4.10 vereinbarten IT-Sicherheitsanforderungen schuldet der Auftragnehmer zum Zeitpunkt der rechtsgeschäftlichen Abnahme (vgl. Abschnitt 19 des Modulvertrags) den jeweils aktuellen Stand der Technik. Das bedeutet, dass ggf. auch nach der Herstellung der Funktionsfähigkeit (HdF) oder Inbetriebnahme einer STE-Anlage unter Berücksichtigung der jeweiligen aktuellen Zulassung IT-/OT-Sicherheitsanteile zu ergänzen oder anzupassen sind sowie dies entsprechend zu dokumentieren ist. Der Auftragnehmer bindet bei Themen der Entwicklung und Tests den zuständigen Bauartverantwortlichen des Auftraggebers ein.

Ergänzung zu 5.10

– Patchfähigkeit

Bei den Themen Patchfähigkeit und Patchmanagement muss zwischen den verschiedenen Systemen unterschieden werden und es müssen entsprechende Anforderungen beachtet werden:

1. bereits zugelassene Systeme/Komponenten, die Gegenstand dieses Vertrages sind

2. zuzulassende Systeme/Komponenten, die in den Vertrag aufgenommen werden

3. Systeme/Komponenten, die einer Komptabilitätsbewertung unterliegen

4. Systeme/Komponenten, für die der Nachweis der Rückwirkungsfreiheit erforderlich ist

5. sonstige Systeme/Komponenten der LST (außerhalb IB)

Für Systeme der Kategorie 4 und 5 sind in regelmäßigen Abständen Sicherheits-Patches durch den Hersteller zu liefern. Dabei gilt für die Kategorie 4 eine Zeitspanne von 6 bis 12 Monate als Patchzyklus, falls betroffene Systeme/Komponenten ohne Verlust der Genehmigung bzw. einer etwa erforderlichen Zulassung oder einer Freigabe gepatcht werden können. Für Systeme und Komponenten der Kategorie 5 ist ein Patchzyklus nach dem aktuellen Stand der Technik zu gewährleisten, falls betroffene Systeme/Komponenten ohne Verlust der Genehmigung bzw. einer etwa erforderlichen Zulassung oder einer Freigabe gepatcht werden können. Als Orientierung des aktuellen Stands der Technik für Sicherheitspatches, dienen die Bestimmungen der DB Konzernrichtlinie 114.0240A03.

Der Auftragnehmer gibt auf Anfrage des Auftraggebers eine Empfehlung für die Umsetzung der Patches ab. Zusätzlich findet zwischen den Vertragspartnern eine Abstimmung zur Planung und Umsetzung der Patches statt.

Der Auftragnehmer muss dem Auftraggeber auf Anfrage Maßnahmen aufzeigen, um bereits zugelassene Systeme (Kategorie 1) so anzupassen, dass bekannte IT-sicherheitstechnische Lücken in ihrem Risiko behandelt werden können, falls keine Möglichkeit des Patchens besteht. Gleiches gilt auch für Systemkategorie 2 und 3. Die Maßnahmen müssen unter Berücksichtigung der jeweils aktuellen Zulassung gewählt werden.

Bei neuen oder noch nicht zugelassenen Systemen hat der Auftragnehmer sicherzustellen, dass die Möglichkeit zum Patchen der Systeme vorhanden ist und dies mit der freigebenden Stelle entsprechend vereinbart werden kann.

Der Patchstand ist durch den Auftragnehmer zu dokumentieren und in einem CMDB-lesbaren Format dem AG zur Verfügung zu stellen. Bei neuen Releases und Neuzulassungen ist die Aktualität der verwendeten Systeme und Software mit aktuellen Patches zu gewährleisten. Auf Verlangen des Auftragnehmers ist eine angemessene Karenzzeit von nicht mehr als sechs Monaten zwischen Auftragnehmer und Auftraggeber abzustimmen, um für den Fall neuer Releases und Neuzulassungen die Aktualität und Umsetzbarkeit sicherzustellen. Nach Ablauf der Karenzzeit ist die Aktualität der verwendeten Systeme und Software vollumfänglich zu gewährleisten.

Ergänzung zu 5.11 – Patchmanagement

Ansprechpartner für das Thema Patchmanagement ist die verantwortliche Bauartbetreuung des jeweiligen Systems oder der jeweiligen Komponente beim Autraggeber. Mit dieser werden u.a. die Ergänzungen zu 5.10 abgestimmt und umgesetzt.

Ergänzung zu 5.12 - Vorbereitung der Inbetriebnahme

Zwischen Auftragnehmer und Auftraggeber ist die Art und Durchführung des Monitoringverfahrens für die beauftragte Anlage abzustimmen, soweit diese über die rückwirkungsfreien Monitoringmaßnahmen hinausgehen. Siehe dazu auch Ergänzungen zu 5.22.

Für bereits zugelassene Systeme ist dem Auftragnehmer auf Anfrage ein Katalog mit möglichen Maßnahmen zur Absicherung der Systeme hinsichtlich Manipulationsmöglichkeiten, d.h. Maßnahmen, die nicht zu einem Zulassungsverlust (z.B., weil sich nicht die Prüfsumme ändert) führen bzw. sind diese Maßnahmen durch den Auftragnehmer in Rücksprache mit dem Auftraggeber zu übergeben und umzusetzen.

Ergänzung zu 5.13 - Standardpasswörter

Alle Passwörter müssen änderbar sein und technisch den Vorgaben der DB InfraGo AG entsprechend konfigurierbar sein. Voreingestellte Standardpasswörter sind in einem gesonderten Dokument angemessen verschlüsselt dem AG zu übermitteln. Dieses Dokument muss für jedes enthaltene Passwort, einen Verweis zur Dokumentation enthalten, in der die Änderung beschrieben wird. Passwörter sind zur Inbetriebnahme in Abstimmung mit dem ALV gem. Ril 114.0230A01 der DB AG zu ändern.

Zusätzlich übergibt, angemessen verschlüsselt, der Auftragnehmer eine Übersicht aller bereits im System bzw. im Liefergegenstand eingerichteten Konten und Nutzer in einem separaten Dokument. Dies inkludiert auch die zugehörigen voreingestellten Passwörter. Ausgenommen hiervon sind die Passwörter der ggf. für Servicezwecke eingerichteten AN-Konten/Nutzer. Diese unterliegen den einschlägigen Vorgaben des AG. Jede Konto- und Nutzerangabe ist mit einem Verweis auf die Herstellerdokumentation zu versehen, in der die Berechtigungen des Nutzers/Kontos bzw. der zugrundeliegenden Rollen beschrieben sind. Auf Einschränkungen der Administration und Bearbeitbarkeit von Berechtigungen, Rollen, Konten und Nutzern ist explizit hinzuweisen.

Ergänzung zu 5.16 – Konfigurationsdaten

Bei Auslieferung eines Produktes an den Auftraggeber muss auf Anfrage ein Auszug der Assetinformationen des Produktes gemäß Anhang 6.2 und ggf. 6.2.1 in maschienenlesbarer Form an den Auftraggeber gesendet werden. Die Assetdaten sollten alle bei Abnahme unveränderlichen Informationen/Datenfelder enthalten.

Enthalten sein müssen die konkreten Versions-, Hersteller- und Konfig- und Patchdaten. Das beinhaltet auch Daten über zugekaufte Produkte und/oder Komponenten.

Ergänzung zu 5.21 – Schwachstellenprüfung

Als Grundlage der Schwachstellenbewertung dient das Common Vulnerability Scoring System (CVSS). Dieser Standard dient zur einheitlichen Bewertung von Schwachstellen, um eine Priorisierung anhand von standardisierten Kriterien festzulegen. Die Priorisierung der relevanten Bewertungsmetriken und die Kategorisierung des CVSS Scores ist der DB Konzernrichtline 114.0240A03 zu entnehmen. Zu Vertragsbeginn wird zwischen dem Auftragnehmer und dem Auftraggeber abgestimmt, mit welchen Maßnahmen auf die jeweilige Kategorie bzw. den jeweiligen CVSS Score reagiert werden muss.

Voraussetzung zur Bewertung einer Schwachstelle durch den AG, ist die verpflichtende Bereitstellung der notwendigen Assetinformationen durch den AN zu den jeweiligen Komponenten etc., die innerhalb der Anlage verbaut sind. Weiterhin dienen die Assetinformationen einer zielgerichteten Diagnose und Behebung der Schwachstelle.

Mit Antrag der DB-Freigabe ist eine aktuelle (nicht älter als 30 Tage) Schwachstellen-prüfung und -dokumentation des Produktes zu übergeben. Diese Prüfung ist in Abhängigkeit der Systemkategorie, aber auf jeden Fall vor Inbetriebnahme, regelmäßig zu wiederholen. Die Regelmäßigkeit der Prüfungen und die schwachstellenbezogenen Maßnahmen orientieren sich nach den Systemkategorien aus Kapitel „Ergänzungen zu 5.10 - Patchfähigkeit“. Diese lauten:

Turnus, grobe Nennung von Maßnahmen zur Beseitigung der Schwachstelle

1. 1 x im Quartal, Workaround, Patches bei Folgerelease

2. nach Zulassung wie 1,

3. wie 1

4. 1 x im Quartal, Patches

5. gemäß Best Practices (alle 30 Tage) und anlassbezogen; Patches

Diese Zyklen gelten unter der Berücksichtigung der jeweils aktuellen Zulassung, falls nicht anderweitig im Einzelvertrag zwischen Auftragnehmer und Auftraggeber (Beteiligung von Bauartverantwortung notwendig) geregelt.

Hinweis: Vor der Inbetriebnahme ist bei allen Kategorien eine Prüfung verpflichtend.

Ergänzung zu 5.22 – Integration Schwachstellenmanagement und Event Management

Um eine Integration des Schwachstellenmanagement und Event Management zu gewährleisten, legt der Auftragnehmer fest, welche Systeme und Netzsegmente anzubinden sind. Es ist abzustimmen, welche Netzwerkarchitekturen, Logs, Events und Protokolle etc. benötigt und zukünftig genutzt werden. Diese Informationen dienen zur Anbindung genutzter Systeme an das SIEM des SOC der DB InfraGo.

Die Umsetzung der Logging-Strategie des AG für die zu liefernden Systeme und Komponente sowie deren Ausleitung an das SOC der DB InfraGo AG wird durch den AN gemeinsam mit dem AG je System/Komponente auf Basis des gültigen Threat-Modellings des AG entworfen und durchgeführt. Bei zulassungs- oder kompatibilitätsrelevanten Systemen/Komponenten muss dies vor der fachtechnischen Abnahme bzw. vor den Integrationstests erfolgen. Zusätzlich dienen die Informationen zur Integration in das Schwachstellenmanagement der DB InfraGo, um eine zielgerichtete Schwachstellenbeseitigung durchführen zu können.

Die entsprechenden Audit Policies und Logging-Einstellungen dürfen nicht einer Zulassungs-, Legitimations- oder Kompatibilitätsbewertung unterliegen und müssen im laufenden Betrieb, ggf. unter Mitwirkung des Auftragnehmers, änderbar sein, um auf eine geänderte Bedrohungslage reagieren zu können. Abweichungen hiervon sind mit dem Auftraggeber explizit abzustimmen.

Ergänzung zu 5.23 – Meldung von Schwachstellen

Die Meldung durch den AN erfolgt aktiv, eine passive Publikation über eine AN-seitige Internetseite o.ä. ist nicht zulässig - stattdessen sollen die in „Ergänzung zu 2.2 - Rollen und Ansprechpartner“ genannten Kontaktwege Anwendung finden, die Übermittlung ist als Vertraulich zu behandeln.

Ergänzung zu 5.24 – Beseitigung von Schwachstellen

Die Behebungsform und -fristen von Schwachstellen ist abhängig von der Kritikalität der Schwachstelle und der Systemkategorie aus „Ergänzung zu 5.10 - Patchfähigkeit“.

Zur Eingrenzung des Risikos durch offene Schwachstellen ergeben sich zusätzlich zu Patches auch kurzfristigere Behandlungsmöglichkeiten z.B. in Form eines Workarounds. Abhängig von der Kritikalität der Schwachstelle und der betroffenen Systemkategorie, ergeben sich unterschiedliche Reaktionszeiten. Als Richtwert können die Werte aus der EVB IS LST/TK Kapitel 5.1. genutzt werden.

Für die Bewertung der Schwachstelle und die Dauer der möglichen Bereitstellung des Workarounds (abhängig von betroffener Systemkategorie), muss mit den Bauartverantwortlichen zu Vertragsbeginn ein Richtwert definiert werden.

Abhängig von der Schwere des Vorfalls leitet der Auftragnehmer Maßnahmen zur Behandlung der Schwachstelle ein. Als Richtwert gelten die Behandlungsfristen aus der DB-Richtline 114.0240A03. Die Behandlung der Schwachstellen ist unter der Berücksichtigung der jeweils aktuellen Zulassung durchzuführen.

Der Auftragnehmer hat dafür Sorge zu tragen, dass die Workarounds abhängig von den in „Ergänzung zu 5.10“ benannten Patchzyklen durch Patches / Folgereleases abgelöst werden. Ausnahmen für Systeme und Schwachstellen können zwischen den Vertragspartnern abgestimmt werden, falls ein Patch nicht realisierbar ist oder der Workaround zunächst langfristig angewendet werden muss.