Wie steigere ich systematisch die Security-Kompetenz in meinem Team?
Softwareprodukte aller Art geraten immer häufiger ins Visier von Cyber-Attacken. Dennoch wird dem Thema Security in der Softwareentwicklung weiterhin zu wenig Priorität eingeräumt. Das liegt auch an der unzureichenden Sensibilisierung und Ausbildung der Fach- und Führungskräfte. Ein Grund, warum eine systematische Herangehensweise wichtig ist.
Weltweit berichten Online-Nachrichtenportale fast täglich über Sicherheitsvorfälle in allen Arten von Softwareprodukten. Mehrere Sicherheitsberichte bestätigen diesen Eindruck und kommen zu dem Schluss, dass es eine wachsende Anzahl von Sicherheitslücken, Angriffen und Vorfällen gibt. Ein eindrucksvolles Beispiel liefert die US-Behörde NIST: Im Jahr 2021 sammelte sie insgesamt 20.137 Schwachstellen, pro Tag ergibt das durchschnittlich 55 neue Schwachstellen. Und jedes Jahr wächst die Anzahl der neu entdeckten Schwachstellen deutlich.
Aber auch in Deutschland nimmt die Zahl an Security-Meldungen stetig zu. Das zuletzt mit Abstand prominenteste Beispiel ist sicherlich die aufgrund der Corona-Pandemie entstandene Luca-App, die zahlreiche schwerwiegende Sicherheitslücken aufwies. Beispielsweise war es möglich, sowohl die Daten der Nutzer:innen zu stehlen als auch die Gesundheitsämter anzugreifen. Aber sind dies Einzelfälle oder existiert ein grundsätzliches Problem in deutschen Unternehmen?
Um diese Frage zu beantworten und den aktuellen Stand der Software-Security in den deutschen Unternehmen zu analysieren, haben wir in unserem Forschungsprojekt AppSecure.nrw eine umfassende Studie durchgeführt [1]. Das Ergebnis: Die Gewährleistung sicherer Softwareprodukte ist eine vielschichtige Herausforderung für die Unternehmen und es besteht ein hoher Handlungsbedarf. Im Allgemeinen fehlt es den meisten Entwickler:innen, Product Ownern und Führungskräften gleichermaßen an der Sensibilisierung für das Thema Software-Security und an der notwendigen Security-Kompetenz für ihre spezifischen Rollen. Gleichzeitig hat unsere Studie aufgedeckt, dass es derzeit keine systematische Vorgehensweise gibt, um sowohl die Sensibilisierung als auch die Security-Kompetenz zu steigern.
In diesem Beitrag möchten wir unsere Studienergebnisse kurz vorstellen und im Anschluss eine Liste von Maßnahmen präsentieren, die wir erarbeitet haben, um den identifizierten Problemen und Herausforderungen entgegenzuwirken. Alle Maßnahmen haben dabei stets das Ziel, systematisch die Software-Security-Kompetenz in den Unternehmen zu steigern und somit den Schutz vor erfolgreichen Angriffen zu erhöhen.
Die AppSecure.nrw Software-Security-Studie
Unsere frei verfügbare Studie besteht aus zwei Teilen: einer repräsentativen Online-Umfrage, die von 256 Entwickler:innen vollständig ausgefüllt wurde und 17 Interviews mit Product Ownern und Führungskräften. Im Folgenden möchten wir über den beruflichen Hintergrund der Teilnehmenden und über unsere Erkenntnisse zu den Themen Prozesse, Werkzeuge, Kompetenz, Kompetenzaufbau und Sensibilisierung berichten.
Beruflicher Hintergrund
Von den 256 Entwickler:innen geben 61 Prozent an, über mehr als zehn Jahre Berufserfahrung in der Softwareentwicklung zu verfügen. 40 Prozent der Entwickler:innen in kleinen und mittleren Unternehmen, die anderen 60 Prozent in Großunternehmen. Die Geschäftsmodelle ihrer Unternehmen sind sehr unterschiedlich: Software wird innerhalb des Unternehmens eingesetzt (55%), an Kunden lizenziert (36%) und/oder direkt für Kunden entwickelt (28%). 15 Prozent der Entwickler:innen werden auch an andere Unternehmen geschickt. Die Entwickler:innen arbeiten dabei in verschiedenen Bereichen: Web (66%) und Backend (59%) stehen im Mittelpunkt, gefolgt von Desktop (37%), Mobile (25%) und Embedded (14%).
Die befragten Product Owner und Führungskräfte kommen aus kleinen, mittelständischen und großen Unternehmen. Sie entwickeln Software für verschiedene Industriezweige (z. B. Automotive, Gesundheitswesen und Versicherungen). Darüber hinaus gibt fast die Hälfte an, Software für mehr als einen Industriesektor zu entwickeln. Auch die Geschäftsmodelle ihrer Unternehmen unterscheiden sich stark: Software wird für den internen Gebrauch, den direkten Kundenauftrag oder den Lizenzverkauf entwickelt. Zwei Interviewpartner arbeiten auch für Unternehmen, die ihre Mitarbeitenden in andere Unternehmen entsenden.
Prozesse
Für ein sicheres Endprodukt ist der Entwicklungsprozess von entscheidender Bedeutung. Wie viele andere Expert:innen empfehlen wir auch den Ansatz Security-by-Design, der folgende Idee hat: Im gesamten Entwicklungsprozess wird Security von Anfang an und durchgängig mit betrachtet (s. Abb. 1). In unserer Studie haben wir daher untersucht, ob dieser Security-by-Design-Gedanke bereits heute gelebt wird. Das Ergebnis: 59 Prozent der Entwickler:innen geben an, dass sie keine klar definierten Richtlinien und Prozesse zur sicheren Softwareentwicklung haben. Zudem sagen 41 Prozent, dass ihre Security-Anforderungen (z. B. zur Verarbeitung sensibler Daten) nicht klar definiert bzw. bekannt sind. Mehr als die Hälfte (56%) meint keine passende Sammlung an Werkzeugen zu haben, um Software sicher zu entwickeln. Darüber hinaus analysieren 20 Prozent zu keinem(!) Zeitpunkt des Prozesses ihre Software bezüglich Security.
Spezifisch für die Product Owner und Führungskräfte hat unsere Studie ergeben, dass fast alle von ihnen selten proaktiv Maßnahmen ergreifen. Beispielsweise stellen nur wenige Product Owner Sicherheitsanforderungen an das Produkt und fordern auch nicht ein, dass das Team Ihnen begründet, warum das Produkt sicher ist. Die Führungskräfte ergreifen ebenfalls selten Maßnahmen, um beispielsweise die Software-Security-Kompetenz ihrer Mitarbeitenden zu erhöhen. Während der Entwicklung spielt Software-Security insgesamt eine sehr untergeordnete Rolle, einzig der Klassiker – der abschließende Pentest – wird von den Product Ownern und Führungskräften regelmäßig als Maßnahme genannt.
Werkzeuge
Security-Werkzeuge unterstützen Entwickler:innen, Fehler zu vermeiden bzw. frühzeitig zu finden und zu beheben. Zusätzlich können durch Security-Werkzeuge manuelle und zeitaufwändige Tätigkeiten automatisiert werden, wodurch nicht nur Zeit eingespart, sondern auch Fehler und dadurch mögliche Vorfälle deutlich reduziert werden können. Wir haben daher die Entwickler:innen gefragt, inwiefern sie Security-Werkzeuge nutzen: Im Anforderungsmanagement und im Entwurf werden Werkzeuge von weniger als 20 Prozent eingesetzt. Während der Implementierung nutzen immerhin 35 Prozent der befragten Entwickler:innen Werkzeuge, um Security-Eigenschaften automatisch zu überprüfen (s. Abb. 2). Darüber hinaus gibt ein Großteil der Entwickler:innen an, Werkzeuge zur statischen Codeanalyse einzusetzen (52%). Dennoch bedeutet dies, dass selbst während Implementierung und Betrieb eine Vielzahl keine Security-Werkzeuge einsetzt. Darüber hinaus gibt eine deutliche Mehrheit der Entwickler:innen an, dass mehr oder bessere Werkzeuge ihnen helfen würden, ihre Aufgaben besser zu erfüllen.
Die meisten Product Owner und Führungskräfte geben an, dass ihre Entwickler:innen nur Werkzeuge nutzen, von denen sie selbst überzeugt sind. Dadurch kann es vorkommen, dass für den gleichen Zweck unterschiedliche Werkzeuge im Einsatz sind – insbesondere, wenn es mehrere kostenfreie Alternativen gibt. Für die Anschaffung von kostenpflichtigen Werkzeugen verfügen die befragten Product Owner und Führungskräfte in der Regel über ausreichend Budget. Allerdings achten sie hier anders als beim Einsatz von kostenfreien Werkzeugen genau auf den Mehrwert, der bei der Nutzung der Werkzeuge entsteht. Erst wenn ihre Entwickler:innen den Mehrwert ausreichend begründen können, unterstützen sie die Anschaffung. Allerdings berichten die Product Owner und Führungskräfte, dass die Entwickler:innen nur sehr selten vorschlagen, ein kostenpflichtiges Werkzeug zu beschaffen.
Security-Kompetenz
Um die Security-Kompetenz der Entwickler:innen zu bewerten, haben wir sie gebeten, eine Selbsteinschätzung in zehn Software-Security-Themen (u. a. Eingabeprüfung, Penetrations-Tests, Incident Response) durchzuführen. Hierbei hat sich gezeigt, dass die meisten Entwickler:innen die Themen kennen, was sehr erfreulich ist. Jedoch sind ihre praktischen Erfahrungen in diesen Themen sehr verschieden – beispielsweise haben 61 Prozent praktische Erfahrungen in der Eingabeprüfung, aber nur 21 Prozent praktische Erfahrungen in der Durchführung einer Bedrohungsanalyse (s. Abb. 3).
Anschließend haben wir die Entwickler:innen gefragt, ob sie der Meinung sind, dass die aktuellen Fähigkeiten ihres Teams ausreichen, um Software sicher zu entwickeln oder zu betreiben. Zwei Drittel sagen, dass dies nicht der Fall ist. Gleichzeitig antworteten aber auch 70 Prozent der Entwickler:innen, dass jedes Mitglied des Teams über hohe Kompetenzen bzgl. Software-Security haben sollte (s. Abb. 4). Darüber hinaus haben wir alle Entwickler:innen gefragt, ob sie jeweils selbst durch Expert:innen im Thema der sicheren Softwareentwicklung weitergebildet werden möchten. Eine deutliche Mehrheit von 89 Prozent bestätigt diese Aussage. Unser Fazit ist daher, dass nahezu alle Entwickler:innen nicht nur mehr Kompetenzen bei ihren Teams, sondern auch bei sich selbst als notwendig erachten.
Bzgl. der Product Owner und Führungskräfte haben wir herausgefunden, dass viele von ihnen nicht über die nötigen Kompetenzen verfügen und es Diskussionsbedarf über ihre Rolle zum Thema Software-Security gibt. Dies empfinden auch die meisten Product Owner und Führungskräfte so: zwei Drittel wünschen sich jeweils selbst mehr Kompetenzen. Zudem haben Product Owner und Führungskräfte nur wenige Anforderungen an die Software-Security-Kompetenz ihrer Entwickler:innen. Darüber hinaus variieren diese wenigen Anforderungen je nach befragter Person stark. Die meisten Anforderungen beziehen sich dabei auf die Disziplin Implementierung & Test. Für die anderen Disziplinen (Anforderungen, Entwurf und Release) werden nahezu keine Anforderungen genannt. Auf die Frage, ob ihre Entwickler:innen mehr Kompetenzen bzgl. Software-Security benötigen antwortet jedoch mehr als die Hälfte der Product Owner und Führungskräfte, dass dies der Fall ist.
Kompetenzaufbau
Den meisten Entwickler:innen, Product Ownern und Führungskräften sind die im deutschsprachigen Raum angebotenen Schulungen nicht bekannt, obwohl der Großteil von ihnen zuvor erklärt hat, dass ein Ausbau der Security-Kompetenzen notwendig ist. Zudem sind zwei Drittel der Entwickler:innen, die die angebotenen Trainings kennen, damit nicht zufrieden.
Ein weiteres Umfrageergebnis ist, dass sich nur 55 Prozent der Entwickler:innen regelmäßig über (neue) potenzielle Sicherheitslücken informieren. Dabei sind Online-Nachrichtenseiten wie Heise ihre meistgenannten Quellen. Zudem haben wir gefragt, ob die Entwickler:innen regelmäßig an Meet-ups und Konferenzen zu Sicherheitsthemen teilnehmen. Nur 23 Prozent bestätigen dies. Darüber hinaus wünschen sich die Entwickler:innen unterschiedliche Formate, um ihre Kompetenzen zu erweitern. Beliebt sind insbesondere Möglichkeiten zum Selbststudium, trainerbasierte Präsenzschulungen und Fernschulungen. Eine eindeutige Präferenz gibt es dabei allerdings nicht.
Die Product Owner und Führungskräfte ermutigen ihre Entwickler:innen aktiv, ihre allgemeine Software-Entwicklungs-Kompetenz durch Schulungen, Konferenzen oder Selbststudium zu erhöhen. Veranstaltungen zum Thema Software-Security werden von ihnen jedoch nicht vorgeschlagen oder eingefordert. Darüber hinaus wissen die meisten von ihnen nicht, ob ihre Entwickler:innen an Veranstaltungen mit Security-Bezug teilnehmen. Eine selten erwähnte Ausnahme ist die Maßnahme zur Ernennung und Ausbildung von Security-Champions. Dies sind Entwickler:innen, die über eine hohe Security-Kompetenz verfügen und ca. 20 Prozent ihrer Arbeitszeit in Software-Security investieren. Dabei sollen diese Champions nicht alleinig für die Security verantwortlich sein, sondern vielmehr als Multiplikatoren fungieren und das Team ermutigen und so befähigen, dass jedes Teammitglied seinen Teil zur Gewährleistung der Security beiträgt.
Sensibilisierung
In den vorangegangenen Abschnitten hat sich gezeigt, dass sowohl die Qualität der Prozesse, die Verbreitung geeigneter Werkzeuge als auch die Security-Kompetenz meist eher gering sind. Eine mögliche Ursache hierfür könnte eine unzureichende Sensibilisierung einzelner oder gar aller Beteiligter sein. Für die Auswertung unserer Studie haben wir die Sensibilisierung daher in drei Kategorien unterteilt:
- Keine Sensibilisierung: Eine Person ist für das Thema Software-Security nicht sensibilisiert, wenn ihr das Thema unbekannt ist oder sich ihr dessen Nutzen nicht erschließt. Selbstverständlich sehen Personen dieser Gruppe keinen Handlungsbedarf, Kompetenzen auszubauen, Prozesse zu verbessern oder Werkzeuge zu nutzen.
- Geringe Sensibilisierung: Eine Person, der das Thema Software-Security bekannt ist und die dessen Bedeutung grob verstanden hat, ist mindestens gering sensibilisiert. Damit ein Thema bekannt ist, genügt grundlegendes Verständnis. Ein Indiz für eine geringe Sensibilisierung ist, wenn die Person nicht proaktiv Maßnahmen durchführt, um die Security zu gewährleisten.
- Umfassende Sensibilisierung: Für eine umfassende Sensibilisierung bzgl. Software-Security ist ein Bewusstsein für Datensicherheit und Angriffssicherheit unerlässlich. Personen dieser Gruppe wissen um die Risiken von Datenverlust, -diebstahl und -manipulation. Sie handeln, falls sie Missstände erkennen und können ihre Aufgaben und ihre Verantwortung im Kontext Security benennen.
Für die Entwickler:innen hat unsere Studie ergeben, dass die meisten von ihnen nur gering für das Thema Software-Security sensibilisiert sind – dies bestätigen auch die befragten Product Owner und Führungskräfte. Es gibt jedoch jeweils auch Entwickler:innen, die entweder gar nicht oder sogar sehr umfassend sensibilisiert sind. Darüber hinaus haben wir eine unpassende Selbsteinschätzung vieler Entwickler:innen festgestellt: Für jede Disziplin (Anforderungen, Entwurf, Implementierung & Test, Release) geben die Entwickler:innen an, dass sie auf den Aspekt Security achten – gleichzeitig haben sie nur selten Maßnahmen (Vorlagen, Standards, Verfahren, Werkzeuge, Experten, Reviews) in Kraft, die eine systematische Gewährleistung der Software-Security ermöglichen.
Die meisten Product Owner und Führungskräfte sind ebenfalls nur gering sensibilisiert. Niemand bezweifelt, dass Software-Security ein wichtiges Thema ist – jedoch können nur die allerwenigsten konkrete Maßnahmen benennen, um eine Gewährleistung der Software-Security zu erreichen. Die Bedeutung der Themen Angriffssicherheit und Innentäter ist leider nur den wenigsten Befragten bewusst. Vereinzelt gibt es jedoch auch umfassend sensibilisierte Product Owner und Führungskräfte. Diese berichten jedoch, dass ihre Kolleg:innen, ihre Führungskräfte und ihre Kund:innen meist nur gering sensibilisiert sind, was ihr Wirken stark erschwert.
Ein kurzes Zwischenfazit
Auch wenn wir hier nur einen kleinen Einblick in unsere Studie geben konnten, so wurde hoffentlich klar, dass ein dringender Handlungsbedarf für softwareentwickelnde Unternehmen in Deutschland besteht. Denn zum einen sind die befragten Entwickler:innen, Product Owner und Führungskräfte zumeist nur gering sensibilisiert und haben eine unzutreffende Selbsteinschätzung. Zum anderen hat unsere Studie aufgezeigt, dass alle Beteiligten mehr einschlägige Kompetenz benötigen. Obwohl nahezu alle Teilnehmenden der Studie sich einen Kompetenzausbau wünschen, geschieht dieser bisher nur vereinzelt und unsystematisch.
Es gilt daher alle Beteiligten noch stärker als bisher zu sensibilisieren und ihnen Konzepte zum systematischen Kompetenzaufbau aufzuzeigen. Im Folgenden möchten wir hierzu erste Ergebnisse vorstellen.
Konzept zum systematischen Kompetenzaufbau
Allein mit neuen Prozessen und Werkzeugen lassen sich die beschriebenen Herausforderungen nicht bewältigen. Der Blick auf das Thema muss sich grundsätzlich ändern: Software-Security ist eine Aufgabe für das gesamte Team – inklusive Product Owner und Führungskräfte. Sie alle müssen für das Thema Software-Security stärker als bisher sensibilisiert werden. Zudem müssen alle Beteiligten ihre Rolle kennen und über die hierfür notwendige Kompetenz verfügen, sodass sie die Software-Security ihrer Produkte gewährleisten können.
Damit Software-Security-Kompetenz bei den Entwickler:innen aufgebaut werden kann, genügen unserer Meinung nach die klassischen zweitägigen Schulungen nicht, da die Wissenslücke einfach zu groß ist. Gleichzeitig hat unsere Studie gezeigt, dass das aktuelle Schulungsangebot unzureichend ist. Aus diesem Grund haben wir neue Intensivschulungen entwickelt: das Security-Champion-Training und den Programmierwettbewerb BiFiRi. Beide Formate fokussieren primär die Entwickler:innen. Da es für Product Owner und Führungskräfte bisher keine rollenspezifischen Schulungen gab, haben wir für diese ebenfalls neue Schulungsformate erstellt.
- Das Security-Champion-Training [2]: Ziel dieses Trainings ist es, motivierte und security-begeisterte Softwareentwickler:innen zu Security-Champions auszubilden. Wie zuvor bereits angerissen, ist ein Security-Champion weiterhin Mitglied des Teams, besitzt jedoch umfangreiches Wissen bzgl. Software-Security, um Sicherheitslücken der Software bzw. Probleme im Entwicklungsprozess zu erkennen und das Team auf Probleme hinzuweisen. Letztlich soll sich das Team durch das Wirken des Security-Champions selbstverantwortlich um die Security seines Produktes kümmern können.
- Der Programmierwettbewerb BiFiRi [3]: Das BiFiRi (Break it, Fix it, Review it) ist eine Adaption des in der universitären Lehre bekannten BiBiFi (Build it, Break it, Fix it). In unserer Variante dauert es jedoch nur vier Tage statt eines vollen Semesters, dient aber ebenfalls zur praktischen Erprobung und Vertiefung der eigenen Software-Security-Kompetenzen in Form eines teamübergreifenden Wettstreits.
Das Training für Product Owner [4] soll erreichen, dass diese das Thema Software-Security in ihre Produkte nachhaltig etablieren. Damit dies möglich wird, müssen die Product Owner ihre Rolle bzgl. Software-Security verstehen und anschließend die notwendigen Kompetenzen (Risikomanagement, Incident Response, Teambefähigung) lernen. Begleitet wird dies von einem Coaching-on-the-Job.
Die Führungskräfte[5] erhalten ebenfalls ein auf sie abgestimmtes Training, ähnlich dem der Product Owner. Hier gilt es jedoch, die notwendigen Kompetenzen zu vermitteln, um die eigene Organisationseinheit systematisch und strategisch aufzustellen. Hierzu zählen Themen wie die Mitarbeiterweiterbildung, die Schaffung einer Organisationskultur, die Software-Security entsprechend priorisiert und wertschätzt, sowie die Etablierung neuer Software-Security-Prozesse.
Neben dem Erwerb von notwendigen Kenntnissen in rollenspezifischen Schulungen ist es wichtig, dass die Kompetenzen des Teams systematisch ausgebaut werden und einen Mehrwert für das Produkt bieten. Um den Reifegrad eines Teams zu ermitteln und auszubauen, haben wir daher das Reifegradmodell Security Belts für agile Teams entwickelt.
- Das Reifegradmodell Security Belts für agile Teams [6]: Wie es der Name schon andeutet, werden bei den Security Belts die einzelnen Reifegrade – analog zu Judo und Karate – als Gürtel dargestellt. Sie werden dem gesamten Team verliehen, da wir der Meinung sind, dass die Gewährleistung der Security eine Teamaufgabe ist und es nicht genügt, wenn nur einzelne Personen sich darum kümmern. Ein Gürtel umfasst dabei mehrere Aktivitäten aus verschiedenen Bereichen, wobei jede Aktivität zur nachhaltigen Verbesserung der Software-Security beiträgt. Die Gürtel sind dabei nach Kosteneffizienz sortiert: Aktivitäten mit hohem Nutzen und wenig Aufwand sind in frühen Gürteln zu finden, während Aktivitäten mit niedrigerem Nutzen und höherem Aufwand in den späteren Gürteln zu finden sind.
Fazit und Ausblick
Das Thema Software-Security stellt Unternehmen vor vielschichtige Herausforderungen. Dies zeigen nicht nur die täglichen Meldungen über Sicherheitsvorfälle aller Art, sondern auch unsere Studie zum Stand der sicheren Softwareentwicklung in deutschen Unternehmen. Entwickler:innen, Product Ownern und Führungskräften fehlt es gleichermaßen an der Sensibilisierung für das Thema Software-Security und an wichtiger Sicherheitskompetenz für ihre spezifischen Rollen.
In diesem Beitrag haben wir verschiedene Maßnahmen vorgestellt, um den identifizierten Problemen und Herausforderungen entgegenzuwirken. Alle Maßnahmen haben dabei stets das primäre Ziel die Sensibilisierung und die Software-Security-Kompetenz in den Unternehmen zu steigern und somit den Schutz vor erfolgreichen Angriffen zu erhöhen.
- AppSecure.nrw
- Fraunhofer IEM: Security-Champion-Training
- Programmierwettbewerb BiFiRi (Webseite ist in Erstellung)
- Training für Product Owner
- Training für Führungskräfte (Webseite ist in Erstellung)
- Reifegradmodell "Security Belts" für agile Teams
