Shift Left - Secure by Design und agile Entwicklung
Seite 3: Clean ist nicht gleich Secure
Das Buch "Clean Code" [2] von Robert Martin alias Uncle Bob hat den Begriff des sauberen Codes geprägt. Eine häufige, fehlerhafte Annahme seitens der Entscheidungsträger ist jedoch, dass die korrekte Umsetzung eines Features sauberen Code impliziert und gleichzeitig die Sicherheit des Codes abdeckt.
Sicherer und sauberer Code haben gemeinsame Schnittmengen, sind jedoch nicht identisch. "Clean Code" propagiert Verständlichkeit, Wartbarkeit und Wiederverwertbarkeit von Code, sicherer Code bedarf hingegen zusätzlich eigener, vorab definierter Spezifikationen und deren Einhaltung. Sauberer Code ist allerdings häufig eine Voraussetzung für sicheren Code. Dennoch kann Code sauber geschrieben sein, ohne über Sicherheitsfeatures zu verfügen. Die saubere Implementierungen öffnet jedoch erst das volle Potenzial für Sicherheitsmaßnahmen.
Sauber geschriebener Code ist zudem besser abzusichern, da die Relationen von Komponenten und Funktionen zueinander klar definiert und abgrenzbar sind. Jedes Entwicklerteam, das nach Gründen sucht, um die Einhaltung und Umsetzung der "Clean Code"-Prinzipien zu propagieren, findet in der Sicherheit des Codes gute Argumente, die sich auch gegenüber Entscheidungsträgern ökonomisch erläutern lassen.
Gute Zeitplanung
Allgemein und insbesondere in der agilen Entwicklung rechnen Teams bei der Planung des nächsten Release zu wenig Zeit für das Härten der Codebasis ein. Im Sprint Planning gilt das Augenmerk zur Aufwandsabschätzung erstrangig der Zeit für die Entwicklung eines neuen Features. Damit ist jedoch der Zeitaufwand gemeint, den Entwickler brauchen, um die Funktionsweise umzusetzen. Das Härten findet höchstens implizit Beachtung, sofern es keine konkrete Forderung dazu gibt.
Wie viel Zeit Teams für die sichere Umsetzung eines Features veranschlagen müssen, hängt von der Funktionsweise, dem Stand des Produktinkrements, der bestehenden technischen Schuld und dem Vorwissen der Entwickler ab. Erfahrungswerte zeigen, dass moderat geschulte Entwicklerteams einfache Feature-Requests mit einem Zeitaufschlag von etwa 30 Prozent "sicher" umsetzen können. Wie in der agilen Entwicklung vorgesehen, sollte die Einschätzung des tatsächlichen Zeitaufwands jedoch dem Team obliegen. Da insbesondere am Anfang mit Fehlkalkulationen zu rechnen ist, mag es sinnvoll sein, die Zahl der übernommenen User-Stories gegenüber den bisherigen Sprints herabzusetzen.
Die richtigen Ansprechpartner
Wichtig ist, dass jedes Team Sicherheitsexperten hinzuzuziehen kann. IT-Sicherheit gliedert sich in zahlreiche, teilweise hochspezifische und komplexe Teilgebiete, für die hauptberufliche Sicherheitsexperten zuständig sind. Gute Programmierer sind hauptberuflich Entwickler und haben keinen Security-Fokus. Entwickler können nach einer IT-Sicherheitsschulung ebensowenig IT-Sicherheitsexperten ersetzen wie Letztere nach einem Programmierkurs Entwickler.
Die Sparte der auf Softwaresicherheit spezialisierten Entwickler befindet sich derzeit – insbesondere im europäischem Raum – noch im Aufbau. Bis eine hinreichende Durchsetzung der Entwicklerteams mit solchen Spezialisten stattgefunden hat, sind Unternehmen auf externe Fachexpertise im Bereich Sicherheit und deren gemeinsame Integration in die Entwicklung angewiesen. Es liegt in der Verantwortung der Projektleitung, für die organisatorischen, strukturellen und finanziellen Voraussetzungen zu sorgen, damit Teams bei Bedarf und Einschätzung unkompliziert einen Fachexperten hinzuziehen können. Das ist in den meisten Teams standardmäßig nicht gegeben.
Umgang mit technischen Schulden
Technische Schulden (Technical Debts) entstehen regelmäßig während der Entwicklung. Eine sinnvolle Best Practice ist es, den Umstand zu akzeptieren und das Aufarbeiten technischer Schulden als selbstverständlichen Bestandteil der Entwicklungsarbeit zu betrachten. Teams müssen dabei diese Auffassung nach außen kommunizieren. Es erweist sich als sinnvoll, regelmäßige Sprints einzuplanen, die ausschließlich der Bearbeitung technischer Schulden dienen. Das Budget hierfür lässt sich vorab als prozentualer Anteil der umgesetzten Projekte akquirieren, die letztlich für die technische Schuld verantwortlich sind. Alternativ besteht die untergeordnete Strategie darin, einen festgelegten Teil der veranschlagten Projektzeit für die Abarbeitung technischer Schulden anzusetzen. Der Ansatz ist untergeordnet, da die Gefahr besteht, dass unter dem Sprintdruck Teams die für die Aufarbeitung technischer Schulden angesetzte Zeit stattdessen für die Umsetzung eines Features nutzen und das Ausmaß der technischen Schuld nicht korrekt abschätzten.
Technische Schulden sind integraler Bestandteil der Entwicklung, und Projektverantwortliche sollten sie als solche handhaben – sowohl bezüglich der Zeit- als auch der Budgetplanung. Technical Debts haben negative Auswirkungen auf die Wartbarkeit, die weitere Entwicklung und die Sicherheit der Codebasis. Es gibt Untersuchungen, die den Aufwand für die Anpassung und (Weiter-)Entwicklung von Features in Projekten mit kontinuierlich akkumulierenden technischen Schulden um den Faktor 60 bis 100 erhöhen. Das bedeutet nicht nur eine erhebliche Steigerung der Kosten der einzelnen (Neu-)Implementierung, sondern ist zusätzliche eine nachhaltige Verlangsamung der Gesamtproduktion des Unternehmens durch eine längere Blockierung der Entwickler durch einzelne Projekte. Es ist somit im Interesse aller Beteiligter – insbesondere der Geschäftsführung –, die technischen Schulden einer Codebasis gering zu halten und kontinuierlich abzubauen.
Fortbildungen zu Secure Coding
Typischerweise liegt irgendwo in einem allgemein zugänglichen Ordner eine Liste mit Secure Coding Guidelines. Oft hängen zudem die OWASP Top 10 an einer öffentlichen Stelle aus. Der trügerische Schluss lautet: Security kann man im Vorbeigehen lernen, und jeder hat Zugang zu dem nötigen Material. Mitarbeiter lesen solche Dokumente jedoch meist nicht oder überfliegen sie bestenfalls. Häufig wissen langjährige Teams nicht mehr, wo solche Dokumente liegen, geschweige denn, welchen Nutzen sie daraus ziehen sollten. Ermahnende Worte, die zum Lesen der Guidelines aufrufen, sind wenig hilfreich, wenn Unternehmen dafür keine zusätzliche Zeit schaffen.
In bisher ungeschulten Teams hat es sich als hilfreich erwiesen, regelmäßig gemeinsame Trainingssessions einzuführen. Sie können beispielsweise zwischen zwei Sprints liegen und dürfen, müssen aber nicht, am aktuellen Produkt orientiert sein. Dazu kommen sowohl externe Schulungen als auch interne Projekte in Frage.
Einen guten und leichten Einstieg für interne Schulungen bietet unter anderem das OWASP-WebGoat-Projekt. Dabei handelt es sich um eine absichtlich unsicher gehaltene Webanwendung, die Teams nutzen können, um anhand der vorbereiteten Lektionen nach Schwachstellen im Code zu suchen und sie zu beheben. Im Anschluss an jede Lektion sollten Teams erarbeiten, inwiefern das Erlernte im aktuellen Projekt eine Rolle spielt und welche Komponenten dafür anfällig wären.
