Die überarbeiteten Richtlinien des PCI Security Standards Council: Ein ausreichender Schritt nach links?

Eine Version dieses Artikels wurde ursprünglich im Digital Transactions Magazine veröffentlicht.

Das PCI Security Standards Council hat in diesem Jahr eine völlig neue Reihe von Software-Sicherheitsrichtlinien im Rahmen seines PCI Software Security Frameworks veröffentlicht. Dieses Update zielt darauf ab, bewährte Verfahren der Softwaresicherheit an die moderne Softwareentwicklung anzupassen. Es ist eine fantastische Initiative, die anerkennt, wie sich dieser Prozess im Laufe der Zeit verändert hat, und ein Umdenken bei den Sicherheitsstandards erfordert, die lange vor der rasanten Digitalisierung unseres Lebens festgelegt wurden.

Dies ist ein klarer Beweis dafür, dass sich unsere Branche intensiver mit der Idee anpassungsfähiger Richtlinien auseinandersetzt – Richtlinien, die sich mit unseren sich wandelnden Bedürfnissen weiterentwickeln – sowie mit den Anforderungen einer Cybersicherheitslandschaft, die sehr schnell außer Kontrolle geraten könnte, wenn wir bei unseren sicheren Entwicklungsprozessen weiterhin nachlässig sind. Da das PCI Security Standards Council als Aufsichtsgremium in der Banken- und Finanzbranche fungiert (und damit die Sicherheitsstandards für die Software festlegt, der wir beim Schutz unseres Geldes, unserer Kreditkarten, Online-Transaktionen und am Point-of-Sale vertrauen), trägt es ein hohes Risiko und hat ein großes Interesse daran, dieses zu reduzieren.

Obwohl diese Standards zweifellos eine Verbesserung gegenüber der vorherigen Version darstellen und dazu beitragen, die Lücke bei der schnellen, innovativen Funktionsentwicklung zu schließen, die Sicherheit auch als Teil ihrer allgemeinen Qualitätsbewertung priorisiert, ist es etwas enttäuschend festzustellen, dass wir noch einen langen Weg vor uns haben.

Nein, das ist kein „Bah, Humbug!“ meinerseits gegenüber dieser Initiative. Tatsache ist, dass uns diese neuen Sicherheitsrichtlinien einfach nicht weit genug nach links bringen.

Wir sind immer noch auf das Testen fixiert (und wir testen zu spät).

Ein eklatantes Problem, das ich beim PCI Security Standards Framework festgestellt habe, ist die offensichtliche Abhängigkeit vom Testen. Natürlich muss Software weiterhin getestet werden (und der SAST/DAST/IAST-Prozess hat nach wie vor seine Berechtigung), aber wir tappen immer noch in dieselbe Falle und erwarten ein anderes Ergebnis.

Wer schreibt Zeile um Zeile Code, um die Software zu erstellen, die wir kennen, lieben und der wir vertrauen? Softwareentwickler.

Wer hat die undankbare Aufgabe, diesen Code entweder mit Scan-Tools oder durch manuelle Code-Reviews zu testen? AppSec-Spezialisten.

Was entdecken diese Spezialisten immer wieder? Dieselben Fehler, die uns schon seit Jahrzehnten plagen. Einfache Dinge, deren Behebung wir seit Jahren kennen: SQL-Injection, Cross-Site Scripting, Schwächen im Sitzungsmanagement... es ist wie „Und täglich grüßt das Murmeltier“ für diese Leute. Sie verbringen ihre Zeit damit, Code-Verletzungen zu finden und zu beheben, die Entwickler selbst schon seit Jahren hätten beheben können – nur wurde Sicherheit in ihrem Prozess nicht priorisiert. Besonders jetzt, im Zeitalter der agilen Entwicklung, in dem die Bereitstellung von Funktionen König ist und Sicherheit der Grinch, der den kreativen Prozess und den Triumph des Projektabschlusses stiehlt.

Dies ist keine negative Bewertung eines der beiden Teams; sowohl Entwickler als auch AppSec-Profis haben extrem wichtige Aufgaben zu erfüllen, aber sie stehen sich weiterhin gegenseitig im Weg. Diese Situation zementiert nur einen fehlerhaften SDLC, in dem Entwickler mit wenig Sicherheitsbewusstsein in einer negativen Sicherheitskultur arbeiten und unsicheren Code produzieren, der dann lange nach seiner ursprünglichen Erstellung gescannt, bewertet und korrigiert werden muss. AppSec hat kaum Zeit, die wirklich komplexen Probleme zu lösen, weil sie so sehr mit den kleinen, wiederkehrenden Problemen beschäftigt sind, die für ein Unternehmen zur Katastrophe führen könnten, wenn sie nicht kontrolliert werden.

