Haben Sie sich schon einmal frustriert gefühlt, wenn es um die Einhaltung von Sicherheitsvorschriften ging? Dann sind Sie nicht allein. Wir alle haben eine Art "Kryptonit", wenn es um die Einhaltung von Vorschriften geht. Ich habe einige unserer InfoSec-Auditoren gebeten, ihren Kryptonit zu teilen. Ihre Antworten konzentrierten sich auf den Schmerz des Tages, die neuen Versionen 4.0 und 4.01 des PCI DSS-Standards. Also, lieber Leser, lassen Sie uns zum Kern der Sache kommen.
Die erste Antwort ist Chris CamejoLeiterin der Compliance-Praxis :
Nie gefragt
"Mein Kryptonit in Sachen Compliance ist, wenn eine Organisation fragt, warum wir sie zwingen, etwas für die Compliance zu tun, was sie vorher noch nie tun musste. Oft handelt es sich dabei um Sicherheitskontrollen, die von früheren Prüfern genehmigt wurden. Das führt dazu, dass ich mein Verständnis des Rahmens (und manchmal auch meine geistige Gesundheit) in Frage stelle. Zu sagen "Alle anderen Prüfer, mit denen Sie gesprochen haben, haben sich geirrt", erscheint mir egoistisch, also gehe ich oft zur Quelle zurück, um mein Verständnis zu überprüfen, aber in der Regel stoße ich auf eine ziemlich klare Anforderung, die durch Leitfäden und FAQs unterstützt wird, die oft relevante spezifische Beispiele enthalten".
"Nach vielen Jahren bin ich zu dem Schluss gekommen, dass einige Prüfer in dieselbe Falle tappen wie die Organisationen, die sie beurteilen: Sie machen Annahmen über die Bedeutung einer Anforderung, ohne sie wirklich in ihrem Kontext zu verstehen oder zusätzliche Leitlinien zu konsultieren (ich sage das nur ungern, aber ich war wahrscheinlich zu Beginn meiner Karriere im Bereich Compliance dieser Typ). Damit tut man den geprüften Organisationen keinen Gefallen, denn sie erleben bei der Prüfung plötzliche Überraschungen, wenn ein neuer Prüfer ein besseres Verständnis der Anforderungen hat als der vorherige Prüfer. Manchmal funktioniert es auch in die andere Richtung. Ich finde Organisationen, die Dinge tun, die 'zum Zwecke der Einhaltung' nicht erforderlich sind, weil sie die Anforderungen nicht richtig gelesen haben".
Von Anfang an
"Es gab schon immer Missverständnisse darüber, wie PCI DSS (und andere Compliance-Rahmenwerke) ihren Anwendungsbereich definieren und was für bestimmte Anforderungen akzeptabel ist. Viele dieser Missverständnisse wurden in verschiedenen Leitfäden und FAQs angesprochen, für die sich außer den engagiertesten Compliance-Experten niemand die Zeit genommen hat, sie zu lesen und zu verstehen. Ich bin der Ansicht, dass viele der "Änderungen" in Version 4.0 des PCI DSS-Standards die Informationen aus den Leitfäden und FAQs in den Standard selbst hineinziehen und so das, was schon immer erwartet wurde, an einem Ort konsolidieren, an dem es mit größerer Wahrscheinlichkeit zu sehen ist. Ein Beispiel hierfür ist das in Abschnitt 4 des PCI DSS-Standards hinzugefügte Flowchart des Anwendungsbereichs. Es hat vielen Organisationen geholfen, besser zu verstehen, was zum Geltungsbereich gehört und was nicht. Das Geheimnis ist, dass sich dieses Flussdiagramm jahrelang im Dokument PCI Scope and Segmentation Guidance versteckt hatte, wo es nur sehr wenigen auffiel, und erst jetzt in den DSS-Standard selbst aufgenommen wurde.
Neu für Sie
"Ich habe gesehen, wie eine Reihe von Kunden die Änderungen als notwendig für die Anpassung an die neue Version 4.0 des PCI DSS-Standards beschuldigt haben, obwohl das Ergebnis der Änderung etwas ist, was sie von Anfang an hätten tun sollen. Einerseits bedeutet dies, dass Änderungen effektiv sind: Sie zwingen Organisationen dazu, zu einem einheitlichen und konsistenten Verständnis des Geltungsbereichs und der Anforderungen des PCI DSS-Standards zu konvergieren, anstatt dass einige Organisationen mit Einsparungen am falschen Ende davonkommen. Andererseits ist es als Berater schmerzhaft, einem Kunden sagen zu müssen, dass er sich geirrt hat und seine Herangehensweise an die Einhaltung von Vorschriften überdenken muss.
Ich wurde reingelegt
"Als Praxisleiter bin ich oft in die Technik vor dem Verkauf involviert und helfe dabei, die Compliance-Verpflichtungen für unsere potenziellen Kunden zu definieren. Ich habe regelmäßig mit Organisationen zu tun, die sich abmühen, weil die Einhaltung eines bestimmten Rahmenwerks von einem ihrer Partner oder Kunden vertraglich gefordert wird. Sehr oft finde ich mich dabei wieder, dass ich zu erklären versuche, dass der Compliance-Rahmen aus irgendeinem Grund nicht für ihre Organisation gilt. Oft liegt es daran, dass die Organisation nicht die Art von Informationen verarbeitet, für die das Rahmenwerk gilt, oder dass die Organisation nicht in der Art von Aktivität tätig ist, für die das Rahmenwerk gilt. Der wahre Grund ist, dass der Partner oder Kunde, der die Organisation zur Einhaltung der Vorschriften auffordert, nicht versteht, was die Compliance-Rahmen selbst sind, und die falschen Fragen stellt. Nachdem ich zu viele solcher Anrufe beantwortet habe, habe ich einen Artikel verfasst, in dem ich die Anwendbarkeit von Frameworks erkläre, die oft unangemessen angewendet werden."
Anbieter von Dienstleistungen
"Gemäß PCI-Anforderung 12.8.5 müssen Händler die Verantwortlichkeiten der Dienstleister dokumentieren, aber es war schon immer schwierig, diese Informationen von den Dienstleistern zu erhalten. Die neue Anforderung 12.9.2 sollte dies erleichtern, da die Dienstleister nun gemäß PCI DSS verpflichtet sind, ihren Kunden zu helfen, ihre Verantwortlichkeiten zu verstehen. Aber es gibt einen Haken: Einige große Organisationen veröffentlichen Verantwortungsmatrizen, die mehr Fragen als Antworten hinterlassen (z. B. sind in der Matrix von Microsoft Azure alle Unteranforderungen x.1.1 und x.1.2 als alleinige Verantwortung des Kunden gekennzeichnet, selbst bei Anforderungen, für die Microsoft bei anderen Unteranforderungen eine gemeinsame oder alleinige Verantwortung beansprucht hat). Wenn Microsoft für bestimmte Unteranforderungen verantwortlich ist, muss Microsoft auch für seine eigenen Richtlinien, Verfahren und Rollenzuweisungen für diese Verantwortlichkeiten gemäß den Unteranforderungen x.1.1 und x.1.2 verantwortlich sein. Dienstanbieter haben einen langen Weg vor sich, um ihren Kunden zu helfen, genau zu verstehen, welche Verantwortlichkeiten sie haben.
Chris hatte viel zu sagen!
Fortsetzung folgt Lee QuintonLee Quinton, ein weiterer langjähriger QSA-PCI, arbeitet in Großbritannien.
Mit den Füßen schleifen
"Um genauer auf den letzten von Chris angesprochenen Punkt einzugehen, stoßen sie auch auf die Tatsache, dass ihre Compliance innerhalb der nächsten zwei bis drei Monate erforderlich ist, während der PCI-Drittanbieter (TPSP) die Compliance erst in sechs bis neun Monaten erreichen muss und über keine Art von entwickelter Verantwortungsmatrix verfügt, um seinem Kunden bei der Einhaltung der Anforderung 12.8.5 zu helfen."
Alle QSA, die ich befragt habe, berichteten über das Problem mit der PCI-Anforderung 12.8.5.
Der nächste Artikel ist Linus GarinPCI QSA. Obwohl er der jüngste und jüngste QSA bei TrustedSec ist, hat er Erfahrungen in verschiedenen Führungspositionen und Branchen gesammelt.
Handelt es sich um ein MAP?
"Ich habe auch ähnliche Schwierigkeiten mit den Anforderungen 12.8 und 12.9. Ich helfe Chris dabei, eine Matrix der TPSP-Verantwortlichkeiten für einen Kunden zu erstellen, und es ist BRUTAL. Die Verantwortlichkeiten der einzelnen TPSPs zu kartieren, gleicht einem Ratespiel, insbesondere wenn die TPSPs keine Version ihrer Verantwortlichkeiten oder ein AOC zur Verfügung stellen (entweder haben sie keine oder der Kunde ist aus irgendeinem Grund nicht in der Lage, diese zu sammeln). Und bei TPSPs, die ihre eigene Verantwortungsmatrix haben, wie Azure und Cloudflare, gibt es, wie Chris schon sagte, Abweichungen in der Matrix, die mehr Fragen als Antworten erzeugen. Es gibt Kontrollen, die als nicht anwendbar für das TPSP markiert sind, obwohl sie es eindeutig sein sollten, wie 12.10 stuff. Sollte ich ihrer Verantwortungsmatrix folgen oder das "Urteil und die Interpretation der QSA" nutzen, um ihre Verantwortungsmatrix zu übergehen?"
"So hat der Kunde am Ende ein TPSP, das etwas sagt, und ein QSA, das etwas anderes sagt, was für seine (und unsere) Erfahrung nicht gut ist."
Der nächste ist der berühmte Autor und QSA, Arthur Cooper (Coop).
Auf dem Laufenden bleiben
"Sie haben Recht, Sir. Meiner bescheidenen Meinung nach war das TPSP-Thema der SCHLECHTESTE Teil meiner Zeit als QSA.
Coop versucht auch, mit PCI eine schnelle Lösung für die Sicherheitsstandards der Branche zu erreichen. Beispielsweise verwenden viele der derzeit zugelassenen POS/POI-Zahlungsgeräte den Triple Data Encryption Standard (3DES) als Teil des Schemas Derived Unique Key Per Transaction (DUKPT), aber ab dem 31. Dezember 2023 hat das National Institute of Standards and Technology (NIST) dieses Schema herabgestuft und Organisationen geraten, es aufgrund von Sicherheitsproblemen und der Verfügbarkeit robusterer Verschlüsselungsalgorithmen aufzugeben.
Als ursprünglicher Autor von Anforderung 10 des PCI DSS-Standards während seiner Zeit im PCI-Rat bittet Coop den aktuellen Rat häufig um die Klärung verschiedener Aspekte des Standards.
Der nächste Artikel ist Steph SaundersSteph Saunders, PCI QSA und langjähriger Spezialist für die Umsetzung von Sicherheitsmaßnahmen. Sie hat Sicherheitskontrollen im gesamten Unternehmen unterstützt und stellt fest, dass viele Unternehmen vor zahlreichen Herausforderungen stehen, wenn es um die globale Abdeckung und einheitliche Konfiguration von IAM geht, insbesondere mit MFA in der heutigen Zeit.
Melden Sie sich an
"Für Unternehmen, die mehrere technische Innovationszyklen durchlaufen haben, sind viele IAM-Konfigurationen einfach nicht kompatibel oder zentralisiert. Abgesehen von den technischen Unterschieden bedeutet die dezentrale Verwaltung oft auch, dass die rechtzeitige, konsistente oder transparente Deaktivierung von Konten von einem System zum anderen völlig unterschiedlich ist."
"Viele Compliance-Standards wie PCI sind nicht sehr präskriptiv, was die korrekte Konfiguration der MFA angeht (z. B. bewährte Verfahren zur Verhinderung der Wiederverwendung von Token). Viele Standards wie PCI beinhalten noch keine akzeptable passwortlose Authentifizierung, trotz der vielen vorhandenen Optionen."
Die nächste Hintertür im XZ-Dienstprogramm
"Wie weit muss man mit der neuen PCI-Anforderung 6.3.2, die eine Bestandsaufnahme aller maßgeschneiderten und kundenspezifischen Software verlangt, gehen? Bis zu welchem Detailgrad muss ein Unternehmen beispielsweise Open-Source-Bibliotheken inventarisieren und verwalten? Was ist mit den Bibliotheken, die von diesen Bibliotheken aufgerufen werden? Warum nicht bis zu fünf Tiefenebenen gehen und mit welchem Grad an Sicherheit? Viele Unternehmen wissen nicht, wo die Sorgfaltspflicht enden soll".
Wie viel Sorgfalt würde hätte den Angriff auf die Hintertür des XZ-Dienstprogramms verhindert?
"Viele Unternehmen wissen nicht, welche ihrer Dienstleister von der Einhaltung der Vorschriften betroffen sind. Sehr häufig werden die Hersteller von Betriebssystemen (z. B. Microsoft) und Netzwerkgeräten (z. B. Cisco) als Anbieter von Kernprodukten und nicht als Dienstleister behandelt. Wenn aber dieselben Anbieter keine rechtzeitigen Updates liefern, können sie immer noch die Schwachstelle im nächsten Datenbereich sein. Wie weit sollte die Sorgfaltspflicht gehen?
Der nächste ist Ihr Blogger, Steve MaxwellPCI QSA unter anderem Standards.
Was, diese alten Lumpen?
Was ist mein größter Kryptonit in Bezug auf die Einhaltung von Vorschriften? Wie andere schon gesagt haben, ist es die Herausforderung, die Sicherheitsabdeckung von Technologietransfer-Dienstleistern zu überwachen. Die Dienstleister verkünden öffentlich, dass sie ihre Kunden vor Compliance-Problemen bewahren, aber das Kleingedruckte, das sie privat mit ihren Kunden teilen, ist oft viel bescheidener.
Sie sind wie Mitglieder des Königshauses, die für den roten Teppich am Eingang "neu" angezogen werden. Sobald sie drinnen sind, antworten sie auf die Frage nach ihrer Kleidung mit "Was, diese alten Lumpen?". Die Tatsache, dass sie die Butter auf dem Brot haben, erschwert es ihren Kunden, zu zeigen, dass sie sich an die Regeln halten.
Viele PCI-Kunden halten es für notwendig, bessere Informationen zu verlangen, als sie derzeit von den TPSPs angeboten werden. Die PCI-Industrie muss die TPSPs möglicherweise für die genaue Dokumentation der Sicherheitskontrollen der Kunden verantwortlich machen. Bis die meisten TPSPs genauer werden, kann Kunden, die versuchen, ihre eigene Compliance nachzuweisen, geraten werden, nachzuweisen und zu dokumentieren, wo ihre Fähigkeit, Auswirkungen auf die Sicherheit zu haben, endet, und intuitiv, wo nachgewiesen wird, dass das TPSP den Zugang oder die Kontrollen des Kunden unterstützt oder zumindest nicht zulässt. Dies ist keine perfekte Lösung, aber es ist die einzige Option, die viele PCI-abhängige Kunden derzeit haben.
Das ist ein Merkmal, kein Fehler
In Anlehnung an Chris' Artikel "There All Along" nenne ich dies das Problem des "Fehlens einer einzigen Quelle der Wahrheit". Ich sehe z. B. bestimmte Berichtsanforderungen in einer einzigen Berichtsvorlage, nur im DSS, nur in einer FAQ oder nur in einer OCR-Vorlage, aber irgendwie nicht in der SAQ-D-Vorlage.
Die Tatsache, dass die Wahrheit an vielen Orten zu finden ist, bedeutet, dass man im besten Fall an allen möglichen Orten suchen muss, bevor man Schlussfolgerungen zieht. Im schlimmsten Fall bedeutet es, dass man aus einer einzigen Quelle eine falsche Schlussfolgerung ziehen muss, obwohl es auch andere gibt. Es genügt zu sagen, dass ich eine Liste der offensichtlichen Widersprüche in den verschiedenen Quellen der PKI führen muss. Auch wenn viele den Spielraum, den die QSA bei der Auslegung des Geltungsbereichs und der Anforderungen des ICP haben, nicht schätzen, ist dieses Bedürfnis so weit verbreitet, dass es als Merkmal angesehen wird.
Grenzen der Dokumentenprüfung
Wenn immer noch keine Klarheit herrscht, kann die einzige Möglichkeit für den Kunden darin bestehen, seine Grenzen in Bezug auf die Auswirkungen auf die Sicherheit der Daten von Karteninhabern zu testen und zu dokumentieren. Wenn beispielsweise ein Zahlungsabwicklungsunternehmen, das alle Daten von Karteninhabern speichert, nicht behauptet, alle logischen Zugriffskontrollen für die gespeicherten Daten zu besitzen, muss der Kunde möglicherweise eine Liste aller Nutzer erstellen und deren Fähigkeit testen, auf die Daten zuzugreifen oder den Zugriff zu verwalten. Wenn es keinen Zugriff auf die gespeicherten Daten gibt, sollte man dies dokumentieren und hoffen, dass die TPSPs bald genauer und nützlicher in ihren Berichten werden.
Verweis auf das Ziel des personalisierten Ansatzes
Meine einfachste Methode, verwirrende DSS-Kontrollen zu interpretieren, besteht darin, das Ziel des benutzerdefinierten Ansatzes zu lesen. Wenn die bewertete Einheit das Ziel umfassend berücksichtigt, ist es wahrscheinlich, dass sie nachweisen kann, dass sie abgedeckt ist. Umgekehrt gilt: Wenn ein Unternehmen die PCI-Anforderungen im Rahmen des definierten Ansatzes erfüllt hat, aber das Ziel des benutzerdefinierten Ansatzes nicht erreicht hat, ist es wahrscheinlich, dass es viele andere Anforderungen nicht erfüllt. Das Ziel des benutzerdefinierten Ansatzes ist der einfachste Weg, um Fehlinterpretationen zu vermeiden.
Lieber Leser, deckt sich das mit Ihren Erfahrungen? Unsere Berater können Ihnen in all diesen Bereichen helfen, also zögern Sie nicht, sie um Hilfe zu bitten.