67 Seiten füllt die neue Version 1.0 des Software Security Frameworks (PDF) der Payment Card Industry (PCI). Es beschreibt die wichtigsten Sicherheitsgrundsätze des Secure-Software-Lifecycle (Secure SLC)-Standards. Dazu gehören unter anderem Governance, Erkennung von Bedrohungen, Erkennung und Eindämmung von Schwachstellen, Sicherheitstests, Änderungsmanagement, sichere Softwareaktualisierungen und Kommunikation mit dem Stakeholder.
Foto: Seksan 99 - shutterstock.com
Im Zuge der neuen Version weitet die PCI auch sie zulässigen Testmethoden aus. Neben SAST (Static Analysis Security Testing) und DAST (Dynamic Analysis Security Testing) stehen jetzt auch die Softwarekomponentenanalyse (SCA) sowie insbesondere IAST (Interactive Application Security Testing) auf der Liste anzuwendender Technologien. Um sich die Vorteile dieser beiden Methoden zu erschließen und gleichzeitig die Compliance aufrechtzuerhalten, müssen Unternehmen gegebenenfalls ihre internen Standards anpassen.
SCA
Mit SCA-Tools lässt sich Software automatisiert nach verwendeten Open-Source-Komponenten durchsuchen. Ziel ist es, Risikomanagement, Sicherheit und Lizenz-Compliance zu erleichtern. In moderner Software finden sich zahlreiche Open-Source-Bausteine, die oft mit etlichen Sicherheitsrisiken einhergehen können.
Großen Schaden richtete beispielsweise eine Struts-2-Schwachstelle beim amerikanischen Dienstleister Equifax an. Apache Struts ist ein bei Banken und Behörden beliebtes Open-Source-Framework, um Java-basierte Web-Anwendungen zu bauen, die sowohl Front- als auch Backend-Web-Services betreiben. Über die Schwachstelle, bei der Nutzereigaben nicht ausreichend validiert wurden, konnten die Angreifer Daten von 143 Millionen Verbrauchern abgreifen, die bei dem Finanzdienstleister gespeichert waren. Die Schwachstelle war bereits zwei Monate vor dem Leck bekannt und von Apache gepatcht worden aber Equifax versäumte es, das Update zeitnah zu implementieren.
- CI/CD
Continuous Integration beziehungsweise Continuous Delivery wird oft als essenzieller Teil einer erfolgreichen DevOps-Strategie gesehen. Meist ist die Kombination beider Methoden gemeint, um schneller stabilen Code ausliefern zu können. - Continuous Integration (CI)
Dieser Begriff beschreibt eine Methode, um fortlaufend Veränderungen im Code in den Hauptzweig zu integrieren, die anschließend automatisiert getestet werden. Damit erhalten Entwickler innerhalb weniger Minuten Rückmeldung, ob der Build die Qualitätsansprüche erfüllt. Zudem vermeiden sie den hohen Aufwand, der entsteht, wenn sämtliche Code-Anpassungen auf einmal am Tag der Veröffentlichung in den Release-Zweig integriert werden müssen. - Continuous Delivery (CD)
Dies beschreibt die automatisierte Auslieferung von Anwendungs-Code an diverse Infrastruktur-Umgebungen wie Entwicklungs-, Test, Integrations- und Produktivumgebungen. - Integrated Developer Environments (IDE)
Integrierte Entwicklungsumgebungen sind Anwendungen, die dabei helfen, Anwendung zu bauen. Darin sind normalerweise ein Code-Editor, Compiler, Debugger und Tools zur Build-Automatisierung enthalten, um zeitaufwändige, händische Aufgaben aus der Entwicklung zu entfernen. - Software Development Lifecycle (SDLC)
Es gibt verschiedene Vorgehensmodelle zur Softwareentwicklung, die unterschiedliche Phasen des Software-Lebenszyklus definieren. Die für DevOps verwendeten wiederholbaren Modelle verwenden meist ein kreisförmiges Schema, in denen oft die Stufen Analyse („Was soll die App können?“), Entwurf/Entwicklung, Implementierung, Test und Wartung/Evaluation enthalten sind. - Static Application Security Testing (SAST)
SAST ist eine Methode, um die Sicherheit von Anwendungen während der Entwicklung zu testen. Dabei wird der Quellcode „von innen heraus“ auf Schwachstellen und Bugs hin analysiert. Da der Code für die Analyse nicht kompiliert sein muss, kann SAST sehr früh im Entwicklungszyklus eingesetzt werden, um so Fehler bereits in der Entstehung zu beseitigen. - Regressionstest
In einem Regressionstest werden Testfälle wiederholt, um sicherzustellen, dass Modifikationen in bereits getesteten Teilen der Software keine neuen Fehler („Regressionen“) verursachen.
IAST
IAST, also das interaktive Testen, ist eine relativ junge Methode, die eine Applikation auf Schwachstellen untersucht während sie ausgeführt wird. Das schließt automatisierte Tests, Funktionstests durch Anwender oder sonstige Ausführung und Interaktion mit der Anwendung mit ein. So entdeckte Schwachstellen werden in Echtzeit an Tester und Testverantwortliche geschickt. Dadurch fällt keine zusätzliche Zeit für die CI/CD-Pipeline (Continuous Integration/Continuous Delivery) durch die Tests an.
IAST arbeitet aus der Applikation heraus und unterscheidet sich daher von statischer (SAST) und dynamischer (DAST) Analyse, die im Wesentlichen von außen den Quellcode oder die Applikation als Blackbox untersucht. Als Bestandteil der Applikation selbst fällt die Analyse leichter, da der Datenfluss genauer beobachtet und damit besser analysiert werden kann. Das führt zu weniger Falschmeldungen (False Positives). Zwar liefert IAST auch keine hundertprozentig akkuraten Ergebnisse, Benchmarks zeigen jedoch Verbesserungen gegenüber den bisherigen Technologien auf.
Die Abdeckung (die Anzahl getesteter Schrittstellen oder untersuchter Codezeilen) ist dabei genauso wie bei den bisherigen Testmethoden. IAST-Produkte geben aber auch Aufschluss über die Abdeckung, um den Anwender nicht in falscher Sicherheit zu wiegen.
Es müssen keine speziellen Sicherheitstests vorbereitet werden, denn mit IAST wird jegliche Ausführung automatisch zum Sicherheitstest. IAST soll, je nach Einschätzung und Produkt, SAST und DAST nicht nur ergänzen, sondern sogar ersetzten können. Das ist im Augenblick aber noch ein strittiges Thema zwischen den Herstellern. Nicht so sehr umstritten ist die Tatsache, dass IAST unter Umständen SCA ersetzen kann. Eingesetzte Frameworks und Bibliotheken können genauso wie eigener Code im laufenden Betrieb untersucht werden.
Foto: Mirko Brandner
Anwender, die mit den Ergebnissen von SAST und DAST nicht zufrieden sind, können nun auf IAST wechseln und dennoch den PCI-Standard erfüllen. Im Sinne eines modernen Security-by-design-Ansatzes gilt es, Software sowohl schnell als auch sicher zu entwickeln sowie Softwaretests zu automatisieren. Daher kann sich IAST zu einer Standardtechnologie für DevOps und DevSecOps entwickeln.
WAF und RASP
Der neue PCI-Standard ist umfangreich und gibt der Software-Entwicklung mehr Freiheiten. Zugleich fordert er aber nicht nur umfangreiche Tests während des Entwicklungsprozesses sondern auch, Schwachstellen und Angriffe im produktiven Einsatz zu erkennen.
Um dies umzusetzen, stehen Sicherheitsexperten Lösungen wie Web Application Firewalls (WAFs) oder Runtime Application Self Protection (RASP) zur Verfügung. Letztere überprüft auf Anwendungsebene ständig alle Aufrufe und Befehle und kann so beispielsweise vor SQL-Injection schützen. Der Standard nennt diese Lösungen in dem Zusammenhang zwar nicht explizit, sie erfüllen diese Anforderungen aber in hohem Maße.
Ähnlich wie bei den Testmethoden stehen sich bezüglich WAF- und RASP-Produkten alte und neue Technologien strittig mit Vor- und Nachteilen gegenüber. Wo die eigenen Präferenzen auch liegen mögen, Verantwortliche aus Entwicklungs- und Security-Abteilungen sollten einen genauen Blick in den neuen Standard werfen. Die erweiterten Möglichkeiten bieten einige Vorteile, um Softwareentwicklung sowohl effizienter als auch sicherer zu machen.