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.

Bewährte Verfahren für die Cybersicherheit sind seit mehr als einem Jahrzehnt ein heißes Thema, das auf Regierungsebene in den meisten Regionen der Welt häufig diskutiert wird. Cyberattacken sind im Grunde eine tägliche Realität, und jedes Unternehmen, das wertvolle private Daten online speichert, ist ein potenzielles Ziel. Allein in Deutschland schätzt das Bundesministerium für Bildung und Forschung, dass 96 Prozent aller kleinen und mittleren Unternehmen bereits einen IT-Sicherheitsvorfall erlebt haben. Der gleiche Bericht unterstreicht den dringenden Bedarf an Cybersecurity-Forschung, -Gesetzgebung und -Bewusstsein und fordert definitiv eine solidere Sicherheitsausbildung in Informatik und IT-bezogenen Fächern.

Mit der Einführung von GDPR sowie einer überarbeiteten Strategie nach einem mehrstufigen Angriff, bei dem die sensiblen Daten vieler Persönlichkeiten des öffentlichen Lebens sowie Server der deutschen Bundesregierung offengelegt wurden, ist es klar, dass das Bewusstsein für Cybersicherheit und entsprechende Maßnahmen für Führungskräfte in der DACH-Region an erster Stelle stehen. Der Hack Ende 2018 wurde von einem 20-jährigen Studenten mit relativ geringen Fähigkeiten durchgeführt, wobei der Hauptzugang zu hochsensiblen Informationen durch einfaches Erraten von Passwörtern möglich war. Dies war zwar ein äußerst besorgniserregender Authentifizierungs-Exploit, machte aber auch deutlich, dass ein weitaus besseres Sicherheitsbewusstsein auf Regierungs-, Unternehmens- und gesellschaftlicher Ebene erforderlich ist. In einem Bericht aus dem Jahr 2019 wurde hervorgehoben, dass Deutschland in Bezug auf Initiativen zur Cybersicherheitsverteidigung ins Hintertreffen geraten ist und sich auf die Gesetzgebung als Haupttaktik verlässt. Mit dem Aufkommen von DevSecOps als ideale Entwicklungsmethodik haben viele Unternehmen jedoch den Bedarf an praktischen Schulungen, Secure-by-Design-Softwareerstellung und unternehmensweiten Programmen zur Sensibilisierung für Sicherheit erkannt.

Der Software-Sicherheits-Herzschlag in DACH

Organisationen wie OWASP und MITRE veröffentlichen datengeprüfte Ranglisten der am häufigsten auftretenden Sicherheitslücken. Über alle Sprachen hinweg rangiert die SQL-Injection auf Platz eins. Obwohl sie schon Jahrzehnte alt ist, ist sie ein weit verbreiteter Fehler, der oft mit katastrophalen Folgen ausgenutzt wird.

Die Schweizer BPC-Bankensoftware SmartVista wurde vom SwissCERT auf eine SQLi-Schwachstelle aufmerksam gemacht, die jedoch monatelang ungepatcht blieb, obwohl sie sensible Kundendaten, einschließlich Kreditkartennummern, preisgeben könnte. SQL-Injektion kann und wird zu gefährlichen Sicherheitsverletzungen führen, so wie im Jahr 2017, als mehrere Regierungsbehörden und Universitäten in den USA und Großbritannien betroffen waren. Viele dieser Vorfälle werden durch laxe Eingabevalidierungsprozesse verursacht, die es einem Angreifer ermöglichen, bösartigen Code über das Frontend einer Anwendung einzufügen. Eine weitere häufige Quelle für Schwachstellen ist die Verwendung von unsicherem Herstellercode, der nicht auf Sicherheitslücken geprüft wird, so dass Fehler in eine zuvor gescannte und freigegebene Produktionsumgebung eingeschleust werden. Keiner dieser Zugangspunkte ist spezifisch für die DACH-Region, vielmehr handelt es sich um globale Beispiele für schlechte Sicherheitspraktiken, die nicht fortbestehen können, wenn die Welt mehr Code produziert.

Es ist zwingend notwendig, Probleme zu patchen, sobald sie entdeckt werden, und die Entscheidung von SmartVista, die Sache hinauszuzögern, hätte eine Katastrophe sein können. Auch wenn es in der DACH-Region bereits einige Sicherheitsverletzungen gegeben hat, könnten gezieltere Richtlinien und Unterstützung für Sicherheitsbewusstsein und Schulungen verhindern, dass potenzielle Probleme auf organisatorischer Ebene aus dem Ruder laufen.

Nicht alle Schulungen für sicheren Code sind gleich.

Viele Cybersicherheitsrichtlinien auf der ganzen Welt werden immer umfassender, bleiben aber recht unspezifisch, wenn es darum geht, ein effektives Sicherheitstraining zu umreißen. Die NIS-Richtlinie in der EU enthält zwar die Forderung nach "Bewusstseinsbildung, Schulung und Ausbildung" auf nationaler Ebene, aber eine überstürzte Einführung einer Schulungslösung führt möglicherweise nicht zum gewünschten Ergebnis einer spürbaren Risikominderung, wenn Schlüsselelemente fehlen, die Entwickler und organisatorische Veränderungen vorantreiben.

Schulungslösungen variieren, und die Schulung muss spezifisch für die tägliche Arbeit des Entwicklers sein (einschließlich der Möglichkeit, in der bevorzugten Sprache und dem bevorzugten Framework zu lernen) sowie ansprechend und im Laufe der Zeit messbar bleiben.

Statische Schulungslösungen, wie z. B. computergestützte Videotrainings, sind oft zu allgemein gehalten und werden nur selten auf ihren Erfolg bei der Förderung des Bewusstseins und der Fähigkeit, das Eindringen von Schwachstellen in den Code während des Schreibens zu verhindern, überprüft oder bewertet. Dynamisches Training hingegen ist entscheidend, um Entwickler mit kontextbezogenen Beispielen weiterzubilden und darüber hinaus Metriken bereitzustellen, die den Prozess der Schadensbegrenzung beeinflussen. Es wird häufig aktualisiert, fördert ein hohes Maß an Wissensspeicherung und ist Teil des Aufbaus sicherheitsbewusster Entwickler, die zu einer positiven Sicherheitskultur an ihrem Arbeitsplatz beitragen.

Secure Code Warrior Datenpunkte von DACH-Piloten:

Secure Code Warrior Ema Rimeike, Sales Director (MSc in Cyber Security), hat eng mit Unternehmen in der DACH-Region zusammengearbeitet und Pilotprogramme für Entwickler durchgeführt, um die internen Kompetenzen der Entwickler im Bereich Secure Coding, ihr Engagement für Best Practices im Bereich Sicherheit sowie die allgemeine Sicherheitskultur des Unternehmens zu ermitteln. Durch den Einsatz von gamifizierten, dynamischen Secure-Code-Trainings zeigen ihre wichtigsten Ergebnisse eine vielversprechende Zukunft auf, wenn Entwicklern das Wissen und die Werkzeuge zur Verfügung gestellt werden, die eine erfolgreiche Reduzierung von Schwachstellen von Beginn des SDLC an fördern.

Während ihrer Pilotprogramme sammelte sie Statistiken, die auf einer durchschnittlichen Verweildauer von 90 Minuten pro Benutzer auf der Plattform Secure Code Warrior (SCW) basierten, in denen sie 15 sichere Coding Challenges(mundgerechte, gamifizierte und selbstgesteuerte Lektionen) spielten:

Die Benutzer brauchten durchschnittlich 5,5 Minuten, um eine Herausforderung abzuschließen, im Vergleich zu durchschnittlich 3 Minuten bei anderen globalen SCW-Piloten.

• Genauigkeit vs. Konfidenz: Die DACH-Piloten verzeichneten einen durchschnittlichen Prozentsatz von 88-92 % für das Vertrauen in ihre Antworten auf die Herausforderungen, doch die Genauigkeit dieser Antworten lag zwischen 53-66 %
• Über 75% der befragten Teilnehmer bevorzugen gamifizierte - oder dynamische - Trainingsmethoden, im Gegensatz zu statischen Ansätzen wie Computer Based Training (CBT).
• Zu den am häufigsten festgestellten Schwachstellen gehörten Injektionsfehler, falsche Sicherheitskonfiguration, Cross-Site-Scripting (XSS), unsachgemäße Plattformnutzung, Zugriffskontrolle, Authentifizierung, Speicherkorruption, Cross-Site-Request-Forgery, unzureichender Schutz der Transportschicht sowie nicht validierte Um- und Weiterleitungen.

