Effektivität des Security-Champion-Programms messen

„Woher wissen wir, dass das Sicherheitsprogramm funktioniert?" Diese Frage kommt von der Unternehmensführung, und sie verdient eine echte Antwort. Vage Antworten wie „Wir sind sicherer" reichen nicht. Sie benötigen konkrete Metriken, die Fortschritte zeigen, Probleme identifizieren und weitere Investitionen rechtfertigen.

Dieses Kapitel behandelt, was zu messen ist, wie man es misst, Dashboards erstellt, die eine Geschichte erzählen, und der Unternehmensführung so berichtet, dass es Aufmerksamkeit und Unterstützung erhält.

Warum Messung wichtig ist

Ohne Metriken fliegen Sie blind:

Für Sie:

• Können nicht feststellen, ob Initiativen funktionieren
• Wissen nicht, wo man den Aufwand fokussieren soll
• Können nicht effektiv priorisieren
• Kein Weg, Fortschritte zu zeigen

Für die Unternehmensführung:

• Kann Sicherheitsausgaben nicht rechtfertigen
• Kann nicht mit Branchenbenchmarks vergleichen
• Keine Sichtbarkeit der Risikolage
• Sicherheit fühlt sich wie eine Blackbox an

Für das Team:

• Keine Ziele, auf die man hinarbeiten kann
• Keine Anerkennung für Verbesserungen
• Kein Feedback zu dem, was wichtig ist
• Sicherheit fühlt sich undankbar an

Die richtigen Metriken machen Sicherheit sichtbar, messbar und handhabbar.

Was eine gute Sicherheitsmetrik ausmacht

Nicht alle Metriken sind nützlich. Gute Sicherheitsmetriken sind:

Merkmal	Warum es wichtig ist	Beispiel
Umsetzbar	Sie können etwas dagegen unternehmen	„% der innerhalb des SLA gepatchten Systeme" (kann verbessert werden) vs. „Anzahl versuchter Angriffe" (kann nicht kontrolliert werden)
Messbar	Sie können es tatsächlich zählen	„Mittlere Zeit bis zur Behebung kritischer Schwachstellen" (messbar) vs. „Sicherheitskultur" (vage)
Relevant	Verbindet sich mit echtem Risiko	„% der Mitarbeiter mit MFA" (schützt vor Konto-Kompromittierung) vs. „Sicherheitsschulungsstunden" (Aktivität, kein Ergebnis)
Vergleichbar	Kann im Zeitverlauf verfolgt werden	Gleiche Definition jedes Quartal ermöglicht Trendanalyse
Verständlich	Unternehmensführung kann es erfassen	„3 kritische Schwachstellen in Produktion" vs. „CVSS-Gesamtpunktzahl von 7,2"

Eitelkeitsmetriken vs. echte Metriken

Eitelkeitsmetriken sehen gut aus, treiben aber keine Entscheidungen:

• Anzahl der eingesetzten Sicherheits-Tools
• Insgesamt blockierte Phishing-E-Mails
• Geleistete Sicherheitsschulungsstunden
• Anzahl der geschriebenen Richtlinien

Echte Metriken zeigen den tatsächlichen Sicherheitsstatus:

• Prozentsatz der innerhalb des SLA behobenen kritischen Schwachstellen
• Phishing-Simulations-Klickrate (und Trend)
• Zeit bis zur Erkennung und Reaktion auf Vorfälle
• Prozentsatz der Systeme mit aktuellen Patches

Frühindikatoren vs. Spätindikatoren

Diese Unterscheidung ist wichtiger, als die meisten Security Champions erkennen.

Spätindikatoren zeigen, was bereits passiert ist:

• Anzahl der Sicherheitsvorfälle
• Erkannte Einbrüche
• In Produktion gefundene Schwachstellen
• Compliance-Audit-Fehler

Frühindikatoren sagen zukünftige Probleme voraus:

• Prozentsatz der Projekte mit Threat Modeling
• Sicherheitstest-Abdeckung in CI/CD
• In sicherem Coding geschulte Entwickler
• Abgeschlossene Drittanbieter-Risikobewertungen
• Sicherheitsanforderungen in neuen Projektspezifikationen

Typ	Beispiel	Warum es wichtig ist
Spät	5 Vorfälle dieses Quartal	Zeigt vergangene Probleme, aber zu spät, um sie zu verhindern
Früh	80 % der PRs haben Sicherheits-Review	Sagt weniger Vorfälle nächstes Quartal voraus
Spät	12 Schwachstellen in Produktion gefunden	Schaden bereits möglich
Früh	95 % der Schwachstellen in CI/CD abgefangen	Probleme vor Produktion gestoppt

Experteneinblick: Die meisten Organisationen messen nur Spätindikatoren. Sie sind leicht zu zählen, erzählen aber von gestern. Frühindikatoren erfordern mehr Aufwand für Definition und Tracking, sind aber die, die tatsächlich Verbesserungen vorantreiben.

Eine ausgewogene Scorecard enthält beides:

• Spät: um Ergebnisse zu messen und Auswirkungen nachzuweisen
• Früh: um Trends vorherzusagen und frühzeitig gegenzusteuern

Kernmetriken für Security Champions

Beginnen Sie mit diesen grundlegenden Metriken. Sie sind messbar, umsetzbar und für die Unternehmensführung bedeutungsvoll.

1. Schwachstellenmanagement-Metriken

Metrik	Was sie misst	Ziel	Wie zu erfassen
Offene kritische/hohe Schwachstellen	Aktuelles Risikoexposure	0 kritisch, weniger als 10 hoch	Schwachstellen-Scanner, Issue-Tracker
Mittlere Zeit bis zur Behebung (MTTR)	Wie schnell Sie Probleme beheben	Unter 7 Tage kritisch, unter 30 Tage hoch	Von Entdeckung bis Schließung verfolgen
Patch-Compliance-Rate	Systeme auf dem neuesten Stand	>95 % innerhalb des SLA	Patch-Management-Tool
Schwachstellendichte	Probleme pro Codebasis-Größe	Abnehmender Trend	SAST-Tools (Befunde pro KLOC)
Alter der ältesten Schwachstelle	Vernachlässigte Probleme	Unter 30 Tage für kritisch	Issue-Tracker-Abfrage

