Payment Card Industry Data Security Standard (PCI DSS) filePayment Card Industry Data Security...

Payment Card Industry Data Security Standard (PCI DSS)

Sicherheitsprüfungsverfahren

Version 1.1 Veröffentlichung: September 2006

Copyright 2006 PCI Security Standards Council LLC. Sicherheitsprüfungsverfahren, Version 1.1 2

Inhaltsverzeichnis Sicherheitsprüfungsverfahren ........................................................................................................................................................................................................ 1 Version 1.1 ..................................................................................................................................................................................................................................... 1

Inhaltsverzeichnis ................................................................................................................................................................................................................... 2 Einführung ...................................................................................................................................................................................................................................... 3 Informationen zur Anwendbarkeit des PCI DSS ............................................................................................................................................................................ 4 Umfang der Bewertung der Einhaltung von PCI-DSS-Anforderungen .......................................................................................................................................... 5

Drahtlostechnologie ................................................................................................................................................................................................................ 6 Outsourcing ............................................................................................................................................................................................................................ 6 Stichproben ............................................................................................................................................................................................................................. 6 Ersatzkontrollen ...................................................................................................................................................................................................................... 7

Anweisungen zu Erstellung und Inhalt des Erfüllungsberichts ...................................................................................................................................................... 7 Erneute Überprüfung von offenen Posten ..................................................................................................................................................................................... 8 Einrichtung und Unterhaltung eines sicheren Netzwerks .............................................................................................................................................................. 9

Anforderung 1: Installation und Verwaltung einer Firewallkonfiguration zum Schutz von Karteninhaberdaten ..................................................................... 9 Anforderung 2: Keine Verwendung der Standardwerte des Herstellers für Systemkennwörter und andere Sicherheitsparameter ................................... 13

Schutz von Karteninhaberdaten .................................................................................................................................................................................................. 18 Anforderung 3: Schutz von gespeicherten Karteninhaberdaten .......................................................................................................................................... 18 Anforderung 4: Verschlüsselung der Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke ............................................................... 26

Verwalten eines Programms zur Bewältigung von Sicherheitsrisiken ......................................................................................................................................... 29 Anforderung 5: Verwendung und regelmäßige Aktualisierung von Antivirusprogrammen .................................................................................................. 29 Anforderung 6: Entwicklung und Verwaltung sicherer Systeme und Anwendungen ........................................................................................................... 30

Implementieren strikter Zugriffssteuerungsmaßnahmen ............................................................................................................................................................. 36 Anforderung 7: Beschränkung des Zugriffs auf Karteninhaberdaten auf die geschäftlich erforderlichen Daten ................................................................. 36 Anforderung 8: Zuweisung einer eindeutigen ID zu jeder Person mit Computerzugriff ....................................................................................................... 37 Anforderung 9: Beschränkung des physischen Zugriffs auf Karteninhaberdaten ................................................................................................................ 43

Regelmäßiges Überwachen und Testen von Netzwerken .......................................................................................................................................................... 48 Anforderung 11: Regelmäßiger Test von Sicherheitssystemen und -prozessen ................................................................................................................. 52

Verwalten einer Informationssicherheitsrichtlinie......................................................................................................................................................................... 55 Anforderung 12: Verwaltung einer Informationssicherheitsrichtlinie für Mitarbeiter und beauftragte Unternehmen ............................................................ 55

Anhang A: Anwendbarkeit des PCI DSS für Hosting-Anbieter (mit Testverfahren) .................................................................................................................... 63 Anforderung A.1: Schutz der Karteninhaberdaten-Umgebung durch Hosting-Anbieter ...................................................................................................... 63

Anhang B: Ersatzkontrollen ......................................................................................................................................................................................................... 66 Ersatzkontrollen – Allgemein ................................................................................................................................................................................................ 66 Ersatzkontrollen für Anforderung 3.4 .................................................................................................................................................................................... 66

Anhang C: Arbeitsblatt für Ersatzkontrollen mit Beispiel ............................................................................................................................................................. 67


Einführung Die PCI-Sicherheitsprüfungsverfahren dienen als Richtlinie für Gutachter, die bei Händlern und Dienstanbietern Vor-Ort-Prüfungen durchführen, um die Einhaltung der Anforderungen des Payment Card Industry (PCI) Data Security Standard (DSS) sicherzustellen. Die hier beschriebenen Anforderungen und Sicherheitsprüfungen beruhen auf dem PCI DSS.

Dieses Dokument enthält folgende Abschnitte:

• Einführung • Informationen zur Anwendbarkeit des PCI DSS • Umfang der Bewertung der Einhaltung von PCI-DSS-Anforderungen • Anweisungen zur Erstellung und Inhalt des Erfüllungsberichts • Erneute Überprüfung von offenen Posten • Sicherheitsprüfungsverfahren ANHÄNGE • Anhang A: Anwendbarkeit des PCI DSS für Hosting-Anbieter (mit Testverfahren) • Anhang B: Ersatzkontrollen

• Anhang C: Arbeitsblatt für Ersatzkontrollen mit Beispiel


Informationen zur Anwendbarkeit des PCI DSS 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.

* 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).

Datenelement Speicherung erlaubt

Schutzerforderlich

PCI DSSANF. 3.4

KarteninhaberdatenPrimary Account

Number (PAN) JA JA JA

Name des Karteninhabers*

JA JA* NEIN

Servicecode* JA JA* NEIN

Ablaufdatum* JA JA* NEIN

Vertrauliche Authentifizierungsdaten**

Magnetstreifen NEIN - -

CVC2/CVV2/CID NEIN - -

PIN/PIN-Block NEIN - -


Umfang der Bewertung der Einhaltung von PCI-DSS-Anforderungen Die Sicherheitsanforderungen des PCI DSS 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. Zu Netzwerkkomponenten gehören u. a. Firewalls, Switches, Router, drahtlose Zugriffspunkte, Netzwerkgeräte und sonstige Sicherheitsvorrichtungen. Servertypen können u. a. Web-, Datenbank-, Authentifizierungs-, Mail-, Proxyserver sowie NTP (Network Time Protocol)-Server und DNS (Domain Name Service)-Server einschließen. Anwendungen umfassen alle käuflich erworbenen und kundenspezifischen Anwendungen, einschließlich interner und externer (Internet)-Anwendungen.

Durch eine adäquate Netzwerksegmentierung, die Systeme zum Speichern, Verarbeiten oder Übermitteln von Karteninhaberdaten vom übrigen Netzwerk trennt, lässt sich der Umfang der Karteninhaberdaten-Umgebung verkleinern. Der Gutachter muss überprüfen, ob die Segmentierung ausreicht, um den Prüfungsumfang zu reduzieren.

Ein Dienstanbieter oder Händler kann zur Verwaltung von Komponenten (z. B. Router, Firewalls, Datenbanken, physische Sicherheit und/oder Server) einen Drittanbieter einsetzen. In diesem Fall wird die Sicherheit der Karteninhaberdaten-Umgebung möglicherweise beeinträchtigt. Die relevanten Dienste des Drittanbieters müssen entweder 1) bei jedem PCI-Audit der Kunden des Drittanbieters oder 2) beim PCI-Audit des Drittanbieters genau überprüft werden.

Sofern nicht anders angegeben, muss bei Dienstanbietern, die zu einer jährlichen Vor-Ort-Überprüfung verpflichtet sind, für alle Systemkomponenten zum Speichern, Verarbeiten oder Übermitteln von Karteninhaberdaten eine Erfüllungsüberprüfung durchgeführt werden.

Bei Händlern, die zu einer jährlichen Vor-Ort-Überprüfung verpflichtet sind, konzentriert sich die Erfüllungsüberprüfung auf alle autorisierungs- und zahlungsrelevanten Systeme bzw. Systemkomponenten zum Speichern, Verarbeiten oder Übermitteln von Karteninhaberdaten, einschließlich der folgenden: • Alle externen Verbindungen zum Händlernetzwerk (z. B. Remotezugriff für Mitarbeiter, Zugriff für

Zahlungskartenunternehmen und Drittanbieter zu Verarbeitungs- bzw. Wartungszwecken) • Alle Verbindungen zur bzw. von der Autorisierungs- und Zahlungsumgebung (z. B. Verbindungen für Mitarbeiterzugriff

oder Vorrichtungen, wie Firewalls and Router) • Alle Datenspeicher außerhalb der Autorisierungs- und Zahlungsumgebung, in denen mehr als 500.000 Kontonummern

gespeichert werden. Hinweis: Auch wenn einige Datenspeicher oder Systeme vom Audit ausgenommen werden, hat der Händler sicherzustellen, dass alle Systeme zum Speichern, Verarbeiten oder Übermitteln von Karteninhaberdaten dem PCI DSS entsprechen.

• POS (Point-of-Sale)-Umgebung – überall dort, wo am Standort des Händlers Transaktionen angenommen werden (d. h. Einzelhandelsgeschäft, Restaurant, Hotel, Tankstelle, Supermarkt oder anderer POS-Ort).


• Ist kein externer Zugriff auf den Händlerstandort vorhanden (über Internet, Drahtlostechnologie, virtuelles privates Netz (VPN), Einwahl, Breitband oder öffentlich zugängliche Geräte wie Kiosks), kann die POS-Umgebung ausgenommen werden.

Drahtlostechnologie

Wenn zum Speichern, Verarbeiten oder Übermitteln von Karteninhaberdaten (z. B. Point-of-Sale-Transaktionen, „Line-Busting“) Drahtlostechnologie verwendet wird oder die Karteninhaber-Datenumgebung an ein drahtloses lokales Netz (WLAN) angeschlossen bzw. Teil eines solchen Netzes (z. B. nicht klar durch eine Firewall abgegrenzt), gelten die Anforderungen und Testverfahren für drahtlose Umgebungen und müssen ebenfalls erfüllt bzw. ausgeführt werden. Die Sicherheit von Drahtlostechnologien ist zwar noch nicht ausgereift, doch geben diese Anforderungen die grundlegenden Sicherheitsfunktionen für Drahtlostechnologien an, die zur Gewährleistung eines minimalen Schutzes implementiert werden müssen. Da Drahtlostechnologien noch nicht ausreichend gesichert werden können, sollten Unternehmen das Für und Wider sorgfältig abwägen, bevor sie sich für den Einsatz solcher Technologien entscheiden. Es wird empfohlen, Drahtlostechnologie nur bei der Übertragung nicht vertraulicher Daten einzusetzen oder zu warten, bis eine sicherere Technologie verwendet werden kann.

Outsourcing

Bei Entitäten, die dritte Dienstanbieter mit der Speicherung, Verarbeitung oder Übertragung von Karteninhaberdaten beauftragen, müssen die Aufgaben der einzelnen Dienstanbieter im Erfüllungsbericht dokumentiert sein. Weiterhin müssen die Dienstanbieter unabhängig von den Audits ihrer Kunden selbst dafür Sorge tragen, dass sie selbst die Anforderungen des PCI DSS erfüllen. Außerdem müssen Händler und Dienstanbieter alle beauftragten dritten Parteien, die über Zugriff auf Karteninhaberdaten verfügen, vertraglich zur Einhaltung des PCI DSS verpflichten. Weitere Informationen finden Sie unter Anforderung 12.8 in diesem Dokument.

Stichproben

Der Gutachter kann unter den zu testenden Systemkomponenten eine repräsentative Auswahl treffen. In dieser Stichprobe müssen alle Typen von Systemkomponenten sowie verschiedene Betriebssysteme, Funktionen und Anwendungen, die für den zu prüfenden Bereich maßgebend sind, vertreten sein. Der Prüfer kann z. B. Sun-Server mit Apache WWW, NT-Server mit Oracle, Mainframe-Systeme mit Legacy-Kartenverarbeitungsanwendungen, Datenübertragungsserver mit HP-UX und Linux-Server mit MYSQL auswählen. Wenn alle Anwendungen unter demselben Betriebssystem (z. B. NT oder Sun) ausgeführt werden, sollte die Stichprobe verschiedene Anwendungen umfassen (z. B. Datenbankserver, Webserver oder Datenübertragungsserver).

Bei der Stichprobenauswahl für Handelsgeschäfte bzw. Vertragshändler sollten die Gutachter Folgendes berücksichtigen: • Wenn standardmäßige, obligatorische PCI DSS-Prozesse eingesetzt werden, die von jedem Geschäft zu befolgen sind,

kann die Stichprobe kleiner ausfallen als gewöhnlich, um die Übereinstimmung mit dem Standardprozess in angemessener Weise sicherzustellen.


• Wenn mehrere Standardprozesse (z. B. für verschiedene Geschäftstypen) vorhanden sind, muss die Stichprobe groß genug sein, um alle Geschäfte zu berücksichtigen, die mit den einzelnen Prozesstypen gesichert werden.

• Wenn keine standardmäßigen PCI DSS-Prozesse verwendet werden und jedes Geschäft für seine Prozesse selbst verantwortlich ist, muss die Stichprobengröße größer sein, um sicherzustellen, dass die Anforderungen des PCI DSS von den einzelnen Geschäften richtig verstanden und umgesetzt werden.

Ersatzkontrollen

Ersatzkontrollen müssen vom Gutachter dokumentiert und zusammen mit dem Erfüllungsbericht eingereicht werden (siehe Anhang C, „Arbeitsblatt für Ersatzkontrollen mit Beispiel“).

Siehe Definition für „Ersatzkontrollen“ unter „PCI DSS-Glossar, Abkürzungen und Akronyme”.

