Es ist kein Geheimnis, dass wir bei Secure Code Warrior fest an die Macht der Gamification glauben, um Entwickler zu sicherem Code zu bewegen. Das ist es, was wir tun, und die Ergebnisse waren bisher erstaunlich. Aber was ist mit der Verwendung eines echten Videospiels, um potenzielle neue Mitarbeiter zu beurteilen? Geht das einen Schritt zu weit, oder könnte es eine effektive Praxis sein?

Genau das macht das Startup Scoutible, und ich muss sagen, dass ich von ihrem Ansatz fasziniert bin. Scoutible bewertet potenzielle Mitarbeiter mithilfe eines Videospiels - keine gamifizierten Bewertungen, sondern ein tatsächliches Videospielerlebnis - und überprüft, wie sich die Person in bestimmten Situationen verhält. Das Spiel erfasst "Millionen von Datenpunkten, die zur Messung der verschiedenen Attribute eines Kandidaten verwendet werden", während nur 20 Minuten Spielzeit, und verwendet diese Datenpunkte, um zu bewerten, wie der Kandidat für den jeweiligen Job geeignet wäre.

Es gibt hier eine Menge zu mögen, und auch eine Menge zu lernen. Das Produkt ist flexibel, um die Bedürfnisse der Kunden zu erfüllen, und es zielt auf ein Problem ab, das viele Einstellungsverantwortliche seit langem kennen. Selbsteinschätzungen assessment, wie Myers-Briggs, sind einfach nicht zuverlässig. Sie erlauben es Ihnen, das System zu "spielen", oder es zumindest zu versuchen, indem Sie nicht ganz ehrlich sind. In einem Spiel haben Sie ein Ziel und müssen sich anpassen und Probleme lösen, um dieses Ziel zu erreichen. Es ist ziemlich einfach und genial, wenn es so funktioniert, wie Scoutible behauptet. Ich kann es kaum erwarten, mehr darüber zu erfahren.

Spielen versus Gamification

Der Ansatz von Scoutible ist sinnvoll für die Zielgruppe und den Anwendungsfall. An einem bestimmten Punkt in der Entwicklung von Secure Code Warrior haben wir den Wert einer vollständigen Spieleplattform oder in die Schulung integrierte Minispiele in Betracht gezogen, aber am Ende hat dieser Blickwinkel für unsere Zwecke nicht wirklich genug Wert geschaffen. Die Endanwender, die an unseren Sicherheitsschulungen teilnehmen, wissen, dass sie etwas lernen sollen.

Auf unserer Plattform Secure Code Warrior messen wir die sicheren Programmierfähigkeiten eines Softwareentwicklers und nutzen gleichzeitig spielerische Elemente, um die Teilnehmer zu beschäftigen. Das bedeutet, diese Fragen im Hinterkopf zu behalten:

• Kennen sie die häufigsten Software-Sicherheitslücken?
• Können sie gängige Sicherheitsprobleme mit Hilfe von Framework-spezifischen Sicherheitsfunktionen beheben?
• Sind sie von ihren Software-Sicherheitskenntnissen überzeugt?
• Was sind ihre Stärken und Kompetenzlücken in Bezug auf sicheren Code?

Fürsorge durch Design

Es gibt noch einen weiteren Grund, warum ich mich stark mit dem Produkt von Scoutible identifizieren kann. Es ist nicht nur ein Vorteil für das einstellende Unternehmen, sondern auch für den Kandidaten. Nicht alle starken Kandidaten, die man antrifft, sind gut im Vorstellungsgespräch. Bei einigen liegt es einfach nicht in ihrer Persönlichkeit. Anderen wurde die Kunst des Vorstellungsgesprächs nie beigebracht, oder sie sind neu im Berufsleben und es ist ihr erstes Vorstellungsgespräch.

Hier sehe ich eine Ähnlichkeit mit Softwareentwicklern. Leider gibt es in vielen Universitätsprogrammen einfach keinen Fokus auf Sicherheit. Angehenden Entwicklern wird gesagt: "Das lernst du bei der Arbeit." Sie verlassen die Schule mit dem Wissen, wie ihr Code funktioniert, aber sie verewigen unwissentlich all die gleichen Schwachstellen, gegen die wir seit 20 oder mehr Jahren kämpfen.

Wenn Entwickler diesen Job bekommen und darum bitten, etwas über Sicherheit zu lernen, haben sie sogar noch weniger Zeit als zu ihrer Schulzeit. Sie werden dafür bezahlt, funktionale, effektive Software zu produzieren, und viele der Sicherheitsschulungen für Entwickler courses ... nun, sie sind langweilig. Lassen Sie uns ehrlich sein.

Was wäre, wenn Sie Ihre Entwickler, neue und alte, dazu bringen könnten, sich um Sicherheit zu kümmern, ohne wirklich darüber nachzudenken? Wie können Sie Schulungen interessant, fesselnd und sogar unterhaltsam gestalten, während sie gleichzeitig effektiv sind?

Das ist unsere Herausforderung, und genau wie die von Scoutible ist es eine sehr reale Herausforderung. Nur weil das Problem unglaublich ernst ist, heißt das nicht, dass die Lösung profan und langweilig sein muss. Das haben wir schon versucht. Wir ziehen es vor, ein wenig Spaß, Spannung, Wettbewerb und Engagement in unsere Lösung zu injizieren. Bis jetzt hat das sehr, sehr gut funktioniert.

Ich dachte, wenn wir ein Tool bauen könnten, das sich wie ein Spiel anfühlt und Tests für die entsprechenden Persönlichkeits- und kognitiven Eigenschaften enthält, könnten wir viele der Probleme angehen, die ich untersucht hatte.

https://www.inc.com/kevin-j-ryan/scoutible-video-game-reinventing-the-hiring-process.html

Bei der Entwicklung für Mobiltelefone müssen Anwendungen oft einige Berechtigungen vom System anfordern. Sie benötigen möglicherweise Zugriff auf die Kontakte des Benutzers, auf die Bluetooth-Verbindung oder die Möglichkeit, SMS-Nachrichten zu senden. Alle oben genannten Berechtigungen sind Plattformberechtigungen, die durch das Android-Framework definiert sind.