Wie MTTR zu berechnen ist:

MTTR = Sum of (Closure Date - Discovery Date) for all vulns / Number of vulns

Example:
- Vuln A: Discovered Jan 1, Fixed Jan 5 = 4 days
- Vuln B: Discovered Jan 3, Fixed Jan 10 = 7 days  
- Vuln C: Discovered Jan 5, Fixed Jan 8 = 3 days

MTTR = (4 + 7 + 3) / 3 = 4.67 days

2. Zugangs- und Authentifizierungsmetriken

Metrik	Was sie misst	Ziel	Wie zu erfassen
MFA-Adoptionsrate	Kontoschutz	100 % für kritische Systeme	Identity-Provider-Admin-Konsole
Konten mit MFA	Gesamte MFA-Abdeckung	>95 % aller Konten	IdP-Dashboard
Privilegierte Kontenanzahl	Admin-Sprawl	Minimum notwendig	IAM-Audit
Verwaiste Konten	Zugriffsbereinigung	0	Regelmäßige Zugriffsüberprüfungen
Fehlgeschlagene Login-Versuche	Potenzielle Angriffe	Basis + Alarme für Spitzen	Auth-Protokolle

Beispiel-MFA-Tracking-Dashboard:

MFA Adoption by Service — March 2025

Service              Users    With MFA    Rate
─────────────────────────────────────────────
Google Workspace      45        45       100%
GitHub                32        32       100%
AWS Console           12        12       100%
Slack                 45        43        96%
Salesforce            18        15        83%  ← Action needed
Jira                  38        38       100%
─────────────────────────────────────────────
Total                190       185        97%

3. Vorfallmetriken

Metrik	Was sie misst	Ziel	Wie zu erfassen
Anzahl der Vorfälle	Problemvolumen	Trend nach unten im Zeitverlauf	Vorfall-Tracker
Mittlere Zeit bis zur Erkennung (MTTD)	Wie schnell Sie es bemerken	Unter 1 Stunde für kritisch	Vorfall-Protokolle
Mittlere Zeit bis zur Reaktion (MTTR)	Wie schnell Sie handeln	Unter 4 Stunden für kritisch	Vorfall-Protokolle
Mittlere Zeit bis zur Auflösung	Vollständige Behebung	Unter 24 Stunden für kritisch	Vorfall-Protokolle
Vorfälle nach Schweregrad	Risikoverteilung	Weniger kritisch im Zeitverlauf	Vorfall-Tracker
Vorfälle nach Kategorie	Mustererkennung	Identifiziert Fokusbereiche	Vorfall-Tracker

Beispiel für Vorfall-Trends:

Incidents by Severity — 2024

        Q1    Q2    Q3    Q4    Trend
        ──    ──    ──    ──    ─────
Critical  2     1     1     0      ↓
High      5     4     3     2      ↓
Medium    8    10     7     5      ↓
Low      12    15    11     8      ↓
        ──    ──    ──    ──
Total    27    30    22    15      ↓

Notes:
- Q2 spike due to Log4j-related incidents
- Q4 improvement reflects patch automation

4. Schulungs- und Awareness-Metriken

Metrik	Was sie misst	Ziel	Wie zu erfassen
Schulungsabschlussrate	Compliance	100 % für Pflichtschulungen	LMS oder Tracking-Tabelle
Phishing-Simulations-Klickrate	Awareness-Effektivität	Unter 5 %, abnehmend	Phishing-Simulations-Tool
Phishing-Melderate	Mitarbeiterwachsamkeit	>50 % der simulierten Phishes	Phishing-Tool
Gestellte Sicherheitsfragen	Engagement	Trend nach oben	Slack-Kanal-Analysen
Richtlinien-Anerkennungsrate	Richtlinien-Bewusstsein	100 %	HR-System oder Formular

Phishing-Simulations-Tracking:

Phishing Simulation Results — 2024

Campaign          Sent    Clicked    Rate    Reported    Report Rate
────────────────────────────────────────────────────────────────────
Jan: Fake DocuSign  45        8      18%         12         27%
Mar: IT Password    45        5      11%         18         40%
May: Delivery       45        4       9%         22         49%
Jul: LinkedIn       45        3       7%         25         56%
Sep: Invoice        45        2       4%         28         62%
Nov: Holiday        45        2       4%         30         67%
────────────────────────────────────────────────────────────────────
Trend                         ↓ 14 pts         ↑ 40 pts

Goal: Click rate under 5%, Report rate over 50% ✓

5. Sicherheitshygiene-Metriken

Metrik	Was sie misst	Ziel	Wie zu erfassen
Endpoint-Schutz-Abdeckung	Gerätesicherheit	100 %	EDR/AV-Dashboard
Verschlüsselung im Ruhezustand	Datenschutz	100 % für sensible Daten	Cloud-Konsole-Audit
Backup-Erfolgsrate	Wiederherstellungsfähigkeit	>99 %	Backup-System-Protokolle
Secret-Scanning-Alarme	Offengelegte Anmeldedaten	0 unbehandelt	GitHub/GitLab-Sicherheits-Tab
Abhängigkeits-Schwachstellen	Supply-Chain-Risiko	0 kritisch, unter 10 hoch	Dependabot, Snyk

Ein Sicherheits-Dashboard erstellen

Ein Dashboard verwandelt rohe Metriken in eine Geschichte. Das richtige Dashboard beantwortet „Wie läuft es bei uns?" auf einen Blick.

Dashboard-Designprinzipien

1. Zielgruppengerecht:

• Führungskräfte-Dashboard: 5–7 hochrangige Metriken
• Sicherheitsteam-Dashboard: Detaillierte operative Metriken
• Entwickler-Dashboard: Code- und Abhängigkeitsmetriken

2. Trend-fokussiert:

• Veränderung im Zeitverlauf zeigen, nicht nur aktuellen Status
• Pfeile, Farben oder Sparklines für Trends verwenden
• Mit vorheriger Periode vergleichen

3. Umsetzbar:

• Links zu Details für Untersuchungen
• Hervorheben, was Aufmerksamkeit benötigt
• Nächste Schritte offensichtlich machen

4. Ehrlich:

• Schlechte Nachrichten nicht verstecken
• Kontext für Anomalien zeigen
• Cherry-picking guter Metriken vermeiden

Führungskräfte-Dashboard-Vorlage

Sicherheits-Dashboard — März 2025 · Gesamtstatus: GUT (8/10 Metriken im Zielbereich)

Kritische Metriken:

Metrik	Wert	Ziel	Status
Offene kritische Schwachstellen	0	0	✓ OK
MFA-Adoption	97 %	95 %	✓ OK
Phishing-Klickrate	4 %	unter 5 %	✓ OK
MTTR kritisch	2,5 T.	unter 7 T.	✓ OK
Salesforce-MFA	83 %	100 %	⚠ Aktion erforderlich
Schulungsabschluss	88 %	100 %	⚠ Aktion erforderlich

Trends vs. letztem Quartal: Sicherheitsvorfälle 15 → 12 (−20 %) · Behobene Schwachstellen 45 → 52 (+16 %) · Mittlere Zeit bis zur Behebung 8 T. → 5 T. (−38 %)

Wichtigste Errungenschaften: Automatisiertes Abhängigkeits-Scanning eingesetzt · 100 % MFA für alle Admin-Konten erreicht · Kritische Schwachstellen-MTTR von 8 auf 2,5 Tage reduziert

Nächster-Quartal-Fokus: Salesforce-MFA-Rollout abschließen · 100 % Schulungs-Compliance erreichen · Container-Scanning in CI/CD implementieren

Dashboard-Tools

Tool	Geeignet für	Kosten	Aufwand
Google Sheets/Excel	Schneller Start, einfache Metriken	Kostenlos	Gering
Notion	Visuell, einfaches Teilen	Kostenloser Tarif	Gering
Google Data Studio	Mehrere Datenquellen	Kostenlos	Mittel
Grafana	Technische Metriken, Zeitreihen	Kostenlos (self-hosted)	Mittel
Datadog	Integration mit Monitoring	Kostenpflichtig	Mittel
Splunk	Enterprise, komplexe Abfragen	Kostenpflichtig	Hoch
Benutzerdefinierte App	Spezifische Anforderungen	Entwicklungszeit	Hoch

Für kleine Unternehmen: Beginnen Sie mit einer Tabellenkalkulation. Im Ernst. Eine gut gepflegte Google-Tabelle schlägt eine ungepflegte Grafana-Instanz.

Automatisierung der Datenerfassung

Manuelle Datenerfassung skaliert nicht. Dort automatisieren, wo es möglich ist:

# Example: Weekly metrics collection script
name: Weekly Security Metrics

on:
  schedule:
    - cron: '0 9 * * 1'  # Every Monday at 9 AM

jobs:
  collect-metrics:
    runs-on: ubuntu-latest
    steps:
      - name: Get vulnerability count
        run: |
          # Query GitHub Security tab
          gh api repos/$ORG/$REPO/vulnerability-alerts --jq 'length'
          
      - name: Get Dependabot alerts
        run: |
          gh api repos/$ORG/$REPO/dependabot/alerts --jq '[.[] | select(.state=="open")] | length'
          
      - name: Get MFA status
        run: |
          # Query Google Workspace Admin API or IdP
          
      - name: Post to Slack
        run: |
          curl -X POST $SLACK_WEBHOOK -d '{
            "text": "Weekly Security Metrics: ..."
          }'

Der Unternehmensführung berichten

Metriken sind nutzlos, wenn die Unternehmensführung sie nicht sieht. Regelmäßiges Reporting hält Sicherheit sichtbar und demonstriert Wert.

Berichtshäufigkeit

Bericht	Häufigkeit	Zielgruppe	Inhalt
Dashboard	Echtzeit	Sicherheitsteam	Alle Metriken, detailliert
Wochenzusammenfassung	Wöchentlich	Sicherheits- + IT-Leiter	Wichtige Änderungen, Alarme
Monatsbericht	Monatlich	Abteilungsleiter	Trends, Fokusbereiche
Quartalsbericht	Vierteljährlich	Führungsteam	Strategische Sicht, Errungenschaften
Jahresbericht	Jährlich	Vorstand (falls zutreffend)	Jahresrückblick, Roadmap

Quartalsbericht-Vorlage

# Security Quarterly Report — Q1 2025

## Executive Summary

Q1 was a strong quarter for security. We closed 52 vulnerabilities, 
reduced our incident count by 20%, and achieved our MFA target for 
critical systems. Two areas need attention: Salesforce MFA rollout 
and training completion.

## Key Metrics

### Security Posture

| Metric | Q4 2024 | Q1 2025 | Target | Status |
|--------|---------|---------|--------|--------|
| Open Critical Vulns | 2 | 0 | 0 | Met |
| Open High Vulns | 12 | 8 | under 10 | Met |
| MTTR (Critical) | 8 days | 2.5 days | under 7 days | Met |
| MFA Adoption | 94% | 97% | 95% | Met |
| Phishing Click Rate | 7% | 4% | under 5% | Met |

### Trend Analysis

[Include sparklines or simple charts showing 4-quarter trends]

## Accomplishments

### Completed initiatives
1. **Automated dependency scanning** — Now running on all repositories, 
   catching vulnerable packages before deployment
2. **Admin MFA enforcement** — 100% of admin accounts now require 
   hardware security keys
3. **Incident response improvement** — Reduced critical incident 
   MTTR from 8 to 2.5 days through updated runbooks

### Metrics improvements
- Closed 52 vulnerabilities (up from 45 last quarter)
- Security incidents down 20% (15 vs. 19)
- Phishing resilience improved: 4% click rate (down from 7%)

## Incidents

### Summary
- Total incidents: 15 (down from 19)
- Critical: 0 | High: 2 | Medium: 5 | Low: 8

### Notable incidents
1. **Compromised contractor account (High)** — February 12
   - Detected within 2 hours, contained within 4 hours
   - No customer data accessed
   - Root cause: Shared credentials; fixed by enforcing individual accounts

