SRC und die DAkkS-Akkre­di­tierung nach ISO/IEC EN 17025: Ein wichtiger Schritt in Richtung EUCC 

SRC Security Research & Consulting GmbH kann einen weiteren bedeu­tenden Erfolg verzeichnen: Die erfolg­reiche Akkre­di­tierung durch die Deutsche Akkre­di­tie­rungs­stelle (DAkkS) nach DIN EN ISO/IEC 17025. Dieser Schritt unter­streicht nicht nur die Kompetenz und Zuver­läs­sigkeit 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äi­schen Cybersicherheitslandschaft.

Bedeutung der DAkkS-Akkreditierung

Die Akkre­di­tierung nach DIN EN ISO/IEC 17025 ist ein klares Zeichen für die Profes­sio­na­lität und den Anspruch von SRC, erstklassige Prüfdienst­leis­tungen anzubieten. Sie bestätigt, dass unser CC-Prüflabors den inter­na­tional anerkannten Standards entspricht und vertrau­ens­würdige, konsis­tente Ergeb­nisse liefert.

Vorbe­reitung auf die EUCC

Die EUCC stellt das auf den Common Criteria basie­rende europäische Zerti­fi­zie­rungs­schema dar, soll die Sicher­heits­zer­ti­fi­zierung von IKT-Produkten in Europa verbessern. Mit unserer DAkkS-Akkre­di­tierung ist SRC nun bestens gerüstet, um die Heraus­for­de­rungen der EUCC zu meistern und eine führende Rolle in der IT-Sicher­heits­zer­ti­fi­zierung in Europa zu übernehmen. Die EUCC erweitert die Anfor­de­rungen der bishe­rigen Common Criteria und wird künftige Zerti­fi­zie­rungen in der EU grund­legend prägen.

Unser Engagement für Qualität und Genauigkeit

Mit dieser Akkre­di­tierung demons­triert SRC sein Engagement für höchste Quali­täts­stan­dards und Unpar­tei­lichkeit in unseren Labor­tä­tig­keiten. Wir sind stolz darauf, diesen Meilen­stein erreicht zu haben und freuen uns darauf, unseren Kunden weiterhin Dienst­leis­tungen auf höchstem Niveau anzubieten.

Bei weiteren Fragen stehen unser Sales-Team Ihnen jederzeit zur Verfügung!

SRC TeleTrusT

SRC ist dem Bundes­verband IT Sicherheit (TeleTrusT) angeschlossen

SRC hat sich dem Bundes­verband IT Sicherheit (TeleTrusT) angeschlossen.

Der Bundes­verband IT-Sicherheit e.V. (TeleTrusT) ist ein Kompe­tenz­netzwerk, das in- und auslän­dische Mitglieder aus Industrie, Verwaltung, Beratung und Wissen­schaft sowie thema­tisch verwandte Partner­or­ga­ni­sa­tionen umfasst.

Aufgrund der permanent ändernden Anfor­de­rungen im Bereich IT-Sicherheit ist es für SRC von Bedeutung, dass sich ihre Experten regel­mäßig über neue Notwendig­keiten, Techniken, Prozesse und Regularien infor­mieren und austau­schen müssen.

TeleTrusT bietet hierfür insbe­sondere gute Voraus­set­zungen, da neben dem Austauch der Experten aus der Wirtschaft auch der Kontakt zu Politik und Wissen­schaft herge­stellt ist.

SRC wird sich mit ihrer breit gefächerten Expertise in die verschie­denen Arbeits­gruppen 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 bevor­ste­henden 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 Mitar­bei­tenden und Geschäfts­partner zu verzichten. Statt­dessen möchten wir erneut die Winter­hilfe für die Ukraine unter­stützen, welche vom Verein Help e.V. in bewun­derns­werter Weise organi­siert wird.

Unzählige Menschen in der Ukraine sind den winter­lichen Tempe­ra­turen schutzlos ausge­liefert. Der Krieg hat starke Spuren im ganzen Land hinter­lassen. Neben öffent­lichen Einrich­tungen wurden etwa 170.000 Wohnge­bäude beschädigt – Häuser, in denen weiterhin Menschen wohnen. Ohne Fenster, die vor Kälte und Wind schützen, ohne ausrei­chende Wasser‑, Strom- und Gasver­sorgung. Help leistet Winter­hilfe und sorgt dafür, dass Familien ein warmes Zuhause haben und versorgt sie darüber hinaus mit dringend benötigten Hilfs­gütern und warmen Mahlzeiten.

