[Seite 1]
| lfd. Nr. | Bewerber-/ Bieterfrage | Antwort Universität Hamburg | Eingang am | Antwort am | |
|---|---|---|---|---|---|
| 1 | Netzwerksensorik / Open Source-Anteil Bezug: Kapitel 2.2 "Security Operation Center" In der Leistungsbeschreibung wird die "Beistellung von Netzwerksensorik inkl. aktivem Monitoring auf Basis eines souveränen Technologiestacks (im Kern Open Source, im Sourcecode auditierbar)" gefordert. Im SOC-Umfeld kommen für die Anbindung von Datenquellen an das SIEM-System üblicherweise herstellerspezifische Datenconnectoren bzw. Sensoren zum Einsatz. Diese basieren häufig auf kommerziellen Produkten und können Open-Source- Komponenten enthalten. Frage: Bezieht sich die Forderung nach einem "im Kern Open Source, im Sourcecode auditierbaren Technologiestack" ausschließlich auf enthaltene Open-Source-Komponenten innerhalb der Lösung oder muss die vollständige Software der eingesetzten Netzwerksensorik bzw. Datenconnectoren als Open Source verfügbar und auditierbar sein? | Es bezieht sich auf das, was in inhaltlicher eigener Verantwortung als Teil des SOC Stacks betrieben wird. | 31.08.2026 | 07.09.2026 | |
| 2 | Agenten zur Informationsgewinnung Bezug: Informationsgewinnung auf Servern und Endpunkten Für die Erhebung sicherheitsrelevanter Informationen werden üblicherweise Agenten auf Servern und Endpunkten eingesetzt. Frage: Ist die Installation zusätzlicher Agenten auf den Systemen des Auftraggebers zulässig und gewünscht? Falls ja, bestehen Vorgaben hinsichtlich der unterstützten Betriebssysteme, der maximal zulässigen Ressourcenbeanspruchung oder der Anzahl der zu überwachenden Systeme? | Die Installation von Agenten ist überwiegend möglich. Nach Möglichkeit sollten mehrere Lösungsansätze unterstützt werden. Agentenlose Lösungen (z.B. WEF) oder solche die mit bereits im Einsatz befindlichen Agenten (z.B. NXLog) kompatibel sind, wären vorteilhaft, da die Reduktion von Agenten auf Systemen die Komplexität verringert. Die Art der über die verschiedenen Hochschulen eingesetzten Betriebssysteme kann stark variieren. Zu der Ressourcenbeanspruchung und der Anzahl der zu Überwachenden Systeme ist bislang keine Vorgabe gefallen. Eine geringere Ressourcenbeanspruchung bei gleicher Leistung ist besser. | 31.08.2026 | 07.09.2026 | |
| 3 | SIEM-Connectoren und benötigte Infrastruktur Bezug: Anbindung von Datenquellen an das SIEM Für die Anbindung der relevanten Datenquellen an das SIEM-System können Connectoren, Collector-Systeme oder Sensoren erforderlich sein. Frage: Kann der Auftraggeber Angaben zur erwarteten Anzahl der anzubindenden Datenquellen bzw. SIEM-Connectoren machen? Darüber hinaus wird um Klarstellung gebeten, ob die hierfür erforderliche Hardware beziehungsweise virtuelle Infrastruktur durch den Auftraggeber bereitgestellt wird oder Bestandteil der Leistung des Auftragnehmers ist. | Hierzu kann derzeit keine genaue Größe angegeben werden, da dieses Projekt hochschulübergreifend ist. Erforderliche (virtuelle) Hardware über den RZ-Standard der Hochschulen (z.B. virtuelle Maschinen, Netzwerkzugänge, Speicher, Firewall-Freigaben) hinaus (z.B. Appliances, Sensoren) sind Leistungsbestandteil. | 31.08.2026 | 07.09.2026 |
Seite 1 von 3 Stand: 07.09.2026
[Seite 2]
| lfd. Nr. | Bewerber-/ Bieterfrage | Antwort Universität Hamburg | Eingang am | Antwort am | |
|---|---|---|---|---|---|
| 4 | Domain-Controller und sicherheitsrelevante Systeme Bezug: Integration in die bestehende IT-Landschaft Frage: Ist eine Anbindung beziehungsweise Datenerfassung von Domain-Controllern und weiteren zentralen Infrastrukturkomponenten (z.B. Active Directory, DNS, DHCP, Fileserver) vorgesehen? Falls ja, wird um Angabe der Anzahl der Systeme sowie der gewünschten Erfassungs- bzw. Monitoring-Tiefe gebeten. | Ja, die Anbindung bzw. Datenerfassung ist vorgesehen. Die Anzahl der Systeme kann zum gegenwärtigen Zeitpunkt nicht mitgeteilt werden, da dies hochschulübergreifend variiert. | 31.08.2026 | 07.09.2026 | |
| 5 | Gemäß Ziffer 14 der Vergabeunterlagen sind für die Referenznachweise unter anderem Angaben zum Auftraggeber zu machen. Da die ausgeschriebenen Leistungen sicherheitskritische Bereiche wie Security Operations Center (SOC), Incident Response, CERT- Dienstleistungen, SIEM-Betrieb und Vulnerability Management betreffen, unterliegen entsprechende Referenzprojekte häufig besonderen Vertraulichkeits- und Sicherheitsanforderungen. Es wird daher um Bestätigung gebeten, dass Referenzen zum Schutz vertraulicher Kunden- und Sicherheitsinformationen anonymisiert eingereicht werden dürfen, sofern die Vergleichbarkeit der Referenz hinsichtlich Leistungsinhalt, Umfang, Komplexität, Vertragsvolumen und Auftraggebertyp weiterhin nachvollziehbar dargestellt wird. Falls eine vollständige Anonymisierung nicht zulässig sein sollte, wird um Mitteilung gebeten, in welchem Umfang eine Pseudonymisierung des Auftraggebers akzeptiert wird. | Eine Anonymisierung kann erfolgen. Es muss jedoch eindeutig nachvollziehbar sein, in welcher Branche mit welchen Kennzahlen im Detail die Referenz verortet ist. | 27.08.2026 | 07.09.2026 | |
| 6 | Gemäß Ziffer 14 der Vergabeunterlagen werden Referenzen über vergleichbare Leistungen der letzten drei Jahre aus dem universitären bzw. wissenschaftlichen Auftraggeberumfeld, dem Umfeld öffentlicher Auftraggeber oder anderer Auftraggeber als grundsätzlich geeignete Referenzen anerkannt. Gleichzeitig wird gefordert, dass mindestens eine Referenz zwingend aus dem Bereich Hochschulen stammen muss. Zudem führt die Nichterfüllung dieser Anforderung zum Ausschluss vom Verfahren. Wir bitten um Erläuterung, welche konkreten hochschulspezifischen Besonderheiten des ausgeschriebenen Leistungsgegenstandes die Forderung rechtfertigen, dass mindestens eine Referenz zwingend aus dem Hochschulbereich stammen muss. Nach unserem Verständnis handelt es sich bei den ausgeschriebenen Leistungen um branchenübergreifend erbringbare IT- Sicherheitsleistungen, insbesondere Managed Security Services, Security Operations Center (SOC), SIEM-Betrieb, Incident Response, CERT-Dienstleistungen, Threat Intelligence sowie Vulnerability Management. Vergleichbare technische, organisatorische und sicherheitsrelevante Anforderungen können ebenso bei anderen öffentlichen Auftraggebern, wissenschaftlichen Einrichtungen sowie Unternehmen außerhalb des Hochschulumfelds bestehen. Vor diesem Hintergrund erscheint nicht ohne Weiteres nachvollziehbar, weshalb die erforderliche fachliche und technische Leistungsfähigkeit ausschließlich durch eine Hochschulreferenz nachgewiesen werden kann und nicht gleichermaßen durch hinsichtlich Leistungsgegenstand, Komplexität, Organisationsgröße und Betriebsanforderungen vergleichbare Referenzprojekte aus anderen Bereichen. Wir bitten daher zu prüfen, ob die Anforderung dahingehend angepasst werden kann, dass anstelle einer zwingenden Hochschulreferenz auch Referenzen aus anderen Auftraggeberumfeldern anerkannt werden, sofern diese hinsichtlich Leistungsinhalt, Umfang und Komplexität mit dem ausgeschriebenen Leistungsgegenstand vergleichbar sind. Dies würde aus unserer Sicht den Wettbewerb fördern und gleichzeitig eine ausreichende Prüfung der technischen und beruflichen Leistungsfähigkeit gewährleisten. | Hochschulen, Universitäten stellen in ihrem technischen Gefüge, den verwendeten Methoden, dem Kompetenzgefüge aber auch ihren Governance-Strukturen besondere Einrichtungen dar. Die ensprechende Implementierung und der Betrieb eines SOC bedürfen sowohl im Verständnis als auch bei der Operationalisierung entsprechende Erfahrungen, da gerade in diesem Umfeld sonst Risiken steigen und Aufwände unverhältnismäßig hoch werden. Hochschulen verbinden die Anforderungen von öffentlichen Auftraggebern, wissenschaftlichen Einrichtungen und Unternehmen außerhalb des Hochschulumfelds je nach Anwendungskontext und stellen damit insgesamt eine eigene und spezielle Komplexitätsklasse dar. Die Referenzen sollen eine Leistungsfähigkeit unter vergleichbaren Bedingungen glaubhaft machen. Vor diesem Hintergrund ist eine Forderung nach mindestens einer Referenze, insbesondere vor dem Hintergrund der Komplexität dieses neuartigen Projekts für die Hamburger Hochschulen, im Hochschulbereich notwendig. | 27.08.2026 | 07.09.2026 |
Seite 2 von 3 Stand: 07.09.2026
[Seite 3]
| lfd. Nr. | Bewerber-/ Bieterfrage | Antwort Universität Hamburg | Eingang am | Antwort am | |
|---|---|---|---|---|---|
| 7 | Aus den Vergabeunterlagen geht hervor, dass die Plattform in den Rechenzentren der Hochschulen betrieben werden soll. Ist der Betrieb der Lösung in den Rechenzentren der Hochschulen zwingend vorgeschrieben, oder sind alternativ auch Cloud- basierte Betriebsmodelle zulässig, sofern die Anforderungen an Datenschutz, Informationssicherheit, Datenhaltung und Compliance vollständig erfüllt werden? | Der Betrieb der Lösung auf IT-Infrastruktur der Hochschulen oder auf der eigenen Infrastruktur des Dienstleisters im eigenen DataCenter ist zulässig. | 28.08.2026 | 07.09.2026 | |
| 8 | Nach unserem Kenntnisstand ist beim Auftraggeber bereits eine gemanagte Detection-and-Response-Lösung mit angebundenem Analystenbetrieb lizenziert und im Einsatz. Zur wirtschaftlichen Bewertung bitten wir um Auskunft: Welche Leistungsbestandteile der Ausschreibung werden durch die bestehende Lizenzierung nachweislich nicht abgedeckt? Ist eine Anrechnung oder Aufwertung des Bestands (Upgrade auf eine höhere Servicestufe) als Angebotsvariante zugelassen? Wie wird bei der Wertung berücksichtigt, dass ein Parallelbetrieb zweier Detection-Stacks doppelte Lizenz-, Integrations- und Betriebskosten sowie redundante Alarmierung erzeugt? Wir bitten zudem um Bestätigung, dass Nebenangebote auf Basis der vorhandenen Plattform zugelassen sind. | Gegenstand dieser Vergabe sind durch die BWFG geförderte Managed Security Services sowie der Aufbau und Betrieb eines an der UHH angesiedelten Security Operations Centers (SOC) und weiterer IT-Security- relevanter Dienstleistungen für die beteiligten staatlichen Hamburger Hochschulen, vgl. Ziff. 10ff. der Unterlage Aufforderung zur Teilnahme am Wettbewerb und Verfahrensbedingungen bzw. Leistungsbeschreibung und Vertragsbedingungen ENTWURF ab Ziff. 2ff. Wir suchen daher einen leistungsstarken Dienstleister, der uns beim Aufbau und dauerhaften Betrieb unterstützt. Etwaige Aufwertungen von ggf. bisher rudimentär genutzten Systemen sind explizit nicht Teil dieses Vergabeverfahrens, da ein dauerhafter SOC-Betrieb zukunftsfähig aufgebaut werden muss. Nebenangebote sind daher nicht möglich und sind ausgeschlossen (vgl. § 35 Abs. 1. VgV und Ziff. 7 der Unterlage Aufforderung zur Teilnahme am Wettbewerb und Verfahrensbedingungen). | 02.09.2026 | 07.09.2026 |
Seite 3 von 3 Stand: 07.09.2026