Es ist kein Geheimnis, dass im Allgemeinen eine starke Arbeitsmoral und der Fokus auf Präzision von vielen in der DACH-Region geschätzt wird, und die Entwickler, die das Pilotprogramm ausprobieren, sind keine Ausnahme. Diese Datenpunkte sprechen für ihre Unvertrautheit mit dieser Art von Training, aber auch für den Wunsch, weiter zu spielen, ihre Punktzahl zu verbessern und die verfügbare "Tipp"-Funktion nicht zu nutzen. Ihr Wunsch, zu lernen und sich zu verbessern, ist offensichtlich, aber es zeigt auch, dass mehr getan werden muss, um effektive Schulungen und ein Bewusstsein innerhalb der Organisation selbst zu implementieren.

Großartige Schulungen, die Risiken reduzieren und Schwachstellen vereiteln, sind keine einmalige Übung, und es geht um mehr als nur um Compliance. Manager und AppSec-Mitarbeiter müssen sich bemühen, ein Security-Awareness-Programm mit einer Strategie und Unterstützung auszurollen, das die zentralen Sicherheitsziele widerspiegelt und darauf abzielt, diese langfristig zu erhalten. Dies ist in der Tat das Rückgrat eines erfolgreichen DevSecOps-Prozesses mit sicherheitsbewussten Entwicklern.

Was sagt ein Pilotprogramm über eine Organisation aus?

Die Pilotprogramme vonSecure Code Warrior sind ein unglaublich wertvolles Werkzeug, um Unternehmen eine Momentaufnahme ihres aktuellen Sicherheitszustands (in der Regel zwischen 65-75 %) sowie Bereiche für sofortige Verbesserungen zu geben. Sie offenbaren:

• Klarheit darüber, welche Schwachstellen vorrangig angegangen werden müssen, sowie darüber, ob diese Anweisung für ein bestimmtes Team, eine Geschäftseinheit oder eine Programmiersprache gelten soll
• Eine genaue, umfassendere Information über die Cybersecurity-Risikofaktoren innerhalb ihres SDLC, die auch den menschlichen Faktor der Softwareentwicklung einschließt.
• Durch den Einsatz der SCW-Plattform können Unternehmen das potenzielle Ergebnis von Pen-Tests vorhersagen und haben die Möglichkeit, diese Risiken im Vorfeld zu minimieren, indem sie Teams vorbereiten, bevor sie überhaupt mit einem bestimmten Projekt betraut werden.

In Unternehmen, die mit der Einführung umfassender und effektiver Sicherheitsprogramme begonnen haben, werden in der Regel 1-1,5 Stunden pro Woche an professioneller Weiterbildung auf Managementebene genehmigt, um ihre Entwickler bei der Verbesserung ihrer Kenntnisse im Bereich der sicheren Programmierung zu unterstützen. Wir stellen jedoch fest, dass sich die Unternehmen von dem Fokus "Zeitaufwand für die Plattform" wegbewegen hin zu der Frage, "welche Softwareentwicklungsteams das höchste und welches das geringste Risiko für das Unternehmen darstellen". Dies ist eng verknüpft mit formalisierten Zertifizierungen, der Entdeckung von Sicherheits-Champions und Mentoring-Programmen für beste Ergebnisse. Die Zuteilung von Zeit sowie eine konstruktive und positive assessment ist der absolute Schlüssel, um sicherheitsbewusste Entwickler zu schaffen, die nicht nur die Sicherheit mögen, sondern auch das Risiko für das Unternehmen messbar reduzieren.

Wie nutzen Organisationen bereits Secure Code Warrior?

Mehrere Unternehmen nutzen bereits Secure Code Warrior , um ein Bewusstsein zu schaffen, die Fähigkeiten von Entwicklern auszubauen und eine positive Sicherheitskultur zu skalieren.

In einem Anwendungsfall nutzte beispielsweise ein Team, das auf der Plattform trainierte, den SCW, um seine Sicherheitsstärken und -schwächen aufzudecken:  

Maßnahmen für Entwickler: Die Entwickler konnten ihre eigenen Ergebnisse sehen, die ihnen die Bereiche aufzeigten, auf die sie sich konzentrieren sollten, und wurden in die Lage versetzt, das Training selbst zu steuern, um bestimmte Schwachstellen oder Wissenslücken zu entschärfen, die ihnen bei zukünftigen Softwareentwicklungen helfen werden.

Management-Maßnahmen: Sie analysierten die allgemeinen Stärken und Schwächen auf Teamebene und waren in der Lage, einen gamifizierten Ansatz vorzuschreiben, der die spezifischen Problembereiche anspricht. Dadurch wurde ein zweiseitiger Bildungsweg geschaffen, der schnell relevantes Wissen aufbaut.

Das Ergebnis: Sobald das Pentesting auf Teamebene durchgeführt wurde, sind alle Schwachstellen sichtbar, und der Vergleich früherer Ergebnisse machte es einfach, zu überprüfen, ob die Schulung bei der Reduzierung häufiger Sicherheitsfehler wirksam war.

Dies führt zurück zu den Anfangsphasen der Softwareentwicklung, in denen die Vorab-Schulung von Teamzielen der kontinuierlichen Verbesserung und die Einführung von Best Practices für die Sicherheit zu Beginn effektiv sein kann, einfach auszurollen ist und Zeit über den gesamten Entwicklungsbereich spart.

DevSecOps-Projektteams

In einer idealen DevSecOps-Umgebung sind mehrere Geschäftsbereiche in einem Projektteam vertreten, um über zentrale Ergebnisse zu entscheiden und diese zu liefern, zu denen auch Best Practices für die Sicherheit gehören.

In Bezug auf die Recherche und Planung vor Projektbeginn kann die SCW-Plattform die Sicherheitskompetenzen des vorgeschlagenen Entwicklungsteams bewerten, bevor es mit der Arbeit beginnt, und mögliche Pentesting-Ergebnisse und sicherheitsbezogene Verzögerungen im SDLC mit mehr als genug Zeit für eine angemessene Vorbereitung vorhersagen. Für das Team kann eine auf den Projektcode und die Projektstruktur abgestimmte Schulung erstellt werden, einschließlich eines assessment/Zertifizierungsprozesses, der die allgemeinen Fähigkeiten des Sicherheitsbewusstseins überprüft und eine voreingestellte Erfolgsquote erfordert, bevor das Team für die Projektleistungen freigestellt wird.

Dieser Ansatz bietet einen immensen geschäftlichen Nutzen, da er die Kosten für die Behebung von Schwachstellen senkt, Sicherheitsrisiken mindert, Zeit beim Pentesting spart, die Kosten für teure Bounty-Programme reduziert und die Entwicklungskohorte auf eine zentralisierte, nachhaltige, skalierbare und einheitliche Weise weiterbildet.

Fazit:

Der Druck auf Unternehmen steigt, Sicherheit zu priorisieren, unsere Daten zu schützen und die immer strengeren Vorschriften weltweit einzuhalten, aber insbesondere für Organisationen, die in der EU unter den strengen GDPR-Richtlinien handeln.

Für Unternehmen in der DACH-Region ist klar, dass sie praktikable Sicherheitswege beschreiten, indem sie Schulungsaufwand und -ergebnisse mit realen Aktivitäten zur Risikovermeidung verbinden; dazu gehört auch die Reduzierung häufiger Schwachstellen in dem von ihnen produzierten Code.

Um einen wirklich quantifizierbaren Business Case für eine Erhöhung der Sicherheitsbudgets, des Sicherheitsbewusstseins und der allgemeinen Compliance aufzubauen, müssen die Schulungen für die Entwickler ansprechend, konsistent, anpassbar und messbar sein. Die Nachverfolgung des aktuellen Stands der Fähigkeiten, um das richtige Training zuzuschneiden, die Entdeckung von Sicherheits-Champions und die Messung der Teamleistung im Laufe der Zeit sind alles wichtige Initiativen, und viele vorausschauende Unternehmen in der DACH-Region erkennen die Vorteile nach einem umfassenden SCW-Pilotprojekt.

Viele Unternehmen kämpfen mit zu allgemein gehaltenen Metriken zur Sicherheitsleistung. Mit einer längerfristigen, konsequenten Nutzung der SCW-Plattform könnten Unternehmen präzise Bewertungen, courses und Managementmetriken nutzen, um zu entdecken:

• Verringerung der Schwachstellen im Laufe der Zeit
• Reduzierung der Kosten für die Behebung von Sicherheitslücken im Laufe der Zeit
• Entwicklung von individuellen und Teamfähigkeiten im Laufe der Zeit
• Kosten- und Zeitersparnis beim Pentest

Welche Metriken verfolgt Ihr Unternehmen derzeit, wie oft werden sie neu gemessen und haben sie im Laufe der Zeit deutliche Verbesserungen gezeigt? Wie integriert sind Ihre Schulungsinitiativen in Bezug auf den bestehenden Arbeitsablauf der Entwickler?

