Ja, heute in meinem Studio habe ich Manuel zu Gast, a.k.a. Honkhase. Manuel, ich grüße dich.

Moin, moin.

Vielleicht stellst du dich trotzdem nochmal ganz kurz vor für die, die mit deinem Nicknicks anfangen können.

Ja, mein Name ist Hase, Honkhase. Ich mache Beratung und Prüfung von kritischen Infrastrukturen. Ich habe aber in meinem Vorleben, bevor ich ausschließlich kritische Infrastruktursicherheit gemacht habe, Ich habe sehr, sehr viel Payment-Card-Industry-Sicherheitsmaßnahmen, also Kreditkartensicherheit gemacht und bin dafür weltweit durch die Welt getingelt und habe eben all diese Prüfungen gemacht, all diese Systemlandschaften auditiert oder eben auch zu Zahlungsverkehr, der Verschlüsselung und dem Schutz von Kartendaten alle möglichen Dinge beraten und konzipiert.

Genau. Und wer ihn mal gesehen hat im Fernsehen, hat ihn nicht so gesehen, wie ich ihn jetzt sehe. Vielleicht findet ihr die Fotos auf Social Media, wie wir beide hier drin sitzen. Aber Manuel, schön, dass du da bist. Immer wenn ich ein Thema habe mit IT-Sicherheit, bist du mein Go-To-Guy quasi, der mir das alles hervorragend erklären kann. Und heute wollen wir mal sprechen über PCI-DSS. Geile Abkürzung. Klingt irgendwie gefährlich.

Payment-Card-Industry-Data-Security-Standard klingt eigentlich ganz einfach. Der Zahlungsverkehr, der internationale bargeldlose Zahlungsverkehr hat sich zusammengetan und Data-Security-Standard sagt es ja schon aus, die würden ganz gerne ihre Daten sichern und demzufolge haben sie gesagt, bauen wir mal einen Standard raus.

Ja und warum reden wir jetzt drüber? Weil PCI DSS auch für die öffentliche Verwaltung und vor allen Dingen auch für das Online-Bezahlen in der öffentlichen Verwaltung relevant ist. Weil hier natürlich Verträge geschlossen werden mit der Payment Card Industry, um auch Kreditkarten akzeptieren zu können. Du hast gerade schon erzählt, was PCI DSS ist. Vielleicht nochmal ganz kurz im Detail draufgehen, warum brauchen wir denn dieses PCI DSS?

Kurz gesagt, weil die Banken sich überlegt haben, wo passiert der Missbrauch bei den Händlern. Wir geben Karten heraus, die werden bei Händlern abgegriffen, also eine Magnetstreifen oder die Kreditkartennummer, die PIN und so weiter. Dann müssen ja die Händler und ihre Dienstleister alle doof sein und brauchen Sicherheit. Wir selber für uns brauchen natürlich keine, das heißt PCI DSS wird von den sogenannten Memberbanken von Visa, Mastercard und so weiter rausgegeben und die sogenannten Acquirer, also diejenigen, die das Händlerentgeltkonto betreuen und verwalten, wenn ich bei einem Händler bezahle, dann landet das Geld bei diesem Händler auf dem Konto. Die und ihre Dienstleister und die ganzen Händler selbst müssen dann diese Sicherheitsmaßnahmen umsetzen, damit die Kreditkartendaten so weit sicher sind, dass alle dieses Bezahlsystem noch nutzen wollen.

Und diese Acquirer, das ist sowas wie Payone, VR Payment und solche Geschichten, oder?

Ja genau, da gibt es noch Concades, da gibt es Airplus, da gibt es alle möglichen. In Deutschland haben wir so circa 10. Weltweit sind das etliche, die halt dieses Acquiring-Geschäft anbieten. Die gibt es allerdings, und das ist auch wichtig, nur bei Visa und Mastercard, beispielsweise bei Amex. Bei American Express gibt es das nicht, denn Amex ist ein sogenanntes geschlossenes oder Three-Party-System. Die haben keine Equirer und Issuer, also Karten herausgebende Banken und die Händler, Entgeltkontobetreiber, die sind das alles selbst. Das heißt, bei Amex habe ich nur einen Vertrag mit Amex selbst, die machen alles und bei Visa oder Mastercard, wenn ich Karten rausgeben will, muss ich eine Memberbank werden und wenn ich Karten annehmen will, eine Akzeptanzstelle sein will, dann muss ich als Acquirer da die Lizenz haben.

Genau. Und die Akzeptanzstellen sind jetzt in der öffentlichen Verwaltung die einzelnen Behörden, die euch Online-Leistungen zur Verfügung stellen, wo ihr Online-Anträge stellen könnt, die ihr dann auch direkt online bezahlen könnt mit euren Kreditkarten. Das sind dann die Akzeptanzstellen.

Genau.

Und jetzt gab es PCI DSS 4.0, der ist vor zwei Jahren rausgekommen und ist ab Ende diesen Jahres pflichtend, beziehungsweise ab 1.1.2025 ist dann auch die Karenzzeit abgelaufen und da hat sich ein bisschen was verändert und ein bisschen intensiver geworden, ein bisschen intensivere Prüfaufträge reingekommen. Was ist denn da jetzt zu tun von den Akzeptanzstellen?