Wir denken, dass wir mit unserer Unter­stützung für Help auch im Sinne aller unserer Geschäfts­partner 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 Unter­stützung im vergan­genen 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 besinn­liche Weihnachtszeit, erholsame freie Tage und einen gelun­genen 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 Referenz­ver­an­staltung für praxis­ori­en­tierte Forscher, Mitglieder von Standar­di­sie­rungs­gruppen, Entschei­dungs­träger und Experten aus Unter­nehmen und staat­lichen Verwaltungen.

Hier geht es zur Anmeldung.

Die Beiträge des Workshops befassen sich mit Innova­tionen, Vorschriften, Standards, Zerti­fi­zie­rungen oder Imple­men­tie­rungen in Bezug auf elektro­nische Identi­täten für vernetzte Geräte und Personen, wobei der Schwer­punkt auf anwen­dungs­be­zo­genen oder grund­le­genden Themen und Forschungs­ar­beiten liegt, wie z. B.:

  • Alle Aspekte der Lebens­zyklen digitaler Identitäten
  • Techno­logien und bewährte Praktiken der Branche in Bezug auf Krypto­grafie als PQC, Konfor­mitäts- und Inter­ope­ra­bi­li­täts­tests, Bewertung und Zertifizierung
  • Identi­täts­tech­no­logien wie Reise- und Ausweis­do­ku­mente, Brief­ta­schen, quali­fi­zierte elektro­nische Beschei­nigung von Eigen­schaften, Identi­täts­nachweis usw.
  • Anwen­dungs­fälle für Verbraucher und Indus­trien wie Secure IoT, Automation, Gesund­heits­wesen, Mobilität/Automobil, Regie­rungs­dienste und andere.

Unser Kollege, Detlef Kraus ist Mitglied der Programmbeirats.

 

Die Konfe­renz­sprache ist Englisch, einschließlich aller Präsentationen.

Detail­lierte Hinweise zur Anmeldung und zum Programm finden sie auf der Webseite des ID:Smart Workshops.

PCI DSS

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 Risiko­analyse) veröf­fent­licht – 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 Flexi­bi­lität zu ermög­lichen. Eines der Werkzeuge hierfür ist die sogenannte „Targeted Risk Analysis“ (gezielten Risikoanalyse).

Gezielte Risiko­ana­lysen unter­scheiden sich von den firmen­über­grei­fenden Risiko­ana­lysen, die in PCI DSS v3.2.1 gefordert waren. Sie betrachten die konkreten Risiken für einen ganz spezi­ellen Anwendungsfall.

Im PCI DSS v4.0 kommen gezielte Risiko­ana­lysen an zwei Stellen vor:

  • Einige Anfor­de­rungen des Standards verlangen gezielte Risiko­ana­lysen, um festzu­legen, wie häufig eine bestimmte regel­mäßige Maßnahme durch­ge­führt werden sollte.
  • Außerdem ist die gezielte Risiko­analyse Teil des sogenannten „Custo­mized Approach“, mit dem man eine Anfor­derung auf eigene Weise, abwei­chend von der wortwört­lichen Umsetzung, umsetzen kann.

Wir werden uns hier auf den ersten Fall konzen­trieren, da wir dem Custo­mized Approach im Februar noch einen eigenen Blog-Eintrag widmen werden.

Wo wird sie gefordert?

