PCI DSS: SSL Anforderungen an das Zertifikatsmanagement

Für IT- und Sicherheitsteams steht die Einhaltung von Vorschriften ganz oben auf der Prioritätenliste. Wenn Sie in Ihrem Unternehmen für die Verwaltung von Schlüsseln und Zertifikaten zuständig sind, wissen Sie das nur zu gut.

PCI DSS ist eine der gängigsten und am weitesten verbreiteten Compliance-Vorgaben. Grundsätzlich gilt: Wenn Ihr Unternehmen Kredit- oder Debitkarten als Zahlungsmittel akzeptiert, dann gilt PCI DSS auch für Sie. Die gute Nachricht ist, dass die meisten der 12 PCI DSS-Anforderungen einfach vernünftige Sicherheitskontrollen sind, die Sie bereits eingeführt haben sollten.

In diesem Blog befassen wir uns mit dem PCI DSS, seinen Änderungen und der Zuordnung der Zertifikatsanforderungen des PCI DSS SSL zu Ihren Schlüssel- und Zertifikatsverwaltungspraktiken.

Der Payment Card Industry Data Security Standard (PCI DSS) ist eine Reihe von Regeln und Anforderungen zum Schutz von sensiblen Karteninhaberdaten, Krediten und Transaktionen und erleichtert die breite Einführung von einheitlichen Datensicherheitsmaßnahmen.

Der Standard bietet einen Grundstock an technischen und betrieblichen Anforderungen zum Schutz von Finanzdaten. Ziel des PCI DSS ist der Schutz von Karteninhaberdaten und sensiblen Authentifizierungsdaten, wo immer sie verarbeitet, gespeichert oder übertragen werden.

PCI DSS gilt für alle Organisationen, die an der Verarbeitung von Kreditkarten beteiligt sind, einschließlich Händlern, Verarbeitern, Acquirern, Emittenten und Dienstleistern. Der Standard wird von einem unabhängigen Gremium, dem PCI Security Standards Council (SSC), verwaltet, das von Visa, MasterCard, American Express, Discover und JCB gegründet wurde.

Im Folgenden finden Sie einen kurzen Überblick über die 12 wichtigsten Compliance-Anforderungen des PCI DSS:

Zweck des PCI DSS ist es, die Kontrolle von Karteninhaberdaten zu verstärken, um den Kreditkartenbetrug zu verringern. Der PCI DSS bietet Kartenherausgebern einen zusätzlichen Schutz, indem er von den Händlern verlangt, bei der Speicherung, Verarbeitung und Übermittlung von Karteninhaberdaten ein Mindestmaß an Sicherheit zu gewährleisten.

Schlüssel und digitale Zertifikate spielen eine wichtige Rolle bei der Erfüllung und Einhaltung des PCI DSS. Diese kryptografischen Assets werden verwendet, um Daten zu sichern, die Kommunikation sicher und privat zu halten und Vertrauen zwischen kommunizierenden Parteien aufzubauen - aber auch sie müssen entsprechend gesichert und verwaltet werden, um die PCI-Konformität zu gewährleisten.

Lassen Sie uns einige der wichtigsten PCI DSS-Anforderungen für die Verwaltung von SSL/TLS Zertifikaten in Ihrer Umgebung aufschlüsseln.

Wenn keine starke Authentifizierung und verschlüsselte Kommunikation implementiert sind, könnten sensible betriebliche oder privilegierte Kontodaten abgefangen werden, z. B. durch einen Man-in-the-Middle-Angriff. Ein böswilliger Akteur könnte dann diese Informationen nutzen, um auf das Unternehmensnetzwerk zuzugreifen und Finanzdaten zu stehlen oder zu gefährden. Um eine "starke Kryptographie" zu etablieren, verlangt der PCI DSS die Verwendung von branchenweit anerkannten Protokollen mit angemessener Schlüsselstärke und Schlüsselverwaltung (siehe NIST SP 800-52 und SP 800-57).

Kernkompetenzen:

• Zentralisierte Sichtbarkeit von Schlüsselstärken, Algorithmen und Protokollen im Einsatz
• Richtlinienbasierte Arbeitsabläufe zum Ausstellen, Bereitstellen, Erneuern und Widerrufen von Schlüsseln und Zertifikaten
• Automatisierte Handhabung des Lebenszyklus von Schlüsseln und Zertifikaten

Diese Bestimmung unterstreicht die Sichtbarkeit aller Systemkomponenten, einschließlich der Schlüssel und Zertifikate. Das Führen einer aktuellen Liste aller Schlüssel und Zertifikate ermöglicht es einer Organisation, den Umfang ihrer Umgebung genau und effizient zu definieren. Wird kein Inventar geführt, führt dies zu unzulässigen, abgelaufenen und nicht verfolgten Zertifikaten. Dies führt zu erheblichen Ausfällen oder schlimmer noch, zu Sicherheitsverletzungen. Die meisten Unternehmen wissen jedoch nicht, wie viele Schlüssel und Zertifikate in ihrem Netzwerk aktiv verwendet werden, und verlassen sich häufig auf manuelle, fehleranfällige interne Skripte oder manuelle Tabellen.

