PCI ist kein Allheilmittel für die IT-Sicherheit
Viele Unternehmen sind darum bemüht, ihren Aufwand für Compliance in Grenzen zu halten, müssen aber andererseits ein Höchstmaß an Sicherheit für ihre sensiblen Informationen gewährleisten. Dieses Dilemma veranlasst viele Organisationen dazu, ihre gegenwärtigen Sicherheitsinitiativen (d.h. PCI) genauer unter die Lupe zu nehmen.
Bereits mit der Einführung der Version 1.2 sind 32 Änderungen erfolgt, darunter viele Klarstellungen und Standardisierungen im Hinblick auf die Terminologie. Abgesehen von diesen Klarstellungen wurden auch, um den Entwicklungen in der realen Welt Rechnung zu tragen, die Technologieanforderungen für PCI modifiziert. Das Feedback von vielen Organisationen brachte das PCI Security Standards Council (SSC) zu der Einsicht, dass einige der PCI-DSS-Vorgaben zu eng gefasst waren, wodurch besonders große Organisationen Probleme damit hatten, ihre Dienste zu modifizieren und dennoch eine sichere Umgebung auf Basis guter Sicherheitspraxis aufrechtzuerhalten.
Als Reaktion auf diese Rückmeldungen empfahl der PCI SSC, dass die Kreditkartenorganisationen einige der PCI-DSS-Anforderungen, die sie von ihren Handelspartnern verlangten, abschwächen konnten. Dies verschärfte allerdings die Problematik eines zu laxen Umgangs mit den PCI-Regeln, denn der Vorgang zeigte, dass die Kartenorganisationen bereit waren, ihre Anforderungen zurückzunehmen, wenn nur eine Mehrheit der teilnehmenden Handelsunternehmen und Dienstleister meinte, die Anforderungen seien zu streng. Die Kartenunternehmen kamen dem Händlerinteresse dadurch entgegen, dass sie die Zeiträume zwischen Updates verlängerten oder notwendige Updates abhängig von besonderen “Risikosituationen” machten. So wurde z.B. das im PCI-DSS-Abschnitt 1.1.6 (vormals Abschnitt 1.1.8) geforderte Intervall zwischen den Überprüfungen der Firewall und der Router-Regelsets von einem Vierteljahr auf mindestens alle sechs Monate verlängert.
Diese Änderung beruhte auf dem Umstand, dass in den meisten Organisationen die Firewall- und Routerregel-Einstellungen nach anfänglicher Konfiguration selten umgestellt werden, was im wesentlichen auf die PCI-DSS-Empfehlung zurückzuführen war, dass man die Reichweite einer Organisation durch eine Segmentierung des Kreditkarten-Handling-Netzwerks von den örtlichen Unternehmensnetzwerken (LANs) verringern sollte. Zudem verlangte der PCI-DSS-Abschnitt 6.1 früher monatliche Patches für Systeme, die dem PCI-Regelwerk unterliegen. Nun wurde dieser umformuliert in: “Eine Organisation kann einen risikoorientierten Ansatz wählen und ihre Patch-Installationen je nach Priorität vornehmen.” Damit können Organisationen ihre Sicherheitsrichtlinien in vollem Umfang umsetzen, ohne eilige Installationen vornehmen zu müssen, nur weil PCI-DSS-Vorgaben zu erfüllen sind.
Eine der großen Änderungen in der Version 1.1, die auch in der Version 1.2 fortgeführt wurde, war die Einfügung des Punktes 6.6 (der seit 30. Juni offizielle PCI-DSS-Vorgabe ist). Darin wird festgehalten, dass entweder eine manuelle Code-Überprüfung oder eine Firewall mit Anwendungs-Layer eingesetzt werden muss, um die mit dem Internet interagierenden Anwendungen zu schützen. Zu beachten ist, dass PCI DSS nicht festlegt, eine bestimmte Firewall einzusetzen. Der Einsatz von Tools zur Segmentierung von Systemen, die Karteninhaberdaten getrennt von anderen Teilen des Netzwerks verwalten, haben den Vorteil, dass die Reichweite der zu überprüfenden Systeme eingeschränkt bleibt.