Eine gezielte Risiko­analyse wird bei den folgenden Anfor­de­rungen gefordert:

  • 5.2.3.1: Wenn eine Organi­sation für System­kom­po­nenten evaluiert hat, dass diese üblicher­weise nicht von Malware betroffen sind und daher keine Anti-Malware-Lösung benötigen, dann muss in regel­mä­ßigen Abständen überprüft werden, ob dies immer noch so ist. Die Häufigkeit dieser Überprü­fungen muss in einer gezielten Risiko­analyse festgelegt werden.
  • 5.3.2.1: Wenn regel­mäßige Malware-Scans verwendet werden, muss deren Häufigkeit in einer gezielten Risiko­analyse festgelegt werden.
  • 7.2.5.1: Häufig gibt es nicht nur Nutzer­konten, die von Personen genutzt werden, sondern auch technische Nutzer­konten, die von Systemen oder Anwen­dungen genutzt werden. Deren Zugriffs­rechte müssen regel­mäßig überprüft werden. Die Häufigkeit dieser Überprü­fungen muss in einer gezielten Risiko­analyse festgelegt werden.
  • 8.6.3: Passwörter für die genannten techni­schen Nutzer­konten müssen geschützt werden. Die Häufigkeit der Passwort­wechsel und die Passwort-Komple­xität müssen in einer gezielten Risiko­analyse festgelegt werden.
  • 9.5.1.2.1: Zahlgeräte (Zahlter­minals) am Point of Inter­action müssen regel­mäßig inspi­ziert werden, um Manipu­la­tionen oder gar ihren Austausch zu erkennen. Die Häufigkeit und Art der Inspek­tionen müssen in einer gezielten Risiko­analyse festgelegt werden.
  • 10.4.2.1: Sicher­heits­kri­tische Logs (Security Events sowie Logs von Systemen, die mit Karten­daten in Berührung kommen, Sicher­heits­funk­tio­na­lität haben oder ander­weitig kritisch sind) müssen mindestens einmal am Tag einem Review unter­zogen werden, um auffällige Aktivi­täten zeitnah zu entdecken. Die Häufigkeit des Reviews für alle anderen Logs muss in einer gezielten Risiko­analyse festgelegt werden.
  • 11.3.1.1: Werden bei internen Schwach­stel­len­scans hochris­kante oder kritische Schwach­stellen entdeckt, müssen diese behoben werden. Für niedriger einge­stufte Schwach­stellen muss eine gezielte Risiko­analyse festlegen, wie diese zu adres­sieren sind.
  • 11.6.1: E‑Com­merce-Zahlseiten müssen regel­mäßig mit einem Mecha­nismus zur Erkennung von Änderungen und Manipu­la­tionen überprüft werden. Dieser Mecha­nismus muss mindestens alle sieben Tage angewendet werden – andern­falls muss eine geringere Häufigkeit mit einer gezielten Risiko­analyse begründet werden.
  • 12.10.4.1: Das Personal, das für die Reaktion auf Sicher­heits­vor­fälle zuständig ist, muss darin geschult werden. Die Häufigkeit dieser Schulungen muss in einer gezielten Risiko­analyse festgelegt werden.

Wie kann man die gezielte Risiko­analyse durchführen?

Wie die gezielte Risiko­analyse durch­ge­führt werden soll, ist in Anfor­derung 12.3.1 des PCI DSS v4.0 definiert. Hier ist festgelegt, dass die Analyse zunächst mindestens folgende Punkte identi­fi­zieren muss:

  • Die zu schüt­zenden Güter (Assets). Zu schüt­zende Assets sind natürlich immer die Karten­daten selbst, aber zusätzlich können es auch Assets wie Systeme oder Passwörter sein.
  • Die Bedro­hungen, gegen die die entspre­chende PCI DSS-Anfor­derung schützen soll.
    Zur Bestimmung der entspre­chenden Bedro­hungen ist es hilfreich, das „Custo­mized Approach Objective“ der entspre­chenden bzw. der überge­ord­neten PCI DSS-Anfor­derung zu Rate zu ziehen, da in dieser Zielsetzung häufig bereits Bedro­hungen benannt sind, gegen die die Anfor­derung schützen soll.
  • Faktoren, die die Eintritts­wahr­schein­lichkeit und/oder die Auswir­kungen der Reali­sierung der genannten Bedro­hungen beitragen.

Werden wir konkret und nehmen als Beispiel die Anfor­derung 9.5.1.2.1.

Hier sind sowohl die Karten­daten als auch die Zahlgeräte die zu schüt­zenden Assets.

Das „Custo­mized Approach Objective“ der überge­ord­neten Anfor­derung 9.5.1.2 ist, dass die Manipu­lation der Geräte, unauto­ri­sierter Austausch der Geräte, sowie das Anbringen von Skimming-Devices nicht ohne zeitnahe Entde­ckung durch­ge­führt werden können.

Typische Bedro­hungs­sze­narien wären also bspw.:

  • Angreifer bringen Skimming-Devices an, welche Eingaben mitlesen.
  • Angreifer geben sich als Service-Techniker oder Mitar­beiter des Geräte-Providers aus und tauschen das Zahlgerät durch ein manipu­liertes Zahlgerät aus, welches die Karten­daten anschließend mitliest und an Angrei­fende weiterleitet.
  • Angreifer stehlen ein Zahlgerät, auf dem im Fall von offline Trans­ak­tionen Daten temporär gespei­chert sein könnten.
  • Angreifer manipu­lieren das Zahlgerät so, dass dessen Sicher­heits­funk­tio­na­lität geschwächt wird (bspw. Verschlüs­selung ausgeschaltet).

