Die überarbeiteten Richtlinien des PCI Security Standards Council: Verschieben sie sich weit genug nach links?

Eine Version dieses Artikels wurde ursprünglich veröffentlicht in Magazin für digitale Transaktionen.

In diesem Jahr veröffentlichte der PCI Security Standards Council ein brandneues Set von Richtlinien zur Softwaresicherheit als Teil ihres PCI Software Security Framework. Dieses Update zielt darauf ab, bewährte Verfahren zur Softwaresicherheit mit der modernen Softwareentwicklung in Einklang zu bringen. Es ist eine fantastische Initiative, die anerkennt, wie sich dieser Prozess im Laufe der Zeit verändert hat. Sie erfordert ein Überdenken der Sicherheitsstandards, die lange vor der raschen Digitalisierung eines Großteils unseres Lebens festgelegt wurden.

Dies ist ein klarer Beweis dafür, dass sich unsere Branche stärker mit der Idee anpassungsfähiger Richtlinien befasst — solchen, die sich an unsere sich ändernden Bedürfnisse anpassen — sowie mit den Anforderungen einer Cybersicherheitslandschaft, die sehr schnell außer Kontrolle geraten könnte, wenn wir unsere sicheren Entwicklungsprozesse weiterhin lax gestalten. Da der PCI Security Standards Council als Leitungsgremium innerhalb der Banken- und Finanzbranche fungiert (indem er die Sicherheitsstandards für die Software festlegt, auf die wir vertrauen, um all unser Geld, unsere Kreditkarten, Online-Transaktionen und an der Kasse zu schützen), bergen sie natürlich ein großes Risiko und sind sehr motiviert, es zu reduzieren.

Obwohl diese Standards die Vorgängerversion sicherlich verbessern und die Lücke schließen, die wir bei der schnellen, innovativen Funktionsentwicklung haben, bei der auch Sicherheit als Teil der allgemeinen Qualitätsbewertung Priorität eingeräumt wird, ist es eine etwas enttäuschende Realität, dass wir noch einen langen Weg vor uns haben.

Nein, das sage ich nicht mit einem „Bah, Quatsch!“ zu dieser Initiative. Tatsache ist, dass uns diese neuen Sicherheitsrichtlinien einfach nicht weit genug nach links rücken.

Wir sind immer noch aufs Testen fixiert (und testen zu spät).

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

Wer schreibt Zeile für Zeile Codezeile um die Software zu entwickeln, die wir kennen, lieben und der wir vertrauen? Softwareentwickler.

Wer hat die wenig beneidenswerte Position, diesen Code entweder mit Scan-Tools oder manueller Codeüberprüfung zu testen? AppSec-Spezialisten.

Was entdecken diese Spezialisten weiterhin? Dieselben Bugs, die uns seit Jahrzehnten plagen. Einfache Dinge, von denen wir seit Jahren wissen, wie man sie repariert: SQL-Injektion, Site-übergreifendes Scripting, Schwächen beim Sitzungsmanagement... es ist wie Groundhog Day für diese Jungs. Sie haben ihre Zeit damit verbracht, Codeverstöße zu finden und zu korrigieren, die die Entwickler seit Jahren selbst beheben konnten, außer dass Sicherheit in ihrem Prozess keine Priorität hat. „Vor allem jetzt, im Zeitalter der agilen Entwicklung, in dem die Bereitstellung von Funktionen an erster Stelle steht und Sicherheit der Grinch ist, der den kreativen Prozess und den Triumph des Projektabschlusses stiehlt.

Dies ist keine negative Bewertung der beiden Teams. Entwickler und AppSec-Experten haben beide extrem wichtige Aufgaben zu erledigen, aber sie stehen sich weiterhin gegenseitig in die Quere. Diese Situation setzt nur einen fehlerhaften SDLC fort, bei dem Entwickler mit wenig Sicherheitsbewusstsein in einer negativen Sicherheitskultur agieren und unsicheren Code produzieren, der dann lange nach seiner ursprünglichen Erstellung gescannt, bewertet und repariert 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 immer noch eine Katastrophe bedeuten könnten, wenn sie nicht überprüft werden.

Wir verschwenden Zeit, Geld und Ressourcen, indem wir zulassen, dass Tests das Auffangen von Sicherheitslücken im Code sind. Und da jeden zweiten Tag massive Datenschutzverletzungen stattfinden, funktioniert diese Methode offensichtlich nicht optimal, wenn überhaupt. Diese neuen Standards bewerten immer noch den Zustand des Endprodukts (vielleicht unter der Annahme, dass alle Entwickler sicherheitsbewusst sind, was nicht der Fall ist): als ob es sich um einen Standard handelt, der bereits entwickelt wurde. Dies ist die teuerste und schwierigste Phase, um Fehler zu beheben. Es ist, als würde man ein schickes, neues Haus bauen, nur um am selben Tag, an dem Sie einziehen, ein Sicherheitsteam hinzuzuziehen, das nach Gefahren sucht. Wenn etwas mit dem Fundament nicht stimmt, stellen Sie sich vor, wie viel Zeit, Kosten und Kopfschmerzen es mit sich bringt, in diesen Bereich zu gelangen, um überhaupt mit der Behebung der Probleme zu beginnen. Oft ist es einfacher und billiger, einfach wieder von vorne zu beginnen (und was für ein völlig unbefriedigender Prozess ist das für alle, die die erste Version erstellt haben).

