Sicherheits-Etikette: Security in der Softwareentwicklung
Security ist für Softwareentwickler ein zentrales Thema. Oft lauern die Gefahren dabei nicht in komplexen Systemen: Viele Sicherheitslücken lassen sich mit dem richtigen Vorgehen recht einfach vermeiden.
- Christoph Klünter
- Zara Gebru
Die zunehmende Digitalisierung führt dazu, dass Organisationen mit schnell wachsenden Datenmengen arbeiten. Damit entstehen immer mehr Sicherheitsrisiken, und die Berichte über neue Leaks häufen sich. Inzwischen umfasst die Datenbank haveibeenpwned.com des Sicherheitsforschers Troy Hunt mehr als vier Milliarden kompromittierte Accounts mit Usernamen und Passwörtern. Die Daten stammen fast ausnahmslos aus Angriffen auf große Organisationen mit personalstarken Entwicklerteams. Man sollte eigentlich annehmen, dass solche Organisationen besser mit Daten umgehen können. Das wirft die Frage auf, welche Schwachstellen sie übersehen haben.
Die in letzter Zeit bekannt gewordenen Hacks haben als ersten Angriffspunkt erstaunlicherweise fast immer recht einfach zu vermeidende Sicherheitslücken ausgenutzt. Dem Finanzdienstleister Equifax wurde zum Verhängnis, dass seine Software nicht auf dem aktuellen Stand war und die Verantwortlichen ein Sicherheitsupdate nicht eingespielt hatten. Uber hatte Passwörter im Code, mit deren Hilfe der Zugriff auf Server möglich war. Mit steigender Popularität von Cloud-Diensten kommt es auch immer häufiger zu Vorfällen, bei denen eine fehlerhafte Berechtigungsvergabe den Zugriff auf Daten für Außenstehende erlaubt. Vom US-Militär gestohlene Daten lagen auf öffentlich zugänglichen S3-Servern bei Amazon Web Services (AWS). Die Schwachstellen sind allgemein bekannt und tauchen regelmäßig in den OWASP Top 10 auf, einer Rangliste der häufigsten Schwachstellen in Webanwendungen, die das Open Web Application Security Project (OWASP) veröffentlicht.
Gemeinsame Grundlage für Sicherheit: Security Baseline
Zu einem sicheren Entwicklungsprozess gehört immer eine sogenannte Security Baseline, die Maßnahmen und Regeln umfasst, um eine grundlegende Sicherheit zu gewährleisten. Sie soll nicht festlegen, wie Teams arbeiten oder welche Verschlüsselung sie benutzen. Vielmehr soll die Richtlinie allen Teams eine Richtlinie an die Hand geben, die sie jeweils individuell ausarbeiten können. Eine Richtlinie sollte beispielsweise den Einsatz eines Passwortmanagers festlegen, nicht aber vorschreiben, welches Werkzeug die Mitarbeiter verwenden sollen. Auf diese Weise können Teams diejenigen Prozesse und Tools wählen, die für sie am besten passen. Das OWASP bietet hierfür einen guten Leitfaden (S. 20 ff.). Teams mit dieser Entscheidungsfreiheit sind motiviert, sich intensiv mit der Materie auseinanderzusetzen. Es ist nicht das Ziel, eine Liste mit Vorgaben zu kopieren und stumpf abzuarbeiten. Vielmehr geht es darum, einen Leitfaden zu nutzen, der sich an die Bedürfnisse der Organisation und des Projekts anpassen lässt.
Vielen Projektteams fällt es schwer, die projektspezifischen Anforderungen zu identifizieren. Es hat sich gezeigt, dass die Beteiligten hierfür Zeit investieren müssen. An der Diskussion sollten Teammitglieder in unterschiedlichen Rollen sowie andere Stakeholder beteiligt sein. Für die meisten Punkte einer Richtlinie ist kein Security-Experte erforderlich. Workshops mit den Teams behandeln typischerweise nahezu alle wesentlichen Aspekte. Bei der Diskussion der Security Baseline ist es essenziell, die Erfahrung aus früheren Projekten mit einzubringen.
Für viele Organisationen mag das nichts Neues sein. In den letzten Jahren waren Information Security Offices (ISO) dafür verantwortlich, Security Baselines zu erstellen. Die oben genannten Beispiele für Hackerangriffe zeigen aber, dass es noch erheblichen Verbesserungsbedarf gibt. Die größte Herausforderung liegt nicht darin, solche Richtlinien zu erarbeiten, sondern dafür zu sorgen, dass sie bekannt sind und alle Mitarbeiter sie befolgen. Dafür müssen die Informationen gut zugänglich und leserlich aufbereitet sein. Gerade an dem Punkt hapert es in vielen Fällen. Es reicht nicht, Vorgaben einfach irgendwo abzulegen. Die Teams müssen die Möglichkeit haben, diese Richtlinien anzupassen und sollten über Änderungen laufend informiert werden. Erfahrungsgemäß ist das selten der Fall. Oft kommt es vor, dass Teams die für sie wichtigen Informationen nicht finden und daher die Richtlinien im täglichen Entwicklungsprozess nicht beachten.
Wenn die Informationen zur Richtlinie verständlich sind, können Teams durch regelmäßige Self-Assessments selber bewerten, wie versiert sie sich im Umgang mit Security fühlen und damit den Anforderungen genügen. Wenn das der Fall ist, können sie die Ergebnisse anderen Teams zur Verfügung stellen. Häufig ist Stakeholdern nicht bewusst, welche Richtlinien es gibt und in welchem Zustand sich das Softwareprodukt befindet. Mit den Ergebnissen von Self-Assessments können alle leichter verstehen, welche Stories wichtig sind und entsprechend priorisieren.
Transparenz und Austausch
Das Ziel ist es, maximale Transparenz zu erreichen, sodass alle Beteiligten immer den Zustand der Security kennen und verstehen. Jedem sollte klar sein, welche Anforderungen zurzeit nicht erfüllt sind, und welche Risiken darin liegen. Diese Transparenz können Teams beispielsweise durch ein Dashboard realisieren. Hilfreich ist, wenn sich Änderungen schnell und einfach durchführen lassen. Eine Excel-Tabelle reicht daher in den meisten Fällen nicht aus.
Unterschiedliche Teams verantworten unterschiedliche Teile einer Richtlinie. Am Dashboard lässt sich sehen, welches Team was umgesetzt hat und welche Themen noch offen sind. Zusätzlich bietet Visualisierung die Möglichkeit, Muster zu erkennen. Wenn klar wird, dass alle Teams gleichermaßen an einem bestimmten Punkt hängen bleiben, können die Beteiligten das Problem gemeinsam angehen. Häufig sehen die Autoren in der Praxis beispielsweise, dass Teams mit Credentials im Code Probleme haben. Solche Probleme lassen sich gut teamübergreifend durch die Bereitstellung eines gemeinsamen Service wie Hashicorp Vault lösen. Auch Stakeholder können so besser verstehen, mit welchen Herausforderungen ein Team konfrontiert ist.
Der Einsatz eines Dashboards fördert außerdem den Austausch zwischen Teams. Wenn sie sehen, was andere Teams umgesetzt haben, können sie sich dort Inspiration und Hilfe abholen. Dabei geht es nicht um Kontrolle, sondern um ein einheitliches Verständnis innerhalb der gesamten Organisation. Zur Steuerung lässt sich ein solches System nicht einsetzen. Um sicherzustellen, dass das Dashboard die aktuelle Situation abbildet und Teams selbstbewusst den Status teilen, muss genügend Vertrauen zwischen den Teams und zu den Stakeholdern vorhanden sein.
Ein guter Ansatz, um mehr Sicherheit in Unternehmen zu bringen, ist in diesem Zusammenhang Gamification. Die Transparenz, die das Dashboard liefert, fördert den Wettbewerb zwischen den Teams. Man kann mit virtuellen Medaillen beziehungsweise Achievements nachhelfen, um den Spaß an der Arbeit zum Thema Sicherheit zu erhöhen.
