PCI-Standards: Anforderungen an Open-Source-Sicherheit – wie erfüllen Sie sie?

Angesichts der zunehmenden Nutzung von Open-Source-Sicherheit in der modernen Softwareentwicklung ist es dringend erforderlich, Open Source sicher einzusetzen. Doch Open-Source-Sicherheit ist noch nicht flächendeckend etabliert: Ein aktueller Bericht von Snyk zeigt, dass 37 % der Open-Source-Entwickler während ihres Continuous-Integration-Prozesses (CI) keinerlei Sicherheitstests durchführen! Das Wachstum von Open Source bei gleichzeitig hinterherhinkenden Sicherheitsstandards hat viele Regulierungsbehörden und Branchenaufsichtsstellen dazu veranlasst, auf strengere und klarere Regeln zum Schutz von Anwendungen mit Open-Source-Code hinzuarbeiten.

PCI greift das Thema Open Source auf

Im Januar 2019 rief der Payment Card Industry Security Standards Council das PCI Software Security Framework (SSF) ins Leben, das sich auf die Anwendungssicherheit konzentriert. Ergänzend wurde der Secure Software Lifecycle (SLC) Standard eingeführt – ein Teilbereich des PCI Software Security Frameworks, der Sicherheitsanforderungen und Bewertungsverfahren festlegt. Damit können Softwareanbieter überprüfen, wie sie die Sicherheit von Zahlungssoftware während ihres gesamten Lebenszyklus gewährleisten.

(Hinweis: Das neue Framework ersetzt die bisherigen Richtlinien des PCI Payment Application Data Security Standard [PCI PA-DSS], der in den kommenden Jahren außer Kraft gesetzt wird.)

Wir bei Snyk freuen uns, dass PCI die Bedeutung der Absicherung von Open-Source-Komponenten im Code anerkennt und Unternehmen dazu anhält, die Verantwortung für die Sicherheit im Softwareentwicklungslebenszyklus aktiv „nach links zu verlagern“. Je früher wir bewährte Sicherheitspraktiken in den Softwarelebenszyklus integrieren können – insbesondere bei Open Source –, desto sicherer werden unsere Anwendungen.

Wie bei vielen anderen Compliance-Frameworks kann es jedoch schwierig sein, neue Regeln zu verstehen und umzusetzen. Deshalb möchten wir Ihnen einen Einblick in die neuen PCI-Compliance-Regeln geben und erläutern, wie Sie die aktualisierten Anforderungen speziell in Bezug auf Open Source erfüllen können.

Für wen sind die PCI-Aktualisierungen relevant?

Der PCI Secure Software Standard (und der zugrunde liegende SLC Standard) gilt für Zahlungssoftware, die an Dritte verkauft, verteilt oder lizenziert wird, damit diese Zahlungstransaktionen durchführen können. Das PCI Software Security Framework ist besonders relevant für Anbieter, die Anwendungen zur Zahlungsabwicklung entwickeln und diese Lösungen an andere verkaufen. Die Aktualisierung betont, dass sowohl Sicherheitsverantwortliche als auch Engineering-Teams für die Einhaltung der Compliance-Standards verantwortlich sind.

Unternehmen, die Zahlungen akzeptieren, müssen gemäß den PCI-DSS-Richtlinien noch weitere Regeln beachten. Die Standards, auf die wir uns in diesem Beitrag konzentrieren, gelten jedoch direkt für Softwareentwickler.

Einmal ist keinmal: Kontinuität ist entscheidend

Der vielleicht wichtigste Aspekt des neuen Standards ist das Konzept der „kontinuierlichen Anwendungssicherheit“. Der Standard verlangt von Unternehmen, Schwachstellen und Schutzmaßnahmen kontinuierlich zu überwachen und sich an veränderte Bedrohungen anzupassen. Außerdem müssen Unternehmen die Sicherheitskontrollen ihrer Anwendungen fortlaufend testen und nachweisen, dass diese im Laufe der Zeit weder geschwächt noch unwirksam geworden sind. Die Anforderungen sind hoch – und das ist gut so. Sie sorgen dafür, dass Sicherheit als Teil des CI/CD-Prozesses behandelt wird und nicht erst im Nachhinein Beachtung findet.