Anweisungen zu Erstellung und Inhalt des Erfüllungsberichts Dieses Dokument ist von Gutachtern bei der Erstellung des Erfüllungsberichts als Vorlage zu verwenden. Die geprüfte Entität sollte die Berichtsanforderungen des jeweiligen Zahlungskartenunternehmens einhalten, um die Anerkennung ihres Erfüllungsstatus durch das Unternehmen sicherzustellen. Informieren Sie sich bei den einzelnen Zahlungskartenunternehmen über die jeweiligen Berichtsanforderungen und Anweisungen. Alle Gutachter müssen bei der Erstellung eines Erfüllungsberichts die folgenden Anweisungen für Inhalt und Format befolgen:

1. Kontaktinformationen und Berichtsdatum

• Nehmen Sie Kontaktinformationen für Händler bzw. Dienstanbieter und Gutachter auf • Datum des Berichts

2. Zusammenfassung Nehmen Sie Folgendes in den Bericht auf: • Geschäftsbeschreibung • Dienstanbieter und andere Entitäten, mit denen das Unternehmen Karteninhaberdaten austauscht • Prozessorbeziehungen • Angaben darüber, ob die Entität direkt mit dem Zahlungskartenunternehmen verbunden ist • Bei Händlern: verwendete POS-Produkte • Alle Entitäten im Alleineigentum, die zur Erfüllung des PCI DSS verpflichtet sind • Alle internationalen Entitäten, die zur Erfüllung des PCI DSS verpflichtet sind • Alle mit der Karteninhaber-Datenumgebung verbundenen WLANs und/oder drahtlosen POS-Terminals


3. Beschreibung von Arbeitsumfang und Verfahrensweise

• Version des Dokuments zu den Sicherheitsprüfungsverfahren, das für die Prüfung verwendet wird • Prüfungszeitrahmen • Umgebung, auf die sich die Prüfung konzentriert (z. B. Internetzugriffspunkte des Kunden, internes Firmennetz,

Verarbeitungspunkte für das Zahlungskartenunternehmen) • Von der Überprüfung ausgenommene Bereiche • Kurze Beschreibung oder Übersichtszeichnung der Netzwerktopologie und Kontrollen • Liste der befragten Personen • Liste der überprüften Dokumentation • Liste der verwendeten Hardware und relevanten Software (z. B. Datenbank- oder Verschlüsselungssoftware) • Bei MSP (Managed Service Provider)-Überprüfungen: genaue Darstellung der für den MSP geltenden (und in der Überprüfung

eingeschlossenen) Anforderungen in diesem Dokument sowie der Anforderungen, die nicht in der Überprüfung eingeschlossen sind und von den Kunden des MSP in ihre Überprüfungen aufgenommen werden müssen. Informationen zu den IP-Adressen des MSP, die im Rahmen der vierteljährlichen Schwachstellenscans des MSP überprüft werden, sowie zu den IP-Adressen, die von den Kunden des MSP in ihre vierteljährlichen Scans einbezogen werden müssen.

4. Ergebnisse der vierteljährlichen Scans

• Fassen Sie die Ergebnisse der vier letzten vierteljährlichen Überprüfungen in Anforderung 11.2 unter „Anmerkungen“ zusammen. • Die Überprüfung muss alle bei der Entität vorhandenen, extern (per Internet) zugänglichen IP-Adressen abdecken.

5. Ergebnisse und Beobachtungen • Alle Gutachter müssen für die Erstellung von detaillierten Berichtsbeschreibungen und Ergebnissen zu den einzelnen

Anforderungen und Unteranforderungen die folgende Vorlage verwenden. • Dokumentieren Sie ggf. erwogene Ersatzkontrollen, die Aufschluss darüber geben, ob eine Kontrolle vorhanden ist. • Eine Definition von Ersatzkontrollen finden Sie unter „PCI DSS-Glossar, Abkürzungen und Akronyme”.

Erneute Überprüfung von offenen Posten Für die Erfüllungsprüfung ist ein Bericht über vorhandene Kontrollen erforderlich. Wenn der erste Bericht des Prüfers/Gutachters offene Posten enthält, muss der Händler/Dienstanbieter diese bereinigen, bevor die Überprüfung abgeschlossen werden kann. Der Gutachter/Prüfer überprüft dann erneut, ob Abhilfe geschaffen wurde und alle Anforderungen erfüllt sind. Nach dieser erneuten Überprüfung stellt der Gutachter einen neuen Erfüllungsbericht aus, um die volle Konformität des Systems zu bestätigen, und reicht ihn gemäß den Anweisungen ein (siehe oben).


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.

ANFORDERUNGEN DES PCI DSS TESTVERFAHREN VORHANDEN NICHT VORHANDEN

ZIELDATUM/ ANMERKUNGEN

1.1 Richten Sie Firewallkonfigurationsstandards ein, die Folgendes umfassen:

1.1 Beschaffen Sie sich die Firewallkonfigurationsstandards und sonstige unten angegebene Dokumentationen, und überprüfen Sie sie auf Vollständigkeit. Füllen Sie jedes Feld in diesem Abschnitt aus.

1.1.1 Formelles Genehmigungs- und Testverfahren für alle externen Netzwerkverbindungen und Änderungen an der Firewallkonfiguration

1.1.1 Überprüfen Sie, ob die Firewallkonfigurationsstandards ein formelles Verfahren für alle Firewalländerungen umfassen, einschließlich einer Test- und Verwaltungsgenehmigung für alle Änderungen an den externen Verbindungen und der Firewallkonfiguration.

1.1.2 Aktuelles Netzwerkdiagramm mit allen Verbindungen zu Karteninhaberdaten, einschließlich drahtloser Netzwerke

1.1.2.a Überprüfen Sie, ob ein aktuelles Netzwerkdiagramm vorhanden ist, das alle Verbindungen zu Karteninhaberdaten dokumentiert, einschließlich drahtloser Netzwerke.

1.1.2.b. Überprüfen Sie, ob das Diagramm regelmäßig aktualisiert wird.

1.1.3 Anforderungen für eine Firewall an jedem Internetanschluss sowie zwischen entmilitarisierten Zonen (Demilitarized Zone, DMZ) und der internen Netzwerkzone

1.1.3 Überprüfen Sie, ob die Firewallkonfigurationsstandards Anforderungen für eine Firewall an jedem Internetanschluss sowie zwischen DMZ und dem Intranet umfassen. Überprüfen Sie, ob das aktuelle Netzwerkdiagramm mit




den Firewallkonfigurationsstandards übereinstimmt. 1.1.4 Beschreibung von Gruppen, Rollen und Verantwortlichkeiten für die logische Verwaltung von Netzwerkkomponenten

1.1.4 Überprüfen Sie, ob die Firewallkonfigurationsstandards eine Beschreibung von Gruppen, Rollen und Verantwortlichkeiten für die logische Verwaltung von Netzwerkkomponenten umfassen.

1.1.5 Dokumentierte Liste von Diensten und Anschlüssen, die für die Geschäftstätigkeit notwendig sind

1.1.5 Überprüfen Sie, ob die Firewallkonfigurationsstandards eine dokumentierte Liste von Diensten/Anschlüssen umfassen, 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.6 Überprüfen Sie, ob die Firewallkonfigurationsstandards eine Dokumentation und Begründung der Notwendigkeit weiterer verfügbarer Protokolle neben HTTP and SSL, SSH und VPN umfassen.

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.7.a Überprüfen Sie, ob die Firewallkonfigurationsstandards eine Dokumentation und Begründung der Notwendigkeit riskanter zulässiger Protokolle (z. B. File Transfer Protocol (FTP)) umfassen, einschließlich einer Begründung für die Verwendung des betreffenden Protokolls und der implementierten Sicherheitsfunktionen.

1.1.7.b Überprüfen Sie die Dokumentation und die Einstellungen für die einzelnen verwendeten Dienste auf Belege dafür, dass die betreffenden Dienste erforderlich und gesichert sind.

1.1.8 Vierteljährliche Überprüfung der Regelsätze für Firewalls und Router

1.1.8.a Überprüfen Sie, ob die Firewallkonfigurationsstandards eine vierteljährliche Überprüfung der Regelsätze für Firewalls und Router vorsehen.

1.1.8.b Überprüfen Sie, ob die Regelsätze vierteljährlich überprüft werden.

1.1.9 Konfigurationsstandards für Router

1.1.9 Überprüfen Sie, ob sowohl für Firewalls als auch für Router Firewallkonfigurationsstandards vorhanden sind.




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.

Treffen Sie eine repräsentative Auswahl unter den Firewalls/Routern 1) zwischen Internet und DMZ und 2) zwischen DMZ und internem Netzwerk. Diese Stichprobe sollte den Choke-Router am Internet, den DMZ-Router und die Firewall, das DMZ-Karteninhabersegment, den Perimeter-Router und das interne Karteninhaber-Netzwerksegment enthalten. Überprüfen Sie die Firewall- und Routerkonfiguration, um sicherzustellen, dass der eingehende und ausgehende Datenverkehr auf die Protokolle beschränkt wird, 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:

1.3 Überprüfen Sie die Firewall-/Routerkonfigurationen, um sicherzustellen, dass Verbindungen zwischen öffentlich zugänglichen Servern und Komponenten, in denen Karteninhaberdaten gespeichert werden, wie folgt beschränkt werden:

1.3.1 Beschränkung des eingehenden Internetverkehrs auf Internetprotokolladressen (IP-Adressen) innerhalb der DMZ (Ingressfilter)

1.3.1 Überprüfen Sie, ob der eingehende Internetverkehr auf IP-Adressen innerhalb der DMZ beschränkt wird.

1.3.2 Unterbindung der Weitergabe von internen Adressen vom Internet an die DMZ

1.3.2 Überprüfen Sie, ob die Weitergabe von internen Adressen vom Internet an die DMZ unterbunden wird.

1.3.3 Implementierung einer statusbehafteten Inspektion, auch als „dynamische Paketfilterung“ bezeichnet (d. h. nur „hergestellte“ Verbindungen mit dem Netzwerk werden zugelassen)

1.3.3 Überprüfen Sie, ob die Firewall eine statusbehaftete Inspektion (dynamische Paketfilterung) durchführt. [Nur hergestellte Verbindungen, die einer zuvor hergestellten Sitzung zugeordnet sind, sollten zugelassen werden (führen Sie NMAP an allen TCP-Anschlüssen mit dem Bitsatz „syn reset“ oder „syn ack“ aus – eine Antwort bedeutet, dass Pakete durchgelassen werden, auch wenn sie nicht Teil einer




zuvor hergestellten Sitzung sind)]1.3.4 Speicherort der Datenbank in einer internen, von der DMZ getrennten Netzwerkzone

1.3.4 Überprüfen Sie, ob sich die Datenbank in einer internen, von der DMZ getrennten Netzwerkzone befindet.

1.3.5 Beschränkung des eingehenden und ausgehenden Datenverkehrs auf die für die Karteninhaberdaten-Umgebung erforderlichen Daten

