Am 11. Juni 2019 veröffentlichte das National Institute of Standards & Technology(NIST) ein aktualisiertes Whitepaper, in dem mehrere Aktionspläne zur Verringerung von Software-Schwachstellen und Cyber-Risiken beschrieben werden. Unter dem Titel Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF) (Minderung des Risikos von Software-Schwachstellen durch Einführung eines sicheren Software-Entwicklungsrahmens) gibt das NIST Unternehmen solide Richtlinien an die Hand, um die unangenehmen - und nicht zuletzt teuren - Folgen einer Datenpanne zu vermeiden.

Es ist wichtig anzumerken, dass das SSDF absichtlich generisch ist, es geht nicht davon aus, dass jede Organisation genau die gleichen Software-Sicherheitsziele hat, noch schreibt es einen genauen Mechanismus vor, um diese zu erreichen. Das Hauptziel ist die Implementierung von Best Practices für die Sicherheit. Die Autorin, Donna Dodson, erklärt: "Während es der Wunsch ist, dass jeder Sicherheitsproduzent alle anwendbaren Praktiken befolgt, wird erwartet, dass der Grad der Implementierung jeder Praxis auf der Grundlage der Sicherheitsannahmen des Herstellers variiert. Die Praktiken bieten den Implementierern Flexibilität, aber sie sind auch klar, um nicht zu viel Interpretationsspielraum zu lassen".

Von besonderem Interesse für mich waren natürlich die spezifischen Einschlüsse rund um Software-Sicherheitstraining für Entwickler. Nun, wir wissen schon lange, dass Entwickler angemessen geschult werden müssen, wenn sie eine Organisation von Beginn des Softwareentwicklungsprozesses an schützen sollen... aber was genau ist angemessen? Es gibt eine Menge unterschiedlicher Meinungen da draußen. Ich denke jedoch, dass der Umschlag endlich in eine Richtung geschoben wird, die signifikante positive Ergebnisse auslösen wird.

Es gibt Sicherheitstraining... und es gibt effektives Sicherheitstraining.

Ich habe ausführlich über die Notwendigkeit gesprochen, Software-Sicherheitsschulungen effektiver zu implementieren, sich damit zu beschäftigen und sie auf die Bedürfnisse der Entwickler zuzuschneiden. Selbst jetzt ist es in vielen Organisationen bestenfalls eine "Tick-the-Box"-Übung. Vielleicht gibt es ein paar Stunden Videotraining oder sogar kostbare Zeit, die abseits der Tools für ein paar Präsenzschulungen verwendet wird. Die Tatsache, dass es jeden zweiten Tag groß angelegte Datenschutzverletzungen gibt, die von Angreifern begangen werden, die bekannte (und in der Regel leicht zu behebende) Sicherheitslücken ausnutzen, ist ein Beweis dafür, dass Software-Sicherheitsschulungen nicht annähernd so effektiv sind, wie sie sein müssten. Und, was vielleicht am wichtigsten ist, es gibt nur sehr wenig, um zu überprüfen, ob das Training überhaupt effektiv war: Werden Schwachstellen schneller behoben? werden Schwachstellen im Code reduziert? Haben die Mitarbeiter die Schulung tatsächlich abgeschlossen oder haben sie nur auf "weiter" geklickt?

Entwickler sind vielbeschäftigte Menschen, die hart arbeiten, um strenge Fristen einzuhalten. Sicherheit ist die meiste Zeit eine Unannehmlichkeit, und nur selten werden sie während ihrer Ausbildung mit dem Wissen ausgestattet, um Cyber-Risiken erfolgreich zu mindern. Das Wort "Sicherheit" fällt in der Regel, wenn ein Mitglied des AppSec-Teams auf Fehler in ihrer Arbeit hinweist, was zu einer eher kalten und dysfunktionalen Beziehung führt. Ein "Dein Baby ist hässlich; geh es reparieren"-Szenario.

