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.

Heute geht’s los – der Karrie­retag 2023 mit SRC in Bonn

Heute ist der große Tag! Wir sind aufgeregt, Dich als Studenten und Absol­venten am Karrie­retag 2023 in Bonn begrüßen zu dürfen. Die SRC GmbH freut sich darauf, Dich an unserem Stand zu treffen und über aufre­gende Karrie­re­mög­lich­keiten in der IT-Sicherheit zu sprechen.

Entdecke die Welt der Cybersecurity

Unsere Experten stehen bereit, um Dir einen Einblick in die Welt der IT-Sicherheit zu geben. Von mobilen Bezahl­me­thoden bis hin zu künst­licher Intel­ligenz und kriti­schen Infra­struk­turen – wir zeigen Dir, wie spannend die IT sein kann.

Unsere Kollegen vor Ort

Am Stand der SRC GmbH wirst Du auf einige unserer talen­tierten Kollegen treffen:

  • Randolf Skerka, Business Develo­pment: Randolf ist der Experte in Sachen Geschäfts­ent­wicklung. Er kennt die neuesten Trends und Chancen in der IT-Branche.
  • Oliver Borcherding, Sales Team: Oliver steht bereit, um Dir alles über unsere Vertriebs­stra­tegien und ‑möglich­keiten zu erzählen.
  • Janina Walgenbach, Fachbe­reich PCI: Janina ist unsere Fachex­pertin und kann Dir Einblicke in die komplexen Themen­felder der IT-Sicherheit bieten.
  • Mustafa Tarik, Pentester: Mustafa bringt praktische Erfahrung mit und kann direkt aus erster Hand über seine Arbeit als Pentester berichten.
  • Stefanie Rader­macher, HR: Stefanie ist unser Ansprech­partner für alle Fragen rund um Karrie­re­chancen und Bewer­bungs­pro­zesse bei SRC.

Egal, welchen Bereich der IT Dich inter­es­siert, unsere Kollegen haben die Antworten auf Deine Fragen und freuen sich darauf, mit Dir zu sprechen.

SRC auf dem Karrie­retag 2023 in Bonn: Dein Sprung­brett zur IT-Karriere

Verpass nicht die Chance, Teil dieses aufre­genden Tages zu sein. Besuche uns am Karrie­retag 2023 in Bonn und lass Dich inspirieren

BSZ

SRC GmbH: Vorreiter in der BSZ-Zerti­fi­zierung mit Erwei­terung des Expertenteams

Im folgenden Artikel erfahren Sie mehr darüber, wie die SRC GmbH seit September 2021 als anerkannte Prüfstelle für die BSZ agiert und welche wichtigen Entwick­lungen und Expertise sie in diesem Bereich bietet.

Beschleu­nigte Sicher­heits­zer­ti­fi­zierung (BSZ): Eine Einführung

Die BSZ ist ein Verfahren, das vom BSI in Deutschland angeboten wird, um die Sicherheit von IT-Produkten nachzu­weisen. Es wurde einge­führt, um den Herstellern eine schnellere Möglichkeit zu bieten, die Sicherheit ihrer Produkte mit einem BSI-Zerti­fikat zu belegen. Durch diese Bewertung soll sicher­ge­stellt werden, dass das Produkt den Sicher­heits­an­for­de­rungen des BSI entspricht und den Endan­wendern ein angemes­senes Maß an Schutz bietet. Im Vergleich zur herkömm­lichen Zerti­fi­zierung nach Common Criteria (CC) bietet die BSZ den Vorteil einer schnel­leren Zerti­fi­zierung, besser planbarer Evalu­ie­rungs­lauf­zeiten, sowie einen erheblich reduzierter Dokumen­ta­ti­ons­aufwand für den Hersteller. SRC ist eine vom Bundesamt für Sicherheit in der Infor­ma­ti­ons­technik (BSI) anerkannte Prüfstelle für die Beschleu­nigte Sicher­heits­zer­ti­fi­zierung (BSZ) und war eine der ersten anerkannten Zerti­fi­zie­rungs­stellen überhaupt.

Der Weg zur Sicherheit: BSZ im Vergleich zu CC

Das Verfahren erlaubt nur einen einzelnen Durchlauf, d.h. das zu evalu­ie­rende Produkt darf während der Evalu­ierung nicht mehr verändert werden. Damit wird das Verfahren insgesamt stark beschleunigt, aller­dings besteht immer das Risiko, dass Produkte im ersten Versuch durch­fallen und damit kein Zerti­fikat erhalten. In dem Fall kann aber jederzeit ein neues Zerti­fi­zie­rungs­ver­fahren beim BSI beantragt werden.

Unter der Leitung von Peter Jung: Die ersten Schritte der SRC mit BSZ

Unter der Projekt­leitung von Peter Jung, der von Beginn an bei der SRC die Beschleu­nigte Sicher­heits­zer­ti­fi­zierung verant­wortet, evalu­ierte die SCR seitdem u.a. den Lancom 1900EF VPN Router, der auch das erste BSZ-Produkt überhaupt war, sowie anschließend den secunet Highspeed­kon­nektor. Sobald dieser evaluiert wird, werden wir in einem weiteren Artikel darüber berichten.

Neue Expertise bei SRC: Tim Hirschberg und Dr. Matthieu Felsinger

BSZWir freuen uns, mitteilen zu können, dass die SRC seit Mai 2023 mit Tim Hirschberg (BSZ-Evaluator), und Dr. Matthieu Felsinger (BSZ-Evaluator und BSZ-Evaluator für Krypto­graphie) nun zwei weitere zerti­fi­zierte Evalua­ti­ons­experten im Team hat, die u.a. Evalu­ie­rungen verant­worten und Prüfungs­be­richte erstellen. Beide ergänzen das bisherige Team – bestehend aus Peter Jung (BSZ-Evaluator und BSZ-Evaluator für Krypto­graphie), Matthias Heuft (BSZ-Evaluator) und Dirk Feldhusen (BSZ-Evaluator für Kryptographie).