Naja, die müssen halt die Kreditkartensicherheit umsetzen, je nachdem, ob sie Mail-Order, Telefon-Order, Moto-Geschäft machen, ob sie E-Commerce-Geschäft machen oder F2F, also Face-to-Face. Und dementsprechend haben sie unterschiedliche Schutzvorgaben, die sie adressieren müssen, um den Schutz dieser Kreditkartendaten einzuhalten.

Das heißt, diese Schutzvorgaben muss ich in der Behörde auch machen, wenn ich diese Terminals einsetze?

Je nachdem, was und wie ich einsetze. Ja, genau. Also die Terminals werden ja Face-to-Face-geschäft. Wenn ich diese Terminals einsetze, dann muss ich bestimmte Vorgaben eben auch umsetzen und einhalten, damit die Terminals nicht manipuliert werden etc.

Aber wir wollten ja heute über E-Payment sprechen und im E-Payment habe ich ja nicht so einen Hardware-Terminal, sondern da ist so eine Art Terminal im Netz. Und meines Erachtens laufen die alle bei den Acquirern, diese virtuellen Terminals. Was muss denn dann jetzt so eine Online-Dienst anbietende Behörde alles noch beachten und tun, damit sie überhaupt die Online-Zahlung annehmen kann?

Naja, wenn sie ein virtuelles Terminal benutzt, ist es ja kein Terminal, sondern es ist ein E-Commerce-Geschäft. Und dann muss sie halt Schutzmaßnahmen umsetzen, auch dass der eigene Server oder die geeignete Landschaft nicht manipuliert wird und dadurch die Bezahldaten beispielsweise erst in ein Man-in-the-Middle-Zwischensystem landen, dort abgegriffen werden und dann vielleicht an den Acquirer zur Autorisierung weitergeschickt werden. Das ist tatsächlich vor 10, 15, 20 Jahren schon passiert. Also das ist nichts Neues. Die Angreifer haben gesehen, oh Moment, da haben sich Händler an den Acquirer angedockt online. Ich schalte mich mal dazwischen und greife die Daten ab. Das ist dann relativ schnell rausgekommen, weil man natürlich sehr schnell merkt, woher sind die Karten abgegriffen, wenn die das sehr plump und banal machen. Das nennt sich dann der CPP, Common Point of Purchase, der dann offensichtlich irgendeinen Fraud erlitten hat, irgendeine Kompromittierung. Und dann haben die Angreifer gesagt, naja, ist ja irgendwie doof, das heißt, dann gehen wir da rein, intercepten die Daten und vor allem, wenn natürlich sozusagen versucht wurde, eine Bezahlung zu machen und die jedes Mal abbricht, aber dann die Daten missbraucht werden, ist ja relativ einfach, wo es versucht wurde. Also haben die gesagt, naja, dann schalten wir uns dazwischen, nehmen die Daten erstmal entgegen, kopieren die uns und schicken sie dann ans echte System weiter, damit die Bezahlung läuft und dann wird es schwieriger erkannt. Dann ist man hingegangen und hat gesagt, naja, wir kompromittieren mehrere. Mixen die Daten oder greifen immer nur jede vierte Visa-Goldkarte ab oder so, damit es nicht so schnell auffällt, weil man dann umso länger diese Daten abgreifen kann. Und dagegen müssen sich natürlich auch die Händler schützen. Die Zahlungssysteme haben über die Jahre diesen PCI-DSS-Standard inzwischen in der Version 4.0 weiterentwickelt. Das ist immer so ein Drei-Jahres-Zyklus, also den Standard PCDSS gibt es ungefähr seit 2005, glaube ich. Visa und Mastercard hatten vorher die Vorläufer in 2002 und 2003 ins Leben gerufen, haben das dann gemerged mit weiteren Zahlungssystemen sozusagen gemeinsam als Payment Card Industry Security Standards Council, PCI SSC, ins Leben gerufen und dann jede drei Jahre weiterentwickelt. Und da sind inzwischen Anforderungen drin, dass man sagt, die Händler müssen diese Systeme, von denen aus die Bezahlung initiiert wird in Richtung Kunde und dann auch zu uns als Akzeptanzumgebung, auch mit abgesichert werden und geschützt werden, weil diese Manipulation dieses Man-in-the-Middle schon seit vielen Jahren sehr erfolgreich funktioniert und man hat jetzt die Auflagen eben auch den Händlern mitgegeben.

Jetzt bin ich kein Händler, sondern eine Behörde. Ist in dem Jargon, ist es das Gleiche? Was muss ich tun, um meine Anwendungen so abzusichern, dass die Daten eben nicht bei mir abgegriffen werden? Wohlgemerkt, in den meisten Online-Diensten werden die Daten gar nicht eingegeben.

