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

Die aktuelle Version des PCI DSS ist 3.2.1, veröffentlicht im Mai 2018. Anforderung 6 besagt, dass Sie „sichere Systeme und Applications entwickeln und pflegen“ müssen.  Klar, kein Problem. Das ist völlig klar und unkompliziert – zumindest für jeden, der noch nie versucht hat, sichere Systeme und Applications zu entwickeln und zu pflegen! Für den Rest von uns ist das eine große Herausforderung. 

Doch das Dokument führt darüber hinaus eine Reihe relativ einfacher Anforderungen auf – Dinge, die bereits zu den sichersten Softwareentwicklungszyklen gehören. Sie sollten einen Prozess zur Erkennung von Sicherheitslücken einrichten, bekannte Lücken schließen, Best Practices bei der Codierung anwenden, Entwicklungs- und Testumgebungen sowie Konten sicher von der Produktion trennen, Codeüberprüfungen durchführen, einen Änderungskontrollprozess einrichten, Entwickler in sicheren Codierungstechniken schulen usw. Alles ziemlich vernünftig. 

Etwas tiefer unter dieser Anforderung der obersten Ebene – in Anforderung 6.5 – werden eine Reihe spezifischer Schwachstellen aufgelistet, vor denen Applications geschützt werden sollten. Dies sind eine Art „Greatest Hits“ aus den OWASP TOP 10, SANS CWE Top 25, CERT Secure Coding usw. und sie sind das, was Sie erwarten würden – SQL-Injection, schwache Kryptografie, XSS, Pufferüberläufe und dergleichen. Nochmals: vernünftig. Angreifer zielen zuverlässig auf diese Art von Schwachstellen als ersten Angriffspunkt ab. 

Dann kommt in Anforderung 6.6 das Wichtigste: „Beschäftigen Sie sich bei öffentlich zugänglichen Web- Applications kontinuierlich mit neuen Bedrohungen und Schwachstellen und stellen Sie sicher, dass diese Applications vor bekannten Angriffen geschützt sind.“ Welche Angriffe? Die Antwort lautet: „Mindestens alle Schwachstellen in Anforderung 6.5.“ Denken Sie einen Moment darüber nach. Diese einzelne Anforderung (6.6) ist tief im Dokument auf Seite 64 vergraben und hat erhebliche Auswirkungen darauf, wie wir Software erstellen und betreiben! Wie wollen Sie diese Anforderung erfüllen? Die Antwort besteht aus zwei Teilen:

• Durch jährliches Überprüfen von Apps und nach jeder Änderung – mithilfe von „manuellen oder automatisierten Tools oder Methoden zur Sicherheitsbewertung von Schwachstellen“
• Durch den Einsatz „einer automatisierten technischen Lösung, die webbasierte Angriffe erkennt und verhindert“ 

Dies wirkt sich sowohl auf die Erstellungszeit als auch auf die Laufzeit von Applications aus und umfasst tatsächlich zwei völlig unterschiedliche Aktivitäten:

1. Überprüfung von Applications , um proaktiv vorhandene Schwachstellen zu ermitteln (und anschließend sicherzustellen, dass diese behoben werden)

- Und - 

2. Angriffe in Echtzeit erkennen und blockieren

Es ist überhaupt keine schlechte Anforderung. In der Anleitung heißt es: „Öffentlich zugängliche Web- Applications sind die Hauptziele von Angreifern, und schlecht codierte Web- Applications bieten Angreifern einen einfachen Weg, um Zugriff auf vertrauliche Daten und Systeme zu erhalten.“ Ich könnte nicht mehr zustimmen. Die Herausforderung besteht in der praktischen Umsetzung der Anforderung. 

Für den ersten Teil, das Überprüfen von Apps, gibt es nicht viele Anleitungen. Apps sollten „mithilfe manueller oder automatisierter Tools oder Methoden zur Sicherheitsbewertung von Schwachstellen“ überprüft werden. Das ist ziemlich weit gefasst. 

Der zweite Teil enthält eine etwas spezifischere Empfehlung. Sie sollten „vor öffentlichen Web Applications eine automatisierte technische Lösung installieren, die webbasierte Angriffe erkennt und verhindert (z. B. eine Web Application Firewall), um den gesamten Datenverkehr kontinuierlich zu überprüfen.“ Dies war ein Segen für die WAF-Anbieter, die plötzlich eine Selbstverständlichkeit für Teams hatten, die Anforderung 6.6 erfüllen wollten. Beim ersten Teil der Anforderung hilft eine WAF allerdings nicht. Eine WAF ist kein Tool zur Sicherheitsbewertung: Es hat keine Ahnung, was eine Application macht oder wie. Es versteht nur, was an eine Application gesendet wird – nicht, was die Application mit diesen Informationen tun kann (oder nicht).

