Unterstützung bei PCI-DSS Compliance Projekten
Der Payment Card Industry Data Security Standard (PCI-DSS bzw. PCI) beinhaltet diverse Anforderungen an Rechnernetze von Kreditkartendaten verarbeitenden Unternehmen. Wir unterstützen Sie bei Prüfungen nach
- Requirement 6.6 Penetrationstest/Prüfen öffentlicher Webanwendungen (application vulnerability security assessment of public-facing web applications)
- Requirement 11.3 Durchführen externer und interner Penetrationstests (external and internal penetration testing)
Darüber hinaus beraten wir Sie zur Umsetzung von Requirement 11.2.1 für vierteljährlich durchzuführende interne Schwachstellenprüfungen.
Die PCI empfehlen die Einhaltung der Secure Coding Principles des Open Web Application Security Project (OWASP) (seit Version 2.0 auch weitere wie CERT Secure Coding) bei der Erstellung von Webanwendungen. Darüber hinaus wird gefordert, selbst erstellten Code gezielt nach Schwachstellen zu untersuchen, Für Web-Anwendungen wird auf die OWASP Top 10 verwiesen. In dieser Top 10 sind die am häufigsten auftretenden Schwachstellen-Kategorien zu finden.
Eine Möglichkeit, die bei komplexen Anwendungen erheblich schneller durchzuführen ist als ein vollständiger Code-Review, ist der Test der Webanwendung aus Sicht eines externen Angreifers auf die in den OWASP Top 10 veröffentlichten Schwachstellen-Kategorien. Mittlerweile gibt es die OWASP Top 10 in 3 Versionen, einmal aus dem Jahr 2004 (Verweis in PCI-DSS Version 1.1), als auch aus dem Jahr 2007 und 2010. Ein Teil der Forderungen ist nicht mit Hilfe eines Angriffs prüfbar, sondern in Form von Interviews mit Entwicklern und Prüfung einzelner Elemente im Code.
Obwohl (noch) nicht gefordert, empfiehlt es sich aus unserer Sicht alle OWASP Top 10 zu prüfen, da der Prüfaufwand aufgrund des recht hohen Deckungsgrads zwischen den beiden Versionen nicht erheblich steigt und somit auch aktuellere Schwachstellen gefunden werden können.
Die folgende Tabelle fast die Anforderungen aus den Jahren 2004, 2007 und 2010 zusammen. In der letzten Spalte wird angegeben, ob es sich um eine rein (t)echnisch prüfbare Schwachstellen-Kategorie handelt, oder ob (i)nterviewbasierte Prüfungen erforderlich sind.
| Jahr, ID | Bezeichnung | Prüfart |
|---|---|---|
| 2010 A1 | Injection | t |
| 2010, A2 | Cross Site Scripting (XSS) | t |
| 2010, A3 | Broken Authentication and Session Management | t |
| 2010, A4 | Insecure Direct Object References | t |
| 2010, A5 | Cross Site Request Forgery (CSRF) | t |
| 2010, A6 | Security Misconfiguration | t/i |
| 2010, A7 | Insecure Cryptographic Storage | t/i |
| 2010, A8 | Failure to Restrict URL Access | t |
| 2010, A9 | Insufficient Transport Layer Protection | t/i |
| 2010, A10 | Unvalidated Redirects and Forwards | t |
| 2004, A5 | Buffer Overflow | t |
| 2004, A9 | Application Denial of Service | t/i |
| 2007, A6 | formation Leakage and Improper Error Handling | t/i |
Die Penetrationstests werden toolgestützt und manuell durchgeführt und durch Abdeckung der interviewbasierten Tests abgerundet.
Alternativ kann die Prüfung entlang des Quell-Codes Ihrer Anwendung erfolgen, der in Teilen oder Gänze dem Tester zur Verfügung gestellt wird. Mit Hilfe von Tools und jahrelanger Expertise wird der Quelltext entlang einer etablierten Methodik auf Schwachstellen untersucht.