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