Bauen Sie keine Security-Tools, sondern Developer-Tools

Dieser Beitrag erschien ursprünglich am 3. November 2017 auf CSO Online.

Leiterinnen und Leiter der Application Security sowie Anbieter verfolgen seit Langem das schwer erreichbare Ziel, Entwicklerinnen und Entwickler für Security zu gewinnen. Dahinter steht teilweise der Wert, Security von Anfang an einzubauen, vor allem aber die schiere Menge und das Tempo. Entwicklerinnen und Entwickler sind den Security-Fachleuten zahlenmäßig im Verhältnis 100 zu 1 überlegen, und die Geschwindigkeit moderner Entwicklung macht es für jedes externe Team unmöglich, Schritt zu halten. Und doch erreichen wir dieses Ziel immer wieder nicht.

Security-Lösungen werden in Development-Tools integriert, Security-Anforderungen in den regulären Anforderungsprozess aufgenommen und Security-Schulungen vierteljährlich wiederholt. Trotzdem gerät Security in Vergessenheit, sobald das Security-Team nicht mehr eingebunden ist. Wie können wir diesen Kreislauf durchbrechen?

Der Schlüssel zum Erfolg: Hören Sie auf, Security-Tools zu entwickeln, die an Dev denken, und entwickeln Sie stattdessen Dev-Tools, die Security berücksichtigen. Das mag wie ein semantischer Unterschied wirken, verändert aber grundlegend, wie wir Security-Tools und -Programme betrachten.

Die Bedürfnisse von Entwicklerinnen und Entwicklern in den Mittelpunkt stellen

Wenn ein Security-Team einen Prozess festlegt, stehen typischerweise die eigenen Bedürfnisse am Anfang. Es muss wissen, woran die Entwicklerinnen und Entwickler arbeiten, sicherstellen, dass bestimmte Kontrollen angewendet werden, und bestimmte Tests vorschreiben. Verständlicherweise konzentrieren sich der Prozess oder die Tools stark darauf, die Anforderungen an Security, Compliance oder Governance sowie die Bedürfnisse des Security-Teams zu erfüllen.

Um Entwicklerinnen und Entwickler wirklich einzubinden, müssen wir sie als wichtigste Nutzergruppe unserer Lösung betrachten und Security und Compliance als unterstützende Funktionen verstehen. Wie kann diese Security-Praxis dazu beitragen, das Ausfallrisiko zu senken? Wie verbessert sie die Kommunikation und Zusammenarbeit im Team? Wie ermöglicht sie es weniger erfahrenen Entwicklerinnen und Entwicklern, größere Aufgaben zu übernehmen? Wenn Sie die Security-Anforderungen im Hinblick auf die Ziele der Entwicklung neu formulieren, stehen die Chancen deutlich besser, dass sie erfüllt werden.

Den Ausgangspunkt ändern

Fast immer versuchen wir, Security-Praktiken an den Dev-Workflow anzupassen. Wir versuchen, statische Analysen in den Build-Prozess einzubinden, und stellen dann fest, dass sie dafür zu lange dauern. Wir führen diese Analysen in der IDE aus, trauen den Entwicklerinnen und Entwicklern aber nicht zu, falsch-positive Ergebnisse zu verwerfen. Wir weisen auf eine bekannte Schwachstelle hin, obwohl die angesprochene Person nicht in der Lage ist, sie zu bewerten.

Gute Developer-Tools gehen von der anderen Seite aus. Wie läuft der Entwicklungsprozess ab? Wann bietet diese Security-Kontrolle den größten Mehrwert und wann stört sie am wenigsten? Was sind die wichtigsten Voraussetzungen für eine erfolgreiche Integration an diesem Punkt? Wenn Sie Antworten auf solche Fragen haben, können Sie Ihre Security-Lösung mit den richtigen Prioritäten entwickeln.

Diese Fragen können auch bestehende Tools in der Pipeline ans Licht bringen, die sich für Security-Prozesse nutzen lassen. So sprach das Security-Team von PagerDuty in einer Folge des Podcasts The Secure Developer über den Einsatz von Splunk für Security-Zwecke. In einer anderen Folge erläuterte Adam Jacobs von Chef, wie InSpec Ihre Security-Posture verbessern kann.

Andere Vergleichsmaßstäbe für Ihre Produkte wählen

Developer-Tools haben sich im letzten Jahrzehnt rasant weiterentwickelt. Angetrieben wurde dies von der DevOps-Revolution und davon, dass Entwicklerinnen und Entwickler mehr Handlungsspielraum erhielten. Ausgehend von den erfolgreichsten Tools haben sich Best Practices entwickelt, die von Benutzerfreundlichkeit und Preisgestaltung bis hin zur Bedeutung einer guten Dokumentation reichen.

Vergleichen Sie Ihre Web-App-Firewall also nicht mit Ihrer Netzwerk-Firewall, sondern mit einem erfolgreichen APM-Tool (Application Performance Monitoring). Stellen Sie Ihre AppSec-Testtools Lintern und Code-Review-Tools gegenüber, nicht Netzwerk-Security-Scannern. Diese Tools haben den Weg in den Alltag und die Herzen von Entwicklerinnen und Entwicklern gefunden, die sich inzwischen regelmäßig auf sie verlassen. Wenn Sie ihre Funktionsweise nachahmen, fügt sich Ihr Tool problemlos in das Denkmodell und den Prozess der Entwicklung ein.

Meine Beispiele beziehen sich zwar etwas stärker auf Tools als auf Prozesse, doch das Prinzip gilt für beides. Auch sichere Entwicklungspraktiken profitieren davon, die Bedürfnisse der Entwicklerinnen und Entwickler in den Mittelpunkt zu stellen, von den aktuellen Dev-Methoden auszugehen und sie mit den anderen Praktiken und Prozessen des Engineering-Teams zu vergleichen. Eine verpflichtende Security-Praxis läuft ständig Gefahr, übergangen zu werden. Eine Entwicklungspraxis hingegen – auch wenn sie Security behandelt – kann sich viel natürlicher etablieren.

Wenn Sie Entwicklerinnen und Entwickler für Security gewinnen möchten, entwickeln Sie keine Security-Tools. Entwickeln Sie Developer-Tools, die Security unterstützen, und erleben Sie, wie sehr sich das auf die Akzeptanz auswirkt.