Schlagwortarchiv für: Zahlungsverkehr

PCI DSS

Unser Dezember-Blog-Eintrag zu PCI DSS v4.0: Targeted Risk Analysis

Das Jahr neigt sich dem Ende zu – und der PCI DSS v3.2.1 auch.

Das PCI Security Standards Council (PCI SSC) hat gerade neue Dokumente zum neuen Konzept „Targeted Risk Analysis“ (gezielten Risiko­analyse) veröf­fent­licht – das nehmen wir doch gleich zum Anlass, das Thema mal etwas genauer zu betrachten.

Targeted Risk Analysis – was ist das?

Der PCI DSS v4.0 zielt darauf ab, mehr Flexi­bi­lität zu ermög­lichen. Eines der Werkzeuge hierfür ist die sogenannte „Targeted Risk Analysis“ (gezielten Risikoanalyse).

Gezielte Risiko­ana­lysen unter­scheiden sich von den firmen­über­grei­fenden Risiko­ana­lysen, die in PCI DSS v3.2.1 gefordert waren. Sie betrachten die konkreten Risiken für einen ganz spezi­ellen Anwendungsfall.

Im PCI DSS v4.0 kommen gezielte Risiko­ana­lysen an zwei Stellen vor:

  • Einige Anfor­de­rungen des Standards verlangen gezielte Risiko­ana­lysen, um festzu­legen, wie häufig eine bestimmte regel­mäßige Maßnahme durch­ge­führt werden sollte.
  • Außerdem ist die gezielte Risiko­analyse Teil des sogenannten „Custo­mized Approach“, mit dem man eine Anfor­derung auf eigene Weise, abwei­chend von der wortwört­lichen Umsetzung, umsetzen kann.

Wir werden uns hier auf den ersten Fall konzen­trieren, da wir dem Custo­mized Approach im Februar noch einen eigenen Blog-Eintrag widmen werden.

Wo wird sie gefordert?

Eine gezielte Risiko­analyse wird bei den folgenden Anfor­de­rungen gefordert:

  • 5.2.3.1: Wenn eine Organi­sation für System­kom­po­nenten evaluiert hat, dass diese üblicher­weise nicht von Malware betroffen sind und daher keine Anti-Malware-Lösung benötigen, dann muss in regel­mä­ßigen Abständen überprüft werden, ob dies immer noch so ist. Die Häufigkeit dieser Überprü­fungen muss in einer gezielten Risiko­analyse festgelegt werden.
  • 5.3.2.1: Wenn regel­mäßige Malware-Scans verwendet werden, muss deren Häufigkeit in einer gezielten Risiko­analyse festgelegt werden.
  • 7.2.5.1: Häufig gibt es nicht nur Nutzer­konten, die von Personen genutzt werden, sondern auch technische Nutzer­konten, die von Systemen oder Anwen­dungen genutzt werden. Deren Zugriffs­rechte müssen regel­mäßig überprüft werden. Die Häufigkeit dieser Überprü­fungen muss in einer gezielten Risiko­analyse festgelegt werden.
  • 8.6.3: Passwörter für die genannten techni­schen Nutzer­konten müssen geschützt werden. Die Häufigkeit der Passwort­wechsel und die Passwort-Komple­xität müssen in einer gezielten Risiko­analyse festgelegt werden.
  • 9.5.1.2.1: Zahlgeräte (Zahlter­minals) am Point of Inter­action müssen regel­mäßig inspi­ziert werden, um Manipu­la­tionen oder gar ihren Austausch zu erkennen. Die Häufigkeit und Art der Inspek­tionen müssen in einer gezielten Risiko­analyse festgelegt werden.
  • 10.4.2.1: Sicher­heits­kri­tische Logs (Security Events sowie Logs von Systemen, die mit Karten­daten in Berührung kommen, Sicher­heits­funk­tio­na­lität haben oder ander­weitig kritisch sind) müssen mindestens einmal am Tag einem Review unter­zogen werden, um auffällige Aktivi­täten zeitnah zu entdecken. Die Häufigkeit des Reviews für alle anderen Logs muss in einer gezielten Risiko­analyse festgelegt werden.
  • 11.3.1.1: Werden bei internen Schwach­stel­len­scans hochris­kante oder kritische Schwach­stellen entdeckt, müssen diese behoben werden. Für niedriger einge­stufte Schwach­stellen muss eine gezielte Risiko­analyse festlegen, wie diese zu adres­sieren sind.
  • 11.6.1: E‑Com­merce-Zahlseiten müssen regel­mäßig mit einem Mecha­nismus zur Erkennung von Änderungen und Manipu­la­tionen überprüft werden. Dieser Mecha­nismus muss mindestens alle sieben Tage angewendet werden – andern­falls muss eine geringere Häufigkeit mit einer gezielten Risiko­analyse begründet werden.
  • 12.10.4.1: Das Personal, das für die Reaktion auf Sicher­heits­vor­fälle zuständig ist, muss darin geschult werden. Die Häufigkeit dieser Schulungen muss in einer gezielten Risiko­analyse festgelegt werden.