Aber es gibt Fälle, in denen diese nicht ausreichen und die Anwendung ihre eigene benutzerdefinierte Berechtigung definieren muss. Ich nehme unser eigenes Unternehmen als Beispiel. Secure Code Warrior könnte eine App erstellen, die einige private Daten als Teil eines Profils speichert, einschließlich der Leistung des Benutzers auf der SCW-Plattform. Und wir möchten einer anderen Sicherheitsschulungs-App, sagen wir DevTrainer, erlauben, diese Daten zu verwenden, wenn der Benutzer ihr die Erlaubnis dazu gibt. Dies sind sensible Daten, der Benutzer möchte sicherlich nicht, dass irgendjemand diese Daten kennt, aber die SCWApp sollte sie nicht komplett verstecken und schützen, da sie nützlich sein könnten. Also möchten wir dem Benutzer die Kontrolle darüber geben. Hier kommen die benutzerdefinierten Berechtigungen ins Spiel.

Die SCWApp erstellt eine benutzerdefinierte Berechtigung, DevTrainer fordert diese Berechtigung an und der Benutzer kann entscheiden, ob er dies zulassen möchte oder nicht. Dies ist eine gängige Praxis und eine gute Möglichkeit, den Zugriff auf White-Listed-Anwendungen zu beschränken.

Leider gibt es einige unintuitive Verhaltensweisen rund um benutzerdefinierte Berechtigungen, die sie aus Sicherheitsaspekten riskant machen. Konkret können benutzerdefinierte Berechtigungen von jeder App zu jeder Zeit definiert werden, und "der Erste gewinnt", und diese Strategie hat einige Konsequenzen.

Für das folgende Szenario definieren wir zwei App-Profile, die wir oben vorgestellt haben (alle diese Anwendungen sind zu Demonstrationszwecken fiktiv):

1. SCWApp: die App, die eine benutzerdefinierte Berechtigung definiert und eine Komponente mit dieser Berechtigung verteidigt.

2. DevTrainer: diese App definiert die gleiche Berechtigung wie SCWApp und erklärt dem Benutzer, dass sie diese Berechtigung besitzen möchte.

Dies ist ein häufiges Szenario, das als "Peer Apps Case" bezeichnet wird. Wenn die DevTrainer-App nur ein Plugin für die SCWApp wäre, müsste sie die benutzerdefinierte Berechtigung nicht definieren. Die Annahme ist in diesem Fall, dass SCWApp vor DevTrainer installiert wird und kein unerwartetes Verhalten auftritt. Wenn der Benutzer irgendwie DevTrainer zuerst installiert, wird der Benutzer nicht über die Anforderung der Berechtigung informiert. Wenn der Benutzer dann später SCWApp installiert, wird DevTrainer die Berechtigung nicht rückwirkend erteilt, sodass die Versuche der DevTrainer-App, die gesicherte Komponente zu verwenden, fehlschlagen.

Hier kommt der Fall der Peers-App ins Spiel. In manchen Fällen können Sie nicht erwarten, dass eine App vor der anderen installiert wird. Sagen wir, wenn Facebook und Twitter beide die Komponenten des jeweils anderen nutzen wollen, müssen sie die benutzerdefinierten Berechtigungen des jeweils anderen definieren.

An dieser Stelle wird es jedoch knifflig. Wenn die DevTrainer-App zuerst installiert wird, wird der Benutzer nicht über seine Anfrage nach der benutzerdefinierten Berechtigung informiert. Zu diesem Zeitpunkt, obwohl der Benutzer nicht informiert wurde, besitzt DevTrainer die benutzerdefinierte Berechtigung und kann auf die gesicherte Komponente zugreifen.

Es wird noch kniffliger. Die DevTrainer-App kann die Berechtigungsschutzstufe ändern. Android verwendet nicht die Schutzstufe des Verteidigers, sondern die Schutzstufe, die zuerst definiert wurde, d.h. diejenige App, die zuerst installiert wurde, kann diese definieren. Das bedeutet, wenn DevTrainer die Berechtigungsstufe auf normal ändert, dann müssen alle zukünftigen Apps, die diese Berechtigung anfordern, nicht vom Benutzer bestätigt werden, sondern erhalten automatisch Zugriff.

Dieses Szenario wurde durch die Erklärung für dieses Problem inspiriert, die auf dem cwac-security github gefunden wurde.

Die "Wer zuerst kommt, mahlt zuerst"-Strategie hat einige gefährliche Konsequenzen. Wenn der Entwickler das Verhalten nicht kennt, könnte er Sicherheitsentscheidungen auf der Grundlage von nicht vertrauenswürdigen Eingaben treffen und unbeabsichtigten Apps den Zugriff auf sensible Daten oder geschützte Dienste ermöglichen. Um mehr über die Vermeidung von Sicherheitsentscheidungen durch nicht vertrauenswürdige Eingaben zu erfahren, besuchen Sie unsere Plattform. Dieses Verhalten wurde ab Android 5.0 (Lollipop) geändert. Da aber derzeit noch mehr als 22 % der Android-Geräte mit einer niedrigeren Version von Android laufen, ist es wichtig, die Risiken des ursprünglichen Verhaltens in Ihrer App zu mindern. Prüfen Sie, ob die Berechtigung bereits beim ersten Start Ihrer App definiert wurde und ergreifen Sie in diesem Fall entsprechende Maßnahmen, um eventuelle Sicherheitsrisiken zu beheben.

Viel Glück beim Codieren und bis nächste Woche!

Durch die Definition von benutzerdefinierten Berechtigungen kann eine App ihre Ressourcen und Fähigkeiten mit anderen Apps teilen.

https://developer.android.com/guide/topics/permissions/defining.html

Von einem Seitenkanalangriff spricht man, wenn ein Hacker Informationen aus der physischen Implementierung eines Softwaresystems gewinnen kann und nicht aus einer theoretischen Schwäche im Algorithmus oder einem Fehler im Code der Software.

Ein Beispiel, das ich gerne verwende, um dies zu verdeutlichen, ist eine Methode zur Aufzählung von Benutzernamen. Wenn Sie wissen möchten, was die Aufzählung von Benutzernamen ist oder warum sie schlecht ist, besuchen Sie unsere Website für eine Videoerklärung oder spielen Sie eine Herausforderung, um zu sehen, ob Sie sie im Code identifizieren können.