Was steckt hinter den PCI-Aktualisierungen? Warum gerade jetzt?

Warum wurden diese Standards also aktualisiert? Wie bereits in der Einleitung erwähnt, hat sich die Softwareentwicklung im Laufe der Jahre weiterentwickelt. Die aktualisierten PCI-Standards reagieren durch eine angepasste Herangehensweise an die Softwaresicherheit gezielt auf diesen Wandel. Insbesondere setzen immer mehr Softwareentwicklungsstrategien auf Open-Source-Komponenten. Daher mussten Anforderungen und Kontrollen für Open Source ergänzt werden. In unserem Bericht „State of Open Source Security 2019“ haben wir einige Zahlen zu diesem Bereich vorgestellt, darunter diese aufschlussreichen Ergebnisse:

• Die Zahl der Schwachstellen in Anwendungsbibliotheken ist innerhalb von zwei Jahren um 88 % gestiegen81 % der Befragten sind der Meinung, dass Entwickler für Sicherheit verantwortlich sein sollten, verfügen dafür aber nicht über die nötigen VoraussetzungenOpen-Source-Maintainer wollen für Sicherheit sorgen, doch 70 % fehlt es an den nötigen Kenntnissen

Neben der zunehmenden Verbreitung von Open-Source-Entwicklung integrieren viele Unternehmen inzwischen Sicherheitstools in ihre DevOps-Pipeline. Diese Tools sind im Laufe der Zeit proaktiver und effektiver geworden. Deshalb ist robuste Sicherheit in kontinuierlichen Entwicklungs- und Integrationszyklen heute nicht nur notwendig, sondern – eine gute Nachricht – auch leichter erreichbar denn je.

Die Rolle von Open Source in den neuen PCI-Aktualisierungen

Sehen wir uns genauer an, welche Aspekte der neuen PCI-Regeln für Open-Source-Softwarekomponenten gelten. (Die vollständigen Standards können Sie auch hier einsehen.)

1. Rechenschaftspflicht der Sicherheitsverantwortlichen

Der Wortlaut: Abschnitt 1.1 – Die Geschäftsleitung des Anbieters weist einer Person oder einem Team offiziell die Verantwortung dafür zu, die Sicherheit der Produkte und Services des Anbieters zu gewährleisten.

Was das für Sie bedeutet: Sicherheitsverantwortliche in großen Unternehmen müssen die Verantwortung für Sicherheit übernehmen und entsprechende Anpassungen an Entwicklungsprozessen und Tools vornehmen, damit die aktualisierten PCI-Anforderungen erfüllt werden können.

Wie Snyk helfen kann: Sicherheitsverantwortliche haben bereits viele Prioritäten. Snyk kann die Einhaltung der neuen PCI-Standards vereinfachen, indem die Lösung Einblick in Open-Source-Abhängigkeiten und Lizenzrisiken bietet, damit diese zeitnah und angemessen behandelt werden können.

2. Die Rolle der Entwickler

Der Wortlaut: Abschnitt 1.2.a – Personen (einschließlich Drittpersonal), die an Konzeption, Entwicklung, Tests und Wartung der Produkte und Services des Anbieters beteiligt sind, müssen dafür verantwortlich gemacht und zur Rechenschaft gezogen werden, dass dessen Software gemäß der Sicherheitsstrategie und allen geltenden Sicherheitsanforderungen entwickelt und gewartet wird.

Was das für Sie bedeutet: Die neuen Anforderungen heben ausdrücklich die Beteiligung und Verantwortlichkeit von Entwicklern („Softwareentwicklungspersonal“) hervor. Sie müssen an den festgelegten Schritten zur Erfüllung der Compliance mitwirken.