Wie kann man die gezielte Risiko­analyse durchführen?

Wie die gezielte Risiko­analyse durch­ge­führt werden soll, ist in Anfor­derung 12.3.1 des PCI DSS v4.0 definiert. Hier ist festgelegt, dass die Analyse zunächst mindestens folgende Punkte identi­fi­zieren muss:

  • Die zu schüt­zenden Güter (Assets). Zu schüt­zende Assets sind natürlich immer die Karten­daten selbst, aber zusätzlich können es auch Assets wie Systeme oder Passwörter sein.
  • Die Bedro­hungen, gegen die die entspre­chende PCI DSS-Anfor­derung schützen soll.
    Zur Bestimmung der entspre­chenden Bedro­hungen ist es hilfreich, das „Custo­mized Approach Objective“ der entspre­chenden bzw. der überge­ord­neten PCI DSS-Anfor­derung zu Rate zu ziehen, da in dieser Zielsetzung häufig bereits Bedro­hungen benannt sind, gegen die die Anfor­derung schützen soll.
  • Faktoren, die die Eintritts­wahr­schein­lichkeit und/oder die Auswir­kungen der Reali­sierung der genannten Bedro­hungen beitragen.

Werden wir konkret und nehmen als Beispiel die Anfor­derung 9.5.1.2.1.

Hier sind sowohl die Karten­daten als auch die Zahlgeräte die zu schüt­zenden Assets.

Das „Custo­mized Approach Objective“ der überge­ord­neten Anfor­derung 9.5.1.2 ist, dass die Manipu­lation der Geräte, unauto­ri­sierter Austausch der Geräte, sowie das Anbringen von Skimming-Devices nicht ohne zeitnahe Entde­ckung durch­ge­führt werden können.

Typische Bedro­hungs­sze­narien wären also bspw.:

  • Angreifer bringen Skimming-Devices an, welche Eingaben mitlesen.
  • Angreifer geben sich als Service-Techniker oder Mitar­beiter des Geräte-Providers aus und tauschen das Zahlgerät durch ein manipu­liertes Zahlgerät aus, welches die Karten­daten anschließend mitliest und an Angrei­fende weiterleitet.
  • Angreifer stehlen ein Zahlgerät, auf dem im Fall von offline Trans­ak­tionen Daten temporär gespei­chert sein könnten.
  • Angreifer manipu­lieren das Zahlgerät so, dass dessen Sicher­heits­funk­tio­na­lität geschwächt wird (bspw. Verschlüs­selung ausgeschaltet).