Die BSZ-Zerti­fi­zierung im Detail: Konzen­tration auf Sicherheitsversprechen

Die Beschleu­nigte Sicher­heits­zer­ti­fi­zierung konzen­triert sich auf die Überprüfung der vom Hersteller zugesagten Sicher­heits­leistung. Die eigent­liche Zerti­fi­zierung wird nach einer Evalu­ierung des Produkts durch eine vom BSI anerkannte Prüfstelle, wie die SRC, durch­ge­führt. Der resul­tie­rende Prüfbe­richt dient dem BSI als Grundlage für die Vergabe des Zertifikats.

Der Weg zum Zerti­fikat: Der Prüfprozess bei SRC

Die Evalu­ierung erfolgt in einem festen Zeitrahmen (etwa 2–3 Monate), der sich nach der Komple­xität des Produkts richtet. Die Evalu­ie­rungs­leis­tungen umfassen unter anderem die Prüfung der zugesagten Sicher­heits­funk­tio­na­lität (Konfor­mi­täts­tests) und der Instal­la­ti­ons­an­leitung sowie Penetra­ti­ons­tests, bei denen unter realis­ti­schen Angriffs­sze­narien die Wirksamkeit der techni­schen Sicher­heits­maß­nahmen des Produkts geprüft wird.

BSZ KryptoEine Ganzheit­liche Bewertung: Krypto­grafie und mehr

Auch die Bewertung der imple­men­tierten krypto­gra­fi­schen Verfahren ist Teil des umfas­senden Prüfpro­zesses, den ein IT-Produkt durch­laufen muss, um die Beschleu­nigte Sicher­heits­zer­ti­fi­zierung zu erhalten.

Der Blick in die Zukunft der Sicherheitszertifizierung

Wir bei der SRC GmbH sind stolz auf unsere Rolle als anerkannte Prüfstelle für die Beschleu­nigte Sicher­heits­zer­ti­fi­zierung und darauf, konti­nu­ierlich die Sicher­heits­stan­dards in der IT-Branche voran­zu­treiben. Mit unserem erfah­renen Team und unserem Engagement für Innovation werden wir weiterhin dazu beitragen, die Sicherheit von IT-Produkten zu gewährleisten.

Wenn Sie mehr über unsere Zerti­fi­zie­rungs­leis­tungen erfahren möchten oder Fragen haben, zögern Sie nicht, uns zu kontak­tieren. Gemeinsam können wir die Sicher­heits­an­for­de­rungen Ihrer Produkte erfüllen und Ihnen den Weg zur Zerti­fi­zierung ebnen. Wir freuen uns darauf, mit Ihnen zusam­men­zu­ar­beiten und die Zukunft der Sicher­heits­zer­ti­fi­zierung zu gestalten.

PCI DSS v4.0

Unser September-Blog-Eintrag zu PCI DSS v4.0

Timeline für die PCI DSS v4.0‑Migration – Was sind die nächsten Schritte?

Mit dem 31.03.2024 rückt das Ende von PCI DSS v3.2.1 näher. Alle Händler, die Zahlungen mit Karten der inter­na­tio­nalen Zahlungs­marken Visa, Mastercard, American Express, Discover, JCB oder UnionPay akzep­tieren, und alle Dienst­leister, die sie dabei unter­stützen, sollten auf PCI DSS v4.0 vorbe­reitet sein.

Aber was sollte man konkret wann tun?

Gap-Analyse

Am Anfang sollte eine Gap-Analyse stehen. Wer bisher noch nicht überprüft hat, welche neuen Anfor­de­rungen mit PCI DSS v4.0 auf ihn zukommen, sollte dies so schnell wie möglich nachholen! Die Gründe liegen auf der Hand:

  • Die Umsetzung neuer Anfor­de­rungen wird Zeit und Ressourcen benötigen.
  • PCI DSS-Fachleute, die bei der Umsetzung beraten können, sind bereits gut gebucht.

Bei der Gap-Analyse müssen die neuen Anfor­de­rungen gelesen und verstanden werden und mit der bestehenden Maßnahmen-Landschaft abgeglichen werden. Für das Verständnis der Anfor­de­rungen ist es extrem hilfreich, nicht nur die Anfor­derung an sich zu lesen, sondern auch die umfang­reichen Hilfe­stel­lungen, die das PCI SSC jeder Anfor­derung im Standard zur Seite gestellt hat:

  • Die „Guidance“-Spalte (rechts von der Anforderung),
  • die mit der Anfor­derung verfolgte Zielsetzung (unterhalb der Anforderung),
  • und, sofern vorhanden, die Hinweise zur Anwend­barkeit (unterhalb der Anforderung).

Auch die einlei­tenden Kapitel des PCI DSS v4.0 und das Glossar im Anhang G können bei Fragen zu Begriff­lich­keiten und Anwend­barkeit unterstützen.

Wenn Sie bereits mit einem PCI DSS-Experten zusam­men­ar­beiten, greifen Sie gerne schon in diesem Schritt auf dessen Expertise und Erfahrung zurück.

Priori­sierung