Also erstmal ist dem Bezahlsystem völlig egal, ob ich eine Behörde bin oder nicht. Ich bin Händler oder eine Akzeptanzstelle und nehme Kreditkartendaten entgegen und dann falle ich eben erstmal unter die Speicherung, Verarbeitung und oder Übermittlung von Kreditkartendaten und falle erstmal unter PCI DSS. Wenn ich alles an Dienstleister ausgelagert habe, zu keinem Zeitpunkt in Kontakt komme mit den Kartendaten, weil ich das an sogenannte Third-Party-Provider abgetreten habe, dann spare ich mir die ganze Arbeit. Ich brauche einen zertifizierten Dienstleister, der diese PCI DSS Zertifizierung hat und sage, okay, das ganze Thema geht an mir vorbei. Ich habe einen sicheren Dienstleister, der kümmert sich darum, der zeigt mir jedes Jahr seinen Zertifikatsupdate, muss ich nichts tun. Wenn ich in irgendeiner Form mit den Kartendaten zu tun habe oder dem Kunden, also in dem Fall dann demjenigen, der diesen Verwaltungsakt haben möchte, der dann bezahlen muss, dem sage, hier kannst du zahlen, ich pointe dich nur auf die Seite, habe ich ja schon den initialen Pointer referenziert. Und dann bin ich Teil dieser Bezahlung, obwohl ich nicht Teil der Kreditkartenabwicklung bin. Aber wenn mein System kompromittiert wird und manipuliert wird, kann ich ja schon die Bezahlung in eine andere Richtung schieben.

Vielleicht kannst du nochmal ganz sagen, was es bedeutet, wenn ich auf diese Bezahlseite pointe, was bedeutet das?

Das bedeutet, dass ich auf meinem System als Behörde oder bei dem Dienstleister, bei dem ich das alles einbetten lasse, sozusagen schon der erste Punkt bin, der irgendwie die Bezahlung initiiert oder in die Wege leitet oder die Konfiguration mit dem Dienstleister abgestimmt hat. Das heißt, da reicht der Bezahlen-Button.

Oder was?

Da reicht sowas wie ein Bezahlen-Button oder ein hier zur Bezahlung weitergehen, wir schicken dich jetzt auf die und die Seite. Da kannst du bezahlen und dann kommst du hierhin wieder zurück und dann ist es schön. Je nachdem, wie das implementiert ist, ist es eben sicherheitsrelevant und kritisch und dann ist es eben zu betrachten. Es gibt da verschiedene Arten, wie man das macht.

Jetzt hast du gespoilert, aber ich, ja genau, vielleicht sagst du nochmal, wie man die verschiedensten Arten sehen kann, wie man das betrachten kann, wie die Einbindung stattfindet.

Dann gehen wir da nur mal high level drüber, weil sonst springen wir den Rahmen und erzählen schon, wie technisch implementiert wird.

Ich habe sowieso noch ein paar Fragen an dich, aber lass mal.

Ja, ja, okay, alles klar. Also im Wesentlichen kann man sagen, es gibt ein sogenanntes Redirecting. Ich leite denjenigen auf eine andere Seite. Man ist auf meinem Behördenportal und ich sage so, ich redirecte das jetzt auf eine Bezahlseite oder auf einen Bezahldienstleister. Dann gibt es das sogenannte iFrame. Das ist, ich bette den Bezahldienstleister in meine Seite ein. Der ist quasi in diesen Rahmen reingeschnitten, aber vom Layout kann ich das so gestalten, wie wenn das eine Seite ist und von mir ist. Dann gibt es ein sogenanntes Direct Posting. Das ist über die URL, wird das direkt an den anderen weitergesendet. Es gibt JavaScript-Implementierung, wo eben JavaScript läuft immer auf dem Browser des Benutzers oder der Benutzerin, Aber das JavaScript selbst lädt die Person, die das nutzen will, ja von meinem Server als Behörde runter oder von meinem Dienstleister runter. Und dann gibt es noch sogenannte APIs, also technische Schnittstellen, mit denen ich das einreichen kann. Das sind so die, sag mal, fünf wesentlichsten Implementierungsarten.

Das ist ja quasi alles, was wir benutzen in unserer Welt, um bezahlen zu lassen.

Ja, also Bezahlung, und das muss man wirklich sagen, ist eine extrem vielfältige Art und Weise, vor allem bargeldlose Bezahlung im E-Commerce-Bereich. Es gibt alle möglichen Arten von Anbindungen, Umsetzungen mit Third-Party-Provider, ohne. Da gibt es irrsinnig viele Prüfmechanismen, die man zusätzlich kaufen kann oder mit weiteren Dienstleistern einbindet, die dann in der Prozesskette stecken oder eben alles außen vor lässt. Heißt, man kann selbst Polizeisysteme mit einbetten. Die Polizei betreibt ein System, das heißt Kuno, K-N-U-O, K-U-N-O, Entschuldigung. Und Kuno ist jetzt nicht für Kreditkarten, aber zumindest für gesperrte Girokarts. Wenn die sagen, hier wurde eine gestohlen und die haben wir jetzt hier als polizeiliches Kuno-System registriert, dann kann ich mich daran andocken und sagen, die Karte ist gesperrt, von der nehme ich genau keine Bezahlung entgegen, weil das Geld kriege ich ja nicht. Also da gibt es wirklich Tod und Teufel an Implementierungen und auch Tod und Teufel an schwachsinnigen, unseriösen und unsicheren Implementierungen, weil die Leute nicht verstanden haben, wie man sichere Bezahlprozesse einbaut oder sichere Prozessketten etabliert und das Ende-zu-Ende absichert. Von daher gibt es auch in diesen fünf Varianten sehr, sehr viele Falschimplementierungen oder total unsichere Varianten.