Der dynamische, spielerische und umfassende Ansatz von SCW wird als ein entscheidender Teil des Secure Software Development Life Cycle-Workflows angesehen. Unternehmen statten ihre Entwickler mit den richtigen Tools und Schulungen aus und betten SCW als Teil ihres SSDLC-Workflows ein.

Dieser Artikel erschien ursprünglich in Informationssicherheit Buzzund wurde von mehreren anderen Medien aufgegriffen. Er wurde für die Syndizierung hier aktualisiert.

Gegen Ende des letzten Jahres veröffentlichte die erstaunliche Community von MITRE ihre Liste der CWE Top 25 der gefährlichsten Softwarefehler, die die Welt im Jahr 2019 betreffen. Diese Liste ist nicht meinungsgesteuert, sondern das Ergebnis einer vielschichtigen Analyse, die sich auf die Arbeit von Organisationen wie NIST sowie auf die veröffentlichten CVE-Daten (Common Vulnerabilities and Exposures) stützt. Um die "Top"-Schwachstellen zu bestimmen, wird ihnen eine Punktzahl zugewiesen, die auf ihrem Schweregrad, ihrer Ausnutzbarkeit und ihrer Verbreitung in aktueller Software basiert. Das ist keine Liste, die mit Lob überschüttet wird, soviel ist sicher.

Doch anders als bei den meisten Jahresrückblicken sind viele der Teilnehmer dieser Liste schon einmal erschienen... immer und immer wieder. Wenn dies die Billboard Hot 100 Charts wären, wäre es so, als würden Britney Spears'Baby One More Time und die Backstreet Boys'I Want It That Way jedes einzelne Jahr seit ihrer ersten Veröffentlichung erscheinen. Und warum habe ich diese Songs ausgewählt? Nun, sie sind ungefähr zwanzig Jahre alt (fühlen Sie sich schon uralt?), ähnlich wie einige dieser gefährlichen Softwarefehler, die uns noch bis ins Jahr 2020 plagen, obwohl sie schon vor Jahrzehnten entdeckt wurden.

Warum sind alte Bugs immer noch so gefährlich? Wissen wir nicht, wie wir sie beheben können?

Nummer sechs auf der aktuellen MITRE-Liste ist CWE-89, besser bekannt als SQL-Injection (SQLi). Die SQLi-Schwachstelle wurde erstmals 1998 entdeckt, damals, als viele von uns noch ihre brennenden Fragen an Jeeves statt an Google stellten. Ein Fix wurde bald darauf bekannt gegeben, und dennoch bleibt dies eine der meistgenutzten Hacking-Techniken im Jahr 2019. Der Akamai Zustand des Internets Bericht zeigte, dass SQLi der Übeltäter bei zwei Dritteln aller Angriffe auf Webanwendungen war.

Was die Komplexität angeht, so ist SQL-Injection weit davon entfernt, ein Exploit auf Genie-Niveau zu sein. Es ist eine einfache Lösung für einen Webentwickler, und wir wissen ohne zu zögern, wie man verhindern kann, dass diese Schwachstelle wertvolle Daten einem Angreifer preisgibt... das Problem ist, dass für viele Entwickler auch heute noch Sicherheit keine Priorität hat. Das mag vor zwanzig Jahren einfacher gewesen sein, aber bei der schieren Menge an Software, die heute und in Zukunft erstellt wird, kann das nicht länger die Norm bleiben.

Entwickler arbeiten in einem kaputten System (die meiste Zeit).

Es ist allzu einfach, sich zurückzulehnen und den Entwicklern die Schuld dafür zu geben, dass sie "schlechten" Code liefern. Die Wahrheit ist, dass ihre Prioritäten sich stark von denen des Sicherheitsteams unterscheiden. Ihr durchschnittliches Entwicklungsteam hat den Auftrag, so schnell wie möglich schöne, funktionale Software zu erstellen. Das unstillbare Bedürfnis der Gesellschaft nach Software sorgt dafür, dass die Entwicklerteams bereits überlastet sind und die Sicherheit keine primäre Rolle spielt; schließlich gibt es deshalb AppSec-Spezialisten. Software-Ingenieure sind an ein etwas kühles Verhältnis zur Sicherheit gewöhnt - sie hören nur von ihnen, wenn Probleme auftreten, und diese Probleme können die Produktion ihrer harten Arbeit aufhalten.

Auf der anderen Seite des Zauns sind AppSec-Spezialisten es leid, jahrzehntealte Fehler zu beheben, die bei jedem Scan und jeder manuellen Codeüberprüfung auftauchen. Diese Spezialisten sind teuer und rar, und ihre Zeit ist weitaus besser für komplexe Sicherheitslücken eingesetzt, anstatt bekannte Fehler immer wieder zu beseitigen.

Es gibt eine unausgesprochene Kultur des Schuldzuweisens zwischen diesen Teams, aber sie haben (oder sollten) das gleiche Ziel haben: sichere Software. Entwickler agieren in einer Umgebung, die ihnen kaum die besten Erfolgschancen in Bezug auf sichere Programmierung bietet; bewährte Sicherheitspraktiken werden nur selten als Teil ihrer Hochschulausbildung gelehrt, und Schulungen am Arbeitsplatz sind oft viel zu selten oder völlig ineffektiv. Die Folge sind astronomische Kosten für die Behebung alter Bugs in fehlerhaftem Code und die unmittelbare Gefahr einer rufschädigenden Datenpanne.

Der menschliche Faktor, a.k.a. "Warum machen all diese Tools unsere Daten nicht sicherer?"

Ein weiteres Problem, das häufig auftritt, ist, dass anstelle von Schulungen ein riesiges Arsenal an Sicherheitstools eingesetzt wird, um Probleme zu finden, bevor die Software in die freie Wildbahn entlassen wird. Das Arsenal an Anwendungs-Scan- und Schutz-Tools(SAST/DAST/RASP/IAST) kann sicherlich bei der sicheren Software-Produktion helfen, aber sie bringen ihre eigenen Probleme mit sich. Vollständiges Vertrauen in sie garantiert keine Sicherheit, denn:

• Kein "einziges" Tool kann nach jeder Schwachstelle, in jedem Framework, in jedem Anwendungsfall suchen
• Sie können langsam sein, besonders wenn sie im Tandem laufen, um sowohl statische als auch dynamische Code-Analyse zu liefern
• False Positives sind nach wie vor ein Problem; diese halten oft die Produktion an und erfordern eine unnötige manuelle Codeüberprüfung, um den Sinn der Alarme zu verstehen
• Sie schaffen ein falsches Gefühl der Sicherheit, wobei sichere Kodierung in der Erwartung, dass diese Tools alle Probleme aufspüren, vernachlässigt wird.

Die Tools werden sicherlich Sicherheitslücken aufdecken, die gepatcht werden können, aber werden sie auch alles finden? Eine 100-prozentige Trefferquote kann nicht garantiert werden, und ein Angreifer braucht nur eine Tür offen zu lassen, um sich Zutritt zu verschaffen und Ihren Tag wirklich zu ruinieren.

Zum Glück erkennen viele Unternehmen den menschlichen Faktor, der bei Software-Schwachstellen eine Rolle spielt. Die meisten Entwickler sind nicht ausreichend für die sichere Programmierung geschult, und ihr Sicherheitsbewusstsein ist insgesamt gering. Sie stehen jedoch ganz am Anfang des Lebenszyklus der Softwareentwicklung und sind in der besten Position, um zu verhindern, dass Schwachstellen jemals in den Code gelangen. Wenn sie von Anfang an sicher programmieren würden, wären sie die erste Verteidigungslinie gegen verheerende Cyberangriffe, die uns jedes Jahr Milliarden kosten.

Entwickler müssen die Chance haben, sich zu entfalten, mit Schulungen, die ihre Sprache sprechen, die für ihre Arbeit relevant sind und sie aktiv für das Thema Sicherheit begeistern. Fehlerfreier Code sollte ein Punkt des Stolzes sein, ähnlich wie das Bauen von etwas funktional Großartigem Ihnen den Respekt der Kollegen einbringt.

Ein modernes Sicherheitsprogramm sollte eine geschäftliche Priorität sein.

Entwicklungsteams können sich nicht selbst an den Ärmeln hochziehen und ein positives Sicherheitsbewusstsein im gesamten Unternehmen durchsetzen. Sie benötigen die richtigen Tools, das Wissen und die Unterstützung, um Sicherheit von Anfang an in den Softwareentwicklungsprozess einzubauen.

Alte Trainingsmethoden funktionieren offensichtlich nicht, wenn die MITRE-Liste immer noch so viele alte Sicherheitsfehler aufzeigt, also versuchen Sie etwas Neues. Suchen Sie nach Trainingslösungen, die sind:

• Hands-on; Entwickler lieben es, "durch Handeln zu lernen", nicht durch das Betrachten von sprechenden Köpfen auf Videos
• Relevant; lassen Sie sie nicht in C# trainieren, wenn sie jeden Tag Java benutzen
• Fesselnd; mundgerechtes Lernen ist leicht verdaulich und ermöglicht es Entwicklern, auf bereits vorhandenem Wissen weiter aufzubauen
• Messbar; kreuzen Sie nicht einfach ein Kästchen an und gehen Sie weiter. Sicherstellen, dass das Training effektiv ist und Wege zur Verbesserung schaffen
• Spaß; schauen Sie sich an, wie Sie das Sicherheitsbewusstsein zusätzlich zur Unterstützung einer positiven Sicherheitskultur aufbauen können und wie dies eine kohäsive Teamumgebung schaffen kann.

Sicherheit sollte für jeden im Unternehmen eine Priorität sein, wobei der CISO die Bemühungen auf jeder Ebene, unsere Daten sicherer zu machen, sichtbar und transparent macht. Ich meine, wer will schon das gleiche alte Lied in der Wiederholung hören? Es ist an der Zeit, sich ernsthaft mit der Beseitigung alter Bugs zu beschäftigen.

Wenn man "Wachstum" in einem geschäftlichen Kontext sieht, bezieht sich das fast immer auf Kennzahlen, Umsatz, Finanzierung, Mitarbeiterzahlen... all das Zeug, über das ich vor einem Jahrzehnt noch nicht nachdenken musste.

Ich hätte diesen Artikel mit all diesen Fakten und Zahlen beginnen können; sie sind unbestreitbar beeindruckend und unsere laufende Unternehmensentwicklung ist stark. Für mich spiegeln diese Zahlen jedoch nicht wider, worauf ich 2019 am meisten stolz bin. Die Realität ist, dass wir ein wirklich spektakuläres Team von Menschen aufgebaut haben, die sich weit über die nackten Finanzmetriken hinaus engagieren. Wir haben einen "Wachstumsschub" erlebt, der das enorme Herz dieses Unternehmens jetzt und in der Zukunft geprägt hat.

Erlauben Sie mir, dies zu demonstrieren, lieber Leser:

‍

Wir haben das Programm "Warriors Give Back" ins Leben gerufen, eine globale Wohltätigkeitsinitiative für alle Mitarbeiter, die innerhalb von 12 Monaten mehr als 10 Veranstaltungen in Sydney, Boston, London und Brügge durchgeführt hat:

• 50 Warriors bauten mit der Organisation Bikes for Tykes Fahrräder und verteilten sie an unterprivilegierte Kinder in Sydney
• 9 Warriors in Boston arbeiteten ehrenamtlich in der Cradles to Crayons Giving Factory und sortierten und bündelten Spenden für bedürftige Kinder vor Ort
• Die Teammitglieder unterstützten die Obdachlosigkeit und erlebten gleichzeitig, wie es ist, mit nur zehn Dollar in der Hand und ohne Heizung oder Kühlung für eine Woche Essen einzukaufen
• In Brügge halfen Warriors 100 Kindern bei CyberSkool-Aktivitäten, darunter Roboter bauen, hacken und Schlösser knacken
• Warriors kauften Artikel für Weihnachtskörbe sowie Spielzeug für bedürftige Kinder mit Wesley City Connect
• Unsere in London ansässigen Warriors haben eine örtliche Grundschule mit Ausrüstung gesponsert und sich dem Umweltteam der Schule angeschlossen, um ihre Spielfelder zu säubern
• Wir haben uns mit TechLadies + the WING zusammengetan und bieten kostenlose Lebenslaufhilfe und persönliches Karriere-Coaching an
• Im Rahmen unserer Jahresendfeier haben wir Weihnachtsgeschenke für bedürftige Familien in der Region eingekauft und sind dabei eine Partnerschaft mit dem ABCD Adopt a Family Program eingegangen. Deren Service bringt bedürftige Familien mit Einzelpersonen, gemeinnützigen Organisationen und Unternehmen zusammen, die einer Familie während der Weihnachtszeit oder das ganze Jahr über helfen wollen.

Und angesichts einer der schlimmsten Buschfeuersaisonen, die es je in Australien gegeben hat, haben wir uns zusammengetan, um dem Rural Fire Service und WIRES zu spenden, kurz bevor das Jahr zu einem düsteren Ende kam. Es ist eine andauernde Krise, in der sich nichts als genug anfühlt, aber ich war berührt von der Empathie, die unser globales Team gezeigt hat.

Diese "Warriors Give Back"-Veranstaltungen erinnern uns regelmäßig daran, dass es im Leben mehr gibt als Metriken, und wir alle sind geerdeter, wenn wir uns die Mühe machen, in den Schuhen anderer zu laufen, die weniger Glück haben. Menschlichkeit und Bescheidenheit sind der Schlüssel zur Aufrechterhaltung einer positiven Kultur, und unser Team setzt sich bei jeder Gelegenheit dafür ein.

Sind Sie noch wegen der Zahlen hier?

In Bezug auf unser Produkt haben wir 2019 1727 neue sichere Coding-Herausforderungen in zehn neuen Sprachframeworks erstellt. Das ist eine gigantische Leistung für unser Entwicklungsteam, das durchschnittlich 144 neue Herausforderungen pro Monat erstellt hat - mehr als in jedem anderen Jahr zuvor. Auch in Bezug auf unsere Nutzer gab es einige interessante Zahlen zu vermelden:

• Die beliebteste Sprache/Framework war Java: Spring, mit 455.973 abgeschlossenen Secure Coding Challenges
• Pseudocode war ein unerwarteter Superstar, mit 295.763 gespielten Herausforderungen
• Die beliebteste Schwachstellenkategorie ist Injection Flaws, was keine Überraschung ist. Sie ist die Nummer eins in den OWASP Top 10 und die Nummer eins für uns.

Unsere Leute in Zahlen.

Als ich dieses Unternehmen gegründet habe, habe ich sehr deutlich gemacht, dass die Vielfalt entscheidend für unseren zukünftigen Erfolg sein wird. Ich möchte nicht in einer Echokammer von Leuten festsitzen, die genauso sind wie ich; die Unterschiedlichkeit der Meinungen, der Kultur, des Geschlechts, der Diäten und der Rasse ist Teil der Magie in einem globalen Startup. Ab sofort repräsentiert unser Team:

• 17 verschiedene Nationalitäten
• 53% männliche, 47% weibliche Mitarbeiter
• Mindestens 9 verschiedene diätetische Anforderungen (es gab Zeiten, in denen das einzige, was wir alle sicher essen konnten, Popcorn war)
• Mehrere Glaubensrichtungen an jedem Ort der Welt.

Ich bin unheimlich stolz auf unser lebendiges Team, und das merkt man bei allem, was wir tun.

Oh, und ja, wir sind beim Umsatz um mehr als 100 % gewachsen, haben unsere Serie-B-Finanzierungsrunde abgeschlossen (was die bisher größte US-Investition in ein australisches Cybersicherheitsunternehmen darstellt), sind schnell auf ein Team von 120 Mitarbeitern angewachsen und haben neue Niederlassungen in Portland und Singapur eröffnet.

Es ist unser fünfter Geburtstag, und obwohl das Unternehmen genauso alt ist wie meine Tochter, sind die Ähnlichkeiten zwischen ihren Reisen zu Ende. Zum Glück habe ich noch ein paar Jahre Zeit, um zu sehen, wie sie eine glückliche, gesunde Erwachsene wird. Bei Kindern zischen diese Jahre in einem Wimpernschlag vorbei, aber Secure Code Warrior ist nicht mehr das freche Kleinkind. Schneller, als ich es mir vor fünf Jahren hätte vorstellen können, sind wir erwachsen geworden und haben uns selbstständig gemacht. Wir sind bereit, den vor uns liegenden Weg des Hyperwachstums zu gehen, aber ich muss mich immer noch an den Gedanken gewöhnen, dass ich als Erwachsene das Sagen habe.

Dieser Artikel wurde ursprünglich veröffentlicht auf DevOps.de. Er wurde aktualisiert und geändert.

Ähnlich wie "Blockchain", "Big Data" und "Digital Disruption" ist der Begriff "DevOps" ein weiteres Buzzword, das derzeit in den IT-Abteilungen großer Unternehmen herumgereicht wird.

