Die breite Nutzerschaft einer Software hat sich längst daran gewöhnt, dass Software bei ihr im Zuge der Anwendung reift. Sichere Software kann sich dies nicht leisten, denn jede Unreife ist ein Sicherheitsrisiko. Jeder Fehler kann Gemeinden, Unternehmen und die Nutzer selbst bei einem Angriff in Mitleidenschaft ziehen. Es braucht darum eine präzise Definition, wann eine Software reif genug ist, um sie dem Stresstest eines Bug-Bounty-Programms und der Nutzung durch die vorgesehene Zielgruppen auszusetzen.
Reife Software ist gehärtete Software
Abraxas hat darum als Voraussetzung zum Start des Abraxas Bug-Bounty-Programms Ende Mai 2022 und zum Start des öffentlichen Programms ab 22. August 2002 den Maturitätsbegriff genau definiert. «Das Abraxas Maturitätsmodell ist Bestandteil unserer Abraxas Security Frameworks», sagt Daniel Scherrer, Chief Software Architect von Abraxas. Mit dem jeweils an die Software, die Entwicklungsphase und die Kundenbedürfnisse angepassten Modell können wir sicher sein, dass die Software reif genug sein wird – so reif wie sie sein muss.»
Somit bestimmt die Maturität den Härtungsgrad einer Software, ehe sie dem Bug-Bounty-Programm oder der breiten Nutzung ausgesetzt wird. Wenn das Modell funktioniert und alle bekannten Schwachstellen beseitigt worden sind, stehen die Chancen gut, dass im Nachhinein kaum kritische Findings mehr auftauchen.
So sieht das Maturitätsmodell aus
Das Maturitätsmodell geht von Mindestanforderungen aus, die gemeinsam mit dem Business und Sicherheitsexperten definiert werden. Danach werden die damit verbundenen Themen definiert (beispielsweise Bug Bounty). In diesen Themen erfolgt eine Bewertung des Reifegrads.
Pro Thema ergeben sich verschiedene Maturitätslevels. Diese bauen aufeinander auf und wirken in einem Stream zusammen (Beispiel: sicherheitsgeprüfte Software → Private Bug Bounty → Public Bug Bounty). Die notwendigen Kriterien pro Stream sind in Kategorien zusammengefasst. Bei jedem einzelnen Kriterium wird der Reifegrad mittels Kriterium-Level analysiert und bewertet. Die Auswertung auf Ebene einer Kategorie umfasst die erforderlichen Levels und den Vergleich mit den Mindestanforderungen.
Themen
Thema 1 – Bug Bounty
Level 0: Pentest Classic (Readyness Bug Bounty)
Level 1: Private Bug Bounty (Security Challenger)
Level 2: Public Bug Bounty (Security Excellence)
Thema 2 – Offenlegung Source Code
Level 1: Offenlegung Source Code
Kategorien (für beide Themen)
- Compliance
- Dokumentation
- Organisatorisch
- Rechtlich
- Technisch (Source Code)
- Technisch (System)
- Technisch (Werkzeuge)
Kriterium-Levels
Incomplete
Kriterium wurde noch nicht vollständig umgesetzt. Der gewünschte Endzustand konnte noch nicht erreicht werden.
Implemented
Der gewünschte Endzustand wurde initial erreicht, die Prozesse oder Dienstleistungen sind jedoch organisatorisch noch nicht vollständig institutionalisiert worden. Die Wiederholbarkeit ist nicht gewährleistet.
Z. B. existieren Prozesse, aber die Zielorganisation wurde noch nicht konkret beauftragt (Rollen und Verantwortlichkeiten) – oder die Organisation wurde bereits beauftragt, aber die Durchführungsprozesse wurde noch nicht final definiert.
Managed
Der Prozess / die Dienstleistung wurde institutionalisiert, sowie alle notwendigen Rollen und Verantwortlichen sind explizit definiert. Institutionalisierung kann über Automatisierung oder manuelle Prozessdurchführung erfolgen. Die Wiederholbarkeit in geforderter Güte kann gewährleistet werden.
Optimized
Die Prozesse werden laufend gemessen, bewertet und durchlaufen einen kontinuierlichen Verbesserungsprozess. Durch die Wiederholung verbessert sich die Güte oder Dienstleistungsqualität laufend.
