• Über uns
    • Dominik Sauer
    • Patrick Sauer
  • Kategorien
    • binsec
    • Datenschutz
    • Informationssicherheit
    • IT-Forensik
    • IT-Sicherheit
    • Netzpolitik
    • PCI DSS
    • Pentest
    • Presse
    • Studium
    • Unkategorisiert
    • Vorlesung
      • HDA
      • THB
    • Vorträge
    • Zertifizierung
  • Lehrveranstaltungen
    • Hochschule Darmstadt (HDA)
      • Internet-Sicherheit
      • IT-Sicherheitsmanagement & Compliance
      • Penetration Testing
      • Security of Web Applications
    • Technische Hochschule Brandenburg (THB)
      • PCI DSS
    • Technische Hochschule Mittelhessen (THM)
      • WK_2620 Secure Coding
      • WK_2621 Penetration Testing
      • WK_2622 Digitale Forensik
  • Impressum / Datenschutzerklärung
InfoSec Blog | Patrick Sauer & Dominik Sauer

Blog - IT Security - Pentest - Fun

Compliance

Erfolgsfaktoren für den PCI DSS Audit und die Zertifizierung

22. August 2013 by Patrick Sauer Leave a Comment

Um Audits erfolgreich und möglichst schnell abzuwickeln, benötigt man

  • einen guten Auditor, der viel Erfahrung im Bereich Security besitzt und auch vor technischen Diskussionen nicht zurückschreckt.
  • eine interne zuständige Person, die PCI DSS kennt, versteht und ausreichend Erfahrung mit dem Standard hat. Idealerweise einen CISO mit sehr starkem technischen Hintergrund. Alternativ einfach das Know-How von außen einkaufen und dabei auf eine CISSP-Zertifizierung achten. Der Berater muss aber nicht nur PCI DSS verstehen, sondern auch Security mit Business kombinieren können.
  • eine Reduzierung des Scopes. In der Regel ist es sehr ungünstig, wenn alle Bereiche eines Unternehmens unter PCI DSS fallen. Das erhöht nicht nur den Dokumentationsaufwand, sondern verringert auch die allgemeine Produktivität.
  • Unterstützung vom Management. Ohne Unterstützung von oben geht es nicht. Eine PCI-Zertifizierung kostet nicht nur Geld, sondern wird im Unternehmen am Anfang garantiert unbequem sein. PCI DSS hat in der Praxis nicht den besten Ruf und es gibt zugegeben angenehmere Zertifizierungen. Insbesondere Softwareentwickler scheinen PCI DSS schnell als Feindbild zu sehen. Das muss nicht sein.
  • Sicherheit als kontinuierlichen Prozess. Vor dem Audit ist nach dem Audit. PCI DSS hört nicht nach dem Audit auf, und fängt nicht zum nächsten Audit wieder an. Beim ersten Audit muss man weniger nachweisen, dass man „pci lebt“. Beim zweiten sollte man besser nicht wieder von vorne anfangen. Hierzu werden Prozesse notwendig sein. Mitarbeiter müssen mitgenommen werden. Ohne eine Person, die hierfür explizit die Zuständigkeit besitzt, wird der nächst Audit meist so schwierig wie der erste.
  • eine gute Vorbereitung. Man sollte bereits vor dem eigentlichen Audit wissen, ob alles compliant ist und wenn nicht, wo die eigenen Schwachstellen liegen.
Posted in: PCI DSS Tagged: Audit, Compliance, QSA

Navigating PCI DSS

22. August 2013 by Patrick Sauer Leave a Comment

Wer PCI DSS nicht kennt, aber plötzlich davon betroffen ist, sollte sich das Dokument Navigating PCI DSS von der offiziellen Website des PCI Security Standards Council herunterladen. Es lohnt sich. Im eigentlichen PCI DSS Dokument werden nur Anforderungen und Testprozeduren definiert. In Navigating PCI DSS wird erklärt, was überhaupt mit den einzelnen Anforderungen erreicht werden soll. PCI DSS zu verstehen ist das A und O bei einem Audit: Das Dokument Navigating PCI DSS hilft dabei.

Posted in: PCI DSS Tagged: Audit, Compliance, Requirement

PCI DSS Requirement 8.5.9 bei Endkundenzugängen

19. August 2013 by Patrick Sauer Leave a Comment

