Anforderungsprofil: Security & Cyberresilienz
Herstellerneutrales technisches Anforderungs- und Beschaffungspaket zum Entscheidungspaket „Security & Cyberresilienz“.
Am Ende stehen ein priorisiertes Security-Zielbild, nachgewiesene Schutz- und Detection-Bausteine, klare Incident-Verantwortung, ein getesteter Restore-/Break-Glass-Pfad und ein geübter Minimalbetrieb.
Thema: security · Stand 2026-09-21Welle 1 · Netzwerk & Schutzbasis
Routing, Segmentierung, Switching und eine belastbare Security-Basis zuerst als gemeinsame Control- und Failure-Domain festlegen.
Vor jeder Punktebewertung nachweisen
Diese Kriterien sind als technische Mindestnachweise formuliert. Nicht erfüllte Muss-Kriterien sollten nicht durch Komfort- oder Preisvorteile kompensiert werden.
| ID | Kriterium | Geforderter Nachweis |
|---|---|---|
| M01 | Abdeckung von Identitäten, Endpoints, Servern, Cloud-Diensten und Netzwerk-Telemetrie gegen ein vollständiges Asset-Inventar prüfen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M02 | Festlegen, wer Alarme triagiert, untersucht und Maßnahmen ausführt – inklusive 24/7-Zeiten, Eskalation und Reaktions-SLA. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M03 | Logquellen, Aufbewahrung, Datenschutz und Detection-Use-Cases mit einem realen Proof of Concept validieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M04 | Rollout-, Ausnahme-, Isolation- und Wiederherstellungsprozesse mit IT-Betrieb und Helpdesk operationalisieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M05 | Datenstandort, Auftragsverarbeitung, Exit/Export, Vertragslaufzeit und tatsächliche Lizenzmetriken vor Vertragsabschluss prüfen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
Mehrwert nur mit realem Betriebsnutzen bewerten
| ID | Kriterium | Bewertungshinweis |
|---|---|---|
| K01 | Korrelierte Security-Sicht kann Identitäts-, Endpoint-, Server-, Cloud- und Netzsignale mit Asset-Kritikalität zusammenführen. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K02 | Isolation, Remediation oder Containment lassen sich kontrolliert, protokolliert und bei Bedarf mit Freigabepunkten ausführen. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K03 | Exposure-/Vulnerability-Kontext unterstützt die Priorisierung technischer Lücken nach tatsächlicher Erreichbarkeit und Kritikalität. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K04 | Co-Managed-/MDR-Optionen können klar abgegrenzte 24/7-Aufgaben übernehmen, ohne Telemetrie, Incident-Daten oder Entscheidungsrechte zu verschleiern. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
Fragen für Angebot, Workshop und technische Klärung
Sind kritische Identitäten, Endpoints, Server, Cloud-Dienste und Netze einem nachvollziehbaren Schutz- und Telemetriepfad zugeordnet?
Werden priorisierte Angriffsszenarien reproduzierbar erkannt und mit verwertbarem Kontext an die zuständige Rolle übergeben?
Sind Triage, Eskalation, Isolation, Freigabe und Wiederaufnahme als geübte Abläufe mit klaren Verantwortlichkeiten definiert?
Ist mindestens ein kritischer Dienst unter realistischen Bedingungen wiederhergestellt und fachlich abgenommen worden?
Existieren kontrollierte Not- und Break-Glass-Pfade, wenn normale Identity- oder Managementwege ausfallen?
Sind Ausnahmen, Alarmqualität, Coverage-Gaps, Maßnahmen und Wiederholungsübungen als laufender Prozess verankert?
Gates als objektive Abnahmekriterien verwenden
Für die priorisierten Verwaltungsleistungen sind technische Abhängigkeiten, Owner und die wichtigsten Ausfall-/Angriffsszenarien benannt.
Kritische Assets haben einen dokumentierten Schutzpfad; offene Lücken besitzen Risiko, Owner, Maßnahme und Termin.
Mindestens ein priorisiertes Angriffsszenario wird reproduzierbar erkannt, bewertet, eskaliert und mit dokumentierten Reaktionsschritten bearbeitet.
Ein kritischer Dienst wurde aus dem vorgesehenen Schutzpfad wiederhergestellt und fachlich abgenommen; Notzugänge sind kontrolliert und unabhängig verfügbar.
Die Übung erzeugt konkrete Verbesserungsmaßnahmen mit Owner und Termin; Schutz, Detection, Response und Recovery sind als gemeinsame Betriebskette dokumentiert.
Vor Produktivsetzung klären
- Coverage, Sensor-/Agent-Health und Telemetrielücken je kritischem Asset kontinuierlich überwachen.
- Detection-, Ausnahme- und Reaktionsregeln mit Owner, Testfall, Review-Cadence und kontrolliertem Rollback betreiben.
- Incident-Rollen, 24/7-/On-Call-Grenzen, Eskalationskontakte und Break-Glass-Zugänge regelmäßig üben und überprüfen.
- Security-Gaps, Patch-/Vulnerability-Risiken, Restore-Nachweise und Maßnahmenstatus in einem gemeinsamen Betriebsreview fortschreiben.
Vor Vertragsbindung nachweisen
- Policies, Ausnahmen, Sensor-/Agent-Konfiguration, Incident-Nachweise, relevante Telemetrie und Response-Runbooks exportierbar bzw. reproduzierbar halten.
- Parallelbetrieb/Cutover auf eine Folgelösung mit überprüfter Coverage und ohne unkontrollierte Detection-Blindspots planen.
- Agenten, Service Principals, API-Schlüssel, Cloud-/Tenant-Bindungen und privilegierte Integrationen nach Migration vollständig und nachweisbar zurückbauen.
Gewichtete Bewertung erst nach den Muss-Kriterien
Die Gewichte ergeben zusammen 100 %. Die Skala bewertet nachgewiesene Eignung – nicht Herstellergröße oder Markenpräferenz.
| Kategorie | Gewicht | Skala | Dokumentation |
|---|---|---|---|
| Security Architecture & Coverage | 25 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Detection & Response | 25 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Resilience & Recovery | 20 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Operations & Governance | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Commercial & Exit | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
Für Pilot, Entscheidung und Vertrag dokumentieren
- Kritische-Leistungen-Matrix
- Asset-/Service-Abhängigkeitsübersicht
- Security-Gap-Backlog
- Detection-Testprotokoll
- Incident-RACI und Runbooks
- Restore-Protokoll
- Break-Glass-Verfahren
- Minimalbetriebsplan
- Krisenkommunikationsvorlage
- 90-Tage-Folgemaßnahmen