Jetzt hast du vorhin gesagt, wenn ich das alles an den Dienstleister outsource, quasi der sich um das ganze Handling kümmert, muss ich als Akzeptanzstelle quasi nichts mehr machen. Das stimmt ja nicht so ganz.

Wenn ich alles ausgelagert habe, dann bin ich außen vor und mache gar nichts.

Ja, aber ich muss ja mindestens diese SAQs ausfüllen.

Na, den SAQ fülle ich immer dann aus, dass ich bestätige, also die Verantwortung wahrgenommen zu haben. Ich meine jetzt nicht technische Implementierung, sondern die Zahlungssysteme haben gesagt, naja, ein Self-Assessment-Questionär ist ja ein Selbstauskunfts-Fragebogen. Diese Selbstauskunft muss ich einmal im Jahr ausfüllen, unterschreiben und zurücksenden an meinen Akzeptanzpartner, weil eben natürlich es sein kann, dass ich doch irgendwas anders gemacht habe oder dass irgendwer das schlecht implementiert hat, dass ich meine Verantwortung nicht wahrgenommen habe. Ich kann zwar den Dienst auslagern, aber die Verantwortung als Akzeptanzsteller habe ich ja trotzdem selbst, auch als Behörde. Und insofern lassen sich die Acquirer einmal im Jahr bestätigen, du hast wirklich, wirklich nirgendwo Einfluss auf die Kartendaten und die Flüsse. Du hast nur zertifizierte Dienstleister unter Vertrag. Du bestätigst jetzt explizit, dass das so ist mit einer Unterschrift einmal im Jahr, das ist dann jetzt für ein Jahr gültig und wir lassen dich in Ruhe, aber du musst schon verstehen, worum es hier geht, nämlich um Kartensicherheit und die nimmst du jetzt wahr und unterschreibst, dass du das kapiert hast. Das müssen die dann natürlich einmal im Jahr machen, aber sie müssen dann, wenn sie das wirklich alles komplett ausgelagert haben, keine technischen Implementierungen mehr vornehmen.

Jetzt schwebt über diesem ganzen Akzeptanzprozess, ganz speziell auch für die öffentliche Verwaltung, dieses Damoklesschwert der ASV-Scans. Was sind die ASV-Scans und wer muss die durchführen? Warum ist klar, aber wer muss die durchführen?

Also ein PCI DSS ASV ist ein Payment Card Industry Data Security Standard Approved Scanning Vendor. Ein Approved Scanning Vendor, also ein ASV, ist jemand, der von den Zahlungssystemen oder vom PCI Security Standards Council, dem PCSSC, zugelassen wurde, diese Security Scans vorzunehmen. Die Security Scans sind sozusagen aus dem Internet erreichbare Systeme auf bekannte Schwachstellen zu scannen und zu prüfen, also möglichst automatisiert sozusagen diese Prüfung durchzuführen und diese Scans passieren non-intrusive und non-destructive. Das heißt, sie sind nicht intrusiv, sie brechen nicht ein und sie sind nicht destruktiv. Das heißt, es gibt keinen Denial of Service oder einen Segmentation Fold oder was auch immer. Also die Vorgaben sind, dass man das als ASV-zertifizierter Scanning Vendor sicherstellen muss und das muss man dann auch einmal im Jahr gegen ein sogenanntes ASV Validation Lab gegenscannen und prüfen und die da absichtlich eingebauten Schwachstellen in allen Kategorien. Es gibt bestimmte Domänen, wie Netzwerkebene, Applikationsebene und so weiter. Da muss man aus allen Ebenen eine Mindestmenge an eingebauten Schwachstellen finden und das jedes Jahr auch wieder unter Beweis stellen.

Okay, diese Scans, die gucken also nur, was man so von außen, so aus dem Internet so sehen kann?

Genau, was man aus dem Internet erreichen kann und was eben an Bekannten über einen solchen Scan abfragbaren Schwachstellen oder Defiziten oder Informationen, also Information Gathering gilt ja auch dazu, irgendwie da ermitteln kann, korrekt.

Aber da bin ich doch eigentlich ganz schlau und fahre meine Web-Application-Firewall hoch und dann zack, sieht gar keiner mehr was von außen.

