Multi-Faktor-Authentifizierung zur Einhaltung des PCI DSS 3.2

Dirk Denayer, 8. November 2017

Am 1. Februar 2018 tritt die Anforderung 8.3 der Payment Card Industry Data Security Standard (PCI DSS 3.2) in Kraft, die eine Multi-Faktor-Authentifizierung für den nicht konsolenbasierten Zugriff auf jene Computer und Systeme, die Karteninhaberdaten verarbeiten, sowie für den Fernzugriff auf die Karteninhaberdatenumgebung zwingend vorschreibt. Anfang dieses Jahres hat der PCI Security Standards Council Richtlinien für die Implementierung von Multi-Faktor-Authentifizierungen herausgegeben.

PCI DSS 3.2

Der PCI DSS gilt für alle Unternehmen und Organisationen, die in jeglicher Form Zahlungskarten handhaben, darunter Einzelhändler, Auftragsverarbeiter, Zahlungsverarbeiter, Kartenaussteller und Dienstleistungsanbieter. Der Standard gilt auch für alle anderen Einrichtungen, die Daten von Karteninhabern bzw. sensible Authentifizierungsdaten speichern, verarbeiten oder übermitteln.

Seit der Veröffentlichung des PCI DSS wurden zwei Hauptversionen herausgegeben: Version 2.0 im November 2010 und Version 3.0 im Oktober 2013. Der jüngste Zusatz, Version 3.2, wurde im April 2016 herausgegeben und enthält einige neue Anforderungen, die bis zum 31. Januar 2018 als Best Practices galten und danach zu verbindlichen Vorschriften wurden. Diese Änderungen stellen sicher, dass die Standards auf dem neuesten Stand sind, wobei hier insbesondere neu auftretende Bedrohungen und Marktveränderungen berücksichtigt wurden. Die wichtigste Änderung ist die überarbeitete Anforderung 8.3 zur Multi-Faktor-Authentifizierung.

Diese Überarbeitung war angesichts der schwerwiegenden Hacking-Angriffe, die sich zuvor in den USA ereignet hatten, dringend erforderlich. Unter anderem kam es zu Datenschutzverletzungen bei Target und Home Depot, im Zuge derer Namen von Kunden, Kreditkartennummern und andere Informationen, die Millionen von Menschen betreffen, von Hackern entwendet wurden. Allein der Angriff auf Target im Jahr 2013 kompromittierte Karteninformationen von 40 Millionen Kunden und betraf weitere 70 Millionen Personen, deren Daten teilweise offengelegt wurden. Nach jahrelangen Recherchen und Verhandlungen hat sich Target mit den Justizbehörden auf eine Strafzahlung in Höhe von insgesamt 18,5 Millionen US-Dollar für diese Datenschutzverletzung geeinigt. Dem Einzelhandelsunternehmen sind aufgrund dieses Datenschutzvorfalls Anwalts- und Folgekosten in Höhe von annähernd 202 Millionen US-Dollar entstanden.

Anforderung 8.3 und Multi-Faktor-Authentifizierung

Die erste Änderung zu Punkt 8.3 ist die Einführung des Begriffs „Multi-Faktor-Authentifizierung“, der den zuvor verwendeten Begriff „Zwei-Faktor-Authentifizierung“ ablöst, da zwei oder mehr Faktoren verwendet werden können. Dies bedeutet, dass der Einsatz von zwei Faktoren für die Authentifizierung eine Mindestanforderung ist.

Die zweite und wichtigste Änderung besteht darin, dass Abschnitt 8.3 auf folgende zwei Gruppen von Mitarbeitern ausgedehnt wurde, für die eine Multi-Faktor-Authentifizierung nun zwingend vorgeschrieben ist: jene, deren Zugriff für administrative Zwecke nicht konsolenbasiert ist, und jene, die über Fernzugriff Zugang zu CDE-Umgebungen haben.

Die neue Anforderung 8.3.1 sieht eine Multi-Faktor-Authentifizierung für alle Mitarbeiter vor, deren Zugriff auf die CDE für administrative Zwecke nicht konsolenbasiert ist. Mit „nicht konsolenbasiert“ ist jeder Zugriff über ein Netzwerk gemeint – einschließlich von internen Netzwerken sowie von externen oder dezentralen Netzwerken –, der nicht über eine direkte physische Verbindung erfolgt.

