Nachweise im PCI DSS-Audit
In dieser Folge unsere PCI DSS v4.0‑Blogs erläutern wir, welche Pflichten Auditoren beim Nachweis ihrer Audit-Ergebnisse haben, und wie Sie am besten die Erbringung angemessener Nachweise für PCI DSS v4.0‑Audits vorbereiten.
Auditprozess
Im Laufe eines PCI DSS-Assessments (oder, wie wir im Deutschen häufig sagen, ‑Audits) prüfen Auditoren, inwieweit die PCI DSS-Anforderungen bei einem Unternehmen umgesetzt sind.
Üblicherweise beinhaltet ein Auditprozess die folgenden Prüfschritte:
- Review von Dokumenten,
- Review von Systemkomponenten/-einstellungen,
- Review von Prozessen,
- Review von physischen Gegebenheiten,
- Review von Protokollen/Ergebnissen, und
- Interviews mit Personal.
Dies ändert sich auch nicht mit der Migration auf PCI DSS v4.0.
Nachweispflichten
Welche Notizen eine Auditorin sich macht und welche Nachweise sie wie ablegt, bleibt für die auditierte Firma normalerweise im Verborgenen. Wir geben Ihnen hier einen kleinen Einblick, was sich dort mit PCI DSS v4.0 verändert.
Das PCI SSC hat mit dem neuen Reporting Template für PCI DSS v4.0 sowie mit einem Update des PCI DSS Program Guide für QSAs jetzt klargestellt, dass sie für jeden Prüfschritt fordern, dass der Auditor einen entsprechenden Nachweis abgelegt. Die prüft das PCI SSC auch stichprobenartig bei den Auditfirmen.
Für Dokumente ist dies einfach: der Nachweis ist das jeweilige Dokumente selbst. Ähnlich ist es bei Protokollen/Ergebnissen – hier muss nur darauf geachtet werden, dass klar ist, um welches System oder welchen Prozess es hier geht.
Falls Sie einem Auditor einen Screenshot oder eine Datei als Nachweis schicken, achten Sie daher bitte darauf, die Information mitzuliefern, um welche Systemkomponente und/oder welche Prozess es geht.
Beim Review von Systemkomponenten/-einstellungen ist es notwendig, dass der Auditor sich dedizierte Notizen zu dem jeweiligen System und der jeweiligen Einstellung macht.
Beim Review von Prozessen oder physischen Gegebenheiten muss die jeweilige Gegebenheit detailliert beschrieben werden, und es muss dargestellt werden, welche Schlüsse die Auditorin aus der Beobachtung zieht. In ähnlicher Form wird auch bei einem Interview erwartet, dass die Auditorin grob die Fragen und Antworten mitschreibt.
Geben Sie bitte dem Auditor im Audit genügend Zeit, sich entsprechende Notizen zu machen. An vielen Stellen kann es die Schreibarbeit verkürzen, wenn der Auditor Kopien oder Screenshots bereitgestellt bekommt oder Fotos machen darf.
Der PCI DSS v4.0 listet etwa 250 Unterpunkte zu den 12 Haupt-Anforderungen auf – entsprechend viele Nachweise benötigt der Auditor.
Aufbewahrungspflichten
Der PCI DSS Program Guide schreibt vor, dass alle oben genannten Nachweise von der Auditfirma für mindestens drei Jahre sicher aufbewahrt werden müssen und auf Anfrage dem PCI SSC und den zugehörigen Gesellschaften verfügbar gemacht werden müssen.
Aus Datenschutz- oder Vertraulichkeitsgründen kommt es vor, dass Unternehmen es für einzelne Nachweise nicht erlauben, dass die Auditorin sie mitnehmen und ablegen darf. In diesem Fall regelt das PCI SSC, dass die Ablage stattdessen bei dem auditierten Unternehmen erfolgen darf. Die Anforderungen an Aufbewahrungsfrist und Verfügbarkeit sind in diesem Fall die gleichen.
Da die Nachweispflichten mit PCI DSS v4.0 größer geworden sind, wird auch dieser Fall in Zukunft häufiger vorkommen.
Wenn Sie erwarten, dass nicht alle Nachweise an den Auditor weitergegeben werden dürfen, bereiten Sie sich als auditiertes Unternehmen am besten vor, indem Sie
- eine revisionssichere Aufbewahrung der Nachweise für mindestens drei Jahre vorbereiten,
- während des Audits eine Liste der nicht ausgehändigten Dokumente und Nachweise führen,
- eine schriftliche Bescheinigung für den Auditor vorbereiten, in der Sie
- den Aufbewahrungsort benennen,
- den Ansprechpartner benennen, an den das PCI SSC sich wenden kann, wenn es Nachweise einsehen möchte, und
- eine revisionssichere Aufbewahrung bis zu einem konkret benannten Datum, welches mindestens drei Jahre in der Zukunft liegt, bestätigen.
Umgang mit Abweichungen
Wie sieht es mit den Nachweisen aus, wenn im Audit nicht sofort die Erfüllung aller Anforderungen nachgewiesen werden konnte, sondern Abweichungen festgestellt wurden?
Geplante Abweichungen
Der einfachste Fall ist es, wenn Sie als auditiertes Unternehmen bereits vorab erkannt haben, dass Sie eine Anforderung nicht erfüllen können oder nicht auf dem vorgegebenen Weg erfüllen möchten. In diesem Fall haben Sie zum Audit bereits eine Dokumentation einer Compensating Control oder eines Customized Approaches vorbereitet. Hierbei kann Ihnen auch ein PCI DSS-Experte helfen – es darf nur nicht der gleiche sein, der die Umsetzung dann auch prüft.
Zum Customized Approach werden wir in einer späteren Folge unseres PCI DSS v4.0‑Blogs noch ausführlich Stellung nehmen.
In beiden Fällen wird die Auditorin die Nachweise der Compensating Control oder des Customized Approaches Ihres Unternehmens prüfen, ggf. Rückfragen stellen, und dann geeignete Prüfmethoden ableiten und durchführen. Die Pflichten zum Erheben von Nachweisen ergeben sich dabei aus der jeweiligen Prüfmethode.
Ungeplante Abweichungen – „INFI“
Treten während eines Auditzeitraums ungeplante Abweichungen von den PCI DSS-Anforderungen auf, müssen diese behoben werden und die Behebung durch den Auditor verifiziert werden. Dies war bereits unter PCI DSS v3.2.1 so.
Der PCI DSS v4.0 verlangt zusätzlich explizit, dass der Grund für das Auftreten der Abweichung identifiziert wird, und dass Prozesse implementiert sind, die ein erneutes Auftreten solch einer Abweichung verhindern. Nur in dem Fall kann der Auditor die Anforderung noch als erfüllt ansehen.
Im neuen „Items Noted For Improvement” (INFI)-Dokument müssen bei jedem PCI DSS v4.0‑Audit alle Abweichungen, ihre Gründe, die korrektiven und präventiven Maßnahmen dokumentiert werden.
Die Auditorin stellt dem auditierten Unternehmen zum Abschluss des Audits das INFI-Dokument zur Verfügung, und beide Parteien unterschreiben es. Das INFI-Dokument belegt, dass das auditierte Unternehmen die Abweichungen erfolgreich bewältigt hat. Das Dokument kann im auditierten Unternehmen intern verwendet werden – bspw. in Compliance- und Risiko-Abteilungen – und auf dessen Wunsch auch mit Dritten geteilt werden. Eine Verpflichtung zur Vorlage des INFI-Dokuments gibt es nicht, und es wird auch nicht in der Attestation of Compliance (AoC) referenziert.
Gerade bei regelmäßig zu wiederholenden Prozessen kommt es immer mal wieder dazu, dass sich eine Durchführung verspätet, z.B. bei der Durchführung von
- Security-Awareness-Trainings,
- der Inspektion von Zahlgeräten,
- Schwachstellenscans, oder
- dem Einspielen von Patches.
Überlegen Sie sich am besten bereits im Vorfeld, wie Sie Ihre Prozesse so gestalten, dass Sie die vorgeschriebenen Zeiträume einhalten und Verspätungen sofort bemerken.
SRC und die DAkkS-Akkreditierung nach ISO/IEC EN 17025: Ein wichtiger Schritt in Richtung EUCC
SRC Security Research & Consulting GmbH kann einen weiteren bedeutenden Erfolg verzeichnen: Die erfolgreiche Akkreditierung durch die Deutsche Akkreditierungsstelle (DAkkS) nach DIN EN ISO/IEC 17025. Dieser Schritt unterstreicht nicht nur die Kompetenz und Zuverlässigkeit unseres Prüflabors für Common Criteria (CC), sondern bereitet uns auch auf die Einführung der EUCC (European Common Criteria) vor, eine wichtige Entwicklung in der europäischen Cybersicherheitslandschaft.
Bedeutung der DAkkS-Akkreditierung
Die Akkreditierung nach DIN EN ISO/IEC 17025 ist ein klares Zeichen für die Professionalität und den Anspruch von SRC, erstklassige Prüfdienstleistungen anzubieten. Sie bestätigt, dass unser CC-Prüflabors den international anerkannten Standards entspricht und vertrauenswürdige, konsistente Ergebnisse liefert.
Vorbereitung auf die EUCC
Die EUCC stellt das auf den Common Criteria basierende europäische Zertifizierungsschema dar, soll die Sicherheitszertifizierung von IKT-Produkten in Europa verbessern. Mit unserer DAkkS-Akkreditierung ist SRC nun bestens gerüstet, um die Herausforderungen der EUCC zu meistern und eine führende Rolle in der IT-Sicherheitszertifizierung in Europa zu übernehmen. Die EUCC erweitert die Anforderungen der bisherigen Common Criteria und wird künftige Zertifizierungen in der EU grundlegend prägen.
Unser Engagement für Qualität und Genauigkeit
Mit dieser Akkreditierung demonstriert SRC sein Engagement für höchste Qualitätsstandards und Unparteilichkeit in unseren Labortätigkeiten. Wir sind stolz darauf, diesen Meilenstein erreicht zu haben und freuen uns darauf, unseren Kunden weiterhin Dienstleistungen auf höchstem Niveau anzubieten.
Bei weiteren Fragen stehen unser Sales-Team Ihnen jederzeit zur Verfügung!
SRC ist dem Bundesverband IT Sicherheit (TeleTrusT) angeschlossen
SRC hat sich dem Bundesverband IT Sicherheit (TeleTrusT) angeschlossen.
Der Bundesverband IT-Sicherheit e.V. (TeleTrusT) ist ein Kompetenznetzwerk, das in- und ausländische Mitglieder aus Industrie, Verwaltung, Beratung und Wissenschaft sowie thematisch verwandte Partnerorganisationen umfasst.
Aufgrund der permanent ändernden Anforderungen im Bereich IT-Sicherheit ist es für SRC von Bedeutung, dass sich ihre Experten regelmäßig über neue Notwendigkeiten, Techniken, Prozesse und Regularien informieren und austauschen müssen.
TeleTrusT bietet hierfür insbesondere gute Voraussetzungen, da neben dem Austauch der Experten aus der Wirtschaft auch der Kontakt zu Politik und Wissenschaft hergestellt ist.
SRC wird sich mit ihrer breit gefächerten Expertise in die verschiedenen Arbeitsgruppen der TeleTrusT einbringen und so dem Stellenwert der IT-Sicherheit in Deutschland und Europa weitere Bedeutung zu geben.
Weihnachten für alle 2023
Wir freuen uns darauf, die Adventszeit und die bevorstehenden Feiertage im Kreise unserer Familien und Freunde zu verbringen, und wir hoffen, dass auch Sie diese Zeit genießen können. Doch trotz der festlichen Stimmung dürfen wir nicht die schwierige Lage in vielen Ländern der Erde aus den Augen verlieren.
Wie bereits im letzten Jahr haben wir uns auch in diesem Jahr entschieden, auf Geschenke für unsere Mitarbeitenden und Geschäftspartner zu verzichten. Stattdessen möchten wir erneut die Winterhilfe für die Ukraine unterstützen, welche vom Verein Help e.V. in bewundernswerter Weise organisiert wird.
Unzählige Menschen in der Ukraine sind den winterlichen Temperaturen schutzlos ausgeliefert. Der Krieg hat starke Spuren im ganzen Land hinterlassen. Neben öffentlichen Einrichtungen wurden etwa 170.000 Wohngebäude beschädigt – Häuser, in denen weiterhin Menschen wohnen. Ohne Fenster, die vor Kälte und Wind schützen, ohne ausreichende Wasser‑, Strom- und Gasversorgung. Help leistet Winterhilfe und sorgt dafür, dass Familien ein warmes Zuhause haben und versorgt sie darüber hinaus mit dringend benötigten Hilfsgütern und warmen Mahlzeiten.
Wir denken, dass wir mit unserer Unterstützung für Help auch im Sinne aller unserer Geschäftspartner handeln und hoffen, auf diese Weise ein wenig dazu beitragen zu können, dass Weihnachten auch in der Ukraine ankommt.
Wir und unser gesamtes Team möchten Ihnen von Herzen für Ihr Vertrauen und Ihre Unterstützung im vergangenen Jahr danken. Wir freuen uns auf das kommende Jahr und darauf, mit Ihnen gemeinsam weitere spannende Projekte umzusetzen.
Bis dahin wünschen wir Ihnen eine besinnliche Weihnachtszeit, erholsame freie Tage und einen gelungenen Start ins neue Jahr, voller Chancen und Inspiration.
ID:Smart Workshop 2024 mit SRC GmbH
Am 21. und 22. Februar 2024 findet der
ID:Smart Workshop 2024
in Darmstadt statt.
Der Workshop, der früher unter dem Namen Smartcard-Workshop bekannt war, ist seit 1991 die Referenzveranstaltung für praxisorientierte Forscher, Mitglieder von Standardisierungsgruppen, Entscheidungsträger und Experten aus Unternehmen und staatlichen Verwaltungen.
Hier geht es zur Anmeldung.
Die Beiträge des Workshops befassen sich mit Innovationen, Vorschriften, Standards, Zertifizierungen oder Implementierungen in Bezug auf elektronische Identitäten für vernetzte Geräte und Personen, wobei der Schwerpunkt auf anwendungsbezogenen oder grundlegenden Themen und Forschungsarbeiten liegt, wie z. B.:
Unser Kollege, Detlef Kraus ist Mitglied der Programmbeirats.
Die Konferenzsprache ist Englisch, einschließlich aller Präsentationen.
Detaillierte Hinweise zur Anmeldung und zum Programm finden sie auf der Webseite des ID:Smart Workshops.
Unser Dezember-Blog-Eintrag zu PCI DSS v4.0: Targeted Risk Analysis
Das Jahr neigt sich dem Ende zu – und der PCI DSS v3.2.1 auch.
Das PCI Security Standards Council (PCI SSC) hat gerade neue Dokumente zum neuen Konzept „Targeted Risk Analysis“ (gezielten Risikoanalyse) veröffentlicht – das nehmen wir doch gleich zum Anlass, das Thema mal etwas genauer zu betrachten.
Targeted Risk Analysis – was ist das?
Der PCI DSS v4.0 zielt darauf ab, mehr Flexibilität zu ermöglichen. Eines der Werkzeuge hierfür ist die sogenannte „Targeted Risk Analysis“ (gezielten Risikoanalyse).
Gezielte Risikoanalysen unterscheiden sich von den firmenübergreifenden Risikoanalysen, die in PCI DSS v3.2.1 gefordert waren. Sie betrachten die konkreten Risiken für einen ganz speziellen Anwendungsfall.
Im PCI DSS v4.0 kommen gezielte Risikoanalysen an zwei Stellen vor:
Wir werden uns hier auf den ersten Fall konzentrieren, da wir dem Customized Approach im Februar noch einen eigenen Blog-Eintrag widmen werden.
Wo wird sie gefordert?
Eine gezielte Risikoanalyse wird bei den folgenden Anforderungen gefordert:
Wie kann man die gezielte Risikoanalyse durchführen?
Wie die gezielte Risikoanalyse durchgeführt werden soll, ist in Anforderung 12.3.1 des PCI DSS v4.0 definiert. Hier ist festgelegt, dass die Analyse zunächst mindestens folgende Punkte identifizieren muss:
Zur Bestimmung der entsprechenden Bedrohungen ist es hilfreich, das „Customized Approach Objective“ der entsprechenden bzw. der übergeordneten PCI DSS-Anforderung zu Rate zu ziehen, da in dieser Zielsetzung häufig bereits Bedrohungen benannt sind, gegen die die Anforderung schützen soll.
Werden wir konkret und nehmen als Beispiel die Anforderung 9.5.1.2.1.
Hier sind sowohl die Kartendaten als auch die Zahlgeräte die zu schützenden Assets.
Das „Customized Approach Objective“ der übergeordneten Anforderung 9.5.1.2 ist, dass die Manipulation der Geräte, unautorisierter Austausch der Geräte, sowie das Anbringen von Skimming-Devices nicht ohne zeitnahe Entdeckung durchgeführt werden können.
Typische Bedrohungsszenarien wären also bspw.:
Faktoren, die sich auf die Realisierung der Bedrohungen auswirken können, sind in dem Fall zum Beispiel:
Aus den gesammelten Faktoren resultiert dann schließlich die Analyse, die bestimmt, wie häufig eine Tätigkeit ausgeführt werden muss, um die Wahrscheinlichkeit, dass die Bedrohungen eintreten, zu minimieren.
Faktoren und Ergebnisse der gezielten Risikoanalyse müssen dokumentiert werden.
Mindestens alle 12 Monate muss jede gezielte Risikoanalyse einem Review unterzogen werden, um zu überprüfen, ob sie noch zutrifft. Hat es Veränderungen in den Faktoren oder in der Einschätzung gegeben, muss die Risikoanalyse entsprechend aktualisiert werden.
Hilfestellungen
Wie bei jeder Anforderung des PCI DSS v4.0 lohnt sich als erstes ein Blick in die „Guidance“-Spalte, die im Standard rechts von der Anforderung steht.
Zusätzlich hat das PCI SSC am 28. November 2023 drei unterstützende Dokumente veröffentlicht:
Und wie immer können Sie auch gerne die PCI DSS-Experten von SRC um Unterstützung bitten.
Ausblick
Dies ist der letzte Beitrag zu PCI DSS v4.0 für dieses Jahr. Wir setzen unsere monatliche Blog-Reihe nächstes Jahr fort – freuen Sie sich dann auf die Themen
Kommen Sie gut ins neue Jahr und bleiben Sie gesund!
Der BSI-Lagebericht 2023: Sichern Sie Ihr Unternehmen – entdecken Sie unsere Lösungen
Der jüngste Lagebericht des Bundesamtes für Sicherheit in der Informationstechnik (BSI) für das Jahr 2023 zeichnet ein Bild der deutschen Cybersicherheitslandschaft, das zugleich Herausforderungen und Handlungsaufforderungen offenlegt. Mit dem Fortschreiten der Digitalisierung in allen Lebensbereichen nimmt auch die Komplexität und die Anzahl der Cyberbedrohungen zu.
Konkrekte IT-Sicherheitsbedrohungen 2023
Besonders Ransomware-Angriffe, die darauf abzielen, Unternehmensdaten zu verschlüsseln und Lösegeldforderungen zu stellen, werden immer ausgefeilter und treffen nicht nur Großkonzerne, sondern zunehmend kleinere und mittelständische Unternehmen sowie öffentliche Institutionen.
Ein weiteres prominentes Thema des Berichts ist der potenzielle Missbrauch von Künstlicher Intelligenz (KI). Mit der rasanten Entwicklung von KI-Technologien und deren Anwendungsmöglichkeiten entstehen neue Angriffsmöglichkeiten. KI-gestützte Angriffe, darunter Deep Fakes und manipulierte Chatbots, stellen eine ernstzunehmende Bedrohung dar, die nicht nur die Sicherheit von Informationen, sondern auch die gesellschaftliche Stabilität untergraben kann.
Die geopolitischen Spannungen, insbesondere der Konflikt in der Ukraine, zeigen ferner, dass Cyberangriffe zunehmend auch als Mittel der Kriegsführung und politischen Einflussnahme eingesetzt werden. Diese Entwicklungen sind nicht nur auf staatliche Akteure beschränkt, sondern betreffen auch die Wirtschaft und die Zivilgesellschaft. Das BSI hebt hervor, dass die Sicherheit im Cyberraum nicht mehr nur eine Frage der technischen Abwehr ist, sondern eine gesamtgesellschaftliche Anstrengung erfordert.
Die Empfehlung des BSI, die „Cyberresilienz“ zu stärken, bekräftigt die Notwendigkeit, proaktiv und präventiv vorzugehen. Dies bedeutet, dass Unternehmen und Behörden nicht nur auf Angriffe reagieren, sondern die Widerstandsfähigkeit ihrer Systeme im Voraus verbessern müssen.
Hier setzt die Expertise der SRC GmbH an, einem Unternehmen, das auf die Sicherheitsbedürfnisse im digitalen Zeitalter spezialisiert ist.
Wie SRC helfen kann, Cyberresilienz herzustellen
Nutzen Sie die Erkenntnisse aus dem BSI-Lagebericht 2023 als entscheidenden Impuls, um Ihre Cybersicherheitsmaßnahmen gezielt zu überprüfen und zu optimieren – die SRC GmbH steht bereit, um mit Ihnen die kritischen Sicherheitsbereiche zu stärken und Resilienz gegenüber aktuellen und zukünftigen Cyberbedrohungen aufzubauen
SRC GmbH: Ihr zertifiziertes MPoC-Labor
Einführung des MPoC-Standards
Nach jahrelanger intensiver Arbeit und umfassendem Feedback aus der Gemeinschaft hat die PCI SSC kürzlich ihren neuen Sicherheitsstandard für Kreditkartenzahlungen auf Händlergeräten wie Smartphones oder Tablets veröffentlicht, bekannt als Mobile Payments on Commercial Off-The-Shelf (MPoC).
Integration und Neue Funktionen
Der MPoC-Standard integriert vorhandene Anwendungsfälle aus den CPoC- und SPoC-Standards und fügt neue Zahlungsfunktionalitäten sowie Zertifizierungsmethoden hinzu. Er ermöglicht beispielsweise PIN-basierte Transaktionen ohne zusätzliches Sicherheitsgerät und unterstützt Offline-Transaktionen.
Anerkennung durch den PCI Security Standards Council
Der PCI Security Standards Council (PCI SSC) ist eine globale Organisation, die die Payment Card Industry-Standards für den Schutz von Karteninhaberdaten weltweit pflegt, weiterentwickelt und fördert. Durch die Zertifizierung des SRC GmbH als MPoC-Labor bestätigt der PCI SSC die Fähigkeiten und die Einhaltung der erforderlichen Sicherheitsstandards durch die SRC GmbH.
Ihre Vorteile durch unsere MPoC-Zertifizierung
Wir freuen uns, Ihnen mitteilen zu können, dass die SRC GmbH kürzlich als eines der MPoC-Labore zertifiziert wurde. Unsere Zertifizierung ermöglicht es uns, die MPoC-Software, Attestation & Monitoring Dienste, oder auch komplette MPoC-Lösungen zu zertifizieren. Diese Anerkennung positioniert uns an der Spitze der mobilen Zahlungssicherheit, und wir sind begeistert, Teil dieser fortschrittlichen Bewegung im Zahlungsraum zu sein.
Ihr Partner für mobile Zahlungssicherheit
Entdecken Sie die Möglichkeiten mit SRC GmbH, Ihrem vertrauenswürdigen Partner für mobile Zahlungssicherheit.
Unser November-Blog-Eintrag zu PCI DSS v4.0: Rollen und Verantwortlichkeiten
Neue Unteranforderung in allen Requirements
In PCI DSS Version 4.0 wurde eine neue Unteranforderung in die Anforderungen 1 bis 11 aufgenommen, die die Notwendigkeit betont, Rollen und Verantwortlichkeiten bei der Ausführung der jeweiligen Anforderung x zu dokumentieren, zuzuweisen und zu verstehen (entsprechende Unteranforderung x.1.2).
Viele Firmen fragen sich, wie solch eine Zuweisung von Rollen und Verantwortlichkeiten aussehen kann. Muss ein neues Dokument erstellt werden? Muss dies firmenübergreifend gelten?
Der PCI DSS lässt die Form der Dokumentation bewusst offen. Das Ziel ist es, dass das Personal sich seiner Verantwortlichkeiten bewusst ist, damit die Aktivitäten zuverlässig durchgeführt werden.
Wie kann die Zuweisung der Verantwortlichkeiten also praktisch aussehen?
Nutzung bestehender Dokumentation
In vielen Firmen sind bereits Rollen und Verantwortlichkeiten in bestehenden Richtlinien und Verfahrensanweisungen enthalten.
Ist aber noch keine derartige Dokumentation vorhanden, sollte sie erstellt werden. Ob die Zuweisung dabei im bestehenden Dokument ergänzt wird, oder ab man ein zusätzliches Dokument erstellt, ist dabei unerheblich.
Form der Darstellung
Auch die Form der Darstellung ist frei wählbar. Natürlich bietet sich eine RACI-Matrix oder eine Variante davon an. Aber auch andere Tabellen, Listen oder Fließtexte können den Zweck erfüllen.
Bei großen Teams mit gleichartigen Aufgaben reicht dabei oft eine Zuweisung wie „das Personal ist für die Durchführung von Aktivität X zuständig, der Teamleiter ist für die Schulung des Personals bei Einstellung, bei Aufgabenwechsel und im jährlichen Rhythmus sowie für die Freigabe der Ergebnisse zuständig“ – bei durchmischten Teams mit vielfältigen Aufgaben muss die Zuweisung ggf. bis auf einzelne Personen runtergebrochen werden.
Anlehnung an die operative Umsetzung
Bleiben Sie nicht zu nah an der Requirement-Aufteilung des PCI DSS – übersetzen Sie, wie Sie die Einhaltung sicherheitsrelevanter Prozesse in Ihrem eigenen operativen Geschäft umsetzen. Häufig sind an der Umsetzung einer Anforderung mehrere Rollen beteiligt – eine schreibt ggf. die Regeln auf, eine andere Rolle hält die Regeln bei der Umsetzung ein, wieder eine andere Rolle macht einen Review und/oder eine Freigabe des Umgesetzten. Wenn Sie die Schritte aufschreiben, wie Sie etwas durchführen, lässt sich gut zuordnen, wer für die jeweilige Tätigkeit zuständig ist.
Akzeptanz der Verantwortlichkeit
Die Zuweisung sollte natürlich nicht nur dokumentiert sein, sondern den Personen auch bekannt sein. Entsprechend sollte ein neues oder angepasstes Dokument im Kreis der Betroffenen vorgestellt werden.
Müssen die Personen unterschreiben, dass Ihnen ihre Verantwortung bewusst ist? In einer anderen Anforderung des PCI DSS v4.0, Anforderung 12.1.3, wird tatsächlich eine schriftliche Anerkennung der allgemeinen Verantwortung für die Informationssicherheit gefordert. Eine entsprechende dokumentierte Anerkennung der spezifischen Verantwortlichkeiten der jeweiligen Rolle wird in Anforderung x.1.2 nicht zwingend gefordert – man kann diese beiden Punkte, wenn man möchte, aber natürlich miteinander verbinden, indem man nicht nur eine generische, sondern auch rollenspezifische Verantwortlichkeiten abzeichnen lässt. Diese Kombination ist jedoch nicht vorgeschrieben.
Zusammenfassung
Was sollte also am Ende der Überlegungen mindestens stehen?
Auf diese Weise sollte die Einhaltung der Unteranforderungen x.1.2 machbar sein.
SRC GmbH freut sich über Auftrag für die Telematikinfrastruktur Deutschlands
NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS
Wir, die SRC GmbH, Anbieter von IT-Sicherheitsprüfungen und IT-Beratungsdienstleistungen, freuen uns, dass wir erfolgreich an einer Ausschreibung des Bundesamtes für Sicherheit in der Informationstechnik (BSI) teilgenommen und den Zuschlag erhalten haben. Wir freuen uns hiermit einen Beitrag zur wachsende Bedeutung der Digitalisierung im deutschen Gesundheitswesen und der IT-Sicherheit beitragen zu können.
Unsere Expertise wird in den kommenden Aufgaben im Bereich der Telematikinfrastruktur (TI) eingesetzt, die eine entscheidende Rolle bei der Vernetzung von Gesundheitseinrichtungen und dem sicheren Austausch von Gesundheitsdaten spielt.
Wir werden das BSI bei seinen gesetzlichen Aufgaben unterstützen, insbesondere in den Bereichen Prüfmechanismen, Spezifikationen und technische Richtlinien.
Das Team der SRC GmbH freut sich auf die zukünftige Zusammenarbeit mit dem Bundesamt für Sicherheit in der Informationstechnik (BSI) und sieht stolz der Gelegenheit entgegen, einen bedeutenden Beitrag zur sicheren Digitalisierung des deutschen Gesundheitswesens zu leisten.
Kontakt für weitere Informationen: Randolf Skerka
Unser Oktober-Blog-Eintrag zu PCI DSS v4.0
Nachweise im PCI DSS-Audit
In dieser Folge unsere PCI DSS v4.0‑Blogs erläutern wir, welche Pflichten Auditoren beim Nachweis ihrer Audit-Ergebnisse haben, und wie Sie am besten die Erbringung angemessener Nachweise für PCI DSS v4.0‑Audits vorbereiten.
Auditprozess
Im Laufe eines PCI DSS-Assessments (oder, wie wir im Deutschen häufig sagen, ‑Audits) prüfen Auditoren, inwieweit die PCI DSS-Anforderungen bei einem Unternehmen umgesetzt sind.
Üblicherweise beinhaltet ein Auditprozess die folgenden Prüfschritte:
Dies ändert sich auch nicht mit der Migration auf PCI DSS v4.0.
Nachweispflichten
Welche Notizen eine Auditorin sich macht und welche Nachweise sie wie ablegt, bleibt für die auditierte Firma normalerweise im Verborgenen. Wir geben Ihnen hier einen kleinen Einblick, was sich dort mit PCI DSS v4.0 verändert.
Das PCI SSC hat mit dem neuen Reporting Template für PCI DSS v4.0 sowie mit einem Update des PCI DSS Program Guide für QSAs jetzt klargestellt, dass sie für jeden Prüfschritt fordern, dass der Auditor einen entsprechenden Nachweis abgelegt. Die prüft das PCI SSC auch stichprobenartig bei den Auditfirmen.
Für Dokumente ist dies einfach: der Nachweis ist das jeweilige Dokumente selbst. Ähnlich ist es bei Protokollen/Ergebnissen – hier muss nur darauf geachtet werden, dass klar ist, um welches System oder welchen Prozess es hier geht.
Falls Sie einem Auditor einen Screenshot oder eine Datei als Nachweis schicken, achten Sie daher bitte darauf, die Information mitzuliefern, um welche Systemkomponente und/oder welche Prozess es geht.
Beim Review von Systemkomponenten/-einstellungen ist es notwendig, dass der Auditor sich dedizierte Notizen zu dem jeweiligen System und der jeweiligen Einstellung macht.
Beim Review von Prozessen oder physischen Gegebenheiten muss die jeweilige Gegebenheit detailliert beschrieben werden, und es muss dargestellt werden, welche Schlüsse die Auditorin aus der Beobachtung zieht. In ähnlicher Form wird auch bei einem Interview erwartet, dass die Auditorin grob die Fragen und Antworten mitschreibt.
Geben Sie bitte dem Auditor im Audit genügend Zeit, sich entsprechende Notizen zu machen. An vielen Stellen kann es die Schreibarbeit verkürzen, wenn der Auditor Kopien oder Screenshots bereitgestellt bekommt oder Fotos machen darf.
Der PCI DSS v4.0 listet etwa 250 Unterpunkte zu den 12 Haupt-Anforderungen auf – entsprechend viele Nachweise benötigt der Auditor.
Aufbewahrungspflichten
Der PCI DSS Program Guide schreibt vor, dass alle oben genannten Nachweise von der Auditfirma für mindestens drei Jahre sicher aufbewahrt werden müssen und auf Anfrage dem PCI SSC und den zugehörigen Gesellschaften verfügbar gemacht werden müssen.
Aus Datenschutz- oder Vertraulichkeitsgründen kommt es vor, dass Unternehmen es für einzelne Nachweise nicht erlauben, dass die Auditorin sie mitnehmen und ablegen darf. In diesem Fall regelt das PCI SSC, dass die Ablage stattdessen bei dem auditierten Unternehmen erfolgen darf. Die Anforderungen an Aufbewahrungsfrist und Verfügbarkeit sind in diesem Fall die gleichen.
Da die Nachweispflichten mit PCI DSS v4.0 größer geworden sind, wird auch dieser Fall in Zukunft häufiger vorkommen.
Wenn Sie erwarten, dass nicht alle Nachweise an den Auditor weitergegeben werden dürfen, bereiten Sie sich als auditiertes Unternehmen am besten vor, indem Sie
Umgang mit Abweichungen
Wie sieht es mit den Nachweisen aus, wenn im Audit nicht sofort die Erfüllung aller Anforderungen nachgewiesen werden konnte, sondern Abweichungen festgestellt wurden?
Geplante Abweichungen
Der einfachste Fall ist es, wenn Sie als auditiertes Unternehmen bereits vorab erkannt haben, dass Sie eine Anforderung nicht erfüllen können oder nicht auf dem vorgegebenen Weg erfüllen möchten. In diesem Fall haben Sie zum Audit bereits eine Dokumentation einer Compensating Control oder eines Customized Approaches vorbereitet. Hierbei kann Ihnen auch ein PCI DSS-Experte helfen – es darf nur nicht der gleiche sein, der die Umsetzung dann auch prüft.
Zum Customized Approach werden wir in einer späteren Folge unseres PCI DSS v4.0‑Blogs noch ausführlich Stellung nehmen.
In beiden Fällen wird die Auditorin die Nachweise der Compensating Control oder des Customized Approaches Ihres Unternehmens prüfen, ggf. Rückfragen stellen, und dann geeignete Prüfmethoden ableiten und durchführen. Die Pflichten zum Erheben von Nachweisen ergeben sich dabei aus der jeweiligen Prüfmethode.
Ungeplante Abweichungen – „INFI“
Treten während eines Auditzeitraums ungeplante Abweichungen von den PCI DSS-Anforderungen auf, müssen diese behoben werden und die Behebung durch den Auditor verifiziert werden. Dies war bereits unter PCI DSS v3.2.1 so.
Der PCI DSS v4.0 verlangt zusätzlich explizit, dass der Grund für das Auftreten der Abweichung identifiziert wird, und dass Prozesse implementiert sind, die ein erneutes Auftreten solch einer Abweichung verhindern. Nur in dem Fall kann der Auditor die Anforderung noch als erfüllt ansehen.
Im neuen „Items Noted For Improvement” (INFI)-Dokument müssen bei jedem PCI DSS v4.0‑Audit alle Abweichungen, ihre Gründe, die korrektiven und präventiven Maßnahmen dokumentiert werden.
Die Auditorin stellt dem auditierten Unternehmen zum Abschluss des Audits das INFI-Dokument zur Verfügung, und beide Parteien unterschreiben es. Das INFI-Dokument belegt, dass das auditierte Unternehmen die Abweichungen erfolgreich bewältigt hat. Das Dokument kann im auditierten Unternehmen intern verwendet werden – bspw. in Compliance- und Risiko-Abteilungen – und auf dessen Wunsch auch mit Dritten geteilt werden. Eine Verpflichtung zur Vorlage des INFI-Dokuments gibt es nicht, und es wird auch nicht in der Attestation of Compliance (AoC) referenziert.
Gerade bei regelmäßig zu wiederholenden Prozessen kommt es immer mal wieder dazu, dass sich eine Durchführung verspätet, z.B. bei der Durchführung von
Überlegen Sie sich am besten bereits im Vorfeld, wie Sie Ihre Prozesse so gestalten, dass Sie die vorgeschriebenen Zeiträume einhalten und Verspätungen sofort bemerken.
Bei Fragen unterstützen wir Sie gerne, melden Sie sich per E‑Mail bei Frau Jana Ehlers.