Ja, das wäre schlau, aber das ist schlecht, weil ein sogenanntes Active Protection System darf nicht aktiv sein und genutzt werden. Das ist in den ASV Scan Interferences bei den Scanning Vendors definiert. Das heißt, die Scanning-Vendoren selber, die zertifizierten Dienstleister, haben die Vorgabe zu sagen, du musst erkennen, ob ein Active Protection System aktiv ist, das irgendwas blockt oder filtert von diesem Scan. Denn ein Intrusion-Prevention-System oder eine Web-Application-Firewall oder was auch immer soll ja natürlich funktionieren, aber es ist nur ein Schritt in der gesamten Kette und diesen Schritt muss man für den Scan-Zeitraum für die IP-Adressen des ASV-Scanning-Vendors explizit deaktivieren und sagen, eine Firewall bleibt oben, alle anderen Schutzmaßnahmen bleiben oben, aber aktive Störkomponenten wie ein IPS oder eine Web-Application-Firewall, darf nicht im Einsatz sein und darf nicht den Scannen sozusagen verhindern. Weil sonst könnte ich einfach sagen, naja, immer wenn der Typ um die Ecke kommt, ich kenne ja seine IPs, muss er ja benennen, wenn der dann abfragt, fahre ich meinen EPS hoch, das sagt dann, nö, ich blocke hier einfach alles, dann bin ich ja super sicher. Die echten Angreifer gehen natürlich anders vor und insofern wäre das vielleicht Betrug und trotzdem Compliant, aber nicht hilfreich.

Okay, jetzt haben wir ganz viel Theorie gemacht. Ich würde gerne mit dir mal so einen typischen Fall durchgehen, so einen typischen Online-Dienst bei einer Kommune. Die hat sich den eingekauft bei einem Dienstleister. Ihr kennt ja diese Eva-Umsetzungen. Kaufe ich mir einen bei Dienstleister A. Meine Webseite läuft im Rechenzentrum Dienstleister B. Und Dienstleister C stellt mir das Bezahlsystem zur Verfügung. So was wie IPBL zum Beispiel, das ist E-Payment für die öffentliche Verwaltung. In meine Webseite binde ich per JavaScript, per Web Components diesen Online-Dienst ein. Der Online-Dienst wird aufgerufen und der Online-Dienst, also auf meiner Webseite wird dieser Online-Dienst aufgerufen und dieser Online-Dienst triggert dann eine Bezahlung und ruft die Paypage von zum Beispiel IPBL auf. Wer ist wo in Charge?

Also wenn Ultima Ratio ist natürlich der Akzeptanzvertragspartner in Charge und muss sicherstellen, dass die Dienstleister alle korrekt agieren. Wenn ich jetzt die IPBL-Seite scannen lasse, dann muss IPBL sicherstellen, dass kein IDS, ein IDS darf laufen, aber kein IPS, kein Intrusion Prevention oder eben kein Web Application Firewall Filter für diese genannten IP-Adressen des jeweiligen Scan-Anbieters in dem Zeitraum des Scans irgendwie das blocken. Wenn das nicht getan wurde, ich meine, für irgendjemand wird ja dieser Scan ausgeführt und auch benannt, wenn das die Behörde ist und da steht drauf, wir haben dich gescannt und das war dann aber das IPBL im Hintergrund, dann wird es trotzdem nicht konformer, wenn das IPBL ein IPS oder eine WAF aktiv hatte beispielsweise oder andere aktive Protection Systems.

Okay, das heißt, ich muss mir im Idealfall von dem IT-Dienstleister, der mir diesen EVA-Dienst zur Verfügung stellt, bestätigen lassen, dass er PCI-konform ist und ich muss mir von dem Dienstleister, der das E-Payment-System betreibt, bestätigen lassen, dass er PCI-konform ist, ich als Kommune.

Ja, von beiden müsste das dann eingefordert werden. Weil das sind ja beide Dienstleister, mit denen ich Kreditkartenabwicklung durchführe.

Okay, was dann der IPBL-Betreiber zum Beispiel tut, wie er mit seinen Payment-Service-Providern umgeht und so weiter. Das steht auf einem ganz anderen Papier, was er für zuschaut.

Das ist seine Verantwortung, genau.

Okay. Das heißt, jede Kommune, die diesen einfachen Prozess so abbildet, weil das ist der einfachste, glaube ich, der stattfindet, muss sich von den Dienstleistern bestätigen lassen, dass sie PCI-konform sind. Wenn ich jetzt auf die Idee komme als Kommune, ich baue mir doch selber noch so einen Online-Dienst, der dann auch gegen die öffentliche Schnittstelle von IPBL zum Beispiel kommuniziert, muss ich dann auch diese Scans auf meinem, oder muss ich die PCI-Konformität auch auf meiner Webseite quasi, in meinem Rechenzentrum durchführen, oder?

Moment, wenn die Kommune...

Die Kommune hat eine eigene Webseite und kommt auf die Idee, ich baue mir damit so einen Formular-Packkasten, keine Ahnung, einen eigenen Online-Dienst zusammen, der aber dann mit IPBL Na.