Wenn alle offenen Punkte identi­fi­ziert wurden, sollten ihnen Zeiträume und Verant­wort­lich­keiten zugewiesen werden.
Bei der Zuweisung der Zeiträume sollte das Folgende beachtet werden:

  1. Wie lange wird die Umsetzung voraus­sichtlich dauern?
    Die Imple­men­tierung neuer techni­scher Lösungen dauert aufgrund interner Abhän­gig­keiten häufig lang. Oft kommt dies zusammen mit geringen Perso­nal­res­sourcen. Themen, bei denen absehbar ist, dass ihre Umsetzung lange dauern wird, müssen früher angegangen werden als welche, die voraus­sichtlich schnell erledigt sind.
  2. Werden gezielte Risiko­ana­lysen verlangt?
    In v4.0 ist die Häufigkeit der Durch­führung für viele regel­mäßige Aufgaben nicht mehr fest vorge­schrieben, sondern soll durch eine gezielte Risiko­analyse bestimmt werden. Die Durch­führung solcher gezielten Risiko­ana­lysen muss intern abgestimmt werden und erfordert entspre­chend Zeit.
  3. Gibt es Zeiträume, die sich besonders gut oder schlecht für die Umsetzung eignen?
    Für die Änderung von Richt­linien kann es z.B. sinnvoll sein, Dokumenten-Review-Zyklen zu berück­sich­tigen. Bei techni­schen Änderungen ergibt es Sinn, eventuelle Freeze-Perioden oder bereits geplante Release-Zeiträume zu berücksichtigen.
  4. Ist die PCI DSS v4.0‑Deadline für diese Anfor­derung 2024 oder 2025?
    Bei vielen grund­legend neuen Anfor­de­rungen im PCI DSS v4.0 ist in den Hinweisen zur Anwend­barkeit vermerkt, dass die Anfor­derung bis zum 31.03.2025 als Best Practice angesehen wird und erst danach verpflichtend ist.
    Anfor­de­rungen ohne diesen Hinweis müssen bis zum 31.03.2024 umgesetzt sein und sollten daher ggf. höher priori­siert werden.

Entschei­dungen

Für manche neuen Anfor­de­rungen gibt es verschiedene Möglich­keiten, sie umzusetzen.
Beispiele dafür sind:

  • Anfor­derung 3.4.2 fordert die Verhin­derung von Kopieren/Verschieben von PAN bei remote-Zugriffen (außer für Personal mit entspre­chendem Business Need). Auch hierfür kann es mehrere Wege geben – z.B. über eine Einstellung in RDP bei Nutzung der Remote-Verbindung, oder indem man bei PAN-Anzeigen auf entspre­chenden Webseiten Markie­ren/­Ko­pie­ren/Maus-Rechts­klicks verhindert.
  • Anfor­derung 8.4.2 fordert die Erzwingung von Multi-Faktor-Authen­ti­fi­zierung (MFA) bei Zugriffen in die Cardholder Data Environment (CDE). Je nachdem, wie die Zugriffe in Richtung CDE statt­finden, kann es sinnvoll sein, die MFA auf Netzwer­kebene zu erzwingen, oder auf System­ebene, oder auf Anwen­dungs­ebene. Diese Entscheidung muss unter Einbe­ziehung der verschie­denen Verant­wort­lichen gut abgewogen werden. Gegebe­nen­falls müssen hier sogar mehrere Parteien zusammenarbeiten.

Wägen Sie frühzeitig ab, welche Auswir­kungen welcher Weg für Sie hat!

Nachver­folgung und Bewertung

Wenn Sie Ihre Aufgaben zeitlich priori­siert haben und sich für Umset­zungswege entschieden haben: lehnen Sie sich bitte nicht zurück! Die Person oder das Team, welches für die Aufrecht­erhaltung der PCI DSS-Konfor­mität verant­wortlich ist, sollte mit den Teams, die für die Umsetzung verant­wortlich sind, in Kontakt bleiben.

  • Gibt es Rückfragen/Verständnisfragen?
  • Gibt es Probleme bei der Umsetzung?
  • Ist die Einhaltung des verein­barten Zieltermins gefährdet?

Technische SicherheitseinrichtungenSobald eine Aufgabe umgesetzt ist, sollte geprüft werden, ob die Lösung der entspre­chenden PCI DSS-Anfor­derung standhält. Wenn gewünscht, können auch für solche kleinen Zwischen-Assess­ments externe PCI DSS-Experten hinzu­ge­zogen werden, um auf der sicheren Seite für das nächste offizielle Assessment zu sein.

Konti­nu­ier­licher Prozess

Wenn eine Anfor­derung einmal erfüllt ist, ist nicht gewähr­leistet, dass dies so bleibt. Karten­da­ten­nutzung, Techno­logien und Angriffs­vek­toren ändern sich. Bereits heute beinhaltet der PCI DSS v3.2.1 regel­mäßige Aufgaben zur Aufrecht­erhaltung der PCI DSS-Konfor­mität. Mit dem PCI DSS v4.0 entwi­ckelt sich dies immer mehr zu einem konti­nu­ier­lichen Prozess.

Gewöhnen Sie sich daher bereits jetzt daran, Ihre Maßnahmen immer wieder auf den Prüfstand zu stellen, und die (in Kapitel 7 des PCI DSS jetzt genau definierten) Zeiträume für wieder­keh­rende Tätig­keiten einzu­halten. So wird Ihnen auch die Einhaltung neuer entspre­chender Anfor­de­rungen leichter gelingen, wie bspw.

  • 2.4 / 7.2.5.1 Review von Benut­zer­konten und zugeord­neten Zugriffsrechten,
  • 3 Review von Risiko­ein­schät­zungen und Review der Angemes­senheit und Sicherheit von verwen­deten krypto­gra­fi­schen Algorithmen, Hardware- und Software-Technologien,
  • 5 Validierung des PCI DSS-Anwen­dungs­be­reichs und
  • 6.2 Review des Security Awareness-Programms.

Aber vor allem: Anfangen!

Dies ist der wichtigste Schritt. Wenn Sie noch nicht angefangen haben, ist heute der beste Tag, dies zu tun.
Stellen Sie ein Team zusammen und planen Sie Zeit ein.

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

Karrie­retag 2023 – SRC ist wieder dabei!

Der Karrie­retag 2023 in Bonn  – Die Karrie­re­messe für Studie­rende und Berufseinsteiger

Das Ende des Studiums ist ersichtlich. Der Abschluss in greif­barer Nähe. Spätestens jetzt benötigen Studie­rende und Absol­venten Kontakt zu einem poten­ti­ellen, zukünf­tigen Arbeit­geber. SRC freut sich auf diesen Kontakt: Der Karrie­retag 2023 in Bonn ist der perfekte erste Einstieg dazu.

Die Jobmesse wird mit vielen Angeboten rund um das Thema Karriere und Karrie­re­planung abgerundet. Dazu gehören z.B. Vorträge, Workshops, Jobboards und vieles mehr.

