PCI DSS

13 05, 2017

Die fünf Stufen von PCI DSS

von |13. Mai 2017|PCI DSS|0 Kommentare|

Der Artikel ist nicht von mir, er ist aber lesenswert und ich kann die Erfahrungen bestätigen:

Had a meeting with a prospect recently that is bound and determined to avoid PCI compliance yet still will accept payment cards.

My response?  Good luck with that!

You would think after 15 years of PCI (and actually even longer) that people would understand that PCI compliance is a fact of life.  But I continue to find that PCI is no different than the five stages of grief.

Denial

This is where that prospect is now.  They cannot believe that there is no way to avoid PCI compliance.

For once and for all, if your organization accepts payment cards, you MUST comply with the PCI DSS.  Do not like that answer?  There is nothing as a QSA I can do to effect that fact.

However, for merchants there is a way out.  Do not accept payment cards for payment.  It is that simple.

That answer though immediately leads to the next stage.

Quelle: http://pciguru.wordpress.com/2017/04/28/the-five-stages-of-pci/

1 09, 2016

Ein Fazit nach 8 Jahren PCI DSS – Gute vs. miserable PCI Auditoren (QSAs)

von |1. September 2016|PCI DSS|0 Kommentare|

Heute wieder einmal einen erfolgreichen PCI DSS Onsite Audit für einen Kunden über die Bühne gebracht. Nahezu reibungslos. Der QSA (Qualified Security Assessor) war zufrieden, der Kunde – ein Zahlungsdienstleister – war zufrieden. Keine Diskussionen. Keine Missverständnisse. Super Ergebnis.

Aber ein wenig nachdenklich macht mich dieser letzte Audit. Was waren die Erfolgsfaktoren? Vorbereitung ist alles! Denkste… das ist nicht immer so. Ein riesiger Erfolgsfaktor ist der Auditor selbst. Ich habe schon ein paar hinter mir:

(sorry Jungs, meine Meinung)

Schnarchnasen. Unvorbereitet. Überfordert. Unsicher im PCI Standard. Verrückte oder absurde Interpretationen. Keine Ahnung von iptables. Man kann Two Factor Authentication auch missverstehen. Philosophische Interpretationen von „all traffic“… uvm.. WTF!

Man kann den CISSP, CISM, CISA bzw. wohl auch die QSA-Lizenz schaffen und so grundsätzlich von Sicherheitskonzepten nicht viel verinnerlicht haben. Wie oft habe ich Auditoren für Kunden „eingefangen“, die Diskussion zurück auf den PCI DSS bezogen und Interpretationen korrigiert.

Es gibt hervorragende QSAs. Und es gibt viele schlechte. Erfolgsfaktor für die eigene PCI Compliance? Die richtige QSA Company mit dem richtigen Auditor wählen. Die falsche Wahl kann Auswirkungen auf die IT und auf die betrieblichen Prozesse haben. Die richtige Wahl macht PCI DSS auch nicht einfacher, aber schützt vor Überraschungen – sowie vor grauen Haaren und Buthochdruck.

16 04, 2016

Übersicht QSA-Unternehmen für PCI DSS Audits in Deutschland

von |16. April 2016|PCI DSS|0 Kommentare|

PCI DSS Audits dürfen ausschließlich vom PCI Council zugelassene Unternehmen mit als QSA zertifizierte Auditoren durchführen. Unter [1] kann man sich die komplette Liste ansehen. Filtert man auf Unternehmen, die als „Place of Business“ Deutschland und als Sprache „Deutsch“ anbieten, ergibt sich eine Liste mit 8 Unternehmen:

  • Adsigo AG
  • Internet Security Systems a wholly owned IBM Company
  • NTT Com Security (UK) Ltd.
  • Protiviti
  • SRC Security Research & Consulting GmbH
  • TUV SUD Management Service GmbH
  • usd AG
  • Verizon/CyberTrust

Als „deutsche Unternehmen“ (mit deutscher Rechtsform) bleiben nur noch

  • Adsigo AG
  • SRC Security Research & Consulting GmbH
  • TUV SUD Management Service GmbH
  • usd AG

Zu drei dieser Unternehmen hatte ich bisher in irgendeiner Art und Weise Kontakt. Wer gerne eine persönliche Empfehlung haben möchte, darf mich gerne kontaktieren. Aus eigener Erfahrung weiß ich, wie wichtig ein kompetenter und erfahrener QSA für die erfolgreiche und effiziente Durchführung eines PCI DSS Audits ist.

