In einer digital gesteuerten Welt sind wir einem immer größer werdenden Risiko des Datendiebstahls ausgesetzt. Da große Organisationen als Hüter unserer wertvollen Informationen fungieren, erkennen viele die Notwendigkeit, strenge Sicherheitsstandards zu implementieren.

Ein großer Teil der Initiative zum "Shifting Left", also der Einführung von Sicherheit viel früher im Entwicklungsprozess, bewegt die Nadel einfach nicht weit genug. Das impliziert, dass wir den Prozess immer noch auf die falsche Art und Weise beginnen und letztlich einen Rückzieher machen, um das Ziel einer sichereren Software zu erreichen. Wir müssen auf der linken Seite beginnen und einen Kulturwandel herbeiführen, der die Entwicklungsteams positiv beeinflusst und sie mit dem Wissen ausstattet, das ihnen derzeit fehlt. Allerdings sind nicht alle Schulungen und Tools gleich.

In diesem Artikel gehen wir der Frage nach, wie Führungskräfte wie Security Awareness- und Entwicklungsmanager ihre Entwickler wirklich befähigen können, um sie in die defensive Frontlinie gegen kostspielige Cyberangriffe zu verwandeln.

Links verschieben vs. links starten: Eine wichtige Unterscheidung.

Im Zeitalter der häufigen Datenschutzverletzungen, die einige der vertrauenswürdigsten Organisationen der Welt betreffen, haben sich Unternehmensleiter an die Sicherheitsbranche gewandt, um Ratschläge zu erhalten, wie man das finanzielle, rufschädigende und aufsehenerregende Desaster eines erfolgreichen Angriffs vermeiden kann.

Seit geraumer Zeit raten AppSec-Spezialisten (mich eingeschlossen), dass wir in der Tat "nach links gehen" müssen. Im Einklang mit der DevOps-Best-Practice sowie besseren Software-Sicherheitsergebnissen rieten viele von uns, dass der Sicherheitsteil eines Software-Builds früher im Software-Entwicklungslebenszyklus (SDLC) kommen muss. Er sollte nicht der letzte, kostspielige Schritt sein - vielmehr sollte er näher an den Beginn des Prozesses verlagert werden, wobei AppSec-Teams frühzeitig eingebunden werden, wenn Softwareprojekte ins Leben gerufen werden.

Das ist kein schlechter Rat, und es ist sicherlich besser als die alte Vorgehensweise (die, wenn die Menge der gestohlenen Daten da draußen und das Alter der Schwachstellen, die für den Diebstahl genutzt wurden, irgendein Anzeichen ist, sowieso nicht funktioniert). Wenn wir jedoch tatsächlich damit anfangen würden, wären die Sicherheitsergebnisse weitaus positiver.

Nach links schieben, nach links starten... wo liegt der Unterschied? Der Unterschied liegt darin, wie Sie Ihr Entwicklungsteam einbinden. In der Tat sind sie der Schlüssel, um sicherere Software zu liefern, und zwar viel kostengünstiger, als es mit nachträglichen Toolchains und manueller Codeüberprüfung möglich ist. In einer idealen Welt würde jeder einzelne Entwickler, der Software schreibt, das Wissen und die Werkzeuge haben, um von Anfang an sicher zu programmieren. Sie würden potenzielle Fehler erkennen und diese abmildern, bevor sie festgeschrieben werden (und somit viel teurer zu beseitigen sind). Es gäbe eine dramatische Reduzierung der Sicherheitslücken, die wir seit Jahrzehnten sehen - solche, die immer noch dafür verantwortlich sind, dass Angreifer durch die Hintertür eindringen können. Diese "windows of opportunity" in Form von SQL-Injection, Cross-Site-Scripting und fehlerhafter Authentifizierung würden sich schließen.

Im Moment wird jedoch einfach nicht genug Wert auf Sicherheit auf beruflicher Ebene gelegt, und die Ausbildung für sichere Kodierung am Arbeitsplatz variiert stark. Infolgedessen haben Entwickler selten das, was sie brauchen, um eine Organisation in die Lage zu versetzen, links zu starten. Es ist an der Zeit, dass die Führungskräfte zusammenarbeiten und sich für ein breiteres Sicherheitsbewusstsein einsetzen. Ihr direktes Wissen und ihr Kontakt zu den Entwicklern sind entscheidend, um Programme voranzutreiben, die funktionieren. Schließlich saßen die Entwicklungsleiter einst in ihrer Position, an den Werkzeugen und mit dem Sicherheitsbereich, der im besten Fall schwer zu navigieren ist.

Entwickler lieben die Sicherheit (noch) nicht... aber Sie können die Konversation ändern.

Sie wissen, wie es läuft: Erwähnen Sie "Sicherheit" gegenüber einem typischen Entwickler, und Sie werden wahrscheinlich bestenfalls mit den Augen rollen, schlimmstenfalls mit Verwunderung reagieren. Im Allgemeinen wird die ganze Sicherheitssache als das Problem von jemand anderem angesehen.

Ein Entwickler ist in erster Linie dafür verantwortlich, Software zu erstellen, die funktional ist, vor innovativen Funktionen strotzt und innerhalb eines engen Projektzeitplans geliefert wird. Sicherheit ist selten eine Priorität auf der Kodierungsebene und kann sogar als lästiger Blocker für eine schnelle Lieferung und kreatives Arbeiten gesehen werden. AppSec hat die Aufgabe, den Code akribisch zu überprüfen, Pen-Tests durchzuführen und dann die schlechte Nachricht zu überbringen: das Vorhandensein von Sicherheitslücken in Code, der oft schon feststeht und ansonsten ganz gut funktioniert. Das ist ein teurer Prozess in einer Umgebung, in der es oft an Ressourcen und Zeit mangelt, wobei die Einrichtung zwangsläufig zu einem Zerwürfnis zwischen zwei Teams führt, die letztlich das gleiche Ziel haben, aber völlig unterschiedliche Sprachen sprechen.

Nun, in diesem Klima wird der Empfang für verpflichtende Sicherheitsschulungen wahrscheinlich ziemlich kühl sein. Aber es ist kein Hirngespinst, in jedem Entwickler ein Sicherheitsdenken zu wecken. Mit der richtigen Art von Training und Unterstützung können sie beginnen, Sicherheit in ihre Software einzubauen und die Verantwortung für die Sicherheitsergebnisse zu übernehmen, die sie kontrollieren können. Wenn sich die Entwickler selbst um die üblichen Fehler kümmern können, werden die teuren Spezialisten frei, um die wirklich komplexen Probleme auszubügeln. Und wenn Sie in der Position sind, ein Entwicklungsteam zu leiten, können Sie entscheidend dazu beitragen, diese Lücke zu schließen und Ihrem Team zu helfen, die Vorteile zu erkennen.

Nicht jedes Training ist gleich.

Wann haben Sie sich das letzte Mal wirklich dafür begeistert, etwas Neues zu lernen? In der Zeit, in der Sie es getan haben, sind Ihnen wahrscheinlich Worte wie "Pflicht", "Compliance" oder "siebzehn Stunden Video" nicht in den Sinn gekommen.

Entwickler sind nicht anders. Sie sind clever, kreativ und lieben es, Probleme zu lösen. Es ist ziemlich unwahrscheinlich, dass das Anschauen endloser Videos über Sicherheitsschwachstellen sie fesseln wird, dass der Inhalt im Gedächtnis bleibt oder dass er sich auf ihre täglichen Aufgaben und Verantwortlichkeiten bezieht. In meiner Zeit als SANS-Trainer hat sich sehr früh gezeigt, dass das beste Training praxisorientiert ist und die Teilnehmer dazu zwingt, zu analysieren und intellektuell herausgefordert zu werden, indem sie Beispiele aus der realen Welt verwenden, die ihr Gehirn testen und auf vorheriges Lernen aufbauen. Gamification und freundschaftlicher Wettbewerb sind ebenfalls mächtige Werkzeuge, um jeden mit neuen Konzepten vertraut zu machen, während sie gleichzeitig nützlich und praktisch in der Anwendung bleiben.

Ein weiterer beängstigender Faktor ist, dass viele Sicherheitsschulungen unkontrolliert ablaufen. Niemand hat gerne das Gefühl, dass Big Brother zuschaut, aber was nützt es, Zeit, Geld und Mühe in die Ausbildung zu investieren, wenn niemand überprüft, ob sie relevant ist?

Mit der richtigen Lösung macht sicheres Coding Spaß, ist relevant, ansprechend und messbar. Fordern Sie Ihre Entwickler heraus, behandeln Sie sie gut und machen Sie es zu einem besonderen Ereignis. Gamifiziertes Training aktiviert die Belohnungszentren im Gehirn und bietet einen Anreiz, weiter zu lernen, die Grenzen des Wissens zu erweitern und ganz einfach einen höheren Softwarestandard zu entwickeln - eine Win-Win-Situation.

Gesundheitscheck der Sicherheitskultur: Ist Ihre am Lebenserhaltungssystem?

Sichere Software in einer Umgebung mit einer schlechten Sicherheitskultur zu erstellen, ist wie der Versuch, einen Marathon mit einem Felsbrocken am Knöchel zu gewinnen: praktisch unmöglich und unnötig schwierig.

Gamified Training, Kopf-an-Kopf-Rennen tournaments und das Engagement, Entwickler bei ihrem Sicherheitswachstum zu unterstützen, helfen immens dabei, eine positive Sicherheitskultur zu fördern, wobei AppSec- und Entwicklungsteams viel mehr Einblick in die tägliche Arbeit des jeweils anderen erhalten. Bessere Beziehungen wachsen und gedeihen, und das (oft begrenzte) Sicherheitsbudget wird nicht durch ein "Murmeltiertag"-Szenario der immer gleichen kleinen, nervigen Bugs verbrannt.

Es gibt noch ein weiteres starkes Nebenprodukt: die Entdeckung der Sicherheitschampions, von denen Sie nie wussten, dass Sie sie haben. Richtiges Training, das alle Beteiligten mit einbezieht und gleichzeitig eine gründliche assessment ermöglicht, kann diejenigen freilegen, die nicht nur eine Begabung für Sicherheit haben, sondern aktiv eine Leidenschaft dafür zeigen. Diese Champions sind wichtig, um den Schwung aufrechtzuerhalten und als Ansprechpartner zwischen den Teams zu fungieren, die Kollegen zu beaufsichtigen und die Best-Practice-Richtlinien aufrechtzuerhalten. Die Implementierung eines soliden Champion-Programms, das Anerkennung und Unterstützung durch die Geschäftsleitung beinhaltet, ist nicht nur ein Pluspunkt für das Unternehmen, sondern macht sich auch sehr gut im Lebenslauf des Einzelnen und in seiner zukünftigen Karriere.

Wenn Sie sich zu einer positiven Sicherheitskultur verpflichten, wird die Verantwortung geteilt und eine höhere Stufe der sicheren Software-Exzellenz kann erreicht werden. Letztendlich muss sich jede Person im Softwareentwicklungszyklus an ein einfaches Mantra halten: Wenn es keine sichere Software ist, ist es keine gute Software.

Verbreiten Sie die Nachricht.