Karriere in der IT – SRC gewährt einen Einblick in spannende Aufgabenbereiche

SRC gibt Studie­renden und Absol­venten auch auf dem Karrie­retag 2023 die Möglichkeit, einen Einblick in und den Austausch über die vielfäl­tigen Themen­felder der IT-Sicherheit zu nehmen. Die SRC-Experten erläutern den Alltag und die Heraus­for­de­rungen bei der Begut­achtung sicher­heits­re­le­vanter IT-Techno­logien. Eine Auswahl aktueller Themen sind z. B. mobile Bezahl­me­thoden, künst­liche Intel­ligenz und kritische Infra­struk­turen. Von unseren neuen Kollegen erwarten wir einen ausge­prägten Instinkt für poten­zielle Fehler­quellen in komplexen Techno­logien, die Kompetenz zur Findung von Lösungen und das Durch­set­zungs­ver­mögen, das Ergebnis ihrer Arbeit gegenüber den Auftrag­gebern zu vertreten.

Aktuelle Stellen­an­gebote auf unserem Karriereportal

Ob als Werkstu­die­rende in unserem Kunden­ma­nagement oder als Scanworker im Pentestteam – vielfältige und spannende Aufgaben neben dem Studium erledigen ist bei uns kein Problem. Aber auch Absol­venten kommen bei uns auf ihre Kosten – Wir suchen Pentester, Beratende und Analytiker/innen für verschiedene Bereiche in unserem Unternehmen.

Gerne können sich Studie­rende und Absol­venten bereits vorab auf unserem Karrie­re­portal über offene Stellen­an­gebote in unserem Unter­nehmen infor­mieren. Wir stehen gerne für Rückfragen am Unter­neh­menstag zur Verfügung! Außerdem besteht die Möglichkeit, uns Bewer­bungs­un­ter­lagen direkt vor Ort zu überreichen.

Mehr Infor­ma­tionen zum Karrie­retag 2023 in Bonn gibt es hier.

PCI DSS v4.0 rückt näher – wir unter­stützen Sie bei der Vorbereitung

Der PCI DSS ist ein ausge­reifter Standard, der Anfor­de­rungen an die sichere Verar­beitung von Karten­daten der inter­na­tio­nalen Zahlungs­systeme definiert.

Die Version 3 des PCI DSS, die – mit verschie­denen Updates – seit 2014 gültig ist, läuft Ende März 2024 endgültig aus und wird durch die neue Version 4.0 ersetzt.

Wir gehen mit Ihnen die letzten Schritte zur Migration auf PCI DSS v4.0.

Nutzen Sie gerne unsere Angebote:

 1. Monat­liche Blog-Artikel, in denen jeweils ein Thema des PCI DSS v4.0 genauer beleuchtet wird.

2. Kostenlose Webinare, welche die Änderungen von PCI DSS v3.2.1 auf v4.0 noch einmal für Sie zusammenfassen.

Sobald die genauen Termine feststehen und die Anmeldung freige­schaltet ist, finden Sie die entspre­chenden Links hier:

  • Webinar zum vollen PCI DSS-Anwen­dungs­be­reich (Januar 2023)
  • Webinar für Card-Present-Händler mit Anwen­dungs­be­reich SAQ B‑IP oder P2PE (Januar 2023)
  • Webinar für E‑Com­merce-Händler mit Anwen­dungs­be­reich SAQ A (Januar 2023)

3. Auf Sie zugeschnittene PCI DSS v4.0‑Workshops, in dem wir die für Sie relevanten Anfor­de­rungen gezielt vorstellen und diskutieren.

4. Eine Gap-Analyse für Ihre Umgebungen und Prozesse. Sie erhalten eine Liste aller in Ihrem Unter­nehmen noch offenen Punkte für die PCI DSS v4.0‑Konformität.

5. Beratungs­pakete nach Wahl, von denen Sie jederzeit Kontin­gente abrufen können, wenn Sie konkrete Rückfragen haben – per Telefon, E‑Mail, Webkon­ferenz, oder in Meetings vor Ort.

Kontakt: Frau Jana Ehlers per E‑Mail

Wie sicher ist die elektro­nische Patientenakte?

Nach der Digita­li­sie­rungs­stra­tegie des Bundes­mi­nis­te­riums für Gesundheit erhalten zukünftig alle gesetzlich Versi­cherten, die nicht aktiv wider­sprechen, eine elektro­nische Patien­tenakte. Wer kann dann auf die persön­lichen Patien­ten­daten zugreifen und wie gut sind die Daten gegen unberech­tigten Zugriff geschützt?

Anfang März 2023 hat Bundes­ge­sund­heits­mi­nister Prof. Karl Lauterbach in einer Presse­kon­ferenz die neue Digita­li­sie­rungs­stra­tegie des Bundes­mi­nis­te­riums für Gesundheit (BMG) vorge­stellt. Ein zentrales Thema der Digita­li­sie­rungs­stra­tegie ist die elektro­nische Patien­tenakte (ePA). Diese wird den 73 Millionen gesetzlich Versi­cherten seit Januar 2021 auf Wunsch (Opt-In) durch die Kranken­kassen bereit­ge­stellt. Laut Karl Lauterbach haben bis heute aller­dings weniger als ein Prozent der gesetzlich Versi­cherten eine ePA beantragt. Dies hat sich offenbar schon länger angedeutet, denn bereits im Koali­ti­ons­vertrag von November 2021 wurde vereinbart, die Einführung der ePA zu beschleu­nigen und allen Versi­cherten, die nicht aktiv wider­sprechen, eine ePA zur Verfügung zu stellen (Opt-Out). Im Rahmen der Digita­li­sie­rungs­stra­tegie erfolgt nun die Umsetzung. Das BMG hat bereits zwei neue Gesetze angekündigt: das Digital­gesetz und das Gesund­heits­da­ten­nut­zungs­gesetz (GDNG). Damit sollen bis zum Jahr 2025 80 Prozent der gesetzlich Versi­cherten über eine ePA verfügen und die Patien­ten­daten pseud­ony­mi­siert für die Forschung nutzbar werden.