Wir verschwenden Zeit, Geld und Ressourcen, indem wir zulassen, dass Tests als Allheilmittel für Sicherheitsschwächen im Code dienen. Und angesichts massiver Datenpannen, die fast täglich auftreten, funktioniert diese Methode offensichtlich nicht optimal, wenn überhaupt. Diese neuen Standards bewerten immer noch den Endproduktzustand (vielleicht unter der Annahme, dass alle Entwickler sicherheitsbewusst sind, was nicht der Fall ist): also ein Produkt, das bereits fertiggestellt ist. Dies ist die teuerste und schwierigste Phase, um Fehler zu beheben; es ist, als würde man ein schickes neues Haus bauen und erst am Tag des Einzugs ein Sicherheitsteam beauftragen, um nach Gefahren zu suchen. Wenn mit dem Fundament etwas nicht stimmt, kann man sich den Zeitaufwand, die Kosten und den Ärger vorstellen, um überhaupt an diese Stelle zu gelangen und die Probleme anzugehen. Es ist oft einfacher und billiger, einfach von vorne anzufangen (und was für ein unbefriedigender Prozess das für alle ist, die die erste Version gebaut haben).

Wir müssen unbedingt von Grund auf arbeiten: indem wir das Entwicklungsteam in bewährte Sicherheitspraktiken einbinden, sie mit dem Wissen befähigen, effizient und sicher zu programmieren, und zusätzlich eine positive Sicherheitskultur an jedem Arbeitsplatz schaffen und pflegen.

Ist das eine Lernkurve? Verdammt ja, das ist es. Ist es unmöglich? Definitiv nicht. Und es muss keine langweilige Plackerei sein. Trainingsmethoden, die direkt die kreativen Problemlösungsfähigkeiten der Entwickler ansprechen, waren im Banken- und Finanzsektor bereits immens erfolgreich, wenn Russ Wolfes Erfahrung bei Capital One ein Indikator ist.

Wir suchen immer noch nach dem perfekten „Endzustand“.

Wenn man die aktualisierten PCI-Sicherheitsstandards in dem Kontext betrachtet, für den sie gedacht sind – also dass Ihr fertiges, benutzerbereites Finanzprodukt diese bewährten Verfahren für optimale Sicherheit und Schutz befolgen muss –, dann sind sie absolut in Ordnung. Meiner Ansicht nach hätte jedoch jedes Unternehmen – ob Finanzbranche oder nicht – die besten Chancen, einen Software-Endzustand zu erreichen, der sowohl für Funktionsqualität als auch für einen hohen Sicherheitsstandard steht, wenn es nur einen Schritt zurücktreten und erkennen würde, dass es viel effizienter ist, dies von Beginn des Zyklus an zu tun.

Dieser perfekte Endzustand? Sie wissen schon, derjenige, der eintritt, wenn ein Produkt gescannt, manuell überprüft und perfekt und fehlerfrei herauskommt? Wir suchen immer noch danach. Zum jetzigen Zeitpunkt ist das ein Einhorn.

Warum ist er so schwer zu fassen? Es gibt eine Reihe von Faktoren:

• Scan-Tools sind zwar weit verbreitet, aber nicht immer effektiv. Fehlalarme sind ein frustrierender Zeitfresser, ebenso wie die Tatsache, dass DAST-, SAST- und PCI-Scans selbst in Kombination nicht jede Schwachstelle im Code aufdecken können. Sicher, sie könnten Entwarnung geben, aber suchen sie wirklich nach allem? Ein Angreifer braucht nur eine einzige Schwachstelle, um auf Bereiche zuzugreifen, die Sie für sicher halten.
• Entwickler machen immer wieder dieselben Fehler. Es gibt keinen Wissensaustausch über Sicherheit und keine etablierten, dokumentierten „Rezepte“ für sicheren Code.
• Es fehlt der Fokus auf eine kollaborative und positive Sicherheitskultur.
• Entwickler müssen mit den richtigen Tools ausgestattet werden, um Sicherheit direkt in ihre Produkte zu integrieren, ohne dabei ihre kreativen Prozesse oder agilen Methoden zu stören.

Diese Richtlinien bieten eine wertvolle Checkliste für Sicherheitsstandards, denen Software entsprechen sollte – doch darüber, wie man diesen Zustand am besten erreicht, gehen die Meinungen auseinander.

Unsichere Software existiert nicht, weil uns Scanner fehlen, sondern weil Entwickler keine benutzerfreundlichen und verständlichen Sicherheitstools erhalten, die sie bei ihrer Arbeit unterstützen.

Wir befinden uns in einer Phase des Wandels. Über Jahre hinweg war Softwaresicherheit oft optional. Heute ist sie im Grunde Pflicht – besonders für Unternehmen, die sensible Daten verwalten (Finanzen, Medizin, Sozialversicherung usw.).

Der PCI Security Standards Council setzt zwar Maßstäbe, doch ich würde mir wünschen, dass sie ihre Branchenrelevanz nutzen, um praxisnahe Richtlinien für Entwickler zu schaffen – mit Fokus auf positive Schulungen und Tools. Aktuell gibt es für Unternehmen kaum Druck, ihre Teams für Sicherheit zu sensibilisieren, und viele Entwickler unterschätzen die Tragweite kleiner, leicht behebbarer Fehler, wenn diese ausgenutzt werden.

Wie bei allem, was im Leben wirklich zählt, braucht es ein ganzes Team, um echte Veränderungen zu bewirken. Und der Wandel, der in der Luft liegt, wird uns hoffentlich alle einen Schritt weiter nach links bringen.