Der PCI DSS 3.0 verlangt in Requirement 11.3 die Durchführung von Penetrationstests. Im älteren PCI-Standard 2.0 umfasste das bisher primär einen Penetrationstest auf Netzwerk- sowie auf Anwendungsebene, der sowohl von extern als auch von intern durchgeführt werden musste. Der Penetration Tester musste dabei natürlich qualifiziert und unabhängig sein.
Diese Punkte sind zwar inhaltlich auch im neuen PCI DSS 3.0 enthalten, jedoch wurden die Anforderungen und auch der Umfang der Penetrationstests erhöht. Nachfolgend möchte ich das neue Requirement 11.3 besprechen und auf die neuen Details eingehen.
11.3 Implement a methodology for penetration testing that includes the following:
– Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)
Durch den zwingenden Verweis auf eine allgemeine akzeptierte Best-Practice Vorgehensweise wie NIST SP800-115 sind damit alle Pentest-Monkeys raus, die einfach nur ein paar Tools wie Metasploit, Nessus & Co benutzen und das ganze dann in einen Report fassen. Andere aus meiner Sicht akzeptierte Vorgehensweisen sind der OWASP Testing Guide oder auch OSSTMM. Interessanterweise beinhaltet der NIST SP800-115 zwar auch Vorgehensweisen zum klassischen Penetration Testing, behandelt aber insgesamt das Thema „Information Security Testing and Assessment“. Ich hätte hier eigentlich einen Verweis auf ein reines Pentesting-Dokument erwartet. Damit deutet sich eine Erweiterung des eigentlichen Penetration Testing im Sinne des PCI DSS an, der z.B. zusätzlich auch technische Reviews beinhalten kann.
– Includes coverage for the entire CDE perimeter and critical systems
– Includes testing from both inside and outside the network
– Includes testing to validate any segmentation and scope-reduction controls
Die ersten beiden Punkte sind nicht neu. Der Pentest muss die gesamte PCI-Umgebung umfassen und von außen sowie von innen durchgeführt werden. Der dritte Punkt hat es dafür in sich: Die (oftmals vorhandene) Netzwerksegmentierung zwischen PCI-Scope und Nicht-PCI sowie die dafür eingesetzten Sicherheitsmaßnahmen müssen auf ihre Wirksamkeit hin geprüft werden. Mein erster Gedanke dabei war: Wie soll ein Penetration Tester das umsetzen? Eigentlich geht das nur über einen kompletten Review der Netzwerkpläne, Kommunikationsverbindungen und Firewall-Regeln, die für die PCI-Umgebung und die daran angeschlossenen Bereiche relevant sind. Das kann dann sicherlich durch einzelne klassische Techniken des Penetration Testing ergänzt werden, aber eigentlich fordert dieser Punkt mehr einen technischen Security-Audit. Diese Änderung geht dabei in die gleiche Richtig wie der vorher beschriebene Verweis auf den NIST SP 800-115. Der Penetrationstest wird mehr zu einem Security Assessment erweitert. Kernbestandteil bleibt zwar weiterhin der eigentliche Penetration Test, jedoch wird das der Umfang eines Penetrationstest im Sinne des PCI DSS durch die Änderung im neuen Standard 3.0 deutlich erweitert.
– Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
– Defines network-layer penetration tests to include components that support network functions as well as operating systems
– Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
– Specifies retention of penetration testing results and remediation activitiesresults.
Die letzten Punkte konkretisieren noch etwas genauer, was eigentlich geprüft werden soll, und dass gefundene Schwachstellen natürlich angemessen behandelt werden wollen. Das ist inhaltlich identisch mit dem alten Standard, außer dass noch ein Augenmerk auf die Bedrohungen und Schwachstellen der letzten 12 Monate gelegt werden muss. Die Umsetzung erfordert in diesem Punkt eine sehr gut gepflegte Dokumentation eines Unternehmens, welchen Bedrohungen und Schwachstellen es ausgesetzt war. Der Penetration Tester muss dann diese Punkte speziell nochmals verifizieren.
11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation
controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.
In der Häufigkeit der Pentests gab es keine inhaltliche Änderung: Jährlich oder nach signifikanten Änderungen. An der Frage, was eigentlich genau signifikante Änderungen sind, scheiden sich immer noch die Geister. Eigentlich ist der PCI-Standard da sehr deutlich, so ist z.B. ein neuer Webserver bereits eine signifikante Änderung. In der Praxis hängt das von der Bewertung des Auditors ab. Aus der reinen sicherheitsrelevanten Betrachtung wäre es natürlich optimal, nach jeder (signifikanten) Änderung einen Test durchführen zu lassen. In der Realität müsste man jedoch bei Tagessätzen von über 1.000€ für Pentester gleich das Security-Budget enorm aufwerten. Unternehmen müssen in der Praxis für die Auslegung des schönen Begriffs „signifikant“ viel Feingefühl verwenden. Ansonsten muss auch bei Änderungen der Segmentierung zwischen Scope vs. Non-Scope ein neuer Pentest durchgeführt werden.
Wie sonst auch oft im PCI DSS verstecken sich gerne in den Prüfprozeduren für die eigentlichen Anforderungen weitere Anforderungen. Im Bereich des Requirements 11.3 ist dieses auch so:
Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
Diese versteckte Anforderung in den Testprozeduren zum 11.3er wurde inhaltlich zum PCI-Standard 3.0 nicht geändert. Der Pentester muss kein QSA oder ASV sein und es wird kein konkreter Nachweis einer bestimmten Qualifikation gefordert. Sofern die Qualifikation offensichtlich ist, also der Pentester z.B. mehrere Jahre Berufserfahrung als Penetration Tester oder einschlägiger Zertifikate wie z.B. den OSCP nachweisen kann, ist die Sache klar. Ansonsten liegt es im Ermessen des Auditors. Unabhängig muss er verständlicherweise auch sein, d.h. entweder ist er gleich von einem anderen Unternehmen oder er ist innerhalb des Unternehmens unabhängig von der eigentlichen IT.
Insgesamt denke ich, dass die Änderungen im PCI DSS 3.0 bezüglich des Requirements 11.3 richtig und gut sind. Die Durchführung nach einem international akzeptierten Vorgehensmodell ist zwar keine Garantie für einen guten Penetrationstest, aber zumindest eine Voraussetzung dafür. Die neue Prüfung der Effektivität der Scope-Trennung wird primär nur durch den Einsatz von Reviews möglich sein. Letztendlich führt hier der Penetration Tester eine technisch fundiertere Analyse durch, als es ein Auditor bei der Festlegung vom Scope durchführen kann.