[1] https://de.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors

12 09, 2014

Änderungen im PCI 3.0 Req. 11.3 Penetration Testing – Erläuterungen und Diskussion

von |12. September 2014|PCI DSS|0 Kommentare|

Der PCI DSS 3.0 verlangt in Requirement 11.3 die Durchführung von Penetrationstests. Im älteren PCI-Standard 2.0 umfasste das bisher primär einen Penetrationstest auf Netzwerk- sowie auf Anwendungsebene, der sowohl von extern als auch von intern durchgeführt werden musste. Der Penetration Tester musste dabei natürlich qualifiziert und unabhängig sein.

Diese Punkte sind zwar inhaltlich auch im neuen PCI DSS 3.0 enthalten, jedoch wurden die Anforderungen und auch der Umfang der Penetrationstests erhöht. Nachfolgend möchte ich das neue Requirement 11.3 besprechen und auf die neuen Details eingehen.

11.3 Implement a methodology for penetration testing that includes the following:
– Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)

Durch den zwingenden Verweis auf eine allgemeine akzeptierte Best-Practice Vorgehensweise wie NIST SP800-115 sind damit alle Pentest-Monkeys raus, die einfach nur ein paar Tools wie Metasploit, Nessus & Co benutzen und das ganze dann in einen Report fassen. Andere aus meiner Sicht akzeptierte Vorgehensweisen sind der OWASP Testing Guide oder auch OSSTMM. Interessanterweise beinhaltet der NIST SP800-115 zwar auch Vorgehensweisen zum klassischen Penetration Testing, behandelt aber insgesamt das Thema „Information Security Testing and Assessment“. Ich hätte hier eigentlich einen Verweis auf ein reines Pentesting-Dokument erwartet. Damit deutet sich eine Erweiterung des eigentlichen Penetration Testing im Sinne des PCI DSS an, der z.B. zusätzlich auch technische Reviews beinhalten kann.

– Includes coverage for the entire CDE perimeter and critical systems
– Includes testing from both inside and outside the network
– Includes testing to validate any segmentation and scope-reduction controls

Die ersten beiden Punkte sind nicht neu. Der Pentest muss die gesamte PCI-Umgebung umfassen und von außen sowie von innen durchgeführt werden. Der dritte Punkt hat es dafür in sich: Die (oftmals vorhandene) Netzwerksegmentierung zwischen PCI-Scope und Nicht-PCI sowie die dafür eingesetzten Sicherheitsmaßnahmen müssen auf ihre Wirksamkeit hin geprüft werden. Mein erster Gedanke dabei war: Wie soll ein Penetration Tester das umsetzen? Eigentlich geht das nur über einen kompletten Review der Netzwerkpläne, Kommunikationsverbindungen und Firewall-Regeln, die für die PCI-Umgebung und die daran angeschlossenen Bereiche relevant sind. Das kann dann sicherlich durch einzelne klassische Techniken des Penetration Testing ergänzt werden, aber eigentlich fordert dieser Punkt mehr einen technischen Security-Audit. Diese Änderung geht dabei in die gleiche Richtig wie der vorher beschriebene Verweis auf den NIST SP 800-115. Der Penetrationstest wird mehr zu einem Security Assessment erweitert. Kernbestandteil bleibt zwar weiterhin der eigentliche Penetration Test, jedoch wird das der Umfang eines Penetrationstest im Sinne des PCI DSS durch die Änderung im neuen Standard 3.0 deutlich erweitert.

– Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
– Defines network-layer penetration tests to include components that support network functions as well as operating systems
– Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
– Specifies retention of penetration testing results and remediation activitiesresults.

Die letzten Punkte konkretisieren noch etwas genauer, was eigentlich geprüft werden soll, und dass gefundene Schwachstellen natürlich angemessen behandelt werden wollen. Das ist inhaltlich identisch mit dem alten Standard, außer dass noch ein Augenmerk auf die Bedrohungen und Schwachstellen der letzten 12 Monate gelegt werden muss. Die Umsetzung erfordert in diesem Punkt eine sehr gut gepflegte Dokumentation eines Unternehmens, welchen Bedrohungen und Schwachstellen es ausgesetzt war. Der Penetration Tester muss dann diese Punkte speziell nochmals verifizieren.

11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation
controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.

In der Häufigkeit der Pentests gab es keine inhaltliche Änderung: Jährlich oder nach signifikanten Änderungen. An der Frage, was eigentlich genau signifikante Änderungen sind, scheiden sich immer noch die Geister. Eigentlich ist der PCI-Standard da sehr deutlich, so ist z.B. ein neuer Webserver bereits eine signifikante Änderung. In der Praxis hängt das von der Bewertung des Auditors ab. Aus der reinen sicherheitsrelevanten Betrachtung wäre es natürlich optimal, nach jeder (signifikanten) Änderung einen Test durchführen zu lassen. In der Realität müsste man jedoch bei Tagessätzen von über 1.000€ für Pentester gleich das Security-Budget enorm aufwerten. Unternehmen müssen in der Praxis für die Auslegung des schönen Begriffs „signifikant“ viel Feingefühl verwenden. Ansonsten muss auch bei Änderungen der Segmentierung zwischen Scope vs. Non-Scope ein neuer Pentest durchgeführt werden.

Wie sonst auch oft im PCI DSS verstecken sich gerne in den Prüfprozeduren für die eigentlichen Anforderungen weitere Anforderungen. Im Bereich des Requirements 11.3 ist dieses auch so:

Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

Diese versteckte Anforderung in den Testprozeduren zum 11.3er wurde inhaltlich zum PCI-Standard 3.0 nicht geändert. Der Pentester muss kein QSA oder ASV sein und es wird kein konkreter Nachweis einer bestimmten Qualifikation gefordert. Sofern die Qualifikation offensichtlich ist, also der Pentester z.B. mehrere Jahre Berufserfahrung als Penetration Tester oder einschlägiger Zertifikate wie z.B. den OSCP nachweisen kann, ist die Sache klar. Ansonsten liegt es im Ermessen des Auditors. Unabhängig muss er verständlicherweise auch sein, d.h. entweder ist er gleich von einem anderen Unternehmen oder er ist innerhalb des Unternehmens unabhängig von der eigentlichen IT.

Insgesamt denke ich, dass die Änderungen im PCI DSS 3.0 bezüglich des Requirements 11.3 richtig und gut sind. Die Durchführung nach einem international akzeptierten Vorgehensmodell ist zwar keine Garantie für einen guten Penetrationstest, aber zumindest eine Voraussetzung dafür. Die neue Prüfung der Effektivität der Scope-Trennung wird primär nur durch den Einsatz von Reviews möglich sein. Letztendlich führt hier der Penetration Tester eine technisch fundiertere Analyse durch, als es ein Auditor bei der Festlegung vom Scope durchführen kann.

23 07, 2014

Der Schwachpunkt PCI Compliance über SAQs

von |23. Juli 2014|PCI DSS|0 Kommentare|

Grundsätzlich müssen alle Unternehmen PCI DSS erfüllen, die Kreditkartendaten bzw. Karteninhaberdaten weiterleiten, speichern oder in irgendeiner anderen Art und Weise verarbeiten. Dies bezieht sich insbesondere auf die vollständige PAN (Personal Account Number), d.h. der Kreditkartennummer sowie auf die weiteren Authentifizierungsdaten des Karteninhabers  wie z.B. Prüfsumme und PIN. Die Anforderungen sind grundsätzlich für alle Unternehmen gleich.

Allerdings gibt es enorme Unterschiede im Nachweisverfahren der PCI DSS Compliance, also im Nachweis der eigenen Konformität zum Standard. Das Nachweisverfahren unterscheidet sich zwischen VISA, MasterCard & Co zwar teilweise im Detail, jedoch ist es im Groben identisch. Ausgehend von VISA Europe[1] muss ein Händler (Merchant) seine PCI DSS Compliance durch einen unabhängigen Auditor (QSA – Qualified Security Assessor) nachweisen lassen, wenn er jährlich über sechs Millionen VISA Transaktionen abwickelt. Er ist in diesem Fall ein sogenannter Level 1 Merchant und muss einen Vor-Ort-Audit in Auftrag geben, bezahlen und  auch erfolgreich abschließen. Unterhalb der Grenze von sechs Millionen Transaktionen entfällt dieser Nachweis. Ab diesem Merchant Level 2 reicht das Ausfüllen und Unterschreiben eines Selbstfragebogens (SAQ – Self Assessment Questionnaire) – ein unabhängiger Audit ist nicht mehr notwendig. Der Merchant attestiert sich sozusagen selbst die PCI DSS Compliance.

Es gibt verschiedene SAQs – SAQ A, C-VT, C und D – wobei ein Merchant in einem SAQ A bestätigt, dass er hat niemals eine digitale Zugriffsmöglichkeit auf die PANs & Co besitzt. SAQ D ist die maximale Steigerung und beinhaltet alle PCI DSS Anforderungen.

