Mit der Veröffentlichung von PCI DSS v4.0 haben sich viele Anforderungen und Prozesse erheblich verändert. Bei einigen der neuen Anforderungen handelt es sich um sogenannte Future Dated Requirements, die erst ab dem 31.03.2025 verpflichtend werden. So auch bei den neu definierten Targeted Risk Analyses. Sie ersetzen die in früheren Versionen des Standards geforderten unternehmensweiten Risikomanagementprozesse und sind auch in der kürzlich veröffentlichten Version 4.0.1 weiterhin Bestandteil. Statt des gesamten Unternehmens fokussieren Targeted Risk Analyses bestimmte Einzelanforderungen.
Tobias Weber, Managing Consultant und Qualified Security Assessor der usd AG, hat das Konzept der Targeted Risk Analyses in seinem Webinar bereits genauer beleuchtet. Wir fassen die wichtigsten Erkenntnisse hier noch einmal für Sie zusammen.
Targeted Risk Analyses: Anforderung 12.3
Die Anforderung 12.3 des PCI DSS v4.0 konkretisiert Vorgaben zur Durchführung von Risikoanalysen. Hiernach müssen Risiken für die Kartendateninhaberumgebung (CDE) formal identifiziert, bewertet und gesteuert werden. Die Anforderung gliedert sich in vier Teilanforderungen.
Requirement 12.3: Risks to the cardholder data environment are formally identified, evaluated, and managed.
12.3.1 - Frequency of performance of controls
12.3.2 - Measures for customized approach
12.3.3 - Cryptographic agility
12.3.4 - Lifecycle management
Die ersten beiden dieser Teilanforderungen beziehen sich jeweils auf PCI DSS Anforderungen, die Unternehmen eine größere Flexibilität bei ihrer Erfüllung ermöglichen als zuvor. Die beiden anderen Teilanforderungen liefern Rahmenwerke für die kryptographische Architektur, die ein Unternehmen einsetzt, und für das Lifecycle-Management von Soft- und Hardware.
12.3.1: Targeted Risk Analysis für Anforderungen mit flexibler Frequenz
PCI DSS v4.0 bietet Unternehmen die Möglichkeit, bei bestimmten Anforderungen selbst die Frequenz zu bestimmen, in der sie geforderte Maßnahmen durchführen. Um eine angemessene Frequenz zu ermitteln, müssen Unternehmen eine Targeted Risk Analysis durchführen.
Unser Tipp für Sie: Überprüfen Sie regelmäßig die Bedrohungslage und die potenzielle Schadenshöhe für die entsprechenden Anforderungen. Sie können sich dabei an „Industry Best Practices“ wie z.B. des NIST oder des BSI orientieren. Wählen Sie die Frequenz für die geforderten Maßnahmen auf Basis dieser Überprüfung und dokumentieren Sie Ihre Ergebnisse.
12.3.2: Targeted Risk Analysis für Anforderungen nach dem Customized Approach
Version 4.0 des PCI DSS beinhaltet viele Mechanismen, die Unternehmen ein flexibleres Vorgehen beim Erfüllen der Anforderungen ermöglichen. So haben Unternehmen bei bestimmten Anforderungen die Wahl, ob sie diese mit dem traditionellen Ansatz (Defined Approach) oder dem neuen Customized Approach erfüllen. Der Customized Approach bietet die Möglichkeit zur Entwicklung und Umsetzung individueller Sicherheitsmaßnahmen. Für jedes Requirement, das mit einem Customized Approach erfüllt wird, muss eine Targeted Risk Analysis durchgeführt werden.
Unser Tipp für Sie: Nutzen Sie für die Durchführung der Targeted Risk Analysis für diese Teilanforderung die Vorlage des Council im Anhang E des Standards. Dieser enthält hilfreiche Vorgaben für die einzelnen Prozessschritte.
12.3.3: Targeted Risk Analysis und Cipher Suites
In Requirement 12.3.3 fordert der Standard nun ein verbessertes Management der kryptographischen Architektur. Dabei wird für alle eingesetzten kryptographischen Cipher Suites und Protokolle überprüft, ob diese auch in Zukunft noch eingesetzt werden können oder ob eine Strategie zur Ablösung veralteter Verfahren entwickelt werden muss.
Unser Tipp für Sie: Führen Sie die Targeted Risk Analysis für Requirement 12.3.3 in drei Schritten durch:
12.3.4: Targeted Risk Analysis und Hardware- und Software-Lifecycle-Management
Die vierte Teilanforderung aus 12.3 bezieht sich auf die Überwachung der eingesetzten Software und Hardware hinsichtlich der kommunizierten End-of-Life-Termine. Wenn ein entsprechender Termin vom Hersteller kommuniziert wurde, muss ein Projekt aufgesetzt werden, um zu festzulegen, wie die veraltete Technologie abgelöst werden kann.
Unser Tipp für Sie: Führen Sie die Targeted Risk Analysis für Requirement 12.3.4 in drei Schritten durch:
In der dynamischen Welt der Cyber Security sind es oft die obskuren und längst vergessenen Schwachstellen, die eine verborgene Bedrohung für ansonsten gehärtete Systeme darstellen. Eine solche Schwachstelle liegt in ungültigen Zeichenkodierungen, die gegen den...
Die Betreiber Kritischer Infrastrukturen (KRITIS) sind gemäß § 8a Absatz 1 BSIG in Deutschland verpflichtet, angemessene organisatorische und technische Vorkehrungen zu treffen, um Störungen der Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit ihrer...
In einer Welt, in der Sicherheit und Effizienz Hand in Hand gehen müssen, zeigt unser jüngstes Projekt mit der HanseMerkur Krankenversicherung AG, wie entscheidend eine gute Organisation und klare Kommunikation für den Erfolg eines Pentest-Projekts sind. Trotz eines...