Kernkompetenzen:

• Erkennung von Zertifikaten über alle Netzwerkendpunkte, Anwendungen, Zertifizierungsstellen (CAs), Schlüssel- und Zertifikatspeicher
• Meldung und Warnung bei gefälschten, abgelaufenen oder nicht konformen Zertifikaten

Während sich diese Anforderung auf netzwerkbasierten Schutz (d. h. Viren- und Malware-Schutz) zum Schutz von Computern vor Malware konzentriert, zielen moderne Malware-Kampagnen zunehmend auf sensible Computeridentitäten ab, wie z. B. SSH-Schlüssel, SSL/TLS und Code-Signatur-Zertifikate. Cyberkriminelle und APT-Gruppen (Advanced Persistent Threats) nutzen diese Schlüssel und Zertifikate, um sich als vertrauenswürdig auszugeben und die Abwehrmaßnahmen zu umgehen.

Kernkompetenzen:

• Kontinuierliche Überwachung des Schlüssel- und Zertifikatsbestands auf Anomalien
• Angemessene Richtlinien für die Erzeugung und Speicherung privater Schlüssel
• Strenge Zugangskontrollen und hardware-basierter Schutz von Code-Signatur-Schlüsseln
• Richtlinienbasierte Arbeitsabläufe für die Erstellung, Bereitstellung und Rotation von SSH-Schlüsseln

PCI DSS verlangt, dass Unternehmen den Zugriff auf Systeme und Karteninhaberdaten einschränken. Dazu gehört auch die Beschränkung des Zugriffs auf privilegierte Benutzer-IDs und Anmeldedaten, einschließlich Schlüssel und Zertifikate. Durch die Durchsetzung von Beschränkungen der Nutzung und des Zugriffs auf Ihre kryptografischen Ressourcen nach dem Prinzip des geringsten Rechtsanspruchs wird das Ausmaß des durch unbefugten Zugriff verursachten Schadens begrenzt. Ohne angemessenen Schutz können Angreifer vertrauenswürdige Schlüssel und Zertifikate nutzen, um ihre Berechtigungen zu erhöhen und sich seitlich zwischen Rechnern zu bewegen.

Kernkompetenzen:

• Rollenbasierte Berechtigungen für die Ausstellung und Verwendung von Schlüsseln und Zertifikaten
• Automatische Überwachung und Behebung von nicht autorisierten Schlüsseln und Zertifikaten

Die Anforderung 8.6 schließlich bezieht sich auf die Funktion der Authentifizierung durch Zertifikate. Zertifikate ermöglichen eine einfache und leistungsstarke Authentifizierung, aber sie müssen einem individuellen Konto oder Benutzer zugewiesen werden und dürfen nicht gemeinsam genutzt werden. Kontrollmechanismen zur eindeutigen Identifizierung des Besitzers eines Schlüssels oder Zertifikats (und zur Beendigung oder Änderung des Besitzes, falls dieser ausscheidet) verhindern, dass sich unbefugte Benutzer über einen gemeinsamen Authentifizierungsmechanismus Zugang verschaffen.

Kernkompetenzen:

• Möglichkeit der Zuweisung und Verfolgung des Eigentums an Schlüsseln und Zertifikaten
• Einfache Suche und Widerruf von Zertifikaten in Ihrem Bestand

Unabhängig davon, ob Sie direkt mit der Verwaltung von SSL/TLS Zertifikaten zu tun haben oder nicht, ist es wichtig, dass Sie die Notwendigkeit der Webverschlüsselung verstehen und wissen, wie sie sich auf Ihr Unternehmen auswirkt.

Es ist auch wichtig zu verstehen, warum die Verschlüsselungsprotokolle, auf die wir uns heute verlassen, in Zukunft unweigerlich unsicher sein werden. Wie können wir das wissen? Weil Schwachstellen in SSL und frühen TLS Protokollen zu zahlreichen Angriffen geführt haben, wie Heartbleed und POODLE. Hacker versuchen, diese veralteten Protokolle auszunutzen, um in Netzwerke einzudringen und sensible Karteninhaberdaten zu kompromittieren.

Infolgedessen haben sich die PCI DSS-Anforderungen für SSL/TLS geändert, um Schritt zu halten. Hier werfen wir einen Blick darauf, wie sich die Anforderungen für die Migration von SSL/TLS von PCI DSS v3.0 zu PCI DSS v3.2 entwickelt haben.

Als PCI DSS v3.0 am 1. Januar 2014 in Kraft trat, wies das Dokument darauf hin, dass "einige Protokollimplementierungen (wie SSL v2.0, SSH v1.0 und TLS 1.) bekannte Schwachstellen aufweisen, die ein Angreifer nutzen kann, um die Kontrolle über das betroffene System zu erlangen". Es bestand jedoch keine Verpflichtung, aktuellere Protokolle zu verwenden.