In beiden Fällen (Merchant Level 1 und Level 2) muss der Merchant zusätzlich noch einen externen Schwachstellen-Scan bei einem vom PCI Council akkreditierten ASV (Approved Scanning Vendor)  durchführen lassen und ihn ohne pci-relevante Schwachstellen bestehen. Dieser Scan besitzt meiner Meinung nach allerdings keine hohe Aussagekraft: Er kann nur offensichtliche Schwachstellen von außen finden. Zusätzlich lässt sich ohne kompletten Review der IT auch nur sehr schwer beurteilen, ob wirklich der gesamte Adressbereich geprüft wurde.

Gerade Merchants, die selbst Zugriff auf die PAN haben möchten und / oder ihre Zahlungsabwicklung nicht komplett outsourcen wollen, stehen prinzipiell vor der Wahl:

Die technischen, organisatorischen, personellen und damit auch finanziellen Herausforderungen des PCI DSS annehmen oder ein (in der Tat erhebliches) Risiko akzeptieren und den SAQ C-VT, C oder D nicht wahrheitsgemäß ausfüllen.

Das SAQ-Verfahren ist für Merchants sicherlich kostengünstig, stellt aber ein großer Schwachpunkt in der nach unten verzweigten Kette der PCI DSS Compliance dar. Selbst wenn der Merchant eine korrekte Compliance beabsichtigt, braucht er unabhängige interne Kontrollverfahren zur Sicherstellung der Compliance. Die müssen zudem tatsächlich wirksam sein.

Ich halte grundsätzlich einen unabhängigen Audit oder das komplette outsourcen der Zahlungsabwicklung an einen Dienstleiter für sinnvoller. Die SAQs sind eine nicht kalkulierbare Schwachstelle im Nachweisverfahren der PCI DSS  Compliance.

[1] http://www.visaeurope.com/en/businesses__retailers/payment_security/merchants.aspx

14 02, 2014

Wer muss PCI DSS erfüllen?

von |14. Februar 2014|PCI DSS|0 Kommentare|

Im Blog der binsec ist von mir über die Fragestellung, welche Unternehmen PCI DSS erfüllen müssen, ein Beitrag erstellt worden:

Grundsätzlich fallen alle Unternehmen, die Kreditkarteninformationen verarbeiten, speichern oder weiterleiten in das Anwendungsgebiet vom Payment Card Industry Data Security Standard (PCI DSS). Darunter können z.B. Händler, Zahlungsdienstleistern und Finanzinstitutionen fallen. Auch Dienstleister oder Outsourcing-Partner, die z.B. das Fraud-Management übernehmen oder Dienstleister für Hotels unterliegen PCI DSS… mehr

19 01, 2014

Microsofts Cloud Azure, PCI DSS und die Kreditkartenspeicherung

von |19. Januar 2014|PCI DSS|0 Kommentare|

Microsofts Cloud Azure wurde von dem Unternehmen Neohapsis PCI DSS zertifiziert, sodass sich Azure grundsätzlich als Cloud für Kreditkartenzahlungsanwendungen verwenden lässt. Die Nutzung einer PCI-Cloud entlässt ein Unternehmen nicht aus der Pflicht sich selbst PCI zertifizieren zu lassen.  Vielmehr werden die Anforderungen des PCI DSS zwischen dem Cloud-Anbieter und dem Cloud-Kunden geteilt. Im Gegensatz zu Amazon gibt Microsoft offen an, für welche Anforderungen sie zuständig sind: Link

Manche Anforderungen gehen vollständig an Microsoft über, andere bleiben komplett beim Kunden. In einem Bereich sehe ich in der Praxis Umsetzungsschwierigkeiten: Möchte der Kunde Kreditkartendaten speichern, muss er sich um die Anforderung 3  und deren Unteranforderungen nahezu komplett selbst kümmern. Das aufwendige und komplizierte Thema Verschlüsselung inklusive dem notwendigen Key Management bleibt beim Kunden. In wie Weit die Nutzung von HSMs (Hardware Security Modules)  bei Azure möglich ist, darf bezweifelt werden. Bleibt nur der Einsatz manueller Klartext-Keymanagementverfahren  oder das Outsourcing der Speicherung der Kreditkartendaten an einen anderen Dienstleister. Beides ist meiner Meinung nach suboptimal.

12 10, 2013

Der richtige Umgang mit QSAs / Auditoren für PCI DSS

von |12. Oktober 2013|PCI DSS|0 Kommentare|

