Die neuen NIST-Richtlinien: Warum maßgeschneiderte Schulungen für die Entwicklung sicherer Software unerlässlich sind

Am 11. Juni 2019 hat das National Institute of Standards & Technology (NIST) veröffentlichte ein aktualisiertes Whitepaper mit Einzelheiten mehrere Aktionspläne zur Reduzierung Software-Sicherheitslücken und Cyberrisiko. Betitelt Minderung des Risikos von Softwareschwachstellen durch die Einführung eines Secure Software Development Framework (SSDF), NIST bietet Unternehmen solide Richtlinien, um die schlimmen — ganz zu schweigen von den teuren — Folgen einer Datenschutzverletzung zu vermeiden.

Es ist wichtig zu beachten, dass die SSDF bewusst generisch ist. Sie geht nicht davon aus, dass jedes Unternehmen genau die gleichen Softwaresicherheitsziele hat, und schreibt auch keinen genauen Mechanismus vor, um diese zu erreichen. Das Hauptziel ist die Umsetzung bewährter Sicherheitsmethoden. Die Autorin Donna Dodson erklärt dazu: „Es ist zwar wünschenswert, dass jeder Sicherheitshersteller alle geltenden Praktiken befolgt, aber es wird erwartet, dass der Grad, in dem jede Praxis umgesetzt wird, je nach den Sicherheitsannahmen des Herstellers variiert. Die Praktiken bieten den Implementierern Flexibilität, sind aber auch klar formuliert, um zu vermeiden, dass zu viel Spielraum für Interpretationen bleibt.“

Von besonderem Interesse für mich waren natürlich die spezifischen Einschlüsse rund um das Thema Softwaresicherheitstraining für Entwickler. Nun wissen wir seit langem, dass Entwickler eine angemessene Schulung benötigen, wenn sie ein Unternehmen von Beginn des Softwareentwicklungsprozesses an schützen wollen... aber was angemessene, genau? Es gibt viele unterschiedliche Meinungen da draußen. Ich denke jedoch, dass die Grenzen endlich in eine Richtung verschoben werden, die zu erheblichen positiven Ergebnissen führen wird.

Es gibt Sicherheitsschulungen... und es gibt effektive Sicherheitsschulungen.

Ich habe ausführlich über die Notwendigkeit gesprochen, Softwaresicherheitstrainings effektiver umzusetzen, einzubeziehen und auf die Bedürfnisse der Entwickler zuzuschneiden. Selbst heute noch ist es in vielen Organisationen bestenfalls ein „Häkchen“. Vielleicht gibt es ein paar Stunden Videotraining oder sogar wertvolle Zeit, die für das Lernen im Klassenzimmer außerhalb der Tools aufgewendet wird. Die Tatsache, dass es jeden zweiten Tag zu groß angelegten Datenschutzverletzungen kommt, die von Angreifern begangen werden, die bekannte (und in der Regel leicht zu behebende) Sicherheitslücken ausnutzen, ist ein Beweis dafür, dass Softwaresicherheitstrainings bei weitem nicht so effektiv sind, wie sie sein müssten. Und, was vielleicht am wichtigsten ist, es gibt kaum Hinweise darauf, ob die Schulung überhaupt wirksam war: Werden Sicherheitslücken schneller behoben? Werden Sicherheitslücken im Code reduziert? Haben die Teilnehmer die Schulung tatsächlich abgeschlossen oder haben sie einfach auf „Weiter“ geklickt, um sie abzuschließen?

Entwickler sind vielbeschäftigte Menschen, die hart daran arbeiten, strenge Termine einzuhalten. Sicherheit ist oft eine Unannehmlichkeit, und selten werden sie während ihrer Ausbildung mit dem Wissen ausgestattet, um Cyberrisiken erfolgreich zu mindern. Das Wort „Sicherheit“ fällt normalerweise, wenn ein Mitglied des AppSec-Teams auf Fehler in seiner Arbeit hinweist, was zu einer eher kalten und dysfunktionalen Beziehung führt. Ein „Ihr Baby ist hässlich; repariere es“ -Szenario.

Was sagt uns das? Es ist ein jahrzehntelanges Warnsignal, dass wir nicht genug tun, um Entwickler für Sicherheit zu gewinnen. Sie sind nicht motiviert, Verantwortung zu übernehmen, und suchen auch nicht nach den Tools, die sie benötigen, um Software zu entwickeln, die funktionsfähig ist und dennoch unter Berücksichtigung bewährter Sicherheitsverfahren entwickelt wurde.

Entwickler sind clever, kreativ und lieben es, Probleme zu lösen. Es ist ziemlich unwahrscheinlich, dass das Anschauen endloser Videos über Sicherheitslücken sie begeistert oder ihnen hilft, sich zu engagieren. In meiner Zeit als SANS-Dozent habe ich sehr schnell gelernt, dass die beste Schulung praktisch ist. Sie zwingt sie, zu analysieren und intellektuell herausgefordert zu werden. Dabei wurden Beispiele aus der Praxis verwendet, die ihr Gehirn auf die Probe stellen und auf früheren Erkenntnissen aufbauen. Gamification und freundschaftlicher Wettbewerb sind ebenfalls leistungsstarke Tools, um alle an neue Konzepte heranzuführen und gleichzeitig nützlich und praktisch in der Anwendung zu bleiben.

In den Richtlinien von NIST heißt es: „Bieten Sie rollenspezifische Schulungen für alle Mitarbeiter an, deren Aufgaben zu einer sicheren Entwicklung beitragen. Überprüfen Sie regelmäßig die rollenspezifischen Schulungen und aktualisieren Sie sie bei Bedarf.“ Und später: „Definieren Sie Rollen und Verantwortlichkeiten für Cybersicherheitspersonal, Sicherheitsexperten, Führungskräfte, Softwareentwickler, Produkteigentümer und andere am SDLC beteiligte Personen.“

Diese Aussage ist zwar nicht spezifisch für die Art der Schulung, trägt aber dennoch dazu bei, Unternehmen nach links zu verlagern und bewährte Sicherheitsverfahren im Blick zu behalten. Dadurch wird das Unternehmen wieder in die Pflicht genommen, effektive, spezifischere Schulungslösungen zu finden, und das wird hoffentlich dazu führen, dass 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 Sicherheitsrisiken und der Reduzierung von Sicherheitsrisiken betont, kann dieser Aufwand oft umsonst sein, wenn die Sicherheitskultur eines Unternehmens weiterhin grundlegend kaputt ist.

Wenn Mitarbeiter effektiv geschult werden, Ziele gesetzt und Erwartungen klar definiert sind, wird es für sie viel einfacher, ihren Platz in der Sicherheitslandschaft zu verstehen und gegebenenfalls Verantwortung zu übernehmen. Insbesondere Entwicklern werden von Anfang an die Tools 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 Doppelhandhabungen, Schuldzuweisungen und isolierte Projektarbeit gibt.

Sicherheit muss für das gesamte Unternehmen an erster Stelle stehen, und es muss ein unterstützendes und kooperatives Engagement für die Bereitstellung großartiger, sicherer Software gewährleistet sein. Das bedeutet, dass die Budgets ausreichen, um unterhaltsame, ansprechende Schulungen anzubieten, die reale Code-Schwachstellen ausnutzen, und die Unterstützung im gesamten Unternehmen, um die Dynamik aufrechtzuerhalten. In dieser sich ständig weiterentwickelnden digitalen Landschaft müssen Schulungen so kontinuierlich sein wie die Durchführung. Wenn Ihnen in der Vergangenheit gesagt wurde, dass ein „einmaliges“ oder „Einstellen und Vergessen“ von Compliance-Schulungen ausreichend oder effektiv ist, ist dies ein Trugschluss.