Um nun zu verstehen, wie die Aufzählung von Benutzernamen durch einen Seitenkanalangriff durchgeführt werden kann, müssen Sie ein gewisses Verständnis dafür haben, wie Kennwörter in modernen Webanwendungen gehandhabt werden (oder zumindest gehandhabt werden sollten). Eine gute Webanwendung kennt Ihr Kennwort nicht, sie speichert Ihr Kennwort nirgendwo. Woher weiß sie also, dass das, was Sie eingegeben haben, korrekt ist und tatsächlich Ihr Passwort ist? Nun, Ihr Passwort ist gehasht.

Eine Hash-Funktion ist eine mathematische Operation, die einfach in eine Richtung ausgeführt werden kann (obwohl sie etwas rechenintensiv ist), aber sehr schwer umkehrbar ist, und bei guten Hash-Algorithmen ist die Ausgabe abhängig von der Eingabe eindeutig. Wenn Sie sich auf einer Website anmelden, wird dieser Hash sicher gespeichert, nicht Ihr Passwort selbst. Das bedeutet, dass die Webanwendung jedes Mal, wenn Sie sich anmelden, Ihre Eingabe hasht und die gehashten Ergebnisse mit dem gespeicherten Hash vergleicht. Wenn Sie mehr über die sichere Speicherung von Passwörtern erfahren möchten, können Sie das auf unserer Plattform tun.

Das Hashing von Eingaben nimmt auf einem Computer einige Zeit in Anspruch und die Entwickler versuchen immer, alles, was sie schreiben, zu optimieren, damit die Benutzer eine reibungslose Erfahrung haben. Eine Sache, die das Programm beschleunigt, ist, das Hashing zu überspringen, wenn es nicht benötigt wird. Wenn zum Beispiel der Benutzername nicht existiert (und somit kein Passwort geprüft werden muss), können sie dem Benutzer sofort antworten. Auf diese Weise können sie die langsame Berechnung des Hashes für das Passwort überspringen. Wenn der Benutzername korrekt war, wird die Kennworteingabe gehasht und mit dem gespeicherten Hashwert verglichen.

An dieser Stelle haben Sie vielleicht schon erraten, wo es schief gehen kann. Auch wenn das Hashing in Wirklichkeit nur ein paar Millisekunden dauert, kann ein Hacker diese zusätzliche Verzögerung nutzen, um herauszufinden, ob der eingegebene Benutzername richtig war oder nicht, da ein falscher Benutzername eine etwas schnellere Antwort hat, weil kein Hashing durchgeführt wurde. Diese Art von Seitenkanalangriff wird als Timing-Angriff bezeichnet und ist ein gutes Beispiel dafür, wie verschiedene nicht-funktionale Anforderungen einander entgegenwirken können. Manchmal kann Code nicht gleichzeitig schnell und sicher sein.

Auch wenn die Kennwörter perfekt verarbeitet werden und die angezeigte Meldung generisch ist und nicht angibt, ob das Kennwort oder der Benutzername falsch war, ist das System also immer noch anfällig. Die Lösung ist einfach: Verschlüsseln Sie das Kennwort immer mit einem Hash-Wert oder verzögern Sie das Senden der Antwort um die Zeit, die für den Hash-Wert erforderlich wäre.

Die erhaltenen Informationen können von einem Angreifer verwendet werden, um eine Liste der Benutzer auf dem System zu erhalten. Diese Informationen können verwendet werden, um die Webanwendung anzugreifen, z. B. durch einen Brute-Force- oder Standard-Benutzername/Passwort-Angriff.

https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)

Das Löschen von Dateien auf einem Computersystem ist knifflig. Jeder, selbst Ihre Mutter, hat schon einmal eine Datei zu viel gelöscht und war froh, sie noch im Papierkorb zu finden und wiederherstellen zu können.

Daten in Computersystemen werden durch eine Folge von Bits dargestellt. Das bedeutet, dass das System eine gewisse Buchhaltung innerhalb des Dateisystems führen muss, um zu wissen, welche Bits für welche Datei stehen. Zu diesen Informationen gehören die Größe der Datei, der Zeitpunkt der letzten Änderung, der Besitzer, die Zugriffsrechte und so weiter. Diese buchhalterischen Daten werden getrennt vom Inhalt der Datei gespeichert.

Wenn eine Datei entfernt wird, passiert normalerweise nichts mit den Bits, die die Datei repräsentieren, aber die Buchhaltungsdaten werden geändert, so dass das System weiß, dass dieser Teil des Speichers jetzt bedeutungslos ist und wieder verwendet werden kann. Bis eine andere Datei an dieser Stelle gespeichert wird und die Bits an dieser Stelle überschrieben werden, können Sie die gespeicherten Daten oft noch wiederherstellen. Dies verbessert nicht nur die Geschwindigkeit des Löschens von Dateien, sondern ist oft eine nützliche Funktion, um das Löschen rückgängig zu machen.

Dieser Ansatz hat jedoch auch seine Nachteile. Wenn eine Anwendung auf einem Computersystem sensible Informationen verarbeitet, speichert sie diese Daten irgendwo im Dateisystem. Irgendwann, wenn die Informationen nicht mehr benötigt werden, werden diese Daten möglicherweise gelöscht. Wenn nicht besonders vorsichtig vorgegangen wird, können diese Daten immer noch wiederhergestellt werden, obwohl die Absicht des Entwicklers war, dass alle Daten gelöscht wurden.

Der einfachste Weg, diese Daten vollständig zu löschen, besteht darin, den Dateiinhalt mit zufälligen Daten neu zu schreiben (manchmal sogar mehrfach). Es gibt mehrere existierende Methoden zum sicheren Entfernen von Dateien und sie variieren je nach Speichertyp und Dateisystem, wie z. B. die Gutmann-Methode. Für den alltäglichen Gebrauch sind diese jedoch etwas übertrieben und Sie können die Daten einfach selbst überschreiben.

