Die überarbeiteten Richtlinien des PCI Security Standards Council: Sind sie weit genug nach links gerückt?

Eine Version dieses Artikels wurde ursprünglich veröffentlicht in Digital Transactions Magazin.

In diesem Jahr hat das PCI Security Standards Council eine komplett neue Reihe von Software-Sicherheitsrichtlinien als Teil des PCI Software Security Framework veröffentlicht. Dieses Update zielt darauf ab, die Best Practices für Software-Sicherheit mit der modernen Software-Entwicklung in Einklang zu bringen. Es ist eine fantastische Initiative, die anerkennt, wie sich dieser Prozess im Laufe der Zeit verändert hat und ein Überdenken der Sicherheitsstandards erfordert, die lange vor der rasanten 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 auseinandersetzt - Richtlinien, die sich mit unseren sich ändernden Bedürfnissen weiterentwickeln - sowie mit den Anforderungen einer Cybersicherheitslandschaft, die sehr schnell außer Kontrolle geraten könnte, wenn wir in unseren sicheren Entwicklungsprozessen weiterhin nachlässig sind. Da das PCI Security Standards Council als Dachverband der Banken- und Finanzbranche fungiert (d. h. die Sicherheitsstandards für die Software festlegt, der wir vertrauen, um unser Geld, unsere Kreditkarten, unsere Online-Transaktionen und unsere Kassengeschäfte zu schützen), trägt es natürlich ein großes Risiko und hat eine große Motivation, dieses zu verringern.

Während diese Standards sicherlich eine Verbesserung gegenüber der Vorgängerversion darstellen und ein Stück weit dazu beitragen, die Lücke zu schließen, die wir in der schnellen, innovativen Funktionsentwicklung haben, die auch die Sicherheit als Teil ihrer Gesamtqualität priorisiert assessment, ist es eine etwas enttäuschende Realität, festzustellen, dass wir noch einen langen Weg vor uns haben.

Nein, das ist kein "bah, humbug!", das ich dieser Initiative entgegenbringe. Tatsache ist, dass diese neuen Sicherheitsrichtlinien uns einfach nicht weit genug nach links rücken.

Wir waren immer noch auf das Testen fixiert (und haben zu spät getestet).

Ein eklatantes Problem, das ich beim PCI Security Standards Framework gefunden habe, ist die offensichtliche Abhängigkeit vom Testen. 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 Code, um die Software zu erstellen, die wir kennen, lieben und der wir vertrauen? Software-Entwickler.

Wer hat die wenig beneidenswerte Position, diesen Code zu testen, entweder mit Scanning-Tools oder manuellem Code-Review? AppSec-Spezialisten.

Was entdecken diese Spezialisten immer wieder? Die gleichen Fehler, die uns schon seit Jahrzehnten plagen. Einfache Dinge, von denen wir schon seit Jahren wissen, wie sie zu beheben sind: SQL-Injection, Cross-Site-Scripting, Schwachstellen in der Sitzungsverwaltung... für diese Leute ist es wie der Murmeltiertag. Sie haben ihre Zeit damit verbracht, Code-Verletzungen zu finden und zu beheben, die die Entwickler selbst schon seit Jahren beheben können, nur dass die Sicherheit in ihrem Prozess keine Priorität hat ", vor allem jetzt, im Zeitalter der agilen Entwicklung, wo die Bereitstellung von Funktionen im Vordergrund steht und die Sicherheit der Grinch ist, der den kreativen Prozess und den Triumph der Projektfertigstellung stiehlt.

Dies ist keine negative assessment eines der beiden Teams; Entwickler und AppSec-Experten haben beide extrem wichtige Aufgaben zu erledigen, aber sie kommen sich weiterhin gegenseitig in die Quere. Diese Situation verewigt nur einen fehlerhaften SDLC, in dem Entwickler mit wenig Sicherheitsbewusstsein in einer negativen Sicherheitskultur arbeiten und unsicheren Code produzieren, der dann lange nach seiner Entstehung gescannt, bewertet und behoben werden muss. AppSec hat kaum Zeit, die wirklich komplexen Probleme zu beheben, weil sie so sehr mit den kleinen wiederkehrenden Problemen beschäftigt sind, die für ein Unternehmen immer noch eine Katastrophe bedeuten können, wenn sie nicht behoben werden.

Wir verschwenden Zeit, Geld und Ressourcen, wenn wir zulassen, dass Testen das Allheilmittel für Sicherheitsschwächen im Code ist. Und mit massiven Datenschutzverletzungen jeden zweiten Tag, funktioniert diese Methode offensichtlich nicht optimal, wenn überhaupt. Diese neuen Standards bewerten immer noch einen Endproduktzustand (vielleicht unter der Annahme, dass alle Entwickler sicherheitsbewusst sind, was nicht der Fall ist): nämlich einen, der bereits gebaut ist. Dies ist die teuerste und schwierigste Phase, um Fehler zu beheben; es ist so, als würde man ein schickes, neues Haus bauen, nur um am selben Tag, an dem man einzieht, ein Sicherheitsteam hinzuzuziehen, um es auf mögliche Gefahren zu überprüfen. Wenn etwas mit dem Fundament nicht in Ordnung ist, stellen Sie sich den Zeitaufwand, die Kosten und das Kopfzerbrechen vor, die nötig sind, um diesen Bereich zu erreichen und die Probleme überhaupt anzugehen. Oft ist es einfacher und billiger, einfach noch einmal von vorne anzufangen (und was für ein völlig unbefriedigender Prozess das für jeden ist, der die erste Version gebaut hat).