Was sagt uns das? Es ist ein jahrzehntealtes Warnsignal, dass wir nicht genug tun, um Entwickler für das Thema Sicherheit zu gewinnen. Sie sind weder motiviert, Verantwortung zu übernehmen, noch suchen sie nach den Werkzeugen, die sie benötigen, um Software zu erstellen, die funktional ist und dennoch unter Berücksichtigung der besten Sicherheitspraktiken entwickelt wurde.

Entwickler sind clever, kreativ und lieben es, Probleme zu lösen. Es ist ziemlich unwahrscheinlich, dass das Anschauen von endlosen Videos über Sicherheitslücken sie begeistern oder ihnen helfen wird, engagiert zu bleiben. In meiner Zeit als SANS-Trainer habe ich sehr schnell gelernt, dass das beste Training praxisorientiert ist und sie dazu zwingt, zu analysieren und intellektuell herausgefordert zu werden, indem sie reale Beispiele verwenden, die ihr Gehirn testen und auf vorheriges Lernen aufbauen. Gamification und freundschaftlicher Wettbewerb sind ebenfalls mächtige Werkzeuge, um alle mit neuen Konzepten vertraut zu machen, während sie gleichzeitig nützlich und praktisch in der Anwendung bleiben.

Die Richtlinien des NIST legen fest: "Stellen Sie rollenspezifische Schulungen für alle Mitarbeiter in Rollen mit Verantwortlichkeiten bereit, die zur sicheren Entwicklung beitragen. Überprüfen Sie das rollenspezifische Training regelmäßig und aktualisieren Sie es bei Bedarf." Und weiter: "Definieren Sie Rollen und Verantwortlichkeiten für Cybersecurity-Mitarbeiter, Security Champions, Senior Management, Softwareentwickler, Product Owner und andere am SDLC Beteiligte."

Diese Aussage ist zwar nicht spezifisch in Bezug auf die Art der Schulung, trägt aber dennoch dazu bei, die Organisationen nach links zu verlagern und dazu beizutragen, dass Best Practices im Bereich Sicherheit im Vordergrund stehen. Sie überträgt die Verantwortung für die Suche nach effektiven, spezifischeren Schulungslösungen wieder auf das Unternehmen, was hoffentlich dazu führt, dass die Entwickler mit den richtigen Tools und Kenntnissen ausgestattet werden, um erfolgreich zu sein.

Kultur: das fehlende Glied.

Selbst wenn ein Unternehmen Zeit und Ressourcen in die Schulung von Entwicklern und anderen wichtigen Mitarbeitern investiert und deren Rolle bei der Vermeidung von Schwachstellen und der Reduzierung des Sicherheitsrisikos betont, können die Bemühungen oft umsonst sein, wenn die Sicherheitskultur eines Unternehmens grundlegend gestört bleibt.

Wenn Einzelpersonen effektiv geschult werden, mit festgelegten Zielen und klaren Erwartungen, wird es für sie viel einfacher, ihren Platz in der Sicherheitslandschaft zu verstehen und gegebenenfalls Verantwortung zu übernehmen. Besonders im Fall von Entwicklern werden ihnen von Anfang an die Werkzeuge und das Wissen an die Hand gegeben, um sicheren Code zu schreiben. Dies lässt sich jedoch am besten in einer positiven Sicherheitsumgebung orchestrieren, in der es weniger Doppelarbeit, Schuldzuweisungen und isolierte Projektarbeit gibt.

Sicherheit muss für die gesamte Organisation im Vordergrund stehen, mit einem unterstützenden und gemeinschaftlichen Engagement für die Bereitstellung großartiger, sicherer Software. Das bedeutet, dass die Budgets ausreichen, um unterhaltsame, ansprechende Schulungen durchzuführen, die reale Code-Schwachstellen nutzen, und dass die gesamte Organisation mitmacht, um die Dynamik aufrechtzuerhalten. In dieser sich ständig weiterentwickelnden digitalen Landschaft muss das Training genauso kontinuierlich sein wie die Bereitstellung. Wenn Ihnen in der Vergangenheit gesagt wurde, dass "einmalige" oder "einmalige" Compliance-Schulungen ausreichend oder effektiv sind, ist dies ein Trugschluss.

