SECURITY5. Juli 2017

Sicherheit bei Kreditkarten­trans­aktionen: Netzwerk­segmentierung und PCI‑Compliance

Thorsten Henning, Systems Engineering Manager Palo Alto Networks<q>Palo Alto Networks</q>
Thorsten Henning, Systems Engineering Manager Palo Alto NetworksPalo Alto Networks

Der Datensicherheitsstandard PCI für Kreditkartentransaktionen hat seine Anfänge im Jahr 2009. Der PCI DSS (Payment Card Industry Data Security Standard), so die vollständige Bezeichnung, war damals ein vieldiskutiertes Thema – und ist es auch heute noch. Um den Anforderungen gerecht zu werden, müssen Unternehmen mit Kartenzahlungsverkehr bestimmte Überwachungsmaßnahmen implementieren, um Kreditkartendaten zu schützen.

von Dipl.-Ing. Thorsten Henning, Senior Systems Engineering Manager Central & Eastern Europe bei Palo Alto Networks

Die Anforderungen wurden seit 2009 immer wieder aktualisiert, da sich seither viel verändert hat: die Einführung von virtualisierten Systemen in großem Stil; der Übergang zu einheitlichen, schlanken E-Commerce-Lösungen, bereitgestellt als Shared-Hosting-Modell; die Implementierung von „Encrypt-at-the-Swipe“-Zahlungskartenlösungen; EMV-kompatible (Europay International, MasterCard und VISA) Verarbeitung und vieles mehr.

Genau wie es bei PCI DSS Version 1 der Fall war, haben heute viele Unternehmen damit zu kämpfen, die PCI Compliance für PCI DSS Version 3.2 in den Griff zu kommen.”

PCI-Anleitung zur Segmentierung

Die Netzwerksegmentierung wird seit langem genutzt, um das Sicherheitsmanagement zu vereinfachen. Aus der PCI-Perspektive heraus ist die Segmentierung keine tatsächliche PCI-DSS-Anforderung, sondern sollte als eine bewährte Praxis zur Vermeidung von erfolgreichen Angriffen angesehen werden. Insbesondere lässt sich dadurch das Risiko reduzieren, dass sich Angreifer einen gefährdeten Bereich des Systems zunutze machen, um sich dann seitlich im Netzwerk vorzuarbeiten. Ebenso kann Hardware mit älteren Betriebssystemen, die nicht mehr mit Sicherheits-Patches versorgt wird, in einem separaten Segment weiterbetrieben werden.

Der PCI DSS legt fest, dass jedes Gerät, das an der Speicherung, Verarbeitung oder Übertragung von Karteninhaberdaten (Card Holder Data, CHD) beteiligt ist, als Teil des Segments gilt. Um die Dinge so einfach wie möglich zu halten, sollten Netzwerkdesigner so segmentieren, dass nur Ressourcen enthalten sind, die für die Transaktionsverarbeitung und -speicherung tatsächlich benötigt werden. Die Segmentierung kann auch dazu beitragen, die Kosten zu reduzieren, die mit der PCI-Bewertung verbunden sind.

Segmentierung sorgt aber generell für eine bessere Netzwerksicherheit. Im Falle einer Umgebung, in der mit Karteninhaberdaten hantiert wird, also einer CDE (Cardholder Data Environment), ist ein beschränkter Zugang einfach besser.”

Seit Jahren beklagen sich Handelsfirmen über den Mangel an Leitlinien seitens des PCI Security Standards Council (SSC) rund um die Segmentierung. Der SSC erhörte schließlich diese Rufe, erkannte den Bedarf und veröffentlichte im Dezember 2016 einen entsprechenden Leitfaden (Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation). Eine der wichtigsten Anstrengungen in dieser Hinsicht wurde umgesetzt durch eine Klarstellung, wie ein „PCI-In-Scope-System“ aussehen muss.

PCI gilt für alle Systemkomponenten, die in der Karteninhaberdaten-Umgebung, also CDE, enthalten oder damit verbunden sind. Die CDE umfasst Personen, Prozesse und Technologien, die Karteninhaberdaten oder sensible Authentifizierungsdaten speichern, verarbeiten oder übertragen. Die offizielle PCI-Definition einer Systemkomponente ist „jede Netzwerkkomponente, jeder Server oder jede Anwendung, die in der CDE enthalten oder damit verbunden ist“. Beispiele für Systemkomponenten sind demnach unter anderem:

Systeme, die Sicherheitsdienste bereitstellen (Authentifizierungsserver), erleichtern die Segmentierung (interne Firewalls) oder können sich auf die Sicherheit von Name-Resolution- oder Web-Redirection-Servern in der CDE auswirken.
 Virtualisierungskomponenten (virtuelle Maschinen, Switches, Router, Appliances, Applikationen, Desktops und Hypervisors)
 Netzwerkkomponenten (Firewalls, Switches, Router, Wireless Access Points, Netzwerkgeräte sowie andere Sicherheitshardware)
 Server (Web, Anwendung, Datenbank, Authentifizierung, Mail, Proxy, Timing, DNS)
 Applikationen (kommerzielle Standardprodukte ebenso wie kundenspezifisch angepasste Applikationen, intern und extern entwickelt)
 Jede andere Komponente oder ein Gerät, das sich innerhalb der CDE befindet oder mit dieser verbunden ist.

Der PCI SSC erklärt nun auch, wie eine adäquate logische Segmentierung aussehen muss, um die PCI-Compliance möglichst unkompliziert zu gestalten. Allerdings herrscht nach wie vor viel Verwirrung hinsichtlich neuer PCI-relevanter Technologien und Prozesse.

Zero-Trust-Netzwerke

In den letzten Jahren hat sich das Prinzip des Zero Trust Network (ZTN) etabliert: ein Netzwerk, das sensible Daten in Mikroperimeter segmentiert und schützt.”

Das Konzept eines ZTN wurde 2010 von John Kindervag (damals bei Forrester Research und jetzt bei Palo Alto Networks) entwickelt und erstmals 2012 im Forrester-Report Build Security Into Your Network’s DNA: The Zero Trust Network Architecture umfassend beschrieben. ZTN ist mehr denn je ein heißes, aber auch komplexes Thema. „Zero Trust Networks: Building Secure Systems in Untrusted Networks” von Evan Gilman und Doug Barth ist die jüngste Neuerscheinung in Buchform zu diesem Thema.

Das Zero Trust-Modell basiert auf der Vorstellung, dass der gesamte Netzwerkverkehr als nicht vertrauenswürdig betrachtet werden sollte.”

ZTN ist in drei Konzepte unterteilt, die folgende Szenarien ausschließen:

1. Vertrauenswürdige und nicht vertrauenswürdige Schnittstellen auf Sicherheitsgeräten
2. Vertrauenswürdige und nicht vertrauenswürdige Netzwerke
3. Vertrauenswürdige und nicht vertrauenswürdige Benutzer

IT-Sicherheitsarchitekten müssen gewährleisten, dass alles, was dem Netzwerk hinzugefügt wird, vertrauenswürdig ist und diese vertrauenswürdige Ressource adäquat geschützt werden kann. Netzwerke müssen von innen heraus entworfen werden, um der PCI-DSS-Segmentierung gerecht zu werden. Durch die proaktive Gestaltung der Sicherheit in der CDE kann eine effektive Segmentierung erreicht werden, so dass mehr Bedrohungen verhindert werden.

Nicht-gelistete Verschlüsselungslösungen

Ende 2012 hat der PCI SSC seine ursprüngliche P2PE-Suite, die Compliance-Standards enthält, veröffentlicht. Diese hat sich seitdem zu einer umfassenden Sammlung von Sicherheits- und Compliance-Anforderungen entwickelt, die alle Aspekte der P2PE-Implementierung für Händler, Dienstleister, unterstützende Technologie und Zahlungsanbieter abdeckt. Die Einführung von P2PE-Standards in der Industrie war zunächst recht langsam, zum Teil aufgrund der öffentlichen Wahrnehmung der Gesamtkomplexität und der Kosten, die mit zertifizierten P2PE-Architekturen verbunden sind.

Autor Dipl.-Ing. Thorsten Henning
Dipl.-Ing. Thorsten Henning beschäftigt sich seit über 20 Jahren mit Netzwerken und IT-Sicherheit. Er leitet bei Palo Alto Networks das Systems Engineering für Zentral- und Osteuropa und berät Großkunden zu IT-Sicherheitslösungen der nächsten Generation – Netzwerk, Cloud und Endpoints inbegriffen. Zuvor war Thorsten Henning für namhafte Hersteller wie 3Com, Ascend Communications, Lucent Technologies und Juniper Networks tätig.

Darüber hinaus begannen einige Händler damit, P2PE in reduziertem Umfang umzusetzen. Ein gutes Beispiel für eine solche „P2PE-Lite“-Implementierung ist die Verwendung von PTS-genehmigten (PIN Transaction Security) POI-Geräten (Point-of-Interaction), die „Encrypt-at-the-swipe“-Fähigkeiten bereitstellen, aber keine weiteren P2PE-Sicherheitskontrollen. Manchmal wurden die Spezifikationen nur in einer sicheren Entschlüsselungsumgebung verwendet, um die Daten zu entschlüsseln.