Faktoren, die sich auf die Reali­sierung der Bedro­hungen auswirken können, sind in dem Fall zum Beispiel:

  • Wie leicht ist das Zahlgerät für Kunden und Dritte erreichbar? Ist es sicher befestigt?
  • Ist das Zahlgerät dauerhaft unter Beaufsichtigung?
  • Wie gut ist das Personal vor Ort quali­fi­ziert und geschult?
  • Sind das Zahlgerät und die Daten darin vor Manipu­la­tionen geschützt, und ist dies durch eine PCI PTS-Zerti­fi­zierung des Geräts und/oder eine PCI P2PE-Zerti­fi­zierung der ganzen Lösung nachgewiesen?
  • Wie stark frequen­tiert ist das Zahlgerät? (Das kann einen Einfluss darauf haben, ob es ein besonders lohnens­wertes Ziel für den Angreifer ist.)
  • Hat der Geräte-Provider in seiner Dokumen­tation Empfeh­lungen gegeben, wie häufig die Geräte überprüft werden sollen?

Aus den gesam­melten Faktoren resul­tiert dann schließlich die Analyse, die bestimmt, wie häufig eine Tätigkeit ausge­führt werden muss, um die Wahrschein­lichkeit, dass die Bedro­hungen eintreten, zu minimieren.

Faktoren und Ergeb­nisse der gezielten Risiko­analyse müssen dokumen­tiert werden.

Mindestens alle 12 Monate muss jede gezielte Risiko­analyse einem Review unter­zogen werden, um zu überprüfen, ob sie noch zutrifft. Hat es Verän­de­rungen in den Faktoren oder in der Einschätzung gegeben, muss die Risiko­analyse entspre­chend aktua­li­siert werden.

Hilfe­stel­lungen

Wie bei jeder Anfor­derung des PCI DSS v4.0 lohnt sich als erstes ein Blick in die „Guidance“-Spalte, die im Standard rechts von der Anfor­derung steht.

Zusätzlich hat das PCI SSC am 28. November 2023 drei unter­stüt­zende Dokumente veröffentlicht:

Und wie immer können Sie auch gerne die PCI DSS-Experten von SRC um Unter­stützung bitten.

Ausblick

Dies ist der letzte Beitrag zu PCI DSS v4.0 für dieses Jahr. Wir setzen unsere monat­liche Blog-Reihe nächstes Jahr fort – freuen Sie sich dann auf die Themen

  • Januar: Änderungen im E‑Commerce: Was ändert sich beim Self-Assessment Questi­on­naire A?
  • Februar: Custo­mized Approach
  • März: Änderungen im E‑Commerce: Integri­täts­schutz von Zahlseiten.

Kommen Sie gut ins neue Jahr und bleiben Sie gesund!

Unser November-Blog-Eintrag zu PCI DSS v4.0: Rollen und Verantwortlichkeiten

Neue Unter­an­for­derung in allen Requirements

In PCI DSS Version 4.0 wurde eine neue Unter­an­for­derung in die Anfor­de­rungen 1 bis 11 aufge­nommen, die die Notwen­digkeit betont, Rollen und Verant­wort­lich­keiten bei der Ausführung der jewei­ligen Anfor­derung x zu dokumen­tieren, zuzuweisen und zu verstehen (entspre­chende Unter­an­for­derung x.1.2).

Viele Firmen fragen sich, wie solch eine Zuweisung von Rollen und Verant­wort­lich­keiten aussehen kann. Muss ein neues Dokument erstellt werden? Muss dies firmen­über­greifend gelten?

Der PCI DSS lässt die Form der Dokumen­tation bewusst offen. Das Ziel ist es, dass das Personal sich seiner Verant­wort­lich­keiten bewusst ist, damit die Aktivi­täten zuver­lässig durch­ge­führt werden.

  • Fast jedem PCI DSS-Assessor ist es schon mal begegnet, dass Schwach­stel­len­scans nicht pünktlich jedes Vierteljahr durch­ge­führt wurden, weil es einfach übersehen wurde – hier hilft eine klar zugewiesene Verant­wort­lichkeit für die Einhaltung des Vierteljahres-Rhythmus.
  • Fast jeder PCI DSS-Asses­sorin ist schon einmal Kassen­per­sonal begegnet, dem nicht bewusst war, dass sie Zahlter­minals auf Verdacht auf Manipu­lation oder Austausch überprüfen müssen. Auch diese Verant­wort­lichkeit sollte klar benannt werden – ebenso die der Rolle, die das Kassen­per­sonal dafür schult.