Wenn Sie dann Zahlungsabrechnungen über IPBL machen und IPBL für die Abwicklung nutzen, dann müssen Sie das sicherstellen, dass IPBL das a. Selber zertifiziert ist und b. je nachdem, wie die Kommune es einbaut, Sie selber noch irgendeine Compliance umsetzen müssen. Oder, wie auch immer geartet, mit IPBL oder ohne IPBL klären, wer ist der Komplett-Dienstleister. Ich muss hier nur diesen SAQ, diesen Self-Assessment-Questionnaire ausfüllen, wo ich sage, ich habe zertifizierte Dienstleister, die haben mir das bereitgestellt. Ich implementiere hier überhaupt nichts auf meinem System. Das machen die alle selbst. Ich bin raus und bin hier sauber. Dann können die das natürlich an sich vorbeivandern lassen. Wenn nicht, müssen sie in ihrem eigenen Rechenzentrum, auf ihrem eigenen Web-Server, wie auch immer, die entsprechenden Schutzmaßnahmen umsetzen, die jeder andere auch umzusetzen hat, klar.

Ich sehe gerade viele Kommunen, viele IT-Mitarbeiter von Kommunen, sehe ich jetzt gerade verzweifelt den Kopf auf die Tastatur hauen. Ich glaube, das bedeutet wahnsinnig viel Aufwand für die Kommunen, das zu tun.

Naja, also warum gibt es PCI DSS? Weil die Händler eben sehr viel Schindluder mit den Kartendaten gemacht haben. Die haben auch beispielsweise bei den E-Commerce-Transaktionen die sogenannte CVV oder CVC2 gespeichert. Das ist die dreistellige Nummer, die hinten drauf ist, die man abfragt, wenn man eine Online-Transaktion macht. Das ist eine Kartenprüfnummer, also eine Prüfnummer zu sagen, du hast physisch die Karte in der Hand. Diese dreistellige Nummer ist nicht auf dem Chip, ist nicht auf dem Magnetstreifen. Wenn du die ablesen kannst, dann hast du die Karte physisch in der Hand. Es steht in allen Standards und Sicherheitsprotokollen und Informationen, die jemals von Visa, Mastercard und sonst wem rausgegeben wurden, niemals, nie, nicht, unter keinen Umständen speicherst du diese Prüfziffer. Nie. Nicht. Nein. Pfui aus. Ich habe knapp 20 Jahre lang PCI-DSS-Beratung und Auditierung weltweit gemacht. Ich habe so oft Kartenprüfnummern in den Datenbanken liegen sehen, wo sogar die Tabelle einfach schon oder die Spalte einfach CVV hieß oder CVC. Einfach damit man direkt weiß, diese dreistellige Nummer ist genau die, die du haben willst, um einkaufen zu gehen, weil du sagst, hier ist die Kartennummer, hier ist die dreistellige Nummer. damit hast du quasi die Kreditkarte von jemandem in der Hand. Wenn also das alles über Jahre sehr extrem passiert ist, ist natürlich das Vertrauen in die Zahlungssysteme immer weniger geworden. Deswegen hatten Visa, ich glaube Visa war 2002 und Mastercard 2003, haben die dann die Vorläufer der Sicherheitsprogramme von PCI DSS ins Leben gerufen. Da haben sie gesagt, okay, wir müssen die Leute auditieren und wir müssen von außen Security Scans machen, ob die irgendwie überhaupt halbwegs sichere Systeme betreiben. Ich meine, bei kritischen Infrastrukturen ist es nicht anders. Ich sehe sehr, sehr oft archäologisch wertvolle Betriebssysteme, die irgendwie im Internet immer noch angedockt sind oder betrieben werden. Kann man machen, ist dann aber auch kacke. Die Zahlungssysteme haben dann gesagt, nee, wir scannen das jetzt und haben bestimmte Vorgaben, weil wer mit unseren Kartennummern rumfummelt, fummelt ja auch mit dem Geld unserer Kunden und vor allem auch mit unserer Vertraulichkeit und mit unserem, naja, Achtung, Seriosität. Deswegen haben die halt gesagt, Händler, die nicht verstanden haben, was sie da tun, sind ein richtig großes Bedrohungsszenario für das gesamte Öko-Infrastruktursystem bargeldloser Zahlungsverkehr, aber vor allem natürlich auch für die Marktmacht von Mastercard, Visamex und so weiter, machen wir uns nichts vor. Und dann haben sie halt gesagt, okay, wir werden jetzt dieses Programm aufsetzen, wir werden das gemeinsam machen mit anderen Bezahlsystemen, also Dynos, Discover, JCB und so alles dabei. Und die haben gesagt, jo, also Händler und all ihre komischen Dienstleister machen jetzt entweder so richtig Sicherheit mit Krypto mitkümmern, mit technisch verstehen oder sie nehmen Dienstleister, der das für die macht und der nimmt dann vielleicht ein paar Euro mehr oder ein paar Dollar mehr. Aber der hat verstanden, was er zu tun hat, denn er wird ja dann geprüft. Jetzt gibt es natürlich billige Audits, ahnungslose AuditorInnen, Tod und Teufel, aber insgesamt muss man schon sagen, machen die ganz schön viel Druck und ganz schön viel Stress und das ist auch immer mehr, ich sag mal, nach oben eskaliert. Da sind große Konzerne, die Prüfer waren, wirklich deregistriert worden, weil die einfach scheiße geprüft haben. Es sind Unternehmen bankrott gegangen, weil sie einfach als Dienstleister unseriös gearbeitet haben und dann hochgenommen wurden und die Zahlungssysteme gesagt haben, so schlecht achtet ihr auf die Kartendaten unserer Kunden und auch der Händler. Okay, wir klemmen euch vom Visa- und Mastercard-Netz ab. Ihr macht gar keine Transaktion mehr mit uns. Und in dem Moment kannst du als Bezahldienst, Nessart Party, kannst du deinen Laden zumachen. Und genau solche Insolvenzen sind passiert. Und damals, als das kam... Habe ich noch gesagt, das wird eine ganz schöne Verschiebung bewirken. Viele Händler werden selber die Kartendaten nicht mehr speichern, verarbeiten, übermitteln. Die werden Dienstleister nehmen. Wir werden eine Marktkonsolidierung erleben. Und genau das ist eingetreten, weil diejenigen, die gesagt haben, das ist alles so viel, ich verstehe das nicht, das ist ja doof oder mimimi, ja, dann geh weg und verarbeite einfach keine Kartendaten mehr. Schnapp den Dienstleister, der es verstanden hat. Das hat eine Weile ganz gut funktioniert. Jetzt ist aber die nächste Evolutionsstufe, dass man genau solche kruden Anbindungen hat und die Angreifer natürlich gesagt haben, ja geil, ich mache Man-In-The-Middle in all diesen kaputten Implementierungen und greife dann halt davor an. Es gibt Parallelenzeug-Chat-Kontrolle. Man wollte die Daten mitlesen, dann wurde immer mehr verschlüsselt und dann hat man gesagt, naja, bevor die dann verschlüsselt werden, greifen wir sie ab. Im Endeffekt machen die Bezahldienstangreifer nichts anderes. Die greifen das dann davor ab, nämlich bei der Behörde beispielsweise und sagen, hier, liebe Kommune, du hast einfach mal eine 3,50 Euro Webseite aufgesetzt und von da aus geht der Bezahlprozess los. Ja, geil, dann bedienen wir uns einfach an dieser Stelle. Das ist Supply Chain und schwächstes Glied in der Kette. Und genau das versuchen die Zahlungssysteme gerade wieder zu unterwandern und zu unterbinden und zu sagen, können die Ahnungslosen mal aufhören, mit den Kartendaten zu arbeiten oder den Prozess einzuspeisen, weil inzwischen schon die Einspeisung des Prozesses unterwandert wird. Und dann muss ich dazu sagen, ausnahmsweise mal richtig gedacht. Ja, das finde ich gut. Also gut.

