Beschaffung SIEM-Lösung inkl. Implementierung | rku.it GmbH | Öffentliches Auftragswesen in Deutschland

Datum	Dokument
2023-12-01	Auftragsbekanntmachung

Kurze Beschreibung

Anforderungen an die SIEM-Software Folgende Anforderungen bezüglich Funktionalitäten stellen wir an die Lösung: 1.1 Log Collection Die Lösung muss "elasticsearch" als Data Lake unterstützen. Es sollte das "Common Event Format" (folgend CEF) mit einem standardisierten Parser unterstützen. Es muss zusätzlich möglich sein, eigene Parser für Logs zu erstellen. Die Lösung muss tolerant gegenüber Logs sein, welche Daten enthalten, die die Lösung nicht interpretieren kann (Unterpunkt Log Coll-ection -> Postel"s Law). Die gesamte Lösung muss mandantenfähig sein. Loginformationen einzelner Kunden müssen sauber dargestellt, separiert, exportiert und gelöscht werden kön-nen. Es muss sichergestellt sein, dass der Zugriff von Mandanten ausschließlich auf ihre ei-genen Daten erfolgen kann. Ein zentraler Mandant (Betreiber-Sicht) muss alle Daten korre-lieren können. *siehe 1.2 Betriebssystem-Unterstützung Die Betriebssystemunterstützung der Lösung sollte umfangreich und aktuell sein, sodass die von rku.it betriebenen Server und Clients abgedeckt werden. Leistungsbeschreibung_SIEM_v0.1 Seite 4/13 Derzeit setzen wir im Serverumfeld folgende Betriebssysteme ein, die unterstützt werden müssen: - Windows Server 2022 Standard - Windows Server 2022 Datacenter - Windows Server 2019 Standard - Windows Server 2019 Datacenter - Windows Server 2016 Standard - Windows Server 2016 Datacenter - Windows Server 2012 R2 - Windows Server 2012 - Redhat 7,8,9 x86_x64 - Redhat 8,9 ppc64le - SLES12, SLES15 x86_64 - SLES12, SLES15 ppc64le - AIX 7.1 / 7.2 / 7.3 Im Clientumfeld setzen wir folgende Betriebssysteme ein, die unterstützt werden müssen: - Windows 10 - Windows 11 - Windows 11 Enterprise Multi Session 1.3 Logverwaltung Ergebnisse der Bewertung des SIEMs müssen in einem Format bereitgestellt werden, wel-ches marktüblich (z.B.: in einem standardisierten JSON-Export) ist und von anderen Syste-men interpretiert werden kann. Falls Logs bzw. Events außerhalb des Data-Lakes gespei-chert werden, sollte ein Speichertiering mit Hot-/Cold-/Archiv-Tier implementierbar sein. Ins-besondere sollte die Lösung als Archiv-Tier einen S3-kombatiblen externen Speicher ver-wenden können. Die gespeicherten Logs müssen innerhalb der Lösung um Tags/Attribute erweiterbar sein. *siehe 1.4 Event Correlation / Use Cases Es sollte ein Basisregelwerk verfügbar sein. Es muss möglich sein eigene Use Cases/Regeln zu erstellen und zu importieren. *siehe 1.5 Bedrohungserkennung Die Lösung sollte Events- und Korrelationsregeln mit bekannten CVEs abgleichen und da-raufhin relevante Informationen in der Event- oder Alertbeschreibung mitliefern. Leistungsbeschreibung_SIEM_v0.1 Seite 5/13 Zusätzlich sollte die Möglichkeit bestehen, Machine Learning (Abgabe von vollständig anony-misierten Daten, verschlüsselt zu übertragen und Analyse der Daten gegen weltweite Daten mit Rückmeldung sonst nicht zu erkennender Bedrohungen) in der Cloud zu nutzen. *siehe 1.6 Visualisierung Dashboards sollten folgende Unterfunktionen bieten: - Statistische Auswertung über einen nutzerdefinierten Filter und Zeitraum mit dynami-schen Updates - Konfigurierbare automatische Aktualisierung - Echtzeitanzeige eingehender Events nach nutzerdefiniertem Filter - Einbetten von Suchanfragen als Dashboardobjekt *siehe 1.7 SOAR Die Lösung sollte an eine SOAR-Lösung angebunden werden können. Falls eine SOAR-Lö-sung vom Anbieter/Dienstleister angeboten werden kann, ist dies als optionales Angebot mit einzupreisen. *siehe 1.8 Real-Time Monitoring Die Lösung sollte im Regelfall Latenzen kleiner sechzig Sekunden, von Eingang eines eine Alarmierung auslösenden Logs bis zur Alarmierung, erreichen. Im Regelfall müssen Logs in-nerhalb von zehn Sekunden gezielt per Query abfragbar sein, z.B. für Live-Debugging eines angebundenen Systems. Es sollte möglich sein die Logverarbeitung, je nach Logquelle, zu priorisieren. 1.9 Alerting Das Alerting sollte, zusätzlich zur Meldung innerhalb der Software, über E-Mail und optional per Webhook, realisierbar sein. Das Alerting muss separiert nach Zielgruppe, Mandant, Kriti-kalität und Uhrzeit konfigurierbar sein. Leistungsbeschreibung_SIEM_v0.1 Seite 6/13 1.10 Reporting Es sollte eine Möglichkeit geben, Informationen und Dashboards der Lösung regelmäßig in automatisiert erstellten Reports zu exportieren und diese Reports per E-Mail zu versenden. Diese Reports müssen sowohl maschinen- wie auch menschenlesbar (z.B.: PDF oder JSON) sein und optional verschlüsselt zur Verfügung gestellt werden. 1.11 Integration Die Lösung muss eine API bereitstellen, die mindestens folgende Kernfunktionen abbildet - Suche wie in der GUI - Export von Reports - Assetpflege, z.B. Import von verantwortlichen Fachteams etc. - Erstellung und Pflege von Logparsern - Erstellung und Pflege von Korrelationsregeln bzw. Use Cases 1.12 Infrastruktur und Skalierbarkeit Die Installation muss in den zwei Rechenzentren der rku.it als voll redundante, on-prem Lö-sung erfolgen. Ausgenommen davon sind die Anforderungen des Abschnittes 1.5 Bedro-hungserkennung. Es sollte möglich sein, sowohl Server-Hardware als auch virtualisierte Res-sourcen zu nutzen. Bei Nutzung virtualisierter Ressourcen müssen entweder VMware und Hyper-V als Hypervisoren oder alternativ OpenShift als Containerumgebung unterstützt wer-den. Bei Lösungen auf Hardware kann diese in Form von Appliances im Angebot enthalten sein; andernfalls müssen die Anforderungen an Hardware bzw. virtualisierte Ressourcen ge-nau spezifiziert sein. Eine Mandantentrennung muss grundsätzlich möglich sein. Auf Softwareebene zwingend. Auf Hardwareebene wird dies als wichtiger positiver Aspekt bewertet. Es muss möglich sein, personenbezogene Daten zu pseudonymisieren. Weitere Einzelheiten entnehmen Sie bitte der Anlage Leistungsbeschreibung

Beschreibung der Beschaffung

Anforderungen an die SIEM-Software Folgende Anforderungen bezüglich Funktionalitäten stellen wir an die Lösung: 1.1 Log Collection Die Lösung muss "elasticsearch" als Data Lake unterstützen. Es sollte das "Common Event Format" (folgend CEF) mit einem standardisierten Parser unterstützen. Es muss zusätzlich möglich sein, eigene Parser für Logs zu erstellen. Die Lösung muss tolerant gegenüber Logs sein, welche Daten enthalten, die die Lösung nicht interpretieren kann (Unterpunkt Log Coll-ection -> Postel"s Law). Die gesamte Lösung muss mandantenfähig sein. Loginformationen einzelner Kunden müssen sauber dargestellt, separiert, exportiert und gelöscht werden kön-nen. Es muss sichergestellt sein, dass der Zugriff von Mandanten ausschließlich auf ihre ei-genen Daten erfolgen kann. Ein zentraler Mandant (Betreiber-Sicht) muss alle Daten korre-lieren können. *siehe 1.2 Betriebssystem-Unterstützung Die Betriebssystemunterstützung der Lösung sollte umfangreich und aktuell sein, sodass die von rku.it betriebenen Server und Clients abgedeckt werden. Leistungsbeschreibung_SIEM_v0.1 Seite 4/13 Derzeit setzen wir im Serverumfeld folgende Betriebssysteme ein, die unterstützt werden müssen: - Windows Server 2022 Standard - Windows Server 2022 Datacenter - Windows Server 2019 Standard - Windows Server 2019 Datacenter - Windows Server 2016 Standard - Windows Server 2016 Datacenter - Windows Server 2012 R2 - Windows Server 2012 - Redhat 7,8,9 x86_x64 - Redhat 8,9 ppc64le - SLES12, SLES15 x86_64 - SLES12, SLES15 ppc64le - AIX 7.1 / 7.2 / 7.3 Im Clientumfeld setzen wir folgende Betriebssysteme ein, die unterstützt werden müssen: - Windows 10 - Windows 11 - Windows 11 Enterprise Multi Session 1.3 Logverwaltung Ergebnisse der Bewertung des SIEMs müssen in einem Format bereitgestellt werden, wel-ches marktüblich (z.B.: in einem standardisierten JSON-Export) ist und von anderen Syste-men interpretiert werden kann. Falls Logs bzw. Events außerhalb des Data-Lakes gespei-chert werden, sollte ein Speichertiering mit Hot-/Cold-/Archiv-Tier implementierbar sein. Ins-besondere sollte die Lösung als Archiv-Tier einen S3-kombatiblen externen Speicher ver-wenden können. Die gespeicherten Logs müssen innerhalb der Lösung um Tags/Attribute erweiterbar sein. *siehe 1.4 Event Correlation / Use Cases Es sollte ein Basisregelwerk verfügbar sein. Es muss möglich sein eigene Use Cases/Regeln zu erstellen und zu importieren. *siehe 1.5 Bedrohungserkennung Die Lösung sollte Events- und Korrelationsregeln mit bekannten CVEs abgleichen und da-raufhin relevante Informationen in der Event- oder Alertbeschreibung mitliefern. Leistungsbeschreibung_SIEM_v0.1 Seite 5/13 Zusätzlich sollte die Möglichkeit bestehen, Machine Learning (Abgabe von vollständig anony-misierten Daten, verschlüsselt zu übertragen und Analyse der Daten gegen weltweite Daten mit Rückmeldung sonst nicht zu erkennender Bedrohungen) in der Cloud zu nutzen. *siehe 1.6 Visualisierung Dashboards sollten folgende Unterfunktionen bieten: - Statistische Auswertung über einen nutzerdefinierten Filter und Zeitraum mit dynami-schen Updates - Konfigurierbare automatische Aktualisierung - Echtzeitanzeige eingehender Events nach nutzerdefiniertem Filter - Einbetten von Suchanfragen als Dashboardobjekt *siehe 1.7 SOAR Die Lösung sollte an eine SOAR-Lösung angebunden werden können. Falls eine SOAR-Lö-sung vom Anbieter/Dienstleister angeboten werden kann, ist dies als optionales Angebot mit einzupreisen. *siehe 1.8 Real-Time Monitoring Die Lösung sollte im Regelfall Latenzen kleiner sechzig Sekunden, von Eingang eines eine Alarmierung auslösenden Logs bis zur Alarmierung, erreichen. Im Regelfall müssen Logs in-nerhalb von zehn Sekunden gezielt per Query abfragbar sein, z.B. für Live-Debugging eines angebundenen Systems. Es sollte möglich sein die Logverarbeitung, je nach Logquelle, zu priorisieren. 1.9 Alerting Das Alerting sollte, zusätzlich zur Meldung innerhalb der Software, über E-Mail und optional per Webhook, realisierbar sein. Das Alerting muss separiert nach Zielgruppe, Mandant, Kriti-kalität und Uhrzeit konfigurierbar sein. Leistungsbeschreibung_SIEM_v0.1 Seite 6/13 1.10 Reporting Es sollte eine Möglichkeit geben, Informationen und Dashboards der Lösung regelmäßig in automatisiert erstellten Reports zu exportieren und diese Reports per E-Mail zu versenden. Diese Reports müssen sowohl maschinen- wie auch menschenlesbar (z.B.: PDF oder JSON) sein und optional verschlüsselt zur Verfügung gestellt werden. 1.11 Integration Die Lösung muss eine API bereitstellen, die mindestens folgende Kernfunktionen abbildet - Suche wie in der GUI - Export von Reports - Assetpflege, z.B. Import von verantwortlichen Fachteams etc. - Erstellung und Pflege von Logparsern - Erstellung und Pflege von Korrelationsregeln bzw. Use Cases 1.12 Infrastruktur und Skalierbarkeit Die Installation muss in den zwei Rechenzentren der rku.it als voll redundante, on-prem Lö-sung erfolgen. Ausgenommen davon sind die Anforderungen des Abschnittes 1.5 Bedro-hungserkennung. Es sollte möglich sein, sowohl Server-Hardware als auch virtualisierte Res-sourcen zu nutzen. Bei Nutzung virtualisierter Ressourcen müssen entweder VMware und Hyper-V als Hypervisoren oder alternativ OpenShift als Containerumgebung unterstützt wer-den. Bei Lösungen auf Hardware kann diese in Form von Appliances im Angebot enthalten sein; andernfalls müssen die Anforderungen an Hardware bzw. virtualisierte Ressourcen ge-nau spezifiziert sein. Eine Mandantentrennung muss grundsätzlich möglich sein. Auf Softwareebene zwingend. Auf Hardwareebene wird dies als wichtiger positiver Aspekt bewertet. Es muss möglich sein, personenbezogene Daten zu pseudonymisieren. Weitere Einzelheiten entnehmen Sie bitte der Anlage Leistungsbeschreibung