Kurz nach Inkrafttreten des PCI DSS v3.0 wurde im April 2015 der neue PCI DSS v3.1 eingeführt. Ein wesentlicher Bestandteil der neuen Version waren strengere Anforderungen an die Nutzung von TLS.

Die neue Version verpflichtete Organisationen, SSL 3.0 und frühere Versionen von TLS (1.0) bis zum 30. Juni 2016 zu deaktivieren. Die Frist wurde jedoch später auf den 30. Juni 2018 verschoben.

Die aktuellste Version ist PCI DSS v3.2 (zum Zeitpunkt der Veröffentlichung dieses Blogs). Die Version 3.2 wurde im April 2016 eingeführt und hat am 1. Februar 2018 offiziell die Version 3.1 als zu befolgenden Standard abgelöst.

Die neue Frist bis zum 30. Juni 2018 wurde in PCI DSS v3.2 aufgenommen, der eine Migration auf TLS 1.1 oder höher vorschreibt, mit Ausnahme einiger Zahlungsterminals (POI).

Das PCI SSC hat mit der Entwicklung von PCI DSS v4.0 begonnen, dessen endgültige Version derzeit für Mitte 2021 erwartet wird. Die neue Version wird voraussichtlich ein ergebnisorientiertes Dokument sein, wobei die Formulierung von "muss implementiert werden" zu "das Ergebnis ist" geändert wird. Außerdem wird der Schwerpunkt stärker auf Sicherheit als kontinuierlichen Prozess gelegt, der in die allgemeine Sicherheits- und Compliance-Position einer Organisation integriert ist.

Weitere Änderungen werden sein:

• Authentifizierung, insbesondere Berücksichtigung der NIST MFA/Passwort-Richtlinien
• Breitere Anwendbarkeit für die Verschlüsselung von Karteninhaberdaten in vertrauenswürdigen Netzwerken
• Überwachung der Anforderungen zur Berücksichtigung des technologischen Fortschritts
• Häufigere Tests von kritischen Kontrollen

Wenn auch nur ein einziger Schlüssel oder ein einziges Zertifikat kompromittiert wird, ist das digitale Vertrauen in Ihr Unternehmen unterminiert. Trotz des wachsenden Problems verwenden die meisten Unternehmen immer noch interne Skripte oder manuelle Tabellen, um den Überblick über ihre Schlüssel und Zertifikate zu behalten. Den Sicherheitsteams fehlt es an Transparenz und Automatisierung, um potenziellen Ausfällen, Sicherheitsvorfällen und vor allem Audit-Anforderungen einen Schritt voraus zu sein.

Das Problem wird durch die schiere Anzahl von Schlüsseln und Zertifikaten im Unternehmen vervielfacht, da in modernen Multi-Cloud-Umgebungen Tausende weitere hinzukommen. Diese hybride Infrastruktur schafft auch eine größere Angriffsfläche und erhöht das Risiko, dass Kreditkartendaten gestohlen oder kompromittiert werden.

Herkömmliche Ansätze für die Verwaltung von Schlüsseln und Zertifikaten können mit dem schnellen Wachstum und den Veränderungen in diesen neuen DevOps- und Multi-Cloud-Bereitstellungen einfach nicht Schritt halten. Es wird ein neuer Ansatz benötigt, der es Ihrem Unternehmen ermöglicht, zu automatisieren und zu skalieren und gleichzeitig die volle Kontrolle über den Lebenszyklus von Schlüsseln und Zertifikaten zu behalten - egal, wo sie sich befinden.

Ein automatisierter Ansatz für kryptografische Identitäten und Autorisierungen von Kreditkartendaten ist ein entscheidender Schritt zur Erfüllung und Aufrechterhaltung der PCI DSS-Konformität. PCI DSS unterstreicht, dass die Einhaltung der Vorschriften die alltägliche Sicherheitsstrategie des Unternehmens sein sollte.

Für die Bereitstellung von Sicherheitsrichtlinien, die sich nicht von der Realität unterscheiden, ist eine vollständig automatisierte Schlüssel- und Zertifikatsverwaltung ein Muss für die End-to-End-Bereitstellung von Verschlüsselung im modernen Finanzsektor. Die Automatisierung beseitigt die Schwachstellen, die durch fehleranfällige und zeitaufwändige manuelle Prozesse entstehen, und bietet eine hohe Skalierbarkeit. Darüber hinaus ermöglicht sie eine schnelle Behebung, so dass Fehler und Versäumnisse nicht zu erheblichen Sicherheitsverletzungen oder Ausfällen führen können.

Finden Sie heraus, warum führende Fortune-500-Banken und Finanzdienstleister bei der Unterstützung ihrer PCI-Compliance-Initiativen und der durchgängigen Automatisierung von PKI und Zertifikatslebenszyklen auf Keyfactor vertrauen.