Der Payment Card Industry Data Security Standard (PCI-DSS) ist ein verpflichtender Branchenstandard der kreditkartenausgebenden zur Datensicherheit für kreditkartendatenverarbeitende Institute. Der vorliegende Artikel behandelt, was dieser Standard in der Praxis für die Datenverarbeitung bedeutet.

Das PCI-DSS Council

Die Standards werden seit 2006 vom PCI-DSS Council, dem Zusammenschluss von American Express, Discover, JCB International, MasterCard und Visa erstellt. Sie gelten für Händler, die Kreditkartenlesegeräte nutzen und für die Hersteller von Hard- und Software, die die globale Infrastruktur für die Verarbeitung von Zahlungsdaten herstellen und betreiben. Dieser Artikel behandelt die Auswirkungen auf die Finanzinstitute, die diese Zahlungsdaten innerhalb ihrer IT-Infrastruktur verarbeiten. Das Council veröffentlicht die Standards auf seiner Webseite [1] Stand Juli 2017 liegen sie in der aktuellen Version 3.2 vor.​
Neben der Aufstellung und Erläuterung der Standards finden sich auf der Webseite auch weitere hilfreiche Dokumente wie Glossare, Quick Reference Guides, Mustervorlagen und Verfahrensweisen zur priorisierten Implementierung der Standards. Anhand der Verfahrensweisen sind die Standards durch die Finanzinstitute umzusetzen. Dabei sind die Ergebnisse vorgegeben, während der Weg der Umsetzung dem einzelnen Unternehmen offen bleibt. Dieser Prozess wird von PCI-DSS zertifizierten Unternehmen (den sog. Qualified Security Assessors: QSA) bei Wunsch beratend unterstützt und innerhalb eines umfangreichen Assessments abgenommen.​
Des Weiteren ist natürlich zu unterbinden, dass sich anhand gestohlener Authentisierungsdaten Karten fälschen lassen. Diese Daten nutzt man üblicherweise nur am Verkaufspunkt, sie dürfen nicht gespeichert werden und unterliegen nicht der PCI-Betrachtung in diesem Artikel.​
Eine Nicht-Umsetzung der Compliance mit den Standards kann zum Entzug der Lizenz für die Verarbeitung der Daten führen. Dadurch entstandene Betrugsfälle werden mit empfindlichen Strafen geahndet

Welche Daten sind zu schützen?

Grundsätzlich lassen sich die Kundendaten einer Kreditkarte in zwei Bereiche aufspalten: den Karteninhaberdaten (Cardholder Data: CHD) wie PAN (Primary Account Number), den Namen des Karteninhabers, den Service Code und das Verfallsdatum der Karte sowie die „empfindlichen" Authentisierungsdaten (Sensitive Authentication Data: SAD), d.h. Daten des Magnetstreifens oder des Chips, die CAV2/CVC2/CVV2/CID-Daten (die drei- oder vierstellige Zahl auf Vorder- oder Rückseite der Karte) und die PIN. Da es an dieser Stelle nur um die in Transaktionen verarbeiteten Karteninhaberdaten geht, können die Authentisierungsdaten, die üblicherweise nur beim Bezahlen am Verkaufspunkt Verwendung finden, in unserer Betrachtung vernachlässigt werden.

Da sich schon allein anhand der Karteninhaberdaten Transaktionen (z.B. Interneteinkäufe) realisieren lassen, ist die Schutzbedürftigkeit der Daten klar: es gibt für sie einen illegalen Markt, in dem der einzelne komplette Datensatz im Wert von derzeit ungefähr einem Euro gehandelt wird. Insbesondere in Rechenzentren, wo Millionen dieser Datensätze in der Verarbeitung sind, ist es unabdingbar die Sätze zu schützen.

Die Standards kümmern sich allein um die Vertraulichkeit der Daten. Richtlinien zu Verfügbarkeit und Integrität werden nicht getroffen.

Scoping

Der erste Schritt zur Einführung des PCI-Datensicherheitsstandards ist die Analyse des Umfangs, des „Scope" seiner Umsetzung. Letztendlich ist jedes Gerät (Rechner, Netzwerkkomponenten, Storage, Arbeitsplatz-PC etc.) mit dem die Daten transportiert, gespeichert, verarbeitet oder angesehen werden und jede Person, die auf eines dieser Geräte Zugriff hat, im Scope des Standards. Ohne geeignete Segmentierung, also Eingrenzung des Aufenthaltsbereichs der Daten innerhalb der verarbeitenden Infrastruktur, wäre der Standard auf alle Hardwarekomponenten und das komplette Personal anzuwenden, das damit in Berührung kommt. Dies ist offensichtlich ein nicht vertretbarer Aufwand an anzuwendender Sicherheitstechnologie und bspw. spezieller, geforderter PCI-Schulung des Personals. Die Beschreibung der genutzten Umgebung zur Verarbeitung der Daten geschieht in der Definition des Cardholder Data Environments (CDE), die detailliert dokumentiert und infolge eines Audits geprüft und abgenommen wird.

Neben der CDE selbst sind allerdings auch alle Geräte, die an ihr angeschlossen sind, im Scope der PCI-DSS-Betrachtung: Backup-Server, Mail-Server, Proxies, NTP und DNS-Server und dergleichen.

Ohnehin schreiben die Standards vor, dass der Zugriff auf die schützenswerten Daten nur dem Personal mit der geschäftlichen Notwendigkeit, dem „Business need to know", gestattet ist. Dies umfasst Mitarbeiter, die z.B. Zahlungen prüfen oder Fragen zu Buchungen beantworten müssen, jedoch nicht die Administratoren der genutzten Datenbanken und Verarbeitungs- und Transportsysteme. Ein zentraler Punkt der Standards ist somit die Vermeidung von Angriffen auf die Datensicherheit, von innerhalb der datenverarbeitenden Unternehmen und folglich auch Verhinderung über gehackte, administrative Nutzerkonten, die sich von außen Zugang zu den Daten verschaffen.

Neben dem angeführten detaillierten Architekturdiagramm der CDE inklusive angeschlossener Systeme, ist auch ein Datenflussdiagramm zu erstellen, in dem aufgeführt ist, an welcher Stelle die relevanten Daten die CDE betreten, wo sie gespeichert, transportiert und verarbeitet werden und wo sie gegebenenfalls die CDE wieder verlassen. Anhand dieser primären Dokumente lässt sich der Aufwand einer Umsetzung der Standards diskutieren, planen und abschätzen.

Weitere Best Practices

PCI-DSS dient nicht nur der einmaligen Bereitstellung einer geeigneten Umgebung zum sicheren Verarbeiten der relevanten Daten. Es müssen zudem geeignete Prozesse etabliert werden, die eine tägliche Sicherheitskontrolle, eine kontinuierliche Dokumentation von sicherheitsrelevanten Ereignissen und regelmäßige Schulungen des Personals gewährleisten, da die PCI-DSS Audits wiederholt stattfinden. Zu den geeigneten Prozessen der täglichen Kontrolle gehört ein engmaschiges Monitoring der Sicherheitskontrollen wie Firewalls, Intrusion Detection und Präventionssysteme, Überwachung der Dateiintegrität, Antivirussoftware, Zugangskontrollen und dergleichen.

Jegliche Änderungen an der Umgebung (Changes) sind auf ihre Auswirkungen in Richtung der PCI-DSS-Anforderungen zu prüfen. Periodisch (viertel-/halb-/jährlich) sind Reviews der Umgebung anzufertigen, die alle Anlagen und Lokationen, Rechenzentren, Komponenten und Software umfasst und sogar Dateien wie Auditlogs und Firewallreviews mit einschließen. Ohne auch bisher eine PCI-DSSAnforderung wörtlich zu kennen, soll klargestellt sein, dass eine Einführung der Standards einen hochkomplexen und tiefgreifenden, und ebenso kostspieligen wie aufwändigen Eingriff in die Unternehmensstruktur bedeutet.

Die Anforderungen im Einzelnen

Die Abbildung 1 zeigt die in sechs Gruppen aufgeteilten 12 Grundanforderungen von PCI-DSS. Diese Grundanforderungen spalten sich in gut 400 einzelne Anforderungen auf. Diese Anzahl reduziert sich allerdings dadurch, dass eine einzelne fachliche Anforderung („setze dies und jenes um"), oftmals gleichlautende, weitere Anforderungen nach sich zieht: Dokumentation zum Status der Umsetzung der Anforderungen, Schulung des Personal zu den Anforderungen, regelmäßige Überprüfung der Anforderungen. Somit bleiben im Endeffekt „nur" rund 120 unterschiedliche Anforderungen übrig.

Selbst diese reduzierte Anzahl an Anforderungen können nicht alle im Rahmen dieses Artikels besprochen werden. Das Dokument [3] beschreibt jedoch alle Anforderungen im Detail und gibt Hinweise auf Prüfverfahren und Anweisungen zur Umsetzung.

Erwähnenswert ist, dass nicht jede Anforderung zwingend umzusetzen ist. In Fällen, in denen eine Stelle eine explizite PCI-DSS-Anforderung aufgrund von legitimen, technischen oder dokumentierten geschäftlichen Einschränkungen nicht exakt erfüllen kann, können sog. Kompensationskontrollen in Erwägung gezogen werden. Voraussetzung hierfür ist jedoch, dass der mit der Nichterfüllung verbundene Risikozuwachs durch die Implementierung von Kontrollen an anderer Stelle kompensiert wird. Die Kompensationskontrollen werden vom Anbieter vorgeschlagen, bedürfen allerdings der Abnahme durch den QSA.

PCI-DSS kümmert sich somit um:

• Vertraulichkeit der PAN-Daten im Netzwerk und in Dateien, Datenbanken (3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs)) • 
• Maßnahmen zur Sicherung von Metadaten (in Logs etc.) 
• Sicherung der Daten in Archiven 
• Vorhandensein und Einhaltung von Changemanagement- und SIEM-Prozessen
• Entdeckung und Abwehr von Angriffen
• Abschottung der kreditkartendatenverarbeitenden Umgebung
• Physische Zugangskontrolle
• Logische Zugangskontrolle (need-to-know-Prinzip)
• Logging und Monitoring von Zugriffen
• Schulung von Mitarbeitern
• Dokumentation der Richtlinien
• Ausführen von Reviews
• Einhaltung von „Best-Practices"-Prozessen

Vorgehen in einem Kundenprojekt

Ziel des Kundenprojektes war die Umsetzung der PCIDSS- Standards zur Auditierung durch einen QSA für eine kreditkartendatenverarbeitende Anwendung in Version 3.1. Zu den Aufgaben zur Realisierung konnten frühzeitig identifiziert werden:

• Konsolidierung der Teildatenbanken für CHD auf eine Datenbank
• Konsolidierung der Transaktionsverarbeitung (Anwendung) auf ein System
• Tokenisierung und Verschlüsselung der PAN
• Entwurf und Umsetzung eines stringenten Verschlüsselungsmanagements 
• Umsetzung einer starken Verschlüsselung entlang aller Lieferwege 
• Entwurf und Umsetzung eines Betriebs- und Benutzerkonzepts für Datenbank, Anwendung und Transaktionsverarbeitung
• Entwurf und Umsetzung eines konformen Konzepts für Logging, Monitoring, Reporting und Alerting
  

Konsolidierung

Ein wichtiger Schritt in Richtung Verkleinerung des CDE war die Konsolidierung der Speicherorte und der Systeme zur Transaktionsverarbeitung. Die Vorteile der Parallelisierung (schnellere Verarbeitung, erhöhte Ausfallsicherheit) wurden dabei beschränkt. Allerdings konnte die Anzahl der beteiligten Systeme und die Anzahl der beteiligten Administratoren gedrittelt werden. Die Anzahl der angeschlossenen Systeme reduzierte sich deutlich, die Verwaltung der relevanten Nutzer konnte durch die Beschränkung des Systems auf die kreditkartendatenverarbeitende Anwendung extrem vereinfacht werden, der Scope von PCI-DSS war somit auf einen Bruchteil der gesamten IT-Landschaft heruntergebrochen.

Tokenisierung und Verschlüsselung

Ein zentraler Aspekt für die Umsetzung der Anforderung 3.4 war die Einführung einer Tokenisierung in der Anwendung, d.h. in der sechzehnstelligen PAN wird eine gewisse Anzahl an Stellen durch einen alphanumerischen Code (Token) ersetzt. In der Datenbank entsteht eine Tabelle, in der die stark verschlüsselte PAN und die tokenisierte PAN gegenübergestellt sind. Den Schlüssel zur Entschlüsselung der PAN darf außer der Anwendung selbst kein Nutzer anwenden. Eine Verarbeitung z.B. von Bulkdaten, d.h. Dateien mit tausenden Abrechnungen mit Klartext- PAN-Daten, läuft somit wie folgt ab:

• Entschlüsselung der ankommenden verschlüsselten Datei  
• Tokenisierung: Ersetzen der PAN durch tokenisierten PAN in der Datei
• Verarbeitung anhand der tokenisierten PAN
• Bei Ausgabe von Verarbeitungsdaten in Datei anschließend Detokenisierung, Verschlüsselung und Weiterversand

Das Betriebssystem unterstützt dabei die Verschlüsselung und Verarbeitung fälschungs- und abbruchsicher mit eigenen Cryptokarten. Einmalig mussten dazu sämtliche in der Datenbank gespeicherten PAN-Daten durch die tokenisierten PANs ersetzt werden. Dieses Verfahren bietet mehrere Vorteile:

• Klartext-PAN-Daten sind vom System verschwunden, Administratoren von Storage, DB und System sehen nur tokenisierte Daten
• Die zentrale Anforderung, keine PAN im Klartext zu speichern, ist erfüllt
• In Backups und Archiven existieren ebenfalls keine Klartext-PANs
• Die Schlüsselnutzung ist auf den Applicationuser begrenzt
• Klartext-PAN-Daten existieren maximal temporär im Hauptspeicher

PCI-DSS schreibt die Mindeststärke der genutzten Schlüssel vor, für die Verschlüsselung der PANs wurde ein symmetrischer Schlüssel der Stärke 256 bit und Methode AES gewählt.

Verschlüsselung der Kommunikation mit Partnern

Für den Datenaustausch mit Partnern werden hybride Verschlüsselungsmethoden eingesetzt, d.h. ein asymmetrisches Schlüsselpaar wird mit dem RSA-Algorithmus erzeugt und der öffentliche Anteil (Public Key) mit dem Partner ausgetauscht. Hybride Verschlüsselungsverfahren werden genutzt, um mit einem symmetrischen Schlüssel die Nutzlast/Dateninhalt der Datei auf effiziente und schnelle Weise zu verschlüsseln. Der symmetrische Schlüssel wird dabei für jede Datenübertragung neu generiert. Mit dem öffentlichen Schlüssel des Partners wird dieser symmetrische Schlüssel verschlüsselt und an die Datei angehängt. Somit umgeht man die technologisch aufwändigere und langsamere Verschlüsselung großer Dateien mit Schlüsseln großer Bitlänge.

PCI-DSS erlaubt nur bestimmte Kombinationen von asymmetrischen und symmetrischen Schlüsseln, so z.B. die Verschlüsselung von AES 128 bit Sessionkeys nur mit RSA 3072 bit [2] Schlüsseln. Die Verschlüsselung läuft über Kryptomodule der Hardware. Diese Module benutzen eigene, abgegrenzte Kryptoprozessoren und Speicherbereiche und stellen höchste Sicherheitsanforderungen zufrieden.