Seien Sie jedoch vorsichtig! Verwenden Sie nicht alle Nullen oder andere Daten mit niedriger Entropie. Viele Dateisysteme optimieren möglicherweise das Schreiben solcher spärlichen Dateien und lassen einen Teil des ursprünglichen Inhalts übrig. Es wird empfohlen, sichere Zufallsdaten zu erzeugen, um den gesamten Dateiinhalt zu überschreiben, bevor die Datei selbst gelöscht wird.

Datenremanenz ist die verbleibende physische Darstellung von Daten, die auf irgendeine Weise gelöscht wurden. Nachdem ein Speichermedium gelöscht wurde, können einige physikalische Eigenschaften vorhanden sein, die eine Rekonstruktion der Daten ermöglichen.

https://fas.org/irp/nsa/rainbow/tg025-2.htm

BSIMM 8 ist da! Fantastisch! Die einzige groß angelegte Studie darüber, welche Sicherheitspraktiken große Organisationen einsetzen, um sichere Software zu produzieren.

Die Studie wird von Fachleuten für Anwendungssicherheit unter der Aufsicht von Gary McGraw durchgeführt, um sicherzustellen, dass die gesammelten Daten konsistent und genau sind und einen Einblick in die tägliche Arbeit von 300.000 Entwicklern geben.In meiner letzten Präsentation beziehe ich mich auf die BSIMM-Zahlen, in denen ich erwähne, dass im Durchschnitt 2 Fachleute für Anwendungssicherheit auf 100 Entwickler kommen.

Das ist jedoch seit BSIMM4 nicht mehr der Fall. BSIMM8 berichtet, dass diese Zahl sogar noch geringer ist und jetzt bei 1,6 pro 100 Entwickler liegt. Mehr Fachleute für Anwendungssicherheit einzustellen, wird einfach nicht funktionieren, da es einen Mangel an Talenten gibt. Mehr denn je müssen wir den Entwicklern die Tools und das Training an die Hand geben, um sicheren Code zu schreiben, der praxisnah, leicht verfügbar und für Unternehmen skalierbar ist.

Der Bericht zeigt auch, dass die häufigste Aktivität in der Trainingspraxis die Durchführung eines Awareness-Trainings für alle Mitarbeiter ist (67 %). Ich habe begonnen, zu kartieren, was wir bei Secure Code Warrior (SCW) in der Trainingspraxis tun, und habe festgestellt, dass unsere Lösung alle 12 Aktivitäten in der Trainingspraxis abhaken kann, von Stufe 1 (die meisten Unternehmen tun es) bis Stufe 3 (sehr wenige Unternehmen tun es).

Eine einzige Lösung, mit der eine ganze Praxis abgedeckt werden kann!Von den 12 Trainingspraktiken sind die interessantesten Praktiken für die Lösung Secure Code Warrior :

• Stufe 1: Awareness-Schulung durchführen
• Stufe 1: Einzelne Schulungen auf Abruf durchführen
• Ebene 2: Verbessern des Satelliten durch Training (SCW-Metriken)
• Stufe 3: Belohnungsprogression durch den Lehrplan (SCW-Abzeichen)
• Stufe 3: Schulungen für Lieferanten oder ausgelagerte Mitarbeiter (SCW-Assessments)
• Ebene 3: Externe Software-Sicherheitsereignisse des Hosts (Modus SCW Tournament )
• Ebene 3: Identifizierung von Satelliten durch Training (SCW-Metriken)

Sind Sie sicher, dass Ihre aktuelle Lösung diese Praktiken berücksichtigt?

Warum erzielt ein Schulungsprogramm für die Sicherheit von Entwickleranwendungen bessere Ergebnisse als ein anderes?

In meinen mehr als 10 Jahren als SANS-Trainer und den letzten drei Jahren, in denen ich Secure Code Warrior (SCW) gegründet und aufgebaut habe, habe ich gesehen, wie wertvoll es ist, Zeit und Ressourcen zu investieren, damit Schulungsprogramme die besten Ergebnisse erzielen.

In unserem ersten Verkaufsjahr hat unser Unternehmen mehr als 10.000 Entwickler an Schulungen zu sicherem Code teilhaben lassen, und ich habe eine Reihe von Trends bei denjenigen festgestellt, die das Programm am effektivsten eingeführt haben. Ihre Ergebnisse sind herzerwärmend: großes Engagement, Steigerung des Sicherheitsbewusstseins und hohe Rentabilität des Programms, da Sicherheitsschwächen früher erkannt werden, bevor sie teuer werden.

Ich gebe es ungern zu, aber es gab auch einige, die den "Low-Effort"-Ansatz wählten und versuchten, ein Programm auszurollen, indem sie eine E-Mail mit einem Link zum Training schickten. Es ist nicht überraschend, dass das nicht so gut funktioniert und wir mussten diese Roll-outs korrigieren.

Im Folgenden teile ich fünf wichtige Erkenntnisse mit, die das Engagement, die Wirkung und den Erfolg jedes Sicherheitstrainingsprogramms für Entwickler, einschließlich unseres, erheblich verbessern werden.

1. Bringen Sie etwas Spaß in den Auftakt, wenn Sie wollen, dass Ihr Programm Wirkung zeigt

Ein spezielles Kick-Off-Tag-Event zu veranstalten oder Ihrem Programm ein Film-/Geek-/Gaming-Thema zu geben, kann von Anfang an einen großen Unterschied für den Grad der Aufregung und der Teilnahme machen. Einer unserer großen Kunden hat ein ganzes Fantasieprogramm rund um eine beliebte Fernsehserie erstellt, mit T-Shirts, Ansteckern und Aufklebern, die das gesamte Trainingsprogramm zu einem Erlebnis machen, das kein Entwickler verpassen möchte. Ein anderer hat seine Veranstaltung rund um Star Wars thematisiert, die passenderweise am 4. Mai stattfand. Ein bisschen Spaß hilft den Mitarbeitern, an Bord zu kommen, und sorgt dafür, dass sich die kurzen Trainingseinheiten für Entwickler mit sicheren Code-Fähigkeiten wie eine Pause von der Arbeit anfühlen und nicht wie eine weitere Aufgabe, die erledigt werden muss. Meilenstein Nr. 1 ist erreicht, wir haben ihre Aufmerksamkeit und sie wissen über das Programm Bescheid.