Wie kann die Zuweisung der Verant­wort­lich­keiten also praktisch aussehen?

Nutzung bestehender Dokumentation

In vielen Firmen sind bereits Rollen und Verant­wort­lich­keiten in bestehenden Richt­linien und Verfah­rens­an­wei­sungen enthalten.

  • Ist bspw. in der Software­ent­wick­lungs­richt­linie bereits enthalten, wer den Code entwi­ckelt, wer den Code-Review durch­führt, wer Tests durch­führt und wer die Freigabe für den Rollout als Teil des Prozesses gibt? Und ist in Inter­views allen Betei­ligten diese Rollen­zu­weisung klar? Dann muss hier im Bereich Software­ent­wicklung nichts mehr ergänzt werden.

Ist aber noch keine derartige Dokumen­tation vorhanden, sollte sie erstellt werden. Ob die Zuweisung dabei im bestehenden Dokument ergänzt wird, oder ab man ein zusätz­liches Dokument erstellt, ist dabei unerheblich.

Form der Darstellung

Auch die Form der Darstellung ist frei wählbar. Natürlich bietet sich eine RACI-Matrix oder eine Variante davon an. Aber auch andere Tabellen, Listen oder Fließ­texte können den Zweck erfüllen.

Bei großen Teams mit gleich­ar­tigen Aufgaben reicht dabei oft eine Zuweisung wie „das Personal ist für die Durch­führung von Aktivität X zuständig, der Teamleiter ist für die Schulung des Personals bei Einstellung, bei Aufga­ben­wechsel und im jährlichen Rhythmus sowie für die Freigabe der Ergeb­nisse zuständig“ – bei durch­mischten Teams mit vielfäl­tigen Aufgaben muss die Zuweisung ggf. bis auf einzelne Personen runter­ge­brochen werden.

Anlehnung an die operative Umsetzung 

Bleiben Sie nicht zu nah an der Requi­rement-Aufteilung des PCI DSS – übersetzen Sie, wie Sie die Einhaltung sicher­heits­re­le­vanter Prozesse in Ihrem eigenen opera­tiven Geschäft umsetzen. Häufig sind an der Umsetzung einer Anfor­derung mehrere Rollen beteiligt – eine schreibt ggf. die Regeln auf, eine andere Rolle hält die Regeln bei der Umsetzung ein, wieder eine andere Rolle macht einen Review und/oder eine Freigabe des Umgesetzten. Wenn Sie die Schritte aufschreiben, wie Sie etwas durch­führen, lässt sich gut zuordnen, wer für die jeweilige Tätigkeit zuständig ist.

Akzeptanz der Verantwortlichkeit

Die Zuweisung sollte natürlich nicht nur dokumen­tiert sein, sondern den Personen auch bekannt sein. Entspre­chend sollte ein neues oder angepasstes Dokument im Kreis der Betrof­fenen vorge­stellt werden.

Müssen die Personen unter­schreiben, dass Ihnen ihre Verant­wortung bewusst ist? In einer anderen Anfor­derung des PCI DSS v4.0, Anfor­derung 12.1.3, wird tatsächlich eine schrift­liche Anerkennung der allge­meinen Verant­wortung für die Infor­ma­ti­ons­si­cherheit gefordert. Eine entspre­chende dokumen­tierte Anerkennung der spezi­fi­schen Verant­wort­lich­keiten der jewei­ligen Rolle wird in Anfor­derung x.1.2 nicht zwingend gefordert – man kann diese beiden Punkte, wenn man möchte, aber natürlich mitein­ander verbinden, indem man nicht nur eine generische, sondern auch rollen­spe­zi­fische Verant­wort­lich­keiten abzeichnen lässt. Diese Kombi­nation ist jedoch nicht vorgeschrieben.

