So erfüllen Sie die PCI-DSS-Anforderung 6.6 – eine Zwei-in-eins-Lösung von Threat Stack

F5

Threat Stack heißt jetzt F5 Distributed Cloud App Infrastructure Protection (AIP). Beginnen Sie noch heute gemeinsam mit Ihrem Team mit der Nutzung von Distributed Cloud AIP.

Die aktuelle Version des PCI DSS ist 3.2.1 und wurde im Mai 2018 veröffentlicht. Anforderung 6 besagt, dass Sie „sichere Systeme und Anwendungen entwickeln und pflegen“ müssen. Klar, kein Problem. Das ist völlig eindeutig und unkompliziert – zumindest für alle, die noch nie versucht haben, sichere Systeme und Anwendungen zu entwickeln und zu pflegen! Für den Rest von uns ist das eine anspruchsvolle Aufgabe.

Das Dokument führt jedoch noch eine Reihe recht klarer Anforderungen auf – Maßnahmen, die bereits Bestandteil der meisten Lebenszyklen für sichere Softwareentwicklung sind. Sie sollten einen Prozess zur Identifizierung von Sicherheitslücken etablieren, bekannte Schwachstellen beheben, bewährte Programmierpraktiken anwenden, Entwicklungs- und Testumgebungen sowie die zugehörigen Konten sicher von der Produktionsumgebung trennen, Code-Reviews durchführen, einen Prozess zur Änderungskontrolle einrichten, Entwickler in sicheren Programmiertechniken schulen und so weiter. Alles durchaus vernünftig.

Etwas weiter unten unter dieser übergeordneten Anforderung – in Anforderung 6.5 – werden einige konkrete Schwachstellen aufgeführt, vor denen Anwendungen geschützt werden sollten. Dabei handelt es sich gewissermaßen um die „größten Hits“ aus den OWASP TOP 10, den SANS CWE Top 25, CERT Secure Coding usw. – also genau das, was man erwarten würde: SQL-Injection, schwache Kryptografie, XSS, Pufferüberläufe und Ähnliches. Auch das ist vernünftig. Angreifer nutzen solche Schwachstellen regelmäßig als ersten Angriffspunkt.

Dann kommt in Anforderung 6.6 der entscheidende Punkt: „Bei öffentlich zugänglichen Webanwendungen müssen neue Bedrohungen und Schwachstellen fortlaufend berücksichtigt und diese Anwendungen vor bekannten Angriffen geschützt werden.“ Vor welchen Angriffen? Die Antwort lautet: „mindestens vor allen in Anforderung 6.5 aufgeführten Schwachstellen.“ Denken Sie einen Moment darüber nach. Diese eine Anforderung – 6.6 –, die tief im Dokument auf Seite 64 verborgen ist, hat erhebliche Auswirkungen darauf, wie wir Software entwickeln und betreiben! Wie soll diese Anforderung erfüllt werden? Die Antwort besteht aus zwei Teilen:

• Durch die jährliche Überprüfung von Anwendungen sowie nach jeder Änderung – unter Verwendung „entweder manueller oder automatisierter Tools oder Methoden zur Bewertung von Sicherheitslücken“
• Durch den Einsatz „einer automatisierten technischen Lösung, die webbasierte Angriffe erkennt und verhindert“

Dies wirkt sich also sowohl auf die Build-Zeit als auch auf die Laufzeit von Webanwendungen aus und umfasst tatsächlich zwei völlig unterschiedliche Aktivitäten:

1. Anwendungen überprüfen, um proaktiv vorhandene Schwachstellen zu identifizieren (und anschließend sicherzustellen, dass sie behoben werden)

– Und –

2. Angriffe in Echtzeit erkennen und blockieren

Das ist keineswegs eine schlechte Anforderung. Wie es in den Leitlinien heißt: „Öffentlich zugängliche Webanwendungen sind bevorzugte Ziele für Angreifer, und mangelhaft programmierte Webanwendungen bieten ihnen einen einfachen Weg, sich Zugriff auf sensible Daten und Systeme zu verschaffen.“ Dem kann ich nur zustimmen. Die Herausforderung liegt in der praktischen Umsetzung dieser Anforderung.

