Was ich als CISO gerne früher gewusst hätte - 7 Learnings aus der Praxis, die Security wirksamer machen

Es gibt Dinge, die versteht man theoretisch sofort – und spürt sie praktisch erst, wenn man ein paar Runden gedreht hat: Budgetzyklen, Incident-Nächte, schwierige Stakeholder, zu viele Baustellen gleichzeitig.

Als CISO ist man selten „nur“ für Security verantwortlich. Man ist Übersetzer, Priorisierer, Krisenmanager, Architekt, Coach – und manchmal auch derjenige, der unangenehme Wahrheiten aussprechen muss. Rückblickend gab es sieben Punkte, die mir viel Reibung (und einige Umwege) erspart hätten, wenn ich sie früher konsequent gelebt hätte.

Dieser Artikel ist bewusst praxisnah. Keine Theorie, kein Buzzword-Bingo – sondern Prinzipien, die sich in verschiedensten Organisationen bewährt haben.

1) 🧩 Security ist ein Business-Outcome, kein Tool-Stack

Viele Security-Programme starten mit Technologie: EDR, SIEM, CASB, PAM, ZTNA, SASE, XDR … Du kannst damit Jahre füllen – und trotzdem keine spürbare Verbesserung erzielen, wenn der Fokus falsch gesetzt ist.

Der entscheidende Perspektivwechsel: Security ist kein Selbstzweck. Security ist ein Mittel, um Business Outcomes zu verbessern – vor allem:

• Risiko reduzieren (nicht abstrakt, sondern konkret: „Weniger erfolgreiche Kontoübernahmen“, „geringere Ausfallwahrscheinlichkeit“)

• Verfügbarkeit erhöhen (Widerstandsfähigkeit, Wiederherstellbarkeit, Betriebsstabilität)

• Delivery beschleunigen (weniger Blocker, klare Standards, schnelleres Enablement)

Wenn du diese Outcomes nicht messbar verbesserst, wird Security automatisch als Kostenstelle wahrgenommen – egal wie gut deine Tools sind.

Was das praktisch bedeutet

• Formuliere Initiativen als Outcomes, nicht als Tool-Projekte.Nicht: „Wir führen PAM ein.“Sondern: „Wir reduzieren privilegierte Kontoübernahmen und verbessern Containment-Fähigkeit.“

• Verkaufe Security nicht über Angst, sondern über Entscheidungssicherheit:„Hier sind drei Optionen, hier sind Kosten/Nutzen/Risiko – entscheidet.“

  
  

Ein pragmatischer Test

Wenn du einem CFO/COO nur einen Satz sagen dürftest:Welche messbare Verbesserung lieferst du in den nächsten 90 Tagen?Wenn du zögerst, fehlt dir wahrscheinlich noch die Outcome-Story.

2) 🔐 Identity ist der stärkste Hebel

Wenn ich heute eine Security-Organisation neu aufbauen müsste, würde ich nicht mit „Perimeter“ starten. Ich würde mit Identität starten.

Warum? Weil Identität der gemeinsame Nenner fast aller erfolgreichen Angriffe ist:

• Credentials werden abgegriffen, weiterverkauft oder wiederverwendet

• Privilegien werden ausgenutzt (PAM-Lücken, lokale Admins, Service Accounts)

• Tokens werden gestohlen (SaaS/Cloud)

• Legacy-Flows umgehen Kontrollen

• 
  

Identity ist nicht nur ein Bereich – es ist ein Multiplikator.Wenn Identity sauber ist, funktionieren viele andere Controls besser. Wenn Identity unsauber ist, wird alles teurer.

Meine Reihenfolge:

PAM (Privileged Access Management)

• klare Trennung zwischen normalen und privilegierten Konten

• Just-in-Time / Just-enough access wo möglich

• sauberes Break-Glass-Konzept

Phishing-resistente MFA

• für privilegierte Identitäten ist „SMS/OTP“ oft nicht mehr ausreichend

• die Hürde sollte dort am höchsten sein, wo der Schaden am größten ist

Conditional Access / Risk-based Policies

• Zugriff abhängig von Risiko, Gerät, Standort, Session, Compliance

• weniger „one size fits all“, mehr dynamische Steuerung

Was viele unterschätzen

• Service Accounts: häufig unsichtbar, oft zu mächtig, selten gut gemanagt

• Legacy-Protokolle: umgehen moderne Policies

• Token-Lifecycle: Abmeldung/Revocation ist oft nicht sauber gelöst

Mein Merksatz:Wenn du Identity nicht im Griff hast, baust du Security auf Sand.

3) ⚙️ Im Incident entscheidet das Operating Model, nicht das Produkt

In einer Folie sehen Incident-Programme oft perfekt aus. In der Realität entscheidet sich alles an drei Fragen:

• Wer darf isolieren? (Endpoint, Account, Netzwerksegment, SaaS-Session)

• Wer entscheidet? (Security, IT Ops, Produktteam, Management)

• Wer trägt Ownership? (klarer Incident Commander, klare Rollen)

In vielen Unternehmen gibt es Tools, aber im Ernstfall fehlt:

• Berechtigung

• Klarheit

• Routine

• ein eingeübter Ablauf

Und dann wird aus Minuten schnell eine Stunde, aus einer Stunde ein halber Tag.

Woran gute Operating Models erkennbar sind

• Rollen sind klar: Incident Commander, Comms Lead, Forensik, IT Ops, Business Owner

