In der Praxis ist es für Hersteller keine leichte Aufgabe, einen ausgeprägten Sicherheitsgedanken kontinuierlich in komplexe Softwareprojekte zu integrieren. Stephan Neumann, Head of usd HeroLab, und Torsten Schlotmann, Head of PCI Security Services, sprechen in unserer Blogserie über praktikable Ansatzpunkte und Möglichkeiten, die Sicherheit von Software dennoch wirksam zu verbessern.
- Teil 1: Gründe für mehr Sicherheit
- Teil 2: Sicherheit in die Unternehmenskultur verankern
- Teil 3: Anforderungs- und Bedrohungsanalyse
- Teil 4: Statische Codeanalyse
- Teil 5: Dynamische Codeanalyse und Vulnerability Management
Im fünften und letzten Teil unserer Software Security Blogserie sprechen unsere Experten mit uns über Ansatzmöglichkeiten bei bereits laufenden Software-Produkten: Schwachstellen aufzudecken mit einer dynamischen Codeanalyse und Einfallstore in Open-Source-Bestandteilen durch ein Vulnerability Management zu vermeiden.
Stephan Neumann: „Nun befinden wir uns in der Phase, in der die Anwendung noch nicht final ist, aber bereits in gewissen Teilen läuft und ein Programmteil ausführbar ist. Das ist ein guter Zeitpunkt über die Möglichkeit einer dynamischen Codeanalyse zu sprechen, denn diese setzt -anders als die statische Codeanalyse- ein lauffähiges Programm voraus. Ich kann Ihnen nur ans Herz legen, nicht bis zum Release der Software zu warten, um potenzielle Schwachstellen in Ihrer Software zu identifizieren. Prüfen Sie es, bevor es ein Angreifer mithilfe anderer Tools versucht. Eine solche Analyse lässt sich bereits in diesem Stadium des Entwicklungsprozesses mit Hilfe von Schwachstellenscannern durchführen. Zur Durchführung der Scans ist es wieder wichtig ein gewisses Knowhow vorzuweisen, aber vor allem gilt auch hier wieder: Haben Sie keine Angst und fangen Sie einfach an.
Um in der Anwendung Schwachstellen zu identifizieren, bieten sich zwei unterschiedliche Ansätze an: Zum einen kann ein voll automatisierter Webapplication-Scanner verwendet werden, wie zum Beispiel Qualys, Netsparker oder Arachni. Diese Scanner laufen nach einer initialen Konfiguration automatisiert über die Anwendung und identifizieren Schwachstellen. Ein Nachteil dieser Scanner ist aber, dass sie nur wenig Einsicht in ihre Abdeckung und Methoden preisgeben.
Ich persönlich bin eher ein Fan davon, einen kleineren und dedizierten Ansatz mit sogenannten Intercepting Proxys wie Burpsuite oder OWASP ZED Attack Proxy zu wählen. Diese können Anfragen aus einem Browser oder einer API-Plattform wie Postman abfangen, um diese im nächsten Schritt manuell zu testen oder automatisiert zu scannen. Das Tool gibt mir direkte Hinweise, welche Requests ich mir in Hinblick auf potenzielle Schwachstellen noch mal anschauen sollte und gibt den Entwickler*innen auch mehr Einsicht in die Netzwerkkommunikation.“
Torsten Schlotmann: „Ich kann Stephan hier nur zustimmen, möchte aber auch erwähnen, dass sich das Thema Schwachstellenanalyse mit dem Einsatz rein automatisierter Tools nicht vollständig erschlagen lässt. Diese Tools sind immer ein Stück weit limitiert in dem, was sie innerhalb der Software prüfen und somit an Schwachstellen aufzeigen können. Besonders Fehler in der Business Logik, lassen sich größtenteils nur über manuelle Tests -intern oder extern- finden. Das beste Ergebnis bringt daher sicherlich auch hier eine Kombination aus automatisiertem und manuellem Testen.
Als letzten Ansatzpunkt für mehr Sicherheit möchte ich noch ein Thema ansprechen, welches meiner Meinung nach einen immer größeren Stellenwert in der Softwareentwicklung einnimmt: das Vulnerability Management und in diesem Kontext besonders das Vulnerability Management für Open-Source-Komponenten. Heutzutage kommen die wenigsten Software-Produkte noch ohne Open Source aus. Daher ist es für Softwarehersteller essenziell, aber auch gleichzeitig eine erste Herausforderung, alle verwendeten Open-Source-Komponenten in der eigenen Anwendung zu identifizieren und zu dokumentieren. Nur so ist es möglich, zu analysieren, ob eingesetzte Komponenten in der aktuellsten beziehungsweise einer Version ohne Schwachstellen genutzt werden. Ohne diese Dokumentation besteht die Gefahr, dass eingebundene Open-Source-Komponenten vergessen werden und in ihrer veralteten Version gegebenenfalls über Schwachstellen verfügen.
Kommerzielle Tools und Open-Source-Lösungen können dabei helfen, regelmäßig zu überprüfen, ob Schwachstellen für die eingesetzte Version bekannt sind und falls notwendig, die Version entsprechend zu aktualisieren. Sie durchsuchen unter anderem Datenbanken und prüfen, ob die eingesetzte Version der Komponente über bekannte Schwachstellen verfügt beziehungsweise aktuellere Versionen verfügbar sind. Vulnerability Management sollte nicht nur im Rahmen der aktiven Entwicklung, sondern auch in der Maintenance-Phase nach dem Release durchgeführt werden.
Meine abschließende Empfehlung für diese Blogserie und ich bin sicher, Stephan stimmt mir hier zu: Alle vorgestellten Maßnahmen und Tools sollten regelmäßig eingesetzt werden. Denken Sie daran, Sicherheit in allen Phasen des Software Development Lifecycles, also auch nach dem Release und in der aktiven oder passiven Maintenance-Phase, zu verankern. Die Bedrohungslage entwickelt sich ständig weiter, immer neue Schwachstellen werden erkannt. Bleiben Sie daher up-to-date und testen Sie Ihre Anwendung regelmäßig – beispielsweise durch Penetrationstests, statische oder dynamische Codeanalyse oder manuelle Code Reviews.“