2. Finden Sie den richtigen Champion für die Sicherheitsschulung von Entwicklern (Hinweis: Sie brauchen eher Kommunikationsfähigkeiten als Sicherheitskenntnisse!)

Die richtigen Sicherheits-Champions in jedem Scrum-Team zu finden, ist entscheidend für den anhaltenden Programmerfolg, besonders in größeren Organisationen. Meiner Erfahrung nach verfügen nicht alle hochqualifizierten Sicherheits- oder Entwicklungsexperten über ausgeprägte menschliche und/oder kommunikative Fähigkeiten. Die besten Sicherheits-Champions, die Ihrem Programm eine positive, anhaltende Wirkung verleihen, sind diejenigen, die sich leidenschaftlich für Sicherheit engagieren und über ausgeprägte Menschenkenntnis, Einflussnahme und Kommunikationsfähigkeiten verfügen. Wählen Sie mit Bedacht und berücksichtigen Sie Persönlichkeit und Kommunikationsfähigkeiten.

3. Coole Belohnungen haben, die Fähigkeiten anerkennen

Im Allgemeinen mag es jeder Computerfreak " einschließlich Entwickler - für seine Intelligenz und Fähigkeiten anerkannt zu werden. Wenn Sie sie mit speziellen Statusaufklebern, geekigen Gadgets, besonderen Abzeichen oder individuell bedruckten T-Shirts belohnen, die ihre Fähigkeiten anerkennen, werden sie diese mit Stolz tragen oder zur Schau stellen. Wenn jemand etwas Bedeutendes im Trainingsprogramm erreicht, ist es wichtig, sich Möglichkeiten zu überlegen, ihm Anerkennung und Aufmerksamkeit zu geben. Ich habe eine großartige Initiative bei einem Kunden gesehen, der regelmäßig Fotos von seinen Secure Code Warrior Champions machte und sie zusammen mit einem Foto und einer Nachricht des CISO des Unternehmens in der Mitarbeiterzeitung veröffentlichte.

4. Versuchen Sie nicht, Ihre Entwickler zu Sicherheitsexperten zu machen

Auch wenn Sie Ihre Entwickler zur "ersten Verteidigungslinie" in Ihrem Sicherheitsprogramm machen wollen, indem Sie ihnen helfen, sicher zu programmieren, bedeutet das nicht, dass sie die detailliertesten Sicherheitsexperten in Ihrem Unternehmen sein müssen; oder dass Sie ihnen ständig neue Sicherheitslücken und Beispiele für Datenverletzungen vorsetzen sollten. Sicherheit ist zwar wichtig, aber ihr primäres Ziel ist es oft, ein großartiges Produkt oder eine Dienstleistung zu entwickeln und dem Tempo des Unternehmens zu folgen. Wenn Sie jemanden mit zu viel Sicherheit überfrachten, laufen Sie Gefahr, ihn zu desinteressieren. Die wichtigsten Lektionen, die wir gelernt haben, sind, dass sie grundlegende Sicherheitshygiene verstehen müssen und dass wir sie mit Tools unterstützen müssen, um sicher zu programmieren, aber sie müssen nicht der Sicherheitsexperte des Unternehmens sein.

5. Messen Sie nicht die Schulung, sondern die Wirkung

Messen Sie nicht, wie viele Stunden Training Ihre Entwickler absolvieren oder wie viele Videos sie sich ansehen, sondern die Anzahl der Schwachstellen, die im Entwicklungslebenszyklus durch Code-Analyse, Bug-Bounties oder klassische Schwachstellen-Tests aufgedeckt werden, bevor Sie das Programm in jedem Team starten. Wenn Ihr Trainingsprogramm funktioniert, wird die Anzahl der gefundenen Schwachstellen sinken. Die zweite Sache, die Sie messen sollten, ist die Zeit, die es braucht, um eine Schwachstelle zu beheben. Wenn ein Entwickler einen Monat braucht, um die Schwachstelle zu beheben, zeigt das deutlich, dass er nicht versteht, wie man es macht, aber wenn er es in einer Stunde beheben kann, wissen Sie, dass er die Fähigkeiten beherrscht. Dies sind die beiden Metriken, die clevere Unternehmen einsetzen, um die Wirkung ihrer Entwicklerschulungen zur sicheren Codierung zu messen.

5 wichtige Lektionen, wie man ein effektives Sicherheitstraining für Entwickler einführt:

1. Bringen Sie etwas Spaß in den Auftakt, wenn Sie wollen, dass Ihr Programm Wirkung zeigt
2. Finden Sie den richtigen Champion für die Sicherheitsschulung von Entwicklern (Hinweis: Sie brauchen mehr Kommunikationsfähigkeiten als Sicherheitskenntnisse!)
3. Coole Belohnungen haben, die Fähigkeiten anerkennen
4. Versuchen Sie nicht, Ihre Entwickler zu Sicherheitsexperten zu machen
5. Messen Sie nicht das Training, messen Sie die Wirkung

Forscher von VirginiaTech veröffentlichten ein Papier, nachdem sie Hunderte von Beiträgen auf dem beliebtesten Entwicklerforum (Stack Overflow) analysiert hatten. Sie untersuchten die Art der Fragen, die rund um das Thema Sicherheit gestellt werden, die beliebtesten Antworten der Community und die Auswirkungen auf den Code von Softwareingenieuren.

Das ist keine wirkliche Überraschung für Leute, die sich schon länger mit Cybersicherheit beschäftigen, aber aus Entwicklersicht ist mehr Bewusstsein für dieses Problem erforderlich:

• Sicherheitsfunktionen, die von Kodierungsframeworks (z. B. JAVA Spring) bereitgestellt werden, sind übermäßig kompliziert und schlecht dokumentiert
• Eine beträchtliche Anzahl von Entwicklern scheint die Sicherheitsimplikationen von Codierungsoptionen nicht zu verstehen, was auf einen Mangel an Cybersicherheitsschulung hinweist
• Viele der Vorschläge und "Korrekturen" in diesen Foren sind nicht sicher, erhielten aber positive Stimmen und damit höhere Bewertungen

Der Bericht schlägt die folgenden Lösungen vor:

• Umschulung der Arbeitskräfte
• Halb-automatische Erkennung und Behebung von Sicherheitsfehlern

Wir müssen die Sicherheit für Entwickler einfach machen und von Anfang an einbauen, um die Geschwindigkeit aufrechtzuerhalten, mit der Unternehmen heute arbeiten.

"Die Bedeutung dieser Arbeit liegt darin, dass wir empirische Beweise für eine signifikante Anzahl von alarmierenden Problemen bei der sicheren Codierung geliefert haben, über die bisher noch nicht berichtet wurde", heißt es in dem Papier. "Diese Probleme sind auf eine Vielzahl von Gründen zurückzuführen, darunter der schnell wachsende Bedarf an Sicherheitsanwendungen in Unternehmen, die mangelnde Sicherheitsausbildung der Softwareentwickler und schlecht konzipierte Sicherheitsbibliotheken."

https://www.theregister.com/2017/09/29/java_security_plagued_stack_overflow/

Anfang des Monats hat der belgische Kopfgeldjäger, Inti De Ceukelaire einen kreativen Hack aufgedeckt, der Hunderte von Unternehmen betrifft. Der Trick besteht in der Ausnutzung fehlerhafter Geschäftslogik in beliebten Helpdesk- und Problemverfolgungssystemen auszunutzen, um sich Zugang zu Intranets, Social-Media-Konten oder - am häufigsten - zu Yammer- und Slack-Teams zu verschaffen. Die Einzelheiten können Sie in einem Inti's eigenem Blog-Post. Ich war beeindruckt von der Kreativität, die nötig war, um diesen Exploit zu entwickeln, und war neugierig auf den Prozess, der damit verbunden war, also beschloss ich, Inti einige Fragen zu stellen, und ich teile seine Antworten mit Ihnen.

Hallo Inti, kannst du dich unseren Lesern kurz vorstellen?

Ich bin Inti, Bug-Bounty-Jäger bei Intigriti und Hackerone. Ich lebe in Aalst (Belgien) und verbringe meine Tage damit, Sachen zu knacken.

Letzte Woche habe ich Ihren Blog-Beitrag über das gelesen, was Sie seitdem "Ticket-Trick" genannt haben, und ich war beeindruckt von Ihrer Kreativität, diesen Exploit zu finden. Wie sind Sie auf die Idee gekommen, diesen Trick auszuprobieren?

Ich nehme an Bug-Bounty-Programmen teil, was bedeutet, dass bestimmte Webseiten Geld für verantwortungsvolle Sicherheitsforscher bieten, die einzigartige Schwachstellen entdecken. Da es eine Menge Konkurrenz gibt, muss man ständig nach Dingen suchen, die andere noch nicht gefunden haben. Ich dachte, dass Slack ein interessanter Angriffsvektor sei, da es oft sensible Informationen enthält und manchmal nur eine gültige Firmen-E-Mail benötigt. Also schnappte ich mir ein Bier, legte mich aufs Sofa und begann, über alle möglichen Angriffsvektoren nachzudenken. Plötzlich hatte ich diese wilde Idee - und es stellte sich heraus, dass sie funktionierte. Ich probiere generell alles aus, was mir in den Sinn kommt. Auch wenn das nur ein paar Mal klappt, es zahlt sich aus ;-)

Als jemand, der normalerweise auf der Gegenseite arbeitet und versucht, Code zu sichern, frage ich mich oft, wie eine Pentesting-Sitzung aussieht. Wo arbeiten Sie? Ist es etwas, das Sie auch in Ihrer Freizeit von Ihrer Couch aus machen? Oder sitzen Sie in einem Büro?

Tagsüber arbeite ich als Digital Creative Coder bei einem Radiosender namens Studio Brussel. Das beinhaltet etwas Programmierung und etwas Social Media, aber keine Sicherheit. Ich versuche, mein Hobby nicht mit meinem professionellen Job zu vermischen. Ich habe Angst, dass ich meine Kreativität verliere, wenn ich das tue. Ich hacke nicht so oft: maximal ein paar Stunden pro Woche. Das kann am Tisch, auf der Couch oder auf meinem Bett sein - was auch immer in dem Moment bequem ist.

Wie fangen Sie an? Haben Sie einen Spickzettel? Haben Sie einige Eingaben, um zu testen, ob es eine ausreichende Eingabevalidierung oder Ausgabe-Escaping gibt?

Ich bin wirklich chaotisch, daher habe ich nicht wirklich eine Checkliste, ich benutze einfach mein Bauchgefühl. Meistens beginne ich mit etwas, das sich Aufklärung nennt: Auflisten aller interessanten Zielinformationen, Subdomains, IP-Adressen, was immer ich finden kann. Ich versuche, das Gesamtbild zu sehen und die Geschäftslogik zu verstehen, bevor ich überhaupt mit dem Hacken anfange. Wenn man nur nach den Standard-Schwachstellen aus dem Lehrbuch sucht, verpasst man viele der cleveren und komplexen Schwachstellen. Wenn es um Eingaben geht, versuche ich, so viele Schwachstellen wie möglich in einer Nutzlast abzudecken. Wann immer ich etwas Interessantes entdecke, spiele ich eine Weile damit herum und werfe eine Menge Unsinn hinein, nur um zu sehen, wie das System darauf reagiert. Die besten Bugs sind oft in den abgelegeneren Teilen einer Web-Anwendung zu finden, also versuche ich, so tief wie möglich zu graben.

Was macht Ihrer Meinung nach einen guten Pentester aus? Haben Sie Tricks im Ärmel, die Sie uns mitteilen können?

Ich bin kein Pentester, also kann ich nicht wirklich für Pentester im Allgemeinen sprechen, aber ich denke, Motivation und Ausdauer sind die wichtigsten Eigenschaften. Die meisten Leute würden nicht einmal in Erwägung ziehen, bei Google nach Sicherheitslücken zu suchen, weil sie die besten Ingenieure der Welt haben und trotzdem jedes Jahr Millionen von Bug Bounties auszahlen. Ich arbeite seit über 2 Jahren an einem Ziel und fange jetzt an, zu den wirklich interessanten Bugs zu kommen. Es dauert eine Weile. Das Problem beim normalen Pentesting ist, dass die Tester einen festen Betrag erhalten, egal ob sie kritische Schwachstellen finden oder nicht. Ich glaube, dass es noch viele Bugs in Facebook gibt, es braucht nur jemanden, der bereit ist, tief genug zu graben.