Wir müssen unbedingt von Grund auf arbeiten: indem wir das Entwicklungsteam mit den besten Sicherheitsmethoden vertraut machen, es mit dem Wissen ausstatten, effizient sicher zu programmieren, und zusätzlich eine positive Sicherheitskultur schaffen und aufrechterhalten jeden Arbeitsplatz.

Ist es eine Lernkurve? Verdammt, ja, das ist es. Ist es unmöglich? Definitiv nicht. Und es muss keine langweilige Plackerei sein. Trainingsmethoden, die direkt auf die kreativen, problemlösenden Eigenschaften der Entwickler eingehen, waren im Banken- und Finanzsektor bereits sehr erfolgreich, wenn Russ Wolfes Erfahrung bei Capital One ist irgendein Hinweis.

Wir sind immer noch auf der Suche nach dem perfekten „Endzustand“.

Wenn Sie die aktualisierten PCI-Sicherheitsstandards in dem Kontext betrachten, für den sie bestimmt sind, also wenn Ihr fertiges, benutzerfreundliches Finanzprodukt diesen Best Practices folgen muss, um optimale Sicherheit zu gewährleisten, dann sind sie absolut in Ordnung. Meiner Ansicht nach hätte jedoch jedes einzelne Unternehmen — ob finanziell oder anderweitig — die besten Chancen, einen Software-Endzustand zu erreichen, der sowohl für die Qualität der Funktionen als auch für einen hohen Sicherheitsstandard repräsentativ ist, 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 kennen den, der passiert, wenn ein Produkt gescannt, manuell überprüft wird und perfekt und fehlerfrei herauskommt? Wir suchen immer noch danach. Zu diesem Zeitpunkt ist es ein Einhorn.

Warum ist es so schwer fassbar? Es gibt eine Reihe von Faktoren:

• Man vertraut auf Scan-Tools, aber sie sind nicht immer effektiv. Falsch positive Ergebnisse sind ein frustrierendes, zeitraubendes Nebenprodukt ihrer Verwendung, ebenso wie die Tatsache, dass DAST/SAST/PCI-Scans selbst zusammen einfach nicht jede mögliche Sicherheitslücke in der Codebasis identifizieren und aufdecken können. Sicher, sie könnte Ich gebe dir Entwarnung, aber suchen sie wirklich nach allem? Ein Angreifer muss nur eine Sicherheitslücke ausnutzen, um auf etwas zuzugreifen, von dem Sie glauben, dass es geschützt ist.
• Entwickler machen weiterhin dieselben Fehler. Es gibt keine Wissensverteilung zwischen Entwicklern zum Thema Sicherheit und es gibt keine „sicheren Coderezepte“ (gute, sichere Codemuster), die bekannt und dokumentiert sind.
• Der Aufbau einer kollaborativen, positiven Sicherheitskultur wird nicht betont.
• Entwickler müssen mit den richtigen Tools ausgestattet werden, um Sicherheit in die von ihnen geschriebenen Produkte zu integrieren, ohne ihre kreativen Prozesse und agilen Entwicklungsmethoden zu stören.

Diese Richtlinien sind eine aussagekräftige Checkliste für die Überprüfung der Sicherheitsstandards, die Software einhalten sollte, aber das beste Verfahren, um Software in diesen Zustand zu bringen, steht zur Debatte.

Wir haben keine unsichere Software, weil es uns an Scannern mangelt, sondern wir haben unsichere Software, weil Entwicklern keine benutzerfreundlichen, leicht verständlichen Sicherheitstools zur Verfügung stehen, die sie leiten.

Wir befinden uns gerade in einer Zeit der Evolution. Softwaresicherheit war im Allgemeinen viele Jahre lang optional. Heute ist sie im Wesentlichen Pflicht — vor allem für diejenigen, die vertrauliche Informationen aufbewahren (Finanzen, Medizin, Sozialversicherung... Sie verstehen schon).

Der PCI Security Standards Council hilft dabei, Maßstäbe zu setzen, aber ich würde mich freuen, wenn er - mit all seiner Wertschätzung und seinem Einfluss in der Branche - darauf hinarbeitet, praktische Richtlinien für Entwickler einzuführen, wobei der Schwerpunkt auf angemessenen und positiven Schulungen und Tools liegt. Derzeit stehen Unternehmen nicht unter Druck, dafür zu sorgen, dass ihre Entwicklungsteams sicherheitsbewusst sind und die Vorschriften einhalten, und viele Entwickler verstehen auch nicht das Ausmaß dieser kleinen, leicht zu behebenden Fehler, wenn sie von denjenigen ausgenutzt werden, die Schaden anrichten wollen.

Wie bei allem, was sich im Leben lohnt, zu erwarten ist, braucht es wirklich ein Dorf, um wirklich Veränderungen herbeizuführen. Und die Veränderung, die in der Luft liegt, wird uns (hoffentlich) alle mitreißen weiter nach links.