Im Laufe der Zeit behaupteten viele Befürworter solcher Implementierungen, dass diese P2PE-Lite-Lösungen die gleichen Fähigkeiten zum Schutz und für die Reduzierung des PCI-Bereichs wie richtig zertifizierte P2PE-Lösungen bieten. Nach einer Weile begann dieser Mythos an Dynamik zu gewinnen, führte aber zu Kontroversen, Verwirrung und Meinungsverschiedenheit zwischen PCI-Profis und ihren Kunden. Händler und Dienstleister, die solche Lösungen implementierten, bestanden darauf, ein PCI-Niveau zu erhalten, das vollständig zertifizierten P2PE-Architekturen entspricht.

Die Lösung des Problems

Um das Problem zu lösen, hat der PCI SSC eine konzertierte Antwort auf dieses Szenario herausgegeben. Hierzu wurden die beiden Leitfäden Assessment Guidance for Non-Listed Encryption Solutions und Frequently Asked Questions: Assessment Guidance for Non-Listed Encryption Solutions herausgegeben.

Der PCI SSC hat nun klargestellt, dass nur vollständig zertifizierte P2PE-Lösungen die maximale Reduzierung des PCI-Bereichs für Händler und Dienstleister bieten können. Sie haben auch festgestellt, dass Händler, die bereits die Implementierung nicht-gelisteter Verschlüsselungslösungen (NLES) durchführen oder abgeschlossen haben, die folgenden Maßnahmen ergreifen müssen:

1. Ein Händler, der eine NLES implementiert, sollte eine Ermittlung der Bereichsreduzierung anfordern, die von seiner abrechnenden Bank vorgenommen werden soll.
2. Die abrechnende Bank und der Zahlungsapplikationsanbieter sollten sich dann an einen P2PE-QSA (Qualified Security Assessor) wenden, um eine P2PE-Lückenbewertung der NLES (E2EE)-Anwendung in Bezug auf alle relevanten P2PE-Anforderungen durchzuführen.
3. Der P2PE-QSA wird die Architektur beurteilen und anschließend einen sogenannten NESA-Report (Non-listed Encryption Solution Assessment) für nicht-gelistete Verschlüsselungslösungen erstellen. Ein solcher Bericht wird sich damit befassen, ob zwischen dem, was für eine P2PE-zertifizierte Lösung und die vorgeschlagene NLES-Lösung erforderlich ist, keine Lücken bestehen.
4. Händler sollten verlangen, dass ihr NLES-Zahlungsapplikationsanbieter mindestens einmal jährlich einen NEAS-Bericht zur Verfügung stellt oder wenn sich die Applikation ändert.

Wenn die vorherigen Schritte einer bevorstehenden PCI-DSS-Bewertung abgeschlossen sind, kann der bestätigende QSA sowohl die tatsächliche Implementierung als auch die P2PE-QSA-Rückmeldung auswerten. So lässt sich feststellen, ob alle Compliance-Kriterien ordnungsgemäß erfüllt sind. Wenn ja, kann der QSA alle Anfragen zur Reduzierung des PCI-DSS-Umfangs seitens P2PE-QSA, Händler und der abrechnenden Bank bestätigen.

Schlussfolgerungen

Da sich die PCI-SSC-Suite mit ihren Sicherheits- und Compliance-Standards weiterentwickelt, dürfte dies auch für die scheinbar nie enden wollende Diskussion über PCI-Umfang und Reduzierung gelten.

Das Konzept der PCI-Bereichsreduzierung, wie es innerhalb der Standards anerkannt ist, ist nicht nur zulässig, sondern wird ausdrücklich empfohlen.”

Netzwerksegmentierung und logische Abstraktion von Zahlungsapplikationskomponenten sind zwei sehr leistungsstarke Konzepte, die derzeit für die Reduzierung des PCI-Bereichs in vielen Karteninhaberdatenumgebungen anwendbar sind. Die richtige Interpretation der PCI-Scoping-Effekte und deren mögliche Reduktion sind zu gleichen Teilen „Kunst“ und „Wissenschaft“. Der Konsens der Industrie in Bezug auf diese Konzepte ist von größter Bedeutung, um die Einhaltung und Konsistenz der Sicherheitskontrollen in den zugehörigen PCI-Disziplinen zu gewährleisten.aj

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert