Schlagwortarchiv für: Update

8‑stellige BINs und PCI DSS

Am 1. April 2022 werden die Karten­or­ga­ni­sa­tionen Visa und Mastercard die BIN (Bank Identi­fi­cation Number) ihrer Karten weltweit von 6 auf 8 Stellen ausdehnen. Von einer 16-stelligen Kredit­kar­ten­nummer (Primary Account Number, PAN) dienen dann in Zukunft die ersten 8 Stellen zur Identi­fi­kation des Karten­her­aus­gebers. Die BIN wird an vielen Stellen genutzt, wo die Verwendung der vollstän­digen PAN nicht nötig ist – z.B. für das Routing von Trans­ak­tionen oder für Reportings.

BINs und PCI DSS 

Überall dort, wo eine vollständige PAN genutzt wird, müssen die Systeme, Umgebungen, Prozesse und Personen die Anfor­de­rungen des Daten­si­cher­heits­stan­dards PCI DSS (Payment Card Industry Data Security Standard) erfüllen. So sinnvoll der Schutz der PAN durch den PCI DSS ist – für die BIN ist er nicht notwendig.

Im PCI DSS ist daher beschrieben, unter welchen Bedin­gungen für Teile der PAN nicht der gleiche Schutz wie für die volle PAN notwendig ist. Wird nicht die volle PAN gespei­chert, verar­beitet oder übertragen, sondern nur einige Stellen davon, spricht man im PCI DSS von „Trunkierung“. Ist zwar die volle PAN im Hinter­grund gespei­chert, aber in einer Appli­kation werden nicht alle Stellen angezeigt, spricht man im PCI DSS bei der Anzeige von „Maskierung“. Im Alltag wird für beide unter­schied­lichen Maßnahmen auch der Begriff „ausgeixt“ verwendet; aus Sicht des PCI DSS muss man diese aber unterscheiden.

Für Trunkierung und Maskierung galten bisher folgende Regeln:

  • Maskierung: PCI DSS-Anfor­derung 3.3 besagt, dass maximal die ersten sechs und letzten vier Stellen („first 6, last 4“) der PAN angezeigt werden dürfen, solange es keinen Business Need für die Einsicht in die volle PAN gibt.
  • Trunkierung: In PCI DSS-Anfor­derung 3.4 wird Trunkierung als Beispiel für die Unkennt­lich­ma­chung von PANs benannt, aber nicht genauer definiert. Die erlaubten Formate werden jeweils von den inter­na­tio­nalen Zahlkarten-Organi­sa­tionen festgelegt und vom PCI SSC im FAQ-Eintrag #1091 zusam­men­ge­fasst. Die meisten Zahlkarten-Organi­sa­tionen hatten sich dabei auf die Regel „first 6, any other 4“ geeinigt, die viele Jahre Bestand hatte.

Änderung der Regeln für Trunkierung und Maskierung 

Aufgrund der Umstellung auf 8‑stellige BINs und der Notwen­digkeit vieler Unter­nehmen, diese zu verar­beiten, haben die Zahlkarten-Organi­sa­tionen ihre Vorgaben nun aber geändert. In der aktuellen Zusam­men­fassung im FAQ-Eintrag des PCI SSC ist nun definiert, dass für 16-stellige PANs bei der Trunkierung „first 8, any other 4“ zulässig ist.
Die (Test)Kartennummer 4012888888881881 dürfte dann in Zukunft z.B. in der Form 40128888xxxx1881 gespei­chert und verar­beitet werden – es reicht aus, wenn beliebige vier Stellen hinter der BIN ausgeixt sind.
Lediglich für kürzere PANs bleibt es bei den bestehenden Regeln „first 6, any other 4“ (Discover) bzw. „first 6, last 4“ (American Express).  Bei der Maskierung wird eine entspre­chende Anpassung der PCI DSS-Anfor­derung mit der Umstellung auf PCI DSS v4.0 erwartet.

Aus Sicher­heits­sicht ist das Ausixen so weniger Stellen keine Verbes­serung – aus der Business-Perspektive ist die Änderung aber wohl notwendig. Es bleibt zu hoffen, dass dies in der Gesamt­sicht durch andere Sicher­heits­maß­nahmen ausge­glichen wird.
Auf jeden Fall stehen in Zukunft die Anfor­de­rungen des PCI DSS der Verwendung einer 8‑stelligen BIN nicht im Wege.

Vorsicht bei der Kombi­nation verschie­dener Formate 

Händler und Dienst­leister, die mit trunkierten Karten­daten arbeiten, sollten – unabhängig von der Länge der BIN – darauf achten, den Schutz der Karten­daten nicht durch die Vermi­schung verschie­dener Formate zu schwächen.

  • Es muss darauf geachtet werden, dass die erwei­terten Trunkie­rungs­formate nur für 16-stellige PANs gelten. Die Länge der PAN muss also für die Trunkierung bei der Speicherung berück­sichtigt werden.
  • Trunkie­rungs­formate wie „first 6, any other 4“ erlauben theore­tisch das Vorliegen unter­schied­licher trunkierter Versionen der gleichen PAN. Die oben angeführte Karten­nummer könnte in einem System als 40128888xxxx1881 gespei­chert sein, in einem anderen als 401288888888xxxx. Das ist nicht verboten – es muss jedoch darauf geachtet werden, dass keiner ohne entspre­chenden Business Need die beiden Versionen zusam­men­führen kann und somit weitere Stellen der PAN – bis hin zur vollstän­digen Karten­nummer – rekon­stru­ieren kann.
    Dies gilt genauso, wenn für Maskierung und Trunkierung unter­schied­liche Formate verwendet werden.
  • Werden in einer Umgebung sowohl trunkierte PANs als auch die Hash-Werte von PANs gespei­chert, so sind die beiden Werte an sich erst einmal unkri­tisch. Lassen sich die trunkierten PANs und ihre Hash-Werte jedoch in Verbindung bringen, lässt sich über Rainbow Tables leicht die ursprüng­liche volle PAN rekon­stru­ieren. Auch in diesem Fall muss also über zusätz­liche Maßnahmen die Möglichkeit der Zusam­men­führung der beiden Versionen verhindert werden.

 

 

PCI DSS v4.0 kommt – Ein Überblick

Der PCI DSS (Payment Card Industry Data Security Standard) ist als umfas­sender Daten­si­cher­heits­standard für Zahlkar­ten­daten der inter­na­tio­nalen Zahlsysteme bekannt. Das Payment Card Industry Security Standards Council (PCI SSC) entwi­ckelt den Standard im Laufe der Zeit weiter, damit er mit fortschrei­tenden Risiken und Bedro­hungen, der sich ständig verän­dernden IT- und Zahlungs­ver­kehrs­land­schaft und geänderten Sicher­heits­an­for­de­rungen Schritt hält.

Das PCI SSC arbeitet seit langem an der neuen, grund­legend überar­bei­teten Version 4.0 des Standards. Nach drei RFC-Phasen in den zurück­lie­genden Jahren wird die neue Version nun im März 2022 offiziell auf der PCI SSC-Website veröffentlicht.
Einige Änderungen wurden bereits angekündigt und werden im Folgenden vorgestellt.

Neue Validie­rungs­op­tionen

Das PCI SSC plant, den Standard flexibler zu gestalten. Tradi­tionell besteht der vorge­sehene Weg zur Erfüllung einer PCI DSS-Anfor­derung darin, ihr Wort für Wort zu folgen. Jetzt plant das PCI SSC, eine Wahlmög­lichkeit anzubieten: Für fast jede Anfor­derung kann ein Unter­nehmen entweder die tradi­tio­nelle Variante wählen, sie Wort für Wort zu erfüllen, oder sie kann eine indivi­duelle, „custo­mized“ Validierung nutzen.

Zu jeder Anfor­derung im Standard wird das Ziel angegeben, das mit der Anfor­derung erreicht werden soll. Wenn ein Unter­nehmen der Meinung ist, dass sie dieses Ziel auf andere Weise erreichen möchte, als durch wortwört­liche Befolgung der Anfor­derung, kann sie ihren Weg dahin dokumen­tieren. Hierzu gehört auch eine Risiko­be­wertung, um die Angemes­senheit des gewählten „custo­mized“ Weges zu überprüfen. Diese Dokumen­tation, inklusive der Risiko­be­wertung, wird dann dem Assessor zur Verfügung gestellt. Der Assessor identi­fi­ziert auf dieser Grundlage geeignete Testver­fahren zur Überprüfung der Umsetzung der „custo­mized“ Maßnahmen.

Änderungen an Anforderungen 

Um sicher­zu­stellen, dass die PCI DSS-Konfor­mität das ganze Jahr über aufrecht­erhalten wird, wurden zusätz­liche Anfor­de­rungen vom PCI SSC angekündigt, z.B. die Notwen­digkeit für

  • Die Definition von Rollen und Verant­wort­lich­keiten für alle PCI-DSS-relevanten Themen, und für
  • Regel­mäßige Überprü­fungen des PCI-DSS-Anwen­dungs­be­reichs (Scope).

Darüber hinaus werden bestehende Anfor­de­rungen an verän­derte Bedro­hungs­lagen und Sicher­heits­an­for­de­rungen angepasst. Unter anderem zu den folgenden Themen wurden Änderungen angekündigt:

  • Anfor­de­rungen an die Authentifizierung,
  • Erken­nungs­me­cha­nismen und Sensi­bi­li­sie­rungs­maß­nahmen für aktuelle Bedro­hungen, sowie
  • Risiko­be­wer­tungen.

Auch die Verwendung von 8‑stelligen BINs wird berück­sichtigt werden müssen (vgl. unseren Blog-Eintrag).
Die genauen Details zu Änderungen stehen natürlich erst nach der endgül­tigen Veröf­fent­li­chung fest.

Übergangs­prozess

Das PCI SSC hat eine Übergangs­frist von zwei Jahren angekündigt, plus eine zusätz­liche Übergangszeit für grund­legend neue Anfor­de­rungen. Nehmen Sie sich also nach der Veröf­fent­li­chung im März 2022 die Zeit, die neue PCI-DSS-Version zu lesen, die Änderungen zu identi­fi­zieren und die Auswir­kungen auf Ihre Umgebung zu verstehen. Nutzen Sie dieses Jahr, um die Umstellung auf PCI DSS v4.0 zu planen und zu entscheiden, wann der richtige Zeitpunkt für Ihr Unter­nehmen ist, von Version 3.2.1 auf 4.0 umzusteigen.

Ihr PCI DSS-Berater oder ‑Auditor kann Ihnen helfen, die Intention hinter den Änderungen, Ihren Anpas­sungs­bedarf und die Validie­rungs­an­for­de­rungen zu verstehen. Bitte zögern Sie nicht, sie zu kontak­tieren. Wenn Sie noch keinen Ansprech­partner zu PCI DSS haben, wenden Sie sich gerne an SRCs Themen­ver­ant­wort­liche.

Um sich einen ersten Überblick über die Änderungen des Standards zu verschaffen, können Sie auch an unserem kosten­losen PCI DSS v4.0‑Webinar am 21./22. April teilnehmen: Hier gehts zur Anmeldung.