Viele haben (richtigerweise) den Bedarf an schnelleren Softwareentwicklungs-Lebenszyklen erkannt; ein präziserer Prozess, der eng mit den Geschäftszielen abgestimmt ist und einen klareren Arbeitsablauf und eine bessere Zusammenarbeit zwischen den Entwicklungs- und Betriebsteams ermöglicht. DevOps ist im Wesentlichen eine "agile" Entwicklung, die erwachsen geworden und bereit ist, sich den ständig innovativen und schnell bereitstellenden Anforderungen des modernen Unternehmens zu stellen. Für Sicherheitsexperten ist es eine fantastische Initiative: Wir können die Sicherheit viel früher in den Prozess einbringen, die Kosten für die Behebung von Fehlern reduzieren und potenzielle Katastrophen im Nachhinein vermeiden.

Das Problem ist, dass nur wenige Unternehmen bei ihrer DevOps-Implementierung wirklich erfolgreich sind. Ohne die richtige Unterstützung, Pflege und das Verständnis im gesamten Unternehmen kann es schnell zu einem weißen Elefanten werden... Sie wissen schon, eines dieser "Erwähnen Sie den Krieg nicht"-Projekte.

Wo liegt also das Problem? Es ist eine interessante Diskussion, und es gibt ein paar Möglichkeiten, DevOps anzugehen, die meiner Meinung nach für einen viel reibungsloseren Ablauf sorgen werden. Ein effektives Programm geht über ein paar ausgefallene neue Tools, Titel und Team-Meetings hinaus. Es wird nicht immer einfach sein, aber wenn man sich die Zeit nimmt, eine kaputte Strategie zu korrigieren (oder sie von Anfang an richtig zu implementieren), wird es auf lange Sicht viel weniger schmerzhaft sein. Und letztendlich wird es zu einer höheren Qualität und Sicherheit der Software führen.

Lassen Sie uns das aufschlüsseln:

Lassen Sie die "Agile"-Schürzenbänder los.

Es gibt ein gewisses Missverständnis, dass eine Organisation sich zwischen Agile oder DevOps entscheiden muss und den einen oder anderen Weg einschlägt, um nie wieder zurückzublicken.

Die Sache ist die, dass der Entwicklungsprozess am besten funktioniert, wenn beides als Einheit betrachtet und umgesetzt wird. DevOps ist keine Neuerfindung der agilen Entwicklung, sondern eine Erweiterung derselben. Die Räder neigen dazu, abzufallen, wenn die Erwartung besteht, dass der Prozess genau wie Agile oder völlig anders als Agile sein wird.

Agile unterstützt das Prinzip der funktionsübergreifenden Teams, indem es Designer, Tester und Entwickler von Anfang an zusammenbringt und sich für offene Kommunikationslinien während eines Projekts einsetzt. Ziel ist es, die siloartige Bereitstellung zu beenden und die doppelte Bearbeitung zu reduzieren - beides sind ebenfalls Vorteile des DevOps-Prozesses. DevOps geht jedoch noch einen Schritt weiter und bezieht Systeme, Sicherheit und Betrieb mit ein, um ein robustes, durchgängiges Skillset zu bieten, das das ultimative Ziel der vollständigen, funktionalen Softwareauslieferung an den Kunden verfolgt.

Während der unvermeidlichen Schmerzpunkte bei der Umstellung auf einen stärker DevOps-zentrierten Prozess kann das Risiko einer siloartigen Entwicklung wieder auftauchen. Oft arbeitet das ursprüngliche Agile-Team zusammen, während die Sicherheits- und Betriebsergänzungen noch ihren Weg in die Maschine finden; niemand ist sich ganz sicher, wie man sie einbezieht, was sie tun sollen und welche Ziele sie insgesamt verfolgen.

DevOps funktioniert nicht ohne klar definierte Ziele, funktionsübergreifendes Onboarding und direkte Kommunikation mit allen Beteiligten. Sicherlich wird es eine Anpassungsphase geben, die ein sorgfältiges Änderungsmanagement erfordert, aber alle auf die gleiche Seite mit den Verbesserungen zu bringen, die DevOps-Funktionen mit sich bringen, ist schon die halbe Miete.

Zunehmend (Gott sei Dank) legt DevOps auch Wert auf bewährte Sicherheitspraktiken als Teil des Prozesses, entmystifiziert diesen Schritt und überbrückt die Kluft zwischen dem Sicherheitsteam und, nun ja, allen anderen. Wie ich bereits gesagt habe, haben wir noch einen langen Weg vor uns, um Entwickler zu befähigen, von Anfang an sicher zu programmieren, aber die erfolgreiche Implementierung von DevOps-Methoden ist eine hervorragende Grundlage, auf der Sicherheitskompetenzen innerhalb des Entwicklungsteams aufgebaut werden können.

Automatisierung ist nicht alles (und auch nicht das Sicherste).

Ein weiteres Merkmal der DevOps-Methodik ist, bis zu einem gewissen Grad, die Automatisierung des Softwareentwicklungsprozesses. Die Prinzipien der kontinuierlichen Integration und der kontinuierlichen Bereitstellung (CI/CD) sind die Eckpfeiler dieses Konzepts und, wie Sie wahrscheinlich erraten können, sehr abhängig von Tools.

Tools sind großartig, das sind sie wirklich. Sie können den Softwareentwicklungsprozess in beispielloser Geschwindigkeit vorantreiben, indem sie das Code-Repository, die Tests, die Wartung und die Speicherelemente relativ nahtlos verwalten.

Doch auch wenn Roboter eines Tages alle unsere Jobs übernehmen und uns gefangen halten könnten, sind sie definitiv noch nicht so weit. Die starke Abhängigkeit von Tools und Automatisierung lässt ein Fenster weit offen für Fehler. Scans und Tests erkennen möglicherweise nicht alles, Code kann ungeprüft bleiben, was im Nachhinein zu enormen Qualitäts- (ganz zu schweigen von Sicherheits-) Problemen führt. Ein Angreifer braucht nur eine Hintertür auszunutzen, um Daten zu stehlen, und der Verzicht auf das menschliche Element bei der Qualitäts- und Sicherheitskontrolle kann katastrophale Folgen haben.

Der "goldene Mittelweg" besteht darin, ein Gleichgewicht zwischen Menschen und Werkzeugen zu schaffen. Tools sollten als Assistenten für ein Team dienen, dem Sie vertrauen, die Projektziele zu erreichen. Das sollten Sie:

• Planen Sie genügend Zeit ein, damit sich die Mitarbeiter mit der gewählten DevOps-Toolchain vertraut machen können
• Fokus auf effektive Zusammenarbeit (und wie die Tools dies unterstützen können)
• Adressieren Sie alle Lücken im Prozess, unabhängig davon, ob es sich um Fähigkeiten/Wissen oder um Werkzeuge handelt.

Kurz gesagt, rüsten Sie nicht einfach "auf" und hoffen Sie auf das Beste.

DevOps ist kein Modewort, sondern eine Kultur. Wachsen Sie Ihre?

Change Management ist in den besten Zeiten schwierig. Die Angst vor dem Unbekannten kann selbst die brillantesten Teammitglieder davon abhalten, ihre Fähigkeiten auszubauen und ihren Horizont zu erweitern.

Sehen Sie, einfach nur zu sagen "lasst uns DevOps machen" und das Betriebsteam dazu zu bringen, den Schreibtisch zu wechseln, wird nicht auf magische Weise einen erfolgreichen Prozess implementieren. Viele werden verwirrt sein, und langjährige Teammitglieder werden verärgert zurückbleiben. Die Kommunikation der Erwartungen ist von entscheidender Bedeutung, ebenso wie das "Gehen des Weges". DevOps stellt eine kulturelle Bewegung dar, genauso wie eine Entwicklungsmethodik, und ein Team sollte eine funktionsübergreifende, kollaborative Denkweise leben und atmen.

Wie sieht eine großartige DevOps-Kultur aus?

• Einzelpersonen sind befähigt, ihr Fachwissen in einen Prozess einzubringen, nicht nur Führungskräfte
• Offene, ehrliche und respektvolle Kommunikation zwischen Teams
• Jede Person übernimmt die Verantwortung für das Gesamtziel, Qualität und Sicherheit in den Entwicklungsprozess einzubauen
• Jeder ist auf derselben Seite mit der Definition von DevOps im Unternehmen, der Roadmap und dem Wie/Was/Warum der Rolle jeder Person.

Seit Jahren betone ich, wie wichtig der Aufbau einer positiven Sicherheitskultur in Entwicklungsteams ist, und das ist bei DevOps nicht anders.

Die richtigen Tools, das richtige Wissen und der richtige Support sind unerlässlich, um Best Practices für die Sicherheit zu erreichen, einen Rückgang der entdeckten Schwachstellen zu sehen und dem Team die Augen zu öffnen, wie wichtig der Schutz unserer Daten ist. Mit DevOps müssen Sie die kulturelle Grundlage für positive Veränderungen schaffen: Stellen Sie sicher, dass jeder seine Rolle, seinen Wert und seine Erwartungen, die allgemeinen Projektziele und die Schritte im Prozess versteht.