Für die Versi­cherten bedeutet dies, eine Entscheidung treffen zu müssen. Keine ePA zu beantragen war einfach und bequem, aber sollte der Einrichtung jetzt wider­sprochen werden? Wie sind die persön­lichen Patien­ten­daten in einer ePA geschützt? Wer kann auf die Patien­ten­daten zugreifen? Dieser Artikel vermittelt Hinter­grund­in­for­ma­tionen zur Funkti­ons­weise der ePA und über den Schutz der in der ePA gespei­cherten Patientendaten.

Die elektro­nische Patientenakte

Die elektro­nische Patien­tenakte ist im Wesent­lichen ein sicherer cloud­ba­sierter Dokumen­ten­speicher mit einem komplexen Berech­ti­gungs­system. Versi­cherte können ihre Patien­ten­daten jederzeit einsehen und die Berech­tigung für den Zugriff durch Ärzte oder andere Personen selber steuern. Dies wird durch das Zusam­men­spiel verschie­dener Kompo­nenten erreicht:

  • Das ePA-Akten­system (ePA-AS) ist die zentrale Backend-Kompo­nente, in der die Patien­ten­daten gespei­chert werden. Hier erfolgen außerdem die Nutzer­au­then­ti­fi­zierung und die Durch­setzung der Zugriffsrechte.
  • Das ePA-Frontend des Versi­cherten (ePA-FdV) ist der dezen­trale Zugangs­punkt für die Versi­cherten. Das ePA-FdV gibt es als mobile App wie auch als Desktop­an­wendung. Über das ePA-FdV können Versi­cherte die eigene Akte verwalten sowie Inhalte hochladen, einsehen, herun­ter­laden oder löschen.
  • Über das Fachmodul ePA auf den Konnek­toren greifen Ärzte und andere Leistungs­er­bringer auf die ePA der Patienten zu.
  • Zwei unabhängige Schlüs­sel­ge­nerie­rungs­dienste (SGD) stellen nutzer­indi­vi­duelle Schlüssel für die Verschlüs­selung der Akten­in­halte bereit.

Verschlüs­selung der Akteninhalte

Die in der ePA gespei­cherten Patien­ten­daten sind perso­nen­be­zogene Gesund­heits­daten gemäß Artikel 9 Daten­schutz­grund­ver­ordnung (DSGVO) und somit besonders schüt­zenswert. Der Schutz wird durch zahlreiche Maßnahmen umgesetzt. Besondere Relevanz hat die Verschlüs­selung der Akten­in­halte. Beim poten­zi­ellen Zugriff auf Akten­in­halte durch eine unberech­tigte Person erhält diese nur verschlüs­selte Daten. Das Gesamt-Verschlüs­se­lungs­ver­fahren setzt sich aus mehreren Verschlüs­se­lungen mit unter­schied­lichen Schlüsseln zusammen:

  • Der Dokumen­ten­schlüssel wird zur Verschlüs­selung eines bestimmten Akten­in­halts verwendet. Im Weiteren wird verein­facht angenommen, dass es sich bei Akten­in­halten um Dokumente (zum Beispiel PDF-Dokumente) handelt. Jedes in der ePA gespei­cherte Dokument wird mit einem indivi­du­ellen Schlüssel verschlüsselt.
  • Der Kontext­schlüssel wird zur Verschlüs­selung der Meta- und Proto­koll­daten verwendet. Die Metadaten enthalten Klartext­in­for­ma­tionen und erlauben, trotz der verschlüs­selten Ablage der medizi­ni­schen Dokumente, einen Überblick der Akten­in­halte und eine server­seitige Suche in der Akte.
  • Der Akten­schlüssel wird für die Verschlüs­selung der Akten­in­halte verwendet. Dazu gehören die bereits genannten Dokumen­ten­schlüssel wie die Dokumente selbst.
  • Die Berech­tig­ten­schlüssel 1 und 2 werden für die Verschlüs­selung des Kontext- und des Akten­schlüssels verwendet. Sie sind nutzerindividuell.

Der Zugriff auf und die Entschlüs­selung von Patien­ten­daten aus der ePA läuft wie folgt ab: eine berech­tigte Person, zum Beispiel der oder die Versi­cherte, authen­ti­siert sich über das ePA-FdV gegenüber dem ePA-Akten­system und den Schlüs­sel­ge­nerie­rungs­diensten. Von den Schlüs­sel­ge­nerie­rungs­diensten erhält das ePA-FdV die indivi­du­ellen Berech­tig­ten­schlüssel 1 und 2, vom ePA Akten­system erhält das ePA-FdV den Akten- und Kontext­schlüssel in verschlüs­selter Form. Mithilfe der Berech­tig­ten­schlüssel werden Akten- und Kontext­schlüssel im Zwiebel­scha­len­prinzip entschlüsselt. Der Kontext­schlüssel wird im Klartext über ein speziell gesichertes Protokoll an das ePA-Akten­system übertragen. Im ePA-Akten­system gibt es eine sogenannte Vertrau­ens­würdige Ausfüh­rungs­um­gebung, die technisch Zugriffe des Betreibers verhindert und damit sicher­stellt, dass der Betreiber keine Akten­in­halte einsehen kann. In dieser Vertrau­ens­wür­digen Ausfüh­rungs­um­gebung wird der sogenannte Akten­kontext mit dem Kontext­schlüssel entschlüsselt. Es handelt sich um Metadaten, die zum Beispiel eine Inhalts­angabe der in der ePA gespei­cherten Dokumente enthält. Über den Akten­kontext kann am ePA-FdV das gewünschte Dokument ausge­wählt und auf das Endgerät geladen werden. Dort wird das Dokument zunächst mit dem Akten­schlüssel entschlüsselt. Das Ergebnis ist ein Dokumen­ten­schlüssel und das damit verschlüs­selte Dokument. Mit dem Dokumen­ten­schlüssel wird das Dokument entschlüsselt und liegt letztlich im Klartext vor. Wird das Dokument außerhalb des ePA-FdV gespei­chert, kann die Sicherheit nicht mehr durch die ePA gewähr­leistet werden.