Aus all diesen Gründen haben viele Teams Schwierigkeiten, die Gesamtheit von 6.6 zu bewältigen. In dieser einen kleinen Anforderung verbergen sich zwei wichtige und völlig unterschiedliche Bedürfnisse. Die meisten werden versuchen, den zweiten Teil mit einer WAF abzudecken und eine Reihe anderer Techniken zusammenstellen, um den ersten Teil anzusprechen (manuelle Codeüberprüfungen, automatisierte Quellcode usw.). 

Es gibt jedoch eine Alternative, die Anforderung 6.6 mit einer einzigen Lösung erfüllen kann. Sie werden feststellen, dass der PCI-Standard bei der Erwähnung von WAF die Phrase „zum Beispiel“ enthält. Dies ist von Bedeutung (und war in früheren Versionen des Standards nicht enthalten). Es wird anerkannt, dass es andere Technologien gibt, die Applications schützen können, solange sie „so konfiguriert sind, dass sie entweder webbasierte Angriffe blockieren oder eine Warnung generieren, die sofort untersucht wird.“  Application Security Monitoring – die einheitliche Application , die Threat Stack ohne zusätzliche Kosten zu seiner Cloud Security Platform® hinzugefügt hat – berücksichtigt sowohl die Build-Time- als auch die Runtime-Aspekte der Anforderung 6.6. Eine Lösung für diese beiden großen Herausforderungen. 

Zur Build-Zeit fügen Sie den Threat Stack-Mikroagenten wie jede andere Codebibliothek von Drittanbietern zu Ihren Applications hinzu. Entwickler finden es sehr ähnlich wie die Instrumentierung ihrer Applications mit einer APM-Lösung. Sobald der Mikroagent hinzugefügt wurde, wird die Application bei jeder Ausführung bewertet – sei es durch lokale manuelle Tests, automatisierte Tests in einem nächtlichen Build, Benutzerakzeptanztests usw. PCI gibt vor, dass die App „mindestens jährlich und nach allen Änderungen“ überprüft werden muss. Threat Stack geht noch weit darüber hinaus und identifiziert kontinuierlich Sicherheitslücken – und das ohne zusätzlichen Arbeitsaufwand für den Entwickler. Es müssen keine Tests geschrieben oder Server verwaltet werden.

Sobald eine Schwachstelle identifiziert wurde, muss diese gemäß Anforderung 6.6 behoben werden. Man müsse sicherstellen, „dass alle Schwachstellen behoben werden und die Application nach der Korrektur erneut evaluiert wird.“ Threat Stack AppSec Monitoring gibt Entwicklern umsetzbare Anleitungen zu allen erkannten Risiken. Es erläutert das Risiko, präsentiert Beispielcode zur Behebung des Risikos und verweist den Entwickler auf den genauen Modul- und Methodennamen sowie den Dateispeicherort und die Zeilennummer, wo das Risiko gefunden wurde. Sobald der Entwickler die Sicherheitslücke behoben hat, sind für die „Neubewertung“ keine besonderen Maßnahmen mehr erforderlich – die Application wird bei der nächsten Ausführung automatisch bewertet. 

Zur Laufzeit besteht die Anforderung darin, „den gesamten Datenverkehr kontinuierlich zu überprüfen“, um die Application vor bekannten Angriffen zu schützen. Derselbe Threat Stack-Mikroagent tut dies auch. Wenn die Application von der Entwicklung in die Produktion überführt wird, wird der Mikroagent mit übertragen (er wird als Abhängigkeit in die Application integriert). Von dort aus analysiert es alle an die Application gesendeten Web-Nutzdaten, um nach Anzeichen eines Angriffs Ausschau zu halten. Wenn festgestellt wird, dass eine Nutzlast bösartig ist, kann die Anforderung sofort gestoppt werden. Teams werden über das Threat Stack-Portal oder in Slack oder anderen ChatOps-Kanälen über den Angriff benachrichtigt. Damit wird die PCI-Anforderung erfüllt, „webbasierte Angriffe entweder zu blockieren oder eine Warnung zu generieren, die sofort untersucht wird.“

PCI 6.6 ist groß. Der Auftrag, „sich kontinuierlich mit neuen Bedrohungen und Schwachstellen zu befassen und sicherzustellen, dass diese Applications vor bekannten Angriffen geschützt sind“, deckt zwei separate Phasen des Softwareentwicklungszyklus (Entwicklung und Produktion) ab und beinhaltet zwei separate Aufgaben (proaktive Schwachstellenbewertung sowie Echtzeiterkennung und -prävention von Angriffen). Beide sind komplex und in der Regel sind unterschiedliche Teams daran beteiligt. Sie benötigen jedoch nicht zwei separate Tools, um diese Probleme anzugehen. Application Security Monitoring von Threat Stack erfüllt beide Anforderungen mit einer einzigen Lösung, die die Arbeit der Entwickler nicht verlangsamt. Probieren Sie es noch heute aus!   

Wenn Sie mehr erfahren möchten 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.