Die PCI DSS Anforderung 8.5.9 besagt, dass Benutzerpasswörter mindestens alle 90 Tage gewechselt werden müssen. Unter Requirement 8 existiert jedoch eine Notiz im Standard, die den Umfang der Anwendbarkeit präzisiert:

„Note: These requirements are applicable for all accounts, including point of sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. However, Requirements 8.1, 8.2 and 8.5.8 through 8.5.15 are not intended to apply to user accounts within a point of sale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts).”

Hier wird u.a. die Anwendbarkeit der Anforderung 8.5.9 deutlich eingeschränkt. Exakt beschreibt der Hinweis im Standard dennoch nicht, wie mit Accounts von Endkunden verfahren werden soll. Hier hilft die zweite Testing Procedure zur Anforderung 8.5.9 etwas weiter:

„For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to change periodically and that non-consumer users are given guidance as to when, and under what circumstances, passwords must change.”

Hierdurch wird nun klar, dass sich die Prüfung der 90-Tage-Regelung primär an „non-consumer user passwords“ richtet. Kombiniert man die zuvor zitierte Notiz inhaltlich mit der zweiten Testprozedur der Anforderung 8.5.9, richtet sich der Zwang zur Änderung eines Passworts alle 90 Tage primär nicht an Benutzer-Accounts von Endkunden. Nachdem Endkunden keinen Zugang zu Kreditkatendaten besitzen (z.B. bei Amazon, Paypal), weder zu anderen noch zur eigenen, besteht kein Risiko für einen Diebstahl von Kreditkartendaten. Das PCI DSS Requirement 8.5.9 zum Wechsel des Passworts alle 90 Tage findet hier keine Anwendung.

Posted in: PCI DSS Tagged: Compliance, Passwörter, Requirement

PCI DSS: Wie die Änderung der Benutzerpasswörter alle 90 Tage indirekt regelmäßig umgangen wird.

8. August 2013 by Patrick Sauer Leave a Comment

Der Payment Card Industry Data Security Standard 2.0 schreibt die Änderung von Benutzerpasswörtern alle 90 Tage vor: “8.5.9 Change user passwords at least every 90 days.” Meistens sehe ich in der Praxis folgende Typen von Nutzern:

  1. Der Nutzer benutzt einen Password-Safe wie z.B. Keepass und er generiert regelmäßig neue Passwörter.
  2. Der Nutzer muss sich das Password tatsächlich merken und iteriert Zahlen durch.

Nutzer von Password-Safes haben aber noch das Problem, dass die Nutzung erst nach der Anmeldung an einen Arbeitsplatz möglich ist. Somit fallen die meisten beim Passwort für den Login am Arbeitsplatz in die Kategorie 2 zurück: Passwörteränderungen werden so realisiert, dass sich der Nutzer ein Schema merkt. Damit ergeben sich sinnlose Passwortänderungen wie z.B.

  • Passwort-01, Passwort-02, Passwort-03, …
  • Passwort!2012-04, Passwort!2013-01, Passwort!2013-02, …

Damit wird in der Praxis die erzwungene Änderung von Passwörtern alle 90 Tage umgangen. „Compliant“ im Sinne von PCI DSS sind diese Passwörter und die damit verbundenen Änderungen dennoch. Ich finde es wäre hilfreich, wenn man die regelmäßige Änderung von Passwörtern beibehält, allerdings die Fristen risikogewichtet und damit flexibler gestaltet. Wenn eine Sicherheitsmaßnahme zu aufwendig ist (hier das Merken neuer Passwörter), und sie umgangen werden kann, wird sie auch umgangen werden.

Posted in: PCI DSS Tagged: Compliance, Passwörter, Requirement

Sprachen

  • Deutsch
    • English

Search

Categories

  • binsec
  • binsec.tools
  • blackhole pentesting
  • Datenschutz
  • Fragen und Antworten (Q & A)
  • Informationssicherheit
  • ISO27001
  • IT-Forensik
  • IT-Sicherheit
  • Lehraufträge
  • Netzpolitik
  • PCI DSS
  • Pentest
  • Presse
  • Regulatorik
  • Reuning
  • Studium
  • Unkategorisiert
  • Vorlesung
    • HDA
    • THB
    • THM
  • Vorträge
  • Zertifizierung

Copyright © 2025 InfoSec Blog | Patrick Sauer & Dominik Sauer.

Omega WordPress Theme by ThemeHall

  • Deutsch
  • English (Englisch)