Ist jetzt da der nächste Schritt, diese Tokenisierung der Kreditkarten? Weil da habe ich ja einen Token für jede Akzeptanzstelle. Da kann ich ja nicht mit dem einen Token bei der anderen Akzeptanzstelle bezahlen.

Also die Tokenisierung ist ja erstmal ein, ich zahle nicht mit der Karte und der Kartennummer, sondern die Kartennummer wird umgewandelt in ein eindeutiges Token, was eins zu eins zu einer Karte gemappt werden kann. Aber ich kann es nicht berechnen. Das ist sozusagen eine Zufallszuordnung 1 zu 1 und teilweise sogar pro Transaktion ein Token. Diese Tokenization ist schon vor vielen Jahren entwickelt worden. Ich habe da viele Implementierungen mitberaten oder eben auch geprüft, teilweise sogar auf Mainframes, also wirklich Hochleistungstokenisierung für viele hunderte von Millionen von Datensätzen. Wenn ich aber in den Anfang, in den absoluten Beginn des Prozesses eingreife, dann kann ich auch da natürlich schon manipulativ wirken und sagen, ich schaffe, dass die Endnutzerin ihre Kartennummer eintippt, aber in meinem System und ich gebe es dann weiter und dann wird es tokenisiert, dann ist es auch zu spät. Also beim Tokenisieren gibt es auch unheimlich viele verschiedene Arten der Implementierung und von daher muss man da auch aufpassen, was da sozusagen sicher und sinnvoll ist oder an welcher Stelle ich mir durch ein Tokenisieren auch tatsächlich erspare, zu sagen, ich muss mehr machen als nur in dem SAQ ausfüllen. Ich habe Dienstleister, die verstanden haben, was sie tun. Die zeigen mir jedes Mal ihr Zertifikat. Ich selber speise hier überhaupt nichts irgendwo ein, bin safe und muss aber natürlich diese Verantwortung nachher wahrnehmen, weil die geht nun mal nicht weg. Ja.

Gibt es oder kennst du Bezahlsysteme, wo ich nicht irgendwie Credentials eingeben muss, wie eine Kreditkartennummer oder Benutzernamen oder ähnliches? Also wo ich mir diesen ganzen Anfang sparen kann, wo ich hier nochmal ein bisschen mehr Sicherheit schaffe, indem ich nichts abgreifen kann oder wenn ich es abgreife, damit nichts anfangen kann?