Das neue NIST-Framework formuliert zwar nicht explizit die Anforderung, eine positive Sicherheitskultur zu pflegen, aber die erfolgreiche Einhaltung der Richtlinien erfordert mit Sicherheit eine solche. Es wird jedoch darauf hingewiesen, dass Organisationen "Richtlinien definieren sollten, die die Sicherheitsanforderungen an die Software der Organisation spezifizieren, einschließlich sicherer Codierungspraktiken, die die Entwickler befolgen müssen".

Die oben genannten Punkte sind für die Skalierung und den Ausbau der Sicherheitskompetenzen innerhalb der Teams von entscheidender Bedeutung. Es kann hilfreich sein, die folgenden Punkte zu berücksichtigen, wenn Sie Ihre eigenen Richtlinien und das aktuelle AppSec-Klima bewerten:

• Sind die Richtlinien und Erwartungen an die Software-Sicherheit klar definiert?
• Ist jedem klar, welche Rolle er beim Erreichen dieser Ziele spielt?
• Wird das Training häufig durchgeführt und bewertet?
• Sind sich Ihre Entwickler der großen Rolle bewusst, die sie bei der Beseitigung von häufigen Sicherheitsfehlern spielen können, bevor sie auftreten?

Nun, der letzte Teil ist, wie ich schon sagte, größtenteils Sache der Organisation und der von ihr gewählten Schulung. Sie muss relevant sein, sie muss häufig stattfinden, sie muss fesselnd sein. Finden Sie eine Lösung, die sie bei ihrer täglichen Arbeit anwenden können, und bauen Sie ihr Wissen kontextbezogen auf.

Was nun?

Ein tiefes Eintauchen in diese neuen Richtlinien ist wahrscheinlich ziemlich überwältigend; es braucht wirklich ein ganzes Dorf, um die sichere Software, die die meisten Unternehmen benötigen, auf die sicherste Art und Weise zu erstellen, zu überprüfen und einzusetzen. Es geht auch nicht nur um die Ausbildung. Es gibt Richtlinien, die bei der Verwendung von Software von Drittanbietern zu beachten sind(die Verwendung von Komponenten mit bekannten Schwachstellen steht immer noch in den OWASP Top 10), Vorschläge zur Verifizierung, zu Penetrationstests und zur Codeüberprüfung sowie Richtlinien für die Aufzeichnung von Sicherheitsdaten, geeignete Toolchains und alles andere. Verwertbare Erkenntnisse für das Gesamtbild finden sich im BSIMM-Modell von Dr. Gary McGraw, auf das im NIST-Dokument verwiesen wird.

Der schnellste Gewinn kann jedoch erzielt werden, wenn Ihre Entwickler mit den richtigen Werkzeugen und Kenntnissen ausgestattet sind, um wirklich von Anfang an sichere Software zu entwickeln. Es ist billiger für das Unternehmen (und insgesamt schneller), häufige Schwachstellen zu verhindern, die in späteren Phasen des SDLC immer wieder auftauchen. Nutzen Sie die Stärken der Mitarbeiter und bieten Sie ihnen einen Anreiz, sich mit der Sicherheitsseite des Unternehmens zu beschäftigen. Es kann wirklich Spaß machen, und sie können die "Just-in-time"-Helden sein, die Sie brauchen, um die Bösewichte fernzuhalten und unsere Daten zu schützen.

Referenzen:

1. MITIGIEREN DES RISIKOS VON SOFTWARE-VULNERABILITÄTEN DURCH ANNAHME EINES SSDF (JUNI 11, 2019), Seite 2.
2. MITIGIEREN DES RISIKOS VON SOFTWARE-VULNERABILITÄTEN DURCH ANNAHME EINES SSDF (JUNI 11, 2019), Seite 5.
3. MITIGIEREN DES RISIKOS VON SOFTWARE-VULNERABILITÄTEN DURCH ANNAHME EINES SSDF (JUNI 11, 2019), Seite 4.