Zusam­men­fassung

Was sollte also am Ende der Überle­gungen mindestens stehen?

  • Die Dokumen­tation der Rollen und Verant­wort­lich­keiten für die verschie­denen Aufgaben im opera­tiven Geschäft bei der Absicherung der Arbeit mit Zahlkar­ten­daten, und
  • Personal, das sich seiner Rollen, Verant­wort­lich­keiten und Aufgaben bewusst ist und dies in Inter­views bestä­tigen kann. 

Auf diese Weise sollte die Einhaltung der Unter­an­for­de­rungen x.1.2 machbar sein.

20 Jahre SRC

20 Jahre SRC

Vor 20 Jahren, am 27. November 2000 fand die Gründungs­ver­sammlung der Gesell­schafter der SRC statt. Das ist eine lange Zeit, aber in der Rückschau betrachtet kommt es den handelnden Personen nicht so vor. Diese Wahrnehmung ist natürlich subjektiv, aber ein entschei­dender Faktor hierfür wird sicherlich die rasante Entwicklung im Bereich der Infor­ma­ti­ons­technik sein.

Die Komple­xität der Digita­li­sierung und der stetig wachsende Bedarf, Vertrauen in neue Lösungen zu schaffen, ist die Geschäfts­grundlage von SRC, der wesent­liche Grund, warum es SRC gibt. Gleich­zeitig ist dies auch eine große Verpflichtung – nämlich dafür zu sorgen, dass neue digitale Lösungen auch wirklich vertrau­ens­würdig sind.

Anschaulich lässt sich die Arbeit der SRC an solchen Dingen erläutern, die viele Menschen im täglichen Leben erleben. Dies sind allem voran das kontaktlose Bezahlen mit Karte und Handy, der sichere Zugriff auf Bankkonten durch Dritte, die elektro­nische Patien­tenakte, die sichere Kommu­ni­kation im Zusam­menhang mit dem Galileo-System und in der Bundeswehr oder auch ganz „profane“ Dinge wie Flaschen­pfand­au­to­maten oder manipu­la­ti­ons­si­chere Regis­trier­kassen – alles Themen der Digita­li­sierung, mit denen Tag für Tag Millionen Menschen in der ein oder anderen Art in Berührung kommen. Die Entwicklung ist damit nicht zu Ende, mit Open Finance, IoT und der verstärkten Nutzung von KI-Methoden stehen noch viele spannende Themen an.

Keine dieser Lösungen wurde von SRC selbst herge­stellt oder wird von SRC betrieben, aber wir haben bei allen einen ganz entschei­denden Beitrag geleistet: Wir sorgen für Vertrauen in diese digitale Lösungen – für Zuver­läs­sigkeit, Sicherheit und Zukunfts­si­cherheit. Wir schaffen „ein gutes Gefühl“ im Umgang mit der Digitalisierung:

  • Standards für neue Techno­logien schaffen Investitionssicherheit,
  • Zuver­lässige Funktio­na­lität neuer Lösungen durch Testen
  • Technische Sicherheit neuer Lösungen durch Sicher­heits­kon­zepte und –prüfungen.

Tatsächlich ist es so, dass dieses „gute Gefühl“, das Vertrauen, so etwas wie der Schmier­stoff der Digita­li­sierung ist. Denn mit der Digita­li­sierung und Techni­sierung des Alltags geht für viele Menschen einher, dass Prozesse nicht mehr überschaubar sind und der Wahrheits­gehalt von Infor­ma­tionen manchmal unklar ist. Vertrauen ermög­licht es, diese Komple­xität zu reduzieren und eröffnet häufig erst die Akzeptanz der mit der Digita­li­sierung angestrebten neuen Möglich­keiten des Erlebens und Handelns.

