Sichere Software entwickeln mit OWASP SAMM
Seite 2: Implementierung – das richtige Werkzeug
Wenn es in die Implementierungsphase geht, denken viele zuerst an Secure Coding. Letzteres dürfen Teams zwar nicht vernachlässigen, aber OWASP SAMM legt ein Hauptaugenmerk auf den Einsatz von Werkzeugen, um Security in den Build- und Deployment-Prozess zu integrieren.
Das Automatisieren von Security-Checks in der Build-Pipeline bietet einen Basisschutz, um bestimmte Schwachstellenklassen frühzeitig zu erkennen. Des Weiteren empfiehlt OWASP SAMM Automatismen, die eingebundene externe Bibliotheken und Frameworks hinsichtlich bekannter Schwachstellen überprüfen. Wer sie automatisiert beim Implementieren erkennt, kann sie noch vor der eigentlichen Verifikationsphase beheben. Das erspart dem Security-Testteam Zeit, um sich auf die komplexeren Schwachstellenklassen konzentrieren zu können, die automatisiert nicht auffindbar sind.
Ähnlich verhält es sich im Deployment-Prozess. Der Fokus auf Automatisierung beugt Problemen vor, die durch menschliche Fehlleistungen entstehen. In der Vollausbaustufe ist der Verteilungsprozess nicht nur über alle Phasen hinweg automatisiert, sondern bezieht zusätzliche Security-Checks und Integritätsprüfungen ein – sowohl für die interne Entwicklung als auch für externe Komponenten. Als Spezialthema greift OWASP SAMM zudem das sichere Bereitstellen von Zugangsdaten und Schlüsselmaterial auf, um die menschliche Interaktion sowohl bei der initialen Verteilung als auch bei der späteren Erneuerung der Secrets zu minimieren und auf angemessen sichere Implementierungsmuster aufzubauen.
In welche Phase das Management von Defekten gehört, bleibt der Diskussion überlassen. In der Regel ist es eine querliegende Funktion über den gesamten Entwicklungszyklus. OWASP SAMM ordnet das Vorgehen der Implementierungsphase zu. Erklärtes Ziel ist, einen Prozess zu definieren, der identifizierte Schwachstellen behandelt, Metriken für die Steuerung ableitet und es der Organisation ermöglicht, für die Zukunft zu lernen. Der Prozess zeigt unter anderem auf, welche Schwachstellen regelmäßig auftreten, welche Auswirkungen sie auf den Entwicklungsprozess haben und wie schnell sie sich durchschnittlich beheben lassen. Teams können dadurch eine faktenbasierte Entscheidung darüber treffen, welche Bereiche der Entwicklung sie mit hoher Priorität verbessern müssen, um die wesentlichen Probleme rasch in den Griff zu bekommen.
Verification – ein Balanceakt
Software ohne umfassende Qualitätssicherung produktiv zu stellen, ist inzwischen in vielen Bereichen undenkbar geworden. Das betrifft insbesondere Sicherheitsüberprüfungen, da eine einzelne übersehene kritische Schwachstelle ausreicht, um die Gesamtsicherheit der Anwendung und potenziell der darunterliegenden Infrastruktur massiv zu gefährden.
Viele Organisationen stehen vor der Herausforderung, dass aufgrund schneller Release-Zyklen die Zeitfenster für Sicherheitstests immer schmaler werden. Das zwingt sie zu neuen Strategien, um trotzdem eine angemessene Testabdeckung und Testtiefe zu erreichen. Die richtige Balance zwischen Testautomatisierung und iterativen manuellen Tests durch Experten ermöglicht, sowohl einen initialen Grundschutz zu erreichen als auch laufend die Testabdeckung und Testtiefe zu steigern.
OWASP SAMM legt einen wesentlichen Schwerpunkt auf Sicherheitsüberprüfungen, die auf konkreten Security-Anforderungen aufbauen. Generische Tests haben weiterhin ihre Berechtigung, aber je konkreter die Sicherheitsanforderungen definiert sind, desto fokussierter kann das Testteam vorgehen. Freilich ist es nicht angenehm, wenn jemand den Finger dort in die Wunde legt, wo es besonders weh tut, aber das Ziel einer Sicherheitsüberprüfung muss sein, vor allem die Schwachstellen zu finden, die den größten Schaden verursachen können. Wenn die Analysten im Requirements Engineering einen guten Job erledigt haben, bilden die Sicherheitsanforderungen das Vorgehen entsprechend ab.
Wer dafür einen hohen Reifegrad anstrebt, muss bereit sein, unterschiedliche Testverfahren zu kombinieren. OWASP SAMM empfiehlt unter anderem Fuzz Testing, Denial of Service Benchmarks und Security Stress Tests, Regressionstests für behobene Schwachstellen sowie Testautomatisierung im Build- und Deployment-Prozess. Für den besseren Tiefgang kommen manuelle Security-Tests hinzu, die vorab definierte Abuse-Case-Szenarien und Business-Logik-Schwachstellen abdecken.
Erneut gilt es, die Angemessenheit nicht aus den Augen zu verlieren. Für Anwendungen mit einem sehr hohen Schutzbedarf, beispielsweise im Bereich der kritischen Infrastruktur, ist eine breit angelegte Teststrategie sinnvoll und notwendig. Bei Anwendungen mit einem niedrigeren Schutzbedarf sollten Teams jedoch abwägen, ob wirklich all diese Testverfahren notwendig sind, um eine ausreichende Testabdeckung und Testtiefe zu erreichen, bei der gleichzeitig der Testaufwand angemessen und wirtschaftlich bleibt.