Die neue Anforderung 8.3.2 ergänzt die zuvor veröffentlichte Anforderung 8.3 um die Multi-Faktor-Authentifizierung für alle Mitarbeiter mit Fernzugriff auf CDE-Umgebungen. Diese Anforderung gilt für alle Mitarbeiter, darunter auch allgemeine Nutzer, Administratoren und Auftragnehmer (z. B. für Support- und Wartungsaufgaben), die Fernzugriff auf das Netzwerk haben, sofern dieses Netzwerk den Zugang zu einer CDE ermöglichen könnte.

Orientierungshilfe für den Einsatz einer Multi-Faktor-Authentifizierung

Seit Änderung der Anforderung 8.3 hat der PCI Security Standards Council eine Reihe von Fragen dazu erhalten, wie die verschiedenen Faktoren zu implementieren sind, sowohl von Organisationen, die die Einführung von MFA beabsichtigen, als auch von Sicherheitsprüfern, deren Aufgabe es ist, MFA-Implementierungen zu bewerten.

Um diese Fragen zu beantworten, wurde das Dokument Ergänzende Informationen – Multi-Faktor-Authentifizierung Version 1.0 veröffentlicht, das beschreibt, welche branchenweit anerkannten Grundsätze und Best Practices für die MFA-Implementierung gelten, einschließlich:

  • Definition, Unabhängigkeit und Schutz von Authentifizierungsfaktoren
  • Missbrauch von Sicherheitsfaktoren, unter anderem bei einer mehrstufigen Authentifizierung

Im letzten Abschnitt werden allgemeine Authentifizierungsszenarien und Überlegungen zur Multi-Faktor-Authentifizierung erörtert.

Faktoren für die Authentifizierung

Für die Multi-Faktor-Authentifizierung müssen gemäß PCI DSS, Abschnitt 8.2 mindestens zwei der drei folgenden Komponenten verwendet werden:

  • Etwas, das der Benutzer weiß, also ein Kennwort, eine PIN oder Antworten auf bestimmte geheime Fragen
  • Etwas, über das der Benutzer verfügt, wie ein Security-Token oder eine Smartcard
  • Etwas, das benutzerspezifisch ist, wie etwa ein biometrisches Merkmal

Innerhalb der Branche sind diese Definitionen zwar hinlänglich bekannt, es bestehen jedoch immer noch Schwierigkeiten, wenn es darum geht, die verschiedenen Authentifizierungsfaktoren in die Praxis umzusetzen.

Seitens des PCI SSC werden auch andere Faktoren erwähnt: „Andere Arten von Informationen, wie Geolokalisierung und Zeitangaben, können zusätzlich in den Authentifizierungsprozess integriert werden. Es müssen jedoch immer mindestens zwei der drei oben genannten Faktoren verwendet werden. Beispielsweise können Geolokalisierungs- und Zeitdaten dazu verwendet werden, um den Fernzugriff auf das Netzwerk je nach Arbeitszeit eines spezifischen Mitarbeiters entsprechend einzuschränken. Während solche zusätzlichen Kriterien das Risiko von illegalen Account-Übernahmen oder anderen böswilligen Aktivitäten durchaus weiter eindämmen können, muss beim Fernzugriff dennoch eine Authentifizierung über mindestens zwei der folgenden Faktoren erfolgen: etwas, das der Benutzer weiß, etwas, über das der Benutzer verfügt, und etwas, das ein benutzerspezifisches Merkmal ist.“

Unabhängigkeit der individuellen Authentifizierungsfaktoren

Die MFA ist so umzusetzen, dass voneinander unabhängige Authentifizierungsmechanismen eingesetzt werden. Damit wird sichergestellt, dass keiner der Faktoren auf einen anderen Faktor hinweist bzw. den Zugriff auf einen anderen Faktor erleichtert, und dass ein gefährdeter bzw. kompromittierter Authentifizierungsfaktor die Integrität eines anderen Faktors nicht beeinträchtigt.