Was war Ihr erster Gedanke, als Sie das Ausmaß des Ticket-Tricks erkannten?

Ich hatte gemischte Gefühle. Ich war erstaunt und dachte sofort an die Bug-Bounties, die ich damit kassieren könnte, aber andererseits war ich schockiert, dass dies möglich war. Wann immer man so etwas findet, besitzt man plötzlich eine Menge wertvoller Informationen, an denen böswillige Parteien sehr interessiert wären. Die Offenlegung ist ein schwieriger Prozess: Man muss so viele betroffene Firmen wie möglich informieren, aber auf der anderen Seite muss man sicherstellen, dass die Informationen nicht durchsickern oder missbraucht werden.

Warum haben Sie sich entschieden, die Informationen zu veröffentlichen, bevor Sie weitere Kopfgelder kassieren?

Das Richtige zu tun ist wichtiger als Kopfgelder zu sammeln. Ich denke, ich hatte meinen gerechten Anteil und möchte nun der Community etwas zurückgeben. Außerdem habe ich die Unternehmen seit Monaten über dieses Problem informiert, so dass immer mehr Leute davon wussten. Ich wollte nicht, dass es durchsickert oder von jemandem mit schlechten Absichten missbraucht wird.

Wie haben Sie die Antworten der betroffenen Unternehmen empfunden?

Die meisten der Antworten waren zufriedenstellend. Einigen Unternehmen war es egal, aber am Ende des Tages ist es ihr Verlust. Als Sicherheitsforscher abgelehnt zu werden, ist Teil des Spiels. Wenigstens habe ich keine Klagen bekommen. Vor 10 Jahren wäre das wahrscheinlich der Fall gewesen.

Eine letzte Frage, auf reddit habe ich gelesen, dass Sie $8.000 an Bug Bounties beansprucht haben, haben Sie irgendwelche coolen Pläne, dieses Geld auszugeben?

Insgesamt habe ich mehr als 20.000 Dollar von diesem Fehler bekommen. Mehr als die Hälfte davon geht für Steuern drauf. Den Rest gebe ich für normale Dinge wie Reisen, Essen gehen, ... nichts Verrücktes. :-)

Vielen Dank für Ihre Zeit und viel Erfolg bei der Jagd in der Zukunft!

Der Fehler ist immer noch vorhanden. Er ist nicht etwas, das sofort behoben werden kann. In den letzten Monaten habe ich Dutzende von Unternehmen und betroffenen Anbietern im Rahmen ihrer Bug Bounty-Programme kontaktiert, um ihre Einrichtung zu beheben.

https://medium.freecodecamp.org/how-i-hacked-hundreds-of-companies-through-their-helpdesk-b7680ddc2d4c

Wenn wir uns eine beliebige Organisation anschauen, ob öffentlich oder kommerziell, können wir zwei Dinge garantieren. Erstens, ihre Produkte und Dienstleistungen sind zunehmend digital, was bedeutet, dass sie Softwareentwickler einbeziehen, die Zeilen von Code erstellen. Zweitens stehen diese digitalen Unternehmen unter dem Druck traditioneller und nicht-traditioneller Wettbewerber, die in einer dynamischeren und globaleren Welt agieren.

In diesem Umfeld sind CIOs zu den neuen Innovatoren geworden und befinden sich in Positionen mit Macht und Einfluss. Der starke Druck, die Markteinführung zu beschleunigen, die Qualität zu verbessern und die Flexibilität zu erhöhen, hat jedoch zu komplexen, verteilten Entwicklungsteams geführt, die sich auf die schnelle Entwicklung von Merkmalen und Funktionen konzentrieren, ohne sich der Schwachstellen bewusst zu sein, die sie schaffen könnten.

Mehr als je zuvor ist eine neue Arbeitsweise erforderlich. Man muss sich nur den nuklearen Schaden bei Equifax nach deren jüngstem Verstoß ansehen, der das Ergebnis unsicherer Codierung war. CIOs und CISOs sollten sorgfältig darüber nachdenken, ob ihre Entwicklungsteams die erste Linie des Risikos sind, oder ob sie die Sicherheits-Champions des Unternehmens sind, die wahre "erste Verteidigungslinie" ihres Unternehmens.

Ich habe diese Checkliste für sicheres Coding erstellt, um CIOs und CISOs dabei zu helfen, zu prüfen, ob Sie Ihre Entwicklungsteams so aufgestellt haben, dass sie sichere Coding-Champions sind, die Ihnen helfen können, mit schnellerem, besserem und sichererem Code Innovationen zu schaffen.

1. Hat Ihre Führungskraft erkannt, dass herkömmliche Netzwerksicherheit nicht ausreicht?

Die Absicherung der Netzwerkebene mit traditionellen Sicherheitsmaßnahmen reicht nicht mehr aus und war ohnehin selten erfolgreich, selbst gegen semiprofessionelle Hacker. Neben vielen anderen übereinstimmenden Berichten stellt der 2017 Data Breach Investigations Report von Verizon fest, dass 35 Prozent der Datenverletzungen heutzutage durch Schwachstellen in Webanwendungen verursacht werden. Die Sicherheit von Webanwendungen ist genauso wichtig wie die Netzwerksicherheit.

2. Denken Sie von Anfang an an die Sicherheit?

Aktuelle Tools für die Anwendungssicherheit konzentrieren sich darauf, sich im Software Development Life Cycle (SDLC) von rechts nach links zu bewegen. Dieser Ansatz unterstützt Erkennung und Reaktion, d. h. Sicherheitsteams erkennen die Schwachstellen im geschriebenen Code und reagieren, um sie zu beheben. Laut dem National Institute of Standards and Technology (NIST) ist es 30-mal teurer, Schwachstellen in festgeschriebenem Code zu erkennen und zu beheben, als sie beim Schreiben von Code in der IDE zu verhindern. Ganz zu schweigen von den Zeitverzögerungen, die bei der Behebung des Problems entstehen. Secure Code Champions beginnen am äußersten linken Ende des SDLC und konzentrieren sich darauf, ihre Entwickler kontinuierlich in sicherem Coding zu schulen, damit sie die erste Verteidigungslinie in ihrem Unternehmen sind und Schwachstellen von vornherein verhindern.