Haben Sie das gemeistert? Prima. Dann lassen Sie uns jetzt die Nadel verschieben, den Sicherheitsaspekt erhöhen und DevSecOps zum ultimativen Plan für Software-Exzellenz machen.

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.

Anfang des Monats hatte ich die Gelegenheit, am OWASP AppSec Day 2019 im schönen Melbourne teilzunehmen. Diese auf Entwickler ausgerichteten Veranstaltungen gehören zu meinen Favoriten im Kalender; sie sind eine demütige Erinnerung an die Community, die unermüdlich daran arbeitet, Software-Ingenieure und -Spezialisten zu schulen und zu befähigen, sich für Sicherheit bei ihrer Arbeit einzusetzen.

Die Gästeliste war sensationell - um nicht zu sagen erfrischend vielfältig - und es ist ein tolles Gefühl, dass auch ich nach all den Jahren in der Branche inspiriert nach Hause gehen kann. Leute wie Tanya Janca, Toni James und Teri Radichel lieferten unglaubliche Präsentationen, während Wireghoul'Eldar Marcussen on-the-spot secure coding challenges das ganze Auditorium auf die Probe stellte, aber es war toll, so viel tiefes Sicherheitsbewusstsein unter den Teilnehmern zu erleben.

Dieses Jahr war Secure Code Warrior ein Platin-Sponsor der Veranstaltung. Ich musste lächeln, als ich mich daran erinnerte, dass es noch vor vier Jahren das Team hinter dem OWASP AppSec Day war, das unserem Startup mit einem kostenlosen Stand und Werbung aushalf. Es war ein Moment des Stolzes, zu sehen, wie weit wir als Unternehmen gekommen waren, und ein Moment der Dankbarkeit, dass es eine so großzügige Gemeinschaft von unglaublichen Menschen gibt.

Toni James: Sicherheit aus der Sicht eines Entwicklers

Wenn es eine Sache gibt, die wir in dieser Welt mehr fördern müssen, dann ist es Empathie. Und wenn es darum geht, Software auf breiter Front sicherer zu machen, ist es unerlässlich, die Notlage des Entwicklers zu verstehen.

Ich habe Tonis Präsentation wirklich genossen, und ich bin sicher, dass sie für jeden Entwickler sofort nachvollziehbar war. Es geht um viel mehr als nur "schreibe sicheren Code", und während ich sicherlich glaube, dass Entwickler, die effektiv in Sicherheit geschult sind, unsere beste Chance im Kampf gegen Schwachstellen sind, ist es unerlässlich, ihre täglichen Herausforderungen zu berücksichtigen.

Die Arbeit eines Softwareentwicklers kann für Millionen von Benutzern sichtbar sein, kritische Infrastrukturen unterstützen und die treibende Kraft hinter Diensten sein, die wir für selbstverständlich halten. Die Entwicklung von Funktionen, die Umsetzung von Geschäftsinnovationen und die Einhaltung schlanker Liefertermine erzeugen eine Menge Druck - und das, bevor ein AppSec-Team auftaucht und die harte Arbeit zerpflückt. Toni sprach darüber, wie das Leben in diesem Umfeld aussieht und wie eine gute Dosis Empathie auf allen Seiten zu weit besseren Prozessen und Sicherheitsergebnissen führen kann. Ich bin sehr erfreut zu sehen, dass solche gesunden Fortschritte gemacht werden, um die Kluft zwischen Entwicklern und AppSec-Teams zu überbrücken; am Ende des Tages ist dies ein kritisches Element für eine positive, florierende Sicherheitskultur, und Toni ist ein Paradebeispiel dafür, dass dieser Prozess unglaublich gut funktioniert.

Tanya Janca und Teri Radichel: Sicherheits-Superhelden

Nicht, dass es ein Wettbewerb wäre, aber die Beiträge von Tanya Janca und Teri Radichel auf der Konferenz gehörten zu meinen Favoriten. Schon nach zehn Minuten ihres Tutorials über DIY-Cloud-Sicherheits-Assessments wurde ihre erstaunliche Bandbreite an Erfahrungen, Qualifikationen und Fachwissen deutlich, aber auch ihre echte Herzlichkeit und ihr Wunsch, Wissen zu teilen und die Entwickler-Community zu unterstützen. Gemeinsam präsentierten sie realistische und umsetzbare Maßnahmen, um sicherzustellen, dass Azure-Implementierungen sicher sind, einschließlich praktischer Ratschläge zur Festlegung von Sicherheitsrichtlinien und Maßnahmen zur Minimierung von Privilegien.

Eine schnelle Google-Suche wird Ihnen alles sagen, was Sie über ihr Engagement für die Unterstützung von Entwicklern an der Basis wissen müssen, mit einer Fülle von kostenlosen Ressourcen, Mentoring-Möglichkeiten und Interviews, um die lustige und engagierte Seite der Software-Sicherheit zu fördern. Sie sind inspirierende, vitale Verfechter unserer Community; wenn sie auf der nächsten Sicherheitskonferenz sprechen, die Sie besuchen, wären Sie verrückt, wenn Sie ihre Session verpassen würden.

Kunden auf der großen Bühne

Es war großartig zu sehen, dass so viele unserer Kunden nicht nur anwesend waren, sondern auch die Bühne in Besitz nahmen und ihr immenses Sicherheitswissen mit dem Publikum teilten.

Wir haben es geschafft, Andrew Bailey von Telstra zu erwischen, der einen wichtigen Vortrag zum Thema "Adding the "Sec'to DevOps"" hielt. Sein Erfahrungsschatz als Senior Software Engineer, der sich nun auf Anwendungssicherheit und sicheres Coding konzentriert, war eine hervorragende Perspektive, die er hervorhob. Er gab durchgängige Tipps, wie man Sicherheit in jede Phase des SDLC einbringen kann (natürlich auch gleich zu Beginn, indem man mehr Entwickler in sicherer Kodierung schult).

Ken Johnson ist Teil des Sicherheitsteams von GitHub, und ich habe mich sehr gefreut, ihn am Ende der Konferenz in der Expertenrunde zu sehen. Zusammen mit den anderen Diskussionsteilnehmern war er nur zu gerne bereit, drängende Fragen aus dem Publikum zu beantworten, darunter auch solche, die in den Medien nicht unbedingt die Aufmerksamkeit erhalten, die sie verdienen. Neben einigen Einblicken in die Branche brachte er das Panel dazu, über die Bedeutung von Wohlbefinden und Work-Life-Balance zu sprechen, was im Zeitalter von Entwickler-Burnout sehr wichtig ist.

Ich möchte ein riesiges Dankeschön an Julian Berton und das gesamte OWASP Melbourne Team für eine weitere unglaubliche Konferenz aussprechen. Wir sehen uns nächstes Jahr (mit mehr Aufklebern).

Es fühlt sich so an, als ob "Cybersecurity Compliance" schon seit Jahren ein Trend ist, mit endlosen Artikeln, Initiativen und Komitees, die darüber diskutieren, wie die Welt am besten gegen das riesige, mehrfach bedrohte Ungeheuer, das die Cyberkriminalität ist, vorgehen sollte.

Das Problem ist, dass wir anscheinend nicht so viel Fortschritt gemacht haben. Weltweit sind die Kosten für Datenschutzverletzungen stetig gestiegen, und zwar um 12 % in fünf Jahren, um sich im Jahr 2019 bei ca. 3,92 Millionen US-Dollar pro Datenschutzverletzung einzupendeln. Als unsere Nutzung des Internets in nur wenigen kurzen Jahrzehnten explodierte, waren viele Unternehmen einfach ohne Rüstung aufgeschmissen, als sie schnell online gingen, ihr Geschäft einrichteten und sich mit den Folgen unsicherer Software, begrenzter AppSec-Ressourcen und in einigen Fällen mit dem Missbrauch des Kundenvertrauens auseinandersetzen mussten.

Heutzutage sind wir unbestreitbar reifer. Wir verstehen und diskutieren ausführlich über das Ausmaß der Bedrohung, Unternehmen sind sich der Auswirkungen bewusst, die ein Cyberangriff auf die Stimmung der Kunden, ihren Ruf und ihren Gewinn haben kann, und vielerorts wird aktiv versucht, die Softwaresicherheit durch Compliance-Schulungen, qualifizierte Einstellungen und zunehmend auch DevSecOps-Initiativen zu verbessern. Trotz dieser großen Fortschritte gewinnen wir den Kampf nicht - nicht einmal annähernd. Allein im Jahr 2019 wurden mindestens vier Milliarden Datensätze bei Datenschutzverletzungen gestohlen.