Berech­ti­gungs­ma­nagement

Gibt eine versi­cherte Person einer anderen Person (zum Beispiel einem Arzt) die Berech­tigung, auf Akten­in­halte zuzugreifen, werden der Akten- und Kontext­schlüssel mit Berech­tig­ten­schlüsseln dieser anderen Person verschlüsselt und im Akten­system für den Abruf durch diese gespei­chert. Nicht berech­tigte Personen, wie der Betreiber des ePA-Akten­systems, sind somit krypto­gra­fisch vom Akten­zu­griff ausge­schlossen. Ist eine Person generell berechtigt und es liegen die notwen­digen Schlüssel vor, kann der Zugriff weiterhin auf Dokumenten-Ebene einge­schränkt werden. So können Versi­cherte für jedes Dokument einzeln festlegen, wer darauf zugreifen darf.

Fazit

Die ePA setzt verschiedene Sicher­heits­me­cha­nismen für den Schutz der Patien­ten­daten um. Für den Zugriff müssen sich Versi­cherte grund­sätzlich authen­ti­sieren. Für die Entschlüs­selung der Inhalte müssen weiterhin verschiedene Schlüssel zusam­men­ge­bracht werden. Die Sicherheit der Verschlüs­selung liegt maßgeblich in den Berech­tig­ten­schlüsseln. Aus diesem Grund gibt es hiervon zwei, die von unabhän­gigen Schlüs­sel­ge­nerie­rungs­diensten bereit­ge­stellt werden. So ist sicher­ge­stellt, dass immer verschiedene Instanzen bei der Entschlüs­selung invol­viert sind. Weder der Betreiber des Akten­systems, noch die Betreiber der Schlüs­sel­ge­nerie­rungs­dienste sind technisch dazu in der Lage, Akten­in­halte zu entschlüsseln. Die Berech­tigung zum Zugriff auf Akten­in­halte wird durch die Versi­cherten selbst gesteuert. Nur berech­tigte Personen können die notwen­digen krypto­gra­fi­schen Schlüssel entschlüsseln, alle anderen sind krypto­gra­fisch ausge­schlossen. Die Berech­tigung zum Zugriff kann feingra­nular für jedes Dokument einzeln vergeben werden.

Vor einem unberech­tigten Zugriff sind die Patien­ten­daten in der ePA gut geschützt. Für die Berech­ti­gungs­steuerung und die Sicherheit herun­ter­ge­la­dener Patien­ten­daten sind die Versi­cherten selbst verant­wortlich. Daten­sou­ve­rä­nität erfordert Eigenverantwortung.

Autor:  Nico Martens, Berater SRC Security Research & Consulting GmbH

Basis­wissen IT-Grund­lagen und ‑Sicher­heits­maß­nahmen für Nicht-Informatiker

Mit fortschrei­tender Digita­li­sierung rückt auch die Banken-IT immer stärker in den Fokus. Um Sicherheit und Schutz insbe­sondere sensibler Infor­ma­tionen und Daten zu gewähr­leisten, müssen u. a. Infor­ma­ti­ons­si­cher­heits­be­auf­tragte, Daten­schutz­be­auf­tragte und IT-Verant­wort­liche eng zusam­men­ar­beiten. Dabei gilt es trotz unter­schied­licher fachlicher Hinter­gründe eine gemeinsame „Sprache“ zu sprechen. Denn: Je besser man IT-Begriffe, Zusam­men­hänge und Prozesse versteht, desto besser gelingt auch die Kommu­ni­kation mit den IT-Fachleuten und desto eher können vorge­schlagene IT-Sicher­heits­maß­nahmen und ihre Wirkung einge­schätzt werden.

Das folgende Inten­siv­se­minar vermittelt IT-Basis­wissen und grund­le­gende IT-Sicher­heits­maß­nahmen und richtet sich speziell an Nicht-Infor­ma­ti­ke­rInnen in Kreditinstituten:

„Basis­wissen IT-Grund­lagen und ‑Sicher­heits­maß­nahmen für Nicht-Informatiker“
am Montag, 20. November 2023, 09:30 bis 17:00 Uhr in Köln

Die erfah­renen Referenten erläutern IT-Begriffe und ‑Grund­lagen, z. B. zum Thema Netzwerke, Kommu­ni­ka­ti­ons­medien und ‑proto­kolle. Vorge­stellt werden außerdem die grund­le­genden IT-Sicher­heits­maß­nahmen in Netzen / im Rechen­zentrum, vom Thema Backup, über Virtua­li­sierung bis hin zur Benutzerverwaltung.

Ein weiteres Modul widmet sich speziell den Themen Verschlüs­selung (symme­trische und asymme­trische Verfahren, Key Management), Signatur, Authen­ti­kation (z. B. Multi-Faktor-Authen­ti­sierung gemäß PSD2) und Integri­täts­si­cherung. Sie erhalten außerdem einen Überblick über neue Techno­logien und Trends (Big Data, Cloud, Künst­liche Intel­ligenz, Beson­der­heiten im mobilen Arbeiten / Homeoffice) und disku­tieren die Anfor­de­rungen an die Sicherheit.

Es referieren:

Florian Schumann | SRC Security, Research & Consulting GmbH
Der Referent Florian Schumann ist IT-Leiter bei der SRC Security Research & Consulting GmbH. In dieser Position verant­wortet er die konti­nu­ier­liche Weiter­ent­wicklung der IT. Außerdem ist er Berater für Infor­ma­ti­ons­si­cherheit und quali­fi­zierter Prüfer gem. § 8 (a) BSIG für kritische Infrastrukturen.

Vincent Becker | SRC Security, Research & Consulting GmbH

Ihre Fragen beant­wortet gern Frau Andrea van Kessel  (Tel. 0221/5490–161) vom bank-verlag.

 

Wir freuen uns auf Ihre Teilnahme!

 