Wir müssen unbedingt von Grund auf arbeiten: indem wir das Entwicklungsteam mit Best Practices für die Sicherheit vertraut machen, sie mit dem Wissen ausstatten, um effizient sicher zu programmieren, und zusätzlich eine positive Sicherheitskultur an jedem Arbeitsplatz schaffen und pflegen.

Ist es eine Lernkurve? Ja, das ist es. Ist es unmöglich? Definitiv nicht. Und es muss keine langweilige Plackerei sein. Trainingsmethoden, die direkt an die kreativen, problemlösenden Eigenschaften der Entwickler appellieren, haben im Banken- und Finanzsektor bereits immensen Erfolg gehabt, wenn man Russ Wolfes Erfahrung bei Capital One glauben darf.

Wir sind immer noch auf der Suche nach dem perfekten "End-Zustand".

Wenn Sie die aktualisierten PCI-Sicherheitsstandards in dem Kontext betrachten, für den sie gedacht sind, also - Ihr fertiges, benutzerfertiges Finanzprodukt muss diesen Best Practices für optimale Sicherheit und Schutz folgen, dann sind sie absolut in Ordnung. Meiner Meinung nach hätte jedoch jedes einzelne Unternehmen - ob im Finanzbereich oder anderswo - 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 sie nur einen Schritt zurücktreten und erkennen würden, dass es viel effizienter ist, dies von Beginn des Zyklus an zu tun.

Der perfekte Endzustand? Sie wissen schon, der, der eintritt, wenn ein Produkt gescannt und manuell überprüft wird und perfekt und fehlerfrei herauskommt? Wir sind immer noch auf der Suche danach. Zum jetzigen Zeitpunkt ist es ein Einhorn.

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

• Man verlässt sich auf Scanning-Tools, doch sie sind nicht immer effektiv. Falschmeldungen sind ein frustrierendes, zeitraubendes Nebenprodukt ihrer Verwendung, ebenso wie die Tatsache, dass DAST/SAST/PCI-Scans selbst zusammen einfach nicht jede mögliche Schwachstelle in der Code-Basis identifizieren und aufdecken können. Sicher, sie geben Ihnen vielleicht Entwarnung, aber suchen sie wirklich nach allem? Ein Angreifer braucht nur eine Schwachstelle auszunutzen, um auf etwas zuzugreifen, von dem Sie glauben, dass es geschützt ist.
• Die Entwickler machen immer wieder die gleichen Fehler. Es gibt keine Wissensverteilung zwischen Entwicklern rund um das Thema Sicherheit und keine "sicheren Code-Rezepte" (gute, sichere Codemuster), die bekannt und dokumentiert sind.
• Es wird kein Wert auf den Aufbau einer kollaborativen, positiven Sicherheitskultur gelegt.
• Entwickler müssen mit den richtigen Werkzeugen ausgestattet werden, um Sicherheit in die Produkte einzubauen, die sie schreiben, ohne ihre kreativen Prozesse und agilen Entwicklungsmethoden zu stören.

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

Wir haben keine unsichere Software, weil es an Scannern fehlt, wir haben unsichere Software, weil den Entwicklern keine einfach zu bedienenden, leicht verständlichen Sicherheitstools zur Verfügung gestellt werden, die sie anleiten.

Wir befinden uns gerade in einer Zeit der Evolution. Software-Sicherheit im Allgemeinen war viele Jahre lang optional. Heute ist sie im Grunde obligatorisch - vor allem für die Hüter sensibler Informationen (Finanzen, Medizin, Sozialversicherung... Sie verstehen schon).

Das PCI Security Standards Council hilft dabei, den Maßstab zu setzen, aber ich würde es gerne sehen, wenn sie - bei all ihrem Ansehen und Einfluss in der Branche - darauf hinarbeiten würden, praktische Richtlinien für Entwickler einzubauen, mit einem Schwerpunkt auf angemessenen und positiven Schulungen und Tools. Im Moment gibt es keinen Druck für Unternehmen, dafür zu sorgen, dass ihre Entwicklungsteams sicherheitsbewusst und konform sind, noch verstehen viele Entwickler das Ausmaß dieser kleinen, leicht zu behebenden Fehler, wenn sie von denen ausgenutzt werden, die Schaden anrichten wollen.

Wie bei allem, was im Leben von Wert ist, braucht es wirklich ein Dorf, um eine Veränderung herbeizuführen. Und die Veränderung, die in der Luft liegt, wird uns (hoffentlich) alle weiter nach links fegen.