Eine fehlende Zutat war ein etwas langsames Durchsickern (auf Regierungsebene) von Cybersicherheitsstandards, Erwartungen und Konsequenzen eines Verstoßes. Die Einführung der GDPR hat zumindest in Europa einige Köpfe rollen lassen, aber viele Regierungsbehörden holen erst jetzt auf, und die plötzliche Notwendigkeit, sich schnell an die neu entstandenen Compliance-Initiativen zu halten, könnte in Zukunft einige unerwünschte Auswirkungen haben.

Narren stürzen sich (auf die falsche Ausbildung)

Robuste Richtlinien in Form von NIST, neue Vorschriften für den Bundesstaat New York und die Gründung des UK Cyber Security Council sind allesamt monumentale Erfolge für diejenigen, die den guten Kampf für die Sicherheit unserer Daten kämpfen. Sie erkennen die Probleme in der aktuellen Softwareentwicklung an und ergreifen Maßnahmen, um Organisationen zu den Standards zu führen, die sie jetzt erfüllen müssen, um als ethisch und konform in Bezug auf die besten Sicherheitsverfahren zu gelten.

Leider sind in diesem Stadium einige der wichtigsten Elemente ein wenig zu offen für Interpretationen. Zum Beispiel lautet eines der Mandate in der Gesetzgebung des britischen Cyber Security Councils:

"Erstellung einer definierten Liste von Zertifizierungen und eines leicht verständlichen Rahmens, wie sie alle miteinander verbunden sind und welche Fähigkeiten sie vermitteln, aufbauend auf der bereits durchgeführten Arbeit an den Karrierewegen".

Zwar werden sich ihre Initiativen im Laufe der Zeit zweifellos verbessern und ausweiten, doch wenn Unternehmen bereits jetzt den Panikknopf drücken und sich auf Schulungen stürzen, sind sie für die Zukunft möglicherweise schlecht gerüstet.

Die Anforderungen an die Cybersicherheit einer Organisation ändern sich schnell, und es ist unwahrscheinlich, dass statische Schulungslösungen den Fluss unsicherer Software in dem erforderlichen Tempo eindämmen können. Die Landschaft ändert sich schneller, als ein traditioneller Kurs aktualisieren kann, was dazu führen kann, dass einige Orte in die "Tick-the-Box"-Compliance-Übungsfalle tappen; Entwickler, Auftragnehmer und andere Sicherheitsexperten erhalten keine angemessene Schulung, und wir sind wieder leichte Beute.

Statisches Training und statische Werkzeuge leiden unter den gleichen Problemen

Statische Analysewerkzeuge sind ein integraler Bestandteil des SDLC und erledigen ihren Job als Scan-Arbeitspferde für die knappen und überlasteten AppSec-Spezialisten in den meisten großen Unternehmen. Sie machen einen guten Job, aber es gibt einen Fehler: Kein "einziges" Tool kann nach jeder einzelnen Schwachstelle scannen und die riesige Bandbreite an Programmier-Frameworks unterstützen, die es gibt. Außerdem ist es ein langsamer Prozess, und es reicht schon ein einziger Sicherheitsfehler, der durch die Maschen fällt, um einem Angreifer Tür und Tor zu öffnen.

Bei statischem Training gibt es ein ähnliches Problem. Wenn Entwickler ein Sicherheitstraining als einen starren, "one-and-done" Kurs erhalten, ist es sehr unwahrscheinlich, dass es mit den häufigsten Sicherheitsproblemen in diesem Zeitraum Schritt gehalten hat. Es dient als eine Momentaufnahme der Zeit, in der es geschrieben wurde, und es wird selten genug wiederholt, in der bevorzugten Sprache und dem Framework des Schülers vermittelt, noch ist es kontextbezogen zu den Schwachstellen, mit denen sie wahrscheinlich in ihrer täglichen Arbeit konfrontiert werden. Stellen Sie sich vor, Sie versuchen, sich an eine relevante Information aus einem Video zu erinnern, das Sie vor Monaten gesehen haben, während Sie versuchen, die Liefertermine einzuhalten und den Code zur Tür hinauszurollen... das ist unwahrscheinlich, dass das passiert.

Traditionelle Schulungsmethoden werden in vielen Branchen neu bewertet, aber wenn es um Sicherheitsschulungen für Entwickler geht, muss man sich nur die schiere Menge an Datenschutzverletzungen ansehen, die wir immer noch erleben (vor allem solche, die auf Schwachstellen zurückzuführen sind, von denen wir seit Jahrzehnten wissen, wie man sie in der Programmierung vermeidet, wie z. B. SQL-Injection), um zu erkennen, dass wir einen anderen Weg einschlagen müssen.

Wir brauchen ein Training, das über die Grenzen eines einzelnen, linearen Kurses hinausgeht und das sich flexibel an die sich ständig ändernden Anforderungen von Cybersecurity Best Practices anpassen kann.

Dynamisches Training: der Goldstandard

Indem Sie Entwicklern eine dynamische Schulungslösung anbieten, die sich schnell an das Unternehmen, den individuellen Kenntnisstand und die allgemeinen Branchenentwicklungen anpassen lässt, bieten Sie ihnen die beste Grundlage für eine sichere Programmierung, bei der die Sicherheit im Vordergrund steht und sie mit einer sicherheitsbewussten Denkweise handeln.

Eine Schulung, die für alle passt, nie wiederholt wird und von vornherein nicht ansprechend ist, ist reine Zeitverschwendung, und das bedeutet leider, dass Sie am Ende ein ineffektives Programm kaufen könnten, nur um der Einhaltung der Vorschriften willen. Es könnte schon veraltet sein, bevor Sie es überhaupt ausgerollt haben, oder es hat kaum Bezug zu den Anforderungen der täglichen Arbeit.

Dynamisches Training ist ein lebendiges, atmendes Werkzeug, das ständig aktualisiert wird, sich an den täglichen Bedürfnissen orientiert, die Benutzer zum kritischen Denken anregt und sie tatsächlich dazu befähigt, Fähigkeiten zu erlernen und Probleme zu lösen.

Wie sieht also ein dynamisches Trainingsprogramm in einem Sicherheitskontext aus?

Das wird es sein:

• Mundgerecht: Entwickler können Fertigkeiten in überschaubaren Häppchen erlernen, die sich viel leichter einprägen (und, was noch wichtiger ist, anwenden) lassen als langatmige Schulungsdecks und Videos
• Relevant: Was nützt ein allgemeines Sicherheitstraining, bei dem die Beispiele in, sagen wir, C# sind, wenn der Entwickler hauptsächlich in Java programmiert? Jede Schulung sollte sich direkt auf ihre Rolle beziehen, damit sie sehen können, was sie beim Programmieren finden und beheben (und idealerweise von vornherein vermeiden) müssen.
• Aktuell: Das scheint offensichtlich, ist es aber oft nicht. Die Cybersicherheitslandschaft ändert sich ständig, und mit mehr Code kommt auch mehr Verantwortung. Damit Entwickler Ihre erste Verteidigungslinie sein können, brauchen sie Schulungen, die mit modernen Best Practices für Sicherheit auf dem neuesten Stand sind.
• Fesselnd: Es ist kein Geheimnis, dass Entwickler "Sicherheit" als lästig empfinden können, vor allem, wenn sie ihren kreativen Fluss stören. Die richtige Schulung zeigt ihnen die Macht, die sie bei der Lösung alltäglicher Sicherheitsprobleme haben, die sich zu großen Risiken entwickeln können, und schafft eine Kultur der Verantwortung und des Sicherheitsbewusstseins.
• Spaß: Dynamisches Training ist selten langweilig; es soll von vornherein zumindest etwas spannend sein. Denken Sie daran, was Entwickler lieben: Probleme zu lösen, sich mit Gleichgesinnten zu messen und wie viele von uns in der Arbeitswelt, Belohnungen und Anerkennung. Spielen Sie mit ihren Stärken und konzentrieren Sie sich darauf, die besten Ergebnisse zu erzielen.

Es ist eine aufregende Zeit, ein Software-Ingenieur zu sein; sie spielen eine wesentliche Rolle bei der digitalen Innovation, helfen dabei, erstaunliche Unternehmen zu gründen, und erobern sogar die Welt mit ihren eigenen Kreationen im Sturm. Da Regierungsbehörden und große Unternehmen jedoch erkannt haben, welche Rolle sie bei der Festlegung von Standards für die Softwaresicherheit spielen müssen, ist es wichtig, sie mit effektiven, dynamischen Schulungslösungen zu unterstützen, die die Liebe zur sicheren Programmierung fördern und nicht eine bürokratische Abhak-Übung darstellen.

