Mit PCI DSS 3.1 ist ein neuer Plan für SSL-Sicherheit notwendig

Die Protokolle SSL und TLS sind anfällig. Der Standard PCI DSS 3.1 adressiert diese Problematik. Händler haben mit der Umstellung bis Juni 2016 Zeit.

Dieser Artikel behandelt

PCI-Standards

Es gibt eine neue Version von Payment Card Industry Data Security Standard (PCI DSS). Die Händler müssen nicht nur von verwundbaren Protokollen zur Datenverschlüsselung Abschied nehmen, sondern auch im Detail vorlegen, wie sie diesen Übergang meistern wollen.

PCI DSS Version 3.1 ist die neueste Iteration des Security-Standards, der im Jahre 2004 von VISA, MasterCard und anderen großen Kreditkartenanbietern entwickelt wurde. Damit sollen die Übermittlung und das Speichern von Kreditkartendaten so sicher wie möglich gestaltet werden.

PCI DSS 3.1 SSL und frühes TLS muss bis Juni 2016 verschwunden sein

Diese nicht planmäßige Version von PCI DSS enthält einige kleinere Klarstellungen und Updates. Primär wurde der Standard allerdings aktualisiert, um risikoreiche Schwachstellen bei den Protokollen zur Verschlüsselung Secure Sockets Layer (SSL) und Transport Layer Security (TLS) zu adressieren, die Zahlungsdaten erhöhten Risiken aussetzen.

PCI DSS 3.1 aktualisiert drei Hauptanforderungen. Speziell geht man auf SSL ein. Im Detail sind das die PCI-DSS-Anforderungen

  • 2.2.3 (Verschlüsselung für VPNs, NetBIOS, gemeinsames Nutzen von Dateien, Telnet, FTP und ähnliche Services),
  • 2.3 (Verschlüsselung für webbasiertes Management und andere administrative Zugriffe, die nicht über eine Konsole erfolgen) und
  • 4.1 (Verschlüsselung der Daten des Kreditkartenbesitzers während der Übermittlung über offene, öffentliche Netzwerke).

Künftig ist nur noch starke Kryptografie gestattet. Das Security Standards Council (SSC) definiert frühes TLS als Version 1.0 und in einigen Fällen sogar als 1.1. Es kommt hier darauf an, wie man es nutzt und wie es implementiert ist.

Ab sofort ist es Händlern nicht mehr gestattet, neue Technologien zu implementieren, die auf SSL und frühes TLS setzen. Ab 30. Juni 2016 dürfen Händler SSL und frühes TLS gar nicht mehr als alleinstehende Kontrollmechanismen für die Sicherheit verwenden, um die Zahlungsdaten zu schützen.

Auslöser für die Änderung war Special Publication 800-52, die vom National Institute for Standards and Technology (NIST) herausgegeben wurde. In diesem Dokument merkt NIST an, dass nur TLS 1.1 und 1.2 sicher genug für behördliche Nutzung sind. Somit wurde signalisiert, dass SSL 2.0, SSL 3.0 und TLS 1.0 nicht mehr länger als starke Standards für Verschlüsselung akzeptabel sind. Viele Händler nutzen in Ihren Kreditkartenumgebungen aber weiterhin die erste Version von TLS und in manchen Fällen sogar SSL.

Normalerweise wird PCI DSS alle drei Jahre aktualisiert. Deswegen war die nächste Version nicht vor dem Herbst 2016 zu erwarten. PCI DSS 3.0 erblickte im November 2013 das Licht der Welt. Das SSC hat im Februar 2015 allerdings ohne viel Tam Tam angekündigt, dass wegen der Schwachstellen in SSL und TLS ein außerplanmäßiges Update für PCI DSS notwendig sei.

Stephen Orfei, Geschäftsführer von PCS SSC, sagte in einer Stellungnahme: „Im Council konzentriert man sich darauf, die besten Standards und Ressourcen bereitzustellen, damit Händler und ihre Geschäftsspartner vor den neuesten Bedrohungen und Schwachstellen geschützt sind. Wie wir bei POODLE und anderen Exploits gesehen haben, stellen die Schwachstellen im SSL-Protokoll ein Risiko für die Zahlungsdaten dar. Mit PCI DSS 3.1 und unterstützender Beratung wollen wir Unternehmen einen pragmatischen, risikobasierten Ansatz liefern, um diese Bedrohungen zu adressieren.“

Neue Anforderungen: Pläne zur Schadensminimierung und Migration für SSL und TLS

Händler haben für den Übergang genügend Zeit. Allerdings diktiert PCI DSS 3.1, dass Händler, die SSL und/ oder frühes TLS verwenden, sofort Maßnahmen einleiten. Das gilt im Speziellen für die Erstellung eines formellen Schadenbegrenzungs- und Migrationsplans.

Das SSC sagte in einer Stellungnahme, dass man für temporäre Ansätze zur Risikominderung mit Rat zur Seite stehen will. Außerdem wird man Vorschläge zur Migration machen und Alternativen für starke kryptografische Protokolle vorstellen. Dafür steht ein begleitendes Informationsdokument mit dem Namen Migrating from SSL and Early TLS zur Verfügung.

Die Händler müssen vor allen Dingen Beschreibungen vorlegen, auf welche Weise sie die verwundbaren Protokolle einsetzen. Das gilt auch für die Ergebnisse der Risikobewertungen und welche Kontrollmechanismen für die Risikominderung man im Einsatz hat. Weiterhin sind die Prozesse zu beschreiben, die für das Monitoring nach neuen Schwachstellen einsetzt werden, die wiederum mit den verwundbaren Protokollen assoziiert sind. 

