CSPM einführen: warum die meisten Teams bei Schritt eins scheitern
Der erste CSPM-Scan in einer gewachsenen Cloud-Umgebung ist ein Erlebnis, das man nicht vergisst. Bei einem Kunden lief er über Nacht durch und warf am Morgen 2.400 Findings aus. Der zuständige Cloud-Engineer schloss das Dashboard, öffnete es wieder, und sagte dann einen Satz, den ich seitdem in fast jedem Projekt höre: „Und jetzt?"
Genau da liegt das Problem. Cloud Security Posture Management einführen ist kein Tool-Kauf, sondern ein Prozess, der ohne klare Reihenfolge innerhalb von drei Monaten zur teuersten Alert-Müllhalde Ihres Unternehmens wird. Ich habe diesen Prozess inzwischen mehrfach begleitet – zweimal ist er ordentlich gegen die Wand gefahren, und aus diesen beiden Projekten stammt das meiste, was hier steht.
Wichtige Erkenntnisse
- Beginnen Sie mit zwei bis drei Cloud-Accounts, nicht mit allen. Ein Big-Bang-Rollout erzeugt mehr Findings, als ein Team abarbeiten kann.
- Die Auswahl des Werkzeugs ist weniger wichtig als die Frage, wer die Findings abarbeitet. Ohne benannte Verantwortliche verpufft jedes noch so gute Dashboard.
- CSPM, CWPP und CIEM lösen unterschiedliche Probleme. Wer alle drei auf einmal einführt, verliert die Übersicht.
- Rechnen Sie mit vier bis acht Wochen allein für die Reduktion von False Positives, bevor die ersten echten Tickets entstehen.
- Ohne Ausnahmen-Register (Suppressions mit Begründung und Ablaufdatum) ist jeder Scan nach sechs Monaten wertlos.
Was CSPM tatsächlich leistet – und was nicht
Die Kurzdefinition kennt inzwischen jeder: CSPM liest kontinuierlich die Konfiguration Ihrer Cloud-Ressourcen aus, vergleicht sie gegen Sicherheitsbaselines und meldet Abweichungen. Öffentlich erreichbare Storage-Buckets, überbreite IAM-Rollen, fehlende Verschlüsselung, offene Verwaltungsports. Das ist der Kern.
Was in den meisten Erklärtexten fehlt: CSPM bewertet Zustände, keine Angriffe. Es sagt Ihnen, dass ein Bucket offen ist. Es sagt Ihnen nicht, ob jemand ihn schon geleert hat. Diese Lücke ist wichtig, weil sie die Erwartungshaltung im Einkauf bestimmt.
Wo CSPM endet und CWPP, CIEM sowie CNAPP anfangen
Diese vier Abkürzungen werden ständig durcheinandergeworfen, und das führt zu falschen Ausschreibungen. Kurz sortiert:
| Kategorie | Fragestellung | Typische Erkenntnis |
|---|---|---|
| CSPM | Ist meine Konfiguration sicher? | S3-Bucket ist öffentlich beschreibbar |
| CWPP | Sind meine Workloads geschützt? | Container-Image enthält kritische Schwachstelle |
| CIEM | Wer darf eigentlich was? | Dienstkonto hat faktisch Administratorrechte |
| CNAPP | Sammelbegriff für all das | Plattform, die CSPM, CWPP und CIEM bündelt |
Mein Rat: Starten Sie mit CSPM allein. CWPP und CIEM lösen echte Probleme, aber sie lösen andere Probleme. Wenn Sie alle drei gleichzeitig ausrollen, haben Sie drei Datenquellen, drei Alert-Ströme und ein Team, das nach zwei Wochen auf Durchzug schaltet. CNAPP ist am Ende oft die vernünftige Zielarchitektur – aber nicht der Einstieg.
Die Einführung in fünf Phasen
Das hier ist die Reihenfolge, die sich bei mir bewährt hat. Sie weicht bewusst von dem ab, was Anbieter in ihren Onboarding-Calls vorschlagen.
Phase 1: Scope festlegen, nicht alles anschließen
Wählen Sie zwei bis drei Accounts oder Subscriptions aus, die repräsentativ sind. Idealerweise einer produktiv, einer in der Entwicklung, einer mit Sonderfällen (Altlasten, Akquisition, Sandbox). Alles andere bleibt zunächst read-only außen vor.
In einem Projekt habe ich stattdessen alle 34 Accounts auf einmal angeschlossen, weil „das Tool skaliert ja". Das Ergebnis: Der Scan dauerte 40 Stunden, die Findings-Seite lud nicht mehr flüssig, und wir haben drei Wochen damit verbracht, technische Limits zu umgehen. Scope-Disziplin ist keine Bürokratie, sie ist Selbstschutz.
Phase 2: Vier Wochen nur lesen
Schließen Sie die Integration an, erlauben Sie ausschließlich lesenden Zugriff, und schalten Sie jede automatische Remediation ab. Vier Wochen. Kein einziger Schreibzugriff.
Warum so lange? Weil Sie in dieser Zeit drei Dinge tun müssen, die niemand gern tut:
- Erkennen, welche der gemeldeten Findings bei Ihnen überhaupt zutreffend sind
- Regeln identifizieren, die in Ihrer Architektur grundsätzlich nicht greifen können
- Eine Gruppierung nach Team und Verantwortlichkeit aufbauen, sonst landet jedes Ticket im Sammelpostfach
Ich habe diese Phase einmal auf zehn Tage verkürzt, weil der Auftraggeber Druck machte. Wir haben anschließend sechs Wochen damit verbracht, Fehlalarme nachträglich zu unterdrücken. Unterm Strich: doppelte Zeit.
Phase 3: Priorisierung, die nicht nach CVSS geht
Die meisten Werkzeuge sortieren Findings nach Schweregrad. Das ist für Cloud-Konfigurationen ein schlechter Kompass, weil ein „kritischer" Befund in einer isolierten Sandbox harmlos ist und ein „mittlerer" in einem öffentlich erreichbaren Produktionsendpunkt nicht.
Bauen Sie stattdessen eine eigene Priorisierung über drei Achsen:
- Erreichbarkeit – ist die Ressource aus dem Internet ansprechbar?
- Datenklassifizierung – liegen dort personenbezogene oder geschäftskritische Daten?
- Faktische Auswirkung – was kann ein Angreifer mit dieser Fehlkonfiguration tatsächlich erreichen? Hier hilft CIEM, auch wenn Sie es noch nicht eingeführt haben: Fragen Sie Ihr Cloud-Team, welche effektiven Berechtigungen an der Ressource hängen.
Alles, was auf allen drei Achsen niedrig ist, wandert in eine Sammelkategorie mit langem Abarbeitungshorizont. Alles, was auf zwei Achsen hoch ist, geht sofort raus.
Phase 4: Verantwortlichkeiten festnageln
Und dann kommt der Teil, an dem CSPM-Einführungen wirklich scheitern. Nicht an der Technik.
Bevor die erste automatische Benachrichtigung rausgeht, muss klar sein, wer sie bekommt. In den meisten Unternehmen sind das drei Gruppen mit unterschiedlichen Interessen: das Cloud- oder Platform-Team, das die Infrastruktur besitzt, das Security-Team, das die Regeln definiert, und bei regulierten Themen die Compliance-Abteilung, die Nachweise braucht. Ohne eine schriftliche Zuordnung, welches Finding an welche Gruppe geht, entsteht der klassische Effekt: Alle sehen die Liste, niemand fühlt sich zuständig, und nach acht Wochen fragt die Geschäftsleitung, warum die Zahl der offenen Befunde steigt statt sinkt.
Phase 5: Remediation und Ausnahmen regeln
Erst jetzt aktivieren Sie Schreibzugriffe – und zwar selektiv. Automatische Korrektur lohnt sich für eine kleine, klar umrissene Menge von Regeln, etwa öffentlich erreichbare Storage-Buckets oder fehlende Verschlüsselung. Alles andere geht als Ticket an Menschen.
Der wichtigste Baustein ist ein Ausnahmen-Register. Jede unterdrückte Regel bekommt drei Felder: Begründung, verantwortliche Person, Ablaufdatum. Ohne Ablaufdatum ist es keine Ausnahme, sondern eine dauerhafte Abschaltung mit Extra-Schritten.
Die Fehler, die ich zweimal gesehen habe
Beide Projekte, die schiefgingen, hatten unterschiedliche Ausgangslagen und exakt dieselben drei Probleme.
Fehlalarme werden nicht als Aufgabe behandelt
Ein False Positive ist Arbeit. Er braucht eine Analyse, eine Entscheidung und einen Eintrag. Teams unterschätzen das regelmäßig um den Faktor drei bis fünf. Planen Sie dafür eigene Kapazität ein, nicht „läuft nebenbei".
Ausnahmen ohne Verfallsdatum
Nach einem halben Jahr hatte ein Team 312 Suppressions angelegt. Keine einzige mit Ablaufdatum. Der Scan lief sauber durch und meldete nichts mehr. Das ist der gefährlichste Zustand überhaupt, weil er Sicherheit vortäuscht.
Niemand hat die Teams geschult
Wenn ein Entwickler zum ersten Mal ein CSPM-Ticket bekommt und nicht weiß, was ein „überbreiter IAM-Policy-Statement" ist, schließt er es entweder falsch oder gar nicht. Zwei Stunden Schulung pro Team, einmalig, sparen später hunderte Stunden Rückfragen.
Werkzeug auswählen: die Checkliste
Die Anbieterlandschaft ist unübersichtlich, und die Funktionslisten ähneln sich. Diese fünf Fragen trennen brauchbare von unbrauchbaren Kandidaten für Ihre Situation:
- Deckt das Werkzeug alle Ihre Cloud-Anbieter ab – und zwar mit derselben Tiefe, nicht mit einem Alibi-Konnektor für den dritten Anbieter?
- Agentless oder Agent? Beides hat Berechtigung, aber agentless ist für den Einstieg deutlich schneller.
- Wie gut lässt sich die Findings-API in Ihr bestehendes Ticket-System und Ihre CI/CD-Pipeline hängen? Ein Werkzeug ohne brauchbare API erzeugt Inselwissen.
- Was kostet es pro Ressource, und wie zählt der Anbieter? Die Abrechnung nach „Ressourcen" kann bei containerisierten Umgebungen böse Überraschungen produzieren.
- Können Sie Regeln selbst schreiben, ohne beim Anbieter einen Änderungsantrag zu stellen?
Preislich bewegen sich die meisten Angebote im Bereich von 10 bis 40 Euro pro Monat und Cloud-Account für kleinere Umgebungen; bei Enterprise-Verträgen wird stattdessen nach Ressourcen oder Workloads abgerechnet. Holen Sie zwei Angebote und lassen Sie sich die Zählweise schriftlich geben.
Wie lange das wirklich dauert
Für eine Umgebung mit drei bis zehn Accounts und einem Team von fünf bis zehn Personen:
- Werkzeugauswahl und Vertrag: 4 bis 8 Wochen, wenn Einkauf und Rechtsabteilung mitspielen
- Technische Integration und erste Scans: 1 bis 2 Wochen
- Lese- und Triage-Phase: 4 Wochen
- Priorisierung und Verantwortlichkeitsklärung: 2 bis 3 Wochen
- Erste automatische Remediation: ab Woche 12
Ein vollständig stabiles Setup erreichen die meisten Teams irgendwo zwischen Monat vier und Monat sechs. Wer Ihnen drei Wochen verspricht, verkauft Ihnen einen Scan, keine Einführung.
Der eigentliche Knackpunkt liegt außerhalb des Dashboards
CSPM ist technisch kein schwieriges Produkt. Die Integration ist an einem Nachmittag erledigt, die erste Auswertung liegt am nächsten Morgen vor. Alles danach ist Organisationsarbeit: entscheiden, wer welche Befunde bearbeitet, welche Regeln für die eigene Architektur überhaupt Sinn ergeben und wann eine Ausnahme ausläuft.
Die Frage, die ich am Ende jedes Projekts stelle, ist deshalb nicht „wie viele Findings haben wir geschlossen". Sondern: Wenn die Person, die das CSPM heute betreut, morgen kündigt – läuft es dann weiter? Wenn die Antwort nein lautet, ist das Werkzeug eingeführt und der Prozess nicht.
