Ahileos - Fotolia

Von SSL und TLS zu TLS 1.2: Migrationsplan für PCI DSS 3.1 erstellen

SSL und frühe Versionen von TLS gelten als unsicher. Deswegen fordert PCI DSS 3.1 von Firmen, diese Verschlüsselungen bis 30. Juni 2016 aufzugeben.

Dieser Artikel behandelt

PCI-Standards

Unternehmen sind außerplanmäßige Updates von Softwareherstellern gewohnt. Die Flicken bessern kritische Sicherheitslücken in den entsprechenden Anwendungen aus. Ein außerplanmäßiges Update für einen Standard ist allerdings wesentlich unüblicher.

Das PCI SSC (Security Standards Council) sah sich aber gezwungen, eine nicht planmäßige Version von Payment Card Industry Data Security Standard (PCI DSS) zu veröffentlichen. Gründe sind die wachsenden Bedrohungen, die vom einst vertrauenswürdigen Protokoll für Kryptografie Secure Sockets Layer (SSL) ausgehen. Die nächste Version hat man eigentlich nicht vor Ende 2016 erwartet. PCS DSS 3.1 (PDF) wurde aber schon im April 2015 veröffentlicht. Händler sind aufgefordert, die anfälligen Protokolle zur Verschlüsselung von Daten nicht mehr länger zu verwenden.

Das Problem mit SSL

Das SSL-Protokoll ist erstmalig im Jahre 1995 aufgetaucht. Das aus dem Jahr 1996 stammende SSL 3.0 wurde zum De-Facto-Standard für die Sicherheit bei der Kommunikation über das Internet. Viele Jahre lang haben sich Angriffe auf SSL auf Fehler bei der Implementierung konzentriert. Security-Lücken wie zum Beispiel POODLE und FREAK sind allerdings direkte Angriffe auf das SSL-Protokoll.

Version 3.1 von SSL wurde als TLS 1.0 (Transport Layer Security) im Jahre 1999 veröffentlicht. Damit verbesserte man die Sicherheit, um in früheren Versionen gefundene Schwachstellen zu lindern. Allerdings sieht man heute TLS 1.0 und in einigen Fällen auch TLS 1.1 als nicht mehr stark genug an.

Kurz gesagt sind schwache Protokolle für die Verschlüsselung als Security-Kontrollmechanismus für den Schutz von Zahlungsinformationen nicht mehr akzeptabel. Das wirkt sich direkt auf die nachfolgenden Anforderungen von PCI DSS aus:

  • Anforderung 2.2.3: Implementierung zusätzlicher Security-Funktionen für die notwendigen Services, Protokolle oder Daemons, die als unsicher eingestuft sind.
  • Anforderung 2.3: Verschlüsselung aller administrativen Zugriffe mithilfe starker Kryptografie, die nicht auf der Konsole stattfinden.
  • Anforderung 4.1: Verwendung starker Kryptografie.

Einen Migrationsplan für den Umstieg auf TLS 1.2 erstellen

Kritische Schwachstellen in so weit verbreiteten kryptografischen Protokollen sind für die Sicherheit von Zahlungsinformationen eine echte Bedrohung. Das gilt vor allen Dingen, da sie nicht einfach zu flicken sind. Einige Kritiker argumentieren, dass die Zertifizierung für PCI DSS ein steifes Verfahren ist, bei dem man lediglich Punkte abhakt. Wahrscheinlich aus diesem Grund fordert das PCI SSC von den Händlern nicht nur eine Abschaffung von SSL und frühen Versionen von TLS bis 30. Juni 2016. Die Organisation verlangt darüber hinaus, dass man dem zuständigen PCI-DSS-Gutachter einen offiziellen Plan für die Migration und die damit verbundenen Maßnahmen vorlegt. Darin soll detailliert aufgelistet sein, wie der Übergang ablaufen soll. Diese Anforderung stellt sicher, dass sich die Betroffenen der Risiken bewusst sind und ihre Infrastruktur nicht auf den letzten Drücker aktualisieren.