3. Bauen Sie tatsächlich Sicherheitsfähigkeiten auf, anstatt nur Wissen zu vermitteln?

Die meisten Schulungslösungen (online und im Schulungsraum) konzentrieren sich auf den Aufbau von Wissen und nicht auf den Aufbau von Fähigkeiten. Damit Entwickler sicheren Code schreiben können, brauchen sie regelmäßigen Zugang zu praktischem Lernen, das sie aktiv einbindet, um ihre Fähigkeiten zur sicheren Programmierung zu erlernen und auszubauen. Sie müssen über kürzlich identifizierte Schwachstellen lernen, in echtem Code und in ihren eigenen Sprachen/Frameworks. Diese Lernerfahrung sollte ihnen helfen zu verstehen, wie man bekannte Schwachstellen im Code lokalisiert, identifiziert und behebt.

4. Messen Sie Ihre Fähigkeiten zur sicheren Codierung mit Echtzeitmetriken?

Es ist wichtig, Nachweise zu schaffen, die dem Entwickler und seiner Organisation beweisen, dass sich die Fähigkeiten eines Entwicklers zur sicheren Programmierung verbessern. Man kann nicht verbessern, was man nicht messen kann. Ihre Assessments sollten dabei helfen, den Fortschritt Ihrer Entwicklungsteams in Echtzeit zu identifizieren sowie deren Stärken und Schwächen im Bereich Secure Coding zu benchmarken.

5. Sind Sie sicher, dass Ihre ausgelagerten Zulieferer sichere Codierungstechniken anwenden?

Viele Unternehmen entscheiden sich dafür, Entwicklungsarbeiten an große On- oder Offshore-Entwicklungshäuser zu vergeben. Im besten Fall ist die einzige Form der Zusicherung, die ein Unternehmen in Bezug auf die Sicherheit verlangt, eine Aussage im Vertrag, die verlangt, dass die zu liefernde Software "sicher" sein muss. Nur wenige überprüfen die Fähigkeiten dieser Entwicklungshäuser im Vorfeld und erhalten am Ende Software, die nicht den guten Praktiken der sicheren Kodierung folgt. Das schlimmste Szenario ist, dass sie nichts davon wissen und die Anwendung in Betrieb nehmen. Das häufigste Szenario ist, dass sie von engagierten Spezialisten (für die Sie bezahlen) aufgegriffen werden und Sie entweder mit Verzögerungen beim Go-Live oder mit vertraglichen Diskussionen darüber konfrontiert werden, wer für die Behebung dieser Sicherheitsschwächen zahlen muss. Seien Sie von vornherein klug und bewerten Sie die Fähigkeiten der Entwickler, die Ihre nächste Anwendung erstellen sollen, hinsichtlich der Anwendungssicherheit.

6. Kennen Ihre Entwickler die häufigsten Sicherheitsschwachstellen?

85,5 % der ausgenutzten Schwachstellen in Webanwendungen sind auf nur 10 bekannte Schwachstellen zurückzuführen " die OWASP Top 10. Ihr Anwendungssicherheitstraining muss mindestens diese und viele weitere Schwachstellenarten abdecken. Die Herausforderungen, die Ihre Entwickler absolvieren, müssen kontinuierlich überarbeitet und mit neuen Herausforderungen für entweder neue Codier-Frameworks oder neue Schwachstellen-Typen aktualisiert werden.

7. Haben Sie interne Sicherheits-Champions?

Jede entwicklungslastige Organisation sollte in jemanden investieren, der sich für die Sicherheit innerhalb Ihrer Entwicklungsteams einsetzt. Ihr Zweck ist es, eine Anlaufstelle für alle zu sein, die Fragen zur Sicherheit haben, aber auch für sichere Codierung und sichere Architekturpraktiken innerhalb eines Teams einzutreten

8. Haben Sie in Tools für Ihre Entwickler investiert, um die sichere Kodierung zu erleichtern?

In einer Umgebung mit vielen Änderungen an Anwendungen oder in der agilen Entwicklung ist die Automatisierung von Teilen der Sicherheit unerlässlich, um mit dem Tempo und Volumen Schritt zu halten. Für jede Phase des Entwicklungslebenszyklus gibt es Tools, die als Ratgeber, Quality Gates oder Erkennungstools dienen. Sie sollten IDE-PlugIns haben, die sich auf bestimmte Arten von Sicherheitsfehlern konzentrieren und wie eine Rechtschreibprüfung fungieren, während der Entwickler seinen Code schreibt. Es gibt auch Tools, die sich in den Build-Prozess integrieren und bestimmte Arten von Schwachstellen erkennen, wenn der Code an ein Code-Repository übermittelt wird. Es gibt auch Tools, die automatisierte Tests über den Code laufen lassen und so Hacking-Techniken simulieren, sobald die Software in Produktion ist. Alle haben ihre eigenen Vorteile und Herausforderungen, und keines kann eine 100-prozentige Garantie bieten, dass es keine Sicherheitsprobleme gibt. Die goldene Regel lautet: Je früher Sie die Schwachstelle erkennen können, desto schneller und kostengünstiger können Sie die Schwachstelle mit den geringsten Auswirkungen auf Ihr Unternehmen beheben.

Da CIOs aggressiv ihre agilen Unternehmensfähigkeiten aufbauen, werden sichere Programmierfähigkeiten eine Waffe der Innovation sein und sie nicht zu haben, wird ein Instrument der Zerstörung sein. Denken Sie zweimal nach, bevor Sie diese kritische Fähigkeit auslassen.

Wie ist Ihre Organisation mit dieser Checkliste umgegangen?

Da CIOs aggressiv ihre agilen Unternehmensfähigkeiten aufbauen, werden sichere Programmierfähigkeiten eine Waffe der Innovation sein und sie nicht zu haben, wird ein Instrument der Zerstörung sein. Denken Sie zweimal nach, bevor Sie diese kritische Fähigkeit auslassen.