Der PCI SSC beschreibt folgende Situationen, die potenziell zu Problemen führen:

  • Erstens: Wenn ein Benutzername in Kombination mit einem Kennwort für den Zugang zum Firmennetzwerk verwendet und dieselbe Kombination auch für ein E-Mail-Konto genutzt wird, an das ein Einmalkennwort gesendet wird, das als zweiter Schutzfaktor fungiert, so sind diese Faktoren nicht voneinander unabhängig. Der erste Faktor zur Authentifizierung (Benutzername/Kennwort) ermöglicht nämlich den Zugriff auf das E-Mail-Konto und damit auf den zweiten Faktor.
  • Zweitens: „Ein auf einem Laptop gespeichertes Softwarezertifikat (etwas, worüber Sie verfügen), das Sie mit denselben Anmeldeinformationen schützen, mit denen Sie sich auch auf Ihrem Laptop anmelden (etwas, das Sie wissen), bietet keinen unabhängigen Schutz.“
  • Drittens: „Die Übertragung eines Einmalkennworts (OTP) an ein Smartphone wird traditionell als effektive, sichere Out-of-Band-Methode angesehen. Wenn dasselbe Telefon jedoch auch für die Eingabe des OTP verwendet wird – beispielsweise über einen Webbrowser – ist dieses OTP als sekundärer Faktor nicht mehr sicher.“ Sobald Sie Ihre Anmeldeinformationen über dasselbe Gerät eingeben, das auch den Authentifizierungsfaktor empfängt (oder diesen speichert/generiert), kann ein Hacker, der ein Gerät kontrolliert, möglicherweise gleich beide Authentifizierungsfaktoren abfangen.

Schutz von Authentifizierungsfaktoren

Um sicherzustellen, dass Authentifizierungsfaktoren nicht kompromittiert werden, müssen sie – gemäß PCI DSS, Anforderung 8 – vor unbefugtem Zugriff und unbefugter Verwendung geschützt werden. Darüber hinaus sollten „Mehrzweck-Verbrauchergeräte, die auch zum Erstellen, Speichern oder Generieren von Authentifizierungselementen verwendet werden – z. B. Mobiltelefone und Tablets –, zusätzlich geschützt werden, sodass das Risiko einer Gefährdung des Geräts selbst besser kontrolliert werden kann.“

Mehrstufiger Prozess oder Multi-Faktor-Verfahren?

Nach den Anforderungen des PCI DSS müssen bei der Multi-Faktor-Authentifizierung alle Faktoren gemeinsam verifiziert werden, bevor ein Benutzer auf ein System zugreifen kann. Wenn ein Benutzer weiß, dass ein Vorgang erfolgreich war (oder nicht), noch bevor er alle Faktoren übermittelt hat, sprechen wir eher von einem mehrstufigen Authentifizierungsverfahren, bei dem lediglich Einzelfaktoren genutzt werden, selbst wenn für jeden Schritt ein anderer Faktor verwendet wird. Dies hat nichts mit einer Multi-Faktor-Authentifizierung zu tun und entspricht nicht den Anforderungen.

Typische Authentifizierungsszenarien

Im letzten Abschnitt zu diesen ergänzenden Informationen beschreibt der PCI SSC vier Multi-Faktor-Authentifizierungsszenarien, in denen die unterschiedlichen Anforderungen an Authentifizierungsfaktoren und deren bestmögliche Umsetzung genauer erläutert werden.

Fazit

Weniger als drei Monate vor Inkrafttreten der PCI-DSS-Anforderung 8.3 ist es Zeit zum Handeln. Ich bin davon überzeugt, dass die Ergänzenden Informationen – Multi-Faktor-Authentifizierung Version 1.0 ein guter Ausgangspunkt für Sie sind, wenn Sie sich darauf vorbereiten möchten, Ihre Multi-Faktor-Authentifizierungslösungen zu überprüfen, zu implementieren oder zu aktualisieren.

Dirk Denayer ist Business Solutions Manager bei OneSpan. Er kam 2016 zu OneSpan und verfügt über 20 Jahre Erfahrung in Business-Softwarelösungen auf den Ebenen Vertrieb, Marketing und Lieferung. Bevor er zu OneSpan kam, arbeitete er bei Exact Software, CODA und Unit4.