Die meisten Programme für Anwendungssicherheit können sagen, was sie im letzten Quartal getan haben. Viel weniger können sagen, ob es gewirkt hat. Der Stream Measure and Improve von OWASP SAMM soll genau diese Lücke schließen.
Dieser Artikel ist Community-Guidance für den Stream Measure and Improve in der Practice Strategy and Metrics von SAMM. Der zugehörige OpenCRE-Eintrag ist Steer the secure software development program. Die Kennzahlen unten beziehen sich auf die Softwareentwicklung in R&D-Teams. Kennzahlen zur Betriebssicherheit, etwa Patchstände von Produktionsservern oder Klickraten bei Phishing, sind ein anderes Thema.
Was eine gute Kennzahl ausmacht
Laut SAMM sollen diese Kennzahlen die Wirksamkeit und Effizienz Ihres Programms für Anwendungssicherheit messen. Behalten Sie das im Blick, während Sie die Liste aufbauen. Jede Kennzahl sollte dem Team für Anwendungssicherheit etwas sagen, das es wissen muss, um seine eigenen Ziele zu erreichen. Eine Kennzahl, auf die niemand reagiert, ist Overhead.
Jede Kennzahl muss außerdem:
- jedes Mal auf dieselbe Weise messbar sein, damit Trends aussagekräftig sind
- günstig zu erheben sein, idealerweise automatisch aus Tools, die Sie ohnehin nutzen
- als Zahl oder Prozentsatz mit klarer Einheit ausgedrückt werden
Dokumentieren Sie jede Kennzahl mit Name, Formel, Einheit, Datenquelle, Erhebungsrhythmus und Verantwortlichem. Diese eine Zeile Dokumentation verhindert später die meisten Diskussionen über die Zahlen.
Drei Kategorien: Aufwand, Ergebnis und Umfeld
Auf Reifegrad 1 erfasst das Security-Team Kennzahlen in allen drei Kategorien, die SAMM definiert: Aufwand (Effort), Ergebnis (Result) und Umfeld (Environment). Am wichtigsten ist zu verstehen, wie Aufwands- und Umfeldkennzahlen die Ergebniskennzahlen beeinflussen.
Diesen Zusammenhang nehmen Sie auch mit ins Management. Führungskräfte interessieren sich für Ergebnisse, investieren können sie aber nur in Aufwand. Wenn Sie zeigen können, welcher Aufwand welche Ergebnisse bewegt, lassen sich Investitionsentscheidungen viel leichter begründen.
Die Übersicht unten zeigt Beispielkennzahlen je Kategorie, mit Linien, die zeigen, wie sie sich gegenseitig beeinflussen. Nutzen Sie sie als Ausgangspunkt und passen Sie sie an die Ziele Ihres eigenen Programms an.
Aufwandskennzahlen
Aufwandskennzahlen messen, wie viel Arbeit in Sicherheitsaktivitäten fließt. Sie zählen vor allem Aktivitäten, die für sich genommen kein Ergebnis sind, aber helfen, Ergebnisse zu erreichen.
Beispiele:
- Anzahl der Security-Schulungen oder Gesamtzahl der Schulungsstunden
- Anzahl besuchter externer Security-Veranstaltungen wie Workshops, Konferenzen und Community-Treffen
- Anzahl interner Mitteilungen zum Thema Sicherheit
- Zeitaufwand für Security Code Reviews
- Anzahl der Architektur-Reviews mit Sicherheitsfokus
- Anzahl der Threat-Modeling-Sessions
- Anzahl der Penetrationstests
- Anzahl der Review-Sessions für Sicherheitsanforderungen in fachlichen Anforderungen
- Anzahl geschlossener Sicherheitsfehler in Ihrem Issue-Tracker, etwa Jira
- Anzahl geschlossener Befunde in SCA-, SAST- und DAST-Tools in einem bestimmten Zeitraum
- Budget für Security-Tools und Lizenzen
- Anzahl durchgeführter OWASP-SAMM-Assessments
Ergebniskennzahlen
Ergebniskennzahlen messen, wie wirksam der Sicherheitsaufwand ist. Auf Reifegrad 2 dieses Streams wählen Sie die wichtigsten davon als Kern-KPIs Ihres Programms für Anwendungssicherheit und legen Ziele dafür fest.
Beispiele:
- Abdeckung der Security-Schulungen: geschulte Personen geteilt durch die Personen, die geschult werden sollten
- Sicherheitsbewusstsein: Durchschnittswerte aus Quizzen oder Umfragen nach Schulungen
- Gesamtzahl der Security Champions
- Abdeckung durch Security Champions: Teams oder Produkte mit mindestens einem Champion geteilt durch alle Teams oder Produkte
- Zugang an Sicherheitsvorfällen: neue Vorfälle in einem bestimmten Zeitraum
- Kosten pro Vorfall, in Geld oder Personentagen
- durchschnittliche Zeit bis zum Patch oder bis zum Abschluss eines Vorfalls
- Tool-Abdeckung: von SCA, SAST und DAST gescannte Anwendungen oder Repositories geteilt durch die, die gescannt werden sollten
- offene SCA-Befunde oder der Gesamtrisikowert der Abhängigkeiten von Drittanbietern
- kritische Schwachstellen in Drittkomponenten, die älter als 90 Tage sind
- offene Sicherheitsbefunde aus SAST
- offene Sicherheitsfehler in Ihrem Issue-Tracker
- Servicelevel: durchschnittliche Zeit zur Behebung von Sicherheitsfehlern und Vorfällen und deren Gesamtkosten in Personentagen
- Abdeckung durch SAMM-Assessments: Scopes mit einem aktuellen Assessment geteilt durch alle Scopes
Umfeldkennzahlen
Umfeldkennzahlen beschreiben den Kontext, in dem die Sicherheitsarbeit stattfindet. Sie helfen, Umfang und Komplexität des Programms zu verstehen. Sie müssen nicht an Security-Tools oder Aktivitäten gebunden sein, aber Sie brauchen sie als Eingangsgrößen für die Ergebniskennzahlen, meist als Nenner von Abdeckungsquoten.
Beispiele:
- Anzahl der Scopes in der Organisation, die Sie für SAMM-Assessments verwenden
- Gesamtzahl der Produkte oder Anwendungen
- Anzahl der Produkte oder Anwendungen, die DAST abdecken sollte
- Anzahl der eingesetzten Drittkomponenten
- Gesamtzahl der Entwicklungs-, QA- und Betriebsteams und der Personen darin
- verfügbares Budget für externe Security-Veranstaltungen und Schulungen
- verfügbares Budget für Security-Tools und Lizenzen
- Anzahl der Security Officers
Wie die Kategorien zusammenhängen
Einige Zusammenhänge aus der Übersicht zeigen, wie das in der Praxis funktioniert:
- Mehr Schulungsstunden sollten die Schulungsabdeckung und die Werte zum Sicherheitsbewusstsein erhöhen und die Zahl der Security Champions wachsen lassen.
- Threat-Modeling-Sessions, Architektur-Reviews und Penetrationstests sollten den Zugang an Vorfällen, die Kosten pro Vorfall und die Zeit bis zum Patch senken.
- Das Schließen von SCA-, SAST- und DAST-Befunden senkt die Zahl offener Befunde, solange neue nicht schneller hinzukommen.
- Budget für Tools erhöht die Abdeckung durch SCA, SAST und DAST, gemessen an der Zahl der Anwendungen aus Ihren Umfeldkennzahlen.
- Durchgeführte SAMM-Assessments erhöhen die Assessment-Abdeckung, gemessen an der Zahl der Scopes.
Bewegt sich ein Ergebnis nicht, obwohl der Aufwand gestiegen ist, lohnt sich ein Gespräch. Vielleicht zielt der Aufwand auf das Falsche, oder das Umfeld ist schneller gewachsen als das Programm.
Kennzahlen für die Vorbereitung auf den CRA
Wenn Sie Produkte mit digitalen Elementen für den EU-Markt herstellen, gibt der Cyber Resilience Act einigen Ergebniskennzahlen ein rechtliches Gewicht. Diese lohnen sich für Ihre Liste:
- Produkte mit aktueller SBOM geteilt durch alle Produkte im Geltungsbereich
- Produkte mit festgelegtem und veröffentlichtem Unterstützungszeitraum
- Median der Zeit zur Behebung kritischer Schwachstellen in unterstützten Produktversionen
- kritische Schwachstellen in Drittkomponenten ohne Fix oder Maßnahmenplan
- Produkte, für die eine veröffentlichte Richtlinie zur koordinierten Offenlegung von Schwachstellen gilt
- Zeit vom Bekanntwerden einer aktiv ausgenutzten Schwachstelle bis zur Frühwarnung innerhalb von 24 Stunden, gemessen in Übungen, bevor Sie es im Ernstfall brauchen
Unser CRA-Leitfaden für KMU erklärt die Pflichten dahinter, und OWASP Dependency-Track kann mehrere der SBOM- und Drittkomponenten-Zahlen automatisch liefern.
Von Kennzahlen zu KPIs
Das Festlegen und Dokumentieren Ihrer Measure-and-Improve-Kennzahlen ist der Schritt vor Reifegrad 2, auf dem Sie die KPIs aus Ihren Ergebniskennzahlen auswählen und Ziele dafür setzen. Fangen Sie klein an. Fünf Kennzahlen, die Sie jeden Monat zuverlässig erheben, sind mehr wert als dreißig, die Sie einmal erheben.
Wenn Sie einen unabhängigen Blick darauf möchten, wo Ihr Programm steht: Unser SSDLC Maturity Assessment bewertet Ihre heutige Praxis mit OWASP SAMM und erstellt eine Roadmap zur Verbesserung.