Der PCI DSS 3.0 verlangt in Requirement 11.3 die Durchf\u00fchrung von Penetrationstests. Im \u00e4lteren PCI-Standard 2.0 umfasste das bisher prim\u00e4r einen Penetrationstest auf Netzwerk- sowie auf Anwendungsebene, der sowohl von extern als auch von intern durchgef\u00fchrt werden musste. Der Penetration Tester musste dabei nat\u00fcrlich qualifiziert und unabh\u00e4ngig sein.<\/p>\n
Diese Punkte sind zwar inhaltlich auch im neuen PCI DSS 3.0 enthalten, jedoch wurden die Anforderungen und auch der Umfang der Penetrationstests erh\u00f6ht. Nachfolgend m\u00f6chte ich das neue Requirement 11.3 besprechen und auf die neuen Details eingehen.<\/p>\n
11.3 Implement a methodology for penetration testing that includes the following:
\n– Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)<\/p><\/blockquote>\nDurch 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\u00e4tte 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\u00e4tzlich auch technische Reviews beinhalten kann.<\/p>\n
– Includes coverage for the entire CDE perimeter and critical systems
\n– Includes testing from both inside and outside the network
\n– Includes testing to validate any segmentation and scope-reduction controls<\/p><\/blockquote>\nDie ersten beiden Punkte sind nicht neu. Der Pentest muss die gesamte PCI-Umgebung umfassen und von au\u00dfen sowie von innen durchgef\u00fchrt werden. Der dritte Punkt hat es daf\u00fcr in sich: Die (oftmals vorhandene) Netzwerksegmentierung zwischen PCI-Scope und Nicht-PCI sowie die daf\u00fcr eingesetzten Sicherheitsma\u00dfnahmen m\u00fcssen auf ihre Wirksamkeit hin gepr\u00fcft werden. Mein erster Gedanke dabei war: Wie soll ein Penetration Tester das umsetzen? Eigentlich geht das nur \u00fcber einen kompletten Review der Netzwerkpl\u00e4ne, Kommunikationsverbindungen und Firewall-Regeln, die f\u00fcr die PCI-Umgebung und die daran angeschlossenen Bereiche relevant sind. Das kann dann sicherlich durch einzelne klassische Techniken des Penetration Testing erg\u00e4nzt werden, aber eigentlich fordert dieser Punkt mehr einen technischen Security-Audit. Diese \u00c4nderung 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 \u00c4nderung im neuen Standard 3.0 deutlich erweitert.<\/p>\n
– Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
\n– Defines network-layer penetration tests to include components that support network functions as well as operating systems
\n– Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
\n– Specifies retention of penetration testing results and remediation activitiesresults.<\/p><\/blockquote>\nDie letzten Punkte konkretisieren noch etwas genauer, was eigentlich gepr\u00fcft werden soll, und dass gefundene Schwachstellen nat\u00fcrlich angemessen behandelt werden wollen. Das ist inhaltlich identisch mit dem alten Standard, au\u00dfer 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.<\/p>\n
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).
\n11.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).
\n11.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
\ncontrols\/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.<\/p><\/blockquote>\nIn der H\u00e4ufigkeit der Pentests gab es keine inhaltliche \u00c4nderung: J\u00e4hrlich oder nach signifikanten \u00c4nderungen. An der Frage, was eigentlich genau signifikante \u00c4nderungen 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 \u00c4nderung. In der Praxis h\u00e4ngt das von der Bewertung des Auditors ab. Aus der reinen sicherheitsrelevanten Betrachtung w\u00e4re es nat\u00fcrlich optimal, nach jeder (signifikanten) \u00c4nderung einen Test durchf\u00fchren zu lassen. In der Realit\u00e4t m\u00fcsste man jedoch bei Tagess\u00e4tzen von \u00fcber 1.000\u20ac f\u00fcr Pentester gleich das Security-Budget enorm aufwerten. Unternehmen m\u00fcssen in der Praxis f\u00fcr die Auslegung des sch\u00f6nen Begriffs „signifikant“ viel Feingef\u00fchl verwenden. Ansonsten muss auch bei \u00c4nderungen der Segmentierung zwischen Scope vs. Non-Scope ein neuer Pentest durchgef\u00fchrt werden.<\/p>\n
Wie sonst auch oft im PCI DSS verstecken sich gerne in den Pr\u00fcfprozeduren f\u00fcr die eigentlichen Anforderungen weitere Anforderungen. Im Bereich des Requirements 11.3 ist dieses auch so:<\/p>\n
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).<\/p><\/blockquote>\n
Diese versteckte Anforderung in den Testprozeduren zum 11.3er wurde inhaltlich zum PCI-Standard 3.0 nicht ge\u00e4ndert. 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\u00e4giger Zertifikate wie z.B. den OSCP nachweisen kann, ist die Sache klar. Ansonsten liegt es im Ermessen des Auditors. Unabh\u00e4ngig muss er verst\u00e4ndlicherweise auch sein, d.h. entweder ist er gleich von einem anderen Unternehmen oder er ist innerhalb des Unternehmens unabh\u00e4ngig von der eigentlichen IT.<\/p>\n
Insgesamt denke ich, dass die \u00c4nderungen im PCI DSS 3.0 bez\u00fcglich des Requirements 11.3 richtig und gut sind. Die Durchf\u00fchrung nach einem international akzeptierten Vorgehensmodell ist zwar keine Garantie f\u00fcr einen guten Penetrationstest, aber zumindest eine Voraussetzung daf\u00fcr. Die neue Pr\u00fcfung der Effektivit\u00e4t der Scope-Trennung wird prim\u00e4r nur durch den Einsatz von Reviews m\u00f6glich sein. Letztendlich f\u00fchrt hier der Penetration Tester eine technisch fundiertere Analyse durch, als es ein Auditor bei der Festlegung vom Scope durchf\u00fchren kann.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"
Der PCI DSS 3.0 verlangt in Requirement 11.3 die Durchf\u00fchrung von Penetrationstests. Im \u00e4lteren PCI-Standard 2.0 umfasste das bisher prim\u00e4r einen Penetrationstest auf Netzwerk- sowie auf Anwendungsebene, der sowohl von extern als auch von intern durchgef\u00fchrt werden musste. Der Penetration Tester musste dabei nat\u00fcrlich qualifiziert und unabh\u00e4ngig sein. Diese Punkte sind zwar inhaltlich auch im … [Read more…]<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":{"0":"entry","1":"post","2":"publish","3":"author-psauer","4":"post-1543","6":"format-standard","7":"category-pci-dss"},"_links":{"self":[{"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/posts\/1543","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/comments?post=1543"}],"version-history":[{"count":29,"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/posts\/1543\/revisions"}],"predecessor-version":[{"id":1572,"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/posts\/1543\/revisions\/1572"}],"wp:attachment":[{"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/media?parent=1543"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/categories?post=1543"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/tags?post=1543"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}