Außerdem müssen die Händler beschreiben, welche Kontrollprozesse sie ändern, damit garantiert ist, dass kein SSL oder frühes TLS mehr in neuen Umgebungen implementiert werden. Darüber hinaus muss das Unternehmen einen Überblick des Schadensminimierungsplans vorlegen. Ferner will man wissen, wie die Frist für die Migration zum 30. Juni 2016 eingehalten werden soll.

PCI DSS 3.1 diktiert, dass die Händler alle ihre Pläne für die Migration auf ein sicheres Protokoll vorlegen. Weiterhin müssen sie die Kontrollmechanismen beschreiben, wie die Risiken im Zusammenhang mit SSL und frühem TLS minimiert werden.

Ergänzend hat das SSC angemerkt, dass Händler mehrere Optionen für eine Implementierung zusätzlicher Maßnahmen für eine Verschlüsselung haben. Einige davon besagen, dass man SSL oder frühes TLS nicht zwingend entfernen muss. 

Eine Möglichkeit ist, auf eine aktuellere und sichere Version von TLS zu setzen. Man kann auch prozessnahe oder Verschlüsselung auf Anwendungsebene verwenden, um die Daten zu sichern, bevor man diese über SSL oder frühes TLS versendet. Weiterhin ist die Implementierung einer stark verschlüsselten Sitzung über zum Beispiel einen IPSec-Tunnel denkbar, bevor man die Daten via SSL verschickt.

Die Experten warnen die Unternehmen an dieser Stelle allerdings. Nur weil es mehrere Optionen gibt, bedeutet das nicht, dass weniger Arbeit für die Absicherung anfällt.

Das SSC hat ausdrücklich betont, dass Händler aller Größen den Änderungen von PCI DSS 3.1 nachkommen müssen. Nur so könne man Versuche zum Diebstahl von Zahlungsinformationen abwehren.

Die Verwendung von SSL lässt sich zum Glück auch mit Open-Source-Tools und webbasierter Software durchführen. An dieser Stelle müssen Unternehmen nicht zwingend etwas kaufen.

PCI DSS 3.1 räumt eine Galgenfrist ein

Bei POS-Systemen (Point-of-Sale) und POI-Terminals (Point-of-Interaction), die vom SSC als Lesegeräte für Magnetstreifenkarten und Chipkarten wie NFC-Touchpoints definiert sind, bleibt den Händlern eine Atempause.

In PCI DSS 3.1 ist Folgendes hinterlegt: Wenn Geräte SSL und frühes TLS verwenden und diese nicht dem Verdacht unterliegen, für alle Exploits hinsichtlich SSL und frühes TLS anfällig zu sein, dann können die Händler solche Gerätschaften auch über den 30. Juni 2016 hinaus verwenden.

Das SSC weist darauf hin, dass sich dieser weniger strikte Standpunkt rechtfertigen lässt. Mit den derzeit bekannten Schwachstellen ist es schwieriger, POS-Systeme anzugreifen und auszunutzen.

Das SSC macht darauf aufmerksam, dass sich einige der SSL-Schwachstellen von Angreifern ausnutzen lassen. Dafür fangen diese die Kommunikation zwischen Client und Server ab und manipulieren sie. Das Ziel der Cyberkriminellen ist es, dass der Client zusätzliche Daten schickt. Diese nutzt der Angreifer, um die Sitzung zu kompromittieren.

POS-Systeme unterstützen allerdings häufig keine mehrfachen, clientseitigen Verbindungen. Außerdem verwenden sie Protokolle, die die Menge an ausgegebenen Daten limitieren. Weiterhin verwenden sie keine Webbrowser-Software, JavaScript oder Cookies, die mit Sicherheit zu tun haben. Um die Schwachstellen in SSL und frühem TLS ausnutzen zu können, ist häufig eines der hier angeführten Charakteristika notwendig.

Das SSC warnte auch davor, dass sich Exploits weiterentwickeln und Unternehmen sich entsprechend auf neue Bedrohungen vorbereiten müssen. Deswegen sollten alle Firmen, die SSL oder frühes TLS einsetzen, so früh wie möglich auf starke kryptografische Protokolle umsteigen.

Manche Experten glauben allerdings, dass das Risiko für das SSC hinsichtlich dieser Entscheidung nicht alleine ausschlaggebend war. Sie vermuten, dass den POS-Herstellern mehr Zeit gegeben werden sollte, die Systeme gründlich zu überarbeiten. Man will großen Einzelhändlern womöglich mehr Zeit einräumen, dass sie nicht überstürzt neue und nicht ausreichend getestete POS-Systeme installieren.

Trustwave bewertet POS-Systeme auf Konformität zu Payment Application Data Security Standard (PA-DSS) und konnte ein Exponieren von Daten zu einem gewissen Grad feststellen, wenn SSL und frühes TLS im Einsatz waren. Die POS-Hersteller arbeiten derzeit mit dem SSC zusammen, um diese Probleme angemessen zu adressieren.

Das SSC hat auch ein Update von PA-DSS veröffentlicht, um die in PCI DSS 3.1 eingeflossenen Änderungen entsprechend zu berücksichtigen.

Eine weitere nennenswerte Änderung in PCI DSS 3.1 ist eine Referenz in der Einführung. Der Teil Schutz der Daten des Karteninhabers (Protecting Cardholder Data) wurde zu Schutz der Kontodaten (Protecting Account Data) umgewandelt. Weiterhin ist eine Klarstellung in Requirement 11.3.4 angefügt. Man muss bei Penetrationstests sicherstellen, dass alle außenstehenden Systeme von Systemen in der CDE isoliert sind. Außerdem gibt es einige Korrekturen bei der Ausdrucksweise rund um Testprozeduren.

Folgen Sie SearchSecurity.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Juli 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über PCI-Datensicherheitsstandards

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close