Es gibt kaum konkrete Hinweise dazu, wie der erste Teil – die Überprüfung von Anwendungen – umgesetzt werden soll. Anwendungen sollten „entweder mit manuellen oder automatisierten Tools oder Methoden zur Bewertung von Sicherheitslücken“ überprüft werden. Das ist ziemlich allgemein gehalten.

Der zweite Teil enthält eine etwas konkretere Empfehlung. Sie sollten „eine automatisierte technische Lösung, die webbasierte Angriffe erkennt und verhindert (zum Beispiel eine Web Application Firewall), vor öffentlich zugänglichen Webanwendungen installieren, um den gesamten Datenverkehr kontinuierlich zu überprüfen“. Dies kam WAF-Anbietern zugute, deren Produkte für Teams, die Anforderung 6.6 erfüllen wollten, plötzlich zu einem Pflichtkauf zum Abhaken wurden. Beim ersten Teil der Anforderung hilft eine WAF jedoch nicht. Eine WAF ist kein Tool zur Sicherheitsbewertung: Sie weiß weder, was eine Anwendung tut, noch wie sie es tut. Sie versteht lediglich, was an eine Anwendung gesendet wird – nicht aber, was die Anwendung mit diesen Informationen möglicherweise tut oder auch nicht.

All dies führt dazu, dass viele Teams Schwierigkeiten haben, die Anforderung 6.6 in ihrer Gesamtheit zu erfüllen. Diese eine kurze Anforderung umfasst zwei wesentliche und sehr unterschiedliche Aspekte. Die meisten werden versuchen, den zweiten Teil mit einer WAF zu erfüllen und für den ersten Teil eine Reihe weiterer Verfahren zu kombinieren (manuelle Code-Reviews, automatisierte Quellcodeanalyse usw.).

Es gibt jedoch eine Alternative, mit der sich Anforderung 6.6 durch eine einzige Lösung erfüllen lässt. Wie Ihnen auffallen wird, enthält der PCI-Standard bei der Erwähnung einer WAF die Formulierung „zum Beispiel“. Das ist von Bedeutung (und war in früheren Versionen des Standards nicht enthalten). Damit wird anerkannt, dass es andere Technologien gibt, die Anwendungen schützen können, sofern sie „so konfiguriert sind, dass sie webbasierte Angriffe entweder blockieren oder eine Warnmeldung auslösen, die umgehend untersucht wird“. Application Security Monitoring – die einheitliche Anwendungssicherheitslösung, die Threat Stack seiner Cloud Security Platform® ohne zusätzliche Kosten hinzugefügt hat – deckt sowohl die Aspekte von Anforderung 6.6 während der Entwicklung als auch zur Laufzeit ab. Eine Lösung für diese beiden großen Herausforderungen.

Während der Build-Phase fügen Sie Ihren Anwendungen den Threat Stack-Microagent wie jede andere Codebibliothek eines Drittanbieters hinzu. Für Entwickler ist dies der Instrumentierung ihrer Anwendungen mit einer APM-Lösung sehr ähnlich. Sobald der Microagent hinzugefügt wurde, wird die Anwendung bei jeder Ausführung überprüft – sei es durch lokale manuelle Tests, automatisierte Tests in einem nächtlichen Build, Benutzerakzeptanztests und so weiter. PCI schreibt vor, dass die Anwendung „mindestens einmal jährlich und nach jeder Änderung“ überprüft werden muss. Threat Stack geht weit darüber hinaus und identifiziert kontinuierlich Sicherheitslücken – ohne dass Entwickler zusätzlichen Aufwand betreiben müssen. Es müssen weder Tests geschrieben noch Server verwaltet werden.