Die Komple­xität der Digita­li­sierung und der stetig wachsende Bedarf, Vertrauen in neue Lösungen zu schaffen, ist die Geschäfts­grundlage von SRC, der wesent­liche Grund, warum es SRC gibt. Gleich­zeitig ist dies auch eine große Verpflichtung – nämlich dafür zu sorgen, dass neue digitale Lösungen auch wirklich vertrau­ens­würdig sind.

In den 20 Jahren seit Bestehen der SRC haben wir mehr als 20.000 Projekte durch­ge­führt. Jedes Jahr wurden es mehr und auch SRC ist Jahr für Jahr gewachsen – nicht nur bezüglich der Anzahl der Mitar­beiter, sondern ganz besonders bei der Erwei­terung der Expertise, teilweise auf Gebieten, die es zum Zeitpunkt der Gründung der SRC noch nicht gab.

Die gegen­wärtige Pandemie-Situation erlaubt es nicht, das 20jährige Bestehen angemessen feiern zu können, was wir gerne gemeinsam mit unseren Kunden gemacht hätten. Wir denken darüber nach, dies zu einem geeig­neten Zeitpunkt nachzu­holen. Aber auch ohne Party würden wir uns freuen, wenn Sie uns als unsere Kunden auch weiterhin Ihr Vertrauen schenken.

Target Risk Analysis

Frenchsys, Elitt und SRC gründen das EPayStan­dards Konsortium

Gemeinsam mit den franzö­si­schen Partnern Frenchsys und Elitt gründet SRC das EPayStan­dards Konsortium, eine Koope­ration zum Ausbau der Beratung und Unter­stützung inter­na­tio­naler Kunden im europäi­schen Zahlungsverkehr.

Als Tochter­un­ter­nehmen von Cartes Bancaires unter­stützt Frenchsys maßgeblich die techni­schen und funktio­nalen Spezi­fi­ka­tionen, so wie die Integration im franzö­si­schen Acquirermarkt.

Elitt hat den Schwer­punkt seiner Tätigkeit in der Entwicklung von Testfall­ka­ta­logen und Testtools für Terminals. Außerdem steht Elitt für innovative Zahlungslösungen.

SRC unter­stützt Entwicklung und Pflege des deutschen girocard-Systems. Dazu gehören die Erstellung funktio­naler und sicher­heits­tech­ni­scher Spezi­fi­ka­tionen für alle betei­ligten System­kom­po­nenten. Auch die Konzeption innova­tiver Lösungen zum mobilen Bezahlen ist Bestandteil des SRC-Leistungsspektrums.

Alle drei Unter­nehmen kennt die Welt des Zahlungs­ver­kehrs als wesent­liche Träger europäi­scher Standar­di­sie­rungs­in­itia­tiven wie nexo, CPACE und der Berlin Group.

Mit dem EPayStan­dards Konsortium erhält der inter­na­tionale Markt für Zahlungs­verkehr den Zugriff auf gebün­delte technische und strate­gische Beratungs­leis­tungen. Der Grund­stein der Zusam­men­arbeit wird mit Workshops für grenz­über­schreitend tätige Kunden wie Termi­nal­her­steller und Prozes­sing­dienst­leister gelegt.

In den letzten Jahren haben sich die europäi­schen Standards für Zahlungs­ver­kehrs­ter­minals weiter entwi­ckelt. Das bietet besonders für inter­na­tional tätige Akzep­tanten Chancen, um ihre Termi­nal­in­fra­struk­turen länder­über­greifend zu harmo­ni­sieren. SRC und Frenchsys bringen detail­lierte Kennt­nisse dieser neuen Standards und der beiden größten europäi­schen Zahlungs­ver­kehrs­märkte und Systeme ein. Elitt rundet die Koope­ration mit seiner Expertise zur techni­schen Vorbe­reitung von Umset­zungen und Zerti­fi­zie­rungen ab. So profi­tiert der inter­na­tionale Markt für Zahlungs­verkehr von der Kombi­nation der Stärken der Konsortialpartner.

Workshop-Konzept eMail an: mailto:contact@epec-experts.eu

 

Schlagwortarchiv für: Zahlungsverkehr