Heute habe ich an einer Präsentation über PCI DSS 3.0 gearbeitet. Da ein großer Kunde von mir ein internationaler Payment-Service-Provider ist, der Kreditkartentransaktionen abwickelt, kenne ich mich mit PCI DSS 2.0 gut aus. Den neuen Standard hatte ich vor einigen Monaten bereits gelesen, doch heute bin ich im Testing Procedure zu PCI-Requirement 6.6 (WAF) über einen interessanten Satz gestolpert, der mich in Sachen PCI DSS 3.0 ins Grübeln bringt.
PCI-DSS-Requirement 6.6 verpflichtet Unternehmen, entweder eine Web Application Firewall (oder ein technisches Äquivalent) einzusetzen, oder nach jeder Änderung manuelle bzw. automatisierte Schwachstellenbewertungen der Anwendung durchzuführen:
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
[..]
- Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.
Eine automatisierte Schwachstellenbewertung von Anwendungen ist etwas heikel und setzt ein Softwareentwicklungsteam sowie Prozesse auf einem hohen Reifegrad voraus. Ich gehe davon aus, dass die meisten Unternehmen Requirement 6.6 über eine Web Application Firewall (WAF) erfüllen. Unternehmen können dafür eigene Regelwerke für eine WAF schreiben, ein Regelwerk des WAF-Herstellers nutzen oder ein Regelwerk von OWASP (OWASP CRS Core Rule Set) verwenden. In jedem Fall ist es sinnvoll, den Blocking- bzw. Enforcing-Modus der WAF zu aktivieren, um Angriffe tatsächlich zu verhindern. Das ist Branchen-Best-Practice und wurde von PCI DSS verlangt – besser gesagt vielleicht verlangt –, wenn Unternehmen zur Erfüllung von Requirement 6.6 eine WAF eingesetzt haben.
Trotz zahlreicher weiterer Änderungen gibt es im Testing Procedure zu PCI-Requirement 6.6 einen neuen Satz, der etwas unglücklich formuliert ist. Man achte auf den letzten Satz:
6.6 For public-facing web applications, ensure that either of the following methods is in place as follows:
[..]
Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:
- Is situated in front of public-facing web applications to detect and prevent web-based attacks.
- Is actively running and up to date as applicable.
- Is generating audit logs.
- Is configured to either block web-based attacks, or generate an alert.
Ich wiederhole es gern noch einmal: Die WAF „ist so konfiguriert, dass sie web-basierte Angriffe entweder blockt oder einen Alarm erzeugt.“ Entschuldigung, aber was zum Teufel? Nach Jahren PCI DSS ist es jetzt also in Ordnung, eine WAF im Monitoring-Modus einzusetzen. Alarme erzeugen muss sie immerhin …
Im Web habe ich zwei Links gefunden, die das ebenfalls als Problem sehen: jemanden in hoher Position bei Gartner[1] sowie einige Folien zu PCI 3.0[2]. Ich habe versucht, das mit unserem QSA-Unternehmen zu klären, bekam aber nur die knappe Antwort, dass eine WAF Angriffe blocken müsse – zum letzten Satz im Testing Procedure von 6.6 gab es keinen Kommentar. Ich habe mich entschieden, eine E-Mail an das PCI DSS Council zu schreiben, und hoffe auf eine Antwort, die das erklärt. Ich werde sie veröffentlichen, falls und sobald ich eine bekomme.
Im Sinne der Sicherheit der Kreditkartendaten der Kunden hoffe ich sehr, dass das eine Art Versehen oder Tippfehler ist. Unabhängig davon gehe ich davon aus, dass es weltweit QSAs geben wird, die eine WAF im Monitoring-Modus akzeptieren – ob das ein Fehler war, ist zweitrangig, wenn PCI DSS wie ein Gesetzestext behandelt und nicht korrekt ausgelegt wird. Wenn das kein Fehler und absichtlich so geändert wurde, könnte ich diesen Sinneswandel im PCI Council kaum nachvollziehen.
[1] http://blogs.gartner.com/anton-chuvakin/2013-11-08/briefly-on-pci-dss-3-0/
[2] https://www.netspi.com/blog/entryid/207/things-not-to-overlook-in-the-new-pci-dss-3-0
30.10.2014: Die Antwort des Councils.