Faktoren, die sich auf die Reali­sierung der Bedro­hungen auswirken können, sind in dem Fall zum Beispiel:

  • Wie leicht ist das Zahlgerät für Kunden und Dritte erreichbar? Ist es sicher befestigt?
  • Ist das Zahlgerät dauerhaft unter Beaufsichtigung?
  • Wie gut ist das Personal vor Ort quali­fi­ziert und geschult?
  • Sind das Zahlgerät und die Daten darin vor Manipu­la­tionen geschützt, und ist dies durch eine PCI PTS-Zerti­fi­zierung des Geräts und/oder eine PCI P2PE-Zerti­fi­zierung der ganzen Lösung nachgewiesen?
  • Wie stark frequen­tiert ist das Zahlgerät? (Das kann einen Einfluss darauf haben, ob es ein besonders lohnens­wertes Ziel für den Angreifer ist.)
  • Hat der Geräte-Provider in seiner Dokumen­tation Empfeh­lungen gegeben, wie häufig die Geräte überprüft werden sollen?

Aus den gesam­melten Faktoren resul­tiert dann schließlich die Analyse, die bestimmt, wie häufig eine Tätigkeit ausge­führt werden muss, um die Wahrschein­lichkeit, dass die Bedro­hungen eintreten, zu minimieren.

Faktoren und Ergeb­nisse der gezielten Risiko­analyse müssen dokumen­tiert werden.

Mindestens alle 12 Monate muss jede gezielte Risiko­analyse einem Review unter­zogen werden, um zu überprüfen, ob sie noch zutrifft. Hat es Verän­de­rungen in den Faktoren oder in der Einschätzung gegeben, muss die Risiko­analyse entspre­chend aktua­li­siert werden.

Hilfe­stel­lungen

Wie bei jeder Anfor­derung des PCI DSS v4.0 lohnt sich als erstes ein Blick in die „Guidance“-Spalte, die im Standard rechts von der Anfor­derung steht.

Zusätzlich hat das PCI SSC am 28. November 2023 drei unter­stüt­zende Dokumente veröffentlicht:

Und wie immer können Sie auch gerne die PCI DSS-Experten von SRC um Unter­stützung bitten.

Ausblick

Dies ist der letzte Beitrag zu PCI DSS v4.0 für dieses Jahr. Wir setzen unsere monat­liche Blog-Reihe nächstes Jahr fort – freuen Sie sich dann auf die Themen

  • Januar: Änderungen im E‑Commerce: Was ändert sich beim Self-Assessment Questi­on­naire A?
  • Februar: Custo­mized Approach
  • März: Änderungen im E‑Commerce: Integri­täts­schutz von Zahlseiten.

Kommen Sie gut ins neue Jahr und bleiben Sie gesund!

BSI Lagebericht 2023

Der BSI-Lagebe­richt 2023: Sichern Sie Ihr Unter­nehmen – entdecken Sie unsere Lösungen

Der jüngste Lagebe­richt des Bundes­amtes für Sicherheit in der Infor­ma­ti­ons­technik (BSI) für das Jahr 2023 zeichnet ein Bild der deutschen Cyber­si­cher­heits­land­schaft, das zugleich Heraus­for­de­rungen und Handlungs­auf­for­de­rungen offenlegt. Mit dem Fortschreiten der Digita­li­sierung in allen Lebens­be­reichen nimmt auch die Komple­xität und die Anzahl der Cyber­be­dro­hungen zu. 

Konkrekte IT-Sicher­heits­be­dro­hungen 2023

Besonders Ransomware-Angriffe, die darauf abzielen, Unter­neh­mens­daten zu verschlüsseln und Lösegeld­for­de­rungen zu stellen, werden immer ausge­feilter und treffen nicht nur Großkon­zerne, sondern zunehmend kleinere und mittel­stän­dische Unter­nehmen sowie öffent­liche Institutionen.

Ein weiteres promi­nentes Thema des Berichts ist der poten­zielle Missbrauch von Künst­licher Intel­ligenz (KI). Mit der rasanten Entwicklung von KI-Techno­logien und deren Anwen­dungs­mög­lich­keiten entstehen neue Angriffs­mög­lich­keiten. KI-gestützte Angriffe, darunter Deep Fakes und manipu­lierte Chatbots, stellen eine ernst­zu­neh­mende Bedrohung dar, die nicht nur die Sicherheit von Infor­ma­tionen, sondern auch die gesell­schaft­liche Stabi­lität unter­graben kann.

Die geopo­li­ti­schen Spannungen, insbe­sondere der Konflikt in der Ukraine, zeigen ferner, dass Cyber­an­griffe zunehmend auch als Mittel der Kriegs­führung und politi­schen Einfluss­nahme einge­setzt werden. Diese Entwick­lungen sind nicht nur auf staat­liche Akteure beschränkt, sondern betreffen auch die Wirtschaft und die Zivil­ge­sell­schaft. Das BSI hebt hervor, dass die Sicherheit im Cyberraum nicht mehr nur eine Frage der techni­schen Abwehr ist, sondern eine gesamt­ge­sell­schaft­liche Anstrengung erfordert.