Kryptoschlüssel besitzen nur eine begrenzte Gültigkeit und werden nach Ablauf der Periode oder wenn der Verdacht einer Kompromittierung besteht ausgetauscht. Ein Prozess des Schlüsselmanagements (Verantwortlichkeiten, Kommunikationswege, Notfallprozeduren, Verwaltung von Master Keys etc.) ist daher zu definieren und wird im Rahmen des Audits überprüft.

Betriebskonzepte

Zur Erstellung der Betriebskonzepte der Anwendung, der genutzten Datenbank und des Transaktionssystems wurde ein pragmatischer Ansatz gewählt. In Workshops mit den beteiligten Administratoren prüften wir die über 400 Anforderungen auf ihre Relevanz für das einzelne Sachgebiet. Die Anzahl der zu erfüllenden Anforderungen reduzierte sich dadurch stark. Für jede übrig gebliebene Anforderung wurde ein Soll-Ist-Vergleich angestellt und diskutiert, wie eine Umsetzung stattfinden kann, womit ein Aktionsplan für das Einführungsprojekt entstand. Durch die nahe Orientierung am Wortlaut des Standards ergab sich durch die Stellungnahme zu jedem relevanten Punkt ein direkter und prüfbarer „Report on Compliance" für den folgenden Audit.

Logging, Monitoring, Reporting und Alarmierung

Auch wenn die Anforderungen zu diesem Thema in der Zahl recht gering sind, ist der technische und organisatorische Aufwand zur konformen Abhandlung enorm.

Über Audittrails muss die Nachvollziehbarkeit des Zugangs von individuellen Nutzern zu kritischen Ressourcen, ebenso wie ihre eigene Unveränderlichkeit, sichergestellt sein. Alle Zugriffe zu Karteninhaberdaten und alle Aktionen von administrativen Nutzern sind zu erfassen. Logs sind in regelmäßigen Abständen nach Anomalien und verdächtigen Tätigkeiten auszuwerten.

Logging bedeutet dabei, dass sicherheitsrelevante Aktivitäten auf dem Rechner in verarbeitbarer Form festgehalten werden.

Monitoring sorgt für eine Filterung relevanter Aktivitäten, die aus dem Logging stammen. Mittels geeigneter Filter (z.B. White- oder Blacklists) erfolgt eine sinnvolle Reduktion der anfallenden Datenmengen und kann durch Setzen von Schwellwerten (bspw. sehr häufiges Eingeben eines falschen Passworts für einen Benutzer) einen Alarm auslösen.

Das Reporting stellt die überwachten Tätigkeiten in geeigneter Form zusammen und generiert Berichte, die vom vorgesehenen Personal gesichtet werden. Bei verdächtigen Tätigkeiten erfolgt eine Alarmierung zur näheren Untersuchung und Bewertung des Alarmgrundes.

Alarmierungen können auf zwei Wegen ausgelöst werden:

• Realtime Alert
  Eingehende Meldungen aus dem Logging bzw. aus dem Monitoring werden von einem Überwachungstool in Echtzeit auf sicherheitstechnische Relevanz hin gefiltert und an ein Security Incident and Management System (SIEM) weitergegeben. Dort wird sofort ein Alarm ausgelöst, auf den innerhalb einer angegebenen Frist reagiert werden muss.
• Reports
  Aus der Gesamtheit der Meldungen wird täglich ein Report generiert, der auch zeitliche Zusammenhänge sicherheitsrelevanter Ereignisse aufdecken kann. Der Report ist täglich zu reviewen und gegebenenfalls ist ein Alarm auszulösen.
  

Funktionstrennung

Im Unternehmen sind für einzelne Tätigkeitsfelder Rollen zu definieren, so dass Sicherheitsleitlinien eingehalten werden können. Dazu gehört eine Trennung von überwachenden und implementierenden Tätigkeiten oder die Bewertung und Lösung von sicherheitsrelevanten Ereignissen.