Letztens habe ich für einen Kunden wiederholt den Audit begleitet und erfolgreich abgeschlossen. Ich möchte an dieser Stelle betonen, wie wichtig der richtige Umgang mit dem QSA ist. In manchen (vielleicht auch vielen?) Unternehmen wird der QSA als Feind gesehen, er ist der „böse Auditor“. Das stimmt so nicht und ist auch ein Fehler. Ein zertifiziertes oder demnächst zertifiziertes Unternehmen ist der Kunde und die QSA-Company der Dienstleister. PCI-Audits sind keine behördliche Prüfung einer Aufsichtsbehörde für Datenschutz oder ähnliches. Man bezahlt für den Audit, also sollte man das Beste aus der Situation machen.

Verliert man die Ansicht, dass der Audit der „böse“ ist und ruft sich in Erinnerung, dass man für seine Dienstleistung bezahlt, ändert sich auch automatisch die Herangehensweise. Der beste Umgang mit einem QSA ist die offene Variante. Man sollte eventuelle Probleme offen ansprechen und mit ihm darüber sachlich diskutieren. Nochmals: Offen und sachlich! Wenn man weiß, dass vielleicht ein Compliance-Problem lauert, kann man das am besten gleich ansprechen. Und zwar direkt am Anfang. Warum? Weil man dann nichts mehr zu verbergen hat und ein Auditor nichts mehr finden kann, was man vielleicht ohnehin schon weiß. Hat man in der Vorbereitung seinen Job gut gemacht, findet er gar nichts mehr. Idealerweise gibt es natürlich gar keine Probleme, aber das ist nicht immer der Fall.

Diese Vorgehensweise schafft etwas Vertrauen zwischen den Beteiligten und kann ungemein den Audit erleichtern. Auditoren müssen für ihren Job eine gewisse Grundskepsis mitbringen, das lässt sich nicht vermeiden. Wer sachlich diskutiert, ehrlich und offen ist, wird beim Audit insgesamt besser fahren, als wenn man sich verschließt und sinnlose Diskussionen führt, bei denen man ohnehin nur verlieren kann. Einfach den Auditor als Partner sehen ;-).

14 09, 2013

Das Image von PCI DSS

von |14. September 2013|PCI DSS|0 Kommentare|

PCI DSS besteht primär aus sinnvollen Best Practices, wenn man mit sensiblen Informationen arbeitet. Dennoch hat er keinen guten Ruf. Er kann Prozesse verkomplizieren, er fordert Investitionen und kostet in Augen vieler Verantwortlicher erst einmal Geld. Aber wo würde die Industrie ohne den Standard stehen? Ich vermute ohne PCI DSS wäre die Zahlung per Kreditkarte im Internet nicht so weit verbreitet. Keine Endkunde würde mehr der Kreditkarte als Online-Zahlungsmittel vertrauen, wenn er regelmäßig von seinem Issuer eine neue Karte erhalten würde, nachdem die vorherige kompromittiert wurde.

Der Standard scheint sein Ziel der Vertraulichkeit von Karteninhaberdaten gut zu erreichen: So wurden erst kürzlich bei Vodafone personenbezogene Daten gestohlen, auch Kontodaten. Aber keine Kreditkartendaten.

Der PCI DSS benötigt ein besseres Image.

25 08, 2013

PCI DSS 3.0 steht vor der Tür

von |25. August 2013|PCI DSS|0 Kommentare|

Seit diesem Monat sind Hinweise zu den Änderungen von PCI DSS 2.0 zu PCI DSS 3.0 online. Ankündigungen von gravierenden Änderungen konnte ich dort nicht lesen, auch wenn der Standard selbst noch nicht final veröffentlicht wurde. Es sollen ein paar neue Anforderungen aufgenommen werden. Zudem wird PCI DSS 3.0 zukünftig in ein paar Punkten mehr Erläuterungen und Klarstellungen enthalten, sowie Veränderungen der Bedrohungslage aufnehmen. Interessant finde ich die Ankündigung, dass die Regelungen zur Passwortkomplexität etwas flexibler werden sollen:

„Provided increased flexibility in password strength and complexity to allow for variations that are equivalent”

Der neue PCI DSS 3.0 soll im November veröffentlicht werden. Für Unternehmen wird eine Zertifizierung nach dem alten Standard noch bis Ende 2014 möglich sein, sodass ausreichend Zeit vorhanden ist, um eventuelle Änderungen an Prozessen und Infrastruktur vorzunehmen.