2. **Phishing campaign targeting finance (Medium)** — March 5
   - 3 employees clicked, 8 reported
   - No credential compromise
   - Response: Additional training for finance team

## Risk Areas

### Issues requiring attention

1. **Salesforce MFA (Medium priority)**
   - Current: 83% adoption
   - Blocker: Some users on legacy mobile devices
   - Plan: Device upgrade for 3 remaining users by April 15

2. **Training completion (Medium priority)**
   - Current: 88% complete
   - Blocker: New hires in onboarding queue
   - Plan: Complete by April 30

### Emerging risks
- Increased targeting of our industry (per threat intel)
- New dependency vulnerabilities in React ecosystem

## Resource Utilization

| Initiative | Planned hours | Actual hours | Notes |
|------------|--------------|--------------|-------|
| Vulnerability remediation | 80 | 75 | On track |
| Security training | 20 | 25 | Additional sessions requested |
| Incident response | 40 | 35 | Fewer incidents |
| Policy updates | 20 | 15 | Completed early |
| Tool evaluation | 20 | 30 | Extended eval for SIEM |

## Next Quarter Plan

### Q2 2025 Priorities

1. **Complete MFA rollout** — 100% coverage including Salesforce
2. **Container security** — Implement image scanning in CI/CD
3. **Security Champions expansion** — Train 2 additional champions
4. **Tabletop exercise** — Quarterly IR practice

### Upcoming milestones
- April 15: Salesforce MFA complete
- April 30: Training 100% complete
- May 15: Container scanning deployed
- June 1: New Security Champions onboarded

## Budget

| Category | Q1 Budget | Q1 Actual | Variance |
|----------|-----------|-----------|----------|
| Tools | $5,000 | $4,500 | -$500 |
| Training | $2,000 | $2,200 | +$200 |
| Contractor | $3,000 | $2,500 | -$500 |
| Certifications | $1,000 | $800 | -$200 |
| **Total** | **$11,000** | **$10,000** | **-$1,000** |

## Recommendations

1. **Approve budget for SIEM pilot** — $3,000/quarter for 90-day eval
2. **Add security requirements to vendor contracts** — Legal review needed
3. **Consider bug bounty program** — Research for Q3 implementation

## Appendix

### A. Full metrics table
[Detailed metrics data]

### B. Incident list
[All incidents with classification]

### C. Tool inventory
[Current security tools and status]

Präsentation vor Führungskräften

Bei der Präsentation vor der Unternehmensführung:

1. Mit der Überschrift führen: „Die Sicherheitslage ist gut. Zwei Punkte benötigen Aufmerksamkeit."

Nicht: „Lassen Sie mich Sie durch unsere 47 Metriken führen..."

2. Ampelfarben verwenden:

• Grün: Im Zielbereich
• Gelb: Aufmerksamkeit erforderlich
• Rot: Kritisches Problem

3. Trends, nicht nur Zahlen zeigen: „Phishing-Klicks sanken in diesem Jahr von 18 % auf 4 %" erzählt eine Geschichte. „4 % Phishing-Klickrate" ist nur eine Zahl.

4. Mit Geschäftsauswirkungen verbinden:

• „Diese Schwachstelle hätte Kundendaten offengelegt"
• „MFA verhindert die häufigste Ursache von Einbrüchen in unserer Branche"
• „Schnellere Vorfallreaktion = weniger Ausfallzeit = weniger Umsatzverlust"

5. Ehrlich über Lücken sein: Unternehmensführung respektiert Ehrlichkeit. Probleme zu verstecken untergräbt Vertrauen.

6. Mit Lösungen kommen: Für jedes Problem einen Plan haben. „Salesforce-MFA liegt bei 83 %. Bis zum 15. April werden wir bei 100 % sein."

7. Um das bitten, was man braucht: Die Anfrage klar machen. „Ich brauche die Genehmigung für einen 3.000 €-SIEM-Pilot."

Mit schwierigen Fragen umgehen

Frage	Wie zu antworten
„Sind wir sicher?"	„Keine Organisation ist zu 100 % sicher. Wir verwalten unsere Top-Risiken effektiv. Hier ist der Beweis: [Metriken]"
„Wie vergleichen wir uns mit anderen?"	„Branchenbenchmarks zeigen [X]. Wir sind bei [Y], was [über/unter/im] Durchschnitt für Unternehmen unserer Größe liegt."
„Warum brauchen wir mehr Budget?"	„Die aktuelle Investition gibt uns [X Abdeckung]. Zusätzliches Budget würde [spezifische Lücke] adressieren, die [Risiko] darstellt."
„Können Sie keine Einbrüche garantieren?"	„Das kann niemand garantieren. Wir können Wahrscheinlichkeit und Auswirkung reduzieren. Hier ist, was wir tun: [Spezifika]"
„Was ist unser größtes Risiko?"	„[Spezifisches Risiko], weil [Grund]. Wir adressieren es durch [Aktion]."

Ziele und Vorgaben setzen

Metriken brauchen Ziele. Ohne Ziele sind Zahlen nur Zahlen.

Wie man realistische Ziele setzt

1. Zuerst eine Basis messen: Den aktuellen Zustand messen, bevor Ziele gesetzt werden. Man kann nicht verbessern, was man nicht kennt.

2. Branchenbenchmarks: Schauen, was ähnliche Unternehmen erreichen:

• Phishing-Klickraten: 5–15 % ist typisch, unter 5 % ist gut
• MTTR für kritische Schwachstellen: 7–30 Tage ist typisch, unter 7 ist gut
• MFA-Adoption: 85–95 % ist typisch, 100 % anstreben

3. Beschränkungen berücksichtigen:

• Teamgröße
• Budget
• Technische Schulden
• Konkurrierende Prioritäten

4. Inkrementelle Verbesserung: Bei 15 % Phishing-Klicks kein Ziel von 2 % setzen. Zuerst 10 % anstreben.

Branchenbenchmarks: Wo man sie findet

Ziele nicht im Vakuum setzen. Branchendaten verwenden:

Quelle	Was es abdeckt	Link	Aktualisierungshäufigkeit
Verizon DBIR	Einbruchsmuster, Angriffsvektoren, Branchentrends	verizon.com/dbir	Jährlich
SANS Security Awareness Report	Phishing-Raten, Schulungseffektivität	sans.org/security-awareness-training	Jährlich
Ponemon Institute	Kosten von Einbrüchen, Zeit zur Erkennung/Eindämmung	ponemon.org	Jährlich
Mandiant M-Trends	Verweildauer, Angriffstechniken	mandiant.com/m-trends	Jährlich
CrowdStrike Global Threat Report	Angriffstrends, Breakout-Zeit	crowdstrike.com/reports	Jährlich
KnowBe4 Benchmarking Report	Phishing-Anfälligkeit nach Branche	knowbe4.com/phishing-benchmarking	Jährlich

Wichtige Benchmarks (Daten 2024):

Metrik	Branchendurchschnitt	Gut	Exzellent
Phishing-Klickrate (ungeschult)	30–35 %	unter 15 %	unter 5 %
Phishing-Klickrate (geschult)	10–15 %	unter 5 %	unter 2 %
MTTD (mittlere Zeit bis zur Erkennung)	197 Tage	unter 30 Tage	unter 7 Tage
MTTC (mittlere Zeit bis zur Eindämmung)	69 Tage	unter 14 Tage	unter 3 Tage
Patch-Compliance (kritisch, 7 Tage)	60 %	>85 %	>95 %
MFA-Adoption	60–70 %	>90 %	100 %

Quellen: Verizon DBIR 2024, Ponemon Cost of Data Breach 2024, KnowBe4 2024

Beispiel: Jährliche Sicherheitsziele

## Security Goals — 2025

### Vulnerability Management
| Goal | Current | Target | By when |
|------|---------|--------|---------|
| Zero critical vulns | 2 avg | 0 | Ongoing |
| MTTR critical | 8 days | 3 days | Q2 |
| MTTR high | 21 days | 14 days | Q3 |
| Patch compliance | 85% | 95% | Q2 |

### Access Management
| Goal | Current | Target | By when |
|------|---------|--------|---------|
| MFA adoption | 94% | 100% | Q1 |
| Privileged accounts | 25 | 15 | Q2 |
| Access review cycle | Annual | Quarterly | Q2 |

### Awareness
| Goal | Current | Target | By when |
|------|---------|--------|---------|
| Phishing click rate | 8% | 5% | Q2 |
| Training completion | 75% | 100% | Q1 |
| Report rate | 40% | 60% | Q3 |

### Incident Response
| Goal | Current | Target | By when |
|------|---------|--------|---------|
| MTTD | 4 hours | 1 hour | Q4 |
| MTTR | 6 hours | 2 hours | Q4 |
| Tabletop exercises | 1/year | 4/year | Ongoing |

Geld sprechen: Risikobasierte Metriken

Unternehmensführung spricht die Sprache des Geldes. Die Übersetzung von Sicherheit in finanzielle Begriffe stärkt Ihre Argumente.

Die FAIR-Methodik (vereinfacht)

FAIR (Factor Analysis of Information Risk) bietet ein Framework zur Quantifizierung von Risiken in Euro. Die vollständige Methodik ist komplex, aber Sie können die Kernkonzepte verwenden:

Risk ($) = Probability of Event × Impact of Event

Example: Credential stuffing attack
- Probability: 25% per year (based on industry data, our exposure)
- Impact: $200,000 (incident response, downtime, reputation)
- Annual risk: 0.25 × $200,000 = $50,000 expected loss

If MFA costs $5,000/year and reduces probability to 2%:
- New risk: 0.02 × $200,000 = $4,000
- Risk reduction: $50,000 - $4,000 = $46,000
- ROI: ($46,000 - $5,000) / $5,000 = 820%

Schnelle Risikoquantifizierungs-Vorlage

Für jedes größere Risiko schätzen:

Faktor	Wie zu schätzen	Beispiel
Wahrscheinlichkeit	Branchendaten + Ihre Kontrollen	25 % pro Jahr
Primärverlust	Direkte Kosten: IR, Wiederherstellung, Bußgelder	50.000 €
Sekundärverlust	Reputation, Kundenverlust, Rechtskosten	150.000 €
Gesamtauswirkung	Primär + Sekundär	200.000 €
Erwarteter Verlust	Wahrscheinlichkeit × Auswirkung	50.000 €/Jahr

Kostendaten für Einbrüche

Diese für Berechnungen verwenden (an Ihre Unternehmensgröße anpassen):

Kostenkategorie	Kleines Unternehmen (unter 100 Mitarb.)	Mittelgroß (100–1000)	Quelle
Durchschnittliche Einbruchskosten	120.000–250.000 €	500.000–2 Mio. €	Ponemon 2024
Kosten pro Datensatz (PII)	150–180 €	150–180 €	Ponemon 2024
Ransomware-Durchschnitt	150.000–300.000 €	500.000–1,5 Mio. €	Coveware 2024
Business Email Compromise	50.000–150.000 €	150.000–500.000 €	FBI IC3 2023
Ausfallkosten/Stunde	1.000–10.000 €	10.000–100.000 €	Variiert nach Branche

Sicherheits-ROI berechnen

Bei Budgetanfragen die Rechnung zeigen:

Security Investment ROI Calculator

Initiative: Implement SAST in CI/CD
Cost: $15,000/year (tool + setup time)

Without SAST:
- Vulns found in production: ~20/year
- Average fix cost in production: $5,000
- Total: $100,000/year + breach risk

With SAST:
- Vulns caught pre-production: 18/20 (90%)
- Vulns reaching production: 2/year
- Average fix cost in development: $500
- Production fixes: 2 × $5,000 = $10,000
- Pre-production fixes: 18 × $500 = $9,000
- Total: $19,000

Savings: $100,000 - $19,000 = $81,000
ROI: ($81,000 - $15,000) / $15,000 = 440%

Plus: Reduced breach probability (harder to quantify but real)

Expertentipp: Diese Berechnungen nicht übertechnisieren. Größenordnung reicht. „50.000 € bis 100.000 € Risiko" ist nützlich. „73.847,23 € Risiko" ist falsche Präzision, die Glaubwürdigkeit untergräbt.