Die beste Lösung ist natürlich, SSL komplett zu deaktivieren und auf TLS 1.2 umzustellen. Das geht aber nicht von heute auf morgen. Aus diesem Grund muss der von PCI DSS 3.1 vorgeschriebene Plan zur Abschwächung der Risiken und zur Migration erläutern, wie man die durch SSL hervorgerufenen Risiken bis zum Abschluss der Umstellungen lindern will. Um sicherzustellen, dass SSL nicht mehr in neuen Umgebungen implementiert wird, muss es eine Beschreibung für das Monitoring auf neue Schwachstellen geben und welche Kontrollmechanismen man für Änderungen einsetzen will.

Der PCI-Zusatz des PCI SSC Migrating from SSL and Early TLS stellt einen Leitfaden und Beispiele von Informationen zur Verfügung, die man im Plan dokumentieren muss. Weiterhin gibt es Ratschläge für die Migration und alternative Optionen für starke Kryptografieprotokolle. Weitere nützliche Informationen in Sachen sichere TLS-Konfigurationen finden Sie im Dokument Special Publication 800-52 vom National Institute for Standards and Technology (NIST). Darin empfiehlt man auch staatlichen Agenturen eine Erstellung eines Plans zur Migration auf TLS 1.2.

Unternehmen sollten sowohl Audits als auch interne und externe Schwachstellen-Scans durchführen, um auf diese Weise unsichere SSL-Implementierungen zu entdecken. In vielen Fällen muss man lediglich SSL 3.0 und TLS 1.0 deaktivieren, da die Mehrheit der modernen Software mit TLS 1.1 und TLS 1.2 umgehen kann. Zum Beispiel unterstützen die meisten populären Webserver und Browser TLS. Administratoren haben mit Group Policy zusätzlich die Option, SSL 3.0 und TLS 1.0 zu deaktivieren und TLS 1.1, sowie TLS 1.2 für den Internet Explorer zu aktivieren.

Anwender müssen Software oder ältere Geräte aktualisieren, die lediglich SSL 3.0 unterstützen. Bei Point-Of-Sale-Systemen (Kassensystemen) von Drittanbietern ist das möglicherweise der Fall. Können Unternehmen nicht komplett von SSL und frühen Versionen von TLS migrieren, dann müssen Sie dem Prozess PCI DSS Addressing Vulnerabilities with Compensation Controls (PDF) folgen. Damit stellen Sie sicher, dass die betroffenen Systeme nicht anfällig für SSL-Schwachstellen sind.

Neben dem Upgrade auf eine sicherere Version von TLS können Händler zusätzliche Maßnahmen für Kryptografie einsetzen. Möglich sind an dieser Stelle Verschlüsselung auf Feldebene oder Anwenderebene, um die Zahlungsdaten vor einer Übertragung zu verschlüsseln. Auch die Verwendung einer stark verschlüsselten Sitzung ist denkbar. Ein Beispiel ist ein IPsec-Tunnel, bevor man Daten via SSL überträgt.

Wie immer erweist sich Defense in Depth als bester Schutz gegen momentane und zukünftige Bedrohungen. Das reduziert außerdem die Notwendigkeit, kritische Sicherheitslücken sofort stopfen zu müssen.

Beim Erstellen eines Migrationsplans sollten Sie im Auge behalten, dass TLS Version 1.3 möglicherweise vor der vom PCI SSC gesetzten Frist am 30. Juni 2016 verfügbar ist. Die Spezifikation liegt derzeit als Entwurf vor und die Transport Layer Security Working Group der Internet Engineering Task Force (IETF) arbeitet daran. Hoffentlich hört dann bald die Unsitte auf, dass man TLS als SSL bezeichnet.

Über den Autor:
Michael Cobb ist CISSP-ISSAP und ein bekannter Security-Autor mit über 20 Jahren Erfahrung. Zu seiner Leidenschaft gehört, Best Practises bezüglich IT-Security verständlich und begreifbar zu machen. Seine Website http://www.hairyitdog.com bietet freie Security-Poster an, um die Anwender auf die Gefahren und die Datensicherheit im Unternehmen aufmerksam zu machen. Er war Co-Autor des Buches IIS Security und hat für viele führende IT-Publikationen Artikel verfasst. Mike war außerdem Microsoft Certified Database Manager und registrierter Consultant bei CLAS (CESG Listed Advisor Scheme).

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

Artikel wurde zuletzt im März 2016 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über PCI-Datensicherheitsstandards

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close