Also ich würde jetzt ungern namentlich welche nennen und sagen, die sind gut oder da kenne ich die Implementierung. Es geht nicht darum.

Ob es gut ist, es geht nur darum, ob es es gibt.

Ja, also gibt es schon, klar. Es gibt Anbieter, die sich Gedanken dazu gemacht haben und wirklich verstanden haben, was wollen die Zahlungssysteme und was will eigentlich die Akzeptanzstelle. Und die das dann so aufgebaut haben, dass sie sagen, ich baue das jetzt alles um dich herum auf und mache das für dich als Ersatzleistung quasi. Allerdings ist es wie immer, kostet natürlich Geld und man muss ja auch, wenn man einen Dienstleister irgendwie haben möchte, im Einkauf ja auch irgendwie verstehen, was ich einkaufen will und auch gegenprüfen können, was derjenige mir leistet und bietet. Und wenn natürlich die Kommunen schon damit überfordert sind zu verstehen, was bieten die da an, was ist der Unterschied und bin ich damit sauber und kann ich dann auch verstehen, was ich da einkaufe und habe die richtige Dienstleistung. Wenn ich da im Einkauf scheitere, dann habe ich eher Zufall, aber nicht, ich weiß, was ich einkaufe. Und das ist immer das Problem bei allen Digitalisierungen. Wenn der Einkauf in den ganzen Kommunen nicht verstanden hat, was er da einkauft, dann können die Dienstleister alles Mögliche leisten, was irgendwie so aussieht oder den Anschein erweckt oder vielleicht sogar tatsächlich sicher ist, aber nicht funktional oder umgekehrt. Und dann bekomme ich irgendwas, nur nicht einen Dienstleister, der das tut, was ich will. Dafür brauche ich nämlich A, einen kompetenten Einkauf und B, eine Dienstleistersteuerung, also ein Outsourcing oder Partymanagement. Und das kann ich nicht auslagern, denn ich muss ja oder kann ich schon, aber das endet dann so, wie wir es an vielen Stellen gesehen haben. Da sitzen dann teilweise Dienstleister an einem Tisch und verhandeln über die Systemlandschaft der Kommune, wo ich dann gefühlt rückwärts umkippe und sage, ist es keiner, kein Verantwortlicher aus dem Laden selbst hier. Es reden Dienstleister untereinander und tauschen sich aus und stimmen sich ab, was sie wie für die tun. Das sind erlösmaximierende Unternehmen. Das kann doch nicht wahr sein. Aber genau das gibt es oft genug. Und wenn ich das hier so mache und einkaufe, dann muss ich mich auch nicht wundern, wenn das so läuft.

Es geht noch schlimmer, aber...

Naja, natürlich. Nach oben ist immer offen.

Also, Manuel, wir haben ja bei unserem Vorgespräch vor zwei Wochen, sind wir ja richtig tief reingenerdet. Das möchte ich jetzt unseren Zuhörerinnen und Zuhörern ersparen. Das ist sinnvoll.

Ja, das war wirklich tief und es ist ja auch wirklich sehr, sehr detailliert. Und es sprengt auch den Rahmen, sowas mal kurz zu machen. Ich habe, um Händlern oder auch Dienstleistern überhaupt mal zu erklären, was ist PCI DSS, worauf musst du achten, wie musst du das umsetzen, wenn du wirklich Kartendaten speicherst, verarbeitest oder übermittelst. Nicht nur so, ich habe eine Webseite und da ist so ein Link, sondern ich mache das. Das Intro, um überhaupt zu verstehen, worum es geht und mal das Gesamtwerk zu sehen, war ein zweitägiger Workshop und zwar intensiv. Ich habe den bei dem einen oder anderen Konzern oder größeren Unternehmen irgendwann dann runtergedrückt bekommen. Die haben gesagt, mach das in den einzelnen Abteilungen innerhalb von einem Tag. Das hieß dann die Druckbetankung vom Hasen. Und die Druckbetankung war dann vieles, was einfach in dem jeweiligen Konzern oder so nicht notwendig war, habe ich weggelassen. Aber das war schon Druckbetankung. Und da waren wirklich hochgestandene, seriöse und kompetente Menschen, die mit so einem rauchenden Schädel rausgegangen sind. Die haben nicht mehr gerade ausgeguckt. Es ist einfach wirklich ein sehr komplexes Thema.

Wir haben, damit wir hier nicht so rein nerden müssen, haben wir eine umfangreiche Linksammlung zu den wichtigsten und einschlägigsten Dokumenten. Die meisten sind auf Englisch, aber meines Erachtens ganz gut verständlich. Vor allen Dingen sind viele Grafiken dabei und man kann viel auch nachvollziehen. Findet ihr alles in den Shownotes. Und Manuel, vielen, vielen Dank.

Gerne.

Für diese Kurzdruckbetankung.

Genau.

Und euch liebe Zuhörerinnen, liebe Zuhörer, bis zum nächsten Mal.

Bis zum nächsten Mal.