Payment Card Industry Data Security Standard (PCI DSS) - Version 1.1 Veröffentlichung: September 2006
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Payment Card Industry Data
Security Standard (PCI DSS)
Version 1.1
Veröffentlichung: September 2006Einrichtung und Unterhaltung eines sicheren Netzwerks
Anforderung 1: Installation und Verwaltung einer Firewallkonfiguration zum Schutz
von Karteninhaberdaten
Anforderung 2: Keine Verwendung der Standardwerte des Herstellers für
Systemkennwörter und andere Sicherheitsparameter
Schutz von Karteninhaberdaten
Anforderung 3: Schutz von gespeicherten Karteninhaberdaten
Anforderung 4: Verschlüsselung der Übertragung von Karteninhaberdaten über
offene, öffentliche Netzwerke
Verwalten eines Programms zur Bewältigung von Sicherheitsrisiken
Anforderung 5: Verwendung und regelmäßige Aktualisierung von
Antivirusprogrammen
Anforderung 6: Entwicklung und Verwaltung sicherer Systeme und Anwendungen
Implementieren strikter Zugriffssteuerungsmaßnahmen
Anforderung 7: Beschränkung des Zugriffs auf Karteninhaberdaten auf die
geschäftlich erforderlichen Daten
Anforderung 8: Zuweisung einer eindeutigen ID zu jeder Person mit Computerzugriff
Anforderung 9: Beschränkung des physischen Zugriffs auf Karteninhaberdaten
Regelmäßiges Überwachen und Testen von Netzwerken
Anforderung 10: Verfolgung und Überwachung sämtlicher Zugriffe auf
Netzwerkressourcen und Karteninhaberdaten
Anforderung 11: Regelmäßiger Test von Sicherheitssystemen und -prozessen
Verwalten einer Informationssicherheitsrichtlinie
Anforderung 12: Verwaltung einer Richtlinie zur Informationssicherheit
Payment Card Industry Data Security Standard (PCI DSS) 1Vorwort
In diesem Dokument werden die 12 Anforderungen des Payment Card Industry (PCI) Data Security
Standard (DSS) beschrieben. Diese PCI DSS-Anforderungen sind in 6 logisch miteinander in
Zusammenhang stehende Gruppen aufgeteilt, die als „Kontrollziele“ bezeichnet werden.
In der folgenden Tabelle werden häufig verwendete allgemeine Karteninhaberdaten und vertrauliche
Authentifizierungsdaten veranschaulicht. Außerdem wird angegeben, ob das Speichern der einzelnen
Datenelemente erlaubt oder verboten ist und ob sie geschützt werden müssen. Die Angaben in dieser
Tabelle schließen nicht alle Möglichkeiten ein, veranschaulichen jedoch die unterschiedlichen Arten von
Anforderungen, die für die einzelnen Datenelemente gelten.
PCI DSS Anforderungen gelten immer dann, wenn eine Primary Account Number (PAN) gespeichert,
verarbeitet oder übermittelt wird. Wird keine PAN gespeichert, verarbeitet oder übermittelt, findet der PCI
DSS keine Anwendung.
Datenelement Speicherung Schutz PCI DSS-
erlaubt erforderlich Anf. 3.4
Primary Account
Karteninhaberdaten JA JA JA
Number (PAN)
Name des
JA JA* NEIN
Karteninhabers*
Servicecode* JA JA* NEIN
Ablaufdatum* JA JA* NEIN
Vertrauliche Magnetstreifen NEIN - -
Authentifizierungsdaten**
CVC2/CVV2/CID NEIN - -
PIN/PIN-Block NEIN - -
* Diese Datenelemente müssen geschützt werden, wenn sie in Verbindung mit der PAN gespeichert werden. Der
Schutz muss die Anforderungen des PCI DSS in Bezug auf den allgemeinen Schutz der Karteninhaber-
Datenumgebung erfüllen. Werden im Rahmen geschäftlicher Tätigkeiten persönliche Verbraucherdaten erfasst,
können außerdem weitere gesetzliche Bestimmungen (zu Verbraucherdatenschutz, allgemeinem Datenschutz,
Identitätsdiebstahl, Datensicherheit usw.) den besonderen Schutz dieser Daten oder eine ordnungsgemäße
Offenlegung der Firmenpraktiken erfordern. Wenn keine PANs gespeichert, verarbeitet oder übermittelt werden,
findet der PCI DSS jedoch keine Anwendung.
** Vertrauliche Authentifizierungsdaten dürfen nach der Autorisierung nicht gespeichert werden (auch nicht, wenn sie
verschlüsselt sind).
Diese Sicherheitsanforderungen gelten für alle Systemkomponenten. Unter Systemkomponenten sind
beliebige Netzwerkkomponenten, Server oder Anwendungen zu verstehen, die Bestandteil der
Karteninhaberdaten-Umgebung oder mit ihr verbunden sind. Die Karteninhaberdaten-Umgebung ist der
Teil des Netzwerks, in dem die Karteninhaberdaten oder vertraulichen Authentifizierungsdaten enthalten
sind. Durch eine adäquate Netzwerksegmentierung, die Systeme zum Speichern, Verarbeiten oder
Übermitteln von Karteninhaberdaten vom übrigen Netzwerk trennt, lässt sich der Umfang der
Payment Card Industry Data Security Standard (PCI DSS) 2Karteninhaberdaten-Umgebung verkleinern. Zu Netzwerkkomponenten gehören u. a. Firewalls, Switches,
Router, drahtlose Zugriffspunkte, Netzwerkgeräte und sonstige Sicherheitsvorrichtungen. Zu den
Servertypen gehören u. a. Web-, Datenbank-, Authentifizierungs-, Mail- und Proxyserver sowie NTP
(Network Time Protocol)-Server und DNS (Domain Name Service)-Server. Anwendungen umfassen alle
käuflich erworbenen und kundenspezifischen Anwendungen, einschließlich interner und externer
(Internet)-Anwendungen.
Einrichtung und Unterhaltung eines sicheren Netzwerks
Anforderung 1: Installation und Verwaltung einer Firewallkonfiguration zum Schutz von
Karteninhaberdaten
Firewalls sind Computervorrichtungen zur Kontrolle des zulässigen eingehenden und ausgehenden
Datenverkehrs innerhalb eines Firmennetzwerks sowie des Verkehrs in sensibleren Bereichen eines
internen Firmennetzwerks. Eine Firewall überprüft den gesamten Netzwerkverkehr und blockiert
Datenübertragungen, die nicht den festgelegten Sicherheitskriterien entsprechen.
Alle Systeme müssen vor nicht autorisiertem Zugriff über das Internet geschützt werden – unabhängig
davon, ob dieser in Form von E-Commerce, als internetbasierter Mitarbeiterzugriff über Desktopbrowser
oder als E-Mail-Zugriff der Mitarbeiter erfolgt. Häufig bieten scheinbar unbedeutende eingehende und
ausgehende Internetpfade Möglichkeiten, in wichtige Systeme einzudringen. Firewalls sind ein wichtiger
Schutzmechanismus für jedes Computernetzwerk.
1.1 Richten Sie Firewallkonfigurationsstandards ein, die Folgendes umfassen:
1.1.1 Formelles Genehmigungs- und Testverfahren für alle externen Netzwerkverbindungen und
Änderungen an der Firewallkonfiguration
1.1.2 Aktuelles Netzwerkdiagramm mit allen Verbindungen zu Karteninhaberdaten, einschließlich
drahtloser Netzwerke
1.1.3 Anforderungen für eine Firewall an jedem Internetanschluss sowie zwischen entmilitarisierten
Zonen (Demilitarized Zone, DMZ) und der internen Netzwerkzone
1.1.4 Beschreibung von Gruppen, Rollen und Verantwortlichkeiten für die logische Verwaltung von
Netzwerkkomponenten
1.1.5 Dokumentierte Liste von Diensten und Anschlüssen, die für die Geschäftstätigkeit notwendig sind
1.1.6 Dokumentation und Begründung der Notwendigkeit weiterer verfügbarer Protokolle neben
Hypertext Transfer Protocol (HTTP), Secure Sockets Layer (SSL), Secure Shell (SSH) und
Virtual Private Network (VPN)
1.1.7 Dokumentation und Begründung der Notwendigkeit riskanter zulässiger Protokolle (z. B. File
Transfer Protocol (FTP)), einschließlich einer Begründung für die Verwendung des betreffenden
Protokolls und der implementierten Sicherheitsfunktionen
1.1.8 Vierteljährliche Überprüfung der Regelsätze für Firewalls und Router
1.1.9 Konfigurationsstandards für Router
1.2 Richten Sie eine Firewallkonfiguration ein, die sämtlichen Datenverkehr von nicht vertrauenswürdigen
Netzwerken und Hosts unterbindet und nur Protokolle zulässt, die für die Karteninhaberdaten-
Umgebung erforderlich sind.
1.3 Richten Sie eine Firewallkonfiguration ein, die Verbindungen zwischen öffentlich zugänglichen
Servern und allen Systemkomponenten beschränkt, in denen Karteninhaberdaten gespeichert
werden (einschließlich Verbindungen von drahtlosen Netzwerken). Diese Firewallkonfiguration sollte
Folgendes umfassen:
Payment Card Industry Data Security Standard (PCI DSS) 31.3.1 Beschränkung des eingehenden Internetverkehrs auf Internetprotokolladressen (IP-Adressen)
innerhalb der DMZ (Ingressfilter)
1.3.2 Unterbindung der Weitergabe von internen Adressen vom Internet an die DMZ
1.3.3 Implementierung einer statusbehafteten Inspektion, auch als „dynamische Paketfilterung“
bezeichnet (d. h. nur „hergestellte“ Verbindungen mit dem Netzwerk werden zugelassen)
1.3.4 Speicherort der Datenbank in einer internen, von der DMZ getrennten Netzwerkzone
1.3.5 Beschränkung des eingehenden und ausgehenden Datenverkehrs auf die für die
Karteninhaberdaten-Umgebung erforderlichen Daten
1.3.6 Schutz und Synchronisierung der Routerkonfigurationsdateien. Beispiel:
Ausführungskonfigurationsdateien (für die normale Routerfunktion) und
Startkonfigurationsdateien (für Computerneustarts) sollten dieselbe sichere Konfiguration
aufweisen.
1.3.7 Unterbindung sämtlichen anderen eingehenden und ausgehenden Datenverkehrs, der nicht
ausdrücklich gestattet wurde
1.3.8 Installation von Perimeter-Firewalls zwischen allen drahtlosen Netzwerken und der
Karteninhaberdaten-Umgebung und Konfiguration dieser Firewalls zur Unterbindung sämtlichen
Datenverkehrs von der drahtlosen Umgebung bzw. zur Kontrolle des Datenverkehrs (falls dieser
zu Geschäftszwecken erforderlich ist)
1.3.9 Installation persönlicher Firewallsoftware auf jedem mobilen oder in Mitarbeiterbesitz befindlichen
Computer mit direktem Internetanschluss (z. B. von Mitarbeitern verwendete Laptops), über den
auf das Netzwerk der Organisation zugegriffen wird
1.4 Unterbinden des direkten öffentlichen Zugriffs zwischen externen Netzwerken und
Systemkomponenten, die Karteninhaberdaten speichern (z. B. Datenbanken, Protokolle,
Ablaufverfolgungsdateien)
1.4.1 Implementieren einer DMZ, um sämtlichen Datenverkehr zu filtern und zu überwachen und
direkte Pfade für eingehenden und ausgehenden Internetverkehr zu vermeiden
1.4.2 Beschränken des ausgehenden Datenverkehrs von Zahlungskartenanwendungen auf IP-
Adressen innerhalb der DMZ
1.5 Implementieren von IP-Tarnung, um zu verhindern, dass interne Adressen übersetzt und im Internet
offen gelegt werden. Verwenden Sie Technologien, die den Adressraum RFC 1918 implementieren,
z. B. Port Address Translation (PAT) oder Network Address Translation (NAT).
Anforderung 2: Keine Verwendung der Standardwerte des Herstellers für
Systemkennwörter und andere Sicherheitsparameter
Hacker (außerhalb oder innerhalb eines Unternehmens) verwenden häufig vom Hersteller angegebene
Kennwörter und andere Standardeinstellungen des Herstellers, um Systeme anzugreifen. Diese
Kennwörter und Voreinstellungen sind in Hackerkreisen allgemein bekannt und lassen sich leicht
ermitteln, da sie öffentlich verfügbar sind.
2.1 Ändern Sie grundsätzlich die vom Hersteller vorgegebenen Standardeinstellungen, bevor Sie ein
System im Netzwerk installieren (z. B. Kennwörter und SNMP (Simple Network Management
Protocol)-Communityzeichenfolgen), und entfernen Sie nicht benötigte Konten.
2.2 Drahtlose Umgebungen: Ändern Sie die herstellerseitigen Voreinstellungen, einschließlich, aber
nicht beschränkt auf WEP (Wireless Equivalent Privacy)-Schlüssel, vorgegebene SSIDs (Service Set
Identifier), Kennwörter und SNMP-Communityzeichenfolgen. Deaktivieren Sie SSID-Broadcasts. Bei
WPA-Fähigkeit: Aktivieren Sie WiFi Protected Access-Technologie (WPA und WPA2) für
Verschlüsselung und Authentifizierung.
Payment Card Industry Data Security Standard (PCI DSS) 42.2 Arbeiten Sie Konfigurationsstandards für alle Systemkomponenten aus. Vergewissern Sie sich,
dass diese Standards alle bekannten Sicherheitsrisiken berücksichtigen und den anerkannten
Systemhärtungsstandards der IT-Branche (z. B. von SysAdmin Audit Network Security Network
(SANS), National Institute of Standards Technology (NIST) und Center for Internet Security (CIS))
entsprechen.
2.2.1 Implementieren Sie nur eine primäre Funktion pro Server (Webserver, Datenbankserver
und DNS sollten z. B. auf getrennten Servern implementiert werden).
2.2.2 Deaktivieren Sie alle unnötigen und unsicheren Dienste und Protokolle (Dienste und
Protokolle, die nicht direkt für die jeweilige Funktion der Geräte erforderlich sind).
2.2.3 Konfigurieren Sie Systemsicherheitsparameter, um Datenmissbrauch zu verhindern.
2.2.4 Entfernen Sie alle unnötigen Funktionen, wie Skripts, Treiber, Features, Subsysteme,
Dateisysteme und nicht benötigte Webserver.
2.3 Verschlüsseln Sie alle nicht über die Konsole erfolgenden Administratorzugriffe.
Verwenden Sie Technologien wie SSH, VPN oder SSL/TLS (Transport Layer Security)
für die webbasierte Verwaltung und sonstige nicht über die Konsole erfolgenden
Administratorzugriffe.
2.4 Hosting-Anbieter müssen die gehosteten Umgebungen und Daten der einzelnen Entitäten
schützen. Diese Anbieter müssen bestimmte Anforderungen erfüllen, die in Anhang A,
„Anwendbarkeit des PCI DSS für Hosting-Anbieter“, ausgeführt sind.
Schutz von Karteninhaberdaten
Anforderung 3: Schutz von gespeicherten Karteninhaberdaten
Verschlüsselung ist ein entscheidender Bestandteil des Schutzes von Karteninhaberdaten. Für einen
Eindringling, der andere Netzwerksicherheitskontrollen umgeht und sich Zugang zu verschlüsselten
Daten verschafft, sind diese Daten ohne die entsprechenden kryptografischen Schlüssel nicht lesbar und
somit nutzlos. Zur Eingrenzung potenzieller Risiken sollten auch andere effektive Methoden zum Schutz
gespeicherter Daten in Erwägung gezogen werden. Risikomindernde Methoden beinhalten
beispielsweise, Karteninhaberdaten nur zu speichern, wenn dies absolut notwendig ist, die Daten
abzuschneiden, sofern nicht die vollständige PAN benötigt wird, und PANs nicht in unverschlüsselten E-
Mails zu senden.
3.1 Speichern Sie Karteninhaberdaten so wenig wie möglich. Arbeiten Sie eine Richtlinie zum
Aufbewahren und Löschen von Daten aus. Begrenzen Sie die Menge und Aufbewahrungsdauer
gespeicherter Daten entsprechend der oben genannten Datenaufbewahrungsrichtlinie auf Werte,
die aus geschäftlichen und rechtlichen Gründen oder aufgrund behördlicher Vorschriften
eingehalten werden müssen.
3.2 Speichern Sie im Anschluss an die Autorisierung keine vertraulichen Authentifizierungsdaten
(auch nicht, wenn diese verschlüsselt sind).
Zu vertraulichen Authentifizierungsdaten gehören die unter Anforderung 3.2.1 bis 3.2.3
angeführten Daten:
3.2.1 Speichern Sie keine vollständigen Spureninhalte auf dem Magnetstreifen (auf der
Kartenrückseite, einem Chip o. Ä.). Diese Daten werden u. a. als „Datenspur“, „Spur 1“,
„Spur 2“ und „Magnetstreifendaten“ bezeichnet.
Bei normalen geschäftlichen Transaktionen müssen u. U. die folgenden Datenelemente
aus dem Magnetstreifen gespeichert werden: Name des Kontoinhabers, PAN,
Ablaufdatum und Servicecode. Zur Verringerung des Risikos sollten nur die geschäftlich
erforderlichen Datenelemente gespeichert werden. Speichern Sie NIEMALS den
Payment Card Industry Data Security Standard (PCI DSS) 5Prüfcode oder -wert der Karte oder Datenelemente des PIN-Prüfwerts. Hinweis: Weitere
Informationen finden Sie im Glossar.
3.2.2 Speichern Sie auf keinen Fall den Kartenprüfcode oder -wert (die drei- oder vierstellige
Nummer auf der Vorder- oder Rückseite der Zahlungskarte), der zur Bestätigung von
Transaktionen ohne Karte verwendet wird.
Hinweis: Weitere Informationen finden Sie im Glossar.
3.2.3 Speichern Sie auf keinen Fall die persönliche Identifikationsnummer (PIN) oder den
verschlüsselten PIN-Block.
3.3 Maskieren Sie die PAN, wenn diese angezeigt wird (es dürfen höchstens die ersten sechs und
letzten vier Stellen angezeigt werden).
Hinweis: Diese Anforderung gilt nicht für Mitarbeiter und sonstige Parteien, die aus bestimmten
Gründen die vollständige PAN einsehen müssen. Auch hat sie keinen Vorrang vor evtl. geltenden
strengeren Anforderungen in Bezug auf das Anzeigen von Karteninhaberdaten (z. B. für POS-
Quittungen).
3.4 Machen Sie zumindest die PAN unabhängig vom Speicherort unlesbar (einschließlich Daten auf
digitalen Wechsel- oder Sicherungsdatenträgern und in Protokollen oder aus drahtlosen
Netzwerken empfangenen oder gespeicherten Daten). Verwenden Sie dazu eine der folgenden
Methoden:
• Funktionen mit starkem One-Way-Hash (Hash-Indizes)
• Abschneiden
• Indextoken und PADs (die PADs müssen sicher gespeichert werden)
• Starke Kryptografie mit dazugehörigen Schlüsselverwaltungsprozessen und -
prozeduren
Die Kontoinformation, die MINDESTENS unlesbar gemacht werden muss, ist die PAN.
Wenn ein Unternehmen aus irgendwelchen Gründen nicht in der Lage ist, Karteninhaberdaten zu
verschlüsseln, siehe Anhang B: „Ersatzkontrollen für die Verschlüsselung von gespeicherten
Daten“.
3.4.1 Falls Datenträgerverschlüsselung verwendet wird (statt Datenbankverschlüsselung auf
Datei- oder Spaltenebene), muss der logische Zugriff unabhängig von systemeigenen
Zugriffssteuerungsmechanismen des Betriebssystems verwaltet werden (z. B. durch
Nichtverwendung von lokalen System- oder Active Directory-Konten).
Entschlüsselungsschlüssel dürfen nicht an Benutzerkonten gebunden sein.
3.5 Schützen Sie Verschlüsselungsschlüssel für Karteninhaberdaten vor Offenlegung und
Missbrauch.
3.5.1 Beschränken Sie den Zugriff auf Schlüssel auf so wenige Verwalter wie möglich.
3.5.2 Speichern Sie Schlüssel sicher an so wenigen Orten und in so wenigen Formaten wie
möglich.
3.6 Alle Schlüsselverwaltungsprozesse und -prozeduren für die Verschlüsselung von
Karteninhaberdaten müssen vollständig dokumentiert und implementiert werden:
3.6.1 Generierung starker Schlüssel
3.6.2 Sichere Schlüsselverteilung
3.6.3 Sichere Schlüsselspeicherung
3.6.4 Regelmäßige Schlüsseländerung
• Je nach Notwendigkeit und gemäß den Empfehlungen der zugehörigen Anwendung
(z. B. Neuverschlüsselung); vorzugsweise automatisch
• Mindestens einmal pro Jahr
Payment Card Industry Data Security Standard (PCI DSS) 63.6.5 Löschen alter Schlüssel
3.6.6 Anwendung des Vier- oder Sechsaugenprinzips (sodass zwei oder drei Personen erforderlich
sind, die nur ihren Teil des Schlüssels kennen, um den gesamten Schlüssel zu rekonstruieren)
3.6.7 Verhinderung eines unbefugten Ersetzens von Schlüsseln
3.6.8 Auswechseln von Schlüsseln, die als unsicher erkannt oder vermutet werden
3.6.9 Sperrung alter oder ungültiger Schlüssel
3.6.10 Schlüsselverwalter müssen ein Formular unterzeichnen, um zu bestätigen, dass sie ihre
Verantwortlichkeiten als Schlüsselverwalter kennen und akzeptieren.
Anforderung 4: Verschlüsselung der Übertragung von Karteninhaberdaten über offene,
öffentliche Netzwerke
Vertrauliche Informationen müssen während der Übertragung über Netzwerke verschlüsselt sein, da
Hacker Daten während der Übertragung mühelos abfangen, ändern und umleiten können.
4.1 Verwenden Sie starke Kryptographie und Sicherheitsprotokolle, z. B. Secure Sockets Layer
(SSL)/Transport Layer Security (TLS) und Internet Protocol Security (IPSEC), um vertrauliche
Karteninhaberdaten während der Übertragung über offene, öffentliche Netzwerke zu schützen.
Beispiele für offene, öffentliche Netzwerke, die unter den PCI DSS fallen, sind das Internet, WiFi
(IEEE 802.11x), Global System for Mobile Communications (GSM) und General Packet Radio
Service (GPRS).
4.1.1 Verschlüsseln Sie Übertragungen von Karteninhaberdaten über drahtlose
Netzwerke mithilfe von WiFi Protected Access-Technologie (WPA oder WPA2), IPSEC
VPN oder SSL/TLS. Verwenden Sie nie ausschließlich Wired Equivalent Privacy (WEP),
um die Vertraulichkeit eines WLAN und den Zugriff darauf zu gewährleisten. Bei
Verwendung von WEP gehen Sie wie folgt vor:
• Verwenden Sie einen Verschlüsselungsschlüssel von mindestens 104 Bit und einem
Initialisierungswert von 24 Bit.
• Verwenden Sie WEP NUR in Verbindung mit WiFi Protected Access-Technologie
(WPA oder WPA2), VPN oder SSL/TLS.
• Wechseln Sie gemeinsam genutzte WEP-Schlüssel vierteljährlich (oder automatisch,
sofern die Technologie dies zulässt) aus.
• Wechseln Sie gemeinsam genutzte WEP-Schlüssel immer aus, wenn Änderungen bei
Mitarbeitern mit Zugriff auf Schlüssel auftreten.
• Beschränken Sie den Zugriff anhand der MAC (Media Access Code)-Adresse.
4.2 Senden Sie niemals per E-Mail unverschlüsselte PANs.
Verwalten eines Programms zur Bewältigung von Sicherheitsrisiken
Anforderung 5: Verwendung und regelmäßige Aktualisierung von Antivirusprogrammen
Viele Sicherheitsrisiken und bösartige Viren gelangen über die E-Mail-Aktivitäten der Mitarbeiter in das
Netzwerk. Auf allen allgemein virenanfälligen Systemen muss zum Schutz vor bösartiger Software ein
Antivirusprogramm eingesetzt werden.
5.1 Stellen Sie auf allen allgemein virenanfälligen Systemen (besonders PCs und Server) ein
Antivirusprogramm bereit.
Payment Card Industry Data Security Standard (PCI DSS) 7Hinweis: UNIX-Betriebssysteme oder Mainframes gehören gewöhnlich nicht zu allgemein
virenanfälligen Systemen.
5.1.1 Stellen Sie sicher, dass die Antivirusprogramme in der Lage sind, sonstige Arten von
bösartiger Software, einschließlich Spyware und Adware, zu erkennen, zu entfernen und
abzuwehren.
5.2 Stellen Sie sicher, dass alle Antivirusmechanismen aktuell und aktiviert sind und
Überwachungsprotokolle erstellen können.
Anforderung 6: Entwicklung und Verwaltung sicherer Systeme und Anwendungen
Skrupellose Angreifer nutzen Schwachstellen aus, um sich privilegierten Zugang zu Systemen zu
verschaffen. Viele dieser Sicherheitsrisiken werden mithilfe von Sicherheitspatches der Hersteller
beseitigt. Daher müssen auf allen Systemen die aktuellen geeigneten Softwarepatches vorhanden sein,
um einen Schutz gegen die Ausnutzung von Schwachstellen durch Mitarbeiter, externe Hacker und Viren
zu gewährleisten. Hinweis: Geeignete Softwarepatches sind Patches, die hinreichend geprüft und
getestet wurden, um sicherzustellen, dass sie keine Konflikte mit vorhandenen Sicherheitskonfigurationen
verursachen. Bei unternehmensintern entwickelten Anwendungen lassen sich zahlreiche
Sicherheitsrisiken durch standardmäßige Systementwicklungsprozesse und sichere Codierverfahren
vermeiden.
6.1 Stellen Sie sicher, dass für alle Systemkomponenten und Programme die neuesten vom
Hersteller bereitgestellten Softwarepatches installiert sind. Installieren Sie relevante
Sicherheitspatches innerhalb eines Monats nach Veröffentlichung.
6.2 Richten Sie einen Prozess zur Identifizierung neu erkannter Sicherheitsrisiken ein (abonnieren
Sie z. B. Warndienste, die im Internet kostenlos angeboten werden). Aktualisieren Sie Standards
entsprechend, um neue Sicherheitslücken zu schließen.
6.3 Entwickeln Sie Softwareanwendungen auf der Grundlage von Best Practices der Branche, und
berücksichtigen Sie die Datensicherheit während des gesamten Lebenszyklus der
Softwareentwicklung.
6.3.1 Testen aller Sicherheitspatches sowie System- und Softwarekonfigurationsänderungen
vor der Bereitstellung
6.3.2 Trennen von Entwicklungs-, Test- und Produktionsumgebung
6.3.3 Trennung der Aufgaben in der Entwicklungs-, Test- und Produktionsumgebung
6.3.4 Keine Verwendung von Produktionsdaten (aktive PANs) für Tests oder Entwicklung
6.3.5 Entfernen von Testdaten und -konten von Produktionssystemen vor der Aktivierung
6.3.6 Entfernen von benutzerdefinierten Anwendungskonten, Benutzernamen und
Kennwörtern, bevor Anwendungen aktiviert oder für Kunden freigegeben werden.
6.3.7 Überprüfung von benutzerdefiniertem Code vor der Freigabe für die Produktion oder
Kunden, um potenzielle Sicherheitsrisiken des Codes zu ermitteln
6.4 Befolgen Sie Änderungskontrollverfahren für alle System- und
Softwarekonfigurationsänderungen. Die Verfahren müssen Folgendes umfassen:
6.4.1 Dokumentation von Auswirkungen
6.4.2 Genehmigung durch Vertreter der Geschäftsführung
6.4.3 Durchführen eines Funktionstests
6.4.4 Backoutverfahren
6.5 Entwickeln Sie alle Webanwendungen auf der Grundlage von sicheren Codierrichtlinien, z. B. den
Open Web Application Security Project-Richtlinien. Überprüfen Sie benutzerdefinierten
Payment Card Industry Data Security Standard (PCI DSS) 8Anwendungscode auf Sicherheitsrisiken. Verhindern Sie häufig auftretende
Codesicherheitsrisiken in Softwareentwicklungsprozessen, um Folgendes zu vermeiden:
6.5.1 Nicht überprüfte Eingaben
6.5.2 Unterbrochene Zugriffssteuerung (z. B. böswillige Verwendung von Benutzer-IDs)
6.5.3 Unterbrochene Authentifizierungs- und Sitzungsverwaltung (Verwendung von
Kontoanmeldeinformationen und Sitzungscookies)
6.5.4 XSS (Cross-Site-Scripting)-Angriffe
6.5.5 Pufferüberläufe
6.5.6 Injektionslücken (z. B. SQL (Structured Query Language)-Injektion)
6.5.7 Nicht ordnungsgemäße Fehlerbehandlung
6.5.8 Unsichere Speicherung
6.5.9 Denial of Service
6.5.10 Unsichere Konfigurationsverwaltung
6.6 Stellen Sie sicher, dass alle Webanwendungen durch eine der folgenden Methoden vor bekannten
Angriffen geschützt werden:
• Überprüfung sämtlichen benutzerdefinierten Anwendungscodes auf häufig auftretende
Sicherheitslücken durch eine auf Anwendungssicherheit spezialisierte Organisation
• Installation einer Firewall auf Anwendungsebene vor Webanwendungen
Hinweis: Diese Methode gilt bis zum 30. Juni 2008 lediglich als Best Practice, wird dann jedoch
obligatorisch.
Implementieren strikter Zugriffssteuerungsmaßnahmen
Anforderung 7: Beschränkung des Zugriffs auf Karteninhaberdaten auf die geschäftlich
erforderlichen Daten
Mit dieser Anforderung wird sichergestellt, dass nur autorisierte Mitarbeiter auf wichtige Daten zugreifen
können.
7.1 Beschränken Sie den Zugriff auf IT-Ressourcen und Karteninhaberdaten auf die Personen, für
deren Tätigkeit ein solcher Zugriff erforderlich ist.
7.2 Richten Sie einen Mechanismus für Systeme mit mehreren Benutzern ein, der den Zugriff auf das
für einen Benutzer erforderliche Mindestmaß beschränkt und jeden Zugriff ablehnt, der nicht
explizit zugelassen ist.
Payment Card Industry Data Security Standard (PCI DSS) 9Anforderung 8: Zuweisung einer eindeutigen ID zu jeder Person mit Computerzugriff
Durch Zuweisung einer eindeutigen ID zu jeder zugriffsberechtigten Person wird sichergestellt, dass
Aktionen, die wichtige Daten und Systeme betreffen, nur von bekannten und autorisierten Benutzern
durchgeführt werden können und sich bis zu ihnen zurückverfolgen lassen.
8.1 Versehen Sie alle Benutzer mit einem eindeutigen Benutzernamen, bevor Sie ihnen den Zugriff
auf Systemkomponenten oder Karteninhaberdaten gestatten.
8.2 Setzen Sie zur Authentifizierung aller Benutzer neben der Zuweisung einer eindeutigen ID
mindestens eine der folgenden Methoden ein:
• Kennwort
• Token (z. B. SecureID, Zertifikate oder öffentlicher Schlüssel)
• Biometrie
8.3 Implementieren Sie eine 2-Faktoren-Authentifizierung für den Remotezugriff auf das Netzwerk
durch Mitarbeiter, Administratoren und Dritte. Verwenden Sie Technologien, z. B. Remote
Authentication and Dial-In Service (RADIUS), Terminal Access Controller Access Control System
(TACACS) mit Token oder VPN (basierend auf SSL/TLS oder IPSEC) mit individuellen
Zertifikaten.
8.4 Verschlüsseln Sie alle Kennwörter während der Übertragung und Speicherung auf allen
Systemkomponenten.
8.5 Stellen Sie eine ordnungsgemäße Benutzerauthentifizierung und Kennwortverwaltung für
Benutzer, die keine Kunden sind, und Administratoren auf allen Systemkomponenten sicher.
8.5.1 Steuern Sie das Hinzufügen, Löschen und Ändern von Benutzer-IDs,
Anmeldeinformationen und anderen Identifizierungsobjekten.
8.5.2 Überprüfen Sie die Benutzeridentität, bevor Sie Kennwörter zurücksetzen.
8.5.3 Legen Sie Ausgangskennwörter auf einen eindeutigen Wert pro Benutzer fest, und
lassen Sie diese nach der ersten Verwendung ändern.
8.5.4 Sperren Sie sofort den Zugriff von Benutzern, die das Unternehmen verlassen haben.
8.5.5 Entfernen Sie inaktive Benutzerkonten mindestens alle 90 Tage.
8.5.6 Aktivieren Sie Konten, die von Herstellern für die Remotewartung verwendet werden, nur
für den benötigten Zeitraum.
8.5.7 Teilen Sie allen Benutzern mit Zugriff auf Karteninhaberdaten die Kennwortprozeduren
und -richtlinien mit.
8.5.8 Verwenden Sie keine Gruppen-, gemeinsam genutzten oder generischen Konten und
Kennwörter.
8.5.9 Ändern Sie Benutzerkennwörter mindestens alle 90 Tage.
8.5.10 Legen Sie eine erforderliche Kennwortmindestlänge von sieben Zeichen fest.
8.5.11 Verwenden Sie Kennwörter, die sowohl numerische als auch alphabetische Zeichen
enthalten.
8.5.12 Lassen Sie nicht zu, dass ein Benutzer ein Kennwort wählen darf, das mit einem seiner
letzten vier Kennwörter identisch ist.
8.5.13 Begrenzen Sie die Anzahl wiederholter Zugriffsversuche, indem Sie die Benutzer-ID nach
maximal sechs Versuchen sperren.
8.5.14 Legen Sie die Dauer der Sperre auf 30 Minuten oder bis zu dem Zeitpunkt fest, an dem
der Administrator die Benutzer-ID wieder aktiviert.
8.5.15 Wenn eine Sitzung länger als 15 Minuten im Leerlauf war, fordern Sie den Benutzer zur
erneuten Eingabe des Kennworts auf, um das Terminal zu reaktivieren.
Payment Card Industry Data Security Standard (PCI DSS) 108.5.16 Authentifizieren Sie sämtliche Zugriffe auf Datenbanken, die Karteninhaberdaten
enthalten. Dazu gehört der Zugriff durch Anwendungen, Administratoren und alle
anderen Benutzer.
Anforderung 9: Beschränkung des physischen Zugriffs auf Karteninhaberdaten
Jeder physische Zugriff auf Daten oder Systeme, die Karteninhaberdaten enthalten, bietet Personen die
Möglichkeit, sich Zugang zu Geräten oder Daten zu verschaffen und Systeme oder Ausdrucke zu
entfernen, und sollte entsprechend beschränkt werden.
9.1 Versehen Sie Gebäude und Räume mit Zugangskontrollen, um den physischen Zugang zu
Systemen, die der Speicherung, Verarbeitung oder Übertragung von Karteninhaberdaten dienen,
zu begrenzen und zu überwachen.
9.1.1 Überwachen Sie sensible Bereiche mit Kameras. Überprüfen Sie erfasste Daten, und korrelieren
Sie diese mit anderen Einträgen. Speichern Sie diese Daten mindestens drei Monate lang, sofern
keine anderen gesetzlichen Vorschriften bestehen.
9.1.2 Beschränken Sie den physischen Zugriff auf öffentlich zugängliche Netzwerkschnittstellen.
9.1.3 Beschränken Sie den physischen Zugang zu drahtlosen Zugriffspunkten, Gateways und
Handheldgeräten.
9.2 Entwickeln Sie Verfahren, mit denen das gesamte Personal Mitarbeiter und Besucher problemlos
voneinander unterscheiden kann, insbesondere in Bereichen, in denen ein Zugriff auf
Karteninhaberdaten möglich ist.
„Mitarbeiter“ bezieht sich auf Voll- und Teilzeitbeschäftigte, Aushilfskräfte und Berater, die ständig
am Geschäftsstandort tätig sind. „Besucher “ sind Lieferanten, Gäste von Mitarbeitern,
Servicekräfte oder beliebige andere Personen, die den Geschäftsstandort für einen kurzen
Zeitraum, meist nicht länger als einen Tag, betreten.
9.3 Stellen Sie sicher, dass alle Besucher wie folgt behandelt werden:
9.3.1 Vor dem Betreten von Bereichen, in denen Karteninhaberdaten verarbeitet oder verwaltet
werden, wird die Befugnis des Besuchers überprüft.
9.3.2 Jeder Besucher erhält ein physisches Kennzeichen (z. B. einen Besucherausweis oder
ein Zugangsgerät) mit einer begrenzten Gültigkeit, das den Besucher als nicht
betriebsangehörig identifiziert.
9.3.3 Jeder Besucher wird aufgefordert, das physische Kennzeichen vor Verlassen des
Gebäudes oder zum Ablaufdatum wieder abzugeben.
9.4 Legen Sie ein Besucherprotokoll als physischen Überwachungspfad der Besucheraktivität an.
Speichern Sie dieses Protokoll mindestens drei Monate lang, sofern keine anderen gesetzlichen
Vorschriften bestehen.
9.5 Lagern Sie Sicherungsdatenträger an einem sicheren standortfernen Ort, z. B. einem alternativen
bzw. Sicherungsstandort oder einem gewerblichen Lager.
9.6 Sichern Sie sämtliche gedruckten und elektronischen Medien (einschließlich Computern,
elektronischen Medien, Netzwerk- und Kommunikationshardware, Telekommunikationsleitungen,
Belegen und Berichten in Papierform sowie Faxen), die Karteninhaberdaten enthalten.
9.7 Halten Sie bei der internen und externen Verteilung aller Medien, die Karteninhaberdaten
enthalten, strikte Kontrollen ein, die u. a. Folgendes umfassen sollten:
9.7.1 Klassifizieren Sie die Medien so, dass sie als vertraulich erkennbar sind.
9.7.2 Versenden Sie die Medien über einen sicheren Kurierdienst oder eine andere genau
nachverfolgbare Übermittlungsmethode.
Payment Card Industry Data Security Standard (PCI DSS) 119.8 Stellen Sie sicher, dass alle Medien den gesicherten Bereich nur mit Genehmigung der
Geschäftsführung verlassen dürfen (insbesondere, wenn sie an Einzelpersonen verteilt werden).
9.9 Halten Sie in Bezug auf die Lagerung und Zugänglichkeit von Medien, die Karteninhaberdaten
enthalten, strikte Kontrollen ein.
9.9.1 Inventarisieren Sie sämtliche Medien ordnungsgemäß, und vergewissern Sie sich, dass
sie sicher gelagert werden.
9.10 Vernichten Sie Medien, die Karteninhaberdaten enthalten und zu geschäftlichen oder rechtlichen
Zwecken nicht mehr benötigt werden, wie folgt:
9.10.1 Ausdrucke müssen geschreddert, verbrannt oder eingestampft werden.
9.10.2 Elektronische Medien müssen bereinigt, entmagnetisiert, geschreddert oder auf sonstige
Weise zerstört werden, damit Karteninhaberdaten nicht rekonstruiert werden können.
Regelmäßiges Überwachen und Testen von Netzwerken
Anforderung 10: Verfolgung und Überwachung sämtlicher Zugriffe auf
Netzwerkressourcen und Karteninhaberdaten
Protokollierungsmechanismen und die Möglichkeit der Nachverfolgung von Benutzeraktivitäten sind
besonders wichtig. Das Vorhandensein von Protokollen in allen Umgebungen erlaubt eine gründliche
Nachverfolgung und Analyse, falls es zu Unregelmäßigkeiten kommt. Ohne Systemaktivitätsprotokolle ist
es äußerst schwierig, die Ursache einer Gefährdung zu ermitteln.
10.1 Richten Sie einen Prozess ein, mit dem sämtliche Zugriffe auf Systemkomponenten
(insbesondere Zugriffe, die mithilfe von Administratorberechtigungen wie root erfolgen) mit den
einzelnen Benutzern in Verbindung gebracht werden können.
10.2 Implementieren Sie für alle Systemkomponenten automatisierte Überwachungspfade, um
folgende Ereignisse zu rekonstruieren:
10.2.1 Sämtliche einzelne Benutzerzugriffe auf Karteninhaberdaten
10.2.2 Sämtliche Aktionen, die mit root- oder Administratorberechtigungen ausgeführt werden
10.2.3 Zugriff auf sämtliche Überwachungspfade
10.2.4 Ungültige Versuche logischen Zugriffs
10.2 5 Verwendung von Identifizierungs- und Authentifizierungsmechanismen
10.2.6 Initialisierung von Überwachungsprotokollen
10.2.7 Erstellung und Löschung von Objekten auf Systemebene
10.3 Zeichnen Sie für alle Systemkomponenten mindestens die folgenden Überwachungspfade pro
Ereignis auf:
10.3.1 Benutzeridentifizierung
10.3.2 Ereignistyp
10.3.3 Datum und Uhrzeit
10.3.4 Angabe von Erfolg oder Misserfolg
10.3.5 Ursprung des Ereignisses
10.3.6 Identität bzw. Name der betroffenen Daten, Systemkomponente oder Ressource
10.4 Synchronisieren Sie alle wichtigen Systemuhren und -zeiten.
10.5 Sichern Sie Überwachungspfade so, dass sie nicht geändert werden können.
Payment Card Industry Data Security Standard (PCI DSS) 1210.5.1 Beschränken Sie die Anzeige von Überwachungspfaden auf Personen, die sie aufgrund
ihrer Arbeitsaufgaben benötigen.
10.5.2 Schützen Sie Überwachungspfaddateien vor unbefugten Änderungen.
10.5.3 Sichern Sie Überwachungspfaddateien in kurzen Intervallen auf einem zentralen
Protokollserver oder -datenträger, der nur schwer geändert werden kann.
10.5.4 Kopieren Sie Protokolle für drahtlose Netzwerke auf einen Protokollserver im internen
LAN.
10.5.5 Verwenden Sie für Protokolle Software zur Überwachung der Dateiintegrität bzw. zur
Änderungserkennung, um sicherzustellen, dass vorhandene Protokolldaten nicht
geändert werden können, ohne dass eine Warnung ausgegeben wird (beim Hinzufügen
neuer Daten sollte jedoch keine Warnung ausgelöst werden).
10.6 Überprüfen Sie täglich die Protokolle aller Systemkomponenten. Protokollüberprüfungen müssen
die Server umfassen, die Sicherheitsfunktionen ausüben, beispielsweise IDS (Intrusion Detection
System)-Server und AAA (Authentication, Authorization and Accounting)-Server (z. B. RADIUS).
Hinweis: Zur Erfüllung von Anforderung 10.6 dürfen Abruf-, Analyse- und Warntools für Protokolle
verwendet werden.
10.7 Der Überwachungspfadverlauf muss mindestens ein Jahr lang aufbewahrt werden und
mindestens drei Monate online verfügbar sein.
Payment Card Industry Data Security Standard (PCI DSS) 13Anforderung 11: Regelmäßiger Test von Sicherheitssystemen und -prozessen
Ständig werden von Hackern und Testern Sicherheitsrisiken entdeckt, die durch neue Software
verursacht werden. Systeme, Prozesse und benutzerdefinierte Programme müssen häufig getestet
werden, um dafür zu sorgen, dass die Sicherheit nachhaltig und auch nach Softwareänderungen
gewährleistet ist.
11.1 Testen Sie Sicherheitskontrollen, Beschränkungen, Netzwerkverbindungen und Einschränkungen
einmal jährlich, um sicherzustellen, dass diese nicht autorisierte Zugriffsversuche angemessen
erkennen und unterbinden können. Setzen Sie mindestens vierteljährlich ein
Analyseprogramm für drahtlose Netzwerke ein, um alle verwendeten drahtlosen Geräte zu
ermitteln.
11.2 Führen Sie mindestens vierteljährlich und nach wesentlichen Änderungen am Netzwerk (z. B.
Installation neuer Systemkomponenten, Änderungen der Netzwerktopologie, Änderungen von
Firewallregeln oder Produktupdates) Schwachstellenscans für das interne und externe Netzwerk
durch.
Hinweis: Der vierteljährliche externe Schwachstellenscan muss von einem von der
Zahlungskartenbranche zertifizierten Anbieter durchgeführt werden. Überprüfungen, die nach
Netzwerkänderungen erfolgen, können von Mitarbeitern des Unternehmens durchgeführt werden.
11.3 Führen Sie mindestens einmal jährlich sowie nach größeren Infrastruktur- bzw.
Anwendungsaktualisierungen oder -änderungen (z. B. Betriebssystemaktualisierung,
Hinzufügung eines Subnetzwerks oder Webservers zur Umgebung) Penetrationstests aus. Diese
Penetrationstests müssen Folgendes umfassen:
11.3.1 Penetrationstests auf der Netzwerkebene
11.3.2 Penetrationstests auf der Anwendungsebene
11.4 Verwenden Sie Intrusion Detection Systems (IDS) zur Erkennung von Angriffen auf das
Netzwerk, hostbasierte IDS und/oder Intrusion Prevention Systems (IPS) zur
Angriffsverhinderung, um sämtlichen Netzwerkdatenverkehr zu überwachen und Mitarbeiter bei
vermuteten Gefährdungen zu warnen. Sorgen Sie dafür, dass alle IDS- und IPS-Programme auf
dem neuesten Stand sind.
11.5 Stellen Sie Software zur Überwachung der Dateiintegrität bereit, um Mitarbeiter bei nicht befugten
Änderungen kritischer System- oder Inhaltsdateien zu warnen, und konfigurieren Sie die Software
so, dass kritische Dateien mindestens einmal pro Woche verglichen werden.
Kritische Dateien sind nicht unbedingt Dateien mit Karteninhaberdaten. Im Rahmen der
Überwachung der Dateiintegrität sind kritische Dateien meist Dateien, die nicht regelmäßig
geändert werden, deren Änderung jedoch ein Hinweis auf eine Systemgefährdung bzw. ein
entsprechendes Risiko sein kann. Produkte zur Überwachung der Dateiintegrität sind i. d. R. mit
kritischen Dateien für das entsprechende Betriebssystem vorkonfiguriert. Andere kritische
Dateien, z. B. für benutzerdefinierte Anwendungen, müssen überprüft und von der Entität (d. h.
vom Händler oder Dienstanbieter) definiert werden.
Payment Card Industry Data Security Standard (PCI DSS) 14Verwalten einer Informationssicherheitsrichtlinie
Anforderung 12: Verwaltung einer Informationssicherheitsrichtlinie für Mitarbeiter und
beauftragte Unternehmen
Eine strenge Sicherheitsrichtlinie gibt die Grundeinstellung zur Sicherheit für das gesamte Unternehmen
vor und vermittelt den Mitarbeitern, was von ihnen erwartet wird. Alle Mitarbeiter müssen sich der
Vertraulichkeit von Daten und ihrer Verantwortung für deren Schutz bewusst sein.
12.1 Erstellen, veröffentlichen, verwalten und verbreiten Sie eine Sicherheitsrichtlinie mit folgendem
Inhalt:
12.1.1 Erfüllung aller Anforderungen in dieser Spezifikation
12.1.2 Jährlicher Prozess zur Ermittlung von Bedrohungen und Sicherheitsrisiken mit
anschließender formeller Risikobewertung
12.1.3 Mindestens einmal pro Jahr stattfindende Überprüfung und Aktualisierungen, wenn
Umgebungsänderungen auftreten
12.2 Entwickeln Sie tägliche betriebliche Sicherheitsprozeduren, die den Anforderungen in dieser
Spezifikation entsprechen (z. B. Prozeduren für die Verwaltung von Benutzerkonten und die
Überprüfung von Protokollen).
12.3 Entwickeln Sie Nutzungsrichtlinien für wichtige von Mitarbeitern genutzte Technologien (z. B.
Modems und drahtlose Geräte), um eine ordnungsgemäße Nutzung dieser Technologien für alle
Mitarbeiter und beauftragten Unternehmen sicherzustellen. Vergewissern Sie sich, dass diese
Nutzungsrichtlinien folgende Voraussetzungen umfassen:
12.3.1 Ausdrückliche Genehmigung der Geschäftsführung
12.3.2 Authentifizierung für die Nutzung der Technologie
12.3.3 Liste aller entsprechenden Geräte und Mitarbeiter mit Zugriff
12.3.4 Kennzeichnung der Geräte mit Besitzer, Kontaktdaten und Zweck
12.3.5 Akzeptable Verwendungszwecke der Technologie
12.3.6 Akzeptable Netzwerkverzeichnisse für die Technologien
12.3.7 Liste der vom Unternehmen genehmigten Produkte
12.3.8 Automatische Trennung von Modemsitzungen nach einem bestimmten Zeitraum der
Inaktivität
12.3.9 Aktivierung von Modems für Hersteller, wenn sie von Herstellern benötigt werden, mit
anschließender sofortiger Deaktivierung
12.3.10 Beim Remotezugriff auf Karteninhaberdaten per Modem: Verbot der Speicherung von
Karteninhaberdaten auf lokalen Festplatten, Disketten oder anderen
Wechseldatenträgern. Verbot der Funktionen zum Ausschneiden und Einfügen
sowie der Druckfunktionen während des Remotezugriffs.
12.4 Vergewissern Sie sich, dass die Verantwortung aller Mitarbeiter und beauftragten Unternehmen
für die Informationssicherheit in den Sicherheitsrichtlinien und -prozeduren klar definiert ist.
12.5 Betrauen Sie eine einzelne Person oder ein Team mit den folgenden Verantwortlichkeiten für
Informationssicherheit:
12.5.1 Einrichtung, Dokumentation und Verteilung von Sicherheitsrichtlinien und -prozeduren
12.5.2 Überwachung und Analyse von Sicherheitswarnungen und -informationen und
Weiterleitung an entsprechendes Personal
Payment Card Industry Data Security Standard (PCI DSS) 1512.5.3 Einrichtung, Dokumentation und Verteilung von Reaktions- und Eskalationsprozeduren
bei sicherheitsrelevanten Zwischenfällen, um allen Situationen rechtzeitig und effektiv
begegnen zu können
12.5.4 Verwaltung von Benutzerkonten, einschließlich Hinzufügungen, Löschungen und
Änderungen
12.5.5 Überwachung und Steuerung sämtlicher Datenzugriffe
12.6 Implementieren Sie ein formelles Sicherheitsschulungsprogramm, um allen Mitarbeitern die
Bedeutung der Sicherheit von Karteninhaberdaten bewusst zu machen:
12.6.1 Schulung von Mitarbeitern bei Einstellung und mindestens einmal pro Jahr (z. B. durch
Rundschreiben, Poster, Memos, Besprechungen und Aktionen)
12.6.2 Schriftliche Bestätigung der Mitarbeiter, dass sie die Sicherheitsrichtlinien und -
prozeduren des Unternehmens gelesen und verstanden haben
12.7 Überprüfen Sie potenzielle Mitarbeiter, um das Risiko von Angriffen aus internen Quellen zu
minimieren.
Für Mitarbeiter, die bei der Abwicklung von Transaktionen jeweils nur auf eine Kartennummer
Zugriff haben (z. B. Kassiererinnen), ist diese Anforderung nur eine Empfehlung.
12.8 Wenn Karteninhaberdaten mit Dienstanbietern ausgetauscht werden, ist folgende vertragliche
Regelung erforderlich:
12.8.1 Dienstanbieter müssen die Anforderungen des PCI DSS erfüllen.
12.8.2 Vereinbarung, die eine Bestätigung über die Verantwortung des Dienstanbieters für die Sicherheit
der in seinem Besitz befindlichen Karteninhaberdaten umfasst
12.9 Implementieren Sie einen Incident-Response-Plan. Bei Sicherheitsverletzungen müssen Sie
sofort reagieren können.
12.9.1 Arbeiten Sie einen Incident-Response-Plan für den Fall einer Gefährdung der
Systemsicherheit aus. Stellen Sie sicher, dass der Plan zumindest spezifische Incident-
Response-Prozeduren, Prozeduren zur Wiederherstellung und Kontinuität des
Geschäftsbetriebs, Datensicherungsprozesse, Rollen und Verantwortlichkeiten sowie
Kommunikations- und Kontaktstrategien vorsieht (sodass z. B. Händlerbanken und
Kreditkartengesellschaften informiert werden).
12.9.2 Testen Sie den Plan mindestens einmal pro Jahr.
12.9.3 Sorgen Sie dafür, dass rund um die Uhr Mitarbeiter zur Verfügung stehen, um auf
Warnungen zu reagieren.
12.9.4 Lassen Sie die Mitarbeiter, die für die Reaktion auf Sicherheitsverletzungen zuständig
sind, entsprechend ausbilden.
12.9.5 Schließen Sie Warnungen aus IDS, IPS und Systemen zur Überwachung der
Dateiintegrität ein.
12.9.6 Arbeiten Sie einen Prozess aus, um den Incident-Response-Plan unter Berücksichtigung
von gewonnenen Erkenntnissen und Entwicklungen in der Branche zu ändern und
weiterzuentwickeln.
12.10 Alle Prozessoren und Dienstanbieter müssen Richtlinien und Prozeduren zur Verwaltung
verbundener Entitäten pflegen und umsetzen, die Folgendes umfassen:
12.10.1. Verwaltung einer Liste von verbundenen Entitäten
12.10.2. Sicherstellung einer Sorgfaltsprüfung vor Herstellung einer Verbindung mit einer Entität
12.10.3. Sicherstellung der Konformität der Entität mit dem PCI DSS
12.10.4. Verbindung und Trennung von Entitäten nach einem festgelegten Verfahren
Payment Card Industry Data Security Standard (PCI DSS) 16Anhang A: Anwendbarkeit des PCI DSS für Hosting-Anbieter
Anforderung A.1: Schutz der Karteninhaberdaten-Umgebung durch Hosting-Anbieter
Gemäß Anforderung 12.8 müssen alle Dienstanbieter mit Zugriff auf Karteninhaberdaten (einschließlich
Hosting-Anbietern) den PCI DSS erfüllen. Außerdem sind Hosting-Anbieter gemäß Anforderung 2.4 verpflichtet,
die gehosteten Umgebungen und Daten jeder Entität zu schützen. Daher müssen Hosting-Anbieter
insbesondere Folgendes beachten:
A.1 Schützen Sie die gehosteten Umgebungen und Daten jeder Entität (d. h. Händler, Dienstanbieter oder
sonstige Entität) gemäß A.1.1 bis A.1.4:
A.1.1 Stellen Sie sicher, dass jede Entität nur Zugriff auf die eigene Karteninhaberdaten-Umgebung
hat.
A.1.2 Beschränken Sie Zugriff und Berechtigungen jeder Entität auf die eigene Karteninhaberdaten-
Umgebung.
A.1.3 Stellen Sie sicher, dass Protokollierung und Überwachungspfade aktiviert sind, für die
Karteninhaberdaten-Umgebung jeder Entität eindeutig sind und die PCI DSS-Anforderung 10
erfüllen.
A.1.4 Aktivieren Sie Prozesse zur zeitnahen Einleitung einer kriminaltechnischen Untersuchung im
Fall einer Sicherheitsgefährdung eines gehosteten Händlers oder Dienstanbieters
Ein Hosting-Anbieter muss diese Anforderungen sowie alle anderen relevanten Paragraphen des PCI DSS
erfüllen. Hinweis: Auch wenn ein Hosting-Anbieter diese Anforderungen erfüllt, ist die Konformität der Entität,
die den Hosting-Anbieter in Anspruch nimmt, nicht unbedingt gewährleistet. Jede Entität muss den PCI DSS
erfüllen und ihre Konformität entsprechend nachweisen.
Payment Card Industry Data Security Standard (PCI DSS) v 1.1 17Anhang B: Ersatzkontrollen
Ersatzkontrollen – Allgemein
Für die meisten Anforderungen des PCI DSS können Ersatzkontrollen in Erwägung gezogen werden, wenn eine
Entität eine technische Spezifikation einer Anforderung nicht erfüllen kann, das damit verbundene Risiko jedoch
ausreichend eingedämmt hat. Eine vollständige Definition von Ersatzkontrollen finden Sie im PCI DSS-Glossar.
Die Effektivität einer Ersatzkontrolle hängt von den Besonderheiten der Umgebung, in der die Kontrolle
implementiert wird, den umgebenden Sicherheitskontrollen und der Konfiguration der Kontrolle ab.
Unternehmen sollten sich bewusst sein, dass eine bestimmte Ersatzkontrolle nicht in allen Umgebungen effektiv
ist. Jede Ersatzkontrolle muss nach der Implementierung eingehend überprüft werden, um ihre Effektivität
sicherzustellen.
Die folgende Richtlinie umfasst Ersatzkontrollen für den Fall, dass Unternehmen nicht in der Lage sind,
Karteninhaberdaten gemäß Anforderung 3.4 unleserlich zu machen.
Ersatzkontrollen für Anforderung 3.4
Für Unternehmen, die aufgrund technischer oder geschäftlicher Einschränkungen nicht in der Lage sind,
Karteninhaberdaten unleserlich zu machen (z. B. durch Verschlüsselung), können Ersatzkontrollen in Erwägung
gezogen werden. Nur Unternehmen, die eine Risikoanalyse durchgeführt haben und legitime technologische
oder dokumentierte geschäftliche Einschränkungen anführen können, dürfen Ersatzkontrollen in Erwägung
ziehen, um die Konformität zu erzielen.
Unternehmen, die Ersatzkontrollen für das Unleserlichmachen von Karteninhaberdaten in Erwägung ziehen,
müssen sich des Risikos bewusst sein, dem die Daten ausgesetzt sind, wenn sie weiterhin leserlich bleiben. Im
Allgemeinen müssen die Kontrollen einen zusätzlichen Schutz gewährleisten, um weitere Risiken zu mindern,
die die Lesbarkeit von Karteninhaberdaten mit sich bringt. Die in Erwägung gezogenen Kontrollen sind
zusätzlich zu den Kontrollen einzusetzen, die gemäß PCI DSS gefordert werden, und müssen der Definition für
„Ersatzkontrollen“ im PCI DSS-Glossar entsprechen. Ersatzkontrollen können entweder ein Gerät oder eine
Kombination von Geräten, Anwendungen und Kontrollen umfassen, die alle folgenden Bedingungen erfüllen:
1. Bereitstellung zusätzlicher Segmentierung/Abstraktion (z. B. auf der Netzwerkebene)
2. Bereitstellung der Möglichkeit zur Beschränkung des Zugriffs auf Karteninhaberdaten oder
Datenbanken nach den folgenden Kriterien:
• IP-Adresse/MAC-Adresse
• Anwendung/Dienst
• Benutzerkonten/-gruppen
• Datentyp (Paketfilterung)
3. Beschränkung des logischen Zugriffs auf die Datenbank
• Steuerung des logischen Zugriffs auf die Datenbank unabhängig von Active Directory oder LDAP
(Lightweight Directory Access Protocol)
4. Verhinderung von bzw. Schutz vor gängigen Angriffen auf Anwendungen oder Datenbanken (z. B. SQL-
Injektion).
Payment Card Industry Data Security Standard (PCI DSS) v 1.1 18Sie können auch lesen