Die Empfehlung des BSI, die „Cyber­re­si­lienz“ zu stärken, bekräftigt die Notwen­digkeit, proaktiv und präventiv vorzu­gehen. Dies bedeutet, dass Unter­nehmen und Behörden nicht nur auf Angriffe reagieren, sondern die Wider­stands­fä­higkeit ihrer Systeme im Voraus verbessern müssen.

Hier setzt die Expertise der SRC GmbH an, einem Unter­nehmen, das auf die Sicher­heits­be­dürf­nisse im digitalen Zeitalter spezia­li­siert ist.

Wie SRC helfen kann, Cyber­re­si­lienz herzu­stellen 

  • Risiko­analyse und Prävention: SRC bietet indivi­duelle Risiko­ana­lysen, um Unter­nehmen dabei zu unter­stützen, ihre Schwach­stellen zu identi­fi­zieren und zu beheben, bevor sie ausge­nutzt werden können.
  • Sicher­heits­ar­chi­tektur und Design: Durch das Design von robusten Sicher­heits­ar­chi­tek­turen trägt SRC dazu bei, dass die Systeme ihrer Kunden auch gegen fortschritt­liche Bedro­hungen bestehen können.
  • Schulungen und Bewusstsein: SRC organi­siert Schulungen für Mitar­beiter, um das Bewusstsein für Cyber­si­cherheit zu schärfen und sicher­zu­stellen, dass Sicher­heits­richt­linien verstanden und einge­halten werden.
  • Regula­to­rische Compliance und Standards: SRC berät zum Thema regula­to­rische Anfor­de­rungen und hilft Unter­nehmen, den gesetz­lichen und norma­tiven Anfor­de­rungen zu entsprechen.
  • Innovation und Techno­lo­gie­be­ratung: Mit Expertise in modernen Techno­logien wie Block­chain und KI entwi­ckelt SRC innovative Lösungen, die nicht nur sicher, sondern auch zukunfts­ori­en­tiert sind.
  • Notfall­planung und Reaktion: Im Falle eines Cyber­an­griffs unter­stützt SRC bei der schnellen Reaktion und Bereit­stellung von Notfall­plänen, um den Schaden zu minimieren und den Geschäfts­be­trieb aufrechtzuerhalten

Nutzen Sie die Erkennt­nisse aus dem BSI-Lagebe­richt 2023 als entschei­denden Impuls, um Ihre Cyber­si­cher­heits­maß­nahmen gezielt zu überprüfen und zu optimieren – die SRC GmbH steht bereit, um mit Ihnen die kriti­schen Sicher­heits­be­reiche zu stärken und Resilienz gegenüber aktuellen und zukünf­tigen Cyber­be­dro­hungen aufzubauen

SRC GmbH: Ihr zerti­fi­ziertes MPoC-Labor

Einführung des MPoC-Standards
Nach jahre­langer inten­siver Arbeit und umfas­sendem Feedback aus der Gemein­schaft hat die PCI SSC kürzlich ihren neuen Sicher­heits­standard für Kredit­kar­ten­zah­lungen auf Händler­ge­räten wie Smart­phones oder Tablets veröf­fent­licht, bekannt als Mobile Payments on Commercial Off-The-Shelf (MPoC).

Integration und Neue Funktionen
Der MPoC-Standard integriert vorhandene Anwen­dungs­fälle aus den CPoC- und SPoC-Standards und fügt neue Zahlungs­funk­tio­na­li­täten sowie Zerti­fi­zie­rungs­me­thoden hinzu. Er ermög­licht beispiels­weise PIN-basierte Trans­ak­tionen ohne zusätz­liches Sicher­heits­gerät und unter­stützt Offline-Transaktionen.

Anerkennung durch den PCI Security Standards Council
Der PCI Security Standards Council (PCI SSC) ist eine globale Organi­sation, die die Payment Card Industry-Standards für den Schutz von Karten­in­haber­daten weltweit pflegt, weiter­ent­wi­ckelt und fördert. Durch die Zerti­fi­zierung des SRC GmbH als MPoC-Labor bestätigt der PCI SSC die Fähig­keiten und die Einhaltung der erfor­der­lichen Sicher­heits­stan­dards 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 zerti­fi­ziert wurde. Unsere Zerti­fi­zierung ermög­licht es uns, die MPoC-Software, Attestation & Monitoring Dienste, oder auch komplette MPoC-Lösungen zu zerti­fi­zieren. Diese Anerkennung positio­niert uns an der Spitze der mobilen Zahlungs­si­cherheit, und wir sind begeistert, Teil dieser fortschritt­lichen Bewegung im Zahlungsraum zu sein.

Ihr Partner für mobile Zahlungssicherheit
Entdecken Sie die Möglich­keiten mit SRC GmbH, Ihrem vertrau­ens­wür­digen Partner für mobile Zahlungssicherheit.

Unser November-Blog-Eintrag zu PCI DSS v4.0: Rollen und Verantwortlichkeiten

Neue Unter­an­for­derung in allen Requirements

In PCI DSS Version 4.0 wurde eine neue Unter­an­for­derung in die Anfor­de­rungen 1 bis 11 aufge­nommen, die die Notwen­digkeit betont, Rollen und Verant­wort­lich­keiten bei der Ausführung der jewei­ligen Anfor­derung x zu dokumen­tieren, zuzuweisen und zu verstehen (entspre­chende Unter­an­for­derung x.1.2).

Viele Firmen fragen sich, wie solch eine Zuweisung von Rollen und Verant­wort­lich­keiten aussehen kann. Muss ein neues Dokument erstellt werden? Muss dies firmen­über­greifend gelten?

Der PCI DSS lässt die Form der Dokumen­tation bewusst offen. Das Ziel ist es, dass das Personal sich seiner Verant­wort­lich­keiten bewusst ist, damit die Aktivi­täten zuver­lässig durch­ge­führt werden.

  • Fast jedem PCI DSS-Assessor ist es schon mal begegnet, dass Schwach­stel­len­scans nicht pünktlich jedes Vierteljahr durch­ge­führt wurden, weil es einfach übersehen wurde – hier hilft eine klar zugewiesene Verant­wort­lichkeit für die Einhaltung des Vierteljahres-Rhythmus.
  • Fast jeder PCI DSS-Asses­sorin ist schon einmal Kassen­per­sonal begegnet, dem nicht bewusst war, dass sie Zahlter­minals auf Verdacht auf Manipu­lation oder Austausch überprüfen müssen. Auch diese Verant­wort­lichkeit sollte klar benannt werden – ebenso die der Rolle, die das Kassen­per­sonal dafür schult.

Wie kann die Zuweisung der Verant­wort­lich­keiten also praktisch aussehen?

Nutzung bestehender Dokumentation

In vielen Firmen sind bereits Rollen und Verant­wort­lich­keiten in bestehenden Richt­linien und Verfah­rens­an­wei­sungen enthalten.

  • Ist bspw. in der Software­ent­wick­lungs­richt­linie bereits enthalten, wer den Code entwi­ckelt, wer den Code-Review durch­führt, wer Tests durch­führt und wer die Freigabe für den Rollout als Teil des Prozesses gibt? Und ist in Inter­views allen Betei­ligten diese Rollen­zu­weisung klar? Dann muss hier im Bereich Software­ent­wicklung nichts mehr ergänzt werden.

Ist aber noch keine derartige Dokumen­tation vorhanden, sollte sie erstellt werden. Ob die Zuweisung dabei im bestehenden Dokument ergänzt wird, oder ab man ein zusätz­liches 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 gleich­ar­tigen Aufgaben reicht dabei oft eine Zuweisung wie „das Personal ist für die Durch­führung von Aktivität X zuständig, der Teamleiter ist für die Schulung des Personals bei Einstellung, bei Aufga­ben­wechsel und im jährlichen Rhythmus sowie für die Freigabe der Ergeb­nisse zuständig“ – bei durch­mischten Teams mit vielfäl­tigen Aufgaben muss die Zuweisung ggf. bis auf einzelne Personen runter­ge­brochen werden.

Anlehnung an die operative Umsetzung 

Bleiben Sie nicht zu nah an der Requi­rement-Aufteilung des PCI DSS – übersetzen Sie, wie Sie die Einhaltung sicher­heits­re­le­vanter Prozesse in Ihrem eigenen opera­tiven Geschäft umsetzen. Häufig sind an der Umsetzung einer Anfor­derung 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 durch­fü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 dokumen­tiert sein, sondern den Personen auch bekannt sein. Entspre­chend sollte ein neues oder angepasstes Dokument im Kreis der Betrof­fenen vorge­stellt werden.

Müssen die Personen unter­schreiben, dass Ihnen ihre Verant­wortung bewusst ist? In einer anderen Anfor­derung des PCI DSS v4.0, Anfor­derung 12.1.3, wird tatsächlich eine schrift­liche Anerkennung der allge­meinen Verant­wortung für die Infor­ma­ti­ons­si­cherheit gefordert. Eine entspre­chende dokumen­tierte Anerkennung der spezi­fi­schen Verant­wort­lich­keiten der jewei­ligen Rolle wird in Anfor­derung x.1.2 nicht zwingend gefordert – man kann diese beiden Punkte, wenn man möchte, aber natürlich mitein­ander verbinden, indem man nicht nur eine generische, sondern auch rollen­spe­zi­fische Verant­wort­lich­keiten abzeichnen lässt. Diese Kombi­nation ist jedoch nicht vorgeschrieben.

Zusam­men­fassung

Was sollte also am Ende der Überle­gungen mindestens stehen?

  • Die Dokumen­tation der Rollen und Verant­wort­lich­keiten für die verschie­denen Aufgaben im opera­tiven Geschäft bei der Absicherung der Arbeit mit Zahlkar­ten­daten, und
  • Personal, das sich seiner Rollen, Verant­wort­lich­keiten und Aufgaben bewusst ist und dies in Inter­views bestä­tigen kann. 

Auf diese Weise sollte die Einhaltung der Unter­an­for­de­rungen x.1.2 machbar sein.

SRC GmbH freut sich über Auftrag für die Telema­tik­in­fra­struktur Deutschlands

NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS

Wir, die SRC GmbH, Anbieter von IT-Sicher­heits­prü­fungen und IT-Beratungs­dienst­leis­tungen, freuen uns, dass wir erfolg­reich an einer Ausschreibung des Bundes­amtes für Sicherheit in der Infor­ma­ti­ons­technik (BSI) teilge­nommen und den Zuschlag erhalten haben. Wir freuen uns hiermit einen Beitrag zur wachsende Bedeutung der Digita­li­sierung im deutschen Gesund­heits­wesen und der IT-Sicherheit beitragen zu können.

Unsere Expertise wird in den kommenden Aufgaben im Bereich der Telema­tik­in­fra­struktur (TI) einge­setzt, die eine entschei­dende Rolle bei der Vernetzung von Gesund­heits­ein­rich­tungen und dem sicheren Austausch von Gesund­heits­daten spielt.

Wir werden das BSI bei seinen gesetz­lichen Aufgaben unter­stützen, insbe­sondere in den Bereichen Prüfme­cha­nismen, Spezi­fi­ka­tionen und technische Richtlinien.

Das Team der SRC GmbH freut sich auf die zukünftige Zusam­men­arbeit mit dem Bundesamt für Sicherheit in der Infor­ma­ti­ons­technik (BSI) und sieht stolz der Gelegenheit entgegen, einen bedeu­tenden Beitrag zur sicheren Digita­li­sierung des deutschen Gesund­heits­wesens zu leisten.

Kontakt für weitere Infor­ma­tionen: Randolf Skerka

Nachweise im PCI DSS-Audit

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-Ergeb­nisse haben, und wie Sie am besten die Erbringung angemes­sener Nachweise für PCI DSS v4.0‑Audits vorbereiten.

Audit­prozess

Im Laufe eines PCI DSS-Assess­ments (oder, wie wir im Deutschen häufig sagen, ‑Audits) prüfen Auditoren, inwieweit die PCI DSS-Anfor­de­rungen bei einem Unter­nehmen umgesetzt sind.

Üblicher­weise beinhaltet ein Audit­prozess die folgenden Prüfschritte:

  • Review von Dokumenten,
  • Review von System­kom­po­nenten/-einstel­lungen,
  • Review von Prozessen,
  • Review von physi­schen Gegeben­heiten, 
  • Review von Protokollen/Ergebnissen, und
  • Inter­views mit Personal.

Dies ändert sich auch nicht mit der Migration auf PCI DSS v4.0.

Nachweis­pflichten

Welche Notizen eine Auditorin sich macht und welche Nachweise sie wie ablegt, bleibt für die auditierte Firma norma­ler­weise im Verbor­genen. 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 klarge­stellt, dass sie für jeden Prüfschritt fordern, dass der Auditor einen entspre­chenden Nachweis abgelegt. Die prüft das PCI SSC auch stich­pro­ben­artig 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 Infor­mation mitzu­liefern, um welche System­kom­po­nente und/oder welche Prozess es geht.

Beim Review von System­kom­po­nenten/-einstel­lungen ist es notwendig, dass der Auditor sich dedizierte Notizen zu dem jewei­ligen System und der jewei­ligen Einstellung macht.

Beim Review von Prozessen oder physi­schen Gegeben­heiten muss die jeweilige Gegebenheit detail­liert beschrieben werden, und es muss darge­stellt 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 entspre­chende Notizen zu machen. An vielen Stellen kann es die Schreib­arbeit verkürzen, wenn der Auditor Kopien oder Screen­shots bereit­ge­stellt bekommt oder Fotos machen darf.