Basis­wissen IT-Grund­lagen und ‑Sicher­heits­maß­nahmen für Nicht-Informatiker
am Montag, 20. November 2023, 09:30 bis 17:00 Uhr

ISB

Zerti­fi­kats­lehrgang „Infor­ma­ti­ons­si­cher­heits­be­auf­tragte (ISB) für Kredit­in­stitute” – 21. bis 24. November 2023

Für den wirtschaft­lichen Erfolg eines Kredit­in­stituts ist eine sichere und effiziente IT unbedingt erfor­derlich. Kredit­in­stitute haben gemäß KWG und MaRisk dafür zu sorgen, dass ihre IT-Systeme und ‑Prozesse die Integrität, Verfüg­barkeit, Authen­ti­zität und Vertrau­lichkeit der Daten sicherstellen.

Mit den „Bankauf­sicht­lichen Anfor­de­rungen an die IT“, die zum 16. August 2021 novel­liert wurden, hat die BaFin ihre Anfor­de­rungen an die Funktion des Infor­ma­ti­ons­si­cher­heits­be­auf­tragten konkre­ti­siert: Diese steuern den Infor­ma­ti­ons­si­cher­heits­prozess, unter­stützen die Geschäfts­leitung bei der Festlegung der Infor­ma­ti­ons­si­cher­heits­leit­linie und erstellen Infor­ma­ti­ons­si­cher­heits­richt­linien. Darüber hinaus sind sie Ansprech­partner für alle Fragen der Infor­ma­ti­ons­si­cherheit – intern und für Dritte.

Nach der großen Resonanz und dem erfolg­reichen Abschluss von nunmehr elf Zerti­fi­kats­lehr­gängen seit 2017 freuen wir uns, Ihnen einen neuen Termin anbieten zu können:

Der viertägige Zertifikatslehrgang

Informationssicherheitsbeauftragte/r (ISB) für Kreditinstitute
vom 21. bis 24. November 2023 in Köln

unter­stützt Sie als (künftige) Informations­sicherheitsbeauftragte oder Stell­ver­treter bei der Erfüllung Ihrer Aufgaben. Sie erhalten einen umfas­senden Einblick in die Aufgaben und Kompe­tenzen des Informations­­sicherheitsbeauftragten, das Thema Informations­sicherheitsmanagement und die diesbe­züg­lichen Risiken sowie alle relevanten gesetzlichen/regulatorischen Anfor­de­rungen. Weitere Schwer­punkte sind die Themen Incident- und Notfall­ma­nagement sowie die Standards ISO 27001 und BSI IT-Grund­schutz. Exkurse aus der Bankpraxis runden die Veran­staltung ab.

Es referieren:
Dr. Anna-Lisa Kofahl
| SRC Security Research & Consulting GmbH
Heinrich Lottmann | TARGOBANK AG
Alexandros Manakos | Apollon Security GmbH
Dagmar Schoppe | SRC Security Research & Consulting GmbH

Als Teilnehmer des Lehrgangs haben Sie die Möglichkeit, das Zerti­fikat „Informationssicherheitsbeauftragte/r für Kredit­in­stitute“ zu erwerben. Voraus­setzung ist die Teilnahme an allen Modulen sowie das Bestehen der webba­sierten Abschluss­prüfung (Multiple Choice) am 27. November. Es fallen keine zusätz­lichen Prüfungs­ge­bühren an.

Profi­tieren Sie bei einer Anmeldung bis spätestens 24. September 2023 von unserem Frühbu­cher­rabatt!

Der Lehrgang setzt Grund­la­gen­wissen zum Thema IT und IT-Sicher­heits­maß­nahmen voraus, welches jedoch im Vorfeld in einem eintä­gigen Seminar erworben werden kann:

Optional: Inten­siv­se­minar „Basis­wissen IT-Grund­lagen und ‑Sicher­heits­maß­nahmen für Nicht-Infor­ma­tiker“ am 20. November 2023

Es referieren:
Florian Schumann | SRC Security Research & Consulting GmbH
Vincent Becker | SRC Security Research & Consulting GmbH

Vermittelt werden hier IT-Begriffe und ‑Grund­lagen; vorge­stellt werden außerdem die grund­le­genden IT-Sicher­heits­maß­nahmen in Netzen / im Rechen­zentrum. Ein weiteres Modul widmet sich speziell den Themen Verschlüs­selung, Signatur, Authen­ti­kation und Integri­täts­si­cherung. Sie bekommen außerdem einen Überblick über neue Techno­logien und Trends (z. B. Big Data, Cloud, Künst­liche Intelligenz).

Feedbacks bishe­riger TeilnehmerInnen:

„Das Seminar war sehr gut! Es hat mir Spaß gemacht und sehr gefallen.“

„Danke für die Organi­sation und die indivi­duelle Ausge­staltung des Lehrgangs – eine profes­sio­nelle Durch­führung und gleich­zeitig viel Austausch und Eingehen auf indivi­duelle Anfor­de­rungen ist in virtu­ellen Zeiten eine große Herausforderung.“

„Sehr angenehmer Mix aus Theorie, Regula­torik und Praxis“

„Vielen Dank, sehr gut geleitete und begleitete Schulung“

Ihre Fragen zum Lehrgang und zum IT-Grund­lagen-Seminar beant­wortet gern Frau Andrea van Kessel (Tel. 0221/5490–161)

Wir freuen uns auf Ihre Teilnahme!

Web-Seite zum Lehrgang

Online-Anmeldung
common criteria 2023

CC:2022 – Ein Überblick

Neue Version der Common Criteria erschienen

Im November 2022 ist eine neue Version der Common Criteria erschienen, die inoffi­ziell als „CC 4.0“ bezeichnet wird, jedoch offiziell CC:2022 heißt. Wir wollen Ihnen mit diesem Überblick dazu einige erste Infor­ma­tionen geben, damit Sie die Möglichkeit haben, sich auf den Übergang zu dieser neuen Version vorzubereiten. 