Sicherheitsreife-Modell

Wo steht Ihre Organisation auf der Reifekurve? Das hilft, realistische Ziele zu setzen und Fortschritte zu kommunizieren.

Fünf Stufen der Sicherheitsreife

Stufe	Name	Merkmale
5	Optimierend	Kontinuierliche Verbesserung, prädiktive Analysen, Sicherheit ermöglicht Geschäftsinnovation
4	Verwaltet	Metriken-gesteuert, quantitatives Risikomanagement, Sicherheit in alle Prozesse integriert
3	Definiert	Dokumentierte Prozesse, konsistente Praktiken, Sicherheitsrichtlinien durchgesetzt, regelmäßige Schulungen
2	Entwicklend	Einige Prozesse vorhanden, reaktive Sicherheit, grundlegende Kontrollen, ad-hoc-Schulungen
1	Initial	Kein formales Sicherheitsprogramm, Chaos-Modus, auf Vorfälle reagieren, wenn sie eintreten

Schneller Reife-Assessment-Check

Bereich	Stufe 1	Stufe 2	Stufe 3	Stufe 4–5
Schwachstellenmanagement	Nur bei Ausnutzung beheben	Gelegentlich scannen	Regelmäßige Scans, SLAs	Automatisiert, risikobasiert
Zugangskontrolle	Geteilte Passwörter	Individuelle Konten	MFA, Zugriffsüberprüfungen	Zero Trust, JIT-Zugang
Vorfallreaktion	Panik-Modus	Grundlegende Runbooks	Geübter IR-Plan	Automatisierte Reaktion
Schulung	Keine	Einmaliges Onboarding	Jährliche Schulung	Kontinuierlich, rollenbasiert
Metriken	Keine	Nach Vorfällen	Grundlegendes Dashboard	Prädiktive Analysen
Sicherheit im SDLC	Keine	Nur abschließende Tests	Integriertes Scanning	Shift-Left, Threat Modeling

Metriken nach Reifegrad

Verschiedene Reifegrade benötigen verschiedene Metriken:

Stufe 1–2 (Anfang):

• Haben wir grundlegende Kontrollen? (Ja/Nein-Checkliste)
• Sind kritische Systeme geschützt? (Binär)
• Können wir offensichtliche Angriffe erkennen? (Testergebnisse)

Stufe 2–3 (Fundament aufbauen):

• Schwachstellenzahlen und Trends
• MFA-Adoptionsprozentsatz
• Schulungsabschlussrate
• Vorfallanzahl und Schweregrad

Stufe 3–4 (Reifend):

• MTTR-, MTTD-Trends
• Risikogewichtete Schwachstellen-Scores
• Frühindikatoren (Sicherheit im Design)
• Kosten pro behobener Schwachstelle

Stufe 4–5 (Optimierend):

• Prädiktive Risiko-Scores
• Sicherheits-ROI nach Initiative
• Geschäftsausgerichtete Risikomatriken
• Benchmark-Vergleiche

Metrik-Gaming: Was zu beachten ist

Jede Metrik, die ein Ziel wird, wird manipuliert. Das antizipieren und Gegenmaßnahmen entwerfen.

Häufige Gaming-Muster

Gaming-Verhalten	Wie es aussieht	Das echte Problem
Schweregrads-Downgrade	„Das ist Mittel, nicht Hoch"	Kritische Schwachstellen entgehen dem SLA
Won't-Fix-Epidemie	MTTR sieht toll aus, Schwachstellen existieren noch	Risiko nicht wirklich reduziert
Fokus auf einfache Gewinne	50 niedrige Schwachstellen geschlossen, 2 kritische ignoriert	Falsche Prioritäten
Nenner-Manipulation	„Nur 5 Systeme brauchen Patches" (wir haben 50 ausgeschlossen)	Abdeckungslücken verborgen
Timing-Spiele	Schwachstelle am 1. April entdeckt, am 5. April protokolliert	MTTD sieht besser aus als Realität
Definitions-Drift	„Das war kein Vorfall, nur ein Ereignis"	Vorfall-Zahl sieht gut aus, Lernen verloren

Wie man Gaming verhindert

1. Mehrere korrelierte Metriken: Wenn MTTR durch Schließen als „won't fix" manipuliert wird, auch „% der als Risiko akzeptierten Schwachstellen" verfolgen und VP-Genehmigung für Risikoakzeptanz verlangen.

2. Outcome-Metriken neben Aktivitätsmetriken: Sowohl „behobene Schwachstellen" als auch „im Zeitverlauf in Produktion gefundene Schwachstellen" verfolgen.

3. Zufällige Audits: Regelmäßig eine Stichprobe geschlossener Schwachstellen überprüfen. Waren sie wirklich behoben? War der Schweregrad korrekt?

4. Trend-Anomalie-Erkennung: Plötzliche Verbesserungen sollten eine Untersuchung auslösen. Hat sich wirklich etwas geändert, oder die Messung?

5. Drittanbieter-Validierung: Periodische Pentests enthüllen, was eigene Metriken möglicherweise verbergen.

Expertentipp: Das Ziel ist nicht, Menschen beim Gaming von Metriken zu ertappen — es ist, Metriken zu entwerfen, die schwer zu manipulieren sind und dabei immer noch das messen, was wichtig ist. Wenn Gaming auftritt, zeigt es oft perverse Anreize, die nicht beabsichtigt waren. Die Anreize beheben, nicht nur das Verhalten.

Echte Geschichten: Wenn Metriken den Unterschied machen

Geschichte 1: Das Phishing-Diagramm, das Budget brachte

Eine Security Championin in einem 200-Personen-Unternehmen verfolgte Phishing-Simulations-Ergebnisse sechs Monate lang. Die erste Simulation: 28 % Klickrate. Nach monatlichen Simulationen und gezielten Schulungen: 4 % Klickrate.

Bei der Präsentation vor dem CEO sprach sie nicht über „Sicherheitsbewusstsein". Sie zeigte:

• „28 % der Mitarbeiter hätten Angreifern ihre Anmeldedaten gegeben"
• „Jetzt sind es 4 % — eine 7-fache Verbesserung"
• „Der branchenübliche Einbruch über Phishing kostet 150.000 €"
• „Wir haben dieses Risiko für 3.000 € Schulungsinvestition reduziert"

Ergebnis: CEO genehmigte Budget für eine richtige Sicherheitsbewusstseins-Plattform und lobte die Initiative beim All-Hands-Meeting.

Geschichte 2: Die MTTR, die einen kaputten Prozess enthüllte

Ein Unternehmen verfolgte MTTR für Schwachstellen und war stolz auf ihren 5-Tage-Durchschnitt. Dann grub ein Security Champion tiefer und fand:

• Kritische Schwachstellen: 3 Tage (gut)
• Hohe Schwachstellen: 8 Tage (okay)
• Mittlere Schwachstellen: 45 Tage (durch den Durchschnitt verborgen)

Die Mittelung verdeckte, dass mittlere Schwachstellen ignoriert wurden. Nach der Enthüllung implementierte das Team SLAs nach Schweregrad, und das echte Problem wurde angegangen.

Geschichte 3: Der fehlende Frühindikator

Ein Startup maß Vorfälle und Schwachstellen, aber nichts über seinen Entwicklungsprozess. Es hatte null Vorfälle (gut!), aber auch:

• Keine Sicherheit in Code-Reviews
• Kein SAST oder Abhängigkeits-Scanning
• Keine Sicherheitsschulung für Entwickler

Ein neuer Security Champion fügte Frühindikatoren hinzu:

• % der Repos mit automatisiertem Sicherheits-Scanning: 0 %
• % der Entwickler mit Sicherheitsschulung: 12 %
• % der PRs mit Sicherheits-Review: 0 %

Diese Daten machten einen überzeugenden Fall, dass ihre niedrige Vorfall-Zahl Glück, keine Sicherheit war. Sechs Monate später, nach dem Hinzufügen dieser Praktiken, fingen sie ihre erste kritische Schwachstelle in CI/CD ab — bevor sie die Produktion erreichte.

Geschichte 4: Als fehlende Metriken eine Katastrophe verursachten

Ein mittelgroßes Unternehmen hatte keine Sicherheitsmetriken. Die Unternehmensführung nahm an: „Keine Nachrichten sind gute Nachrichten." Dann kam ein Ransomware-Angriff:

• Keine Sichtbarkeit des Patch-Status — 40 % der Systeme waren Monate im Rückstand
• Kein Zugangs-Inventar — konnte kompromittierte Konten nicht identifizieren
• Keine Vorfall-Metriken — keine Basis für „normale" Erkennungszeit
• Wiederherstellung dauerte 3 Wochen; Kosten: 800.000 €

Nach dem Vorfall war die erste Frage des CEOs: „Warum wussten wir nicht, dass wir verwundbar waren?" Die Antwort: „Wir haben es nicht gemessen."

Storytelling: Wie man Metriken effektiv präsentiert

Daten sprechen nicht für sich. Sie müssen eine Geschichte erzählen.

Das Pyramidenprinzip

Ihre Präsentation wie eine Pyramide strukturieren:

1. Oben: Die Schlussfolgerung — Mit der Antwort beginnen
2. Mitte: Wichtigste Stützpunkte — 3–4 Hauptgründe
3. Unten: Details — Daten, die jeden Punkt unterstützen

BAD structure:
"Let me walk you through our 47 metrics, and at the end 
I'll tell you what it means..."

GOOD structure:
"Our security posture is strong, with two areas needing 
attention. Here's why I say that: [3 points with data]"

Der „Na und?"-Test

Für jede Metrik „Na und?" beantworten, bevor die Unternehmensführung fragt:

Metrik	Na und?
„Wir haben 12 hohe Schwachstellen"	„Jede könnte zu einem Einbruch führen. Hier ist unser Plan, sie bis [Datum] zu schließen."
„Phishing-Klicks fielen auf 4 %"	„Das ist 7-mal besser als am Anfang und unter dem Branchendurchschnitt. Unsere Investition zahlt sich aus."
„MTTR verbesserte sich von 8 auf 3 Tage"	„Wir beheben kritische Probleme, bevor Angreifer sie ausnutzen können. Schneller als 80 % der Unternehmen unserer Größe."

Visualisierung, die funktioniert

Für diese Daten	Verwenden Sie das	Warum
Trend im Zeitverlauf	Liniendiagramm	Zeigt Richtung und Geschwindigkeit
Aktueller Status vs. Ziel	Anzeige oder Fortschrittsbalken	Zeigt Lücke sofort
Vergleich über Kategorien	Horizontales Balkendiagramm	Einfach zu vergleichen
Mehrere Metriken zusammengefasst	Ampel-Tabelle	Schnelle Status-Übersicht
Vorher/Nachher	Zwei Zahlen nebeneinander	Klare Verbesserungsgeschichte

Zeitpunkt Ihres Berichts

Wann Sie präsentieren, ist wichtig:

• Montagmorgen: Wenig Energie, viel Ablenkung. Vermeiden.
• Freitagnachmittag: Alle mental ausgecheckt. Vermeiden.
• Nach einem Sicherheitsvorfall: Hohe Aufmerksamkeit, aber reaktive Einstellung.
• Budgetplanungssaison: Perfekter Zeitpunkt für Investitionsanfragen.
• Nach einem positiven Meilenstein: Auf dem Schwung aufbauen.

Expertentipp: Regelmäßige Zeit planen (monatlich oder vierteljährlich) statt ad-hoc-Updates. Konsistenz baut Glaubwürdigkeit auf.

Mit Skepsis umgehen

Einwand	Antwort
„Diese Zahlen klingen zu gut"	„Hier sind die Rohdaten und die Methodik. Ich unter-claime lieber, als zu viel zu versprechen."
„Können wir diesen Daten trauen?"	„Wir validieren gegenseitig mit [Quelle]. Hier ist, wie wir sie erfassen."
„Das scheint kompliziert"	„Die Zusammenfassung ist einfach: [ein Satz]. Details stehen im Anhang."
„Andere Prioritäten sind dringender"	„Verstanden. Hier ist das Risiko einer Verschiebung, quantifiziert: [€€€]"

