Sicherheits-Etikette: Security in der Softwareentwicklung

Inhaltsverzeichnis

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.

Bewusstsein schaffen und Wissen aufbauen

Dadurch, dass sich die Teams regelmäßig mit den Themen der Security Baseline beschäftigen und wissen, wie es um die Sicherheit bestellt ist, entsteht ein Bewusstsein für das Thema. Gleichzeitig lässt sich damit das Anti-Pattern des sogenannten Security Sandwich vermeiden. Dabei handelt es sich um ein Phänomen, bei dem das Beschreiben der Anforderungen an die Security zwar am Anfang eines Projektes steht, die Umsetzung und Überprüfung dagegen erst gegen Ende erfolgt, beispielsweise durch einen einzelnen Penetrationstest am Schluss der Entwicklung. In der Praxis kann ein solches Vorgehen zu einer deutlichen Verzögerung des Projektes oder sogar zu einem Abbruch führen.

Wissensaufbau und Übungen

Der kontinuierliche Aufbau von Wissen und Bewusstsein zum Thema Sicherheit bei den Teammitgliedern lässt sich durch themenspezifische Workshops unterstützen. Der Juice-Shop hilft beispielsweise beim Verständnis für klassische Angriffe auf Webapplikationen und für deren Abwehr. Auch Übungen zu Threat Modeling helfen, Probleme im eigenen Produkt zu finden und zu verstehen.

Wenn Unternehmen die Verantwortung für die Sicherheit nicht in die Hände von Projektteams legen, sondern in dedizierten Teams verankern, führt das häufig dazu, dass der Aspekt der Sicherheit vernachlässigt wird. In klassischen Umgebungen sind Infrastruktur-Teams dafür verantwortlich, Standards und Anforderungen festzulegen. Viele kennen das Warten auf Firewall-Freigaben oder neue Accounts. Wenn Teams sich nicht eigenständig um diese Komponenten kümmern können, entstehen mehrere Probleme. Zum einen fördert es die Tendenz, Vorgaben zu umgehen. Teammitglieder teilen Accounts oder beantragen großzügige Firewall-Freigaben, um sich die Mühe weiterer Anträge zu ersparen. Zudem kann sich auf diese Weise kein Bewusstsein für Sicherheit entwickeln. Kein Team wird sich darum kümmern, nicht mehr benötigte Accounts oder Freigaben wieder entfernen zu lassen.

Die beste Möglichkeit, diese Probleme zu vermeiden, ist der Einsatz von Automation und Self-Service. Wenn die Teams innerhalb von Sekunden ihre Infrastruktur anpassen können, ist das eine wesentliche Erleichterung für ihre Arbeit. Im Idealfall existiert sogar ein Log, in dem alle sehen können, was wann warum angelegt wurde. Das Stichwort ist "Infrastructure as Code". IT-Infrastrukturen, die sich automatisch per Code verwalten und bereitstellen lassen, haben sich im Cloud-Umfeld schon lange bewährt, sind aber im Rechenzentrum genauso wertvoll. Viele Infrastruktur-Teams schrecken davor zurück, so viel Verantwortung aus der Hand zu geben. Die Erfahrung zeigt aber, dass diese Angst unbegründet ist, wenn in den Teams durch Transparenz und Selbsteinschätzung ein Bewusstsein für Security entstanden ist.

Fazit

Die Autoren sehen immer wieder, dass die Security nicht den Stellenwert bekommt, den sie verdient hat. Das liegt aber meistens nicht an den Teams, sondern an den Umständen. Teams wissen sehr genau, wo die Schwachstellen in ihrer Software liegen, haben aber keine Motivation oder Möglichkeit, sie zu beseitigen. Durch mehr Transparenz und einen spielerischen Umgang mit Security werden beide Hindernisse behoben. Teams vergleichen sich, sehen, was möglich ist und werden dadurch zum Handeln motiviert. Gleichzeitig erkennen alle den Zustand der Software, und es ist einfacher, Zeit und Mittel für die Beseitigung der Schwachstellen zu finden.

Da Security eine nichtfunktionale Anforderung an die Software ist, stellt Priorisierung für viele Stakeholder eine Herausforderung dar. Ein zusätzliches Feature hat wesentlich mehr Sichtbarkeit als ein verhinderter Datendiebstahl. Deshalb ist Transparenz äußerst wichtig. Das Risikomanagement muss sich der Risiken und der Kosten bewusst sein. Viele Teams schrecken davor zurück, sich um Security zu kümmern, weil sie sich überfordert fühlen. An dem Punkt lässt sich der Hebel ansetzen: Der erste Schritt zu höherer Sicherheit ist die Transparenz, die gleichzeitig einen besseren Wissensstand mit sich bringt. Die ersten Schritte in Richtung sicherer Software sind nicht schwierig. Für den weiteren Weg lässt sich, wenn erforderlich, auf externe Hilfe zugreifen.

Christoph Klünter
ist ein Infrastruktur-Techniker bei ThoughtWorks. In den letzten 15 Jahren hat er sich hauptsächlich mit Themen rund um Rechenzentren, Skalierung und Sicherheit beschäftigt.

Zara Gebru
ist Softwareentwicklerin bei ThoughtWorks und interessiert sich besonders für IT Security sowie für die Digitalisierung im Bildungsbereich.

(rme)