Eine einfache Übersicht darüber, wie man PCI DSS 4.0 aus Entwicklersicht angehen und die Compliance beschleunigen kann
Seien wir ehrlich: Da der Payment Card Industry Data Security Standard (PCI DSS) 4.0 mehr als 356 Seiten umfasst, kann er für den durchschnittlichen Softwareentwickler, der sich mit der Kunst der Cybersicherheit nicht so gut auskennt, etwas entmutigend sein. Allerdings ist PCI DSS ein wichtiger Standard und eine Reihe von Anforderungen, die zur Bewertung und zum Benchmarking des Sicherheitszustands von Zahlungen verwendet werden. PCI DSS enthält eine Mischung aus Anforderungen an Softwareentwickler, Produktmanager, Cybersicherheitsexperten, Finanz- und andere Supportmitarbeiter, sodass Sie es möglicherweise als eine Initiative eines gesamten Unternehmens betrachten. Mein Ziel in diesem Artikel ist es, PCI DSS-Anforderungen auf die Softwareentwicklung abzubilden und es einfacher zu machen, Entscheidungen zur Softwaresicherheit zu planen.
Eine Einschränkung: Es gibt unzählige PCI-Standards. Wenn Ihr Unternehmen Zahlungssoftware oder andere verwandte Software entwickelt, die PCI SSC-Konformität erfordert, wird dieser Artikel nicht auf diese Anwendungsfälle eingehen. Wie bei den meisten Dingen in der Cybersicherheit kommt es auf den Kontext an und es lohnt sich, Ihren Qualified Security Assessor (QSA) zu engagieren, um sicherzustellen, dass Sie auf dem richtigen Weg sind.
Aus Entwicklersicht verwende ich einen einfachen Ansatz für PCI DSS-Anforderungen, um Planung und Überprüfung als Teil des Softwareentwicklungslebenszyklus zu ermöglichen. Um mitzumachen, sollten Sie zur PCI DSS-Site navigieren und sich das Prioritized Approach Tool für v4.0 holen. Es ist wirklich hilfreich!
Erstens enthält die PCI DSS Prioritized Matrix zwölf Anforderungen, die in sechs Ziele kategorisiert sind, mit vielen Unteranforderungen und Klarstellungen unter jeder Hauptanforderung. Während eine Organisation alle PCI-DSS-Anforderungen erfüllen muss, ist es wichtig, eine Entwicklerperspektive zu haben, wie diese Anforderungen während des Softwareentwicklungsprozesses im Vorfeld bewertet werden müssen. Auf der obersten Ebene finden Sie hier ein Diagramm, das zeigt, wie ich entscheide, was je nach Person und Anwendungsfall relevant ist:
