Bevor es losgeht, laden Sie sich am besten gleich das PDF mit der PCI Compliance-Checkliste herunter und richten sich nach den Empfehlungen!
Inhaltsverzeichnis
Übersicht
PCI DSS-Compliance ist eine Anforderung an alle Unternehmen, die Daten/Informationen von Karteninhabern speichern, verarbeiten oder übermitteln. Dabei ist es nicht ganz leicht, sich einen Überblick über hunderte von Seiten und Unteranforderungen zu verschaffen, die das Security Standards Council (SSC) vorgibt. Berücksichtigt man dann noch die Versions-Updates hat man einen entsprechenden Berg vor sich.
Lassen Sie sich davon nicht aus der Ruhe bringen.
Dieser Leitfaden sowie die dazugehörige Checkliste helfen Ihnen auf dem Weg zur PCI DSS 3.2-Compliance. Hier bekommen Sie genauere Informationen zu den Änderungen, die das Update 3.2 bereit hält, zu den 12 PCI-Compliance-Anforderungen und zu einer Reihe von „Do’s and Dont’s“ bei der eigentlichen Umsetzung.
PCI DSS 3.2: Sich wandelnde Anforderungen – Überprüfung von Risikoprioritäten auf höchster Ebene
PCI DSS 3.2 hat mit dem letzten Update mehrere Änderungen und Erläuterungen eingeführt. Wir versuchen an dieser Stelle die Neuerungen aus der Vogelperspektive zu diskutieren.
Neue Compliance-Fristen – Bereiten Sie schon mal den Kalender vor
1. November 2016
Am 1. November 2016 wird PCI DSS 3.1 als Standard aufgehoben. Von diesem Datum an basieren alle Bewertungen auf 3.2.
1. Februar 2018
In der Version 3.2 sind zahlreiche Änderungen und sich wandelnde Anforderungsprofile definiert (siehe weiter unten). Die zusätzlichen Anforderungen gelten bis zum 1. Februar 2018 als Best-Practice und werden nach dem Stichtag zur Compliance-Anforderung.
1. Juli 2018
Schon jetzt sind die SSL- und TLS-Versionen 1.0 oder früher nicht länger geschützte Sicherheitsprotokolle. Die Anwendung aktualisierter Protokolle gilt bis zum 1. Juli 2018 als Best-Practice und wird danach zur Anforderung. Hinweis* – PCI DSS 3.1 hatte bisher eine Frist bis zum 30. Juni 2016 vorgegeben. Diese ist aber für 3.2 verlängert worden.
DO:
- Migrieren Sie schnellstmöglich auf eine aktuelle Version des TLS-Sicherheitsprotokolls.
DON’T:
- Warten Sie nicht bis zum 1. Juli 2018 bis Sie Änderungen vornehmen. Obwohl es noch keine Nicht-Compliance bedeutet, SSL/frühe TLS-Versionen 2016/2017 beizubehalten, ist das PCI Security Standards Council zu dem Schluss gekommen, dass diese Protokolle nicht länger als sicher gelten. Warum also einen Verstoß riskieren?
Mehrfaktor-Authentifizierung für Jeden (8.3)
PCI DSS 3.2 hat die ursprünglich geforderte Zweifaktor-Authentifizierung auf eine Mehrfaktor-Authentifizierung erweitert. Darüber hinaus ist die Anforderung nicht länger auf Remote tätige Mitarbeiter beschränkt, sondern sie gilt für alle Personen, die extern mit Admin-Zugriff auf die Umgebung zugreifen, in der Karteninhaberinformationen (Cardholder Data Environment, CDE) vorgehalten werden. Und zwar ungeachtet vom jeweiligen Standort.
Um Compliance zu gewährleisten, müssen Sie mindestens zwei der folgenden Authentifizierungsmethoden auswählen:
- Etwas, das Sie wissen, wie ein Passwort oder eine Passphrase
- Etwas, das Sie haben, wie einen Token oder eine Smart-Card
- Etwas, das Sie sind, wie ein Fingerabdruck oder ein Netzhaut-Scan
PAN-Maskierung und Transparenz (3.3)
PCI DSS 3.2 gibt vor, dass die PANs (Primary Account Numbers) bei der Anzeige maskiert sein müssen, so dass maximal die ersten sechs und die letzten vier Zeichen sichtbar sind. Darüber hinaus muss eine Liste aller Rollen erstellt werden. Inklusive einer Begründung, wenn Mitarbeiter mehr als die maskierten PAN-Zeichen sehen sollen.
DO:
- Prüfen Sie, ob striktere Anforderungen nicht die oben definierte PAN-Maskierung aufheben (z. B. Kartenanbieter, die die PAN-Maskierung für Verkaufsstellenbelege beschränken).
DON’T:
- Machen Sie nicht die maximale Anzahl der ersten und letzten Zeichen (6 & 4) sichtbar, wenn das geschäftlich nicht erforderlich ist.
- Lösung: Bestimmen Sie die minimalen Zahl von PAN-Zeichen, die Sie in ihrem Unternehmen brauchen und maskieren Sie die verbleibenden.
Striktere Anforderungen an Serviceprovider bei Reportings
PCI DSS 3.2 führt eine Reihe neuer Anforderungen für Serviceprovider ein und integriert zusätzlich die „Designated Entities Supplemental Validation (DESV)“ (Zusatzvalidierung für spezielle Instanzen) in einem Anhang. Und genau hier ist der Haken –Die Kreditkartenanbieter (also die verschiedenen Kreditkartenmarken) bestimmen, wann ein Serviceprovider die zusätzliche Bewertung nach DESV erfüllen muss.
Das wichtigste zuerst – worauf sollten alle Serviceprovider achten?
DO:
- Klären Sie mit Ihren Mitarbeitern, ob die kryptografische Architektur dokumentiert ist, ob die implementierten Sicherheitskontrollen ein kritisches Systemversagen erkennen und ob anschließend die betroffenen Dateneigentümer informiert werden. (3.5.1, 10.8)
- Führen Sie einen Prozess ein, der Änderungsmanagement und Änderungen am System regelt sowie deren Auswirkungen auf die PCI DSS-Anforderungen dokumentiert. (6.4.6)
- Sollten die Sicherheitskontrollen versagen, ergreifen Sie rechtzeitig Gegenmaßnahmen und dokumentieren Sie die Ausfallzeiten, die Ursache, die Ergebnisse aus der Risikobewertung und die überarbeiteten Kontrollmechanismen, um solche Vorkommnisse zukünftig zu verhindern. (10.8.1)
- (Wenn Sie eine Segmentierung verwenden) Führen Sie für die Segmentierungskontrollen Penetrationstests bei allen signifikanten Änderungen durch, mindestens jedoch alle 6 Monate. (11.3.4,1)
- Führen Sie vierteljährliche Prüfungen (mindestens) durch, um zu verifizieren, dass das Personal die Sicherheitsrichtlinien und Verfahren befolgt. (12.11)
*Hinweis: PCI DSS 3.2 definiert: wer seitens des Personals über tägliche Protokollprüfungen geprüft werden muss, die Überprüfung der Firewall-Regelsätze, die Anwendung von Konfigurationsstandards für neue Systeme, Reaktionen auf Sicherheitsmeldungen und die Konformität beim Ändern von Managementprozessen.
- Dokumentieren Sie vierteljährliche Prüfungsergebnisse, einschließlich der Unterschriften des für die PCI DSS Compliance verantwortlichen Personals. (12.11.1)
- Stellen Sie sicher, dass die Geschäftsführung die Verantwortung für den Schutz der Karteninhaberinformation und die PCI DSS 3.2 Compliance eindeutig festlegt, einschließlich einer schriftlichen Verantwortungsbestätigung aller Serviceprovider. (12.4.1, 12.8.2)
Was heißt es, wenn ein Erwerber oder Kreditkartenanbieter festlegen, dass ein Serviceprovider eine zusätzliche DESV-Bewertung benötigt?
Die DESV bietet die zusätzliche Sicherheit, dass ein Serviceprovider die PCI DSS-Kontrollen regelmäßig und effizient umsetzt. Die fünf in der DESV definierten Validierungsschritte, ähneln stark den Anforderungen an neue Serviceprovider: Umsetzen des PCI DSS-Programms, Zugriffskontrollen für das CDE etc. Die DESV kann man in etwa als den „überfürsorglichen Elternteil“ im Gegensatz zum eher „entspannten Elternteil“ der PCI DSS verstehen. Die DESV führt Sie durch sämtliche Schritte beim Aufbau eines PCI DSS Compliance-Programms und prüft kontinuierlich, ob die Initiativen umgesetzt werden, bis hin zur Berichterstattung von Sitzungsprotokollen.
Sie können über die PCI SSC Seite auf die vollständige DESV zugreifen.
PCI 12-Programm – Die Anforderungen im Überblick
PCI DSS definiert die Anforderungen in 12 umfassenden Schritten. Das klingt zunächst nicht besonders kompliziert. Wenn man allerdings erst einmal auf Seite 139 in Schriftgröße 10 angekommen ist, wird man sich garantiert fragen „Was habe ich da eigentlich gerade gelesen?“
Wir gehen daher zunächst einen Schritt zurück und versuchen, diese Anforderungen in übersichtlicheren Kategorien zusammenzufassen. Nämlich auf Grundlage von vier Verteidigungsstrategien, die Sie per Checkliste abarbeiten können. Wir empfehlen den Download unseres kostenlosen Checklisten-PDF, damit Sie selbst Ihre Fortschritte bei der Umsetzung kontrollieren können.
Schutz der Daten von Karteninhabern
Der erste Schritt ist offensichtlich. Hier geht es ausschließlich um Kreditkarteninformationen, sodass wir uns zunächst mit dem Schutz dieser Daten befassen, bevor wir uns der Umgebung zuwenden, in der diese Daten vorgehalten werden.
Anwendbare DSS-Anforderungen:
DSS-Anforderung 3 – Schützen Sie gespeicherte Karteninhaberdaten
DO:
- Implementieren Sie dokumentierte Richtlinien zur Datenaufbewahrung und Entsorgung sowie zur Minimierung der erfassten Daten sowie für die Dauer der Aufbewahrung. (3.1)
- Befragen Sie Ihre Mitarbeiter um sich zu versichern, ob die Richtlinien eingehalten werden. Stellen Sie sicher, dass vierteljährlich wirksam werdende Prozesse dafür sorgen die Karteninhaberdaten zu entfernen, die die Aufbewahrungsfristen überschritten haben. (3.1.b)
- Stellen Sie sicher, dass die gespeicherten und übertragenen Daten nicht lesbar sind. (3.4, 4.1)
- Verschlüsseln Sie Kartendaten und schützen Sie die zugehörigen Schlüssel. (3.5)
- Maskieren Sie die PAN-Daten, wenn diese angezeigt werden müssen (siehe oben) und verwenden Sie dabei möglichst wenige Zeichen (weniger als die ersten 6 und maximal die letzten 4). (3.3)
- Erstellen Sie ein Flussdiagramm zu den Daten der Karteninhaber und zwar für alle Datenflüsse innerhalb Ihrer Firma. (1.1.3)
- Verwenden Sie ein Tool zum Auffinden von Daten um falsch abgespeicherte sensible Daten in der betreffenden Umgebung aufzuspüren.
DON’T:
- Speichern Sie keine sensiblen Authentifizierungsdaten nach der Authentifizierung. (3.2)
- Ausnahme: Ihre Organisation ist selbst Aussteller und verfügt über die entsprechende geschäftliche Legitimation.
- Speicherung maskierter PAN-Daten.
- Lösung: Verwenden Sie Verschlüsselung.
DSS-Anforderung 4 – Verschlüsselte Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke
DO:
- Überprüfen Sie, wohin die Daten der Karteninhaber geschickt werden und stellen Sie sicher, dass Ihre Richtlinien bei der Übermittlung nicht verletzt und ausschließlich vertrauenswürdige Schlüssel oder Zertifikate verwendet werden. (4.1)
- Wählen Sie eine Reihe an ein- und ausgehenden Übertragungen aus und überprüfen Sie inwieweit die Kryptografie während der Übermittlung gewährleistet ist. (4.1.c)
DON’T:
- Schicken Sie keine PANs über Kommunikationskanäle, die für End-User gedacht sind, wie E-Mail, SMS oder IM. (4.2)
- Verwenden Sie keine Technologien, die SSL/ oder frühe TLS-Versionen verwenden (Version 1.0 oder früher)
- Migrieren Sie keine Daten von Karteninhabern auf Systeme, die SSL/oder frühe TLS-Versionen verwenden. (Version 1.0 oder früher)
Schutz vor externen Bedrohungen
Damit haben Sie jetzt die Daten an sich geschützt. Die Daten sind verschlüsselt, werden beim Anzeigen maskiert und ausschließlich über transparent abgebildete Datenflüsse übermittelt. Für einen echten Schutz dieser Daten reicht das aber leider nicht aus. Jenseits der Netzwerkgrenzen ist nicht gerade ein sicherer Ort. Im Gegenteil. Hacker und Profitjäger haben kein geringes Interesse an genau diesen Daten.
PCI DSS will dafür sorgen, dass die Verteidigungsanlagen des Netzwerks nicht weniger sicher sind: Firewalls und Antiviren-Maßnahmen sollen verstärkt, voreingestellte Sicherheitsparameter geändert und sichere Systeme mit wirksamen Prozessen zur Änderungskontrolle unterstützt werden.
Anwendbare DSS-Anforderungen:
DSS-Anforderung 1 – Installieren Sie eine Firewall-Konfiguration, die Karteninhaberinformationen schützt und erhalten Sie diese Konfiguration aufrecht
DO:
- Installieren Sie eine Firewall an jedem mit dem Internet verbundenen Punkt (auf jedem Gerät) sowie zwischen allen demilitarisierten Zonen (DMZ) und der internen Netzwerkzone. (1.1.4, 1.4)
- Konfigurieren Sie Ihre Firewalls mit einer Beschreibung der Gruppen, die für Netzwerkkomponenten verantwortlich sind und entsprechend den jeweiligen geschäftlichen Erfordernissen für alle Dienste/Protokolle/Anschlüsse innerhalb der Konfiguration. (1.1.5, 1.1.6)
- Überprüfen Sie die Firewall- und Router-Konfigurationen mindestens alle sechs Monate und stellen Sie sicher, dass jeder andere, nicht-konfigurierte Datenverkehr (eingehend und ausgehend) blockiert wird. (1.1.7, 1.2.1)
- Konfigurieren Sie die Router so, dass es keine Verbindung zwischen den nicht vertrauenswürdigen Teilen des Netzwerks und dem Zugriff auf Informationen von Karteninhabern gibt. (1.2, 1.3)
- Weisen Sie jemandem konkret die Verantwortung zu, die Firewall-Protokolle täglich zu prüfen.
DON’T:
- Speichern Sie keine Informationen von Karteninhabern in der DMZ oder nicht vertrauenswürdigen Netzwerken.
- Lösung: Erstellen Sie eine sichere interne Netzwerkzone. (1.3.6)
DSS-Anforderung 2 – Verwenden Sie keine standardmäßigen Voreinstellungen für Systempasswörter und andere Sicherheitsparameter.
DO:
- Identifizieren Sie einen für die Systemkomponenten zuständigen Systemadministrator. (2.2.4)
- Pflegen Sie eine Bestandsliste aller im Rahmen von PCI DSS verwendeten Systemkomponenten. (2.4)
- Dokumentieren Sie Richtlinien zur Änderung von voreingestellten Passwörter, geben Sie Wireless-Einstellungen vor und entfernen Sie voreingestellte Konten bevor Sie ein weiteres System in Ihrem Netzwerk installieren. (2.1, 2.1.1, 2.5)
- Dokumentieren Sie Konfigurationsstandards für Systemkomponenten, die sich mit Sicherheitsschwachstellen befassen, beschränken Sie den Service-/Protokoll-Zugriff rein auf den Bedarfsfall und folgen Sie gehärteten Standards. (2.2, 2.2.2)
DON’T:
- Verzichten Sie darauf unterschiedliche Funktionen auf einem einzigen Server umzusetzen, da das zu Berechtigungskonflikten führen kann. (2.2.1)
- Gehen Sie nicht davon aus, dass Anbieter einen Antiviren-Scan durchführen.
- Anforderung: Es liegt in Ihrer Verantwortung sicherzustellen, dass Anbietertechnologien auf dem aktuellen Stand sind und regelmäßig geprüft werden.
DSS-Anforderung 5 – Schützen Sie sämtliche Systeme vor Malware und aktualisieren Sie Antiviren-Software und -Programme regelmäßig
DO:
- Aktualisieren Sie die Antiviren-Software regelmäßig auf häufig betroffenen Systemen und finden Sie heraus, ob weitere Systeme gefährdet/zusätzliche Antiviren-Programme erforderlich sind. (5.1, 5.1.1, 5.1.2)
- Automatisieren Sie Antiviren-Scans und pflegen Sie die Antiviren-Audit-Protokolle für die betreffenden Systeme. (5.2)
- Stellen Sie sicher, dass ausschließlich Administratoren Antiviren -Systeme verändern oder deaktivieren können. (5.3)
- Dokumentieren Sie Methoden zum Schutz vor Malware. (5.4)
DON’T:
- Warten Sie mit der Identifizierung von Malware nicht, bis die verursachten Schäden offensichtlich werden.
- Lösung: Installieren Sie eine Software, die Verhaltensanomalien erkennt und die zuständigen Mitarbeiter bei Abweichungen benachrichtigt.
DSS-Anforderung 6 – Entwickeln und Pflegen von sicheren Systemen und Applikationen
DO:
- Definieren Sie einen Prozess, um sich permanent zu aktuellen Sicherheitsschwachstellen auf dem Laufenden zu halten, Risiken einschätzen und den Bedrohungslevel definieren zu können. (6.1)
- Installieren Sie vom Hersteller bereitgestellte Sicherheits-Patches. (6.2.a)
- Dokumentieren Sie die Auswirkungen, Befugnisse und Bevollmächtigte, Funktionalitätsprüfungen sowie die Back-Out-Verfahren zur Änderungskontrolle. (6.4.5)
- Verwenden Sie nur strikte Entwicklungsprozesse und sichere Codierungsrichtlinien (gemäß der DSS-Definition) bei der betriebsinternen Entwicklung von Software. (6.3)
DON’T:
- Warten Sie nicht länger als einen Monat, um die vom Hersteller bereitgestellten Sicherheits-Patches für eine als kritisch identifizierte Risikoebene zu installieren. (6.2.b)
- Testen Sie betriebsinterne Software nicht in Ihrer Produktionsumgebung, verwenden Sie während den Tests keine Produktionsdaten und hinterlassen Sie keine Test-Konten/IDs nach der Softwarefreigabe. (6.3.1, 6.4.1, 6.4.3)
Schutz vor der internen Bedrohungen
Die Karteninhaberinformationen sind gesichert, externe Barrieren verstärkt. Reicht das für ein ruhiges Gewissen? Leider nicht. Ein nicht zu unterschätzendes Risiko liegt in Bedrohungen aus den eigenen Reihen.
Interne Verstöße können verschiedene Ursachen und Urheber haben. Beispielsweise einen Eindringling, der mit dem erklärten Ziel in ein Unternehmen gekommen ist, Daten heraus zu schleusen, oder jemanden, der die Seiten gewechselt hat. Genauso häufig kommt es allerdings vor, dass Insider unbeabsichtigt wesentlich mehr Zugriffsberechtigungen haben als sie brauchen und so zur Sicherheitsschwachstelle werden.
PCI DSS enthält eine Reihe von Anforderungen, die dazu dienen Insider-Bedrohungen ebenfalls in den Griff zu bekommen. Beispielsweise indem man sowohl den virtuellen als auch den physischen Zugriff auf Karteninhaberdaten innerhalb eines Unternehmens beschränkt.
Anwendbare DSS-Anforderungen:
DSS-Anforderung 7 – Zugriff auf Karteninhaberinformationen gemäß geschäftlicher Erfordernisse einschränken
DO:
- Erstellen Sie eine Liste der Rollen mit Zugriff auf die CDE, einschließlich einer Definition aller Rollen, der jeweiligen Privilegienebene und der Berechtigungen, die alle Rollen benötigen um korrekt zu funktionieren. (7.1, 7.3)
- Erarbeiten Sie eine Richtlinie auf der Basis der minimalen Rechtevergabe und zwar für alle Mitarbeiter sowie eine Standard-Einstellung für „alle ablehnen“ (deny-all) für alle Einstellungen, die Zugriffskontrollen betreffen. (7.1.2, 7.2.3)
- Holen Sie sich eine dokumentierte Genehmigung der Bevollmächtigten für alle zu vergebenden Privilegien oder Änderungen der Privilegien innerhalb der CDE. (7.1.4)
DON’T:
- Vergeben Sie keine übermäßigen Berechtigungen (sozusagen („für alle Fälle“) für eine Rolle.
- Lösung: Verwenden Sie ein Modell der minimalen Rechtevergabe, in dem Berechtigungen nur erteilt werden, wenn sie geschäftlich erforderlich sind.
- Lösung: Gewähren Sie den Zugriff nur für genau den Zeitraum, für den er tatsächlich benötigt wird.
DSS-Anforderung 8 – Identifizieren und Authentifizieren des Zugriffs auf Systemkomponenten
DO:
- Definieren und dokumentieren Sie Verfahren zur Benutzeridentifizierung und -authentifizierung für alle Systemkomponenten. (8.1, 8.4)
- Weisen Sie sämtlichen Benutzern einmalige IDs zu, testen Sie diese Privilegienkontrollen und beseitigen Sie den Zugriff von inaktiven/deaktivierten Benutzern. (8.1.1, 8.1.2, 8.1.3, 8.1.4)
- Überwachen Sie alle Konten, die von Anbietern und anderen Dritten verwendet werden, und deaktivieren Sie diese Konten, wenn sie nicht länger gebraucht werden. (8.1.5)
- Sperren Sie Benutzer-IDs nach sechs fehlgeschlagenen Zugriffsversuchen für 30 Minuten. (8.1.6, 8.1.7)
- Folgen Sie den Best-Practice-Empfehlungen der DSS für das Einrichten von Passwörtern, einschließlich des Erstellens starker Passwörter, dem Verschlüsseln von Zugangsdaten, der ID-Prüfung vor dem Zurücksetzen und einem Pflicht-Reset alle 90 Tage. (8.2.1, 8.2.2, 8.2.3, 8.2.4)
- Integrieren Sie eine Mehrfaktor-Authentifizierung für jeden Admin-Zugriff ohne Konsole sowie den Remote-Zugriff auf die CDE. (8.3)
DON’T:
- Verwenden Sie niemals das gleiche Passwort für mehrere Konten oder Geräte – sobald dieses Passwort kompromittiert ist, sind alle diese Konten/Geräte gefährdet.
- Teilen Sie keine IDs oder Authentifizierungsmethoden innerhalb der CDE. (8.5)
DSS-Anforderung 9 – Beschränken des physischen Zugriffs auf Karteninhaberinformationen
DO: (sofern zutreffend)
- Dokumentieren Sie Prozesse für den physikalischen Zugriff auf CDE-Systeme. Erstellen Sie eine Liste aller Geräte, um den Zugriff auf die Rollen zu beschränken, die den Zugriff wirklich benötigen, und überwachen Sie alle Zugriffe mit Autorisierungs-Token. (9.1.1a, 9.1.1b, 9.2, 9.3, 9.9.1)
- Erstellen Sie eine Besucherautorisierung und Zugriffskontrollen, die sicherstellen, dass Besucher in allen Zugriffsbereichen bezüglich der CDE identifiziert, dokumentiert und überwacht werden. (9.4)
- Definieren Sie strikte Kontrollen für physische Medien innerhalb der Firma/der Organisation und verfolgen Sie ebenfalls nach, wenn diese Medien sich außerhalb des Unternehmens bewegen. Stellen Sie sicher, dass zerstörte Medien nicht wiederhergestellt werden können. (9.5, 9.6, 9.8)
- Schulen Sie die Aufmerksamkeit der Mitarbeiter um Externe zu identifizieren, die einen physikalischen Zugriff anfordern und um verdächtiges Verhalten zu identifizieren/zu melden. (9.9.2, 9.9.3)
Schutz vor zu viel Selbstzufriedenheit
Die Karteninhaberdaten selbst sind geschützt. Die Netzwerkgrenzen zum Schutz vor externen Bedrohungen verstärkt. Und Sie haben Maßnahmen ergriffen, um die Bedrohung durch interne Verstöße zu minimieren. Was jetzt noch übrig bleibt? Zu viel Selbstzufriedenheit.
Mit dem Status der PCI-Compliance sollten Sie sich an dieser Stelle noch nicht zufrieden geben. Die aktuelle Version PCI DSS 3.2 hat ihren Anforderungskatalog bereits entsprechend ausgeweitet. Dazu gehört es beispielsweise den Zugriff auf Netzwerkressourcen verstärkt zu überwachen, die Sicherheitsrichtlinien regelmäßig zu überprüfen und Programme zu entwickeln, die Mitarbeiter kontinuierlich involvieren.
Anwendbare DSS-Anforderungen:
DSS-Anforderung 10 – Nachverfolgen und Überwachen des Zugriffs auf Netzwerkressourcen und Karteninhaberinformationen
DO:
- Implementieren Sie Audit-Trails für alle Systeme, Meldungen bei verdächtigen Aktivitäten und einen Reaktionsplan, wenn Anomalien auftreten. (10.1, 10.2, 10.6.2.b)
- Verfolgen Sie alle Admin-Aktionen, Login-Versuche, Kontoänderungen und Unterbrechungen mittels des Audit-Trails nach. (10.2.3, 10.2.4, 10.2.5, 10.2.6)
- Stellen Sie sicher, dass das Audit-Protokoll die Benutzer-ID, Event-Art, Datum und Uhrzeit, Event-Erfolg oder -misserfolg, Ursprung des Events sowie die betroffenen Ressourcen erfasst. (10.3)
- Heben Sie alle Audit-Protokolle für mindestens ein Jahr auf, wobei die letzten drei Monate zur Auswertung verfügbar sein müssen. (10.7)
- Verhindern Sie die Manipulation von Audit-Trails und verwenden Sie Software zur Benachrichtigung bei Protokolländerungen. (10.5)
- Etablieren Sie einen Prozess zur täglichen Prüfung der CHD-Systemprotokolle sowie einen Prozess um Systemkomponenten zu überprüfen – basierend auf den Ergebnissen Ihrer Risikobewertung. (10.6.1, 10.6.2)
DON’T:
- Vergeben Sie keine Zugriffsrechte auf Protokolle ohne die entsprechende Legitimation für die Rolle. (10.5.1)
- Überprüfen Sie die täglichen Audit-Trails nicht manuell – das nimmt unnötig viel Zeit in Anspruch.
- Speichern Sie keine Audit-Protokolle für nach außen gerichtete Technologien auf diesen Maschinen – sie können kompromittiert werden. (10.5.4)
DSS-Anforderung 11 – Regelmäßige Überprüfung der Sicherheitssysteme und Prozesse
DO:
- Dokumentieren Sie alle autorisierten drahtlosen Zugriffspunkte gemäß den geschäftlichen Erfordernissen. (11.1.1)
- Implementieren Sie Prozesse um autorisierte und nicht autorisierte drahtlose Zugangspunkte auf vierteljährlicher Basis zu testen und um gemäß den Ergebnissen reagieren zu können. (11.1, 11.1.2)
- Führen Sie interne (mit qualifiziertem Personal) und externe (mit zugelassenen Scanning-Anbietern) Schwachstellen-Scans durch. Diese Scans sollten vierteljährlich oder bei jeder relevanten Netzwerkänderung durchgeführt werden. Alle identifizierten Schwachstellen müssen korrigiert und ein erneuter Scan durchgeführt werden. (11.2)
- Führen Sie jährlich interne und externe Penetrationtests (mit qualifiziertem Personal oder mit Hilfe von Dritten) durch. Alle ermittelten Risiken müssen Sie beheben und anschließend einen erneuten Test durchführen. (11.3)
- Verwenden Sie ein Tool, das jede Änderung sofort erkennt, die zuständigen Mitarbeiter bei jeder unbefugt vorgenommenen Änderung an kritischen Systemen informiert und mindestens einmal pro Woche einen Dateiabgleich durchführt. (11.5)
- Dokumentieren Sie einen Prozess wie Sie auf Änderungsmeldungen reagieren. (11.5.1, 11.6)
DON’T:
- Verlassen Sie sich bei den Tests nicht auf das Minimum.
- Lösung: Führen Sie Prüfungen häufiger durch als es vorgeschrieben ist. So sind Sie in der Lage frühzeitig auf Bedrohungen zu reagieren, sogar bevor es zu Datenschutzvorfällen kommt.
DSS-Anforderung 12 – Pflegen Sie eine Richtlinie, die sich mit der Informationssicherheit für alle Mitarbeiter befasst
DO:
- Veröffentlichen Sie eine jährlich geprüfte Sicherheitsrichtlinie, die alle CDE-kritischen Geräte und Dienste dokumentiert, den angemessenen Zugriff definiert (Rolle, Verwendung des Zugriffs und Standort) und die einen Prozess zur Risikoeinschätzung implementiert. (12.1, 12.2, 12.3, 12.4)
- Führen Sie jährlich Sicherheitsschulungen für alle Mitarbeiter durch, die auf die CDE zugreifen. (12.6)
- Weisen Sie Rollenverantwortungen zu, um Verfahren zu dokumentieren, Sicherheitsmeldungen zu analysieren, Konten zu verwalten und den Zugriff auf alle Daten zu überwachen. (12.5)
- Erstellen Sie eine Dokumentation der Serviceanbieter, einschließlich einer Liste der angebotenen Dienste, der Due-Diligence der Auswahl (inklusive Risikobewertung), einer Bestätigung des Serviceproviders zur Annahme der CHD-Verantwortlichkeit und einen Prozess um PCI DSS-Compliance durch die Anbieter zu gewährleisten. (12.8.1, 12.8.2, 12.8.3, 12.8.4, 12.8.5)
- Erstellen Sie einen jährlich zu überprüfenden Reaktionsplan bei auftretenden Systemverstößen. In diesem Plan sollten enthalten sein: die Aufgaben aller Rollen, spezielle Maßnahmen bei verschiedenen Bedrohungsarten/entsprechende Benachrichtigungen, die Behandlung kritischer Systeme und Backups sowie rechtliche Anforderungen an das Reporting und im Hinblick auf die Benachrichtigung der jeweiligen Kreditkartenanbieter. (12.10)
Ausblick
PCI DSS 3.2. hält Sie letztendlich dazu an, Ihre Unternehmenskultur zu verändern. PCI-Compliance sollte also nichts sein, was ein Unternehmen nur erreichen will, weil gerade eine (Risiko)Bewertung ansteht. PCI-Compliance sollte als ein regelmäßig zu durchlaufender Prozess verstanden werden. Innerhalb dieses Prozesses sollten Sie sensible Daten identifizieren, den Zugriff darauf beschränken, verdächtiges Verhalten erkennen und die zuständigen Personen benachrichtigen können. Schlussendlich sollten Sie in der Lage sein, das alles zu dokumentieren.
Die eingangs erwähnte Checkliste hilft Ihnen dabei diese Ziele zu erreichen und die Geschäftsführung darauf vorzubereiten mit neuen Bedrohungen und Anforderungen umzugehen. Klicken Sie hier für eine Druckversion der PCI-Compliance-Checkliste.
Quellen:
http://blog.pcisecuritystandards.org/preparing-for-pci-dss-32
https://www.varonis.com/learn/pci-dss-3-1-it-requirements/
https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss
http://blog.pcisecuritystandards.org/preparing-for-pci-dss-3-2-summary-of-changes
http://info.securitymetrics.com/pci-guide
