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