Der PCI DSS v4.0 listet etwa 250 Unter­punkte zu den 12 Haupt-Anfor­de­rungen auf – entspre­chend viele Nachweise benötigt der Auditor.

Aufbe­wah­rungs­pflichten

Der PCI DSS Program Guide schreibt vor, dass alle oben genannten Nachweise von der Audit­firma für mindestens drei Jahre sicher aufbe­wahrt werden müssen und auf Anfrage dem PCI SSC und den zugehö­rigen Gesell­schaften verfügbar gemacht werden müssen.

Aus Daten­schutz- oder Vertrau­lich­keits­gründen kommt es vor, dass Unter­nehmen 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 statt­dessen bei dem auditierten Unter­nehmen erfolgen darf. Die Anfor­de­rungen an Aufbe­wah­rungs­frist und Verfüg­barkeit sind in diesem Fall die gleichen.

Da die Nachweis­pflichten 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 weiter­ge­geben werden dürfen, bereiten Sie sich als auditiertes Unter­nehmen am besten vor, indem Sie

  • eine revisi­ons­si­chere Aufbe­wahrung der Nachweise für mindestens drei Jahre vorbereiten,
  • während des Audits eine Liste der nicht ausge­hän­digten Dokumente und Nachweise führen,
  • eine schrift­liche Beschei­nigung für den Auditor vorbe­reiten, in der Sie 
    • den Aufbe­wah­rungsort benennen,
    • den Ansprech­partner benennen, an den das PCI SSC sich wenden kann, wenn es Nachweise einsehen möchte, und
    • eine revisi­ons­si­chere Aufbe­wahrung 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 Anfor­de­rungen nachge­wiesen werden konnte, sondern Abwei­chungen festge­stellt wurden?

Geplante Abwei­chungen

Der einfachste Fall ist es, wenn Sie als auditiertes Unter­nehmen bereits vorab erkannt haben, dass Sie eine Anfor­derung nicht erfüllen können oder nicht auf dem vorge­ge­benen Weg erfüllen möchten. In diesem Fall haben Sie zum Audit bereits eine Dokumen­tation einer Compen­sating Control oder eines Custo­mized Approaches vorbe­reitet. Hierbei kann Ihnen auch ein PCI DSS-Experte helfen – es darf nur nicht der gleiche sein, der die Umsetzung dann auch prüft.

 Zum Custo­mized 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 Compen­sating Control oder des Custo­mized Approaches Ihres Unter­nehmens prüfen, ggf. Rückfragen stellen, und dann geeignete Prüfme­thoden ableiten und durch­führen. Die Pflichten zum Erheben von Nachweisen ergeben sich dabei aus der jewei­ligen Prüfmethode.

Ungeplante Abwei­chungen – „INFI“

Treten während eines Audit­zeit­raums ungeplante Abwei­chungen von den PCI DSS-Anfor­de­rungen auf, müssen diese behoben werden und die Behebung durch den Auditor verifi­ziert 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 Abwei­chung identi­fi­ziert wird, und dass Prozesse imple­men­tiert sind, die ein erneutes Auftreten solch einer Abwei­chung verhindern. Nur in dem Fall kann der Auditor die Anfor­derung noch als erfüllt ansehen.

Im neuen „Items Noted For Impro­vement” (INFI)-Dokument müssen bei jedem PCI DSS v4.0‑Audit alle Abwei­chungen, ihre Gründe, die korrek­tiven und präven­tiven Maßnahmen dokumen­tiert werden.

Die Auditorin stellt dem auditierten Unter­nehmen zum Abschluss des Audits das INFI-Dokument zur Verfügung, und beide Parteien unter­schreiben es. Das INFI-Dokument belegt, dass das auditierte Unter­nehmen die Abwei­chungen erfolg­reich bewältigt hat. Das Dokument kann im auditierten Unter­nehmen intern verwendet werden – bspw. in Compliance- und Risiko-Abtei­lungen – 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 regel­mäßig zu wieder­ho­lenden Prozessen kommt es immer mal wieder dazu, dass sich eine Durch­führung verspätet, z.B. bei der Durch­führung von 

  • Security-Awareness-Trainings,
  • der Inspektion von Zahlgeräten,
  • Schwach­stel­len­scans, oder
  • dem Einspielen von Patches.

Überlegen Sie sich am besten bereits im Vorfeld, wie Sie Ihre Prozesse so gestalten, dass Sie die vorge­schrie­benen Zeiträume einhalten und Verspä­tungen sofort bemerken.

Bei Fragen unter­stützen wir Sie gerne, melden Sie sich per E‑Mail bei Frau Jana Ehlers.