Die Phrase "Es braucht ein Dorf" ist ein altes afrikanisches Sprichwort, das sich über viele verschiedene afrikanische Kulturen, Dialekte und geografische Standorte erstreckt. Auch wenn die Sprache, die verwendet wird, um diese Perle der Weisheit zu vermitteln, unterschiedlich sein mag, ist die Stimmung dieselbe: Es braucht den Beitrag der gesamten Gemeinschaft, um eine sichere, positive und aufschlussreiche Umgebung zu schaffen, in der zukünftige Generationen zu gut ausgebildeten Erwachsenen heranwachsen.

Das mag wie ein langer Bogen erscheinen, den man spannen muss, aber tatsächlich hat die Entwicklergemeinschaft jahrzehntelang genau nach diesem Prinzip gelebt. Die Vorstellung vom asozialen, "einsamen Wolf" Geek hinter einem Computer ist wie die meisten Stereotypen: übertrieben und nicht der beste Weg zu lernen, wie wir arbeiten. Es gibt Entwickler aller Art, aus allen Gesellschaftsschichten, und es gab schon immer ein Gefühl der Gemeinschaft bei allem was wir tun.

Lange bevor das Internet zur Norm wurde, tauschten wir auf Schwarzen Brettern Tipps aus, lösten gegenseitig unsere Probleme und stritten uns über die besten Praktiken (und, jedenfalls auf meiner Seite des Zauns, arbeiteten wir hart daran, Dinge zu zerstören). Dieses Gefühl hat sich nicht geändert. Das Internet ist jetzt ein anderes Biest, mit mehr Trollen unter der Brücke und viel mehr Lärm, aber ein schneller Sprung in Orte wie Reddit und Stack Overflow gibt Ihnen ein sofortiges Gefühl von Hilfsbereitschaft, Kameradschaft und einer Fülle von Informationen.

Eine Sache, die wir jedoch alle unterstützen könnten, sind diese realen Verbindungen zu Menschen, die das Gleiche durchmachen. Es gibt eine neue Bedeutungsebene, wenn man in der realen Welt interagiert, und die Förderung einer "IRL"-Community kann den Wissensaustausch, die Klärung und die Erweiterung des Horizonts auf wunderbare Weise beschleunigen.

Wie unterstützt die Entwicklergemeinschaft die Sicherheit?

Organisationen wie OWASP leisten unglaubliche Arbeit in der Sicherheits-Community, mit einer Fülle an kostenlosen Ressourcen zu Schwachstellen, Nachrichten und kritischen Warnungen. Offline gibt es OWASP-Chapter in Städten auf der ganzen Welt, die regelmäßige Veranstaltungen veranstalten, bei denen Menschen zusammenkommen, über Sicherheit sprechen und Tipps austauschen, um unsere Software sicherer zu machen. Es ist wirklich großartig, und für mich ist es das, worum es in der Entwicklergemeinschaft geht.

Eine Sache, die diese Gemeinschaften, egal ob online oder persönlich, helfen, ist die Wissenslücke unter den Entwicklern zu schließen. Viele erfahrene Entwickler sind nur zu gerne bereit, Informationen weiterzugeben, jemandem bei den ersten Schritten zu helfen oder ihm die richtige Richtung zu weisen (jeder gute Jedi weiß, dass er hin und wieder einem Padawan helfen muss).

Es ist also immer ein echter Leckerbissen, wenn wir mit ihnen zusammenarbeiten, um Dinge wie Secure Coding tournaments zu veranstalten. Bisher haben wir Meetups in Australien, England, Indien und den USA unterstützt, und ich hoffe, es werden noch viele weitere folgen.

Wie sieht ein OWASP tournament Meetup aus? Sehen Sie sich dieses Video eines OWASP tournament an, das in London in den kultigen BBC-Studios stattfand:

Diese Veranstaltungen helfen sicherlich bei der Bewusstseinsbildung, und dieser Schwung kann innerhalb von Organisationen genutzt werden, wenn sie diese Basisinitiativen unterstützen, vollwertige Secure Coding-Schulungen einführen sowie sich verpflichten, mit einer positiven Sicherheitskultur zu arbeiten.

Wie helfen Gamification und tournaments dabei, mehr Sicherheit für Entwickler zu schaffen?

Bei den OWASP-Meetups geht es darum, Kontakte zu knüpfen, Wissen auszutauschen und Ideen mit einem breiten Spektrum an sicherheitsbewussten Personen zu diskutieren. Für diejenigen, die neu im Bereich Sicherheit sind (oder noch kein Interesse daran haben), können diese Veranstaltungen jedoch unbemerkt bleiben.

Wenn Unternehmen eine aktive Rolle bei der Schaffung eines Sicherheitsbewusstseins spielen und echtes Interesse bei den Entwicklern wecken, kann dies den positiven Effekt haben, dass ein lebenslanges Streben nach Sicherheitswissen in ihnen geweckt wird - die Art, die wir brauchen, um jeden dazu zu bringen, ernsthaft sicher zu programmieren.

Typische Trainingsmethoden sind selten ein großer Motivator (man denke an das Sitzen in einem Klassenzimmer, während sich die Aufgaben im Job stapeln, oder an den Versuch, wach zu bleiben, indem man sich endlose Videos ansieht), aber das Entfachen eines Gefühls von Wettbewerb, Spaß und Gamifizierung des Prozesses kann das Lernen weit weniger zu einer lästigen Pflicht machen. Gamifizierte Lernmethoden machen technisches (und manchmal trockenes) Wissen viel verdaulicher, indem sie es in kleinere Stücke brechen, die kontextbezogen und einprägsam sind und zum wiederholten Lernen anregen. Secure Code Warrior wurde auf einer Grundlage der Zugänglichkeit aufgebaut, die es den Entwicklern ermöglicht, ihr bisheriges Lernen Schritt für Schritt zu erweitern, und zwar auf eine Art und Weise, die ihre Kreativität und ihren allgemeinen Instinkt für Problemlösungen anspricht.

Bewertungen helfen dabei, jeden auf dem richtigen Weg zu halten und Bereiche für Verbesserungen zu identifizieren, aber ein sicheres Coding tournament kann als Katalysator für das Sicherheitsbewusstsein in der Organisation und für positive Veränderungen dienen, sowie als eine Möglichkeit für die Teilnehmer, ihre robusten Fähigkeiten zu zeigen. Wenn man sieht, wie sich die Rangliste von tournament in Echtzeit aktualisiert, ist man motiviert, weiter nach mehr Punkten zu streben und seine Sicherheitsfähigkeiten unter Beweis zu stellen.

Wie sieht eine erfolgreiche tournament aus?

Das Ziel unserer Meetups mit OWASP ist es immer, in die fortlaufende Gesundheit der Sicherheits-Community zu investieren und ihnen dabei zu helfen, das Konzept zu fördern, dass das Lernen über Sicherheit tatsächlich Spaß machen kann.

Sicheres Programmieren tournaments ist ein absolutes Muss, wenn es darum geht, Entwickler zu engagieren und ihnen zu helfen, ihre Fähigkeiten in einer sozialen Umgebung mit Gleichgesinnten zu verbessern und zu verwirklichen. Sie helfen dabei, die künstlichen Mauern einzureißen, die um die Idee der "Sicherheit" herum bestehen, vielleicht aufgrund einer weniger angenehmen Erfahrung bei der Arbeit oder in der Ausbildung.

Eine wirklich großartige tournament besteht typischerweise aus Folgendem:

• Ein bisschen Fanfare in der Organisation; lassen Sie Leute außerhalb der Entwicklungsteams wissen, was passiert und warum
• Eine urteilsfreie Umgebung, die Entwickler auf allen Ebenen unterstützt
• Ein paar besondere Vergünstigungen; bestellen Sie Essen und Getränke, geben Sie dem Ganzen ein Thema und fördern Sie die Selbstdarstellung
• Belohnungen und Anerkennung; wir Entwickler lieben Werbegeschenke, und tolle Preise für die Gewinner sind ein Bonus: Denken Sie daran, dass Ihre zukünftigen Sicherheits-Champions während dieses Prozesses entdeckt werden könnten
• Ein Gefühl von Gemeinschaft und Kameradschaft.

Wir entwickeln uns zu einer DevSecOps-Welt, und da Sicherheit endlich von Anfang an in den Fokus von Softwareentwicklungsprojekten rückt, müssen Entwickler frühzeitig mit effektiven Schulungen eingebunden werden. Sie sind von dem Moment an, in dem der Code geschrieben wird, maßgeblich daran beteiligt, ein Unternehmen vor Schwachstellen zu schützen, und in einer gedeihlichen Sicherheitskultur kann jeder ein wenig ruhiger schlafen.