Wie Snyk helfen kann: Der entwicklerorientierte Sicherheitsansatz von Snyk erleichtert Entwicklern die Einführung bewährter Sicherheitspraktiken. Mit Snyk können Entwickler Schwachstellen im Rahmen ihrer bestehenden Softwareentwicklungsprozesse finden und beheben. Darüber hinaus ermöglicht Snyk Ein-Klick-Fix-PRs und automatisierte Fehlerbehebungen direkt in Git, damit Entwickler entdeckte Schwachstellen schnell beheben können.

3. Open-Source-Komponenten

Der Wortlaut: Abschnitt 3.2.b – Werden Open-Source-Softwarekomponenten als Teil der Software verwendet, muss der Prüfer die Nachweise des Anbieters untersuchen, darunter Prozessdokumentation und Bewertungsergebnisse, um zu bestätigen, dass diese Komponenten verwaltet werden.

Was das für Sie bedeutet: Open Source kann die Softwareentwicklung erheblich voranbringen. Dennoch müssen Sie sorgfältig prüfen, bevor Sie Open-Source-Komponenten in Ihre Anwendung aufnehmen. Das Unternehmen sollte:

• ein Verzeichnis aller verwendeten Open-Source-Komponenten führen, einschließlich Container-Images

• einen ausgereiften Prozess zur Analyse und Behebung von Schwachstellen entwickeln

• Schwachstellen in Open-Source-Komponenten überwachen

• eine Patch-Strategie implementieren

Wie Snyk helfen kann: Mit Snyk können Kunden Abhängigkeiten in ihren Anwendungen erfassen und aktuelle Schwachstellen erkennen. Die Lösung prüft fortlaufend anhand einer umfassenden Schwachstellendatenbank auf neue Risiken. Snyk bietet umfassende Möglichkeiten zum Patchen und Beheben von Schwachstellen. Automatisierte Fix-Pull-Requests beschleunigen die Priorisierung und Behebung. So automatisiert Snyk die Einhaltung von Abschnitt 3.2.b und reduziert den manuellen Aufwand – und damit auch den Zeitaufwand für die Compliance. Mit Snyk können Teams nachweisen, dass sie Kontrollpunkte, Behebungsmaßnahmen und Überwachung für potenzielle Schwachstellen in Open-Source-Komponenten eingerichtet haben.

PCI-Compliance als Anreiz, Sicherheit „nach links zu verlagern“

Während Unternehmen weiterhin Sicherheit nach links verlagern, entstehen neue Herausforderungen und Chancen. Die aktualisierten PCI-Compliance-Anforderungen tragen der Realität heutiger Softwareentwicklungsprozesse und der weiten Verbreitung von Open Source Rechnung. Auch wenn die Anforderungen zunächst hoch erscheinen mögen: Ihre Erfüllung hilft Ihrem Unternehmen, die Sicherheit zu verbessern und das Gesamtrisiko zu senken. Der Aufwand lohnt sich also – auch über den Nutzen der Compliance hinaus.

Die größte Herausforderung bei der Erfüllung der neuen PCI-Standards wird für viele Unternehmen darin bestehen, erstmals Sicherheitstools speziell für Open Source einzuführen, da diese meist noch nicht zum vorhandenen Werkzeugbestand gehören. Wenn Sie bewährte Sicherheitspraktiken für Open Source in Ihre CI/CD-Pipeline integrieren, werden sie zu einem natürlichen Bestandteil des Entwicklungsprozesses – statt am Ende zur Belastung zu werden oder bei der öffentlichen Bekanntgabe neuer Schwachstellen hektisch nach Lösungen suchen zu müssen.

Wenn Sie erfahren möchten, wie Snyk Sie dabei unterstützt, die neuen PCI-Compliance-Standards für Open Source einfach zu erfüllen, können Entwickler noch heute kostenlos mit Snyk starten.