Zunächst einige Hinweise zu den Rahmen­be­din­gungen der neuen CC-Version: Die CC:2022 ist wie die Vorgänger einer­seits als ISO-Standard erschienen, als ISO/IEC 15408:2022, anderer­seits auch kostenfrei hier auf der Seite des CCRA zu erhalten. Die entspre­chende Mitteilung des BSI dazu findet sich unter dem Link hier.

Auf der Seite des CCRA findet sich auch die Übergangs­re­gelung, die kurz gesagt folgendes enthält:

• Bis 30.06.2024 können noch Evalu­ie­rungen nach der bishe­rigen CC Version 3.1 begonnen werden.
• Re-Evalu­ie­rungen, Re-Assess­ments und Maintenance von nach CC 3.1 zerti­fi­zierten Produkten sind innerhalb von zwei Jahren nach Zerti­fi­kats­er­teilung noch möglich.
• In Evalu­ie­rungen nach CC:2022 dürfen PPs, die nach CC 3.1 geschrieben wurden, noch bis 31.12.2027 verwendet werden.

Hinweis: Vom BSI kam schon die Signa­li­sierung, dass sich diese Übergangs­re­gelung nochmal ändern wird. Darüber hinaus wird es dann auch in Kürze eine detail­liertere Transition Policy geben.

Zu den inhalt­lichen Änderungen in der CC:2022

Die Änderungen der CC bestehen im wesent­lichen darin, dass es künftig mehr Varian­ten­reichtum in der ST-Erstellung und der Durch­führung der Evalu­ierung auf verschie­denen Ebenen geben wird, sie ist aber inhaltlich „abwärts­kom­pa­tibel“ zur CC 3.1, d.h., wer Evalu­ie­rungen im selben Stil wie bisher durch­führen will, soll dies im wesent­lichen tun können. Im letzteren Fall muss an einigen Stellen des ST der Text etwas angepasst werden, so muss wegen der größeren Zahl an Optionen die Beschreibung des „Confor­mance Claim“ etwas umfang­reicher sein.

Wir fassen hier die wichtigsten Änderungen zusammen (ohne Anspruch auf Vollstän­digkeit und Präzision)

• Die CC besteht künftig aus 5 statt wie bisher 3 Teilen. Die Erwei­terung wurde vorge­nommen, weil es sowohl bei der Auswahl der Evalu­ie­rungs­me­thoden (Teil 4) als auch bei sogenannten „Packages“ (Teil 5) nun mehr Varianten gibt als bisher.

• Die CEM besteht wie bisher aus einem Dokument.

• Einige SFRs, die bisher häufig als „extended“ (also selbst­de­fi­nierte) Kompo­nenten genutzt wurden, wurden offiziell in die CC aufge­nommen. Dies betrifft insbe­sondere solche zu Zufallszahlen.

• Eine neue Wahlmög­lichkeit ist wie folgt: Bisher beruht das Evalua­tor­urteil am Ende auf einer Schwach­stel­len­analyse anhand eines definierten Angriffs­po­ten­tials, wozu der Evaluator mögli­cher­weise Penetra­ti­ons­tests neu definiert. Dieser bisherige Weg wird zur Abgrenzung auch „Attack-based approach“ genannt. In Zukunft soll es neben dieser Vorge­hens­weise auch eine Variante einer Evalu­ierung geben, für die eine Menge von Tests fest vorab definiert wird, gegen die jeder TOE geprüft wird. Dies heißt dann „Speci­fi­cation based approach“.

• Die Kompo­si­ti­ons­eva­lu­ierung, wie sie in der Chipkar­tenwelt seit langem üblich ist, wurde nun auch offiziell in die CC aufge­nommen (bisher war sie durch SOGIS/JIL, also die europäi­schen CC-Schemata definiert).

• Der „Multi-assurance-approach“ erlaubt es künftig, für verschiedene Teile eines Produktes verschiedene Assurance-Kompo­nenten (also z.B. verschiedene Angriffs­stärken) zu definieren. (Auch dies wurde in einzelnen PPs schon in der Vergan­genheit modelliert.)

• Das „Package“-Konzept wurde erweitert. • Statt der bishe­rigen „low assurance“ STs (die kaum genutzt wurden) soll es künftig sogenannte „direct rationale“ STs geben, bei denen SFRs nicht auf Sicher­heits­ziele sondern unmit­telbar auf die „Security Problem Definition“ (also Threats etc.) zurück­ge­führt werden.

• Die mögliche „Confor­mance“ zu einem PP kann neben den bishe­rigen Varianten „demons­trable“ und „strict“ nun auch „exact“ sein. Letzteres bedeutet, dass ein Produkt genau die Sicher­heits­an­for­de­rungen eines PP erfüllt, nicht aber eventuelle zusätz­liche (was bei strict und demons­trable erlaubt ist). Dies wurde als Erwei­terung der CC auch bisher schon verwendet, etwa in vielen PPs aus den USA.

• Der oben genannte „speci­fi­cation based approach“ ist primär vorge­sehen für das Verwenden eines PPs zusmman mit den Confor­mance claim „exact“. D.h. ein PP legt sowohl genau fest, was die Funktio­na­lität eines Produktes ist, als auch alle Tests, die vom Evaluator dazu durch­ge­führt werden. (Anmerkung: Dies ist eine in den USA heute schon oft verwendete Vorgehensweise.)

• Noch einmal der Hinweis auf die „Abwärts­kom­pa­ti­bi­lität“: Wenn man keine der neuen Features benötigt, kann man wie bisher nach einer der bekannten EAL-Stufen evalu­ieren lassen und muss dann an den Herstel­ler­do­ku­menten (außer dem Confor­mance Claim im ST) nichts wesent­liches ändern.

Neben diesen genannten Änderungen gibt es noch einige weitere, die die Beschreibung von Evalua­tor­tä­tig­keiten betreffen, aber nichts Grund­le­gendes für den Hersteller ändern.

Bitte wenden Sie sich bei Rückfragen und Diskus­si­ons­bedarf gern an Ihre Ansprech­partner bei SRC.

___________________________________________________