1.3.5 Überprüfen Sie, ob der eingehende und ausgehende Datenverkehr auf die für die Karteninhaber-Datenumgebung erforderlichen Daten beschränkt wird und die Beschränkungen dokumentiert werden.

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.6 Überprüfen Sie, ob die Routerkonfigurationsdateien sicher und synchronisiert sind [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.7 Überprüfen Sie, ob sämtlicher eingehender und ausgehender Datenverkehr, der nicht unter den oben stehenden Punkten 1.2 und 1.3 genannt wurde, gesondert unterbunden wird.

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.8 Überprüfen Sie, ob Perimeter-Firewalls zwischen allen drahtlosen Netzwerken und Speichersystemen für Karteninhaberdaten installiert sind und diese Firewalls den Datenverkehr von der drahtlosen Umgebung zu den Speichersystemen unterbinden oder kontrollieren (falls dieser Verkehr 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

1.3.9 Überprüfen Sie, ob 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, persönliche Firewallsoftware installiert und aktiviert ist, die von der Organisation nach bestimmten Standards konfiguriert wurde und vom




Organisation zugegriffen wird Mitarbeiter nicht geändert werden kann.1.4 Unterbinden des direkten öffentlichen Zugriffs zwischen externen Netzwerken und Systemkomponenten, die Karteninhaberdaten speichern (z. B. Datenbanken, Protokolle, Ablaufverfolgungsdateien)

1.4 Um zu bestimmen, ob der direkte Zugriff zwischen externen öffentlichen Netzwerken und Systemkomponenten, die Karteninhaberdaten speichern, unterbunden wird, sind insbesondere für die zwischen DMZ und internem Netzwerk implementierte Firewall-/Routerkonfiguration folgende Schritte auszuführen:

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.1 Überprüfen Sie die Firewall-/Routerkonfigurationen und vergewissern Sie sich, dass keine direkten Pfade für eingehenden oder ausgehenden Internetverkehr vorhanden sind.

1.4.2 Beschränken des ausgehenden Datenverkehrs von Zahlungskartenanwendungen auf IP-Adressen innerhalb der DMZ

1.4.2 Überprüfen Sie die Firewall-/Routerkonfigurationen und stellen Sie sicher, dass der interne ausgehende Datenverkehr von Karteninhaberanwendungen nur auf IP-Adressen innerhalb der DMZ zugreifen kann.

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).

1.5 Überprüfen Sie für die oben angegebene Auswahl von Firewall-/Routerkomponenten, ob die Weiterleitung von IP-Adressen aus dem internen Netzwerk an das Internet mithilfe von NAT oder einer anderen Technologie, die den Adressraum RFC 1919 verwendet, unterbunden wird (IP-Tarnung).

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.1 Treffen Sie eine repräsentative Auswahl unter Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, und versuchen Sie (mithilfe des Administrators), sich mit den vom Hersteller vorgegebenen Konten und Kennwörtern anzumelden, um zu überprüfen, ob diese geändert wurden. (Vom Hersteller vorgegebene Konten/Kennwörter finden Sie in Anbieterhandbüchern und Quellen im Internet.)

2.1.1 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.

2.1.1 Überprüfen Sie in Bezug auf herstellerseitige Voreinstellungen für drahtlose Umgebungen Folgendes:

• Die vorgegebenen WEP-Schlüssel wurden bei der Installation geändert. Außerdem werden sie jedes Mal geändert, wenn ein Mitarbeiter, der die Schlüssel kennt, das Unternehmen verlässt oder versetzt wird.

• Die vorgegebene SSID wurde geändert. • SSID-Broadcast wurde deaktiviert. • Vorgegebene SNMP-

Communityzeichenfolgen an Zugriffspunkten wurden geändert.

• Vorgegebene Kennwörter an Zugriffspunkten wurden geändert.

• Bei WPA-Fähigkeit: WPA- oder WPA2-Technologie ist aktiviert.

• Ggf. sonstige sicherheitsrelevante Standardeinstellungen des Herstellers für drahtlose Umgebungen.

2.2 Arbeiten Sie Konfigurationsstandards für alle Systemkomponenten aus.Vergewissern Sie sich, dass diese Standards alle bekannten Sicherheitsrisiken berücksichtigen und den anerkannten

2.2.a Überprüfen Sie die Systemkonfigurationsstandards der Organisation für Netzwerkkomponenten, kritische Server und drahtlose Zugriffspunkte, und vergewissern Sie sich, dass die Systemkonfigurationsstandards mit den anerkannten Systemhärtungsstandards der IT-Branche (z. B. SANS, NIST und CIS) übereinstimmen.




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.b Überprüfen Sie, ob die Systemkonfigurationsstandards sämtliche unter 2.2.1 bis 2.2.4 angegebenen Elemente umfassen.

2.2.c Überprüfen Sie, ob die Systemkonfigurationsstandards bei der Konfiguration neuer Systeme angewendet werden.

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.1 Überprüfen Sie anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, ob pro Server nur eine primäre Funktion implementiert ist.

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.2 Überprüfen Sie anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten aktivierte Systemdienste, Daemons und Protokolle. Überprüfen Sie, ob unnötige oder unsichere Dienste oder Protokolle deaktiviert sind oder ob ihre Verwendung gerechtfertigt und dokumentiert ist (z. B. dass FTP nicht verwendet oder mit SSH oder einer anderen Technologie verschlüsselt wird).

2.2.3 Konfigurieren Sie Systemsicherheitsparameter, um Datenmissbrauch zu verhindern.

2.2.3.a Befragen Sie Systemadministratoren und/oder Sicherheitsmanager, um zu überprüfen, ob sie mit allgemeinen Sicherheitsparametereinstellungen für ihre Betriebssysteme, Datenbankserver, Webserver und drahtlosen Systeme vertraut sind.

2.2.3.b Überprüfen Sie, ob die Systemkonfigurationsstandards allgemeine Sicherheitsparametereinstellungen umfassen.

2.2.3.c Überprüfen Sie anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, ob die allgemeinen Sicherheitsparameter ordnungsgemäß festgelegt wurden.

2.2.4 Entfernen Sie alle unnötigen Funktionen, wie Skripts, Treiber, Features, Subsysteme, Dateisysteme

2.2.4 Überprüfen Sie anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, ob alle unnötigen Funktionen (z. B. Skripts, Treiber,




und nicht benötigte Webserver. Features, Subsysteme, Dateisysteme usw.) entfernt wurden. Überprüfen Sie, ob aktivierte Funktionen dokumentiert sind und eine sichere Konfiguration unterstützen und nur dokumentierte Funktionen auf den ausgewählten Geräten vorhanden sind.

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.3 Überprüfen Sie anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, ob nicht konsolengebundener Administratorzugriff verschlüsselt wird. Gehen Sie dazu wie folgt vor:

• Beobachten Sie die Anmeldung eines Administrators bei den einzelnen Systemen, um zu überprüfen, ob vor Abfrage des Administratorkennworts SSH (oder eine andere Verschlüsselungsmethode) aufgerufen wird.

• Überprüfen Sie Dienste und Parameterdateien in Systemen, um sich zu vergewissern, dass Telnet- und andere Befehle für die Remoteanmeldung nicht für die interne Verwendung verfügbar sind.

• Überprüfen Sie, ob der Administratorzugriff auf die drahtlose Verwaltungsschnittstelle mit SSL/TLS verschlüsselt wird. Alternativ dazu können Sie überprüfen, ob die Remoteanmeldung von Administratoren bei der drahtlosen Verwaltungsschnittstelle unterbunden wird (die Verwaltung drahtloser Umgebungen erfolgt ausschließlich über die Konsole).

2.4 Hosting-Anbieter müssen die gehosteten Umgebungen und Daten der einzelnen Entitäten schützen. Diese Anbieter müssen bestimmte in Anhang A beschriebene Anforderungen erfüllen: „Anwendbarkeit des PCI DSS für Hosting-Anbieter“.

2.4 Führen Sie bei PCI-Audits für Shared-Hosting-Anbieter die Testverfahren A.1.1 bis A.1.4 durch, die in Anhang A unter „Anwendbarkeit des PCI DSS für Hosting-Anbieter (mit Testverfahren)“ beschrieben werden, um zu überprüfen, ob die Shared-Hosting-Anbieter die gehosteten Umgebungen und Daten ihrer Entitäten (Händler und Dienstanbieter) schützen.


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.1 Beschaffen Sie sich die Richtlinien und Prozeduren des Unternehmens für das Aufbewahren und Löschen von Daten, und überprüfen Sie,

• ob die Richtlinien und Prozeduren rechtliche, behördliche und geschäftliche Anforderungen für das Speichern von Daten umfassen, einschließlich spezifischer Anforderungen für das Speichern von Karteninhaberdaten (z. B. aus welchen betrieblichen Gründen Karteninhaberdaten für welchen Zeitraum gespeichert werden müssen).

• ob die Richtlinien und Prozeduren Bestimmungen für das Löschen von Daten (einschließlich Karteninhaberdaten) umfassen, die nicht mehr aus rechtlichen, behördlichen oder geschäftlichen Gründen benötigt werden.

• ob die Richtlinien und Prozeduren alle Speicherorte für Karteninhaberdaten abdecken, einschließlich Datenbankservern, Mainframes, Transferverzeichnissen und Massendaten-Kopierverzeichnissen zur Übertragung von Daten zwischen Servern sowie Verzeichnissen zur




Normalisierung von Daten zwischen Serverübertragungen.

• ob die Richtlinien und Prozeduren einen programmgesteuerten (automatischen) Prozess umfassen, mit dem gespeicherte Karteninhaberdaten, die die Speicherfrist in den geschäftlichen Anforderungen überschritten haben, erfüllen, mindestens vierteljährlich entfernt werden. Als Alternative sind auch Anforderungen für ein mindestens vierteljährlich auszuführendes Audit möglich, mit dem sichergestellt wird, dass Karteninhaberdaten die Speicherfrist in den geschäftlichen Anforderungen nicht überschreiten.




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 Wenn vertrauliche Authentifizierungsdaten empfangen und gelöscht werden, informieren Sie sich über die Prozesse zum Löschen der Daten, um sicherzustellen, dass die Daten nicht wiederhergestellt werden können. Führen Sie für alle unten genannten vertraulichen Authentifizierungsdaten folgende Schritte aus:

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 Prüfcode oder -wert der Karte oder Datenelemente des PIN-Prüfwerts.

Hinweis: Weitere Informationen finden Sie im Glossar.

3.2.1 Überprüfen Sie anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten folgende Elemente, und vergewissern Sie sich, dass unter keinen Umständen der vollständige Inhalt einer Spur auf dem Magnetstreifen gespeichert wird:

• Eingehende Transaktionsdaten • Transaktionsprotokolle • Verlaufsdateien • Ablaufverfolgungsdateien • Debugprotokolle • Verschiedene Datenbankschemas • Datenbankinhalte

3.2.2 Speichern Sie auf keinen Fall den Kartenprüfcode (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.2 Überprüfen Sie anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten folgende Elemente, und vergewissern Sie sich, dass unter keinen Umständen der drei- oder vierstellige Kartenprüfcode auf der Vorderseite der Karte oder im Signaturfeld (CVV2-, CVC2-, CID-, CAV2-Daten) gespeichert wird:

• Eingehende Transaktionsdaten




• Transaktionsprotokolle • Verlaufsdateien • Ablaufverfolgungsdateien • Debugprotokolle • Verschiedene Datenbankschemas • Datenbankinhalte

3.2.3 Speichern Sie auf keinen Fall die persönliche Identifikationsnummer (PIN) oder den verschlüsselten PIN-Block.

3.2.3 Überprüfen Sie anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugangspunkten folgende Elemente, und vergewissern Sie sich, dass unter keinen Umständen PINs und verschlüsselte PIN-Blöcke gespeichert werden:

• Eingehende Transaktionsdaten • Transaktionsprotokolle • Verlaufsdateien • Ablaufverfolgungsdateien • Debugprotokolle • Verschiedene Datenbankschemas • Datenbankinhalte

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.3 Beschaffen Sie sich die Richtlinien in schriftlicher Form, und überprüfen Sie sie. Überprüfen Sie die Onlineanzeige von Kreditkartendaten, um sicherzustellen, dass Kreditkartennummern maskiert werden, sofern kein besonderer Grund zum Anzeigen von vollständigen Kreditkartennummern besteht.




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“.

3.4.a Beschaffen Sie sich die Dokumentation zu dem System, das zum Schützen gespeicherter Daten verwendet wird, und überprüfen Sie sie. Dazu gehören auch Informationen wie Hersteller, System-/Prozesstyp und ggf. Verschlüsselungsalgorithmus. Überprüfen Sie, ob Daten mithilfe einer der folgenden Methoden unlesbar gemacht werden:

• One-Way-Hashes (Hash-Indizes), z. B. SHA-1

• Abschneiden oder Maskieren • Indextoken und PADs, wobei die PADs

sicher gespeichert werden • Starke Kryptografie, z. B. Triple-DES

(128 Bit) oder AES (256 Bit) mit dazugehörigen Schlüsselverwaltungsprozessen und -prozeduren

3.4.b Überprüfen Sie verschiedene Tabellen einer repräsentativen Auswahl von Datenbankservern, um zu überprüfen, ob die Daten unlesbar gemacht (d. h. nicht als Klartext gespeichert) werden.

3.4.c Überprüfen Sie eine repräsentative Auswahl von Wechseldatenträgern (z. B. Sicherungsbänder), um sich zu vergewissern, dass Karteninhaberdaten unlesbar gemacht werden.

3.4.d Untersuchen Sie eine repräsentative Auswahl von Überwachungsprotokollen, um sich zu vergewissern, dass Karteninhaberdaten geschützt sind oder aus den Protokollen entfernt werden.

3.4.e Überprüfen Sie, ob aus drahtlosen Netzwerken empfangene Karteninhaberdaten unabhängig vom Speicherort unlesbar gemacht werden.




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.4.1.a Wenn Datenträgerverschlüsselung verwendet wird, überprüfen Sie, ob der logische Zugriff auf verschlüsselte Dateisysteme über einen Mechanismus implementiert wird, der von systemeigenen Betriebssystemmechanismen getrennt ist (indem z. B. keine lokalen oder Active Directory-Konten verwendet werden).

3.4.1.b Vergewissern Sie sich, dass die Entschlüsselungsschlüssel nicht auf dem lokalen System gespeichert werden (sondern z. B. auf Diskette, CD-ROM usw., wo sie gesichert und nur bei Bedarf abgerufen werden).

3.4.1.c Überprüfen Sie, ob Karteninhaberdaten auf Wechseldatenträgern unabhängig vom Speicherort verschlüsselt werden (Wechseldatenträger können häufig nicht mit Datenträgerverschlüsselung verschlüsselt werden).

3.5 Schützen Sie Verschlüsselungsschlüssel für Karteninhaberdaten vor Offenlegung und Missbrauch:

3.5 Überprüfen Sie wie folgt die Prozesse zum Schutz von Verschlüsselungsschlüsseln 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.1 Überprüfen Sie anhand von Benutzerzugriffslisten, ob der Zugriff auf kryptografische Schlüssel auf nur wenige Verwalter beschränkt ist.

3.5.2 Speichern Sie Schlüssel sicher an so wenigen Orten und in so wenigen Formaten wie möglich

3.5.2 Überprüfen Sie anhand von Systemkonfigurationsdateien, ob kryptografische Schlüssel in verschlüsseltem Format und Schlüsselverschlüsselungsschlüssel getrennt von Datenverschlüsselungsschlüsseln gespeichert werden.

3.6 Alle Schlüsselverwaltungsprozesse und -prozeduren für die Verschlüsselung von Karteninhaberdaten müssen vollständig dokumentiert und implementiert werden:

3.6.a Überprüfen Sie, ob Schlüsselverwaltungsprozeduren für die Verschlüsselung von Karteninhaberdaten vorhanden sind.




3.6.b Nur Dienstanbieter: Wenn der Dienstanbieter mit seinen Kunden Schlüssel für die Übertragung von Karteninhaberdaten austauscht, überprüfen Sie, ob der Dienstanbieter seinen Kunden eine Dokumentation mit Richtlinien zum sicheren Speichern und Ändern ihrer Verschlüsselungsschlüssel (für die Übertragung von Daten zwischen Kunden und Dienstanbieter) zur Verfügung stellt.

3.6.c Überprüfen Sie die Schlüsselverwaltungsprozeduren und führen Sie folgende Schritte aus:

3.6.1 Generierung starker Schlüssel 3.6.1 Überprüfen Sie, ob die Schlüsselverwaltungsprozeduren die Generierung von starken Schlüsseln erfordern.

3.6.2 Sichere Schlüsselverteilung 3.6.2 Überprüfen Sie, ob die Schlüsselverwaltungsprozeduren sichere Schlüsselverteilung erfordern.

3.6.3 Sichere Schlüsselspeicherung 3.6.3 Überprüfen Sie, ob die Schlüsselverwaltungsprozeduren sichere Schlüsselspeicherung erfordern.

3.6.4 Regelmäßige Schlüsseländerungen • Je nach Notwendigkeit und

gemäß den Empfehlungen der zugehörigen Anwendung (z. B. Neuverschlüsselung); vorzugsweise automatisch

• Mindestens einmal pro Jahr

3.6.4 Überprüfen Sie, ob die Schlüsselverwaltungsprozeduren regelmäßige Schlüsseländerungen erfordern. Überprüfen Sie, ob die Schlüsseländerungsprozeduren mindestens einmal pro Jahr ausgeführt werden.

3.6.5 Löschen alter Schlüssel 3.6.5 Überprüfen Sie, ob die Schlüsselverwaltungsprozeduren das Löschen alter Schlüssel erfordern.

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.6 Überprüfen Sie, ob die Schlüsselverwaltungsprozeduren die Anwendung des Vier- oder Sechsaugenprinzips erfordern (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.7 Überprüfen Sie, ob die Schlüsselverwaltungsprozeduren es erforderlich machen, das unbefugte Ersetzen von Schlüsseln zu verhindern.

3.6.8 Auswechseln von Schlüsseln, die als unsicher erkannt oder vermutet werden

3.6.8 Überprüfen Sie, ob die Schlüsselverwaltungsprozeduren das Auswechseln von Schlüsseln erforderlich machen, die als unsicher erkannt oder vermutet werden.

3.6.9 Sperrung alter oder ungültiger Schlüssel

3.6.9 Überprüfen Sie, ob die Schlüsselverwaltungsprozeduren die Sperrung alter oder ungültiger Schlüssel erfordern (hauptsächlich für RSA-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.

3.6.10 Überprüfen Sie, ob die Schlüsselverwaltungsprozeduren von den Schlüsselverwaltern die Unterzeichnung eines Formulars erfordern, 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.a Überprüfen Sie, ob bei der Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke grundsätzlich Verschlüsselung (z. B. SSL/TLS oder IPSEC) eingesetzt wird.

• Überprüfen Sie, ob bei der Datenübertragung starke Verschlüsselung verwendet wird.

• Wenn SSL implementiert ist, vergewissern Sie sich, dass HTTPS als Teil der URL (Uniform Resource Locator) angezeigt wird und keine Karteninhaberdaten erforderlich sind, wenn dies nicht der Fall ist.

• Wählen Sie eine Stichprobe von empfangenen Transaktionen aus und beobachten Sie deren Abwicklung, um zu überprüfen, ob Karteninhaberdaten bei der Übertragung verschlüsselt werden.

• Vergewissern Sie sich, dass nur vertrauenswürdige SSL/TLS-Schlüssel bzw. -Zertifikate akzeptiert werden.

• Überprüfen Sie, ob die geeignete Verschlüsselungsstärke für die verwendete Verschlüsselungsmethode implementiert wird (siehe Empfehlungen/Verfahrensweisen des Herstellers).




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.1.1.a Bei drahtlosen Netzwerken, über die Karteninhaberdaten übertragen werden, oder die mit Karteninhaber-Datenumgebungen verbunden sind, ist sicherzustellen, dass für jede drahtlose Übertragung geeignete Verschlüsselungsmethoden verwendet werden, beispielsweise eine der folgenden Methoden: WiFi Protected Access (WPA oder WPA2), IPSEC VPN oder SSL/TLS.

4.1.1.b Bei Verwendung von WEP überprüfen Sie Folgendes:

• Verwendung mit einem Verschlüsselungsschlüssel von mindestens 104 Bit und einem Initialisierungswert von 24 Bit

• Verwendung nur in Verbindung mit WiFi Protected Access-Technologie (WPA oder WPA2), VPN oder SSL/TLS

• Mindestens vierteljährlicher Wechsel gemeinsam genutzter WEP-Schlüssel (oder automatisch, sofern die Technologie dies zulässt)

• Wechsel gemeinsam genutzter WEP-Schlüssel, wenn Änderungen bei Mitarbeitern mit Zugriff auf Schlüssel auftreten

• Beschränkung des anhand der MAC-Adresse erfolgenden Zugriffs

4.2 Senden Sie niemals per E-Mail unverschlüsselte PANs.

4.2.a Überprüfen Sie, ob beim Senden von Karteninhaberdaten per E-Mail eine E-Mail-Verschlüsselungslösung verwendet wird.

4.2.b Vergewissern Sie sich, dass eine Richtlinie vorhanden ist, die das Senden von unverschlüsselten PANs per E-Mail untersagt.




4.2.c Überprüfen Sie durch Befragung von drei bis fünf Mitarbeitern, ob für E-Mails, die PANs enthalten, E-Mail-Verschlüsselungssoftware erforderlich ist.


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.

Hinweis: UNIX-Betriebssysteme oder Mainframes gehören gewöhnlich nicht zu allgemein virenanfälligen Systemen.

5.1 Überprüfen Sie anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, ob ein Antivirusprogramm installiert ist.

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.1.1 Überprüfen Sie anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, ob 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.

5.2 Überprüfen Sie, ob die Antivirusprogramme aktuell und aktiviert sind und Überwachungsprotokolle erstellen können.

• Beschaffen Sie sich die entsprechende Richtlinie, und überprüfen Sie, ob sie Anforderungen für die Aktualisierung von Antivirusprogrammen und Virendefinitionen enthält.

• Überprüfen Sie, ob die Masterinstallation des Programms für automatische Aktualisierungen und regelmäßige Überprüfungen aktiviert ist und diese Features in einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten aktiviert sind.

• Überprüfen Sie, ob die Protokollgenerierung aktiviert ist und Protokolle in Übereinstimmung mit der Aufbewahrungsrichtlinie des Unternehmens aufbewahrt werden.

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.1.a Vergleichen Sie die Liste der auf den einzelnen Systemen installierten Sicherheitspatches anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern, drahtlosen Zugriffspunkten und zugehöriger Software mit der aktuellen Liste der Sicherheitspatches der Hersteller, um sicherzustellen, dass die aktuellen Sicherheitspatches installiert sind.

6.1.b Überprüfen Sie die Richtlinien zur Installation von Sicherheitspatches, um sicherzustellen, dass sie die Installation aller relevanten neuen Sicherheitspatches innerhalb von 30 Tagen vorsehen.

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.2.a Überprüfen Sie durch Befragung von zuständigen Mitarbeitern, ob Prozesse zur Identifizierung neuer Sicherheitsrisiken implementiert wurden.

6.2.b Überprüfen Sie, ob die Prozesse zur Identifizierung neuer Sicherheitsrisiken die Verwendung von externen Quellen zur Einholung von Informationen über Sicherheitsrisiken und Aktualisierung der unter Anforderung 2 überprüften Systemkonfigurationsstandards umfassen, wenn neue Sicherheitsrisiken gefunden werden.

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 Beschaffen Sie sich die Softwareentwicklungsprozesse in schriftlicher Form, und überprüfen Sie, ob sie auf Branchenstandards basieren und die Datensicherheit während des gesamten Lebenszyklus berücksichtigt wird. Überprüfen Sie durch Begutachtung der schriftlichen Softwareentwicklungsprozesse, Befragung von Softwareentwicklern und Untersuchung relevanter Daten (Dokumentation von Netzwerkkonfigurationen, Produktions- und




Testdaten usw.) Folgendes:6.3.1 Testen aller Sicherheitspatches sowie System- und Softwarekonfigurationsänderungen vor der Bereitstellung

6.3.1 Alle Änderungen (einschließlich Patches) werden vor der Bereitstellung für die Produktion getestet.

6.3.2 Trennen von Entwicklungs-, Test- und Produktionsumgebung

6.3.2 Die Test-/Entwicklungsumgebung ist von der Produktionsumgebung getrennt, und die Trennung wird durch Zugriffssteuerung erzwungen.

6.3.3 Trennung der Aufgaben in der Entwicklungs-, Test- und Produktionsumgebung

6.3.3 Es besteht eine Trennung zwischen Aufgaben von Mitarbeitern, die der Entwicklungs-/Testumgebung zugewiesen sind, und Aufgaben von Mitarbeitern, die der Produktionsumgebung zugewiesen sind.

6.3.4 Keine Verwendung von Produktionsdaten (aktive PANs) für Tests oder Entwicklung

6.3.4 Produktionsdaten (aktive PANs) werden nicht für Tests oder Entwicklung verwendet oder vor der Verwendung geschützt.

6.3.5 Entfernen von Testdaten und -konten von Produktionssystemen vor der Aktivierung

6.3.5 Testdaten und -konten werden vor der Aktivierung von Produktionssystemen entfernt.

6.3.6 Entfernen von benutzerdefinierten Anwendungskonten, Benutzernamen und Kennwörtern, bevor Anwendungen aktiviert oder für Kunden freigegeben werden.

6.3.6 Benutzerdefinierte Anwendungskonten, Benutzernamen und/oder Kennwörter werden entfernt, bevor das System in Produktion geht oder für Kunden freigegeben wird.

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.3.7.a Beschaffen Sie sich die Richtlinien in schriftlicher oder anderer Form, und überprüfen Sie, ob Codeüberprüfungen erforderlich sind und von anderen Personen als dem ursprünglichen Autor des Codes durchgeführt werden müssen.




6.3.7.b Vergewissern Sie sich, dass für neuen Code und nach Codeänderungen Codeüberprüfungen durchgeführt werden. Hinweis: Diese Anforderung betrifft Codeüberprüfungen für benutzerdefinierte Softwareentwicklung im Rahmen des System Development Life Cycle (SDLC) – diese Überprüfungen können von internen Mitabeitern durchgeführt werden. Benutzerdefinierter Code für Webanwendungen wird ab dem 30. Juni 2008 weiteren Kontrollen unterzogen – Einzelheiten finden Sie unter der PCI DSS-Anforderung 6.6.

6.4 Befolgen Sie Änderungskontrollverfahren für alle System- und Softwarekonfigurationsänderungen. Die Verfahren müssen Folgendes umfassen:

6.4.a Beschaffen Sie sich die Änderungskontrollverfahren des Unternehmens zur Implementierung von Sicherheitspatches und Softwareänderungen, und überprüfen Sie, ob sie die unten stehenden Punkte 6.4.1 bis 6.4.4 umfassen.

6.4.b Überprüfen Sie anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten die drei letzten Änderungen/Sicherheitspatches für die einzelnen Systemkomponenten, und verfolgen Sie diese Änderungen zu der zugehörigen Änderungskontrolldokumentation zurück. Vergewissern Sie sich, dass für jede überprüfte Änderung gemäß den Änderungskontrollverfahren Folgendes dokumentiert wurde:

6.4.1 Dokumentation von Auswirkungen 6.4.1 Überprüfen Sie, ob in der Änderungskontrolldokumentation für die einzelnen Änderungen die Auswirkungen auf den Kunden dokumentiert werden.

6.4.2 Genehmigung durch Vertreter der Geschäftsführung

6.4.2 Überprüfen Sie, ob für die einzelnen Änderungen eine Genehmigung durch




Vertreter der Geschäftsführung vorliegt. 6.4.3 Durchführen eines Funktionstests 6.4.3 Überprüfen Sie, ob für die einzelnen

Änderungen ein Funktionstest durchgeführt wurde.

6.4.4 Backoutverfahren 6.4.4 Überprüfen Sie, ob für die einzelnen Änderungen Backoutverfahren entwickelt wurden.

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 Anwendungscode auf Sicherheitsrisiken. Verhindern Sie häufig auftretende Codesicherheitsrisiken in Softwareentwicklungsprozessen, um Folgendes zu vermeiden:

6.5.a Beschaffen Sie sich die Softwareentwicklungsprozesse für webbasierte Anwendungen, und überprüfen Sie sie. Vergewissern Sie sich, dass die Prozesse eine Schulung für Entwickler in sicheren Codierungstechniken erfordern und auf Richtlinien wie den OWASP-Richtlinien (http://www.owasp.org) basieren.

6.5.b Überprüfen Sie, ob für webbasierte Anwendungen Prozesse vorhanden sind, die die Anfälligkeit dieser Anwendungen für Folgendes verhindern:

6.5.1 Nicht überprüfte Eingaben 6.5.1 Nicht überprüfte Eingaben

6.5.2 Unterbrochene Zugriffssteuerung (z. B. böswillige Verwendung von Benutzer-IDs)

6.5.2 Böswillige Verwendung von Benutzer-IDs

6.5.3 Unterbrochene Authentifizierungs- und Sitzungsverwaltung (Verwendung von Kontoanmeldeinformationen und Sitzungscookies)

6.5.3 Böswillige Verwendung von Kontoanmeldeinformationen und Sitzungscookies

6.5.4 XSS (Cross-Site-Scripting)-Angriffe 6.5.4 Cross-Site-Scripting

6.5.5 Pufferüberläufe 6.5.5 Pufferüberläufe aufgrund nicht überprüfter Eingaben und anderer Ursachen

6.5.6 Injektionslücken (z. B. SQL (Structured Query Language)-Injektion)

6.5.6 SQL-Injektion und andere Sicherheitslücken durch Codeinjektion

6.5.7 Nicht ordnungsgemäße Fehlerbehandlung

6.5.7 Mängel in der Fehlerbehandlung

6.5.8 Unsichere Speicherung 6.5.8 Unsichere Speicherung

6.5.9 Denial of Service 6.5.9 Denial of Service




6.5.10 Unsichere Konfigurationsverwaltung 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.

6.6 Stellen Sie wie folgt sicher, dass für webbasierte Anwendungen eine der folgenden Methoden verwendet wird:

• Stellen Sie sicher, dass benutzerdefinierter Anwendungscode regelmäßig von einer auf Anwendungssicherheit spezialisierten Organisation überprüft wird, alle Sicherheitsrisiken des Codes beseitigt wurden und die Anwendung nach der Korrektur erneut überprüft wurde.

• Stellen Sie sicher, dass vor Webanwendungen eine Firewall auf Anwendungsebene installiert wurde, um webbasierte Angriffe zu erkennen und abzuwehren.


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.1 Beschaffen Sie sich die Richtlinie zur Datenkontrolle in schriftlicher Form, und überprüfen Sie, ob sie Folgendes umfasst:

• Beschränkung der Rechte für Benutzer-IDs auf die geringsten Berechtigungen, die zum Ausführen der Tätigkeiten erforderlich sind

• Zuweisung von Berechtigungen nach Klassifizierung und Funktion der Tätigkeit des jeweiligen Mitarbeiters

• Anforderung für ein von der Geschäftsführung zu unterzeichnendes Autorisierungsformular, in dem die erforderlichen Berechtigungen angegeben werden

• Implementierung eines automatisierten Zugriffssteuerungssystems

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.

7.2 Überprüfen Sie anhand von Systemeinstellungen und Herstellerdokumentation, ob ein Zugriffssteuerungssystem implementiert ist, das Folgendes umfasst:

• Berücksichtigung aller Systemkomponenten

• Zuweisung von Berechtigungen nach Klassifizierung und Funktion der Tätigkeit des jeweiligen Mitarbeiters

• In der Standardeinstellung wird jeder Zugriff abgelehnt (in der Standardeinstellung einiger


Zugriffssteuerungssysteme wird jeder Zugriff zugelassen, sofern er nicht durch eine festgelegte Regel abgelehnt wird)

Anforderung 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.1 Überprüfen Sie anhand einer repräsentativen Auswahl von Benutzer-IDs Auflistungen von Benutzer-IDs und vergewissern Sie sich, dass allen Benutzern für den Zugriff auf Systemkomponenten oder Karteninhaberdaten ein eindeutiger Benutzername zugewiesen ist.

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.2 Um zu überprüfen, ob Benutzer für den Zugriff auf die Karteninhaber-Datenumgebung mit einer eindeutigen ID und zusätzlichen Anmeldeinformationen (z. B. einem Kennwort) authentifiziert werden, gehen Sie wie folgt vor:

• Beschaffen Sie sich die Dokumentation zu den verwendeten Authentifizierungsmethoden, und überprüfen Sie sie.

• Beobachten Sie für jede Art von Authentifizierungsmethode und jeden Systemkomponententyp, ob die Authentifizierung gemäß den dokumentierten Authentifizierungsmethoden erfolgt.

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

8.3 Um zu überprüfen, ob für den gesamten Remotenetzwerkzugriff 2-Faktoren-Authentifizierung implementiert ist, beobachten Sie einen Mitarbeiter (z. B. einen Administrator) beim Herstellen einer Remoteverbindung mit dem Netzwerk und vergewissern Sie sich, dass ein Kennwort sowie ein




Access Controller Access Control System (TACACS) mit Token oder VPN (basierend auf SSL/TLS oder IPSEC) mit individuellen Zertifikaten.

weiteres Authentifizierungselement (Smartcard, Token-PIN) erforderlich sind.0

8.4 Verschlüsseln Sie alle Kennwörter während der Übertragung und Speicherung auf allen Systemkomponenten.

8.4.a Untersuchen Sie die Kennwortdateien einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, um sicherzustellen, dass Kennwörter nicht lesbar sind.

8.4.b Nur Dienstanbieter: Überprüfen Sie anhand von Kennwortdateien, ob Kundenkennwörter verschlüsselt werden.




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 Überprüfen Sie Prozeduren und stellen Sie durch Befragung von Mitarbeitern sicher, dass Prozeduren zur Benutzerauthentifizierung und Kennwortverwaltung implementiert sind. Gehen Sie dazu wie folgt vor:

8.5.1 Steuern Sie das Hinzufügen, Löschen und Ändern von Benutzer-IDs, Anmeldeinformationen und anderen Identifizierungsobjekten.

8.5.1.a Überprüfen Sie anhand einer repräsentativen Auswahl von Benutzer-IDs, einschließlich Administratoren und allgemeinen Benutzern, ob jeder Benutzer gemäß der Unternehmensrichtlinie zur Verwendung des Systems autorisiert ist. Gehen Sie dazu wie folgt vor:

• Beschaffen Sie sich für jede ID ein Autorisierungsformular, und überprüfen Sie es.

• Überprüfen Sie, ob die ausgewählten Benutzer-IDs in Übereinstimmung mit dem Autorisierungsformular implementiert wurden (einschließlich der angegebenen Berechtigungen und aller erhaltenen Signaturen), indem Sie die Informationen vom Autorisierungsformular zum System zurückverfolgen.

8.5.1.b Vergewissern Sie sich, dass nur Administratoren Zugriff auf Verwaltungskonsolen für drahtlose Netzwerke haben.

8.5.2 Überprüfen Sie die Benutzeridentität, bevor Sie Kennwörter zurücksetzen.

8.5.2 Überprüfen Sie die Kennwortprozeduren und beobachten Sie das Sicherheitspersonal, um sicherzustellen, dass die Identität eines Benutzers überprüft wird, bevor seinem telefonisch, per E-Mail, über das Internet oder anderweitig nicht direkt vor Ort geäußerten Wunsch nachgekommen wird, ein Kennwort zurückzusetzen.

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.3 Überprüfen Sie die Kennwortprozeduren, und beobachten Sie das Sicherheitspersonal, um sicherzustellen, dass Ausgangskennwörter für jeden neuen Benutzer auf einen eindeutigen Wert festgelegt und nach der ersten Verwendung




geändert werden.8.5.4 Sperren Sie sofort den Zugriff von Benutzern, die das Unternehmen verlassen haben.

8.5.4 Vergleichen Sie eine repräsentative Auswahl von Mitarbeitern, die das Unternehmen in den letzten sechs Monaten verlassen haben, mit aktuellen Benutzerzugriffslisten, um sicherzustellen, dass die IDs dieser Mitarbeiter deaktiviert oder entfernt wurden.

8.5.5 Entfernen Sie inaktive Benutzerkonten mindestens alle 90 Tage.

8.5.5 Überprüfen Sie anhand einer repräsentativen Auswahl von Benutzer-IDs, ob inaktive Konten vorhanden sind, die älter als 90 Tage sind.

8.5.6 Aktivieren Sie Konten, die von Herstellern für die Remotewartung verwendet werden, nur für den benötigten Zeitraum.

8.5.6 Überprüfen Sie, ob Konten, die von Herstellern für die Unterstützung und Wartung von Systemkomponenten verwendet werden, deaktiviert sind, nur aktiviert werden, wenn dies für den Hersteller erforderlich ist, und während der Verwendung überwacht werden.

8.5.7 Teilen Sie allen Benutzern mit Zugriff auf Karteninhaberdaten die Kennwortprozeduren und -richtlinien mit.

8.5.7 Überprüfen Sie durch Befragung der Benutzer aus einer repräsentativen Auswahl von Benutzer-IDs, ob sie mit den Kennwortprozeduren und -richtlinien vertraut sind.

8.5.8 Verwenden Sie keine Gruppen-, gemeinsam genutzten oder generischen Konten und Kennwörter.

8.5.8.a Überprüfen Sie Benutzer-ID-Listen anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, um Folgendes sicherzustellen: • Generische Benutzer-IDs und Konten sind

deaktiviert oder wurden entfernt. • Gemeinsam genutzte Benutzer-IDs für

Systemverwaltungsaktivitäten und andere entscheidende Funktionen sind nicht vorhanden.

• Für die Verwaltung von WLANs und Geräten werden keine gemeinsam genutzten und generischen Benutzer-IDs verwendet.

8.5.1.b Überprüfen Sie die Kennwortrichtlinien/-prozeduren, um sicherzustellen, dass Gruppen- und gemeinsam genutzte Kennwörter explizit untersagt sind.




8.5.8.c Vergewissern Sie sich durch Befragung von Systemadministratoren, dass Gruppen- und gemeinsam genutzte Kennwörter auch auf Anforderung nicht verteilt werden.

8.5.9 Ändern Sie Benutzerkennwörter mindestens alle 90 Tage.

8.5.9 Beschaffen Sie sich die Systemkonfigurationseinstellungen für eine repräsentative Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, um zu überprüfen, ob die Benutzerkennwortparameter so festgelegt sind, dass die Benutzer Kennwörter mindestens alle 90 Tage ändern müssen. Nur Dienstanbieter: Überprüfen Sie anhand interner Prozesse und der Kunden-/Benutzerdokumentation, ob Kundenkennwörter regelmäßig geändert werden müssen und Kunden eine Anleitung zu Zeitpunkt und Bedingungen von erforderlichen Kennwortänderungen erhalten.

8.5.10 Legen Sie eine erforderliche Kennwortmindestlänge von sieben Zeichen fest.

8.5.10 Beschaffen Sie sich die Systemkonfigurationseinstellungen für eine repräsentative Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, und überprüfen Sie, ob die Kennwortparameter eine Kennwortlänge von mindestens sieben Zeichen vorschreiben. Nur Dienstanbieter: Überprüfen Sie anhand interner Prozesse und der Kunden-/Benutzerdokumentation, ob Kundenkennwörter eine Mindestlänge aufweisen müssen.

8.5.11 Verwenden Sie Kennwörter, die sowohl numerische als auch alphabetische Zeichen enthalten.

8.5.11 Beschaffen Sie sich die Systemkonfigurationseinstellungen für eine repräsentative Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, und überprüfen Sie, ob die Kennwortparameter so festgelegt sind, dass Kennwörter sowohl numerische als auch alphabetische Zeichen enthalten müssen. Nur Dienstanbieter: Überprüfen Sie anhand interner Prozesse und der Kunden-




/Benutzerdokumentation, ob Kundenkennwörter sowohl numerische als auch alphabetische Zeichen enthalten müssen.

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.12 Beschaffen Sie sich die Systemkonfigurationseinstellungen für eine repräsentative Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, und überprüfen Sie, ob die Kennwortparameter so festgelegt sind, dass neue Kennwörter nicht mit einem der letzten vier verwendeten Kennwörter identisch sein dürfen. Nur Dienstanbieter: Vergewissern Sie sich anhand interner Prozesse und der Kunden-/Benutzerdokumentation, dass neue Kundenkennwörter nicht mit einem der letzten vier Kennwörter identisch sein dürfen.

8.5.13 Begrenzen Sie die Anzahl wiederholter Zugriffsversuche, indem Sie die Benutzer-ID nach maximal sechs Versuchen sperren.

8.5.13 Beschaffen Sie sich die Systemkonfigurationseinstellungen für eine repräsentative Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, und überprüfen Sie, ob die Kennwortparameter so festgelegt sind, dass Benutzerkonten nach maximal sechs ungültigen Anmeldeversuchen gesperrt werden. Nur Dienstanbieter: Überprüfen Sie anhand interner Prozesse und der Kunden-/Benutzerdokumentation, ob Kundenkonten nach maximal sechs ungültigen Anmeldeversuchen vorübergehend gesperrt werden.

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.14 Beschaffen Sie sich die Systemkonfigurationseinstellungen für eine repräsentative Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, und überprüfen Sie, ob die Kennwortparameter so festgelegt sind, dass gesperrte Benutzerkonten für 30 Minuten oder so lange gesperrt bleiben, bis der Systemadministrator sie wieder zurücksetzt.

8.5.15 Wenn eine Sitzung länger als 15 Minuten im Leerlauf war, fordern Sie

8.5.15 Beschaffen Sie sich die Systemkonfigurationseinstellungen für eine




den Benutzer zur erneuten Eingabe des Kennworts auf, um das Terminal zu reaktivieren.

repräsentative Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, und überprüfen Sie, ob das Leerlauftimeout für Systeme/Sitzungen auf maximal 15 Minuten festgelegt ist.

8.5.16 Authentifizieren Sie sämtliche Zugriffe auf Datenbanken, die Karteninhaberdaten enthalten. Dazu gehört der Zugriff durch Anwendungen, Administratoren und alle anderen Benutzer.

8.5.16.a Überprüfen Sie anhand der Konfigurationseinstellungen einer repräsentativen Auswahl von Datenbanken, ob der Zugriff für einzelne Benutzer, Anwendungen, Administratoren usw. authentifiziert wird.

8.5.16.b Überprüfen Sie anhand von Datenbank-Konfigurationseinstellungen und Datenbankkonten, ob direkte SQL-Datenbankabfragen untersagt sind (es sollten nur sehr wenige einzelne Datenbank-Anmeldekonten vorhanden sein. Direkte SQL-Abfragen sollten auf Datenbankadministratoren beschränkt sein).

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 Überprüfen Sie, ob in allen Computerräumen, Datenzentren und anderen physischen Bereichen, in denen sich Systeme mit Karteninhaberdaten befinden, physische Sicherheitskontrollen eingesetzt werden.

• Vergewissern Sie sich, dass der Zugang durch Ausweisleser und sonstige Vorrichtungen kontrolliert wird, einschließlich autorisierter Ausweise sowie Schlösser und Schlüssel.




• Beobachten Sie die Anmeldung eines Systemadministrators bei den Konsolen von drei nach dem Zufallsprinzip ausgewählten Systemen in der Karteninhaber-Datenumgebung, und vergewissern Sie sich, dass diese für unautorisierte Verwendung gesperrt sind.

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.1 Überprüfen Sie, ob Eingänge/Ausgänge von Datenzentren, in denen Karteninhaberdaten gespeichert werden bzw. vorhanden sind, mit Videokameras überwacht werden. Die Videokameras sollten innerhalb der Datenzentren angebracht oder anderweitig vor Manipulationen oder Beschädigungen geschützt werden. Vergewissern Sie sich, dass die Kameras überwacht und die Daten aus den Kameras mindestens drei Monate lang gespeichert werden.

9.1.2 Beschränken Sie den physischen Zugriff auf öffentlich zugängliche Netzwerkschnittstellen.

9.1.2 Vergewissern Sie sich durch Befragung von Netzwerkadministratoren und Beobachtungen, dass Netzwerkschnittstellen nur bei Bedarf von autorisierten Mitarbeitern aktiviert werden. So sollten z. B. in Konferenzräumen, die für Besucher genutzt werden, keine DHCP-aktivierten Netzwerkanschlüsse vorhanden sein. Andernfalls stellen Sie sicher, dass Besucher in Bereichen mit aktivierten Netzwerkschnittstellen grundsätzlich begleitet werden.

9.1.3 Beschränken Sie den physischen Zugang zu drahtlosen Zugriffspunkten, Gateways und Handheldgeräten.

9.1.3 Überprüfen Sie, ob der physische Zugang zu drahtlosen Zugriffspunkten, Gateways und Handheldgeräten angemessen beschränkt wird.




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.2.a Überprüfen Sie die Prozesse und Prozeduren zur Aushändigung von Ausweisen an Mitarbeiter, Auftragnehmer und Besucher, und vergewissern Sie sich, dass diese Prozesse und Prozeduren Folgendes umfassen:

• Prozeduren zur Ausgabe neuer Ausweise, Änderung der Zutrittsanforderungen sowie Zurücknahme der Ausweise von Mitarbeitern, die nicht mehr dem Unternehmen angehören, und abgelaufener Besucherausweise

• Beschränkter Zugriff auf das Ausweissystem

9.2.b Überprüfen Sie durch Beobachtung von Personen am Standort, ob problemlos zwischen Mitarbeitern und Besuchern unterschieden werden kann.

9.3 Stellen Sie sicher, dass alle Besucher wie folgt behandelt werden:

9.3 Überprüfen Sie wie folgt, ob Mitarbeiter-/Besucherkontrollen durchgeführt 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.1 Beobachten Sie Besucher, um zu überprüfen, ob Besucherausweise verwendet werden. Versuchen Sie, sich Zutritt zum Datenzentrum zu verschaffen, um zu überprüfen, ob es mit einem Besucherausweis möglich ist, ohne Begleitung physische Bereiche zu betreten, in denen Karteninhaberdaten gespeichert werden.

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.2 Überprüfen Sie Mitarbeiter- und Besucherausweise, um sicherzustellen, dass sich Mitarbeiter und Besucher/Betriebsfremde mit ihrer Hilfe eindeutig voneinander unterscheiden lassen und Besucherausweise ablaufen.

9.3.3 Jeder Besucher wird aufgefordert, das physische Kennzeichen vor Verlassen des Gebäudes oder zum Ablaufdatum wieder

9.3.3 Beobachten Sie Besucher beim Verlassen des Gebäudes, um zu überprüfen, ob sie aufgefordert werden, ihren Ausweis




abzugeben. beim Verlassen oder bei Ablauf zurückzugeben.

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.4.a Überprüfen Sie, ob der physische Zugang zum Gebäude sowie zu Computerräumen und Datenzentren, in denen Karteninhaberdaten gespeichert oder übertragen werden, in einem Besucherprotokoll festgehalten wird.

9.4.b Vergewissern Sie sich, dass das Protokoll den Namen des Besuchers, die Firma, die er vertritt, und den Mitarbeiter, der den physischen Zugang genehmigt, enthält und mindestens drei Monate lang gespeichert wird.

9.5 Lagern Sie Sicherungsdatenträger an einem sicheren standortfernen Ort, z. B. einem alternativen bzw. Sicherungsstandort oder einem gewerblichen Lager.

9.5 Überprüfen Sie, ob der Lagerort für Sicherungsdatenträger sicher ist. Vergewissern Sie sich, dass die physische Sicherheit und die Feuersicherheit des standortfernen Datenträgerlagers regelmäßig durch Besuche überprüft werden.

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.6 Überprüfen Sie, ob die Verfahren zum Schutz von Karteninhaberdaten Kontrollen zur physischen Sicherung von Papier- und elektronischen Medien in Computerräumen und Datenzentren umfassen (einschließlich Belegen, Berichten in Papierform, Faxen, CDs und Datenträgern in Schreibtischen und an offenen Arbeitsplätzen sowie PC-Festplatten).

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 Überprüfen Sie, ob eine Richtlinie zur Kontrolle der Verteilung von Medien, die Karteninhaberdaten enthalten, vorhanden ist und alle (einschließlich der an einzelne Personen) verteilten Medien umfasst.

9.7.1 Klassifizieren Sie die Medien so, dass sie als vertraulich erkennbar sind.

9.7.1 Überprüfen Sie, ob alle Medien so klassifiziert werden, dass sie als vertraulich erkennbar sind.

9.7.2 Versenden Sie die Medien über einen sicheren Kurierdienst oder eine andere genau nachverfolgbare Übermittlungsmethode.

9.7.2 Überprüfen Sie, ob alle Mediensendungen an firmenexterne Ziele protokolliert und von der Geschäftsführung




genehmigt werden und über einen sicheren Kurierdienst oder ein anderes, nachverfolgbares Übermittlungsverfahren erfolgen.

9.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.8 Überprüfen Sie eine aktuelle und repräsentative Auswahl von Verfolgungsprotokollen für firmenexterne Mediensendungen an verschiedenen Tagen auf Verfolgungsdetails und ordnungsgemäße Genehmigung durch die Geschäftsführung.

9.9 Halten Sie in Bezug auf die Lagerung und Zugänglichkeit von Medien, die Karteninhaberdaten enthalten, strikte Kontrollen ein.

9.9 Beschaffen Sie sich die Richtlinie zur Kontrolle von Lagerung und Verwaltung von Papier- und elektronischen Medien und überprüfen Sie, ob sie regelmäßige Medieninventuren vorschreibt.

9.9.1 Inventarisieren Sie sämtliche Medien ordnungsgemäß, und vergewissern Sie sich, dass sie sicher gelagert werden.

9.9.1.a Beschaffen Sie sich das Medieninventarprotokoll, und überprüfen Sie, ob regelmäßige Medieninventuren durchgeführt werden. 9.9.1.a Überprüfen Sie die Prozesse, um sicherzustellen, dass Medien 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 Beschaffen Sie sich die Richtlinie zur regelmäßigen Vernichtung von Medien, und vergewissern Sie sich, dass sie alle Medien abdeckt, die Karteninhaberdaten enthalten. Führen Sie außerdem folgende Schritte aus:

9.10.1 Ausdrucke müssen geschreddert, verbrannt oder eingestampft werden.

9.10.1.a Überprüfen Sie, ob Ausdrucke gemäß ISO 9564-1 bzw. ISO 11568-3e geschreddert, verbrannt oder eingestampft werden.

9.10.1.b Überprüfen Sie die Lagercontainer, in denen zu vernichtende Informationen aufbewahrt werden, auf Sicherheit. Vergewissern Sie sich z. B., dass Container mit zu schredderndem Material durch ein Schloss vor unbefugtem Zugriff geschützt sind.




9.10.2 Elektronische Medien müssen bereinigt, entmagnetisiert, geschreddert oder auf sonstige Weise zerstört werden, damit Karteninhaberdaten nicht rekonstruiert werden können.

9.10.2 Überprüfen Sie, ob elektronische Medien mithilfe eines militärischen Löschprogramms bzw. durch Entmagnetisierung oder auf andere Weise unwiederbringlich zerstört werden.

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.1 Überprüfen Sie durch Beobachtung und Befragung des Systemadministrators, ob Überwachungspfade – u. a. für jedes verbundene drahtlose Netzwerk – eingerichtet und aktiviert sind.

10.2 Implementieren Sie für alle Systemkomponenten automatisierte Überwachungspfade, um folgende Ereignisse zu rekonstruieren:

10.2 Überprüfen Sie durch Befragungen und Untersuchung von Überwachungsprotokollen und Überwachungsprotokolleinstellungen, ob folgende Ereignisse in Systemaktivitätsprotokollen aufgezeichnet werden:

10.2.1 Sämtliche einzelne Zugriffe auf Karteninhaberdaten

10.2.1 Sämtliche einzelne Zugriffe auf Karteninhaberdaten

10.2.2 Sämtliche Aktionen, die mit root- oder Administratorberechtigungen ausgeführt werden

10.2.2 Aktionen, die mit root- oder Administratorberechtigungen ausgeführt werden




10.2.3 Zugriff auf sämtliche Überwachungspfade

10.2.3 Zugriff auf sämtliche Überwachungspfade

10.2.4 Ungültige Versuche logischen Zugriffs

10.2.4 Ungültige Versuche logischen Zugriffs

10.2 5 Verwendung von Identifizierungs- und Authentifizierungsmechanismen

10.2.5 Verwendung von Identifizierungs- und Authentifizierungsmechanismen

10.2.6 Initialisierung von Überwachungsprotokollen

10.2.6 Initialisierung von Überwachungsprotokollen

10.2.7 Erstellung und Löschung von Objekten auf Systemebene

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 Überprüfen Sie für jedes überwachbare Ereignis (siehe 10.2), ob im Überwachungspfad Folgendes festgehalten wird:

10.3.1 Benutzeridentifizierung 10.3.1 Benutzeridentifizierung

10.3.2 Ereignistyp 10.3.2 Ereignistyp

10.3.3 Datum und Uhrzeit 10.3.3 Datums- und Zeitstempel

10.3.4 Angabe von Erfolg oder Misserfolg 10.3.4 Angabe von Erfolg oder Misserfolg, u. a. für drahtlose Verbindungen

10.3.5 Ursprung des Ereignisses 10.3.5 Ursprung des Ereignisses

10.3.6 Identität bzw. Name der betroffenen Daten, Systemkomponente oder Ressource

10.3.6 Identität bzw. Name der betroffenen Daten, Systemkomponente oder Ressourcen

10.4 Synchronisieren Sie alle wichtigen Systemuhren und -zeiten.

10.4 Beschaffen Sie sich den Prozess für Abruf und Verteilung der richtigen Uhrzeit innerhalb der Organisation sowie die zeitrelevanten Systemparametereinstellungen, und überprüfen Sie anhand einer repräsentativen Auswahl von Systemkomponenten, kritischen Servern und drahtlosen Zugriffspunkten, ob folgende Maßnahmen in den Prozess eingeschlossen und implementiert sind:

10.4.a Überprüfen Sie, ob für die Zeitsynchronisierung NTP oder eine ähnliche Technologie verwendet wird.




10.4.b Vergewissern Sie sich, dass nicht alle internen Server Zeitsignale von externen Quellen empfangen. [Zwei oder drei zentrale Zeitserver in der Organisation empfangen externe Zeitsignale [direkt von einem Spezialsender, GPS-Satelliten oder anderen externen Quellen, die auf der Internationalen Atomzeit (TAI) und UTC (ehemals GMT) basieren], gleichen die Zeit miteinander ab und geben sie an andere interne Server weiter.]

10.4.c Überprüfen Sie, ob die aktuelle NTP (Network Time Protocol)-Version ausgeführt wird.

10.4.d Überprüfen Sie, ob die Zeitserver NTP-Zeitaktualisierungen nur von bestimmten externen Hosts beziehen (um Hacker daran zu hindern, die Uhr zu ändern). Wahlweise können diese Aktualisierungen mit einem symmetrischen Schlüssel verschlüsselt und Zugriffssteuerungslisten erstellt werden, in denen die IP-Adressen von Clientcomputern angegeben sind, für die der NTP-Dienst bereitgestellt wird (um die unautorisierte Verwendung von internen Zeitservern zu verhindern). Weitere Informationen finden Sie unter www.ntp.org.

10.5 Sichern Sie Überwachungspfade so, dass sie nicht geändert werden können.

10.5 Befragen Sie den Systemadministrator, und überprüfen Sie Berechtigungen, um sicherzustellen, dass Überwachungspfade so gesichert werden, dass sie nicht geändert werden können. Gehen Sie dazu wie folgt vor:

10.5.1 Beschränken Sie die Anzeige von Überwachungspfaden auf Personen, die sie aufgrund ihrer Arbeitsaufgaben benötigen.

10.5.1 Vergewissern Sie sich, dass nur Personen mit aufgaben- bzw. tätigkeitsbezogenem Bedarf Überwachungspfaddateien anzeigen können.

10.5.2 Schützen Sie Überwachungspfaddateien vor unbefugten Änderungen.

10.5.2 Überprüfen Sie, ob aktuelle Überwachungspfaddateien durch Zugriffssteuerungsmechanismen, physische Trennung und/oder Netzwerktrennung vor unbefugten Änderungen geschützt sind.

10.5.3 Sichern Sie 10.5.3 Überprüfen Sie, ob aktuelle




Überwachungspfaddateien in kurzen Intervallen auf einem zentralen Protokollserver oder -datenträger, der nur schwer geändert werden kann.

Überwachungspfaddateien in kurzen Intervallen auf einem zentralen Protokollserver oder -datenträger gesichert werden, 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.4 Überprüfen Sie, ob Protokolle für drahtlose Netzwerke auf einen zentralen internen Protokollserver oder -datenträger verschoben bzw. kopiert werden, der nur schwer geändert werden kann.

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.5.5 Überprüfen Sie anhand von Systemeinstellungen, überwachten Dateien und Ergebnissen von Überwachungsaktivitäten, ob für Protokolle Software zur Überwachung der Dateiintegrität oder zur Änderungserkennung verwendet wird.

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 können Harvesting-, Analyse- und Warntools für Protokolle verwendet werden.

10.6.a Beschaffen Sie sich die Sicherheitsrichtlinien und -prozeduren, und überprüfen Sie, ob sie Verfahren enthalten, die eine mindestens tägliche Überprüfung von Sicherheitsprotokollen und die Untersuchung von Ausnahmen vorsehen.

10.6.b Stellen Sie anhand von Beobachtungen und Befragungen fest, ob die Protokolle aller Systemkomponenten regelmäßig überprüft werden.

10.7 Der Überwachungspfadverlauf muss mindestens ein Jahr lang aufbewahrt werden und mindestens drei Monate online verfügbar sein.

10.7.a Beschaffen Sie sich die Sicherheitsrichtlinien und -prozeduren, und überprüfen Sie, ob sie Richtlinien zur Aufbewahrung von Überwachungsprotokollen enthalten und die Aufbewahrung von Protokollen für mindestens ein Jahr vorsehen.

10.7.b Überprüfen Sie, ob Überwachungsprotokolle mindestens ein Jahr lang online oder auf Band verfügbar sind.


Anforderung 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.1.a Vergewissern Sie sich durch Befragung von Sicherheitspersonal und Überprüfung von relevantem Code, Dokumentation und Prozessen, dass Geräte Sicherheitstests unterzogen werden, um sicherzustellen, dass unbefugte Zugriffsversuche innerhalb der Karteninhaber-Datenumgebung durch entsprechende Kontrollen erkannt und unterbunden werden.

11.1.b Überprüfen Sie, ob mindestens vierteljährlich ein Analyseprogramm für drahtlose Netzwerke eingesetzt wird, 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

11.2.a Überprüfen Sie die Ergebnisse der letzten vier vierteljährlichen Netzwerk-, Host- und Anwendungs-Schwachstellenscans, um sicherzustellen, dass die Geräte innerhalb der Karteninhaber-Datenumgebung regelmäßig auf Sicherheitsrisiken überprüft werden. Vergewissern Sie sich, dass die Überprüfungen so oft wiederholt werden, bis ein zufrieden stellendes Ergebnis erzielt wird.




Zahlungskartenbranche zertifizierten Anbieter durchgeführt werden. Überprüfungen, die nach Netzwerkänderungen erfolgen, können von Mitarbeitern des Unternehmens durchgeführt werden.

11.2.b Um sicherzustellen, dass vierteljährlich eine externe Überprüfung in Übereinstimmung mit den PCI Security Scanning Procedures erfolgt, überprüfen Sie die Ergebnisse der letzten vier vierteljährlichen externen Schwachstellenscans auf Folgendes:

• In den letzten 12 Monaten wurden vier vierteljährliche Überprüfungen durchgeführt.

• Die Ergebnisse der einzelnen Überprüfungen entsprechen den PCI Security Scanning Procedures (z. B. keine dringenden, kritischen oder hohen Sicherheitsrisiken)

• Die Überprüfungen wurden von einem für die PCI Security Scanning Procedures zertifizierten Hersteller durchgeführt.

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 Beschaffen Sie sich die Ergebnisse des letzten Penetrationstests, und überprüfen Sie, ob ein solcher Test mindestens jährlich sowie nach größeren Änderungen an der Umgebung durchgeführt wird. Vergewissern Sie sich, dass alle erkannten Sicherheitsrisiken beseitigt wurden. Überprüfen Sie, ob die Penetrationstests Folgendes umfassen:

11.3.1 Penetrationstests auf der Netzwerkebene 11.3.1 Penetrationstests auf der Netzwerkebene

11.3.2 Penetrationstests auf der Anwendungsebene

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

11.4.a Beobachten Sie die Verwendung von IDS und/oder IPS zur Erkennung bzw. Verhinderung von Angriffen auf das Netzwerk. Überprüfen Sie, ob sämtlicher kritischer Netzwerkdatenverkehr in der Karteninhaberdaten-Umgebung überwacht wird.




warnen. Sorgen Sie dafür, dass alle IDS- und IPS-Programme auf dem neuesten Stand sind.

11.4.b Vergewissern Sie sich, dass zur Überwachung IDS und/oder IPS eingesetzt werden, um Mitarbeiter bei vermuteten Gefährdungen zu warnen.

11.4.c Überprüfen Sie die IDS-/IPS-Konfigurationen und vergewissern Sie sich, dass IDS-/IPS-Vorrichtungen gemäß den Anweisungen des Herstellers konfiguriert, verwaltet und aktualisiert werden, um optimalen Schutz zu gewährleisten.




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.

11.5 Überprüfen Sie anhand von Systemeinstellungen, überwachten Dateien und Ergebnissen von Überwachungsaktivitäten, ob innerhalb der Karteninhaberdaten-Umgebung Produkte zur Überwachung der Dateiintegrität verwendet werden.

Verwalten 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

12.1 Überprüfen Sie die Informationssicherheitsrichtlinie, und vergewissern




folgendem Inhalt: Sie sich, dass sie für alle relevanten Systembenutzer veröffentlicht und verbreitet wird (einschließlich Herstellern, Auftragnehmern und Geschäftspartnern).

12.1.1 Erfüllung aller Anforderungen in dieser Spezifikation

12.1.1 Überprüfen Sie, ob die Richtlinie alle Anforderungen in dieser Spezifikation erfüllt.

12.1.2 Jährlicher Prozess zur Ermittlung von Bedrohungen und Sicherheitsrisiken mit anschließender formeller Risikobewertung

12.1.2 Überprüfen Sie, ob die Informationssicherheitsrichtlinie einen jährlichen Prozess zur Ermittlung von Bedrohungen und Sicherheitsrisiken mit anschließender formeller Risikobewertung umfasst.

12.1.3 Mindestens einmal pro Jahr stattfindende Überprüfung und Aktualisierungen, wenn Umgebungsänderungen auftreten

12.1.3 Überprüfen Sie, ob die Informationssicherheitsrichtlinie mindestens einmal pro Jahr überprüft und ggf. aktualisiert wird, um Änderungen an Geschäftszielen oder der Risikoumgebung Rechnung zu tragen.

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.2.a Überprüfen Sie die täglichen betrieblichen Sicherheitsprozeduren. Vergewissern Sie sich, dass sie dieser Spezifikation entsprechen und administrative und technische Prozeduren für die einzelnen Anforderungen umfassen.

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 Beschaffen Sie sich die Richtlinie für wichtige von Mitarbeitern genutzte Technologien, und überprüfen Sie, ob sie Folgendes umfasst:

12.3.1 Ausdrückliche Genehmigung der Geschäftsführung

12.3.1 Überprüfen Sie, ob die Nutzungsrichtlinien eine ausdrückliche Genehmigung der Geschäftsführung für die Verwendung der Geräte erfordern.

12.3.2 Authentifizierung für die Nutzung der Technologie

12.3.2 Überprüfen Sie, ob die Nutzungsrichtlinien für jede Gerätenutzung eine Authentifizierung mit Benutzernamen und




Kennwort oder einem anderen Authentifizierungselement (z. B. Token) erfordern.

12.3.3 Liste aller entsprechenden Geräte und Mitarbeiter mit Zugriff

12.3.3 Überprüfen Sie, ob die Nutzungsrichtlinien eine Liste aller Geräte und der zur Nutzung der Geräte autorisierten Mitarbeiter erfordern.

12.3.4 Kennzeichnung der Geräte mit Besitzer, Kontaktdaten und Zweck

12.3.4 Überprüfen Sie, ob die Nutzungsrichtlinien eine Kennzeichnung der Geräte mit Besitzer, Kontaktdaten und Zweck erfordern.

12.3.5 Akzeptable Verwendungszwecke der Technologie

12.3.5 Überprüfen Sie, ob die Nutzungsrichtlinien akzeptable Verwendungszwecke für die Technologie erfordern.

12.3.6 Akzeptable Netzwerkpfade für die Technologien

12.3.6 Überprüfen Sie, ob die Nutzungsrichtlinien akzeptable Netzwerkpfade für die Technologie erfordern.

12.3.7 Liste der vom Unternehmen genehmigten Produkte

12.3.7 Überprüfen Sie, ob die Nutzungsrichtlinien eine Liste der vom Unternehmen genehmigten Produkte erfordern.

12.3.8 Automatische Trennung von Modemsitzungen nach einem bestimmten Zeitraum der Inaktivität

12.3.8 Überprüfen Sie, ob die Nutzungsrichtlinien erfordern, dass Modemsitzungen nach einem bestimmten Zeitraum der Inaktivität automatisch getrennt werden.

12.3.9 Aktivierung von Modems für Hersteller, wenn sie von Herstellern benötigt werden, mit anschließender sofortiger Deaktivierung

12.3.9 Überprüfen Sie, ob die Nutzungsrichtlinien erfordern, dass von Herstellern verwendete Modems aktiviert werden, wenn sie von Herstellern benötigt werden, und anschließend sofort deaktiviert werden.

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

12.3.10 Überprüfen Sie, ob die Nutzungsrichtlinien das Speichern von Karteninhaberdaten auf lokalen Festplatten, Disketten oder anderen Wechseldatenträgern während des Remotezugriffs per Modem




zum Ausschneiden und Einfügen sowie der Druckfunktionen während des Remotezugriffs.

untersagen. Vergewissern Sie sich, dass die Richtlinien die Funktionen zum Ausschneiden und Einfügen sowie die Druckfunktionen während des Remotezugriffs untersagen.

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.4 Überprüfen Sie, ob die Verantwortung von Mitarbeitern 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 Überprüfen Sie, ob ein leitender Sicherheitsbeauftragter oder ein anderes in Sicherheitsfragen bewandertes Mitglied der Geschäftsführung formell mit der Informationssicherheit betraut wurde. Beschaffen Sie sich die Informationssicherheitsrichtlinien und -prozeduren, um sicherzustellen, dass die folgenden Verantwortlichkeiten für Informationssicherheit spezifiziert und formell zugewiesen wurden:

12.5.1 Einrichtung, Dokumentation und Verteilung von Sicherheitsrichtlinien und -prozeduren

12.5.1 Überprüfen Sie, ob die Verantwortung für die Erstellung und Verteilung von Sicherheitsrichtlinien und -prozeduren formell zugewiesen wurde.

12.5.2 Überwachung und Analyse von Sicherheitswarnungen und -informationen und Weiterleitung an entsprechendes Personal

12.5.2 Überprüfen Sie, ob die Verantwortung für die Überwachung und Analyse von Sicherheitswarnungen und die Verteilung von Informationen an entsprechende Informationssicherheitsmitarbeiter und Abteilungsleiter formell zugewiesen wurde.

12.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.3 Überprüfen Sie, ob die Verantwortung für die Erstellung und Verteilung von Reaktions- und Eskalationsprozeduren bei sicherheitsrelevanten Zwischenfällen formell zugewiesen wurde.

12.5.4 Verwaltung von Benutzerkonten, einschließlich Hinzufügungen, Löschungen

12.5.4 Überprüfen Sie, ob die Verantwortung für die Verwaltung von Benutzerkonten und




und Änderungen Authentifizierung formell zugewiesen wurde. 12.5.5 Überwachung und Steuerung sämtlicher Datenzugriffe

12.5.5 Überprüfen Sie, ob die Verantwortung für die Überwachung und Steuerung sämtlicher Datenzugriffe formell zugewiesen wurde.

Implementieren Sie ein formelles Sicherheitsschulungsprogramm, um allen Mitarbeitern die Bedeutung der Sicherheit von Karteninhaberdaten bewusst zu machen:

12.6.a Überprüfen Sie, ob ein formelles Sicherheitsschulungsprogramm für alle Mitarbeiter vorhanden ist.

12.6.b Beschaffen Sie sich die Prozeduren und Dokumentation zum Sicherheitsschulungsprogramm, und überprüfen Sie sie wie folgt:

12.6.1 Schulung von Mitarbeitern bei Einstellung und mindestens einmal pro Jahr (z. B. durch Rundschreiben, Poster, Memos, Besprechungen und Aktionen)

12.6.1.a Überprüfen Sie, ob das Sicherheitsschulungsprogramm mehrere Methoden für die Vermittlung von Sicherheitsbewusstsein und die Schulung von Mitarbeitern bietet (z. B. Poster, Rundschreiben, Besprechungen).

12.6.1.b Überprüfen Sie, ob die Mitarbeiter bei Einstellung und mindestens einmal pro Jahr an einer Sicherheitsschulung teilnehmen.

12.6.2 Schriftliche Bestätigung der Mitarbeiter, dass sie die Sicherheitsrichtlinien und -prozeduren des Unternehmens gelesen und verstanden haben

12.6.2 Überprüfen Sie, ob das Sicherheitsschulungsprogramm eine schriftliche Bestätigung von den Mitarbeitern verlangt, 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.7 Erkundigen Sie sich bei der Leitung der Personalabteilung, ob (im Rahmen der geltenden Gesetzgebung) der Hintergrund potenzieller Mitarbeiter überprüft wird, die Zugriff auf Karteninhaberdaten oder die Karteninhaberdaten-Umgebung erhalten. (Beispiele für Hintergrundüberprüfungen: vorherige Tätigkeiten, eventuelle Vorstrafen, Kreditgeschichte und Überprüfung von Referenzen)

12.8 Wenn Karteninhaberdaten mit Dienstanbietern ausgetauscht werden, ist

12.8 Wenn die überprüfte Entität Karteninhaberdaten mit einem anderen




folgende vertragliche Regelung erforderlich: Unternehmen austauscht, beschaffen Sie sich die Verträge zwischen der Organisation und dem Karteninhaberdaten verarbeitenden Dritten (z. B. Lagereinrichtungen für Sicherungsbänder, Managed Service-Anbieter, wie Webhosting-Unternehmen, Sicherheitsdienstanbieter oder Unternehmen, die Daten zur Betrugsmodellierung benötigen), und überprüfen Sie sie. Gehen Sie wie folgt vor:

12.8.1 Dienstanbieter müssen die Anforderungen des PCI DSS erfüllen.

12.8.1 Überprüfen Sie, ob der Vertrag Bestimmungen zur Einhaltung der Anforderungen des PCI DSS enthält.

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.8.2 Überprüfen Sie, ob der Vertrag Bestimmungen zur Bestätigung der Verantwortung des Dritten für die Sicherung von Karteninhaberdaten umfasst.

12.9 Implementieren Sie einen Incident-Response-Plan. Bei Sicherheitsverletzungen müssen Sie sofort reagieren können.

12.9 Beschaffen Sie sich den Incident-Response-Plan und die zugehörigen Prozeduren, und führen Sie folgende Schritte aus:

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.1 Überprüfen Sie, ob der Incident-Response-Plan und die zugehörigen Prozeduren Folgendes umfassen:

• Aufgaben, Verantwortlichkeiten und Kommunikationsstrategien für den Fall einer Sicherheitsgefährdung

• Absicherung und Reaktionen für alle entscheidenden Systemkomponenten

• Benachrichtigung zumindest von Kreditkartengesellschaften und Händlerbanken

• Strategie für die Kontinuität des Geschäftsbetriebs nach der Sicherheitsgefährdung

• Bezugnahme auf bzw. Aufnahme von Incident-Response-Prozeduren von Kartengesellschaften

• Analyse von Rechtsvorschriften zur Meldung von Sicherheitsgefährdungen




(Beispiel: Nach dem kalifornischen Gesetzentwurf 1386 müssen alle Unternehmen, deren Datenbanken in Kalifornien wohnhafte Personen enthalten, betroffene Verbraucher bei tatsächlichen oder vermuteten Sicherheitsgefährdungen benachrichtigen).

12.9.2 Testen Sie den Plan mindestens einmal pro Jahr.

12.9.2 Überprüfen Sie, ob der Plan mindestens einmal pro Jahr getestet wird.

12.9.3 Sorgen Sie dafür, dass rund um die Uhr Mitarbeiter zur Verfügung stehen, um auf Warnungen zu reagieren.

12.9.3 Überprüfen Sie anhand von Beobachtungen und durch Überprüfung der Richtlinien, ob rund um die Uhr Mitarbeiter zur Überwachung zur Verfügung stehen, um auf nicht autorisierte Aktivitäten, kritische IDS-Warnungen und/oder Meldungen von nicht autorisierten Änderungen an wichtigen System- oder Inhaltsdateien reagieren zu können.

12.9.4 Lassen Sie die Mitarbeiter, die für die Reaktion auf Sicherheitsverletzungen zuständig sind, entsprechend ausbilden.

12.9.4 Überprüfen Sie anhand von Beobachtungen und durch Überprüfung der Richtlinien, ob für Sicherheitsverletzungen zuständige Mitarbeiter regelmäßig geschult werden.

12.9.5 Schließen Sie Warnungen aus IDS, IPS und Systemen zur Überwachung der Dateiintegrität ein.

12.9.5 Überprüfen Sie anhand von Beobachtungen und durch Überprüfung von Prozessen, ob der Incident-Response-Plan die Überwachung und Alarmreaktion von Sicherheitssystemen umfasst.

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.9.6 Überprüfen Sie anhand von Beobachtungen und durch Überprüfung der Richtlinien, ob ein Prozess zur Änderung und Weiterentwicklung des Incident-Response-Plans unter Berücksichtigung von gewonnenen Erkenntnissen und Entwicklungen in der Branche vorhanden ist.

12.10 Alle Prozessoren und Dienstanbieter müssen Richtlinien und Prozeduren zur Verwaltung verbundener Entitäten pflegen und

12.10 Überprüfen Sie anhand von Beobachtungen und durch Überprüfung von Richtlinien, Prozeduren und begleitender




umsetzen, die Folgendes umfassen: Dokumentation, ob ein Prozess zur Verwaltung verbundener Entitäten vorhanden ist. Gehen Sie dazu wie folgt vor:

12.10.1 Verwaltung einer Liste von verbundenen Entitäten

12.10.1 Überprüfen Sie, ob eine Liste von verbundenen Entitäten verwaltet wird.

12.10.2 Sicherstellung einer Sorgfaltsprüfung vor Herstellung einer Verbindung mit einer Entität

12.10.2 Überprüfen Sie, ob Prozeduren vorhanden sind, die die Durchführung einer Sorgfaltsprüfung sicherstellen, bevor eine Verbindung mit einer Entität hergestellt wird.

12.10.3 Sicherstellung der Konformität der Entität mit dem PCI DSS

12.10.3 Überprüfen Sie, ob die Entität dem PCI DSS entspricht.

12.10.4 Verbindung und Trennung von Entitäten nach einem festgelegten Verfahren

12.10.4 Überprüfen Sie, ob die Verbindung und Trennung von Entitäten nach einem festgelegten Verfahren erfolgt.


Anhang A: Anwendbarkeit des PCI DSS für Hosting-Anbieter (mit Testverfahren) 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:

Anforderungen Testverfahren Vorhanden Nicht vorhanden

Zieldatum/ Anmerkungen

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: 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 gewährleistet. Jede Entität muss den PCI DSS erfüllen und ihre Konformität entsprechend nachweisen.

A.1 Um bei PCI-Audits von Shared Hosting-Anbietern sicherzustellen, dass diese die gehosteten Umgebungen und Daten von Entitäten (Händler und Dienstanbieter) schützen, überprüfen Sie anhand einer Stichprobe von Servern (Microsoft Windows und UNIX/Linux) einer repräsentativen Auswahl von gehosteten Händlern und Dienstanbietern die Erfüllung der unten stehenden Anforderungen 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.1 Wenn ein Shared Hosting-Anbieter Entitäten (z. B. Händler oder Dienstanbieter) gestattet, eigene Anwendungen auszuführen, überprüfen Sie, ob diese Anwendungsprozesse unter Verwendung der eindeutigen ID der Entität ausgeführt werden. Beispiel:

• Keine Entität auf dem System darf eine gemeinsame Webserverbenutzer-ID verwenden.

• Alle von einer Entität verwendeten Skripts müssen als eindeutige Benutzer-ID der Entität erstellt und ausgeführt werden.

A.1.2 Beschränken Sie Zugriff und Berechtigungen jeder Entität auf die eigene Karteninhaberdaten-Umgebung.

A.1.2.a Vergewissern Sie sich, dass die Benutzer-ID der einzelnen Anwendungsprozesse kein privilegierter Benutzer (root/admin) ist.




A.1.2.b Überprüfen Sie, ob die einzelnen Entitäten (Händler, Dienstanbieter) nur für eigene Dateien und Verzeichnisse bzw. für erforderliche Systemdateien (beschränkt durch Dateisystemberechtigungen, Zugriffssteuerungslisten, chroot, JailShell usw.) Lese-, Schreib- oder Ausführungsberechtigungen besitzen. WICHTIG: Die Dateien von Entitäten dürfen nicht von Gruppen gemeinsam genutzt werden.

A.1.2.c Vergewissern Sie sich, dass die Benutzer von Entitäten keinen Schreibzugriff auf gemeinsam genutzte Systembinärdateien besitzen.

A.1.2.d Stellen Sie sicher, dass das Anzeigen von Protokolleinträgen auf die Entität beschränkt ist, die ihr Besitzer ist.

A.1.2.e Um sicherzustellen, dass keine Entität Serverressourcen belegen kann, um Schwachstellen auszunutzen (Fehler-, Race- und Neustartbedingungen, die z. B. zu Pufferüberläufen führen), überprüfen Sie, ob es für die Verwendung der folgenden Systemressourcen Beschränkungen gibt:

• Festplattenspeicher • Bandbreite • Arbeitsspeicher • CPU

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.3.a Überprüfen Sie, ob der Shared Hosting-Anbieter für jede Händler- und Dienstanbieterumgebung die Protokollierung wie folgt aktiviert hat:

• Protokolle sind für häufig verwendete Drittanbieteranwendungen aktiviert

• Protokolle sind standardmäßig aktiviert • Protokolle stehen der Entität, die ihr Besitzer ist,

zur Überprüfung zur Verfügung • Protokollpfade werden der Entität, die ihr

Besitzer ist, eindeutig mitgeteilt

A.1.4 Aktivieren Sie Prozesse zur zeitnahen Einleitung einer kriminaltechnischen

A.1.4 Überprüfen Sie, ob der Shared Hosting-Anbieter über schriftliche Richtlinien für eine zeitnahe




Untersuchung im Fall einer Sicherheitsgefährdung eines gehosteten Händlers oder Dienstanbieters

kriminaltechnische Untersuchung relevanter Server im Fall einer Sicherheitsgefährdung verfügt.

Sicherheitsprüfungsverfahren, Version 1.1 66

Anhang 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).

Anhang C: Arbeitsblatt für Ersatzkontrollen mit Beispiel Beispiel

1. Einschränkungen: Listen Sie Einschränkungen auf, die eine Konformität mit der ursprünglichen Anforderung ausschließen.

2. Ziel: Definieren Sie das Ziel der ursprünglichen Kontrolle. Identifizieren Sie das von der Ersatzkontrolle erreichte Ziel.

3. Identifiziertes Risiko: Identifizieren Sie weitere Risiken, die durch das Fehlen der ursprünglichen Kontrolle entstehen.

Das Ziel, eindeutige Anmeldungen zu verlangen, hat zwei Gründe. Zum einen ist es aus Sicherheitsgründen nicht akzeptabel, Anmeldeinformationen gemeinsam zu nutzen. Zum anderen kann bei gemeinsam genutzten Anmeldeinformationen nicht definitiv nachvollzogen werden, wer für eine bestimmte Aktion verantwortlich ist.

Da nicht sichergestellt werden kann, dass alle Benutzer eine eindeutige ID haben und verfolgt werden können, wird das Zugriffssteuerungssystem einem zusätzlichen Risiko ausgesetzt.

Unternehmen XYZ setzt eigenständige UNIX-Server ohne LDAP ein. Sie erfordern somit eine root-Anmeldung. Unternehmen XYZ ist nicht in der Lage, die root- Anmeldung zu verwalten oder alle root-Aktivitäten der einzelnen Benutzer zu protokollieren.


4. Definition von Ersatzkontrollen: Definieren Sie die Ersatzkontrollen und erläutern Sie, wie sie die Ziele der ursprünglichen

Kontrolle erreichen und ggf. dem erhöhten Risiko entgegenwirken.

Unternehmen XYZ verlangt von allen Benutzern, sich vom Desktop aus mit dem SU-Befehl bei den Servern anzumelden. Mit SU können Benutzer auf das root-Konto zugreifen und Aktionen unter dem root-Konto ausführen, sind dabei aber im su-log-Verzeichnis angemeldet. Auf diese Weise können die Aktionen jedes Benutzers über das SU-Konto verfolgt werden.

Payment Card Industry Data Security Standard (PCI DSS) filePayment Card Industry Data Security...

Documents

Transcript of Payment Card Industry Data Security Standard (PCI DSS) filePayment Card Industry Data Security...