Dieses neue NIST-Framework formuliert zwar nicht ausdrücklich die Notwendigkeit, eine positive Sicherheitskultur zu fördern, aber die erfolgreiche Einhaltung ihrer Richtlinien erfordert mit Sicherheit eine solche. Sie weisen jedoch darauf hin, dass Unternehmen „Richtlinien definieren sollten, die die Sicherheitsanforderungen spezifizieren, die die Software des Unternehmens erfüllen muss, einschließlich sicherer Codierungsmethoden, die Entwickler befolgen müssen“.

Das oben Genannte ist wichtig, um die Sicherheitskompetenzen innerhalb von Teams auszubauen und zu verbessern. Es kann hilfreich sein, bei der Bewertung Ihrer eigenen Richtlinien und des aktuellen AppSec-Klimas Folgendes zu berücksichtigen:

• Sind die Richtlinien und Erwartungen an die Softwaresicherheit klar definiert?
• Ist allen klar, welche Rolle sie bei der Erreichung dieser Ziele spielen?
• Wird das Training häufig durchgeführt und bewertet?
• Sind sich Ihre Entwickler der großen Rolle bewusst, die sie bei der Beseitigung häufiger Sicherheitslücken spielen können, bevor sie auftreten?

Nun, dieser letzte Teil hängt, wie gesagt, weitgehend von der Organisation und der Ausbildung ab, für die sie sich entscheiden. Es muss relevant sein, es muss häufig sein, es muss ansprechend sein. Finden Sie eine Lösung, die auf ihre tägliche Arbeit angewendet werden kann, und erweitern Sie ihr Wissen kontextuell.

Was jetzt?

Ein tiefer Einblick in diese neuen Richtlinien dürfte ziemlich überwältigend sein. Es erfordert wirklich ein ganzes Dorf, um die eiserne sichere Software, die die meisten Unternehmen benötigen, auf die sicherste Art und Weise zu entwickeln, zu verifizieren und bereitzustellen. Es geht auch nicht nur um Schulungen. Bei der Verwendung von Software von Drittanbietern sind Richtlinien zu beachten (Verwenden von Komponenten mit bekannten Sicherheitslücken sitzt immer noch in der OWASP Top 10, immerhin), Vorschläge rund um Verifizierung, Penetrationstests und Codeüberprüfung sowie Richtlinien für die Führung von Sicherheitsaufzeichnungen, geeignete Toolchains und alles andere. Umsetzbare Erkenntnisse für das Gesamtbild finden Sie in Dr. Gary McGraws BSIMM-Modell, auf das im gesamten Dokument von NIST verwiesen wird.

Der schnellste Gewinn kann jedoch erzielt werden, wenn Ihre Entwickler mit den richtigen Tools und dem richtigen Wissen ausgestattet sind, um von Anfang an wirklich erfolgreich sichere Software zu entwickeln. Für das Unternehmen ist es günstiger (und insgesamt schneller), zu verhindern, dass häufig auftretende Sicherheitslücken in späteren Phasen des SDLC immer wieder auftauchen. Nutzen Sie ihre Stärken und bieten Sie einen Anreiz, sich mit der Sicherheitsseite des Unternehmens zu befassen. Es kann wirklich Spaß machen, und sie können die Just-in-Time-Helden sein, die Sie brauchen, um die Bösewichte draußen zu halten und unsere Daten zu schützen.

Referenzen:

1. MINDERUNG DES RISIKOS VON SOFTWARESCHWACHSTELLEN DURCH DIE EINFÜHRUNG EINER SSDF (11. JUNI 2019), Seite 2.
2. MINDERUNG DES RISIKOS VON SOFTWARESCHWACHSTELLEN DURCH DIE EINFÜHRUNG EINER SSDF (11. JUNI 2019), Seite 5.
3. MINDERUNG DES RISIKOS VON SOFTWARESCHWACHSTELLEN DURCH DIE EINFÜHRUNG EINER SSDF (11. JUNI 2019), Seite 4.