• „Containment Actions“ sind vorab freigegeben (Policy + Playbooks)

• Entscheidungen werden nicht „ausdiskutiert“, sondern nach Plan getroffen

Was ich praktisch etabliere

• Runbooks pro Top-Incident-Typ (Account Compromise, Ransomware, SaaS Breach, Cloud Key Leak)

• Entscheidungsrechte schriftlich (nicht „wir klären das im Ernstfall“)

• Tabletop-Übungen mit IT + Business – nicht nur mit Security

Merksatz:Tools helfen. Aber im Incident gewinnt das Team, das Entscheidungen schnell treffen kann.

4) 📊 8–10 KPIs reichen — Tier-0/1 first

Zu viele KPIs führen fast immer zu einem Effekt:Man optimiert Zahlen statt Sicherheit.

Ich halte es bewusst schlank: 8–10 Steuerungs-KPIs, konsequent auf Tier-0/1 ausgerichtet (Crown Jewels, Identität, kritische Prozesse). Alles andere wird schnell „Reporting“.

Warum Tier-0/1 so wichtig ist

Weil „Durchschnitt“ dich betrügt. 95% Abdeckung klingt gut – bis die 5% genau die Systeme sind, die den größten Impact haben.

Beispiele für Steuerungs-KPIs

• Patch-Tempo auf Tier-0/1

• phishing-resistente MFA auf privilegierten Identitäten

• EDR „healthy“ auf kritischen Systemen

• Logging-Qualität (nicht nur Coverage)

• MTTC (Detection → Containment)

• Restore-Tests (und echte Restore-Zeit)

• Exception-Backlog ohne Enddatum

Ein KPI ist nur dann gut, wenn …

… er eine Aktion auslöst:

• Owner ist klar

• Schwellenwerte sind definiert

• bei „rot“ gibt es eine Standardmaßnahme

Merksatz: Wenn ein KPI nicht zu einer Entscheidung führt, ist er Deko.

5) 🙅‍♂️ Sag seltener „Nein“, häufiger „Ja, wenn…“

Das ist eine der größten Führungslektionen:Ein hartes „Nein“ macht dich schnell zum Bremsklotz – auch wenn du fachlich recht hast.

In der Praxis ist es meist besser, in Optionen zu denken:

• Ja, wenn… wir diese Bedingung erfüllen

• Ja, aber… mit diesen Trade-offs

• Ja, und hier ist die sicherere Alternative

Mein Standardformat: 2 sichere Optionen + Trade-offs

Wenn eine Anfrage riskant ist (Tool, Architektur, Go-Live, Feature), bringe ich zwei Varianten:

• Option A: schneller, mehr Risiko

• Option B: minimal langsamer, deutlich sicherer

• (Optional Option C: „Gold Standard“)

Das schafft:

• Tempo

• Transparenz

• Vertrauen

Merksatz: Security gewinnt durch Enablement – nicht durch Blockade.

6) ⏳ Ausnahmen sind normal – unbegrenzte Ausnahmen sind Risiko

Jedes Unternehmen hat Legacy, Engpässe, Spezialfälle. Security-Exceptions sind nicht das Problem. Das Problem sind Exceptions ohne Ende.

„Nur vorübergehend“ ist die häufigste Lüge in Security-Programmen – oft nicht böse, sondern organisatorisch.

Meine Mindestanforderung für jede Exception

• Owner (eine Person, keine Abteilung)

• Mitigation (was reduziert das Risiko bis zur Lösung?)

• Ablaufdatum (wirklich ein Datum)

• Review-Termin (wenn’s länger dauert)

Alles ohne Enddatum wird automatisch kritisch. Nicht als Strafe – sondern weil sonst niemand priorisiert.

Merksatz: Zeitlich unbegrenzte Ausnahmen sind versteckte Security-Schulden.

7) 🧠 Kommunikation schlägt Perfektion

Die beste technische Lösung bringt nichts, wenn sie nicht verstanden wird.Als CISO ist Kommunikation nicht „nice to have“. Sie ist ein Control.

Die 30-Sekunden-Regel

Wenn du eine Initiative nicht in 30 Sekunden erklären kannst, bekommst du:

• keine Priorität

• kein Budget

• keine echte Unterstützung

Und du verlierst dein Gegenüber.

Was ich in der Praxis nutze

• sehr kurze Executive Summaries: 3 Punkte, 1 Entscheidung

• klare Sprache: kein Jargon, keine Buzzwords

• Story über Impact: „Was passiert, wenn wir nichts tun?“ + „Was gewinnen wir, wenn wir handeln?“

Merksatz:Klarheit ist ein Sicherheitsfaktor. Unklarheit ist Risiko.

Was ich als CISO gerne früher gewusst hätte - 7 Learnings aus der Praxis

Ein pragmatischer Startpunkt: Wenn ich heute neu anfangen würde

Wenn ich heute als CISO in eine neue Organisation käme und schnell Wirksamkeit zeigen müsste, würde ich fokussieren auf:

1. Identity (PAM, phishing-resistente MFA, Conditional Access)

2. Logging/Visibility (kritische Quellen, Qualität, Nutzbarkeit)

3. Restore-Tests (Wiederherstellbarkeit wirklich beweisen)

Das sind die drei Säulen, die am schnellsten:

• Risiko spürbar reduzieren

• Incident-Resilienz erhöhen

• und Vertrauen im Business schaffen

  
  

Danach kann man Tooling und Programme sauber ausbauen – auf einem stabileren Fundament.