Vorgehen
Eine GAP-Analyse in diesem Markt ist meist eines von zwei Dingen: die Bewertung eines Herstellers, die zufällig auf das eigene Produkt hinausläuft, oder ein formales Audit gegen ein einzelnes Framework, das zeigt, ob man compliant ist — nicht, was zuerst zu beheben ist oder was es kostet. Dazu kam ein drittes Problem: Jeder Berater im Team führte GAP-Analysen auf seine eigene Art durch, sodass derselbe Kunde je nach Berater ein anderes Ergebnis bekam. Als Erfinder und Verantwortlicher der Methodik habe ich stattdessen ein wiederverwendbares Framework aufgebaut — fundiert auf anerkannten Standards (NIST CSF, CIS Controls, BSI-Grundschutz), damit die Findings einer Prüfung standhalten, aber getrieben von den eigenen realen Kosten- und Aufwandsdaten des Teams, sodass das Ergebnis ein priorisierter Umsetzungsplan war — kein Scorecard und kein Verkaufsgespräch.
Umsetzung
- Eine gemeinsame Aufwands-/Kostendatenbank aus der eigenen Projekthistorie des Teams aufgebaut — Time-to-Value je Maßnahme (Aufbau eines SOC in Jahren gemessen, Aktivierung von SSL-Decryption in Tagen) sowie eine grobe Kostenbandbreite je Maßnahme, genau genug, um „teuer" von „günstig" zu unterscheiden, nicht so genau, dass daraus eine Budgetierungsübung wurde
- Diese Datenbank genutzt, um GAP-Findings kundenspezifisch neu zu gewichten — dieselben Findings konnten für einen budgetknappen Kunden anders sortiert werden als für einen personalknappen Kunden, statt jedem Kunden dieselbe generische Prioritätenliste zu geben
- Reifegradscoring-Methodik über sechs Domänen entwickelt: Netzwerk, Identity, Cloud, Endpoint, Rechenzentren sowie Remote-Access/VPN
- Interview- und Scoring-Prozess gezielt standardisiert, damit das Ergebnis nicht mehr davon abhing, welcher Berater das Projekt durchführte
- Die Analyse über drei Jahre hinweg rund 45-mal durchgeführt, verteilt auf ein Team von drei Managing Consultants — als ursprünglicher Architekt und Verantwortlicher der Methodik
Ergebnis
Erst die Kosten-/Aufwandsdatenbank machte die Findings umsetzbar statt nur wünschenswert — und die Analyse deckte Dinge auf, die ein Checklisten-Audit nicht fand. In einem Projekt war IAM vollständig eingeführt, aber nie auf die kritischsten Systeme ausgeweitet worden — weil die Administratoren befürchteten, bei einem Fehler den Zugriff zu verlieren. Ein Standard-Audit hätte IAM als „vorhanden" abgehakt und wäre weitergezogen. In einem anderen Fall lief ein neu eingeführtes IPS nur im passiven Monitoring-Modus — sichtbar im Architekturdiagramm, unsichtbar im Audit, ohne jede aktive Schutzwirkung. Solche Findings sind der Grund, warum die Methodik nach operativer Realität priorisierte und nicht danach, was auf dem Papier technisch implementiert war.