Operative und überwachende Tätigkeiten sind demnach auf Rollen in unterschiedlichen Abteilungen der Organisation aufgeteilt. Die finanziellen, fachlichen und organisatorischen Konsequenzen aus den Anforderungen sind nicht zu unterschätzen: geeignete Tools sind zu suchen, zu evaluieren und zu implementieren, Regelwerke (Black-/Whitelists etc.) zu entwickeln, testen und einzusetzen, Prozeduren und Personal in der Organisation einzuführen.

Fazit

Dieser Artikel behandelt die hervorstechendsten Aspekte einer Umsetzung von PCI-DSS-Vorgaben [3] in einem kreditkartendatenverarbeitenden Institut. Auf dem Weg dorthin sind meist noch technologische Randthemen (Einschränkung der Zahl der Adminnutzer, Absicherung von Netzwerkstrecken durch TLS innerhalb des RZ, Einbindung von Partnern in die Sicherheitstechnologie etc.) abzudecken. Die Anforderungen sind hoch, aber aufgrund der Angriffswahrscheinlichkeit und des hohen Risikos an Ruf- und finanziellem Schaden sinnvoll.

Glossar

AES
Der Advanced Encryption Standard ist vom National Institute of Standards and Technology (NIST) als Standard definiert worden. Es handelt sich um ein symmetrisches Verschlüsselungsverfahren. 

CHD
Cardholder Data sind personenbezogene Daten, die mit einer Person verbunden sind, die eine Kredit- oder Debitkarte besitzt. 

CDE
Cardholder Data Environment ist ein Computersystem oder eine vernetzte Gruppe von IT-Systemen, die Karteninhaberdaten oder empfindliche Zahlungsauthentifizierungsdaten verarbeitet, speichert und/oder überträgt. 

Kompromittierung
Ein System, eine Datenbank oder auch nur ein einzelner Datensatz wird als kompromittiert betrachtet, wenn Daten manipuliert sein könnten und wenn der Eigentümer (oder Administrator) des Systems keine Kontrolle über die korrekte Funktionsweise oder den korrekten Inhalt mehr hat, beziehungsweise ein Angreifer ein anderes Ziel der Manipulation erreicht hat. 

PAN
Die Primary Account Number identifiziert eindeutig Kreditkarten und Debitkarten, sie ist eine Zahlungskartennummer. Die PAN ist auf der Spur 2 einer Kreditkarte/Debitkarte codiert. 

PCI-DSS
Payment Card Industry Data Security Standard (PCI-DSS) ist ein Regelwerk im Zahlungsverkehr, das sich auf die Abwicklung von Kreditkartentransaktionen bezieht. 

QSA
Ein Qualified Security Assessor (QSA) ist eine Person, die vom PCI Security Standards Council zertifiziert wurde, um Händler für die Einhaltung des PCI-DSS-Standards zu auditieren. 

RSA
Der Rivest-Shamir-Adleman-Algorithmus ist ein System für die Verschlüsselung und Authentifizierung im Internet und gilt als der am häufigsten verwendete Algorithmus zur Verschlüsselung und Authentifizierung. 

SAD
Sensitive Authentication Data sind Daten, die von Kartenausstellern zur Autorisierung von Transaktionen verwendet werden. 

SIEM
Security Incident and Event Management ist ein Ansatz des Sicherheitsmanagements, der darauf abzielt, eine ganzheitliche Sicht auf die Sicherheit der Informationstechnologie eines Unternehmens zu haben. 

TLS
Transport Layer Security ist ein Protokoll zum Schutz persönlicher Daten bei der Kommunikation von Nutzern mit Anwendungen im Internet.

Links

[1] PCI-Standards www.pcisecuritystandards.org/documents/PCI_DSS_v3-2_3_de-DE.pdf

[2] Empfehlung für die Schlüsselverwaltung - National Institute of Standards and Technology https://www.nist.gov/publications/recommendation-key-management-part-1-general-revision-3

[3] PCI-DSS Council https://www.pcisecuritystandards.org

[4] Cover credit: https://www.paymetric.com/blog/5-ways-businesses-can-reduce-pci-dss-scope/