Managing Tech

Managing Technology, from the trenches

Infos

Im privaten Blog von Jan Miczaika geht es um die Arbeit mit Technologien, in Teams, und das insbesondere im Startup-Umfeld. Kontakt?
    jan -at- hitflip.de oder bei XING

Wir wurden durch unseren Kreditkarten-Processor (Wirecard) vor einigen Wochen drauf aufmerksam gemacht, dass wir für Hitmeister eine PCI DSS Zertifizierung benötigen (PCI DSS = PCI Security Standards Council Data Security Standards). Da das Thema vermutlich auf einige zukommen wird, möchte ich den Prozess kurz beschreiben. Erstmal vorneweg: dieser Artikel ist in einem miesen Denglisch geschrieben. Das tut mir Leid, aber die Terminologie kommt aus dem Englischen und wird durch die Unternehmen so verwendet.

Schritt 1: Self-Assessment Questionnaire

In einem ersten Schritt muss man ein sogenanntes Self-Assessment Questionnaire (SAQ) ausfüllen, in dem man die eigene Sicherheit in der IT bewertet. Dieses SAQ kann man als Word-Dokument herunterladen, normalerweise hat der Acquirer aber auch ein Online-Interface dafür.

Die Punkte, die man in diesem SAQ abnicken muss, sind in der Art:

  • Do not store the card-validation code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.
  • Is the PAN masked when displayed? The first six and last four digits are the maximum number of digits to be displayed.)

Wer eine Datenschutzrichtlinie und einen aktiven Datenschutzbeauftragten hat, und sich etwas Mühe mit seinem System gegeben hat, sollte da keine großen Probleme haben. Dieses SAQ muss man unterschreiben, es wird aber nicht geprüft.

Je nachdem, was für ein Merchant man ist, gibt es auch unterschiedliche Levels an Kriterien.

Schritt 2: PCI Security Scan

In einem zweiten Schritt muss ein Approved Scanning Vendor (ASV) die eigenen Systeme mit einem automatischen Test auf Schwachstellen und Löcher überprüfen. Wir haben das mit der Firma usd.de AG gemacht (von Wirecard empfohlen) aber der Scan ist standardisiert. Man kann also einen günstigen Anbieter suchen, wenn man das nicht als Anlass nehmen möchte ein komplettes Audit mit einem guten Dienstleister zu machen.

Dem ASV übergibt man eine Liste mit allen IP-Adressen, die man verwendet, um seinen Dienst zur Verfügung zu stellen. Also WWW, FTP, Mail usw. Man sollte zudem einen Termin für den Scan vereinbaren und mit dem eigenen ISP absprechen, damit keine Intrusion-Detection-Systeme während dem Scan Amok laufen.

Während dem Scan prüft der ASV die Systeme. Der Scan dauert etwa eine Stunde. Mein Tipp ist, das ist ein etwas umgebautes Nessus. Aber an die Regeln kommt man aber nicht ran. Der Scan teilt sicht in fünf Bereiche auf:

  • Information gathering (hier werden keine Lücken gefunden, sondern nur die Systeme analysiert)
  • Web server
  • TCP/IP
  • General remote services
  • Firewall

Die Vulnerabilities werden aufgeteilt in Confirmed, Potential und Information Gathered zusammen mit einer Severity (1-5). Dabei wird noch mal unterschieden, ob eine gefundene Vulnerability auch die PCI Zertifizierung verhindert, oder nur aufgezeigt wird.

Wir hatten im Scan vier Vulnerabilities:

  • Unsere PHP Version war dem ASV zu alt.
  • Unser SSL hat auch Schlüssel unter 128 bit akzeptiert.
  • Man hat an dem Server erkennen können, dass wir PHP nutzen (gut, das steht auch in den URLs, aber egal).
  • Unser Apache hatte eine XSS-Exploit Möglichkeit auf unserer HTTP 413-Fehlerseite (Mehr Infos zu diesem Exploit)

Nachdem wir die obengenannten Vulnerabilities behoben haben wurde der Scan neu angestoßen und unsere Website abgesegnet. In Kombination mit dem SAQ reicht ein erfolgreicher Scan für die Zertifizierung. Der Scan muss aber vierteljährlich wiederholt werden.

Fazit

Insgesamt ist so eine PCI Zertifizierung eine ganz lustige Möglichkeit mal zu gucken, wie sicher ein Außenstehender die eigene Website findet. Man muss das ganze aber etwas relativieren.

  • Der SAQ zeigt ganz gute Stellen auf, wo in der Organisation Probleme lauern könnten. Teilweise sind die Fragen aber ziemlich “Enterprise”-ig.
  • Der Scan ist ganz lustig. Man bekommt Feedback zu den genutzten Systemen und eventuell wird die eine oder andere Sicherheitslücke aufgezeigt. Das ganze ersetzt aber auf keinen Fall ein richtiges Security-Audit von Profis.

Zusätzlich ist die ganze Geschichte ist ganz schön teuer, wird einem aber von den credit card processors aufgedrückt.

4 Responses to “Erfahrungen mit einer PCI DSS-Zertifizierung”

  1. Du hast jetzt leider nichts über den Papierkrieg und den personellen Aufwand geschrieben, der mit auf einen zu kommt und einen im Alltag beim entwickeln und live stellen von änderungen am System “nervt”.

    Felix

  2. Ich habe das so verstanden, dass man den Prozess neu durchlaufen muss, wenn man ändert wie man Kreditkartendaten annimmt, speichert oder verwaltet. Das sollte ja halbwegs selten passieren.

    Oder hast du da andere Informationen?

    Jan

  3. Ok, kommt dann wohl aufs Level an(?).
    Wir “dürfen” bei jeder Codeänderung (Eine Person) einen Laufzettel ausfüllen, der dann durchs QM muss (Zweite Person) und nach O.K. vom QM dann zum Sysadmin (Dritte Person) die dann den Code ohne Änderungsmöglichkeit Live stellt.
    Das QM “muss” dann halt drauf achten, dass alles Sicher ist. (Nach http://www.owasp.org/index.php/OWASP_Top_Ten_Project)

    Felix

  4. Hmm die Frage ist ob das aus den PCI Standards raus kommt, oder sich jmd anderes ausgedacht hat.

    Ich denke die Verifizierung bei Code-Änderungen, die im “Bereich” der KK-Daten ist, ist legitim.

    Ob man das auf jede einzelne Code-Änderung ausdehnen muss, sei mal dahingestellt. Vor allem in einer “normalen” Web-App. Sonst kann ich ja kein Bild mehr austauschen, ohne einen ewigen Prozess.

    Jan

Leave a Reply