Sobald eine Schwachstelle identifiziert wurde, schreibt Anforderung 6.6 außerdem vor, dass sie behoben werden muss. Sie müssen sicherstellen, „dass alle Schwachstellen behoben werden und die Anwendung nach den Korrekturen erneut bewertet wird“. Threat Stack AppSec Monitoring bietet Entwicklern konkrete Handlungsempfehlungen zu allen erkannten Risiken: Es erläutert das Risiko, stellt Beispielcode zur Behebung bereit und verweist auf das genaue Modul, den Methodennamen sowie die Datei und Zeilennummer, an der das Risiko gefunden wurde. Sobald der Entwickler die Schwachstelle behoben hat, sind keine besonderen Schritte für eine „erneute Bewertung“ erforderlich – die Anwendung wird bei der nächsten Ausführung automatisch bewertet.

Zur Laufzeit besteht die Anforderung darin, „den gesamten Datenverkehr kontinuierlich zu überprüfen“, um die Anwendung vor bekannten Angriffen zu schützen. Auch dies übernimmt derselbe Threat Stack-Microagent. Wenn die Anwendung von der Entwicklungs- in die Produktionsumgebung überführt wird, wird der Microagent mit bereitgestellt (er ist als Abhängigkeit fest in die Anwendung integriert). Dort analysiert er sämtliche an die Anwendung gesendeten Web-Payloads auf Anzeichen eines Angriffs. Wird ein Payload als schädlich eingestuft, kann die Anfrage sofort blockiert werden. Teams werden über das Threat Stack-Portal, in Slack oder über andere ChatOps-Kanäle über den Angriff benachrichtigt. Damit wird die PCI-Anforderung, „webbasierte Angriffe entweder zu blockieren oder eine Warnmeldung zu erzeugen, die unverzüglich untersucht wird“, unmittelbar erfüllt.

PCI 6.6 hat es in sich. Die Vorgabe, „fortlaufend auf neue Bedrohungen und Schwachstellen zu reagieren und sicherzustellen, dass diese Anwendungen vor bekannten Angriffen geschützt sind“, erstreckt sich über zwei verschiedene Phasen des Softwareentwicklungszyklus (Entwicklung und Produktion) und umfasst zwei unterschiedliche Aufgaben (proaktive Schwachstellenbewertung sowie Erkennung und Abwehr von Angriffen in Echtzeit). Beides ist komplex und betrifft in der Regel unterschiedliche Teams. Sie benötigen dafür jedoch keine zwei separaten Tools. Application Security Monitoring von Threat Stack erfüllt beide Anforderungen mit einer einzigen Lösung, ohne die Entwicklung auszubremsen. Testen Sie sie noch heute!

Wenn Sie mehr erfahren oder Application Security Monitoring testen möchten, melden Sie sich für eine Demo der Threat Stack Cloud Security Platform an. Unsere Compliance- und Sicherheitsexperten besprechen gerne Ihre spezifischen Anforderungen mit Ihnen.

Referenz

PCI-DSS-Anforderung 6.6 aus „Anforderungen und Sicherheitsbewertungsverfahren“, Version 3.2.1, Mai 2018

6.6 Bei öffentlich zugänglichen Webanwendungen müssen neue Bedrohungen und Schwachstellen fortlaufend berücksichtigt und diese Anwendungen durch eine der folgenden Methoden vor bekannten Angriffen geschützt werden:

• Überprüfung öffentlich zugänglicher Webanwendungen mithilfe manueller oder automatisierter Tools oder Methoden zur Sicherheitsbewertung von Anwendungsschwachstellen, mindestens einmal jährlich sowie nach jeder Änderung
• Installation einer automatisierten technischen Lösung vor öffentlich zugänglichen Webanwendungen, die webbasierte Angriffe erkennt und verhindert (z. B. eine Web Application Firewall), um den gesamten Datenverkehr kontinuierlich zu überprüfen.

Threat Stack heißt jetzt F5 Distributed Cloud App Infrastructure Protection (AIP). Beginnen Sie mit Ihrem Team noch heute mit der Nutzung von Distributed Cloud AIP.

Über den Autor

F5

Weitere Blogbeiträge von F5