Häufige Fehler

1. Alles messen — Zu viele Metriken erzeugen Rauschen; auf das Wesentliche fokussieren
2. Eitelkeitsmetriken — „Sicherheitsschulungsstunden" bedeutet nicht „Mitarbeiter sind sicher"
3. Seltene Updates — Vierteljährliche Metriken ohne zwischenzeitliche Updates erzeugen Überraschungen
4. Kein Kontext — Rohe Zahlen ohne Benchmarks oder Trends sind bedeutungslos
5. Schlechte Nachrichten verstecken — Unternehmensführung findet es sowieso heraus; besser von Ihnen
6. Nur manuelle Erfassung — Kann nicht skalieren; automatisieren, was möglich ist
7. Keine Ziele — Zahlen ohne Ziele treiben keine Verbesserung
8. Zu technisch — CVSS-Scores bedeuten dem CEO nichts
9. Keine Verbindung zum Geschäft — „Na und?" ist eine gültige Frage
10. Schöne Dashboards, keine Aktion — Metriken sollten Entscheidungen vorantreiben

Workshop: Ihr Sicherheits-Dashboard erstellen

Teil 1: Metriken definieren (1 Stunde)

1. Wichtige Metriken identifizieren:

   • 5–7 Metriken aus den obigen Listen auswählen
   • Abdeckung sicherstellen: Schwachstellen, Zugang, Vorfälle, Awareness
   • Metriken wählen, die jetzt tatsächlich gemessen werden können

2. Basiswerte setzen:

   • Aktuellen Zustand für jede Metrik erfassen
   • Dokumentieren, wie Daten erfasst werden
   • Datenverfügbarkeitslücken notieren

3. Ziele setzen:

   • Benchmarks für Ihre Branche recherchieren
   • Realistische Verbesserungsziele setzen
   • Zeitlinie für jedes Ziel definieren

Teil 2: Dashboard erstellen (2 Stunden)

1. Struktur erstellen:

   • Google Sheets, Notion oder Ihr bevorzugtes Tool verwenden
   • Führungskräfte-Zusammenfassungsansicht erstellen
   • Detaillierte Metriken-Ansicht erstellen

2. Mit Daten befüllen:

   • Aktuelle Metriken eingeben
   • Historische Daten hinzufügen, wenn verfügbar
   • Trend-Visualisierungen erstellen

3. Automatisierung hinzufügen:

   • Datenquellen identifizieren
   • Abfragen oder Integrationen einrichten, wo möglich
   • Manuelle Erfassungsschritte dokumentieren

Teil 3: Quartalsbericht schreiben (1 Stunde)

1. Vorlage verwenden:

   • Für Ihr Unternehmen anpassen
   • Aktuelles Quartal ausfüllen
   • Narrative für Schlüsselpunkte hinzufügen

2. Überprüfen und verfeinern:

   • Jemand anderen lesen lassen
   • Auf Jargon prüfen
   • Alle Zahlen verifizieren

Zu produzierende Artefakte

Nach diesem Workshop sollten Sie haben:

• Liste von 5–7 wichtigen Sicherheitsmetriken
• Basiswerte für jede Metrik
• Ziele und Zeitlinien für jede Metrik
• Führungskräfte-Dashboard (Tabellenkalkulation oder Tool)
• Detailliertes Metriken-Tracking-Sheet
• Erster Quartalsbericht-Entwurf
• Datenerfassungsplan/-automatisierung

Selbstcheck-Fragen

1. Was ist der Unterschied zwischen einer Eitelkeitsmetrik und einer echten Metrik?
2. Warum sollte man Trends statt nur aktuelle Zahlen zeigen?
3. Was sind die fünf Kern-Metrik-Kategorien für Security Champions?
4. Wie oft sollten Sie der Unternehmensführung berichten?
5. Was sollten Sie tun, wenn Metriken schlechte Nachrichten zeigen?
6. Wie setzt man realistische Sicherheitsziele?
7. Warum ist Automatisierung für die Metrik-Erfassung wichtig?
8. Was sollte ein Führungskräfte-Dashboard enthalten?
9. Wie verbindet man Sicherheitsmetriken mit Geschäftsauswirkungen?
10. Was ist der erste Schritt, bevor man Verbesserungsziele setzt?

Gespräch mit der Unternehmensführung

Das Pitch: „Ich möchte ein einfaches Dashboard erstellen, das unseren Sicherheitsstatus auf einen Blick zeigt. Sie sehen, wo wir stark sind, wo wir Arbeit brauchen und wie wir uns verbessern. Keine Überraschungen — Sie wissen immer, wo wir stehen."

Was Sie benötigen:

• Zugang zu Sicherheits-Tool-Dashboards (Schwachstellen-Scanner, IdP usw.)
• 2–3 Stunden pro Monat für Datenerfassung und Reporting
• 30 Minuten vierteljährlich mit der Unternehmensführung zur Überprüfung

Der Wert:

• Sichtbarkeit von Sicherheitsinvestitionen
• Frühwarnung vor Problemen
• Nachweise für Audit/Compliance
• Daten für strategische Entscheidungen

Erstes Ergebnis: „Ich werde in 2 Wochen ein Basis-Dashboard bereit haben. Danach monatliche Updates mit einer vierteljährlichen Überprüfung."

Fazit

Messen, um zu verbessern, nicht um zu berichten. Ein Dashboard, das niemand anschaut, ist nur Overhead. Drei Metriken, die jeden Monat Aktionen vorantreiben, sind mehr wert als zwanzig Metriken, die einmal im Quartal präsentiert und dann vergessen werden.

Klein anfangen. Eine Tabellenkalkulation ist fine. Die Gewohnheit des Trackings ist wichtiger als das Tool, das man dafür verwendet.

Was kommt als nächstes

Damit ist der Abschnitt zur Sicherheitskultur abgeschlossen. Weiter: erweiterte Themen und langfristige Strategie — Risikomanagement, Compliance, Anbietersicherheit und Skalierung des Sicherheitsprogramms.