Warum man neugierige Sicherheitsbeauftragte nicht bestrafen, sondern unterstützen sollte

Der jüngste Bericht des Jugend-Sicherheitsforschers Bill Demircapi über die Aufdeckung einer schwerwiegenden Sicherheitslücke in der Software, die an seiner Schule verwendet wurde, hat definitiv Erinnerungen wachgerufen. Ich erinnere mich, dass ich als neugieriges Kind die Haube der Software angehoben habe, um darunter zu schauen und zu sehen, wie sie funktioniert. Und noch wichtiger war, dass ich sie kaputt machen konnte. Seit Jahrzehnten arbeiten Softwareentwickler daran, ihre Produkte kontinuierlich zu verbessern und zu optimieren, und die Sicherheitscommunity spielt (wenn auch manchmal mit etwas übermütigen Ansätzen) eine wichtige Rolle dabei, Fehler und potenzielle Katastrophen aufzudecken. Bevor böswillige Personen dies tun können.

Das Problem dabei ist jedoch, dass er als Reaktion auf seine Entdeckung eine leichte Suspendierung erhielt. Und das geschah erst, nachdem er alle Möglichkeiten ausgeschöpft hatte, um mit dem Unternehmen in Kontakt zu treten (Follett Corporation). Privat entschied er sich schließlich für eine etwas öffentlichkeitswirksame Aktion, um auf sich und seine Fähigkeiten im Bereich der Systemverletzung aufmerksam zu machen. Seine wiederholten Versuche, die Follett Corporation ethisch zu warnen, blieben unbeantwortet. Die Software blieb anfällig, und die riesigen Mengen an Studentendaten waren nicht verschlüsselt und konnten daher leicht offengelegt werden.

Er entdeckte auch einen Fehler in der Software Blackboard eines anderen Unternehmens. Die Daten von Blackboard waren zumindest verschlüsselt, aber potenzielle Angreifer konnten auf Millionen von Datensätzen zugreifen und weitere Datensätze stehlen. Seine Schule verwendete sowohl diese Software als auch Produkte von Follett.

Die Bezeichnung „bösartige Hacker“ ist problematisch.

Demircapı hat dieses Jahr auf einer Konferenz seine Forschungsergebnisse vorgestellt. Def Icon, die noch verspielteren Details seiner Spielereien werden vom Publikum mit Applaus bedacht. Ja, das stimmt. Tatsächlich stieß die Follett Corporation anfangs auf viele Hindernisse, um die von ihm entdeckten Fakten anzuerkennen, aber dank seiner Bemühungen und der Befolgung seiner Ratschläge konnte das Unternehmen letztendlich seine Softwaresicherheit verbessern und eine weitere Datenpanne vermeiden, die zu einer weiteren Statistik geworden wäre. Da er nach dem Highschool-Abschluss an die Rochester Institute of Technology gehen wird, ist es klar, dass er auf dem richtigen Weg ist, um ein gefragter Sicherheitsexperte zu werden.

Als Sicherheitsbeauftragter ist es schwer, keine Einwände gegen die Art und Weise zu erheben, wie diese Situation gehandhabt wurde. In diesem Fall ist zwar alles glatt gelaufen, aber zunächst wurde er wie ein nerviger kleiner Junge behandelt, der seine Nase in Dinge steckt, die ihn nichts angehen.Wenn man diesen Vorfall bei Google sucht, findet man Artikel, in denen er als „Hacker” bezeichnet wird (Sicherheitssachverständige betrachten ihn in vielerlei Hinsicht als Bösewicht). Tatsächlich trägt sein Ansatz (und der vieler anderer) dazu bei, Daten sicher zu schützen.

Wir brauchen neugierige, kluge und sicherheitsbewusste Menschen. Und solche Vorfälle sollten viel häufiger vorkommen. Bis Juli waren allein in diesem Jahr mehr als 4 Milliarden Datensätze böswilligen Datenverletzungen ausgesetzt. Dank einer Sicherheitsverletzung bei der Mode- und Lifestyle-Marke Poshmark im August können wir diese Zahl um weitere 50 Millionen Dollar erhöhen.

Wir machen denselben Fehler. Noch beunruhigender ist, dass diese Schwachstellen oft einfache Schwachstellen sind, die uns immer wieder zu Fall bringen.

Cross-Site-Scripting und SQL-Injection sind nicht verschwunden.

Wie berichtet , wurde festgestellt, dass die Community-Engagement-Software von Blackboard und das Studenteninformationssystem von Follets allgemeine Sicherheitsfehler wie Cross-Site-Scripting (XSS) und SQL-Injection enthalten, die beide seit den 1990er Jahren von Sicherheitsexperten bekannt sind. Wir haben ihre Existenz aufgrund ihrer Präsenz konsequent überwacht. Das ist schon sehr lange her und gehört heute, wie Hypercolor-T-Shirts und Disketten, wohl eher zu den fernen Erinnerungen.

Das ist jedoch nicht der Fall. Und es ist auch klar, dass es nicht genügend Entwickler mit ausreichendem Sicherheitsbewusstsein gibt, um die Einführung solcher Funktionen in den Code zu verhindern. Die Möglichkeiten für Scanning-Tools und manuelle Codeüberprüfungen sind begrenzt, und Sicherheitsprobleme sind weitaus komplexer als XSS und SQL-Injection. Diese kostspieligen und zeitaufwändigen Methoden können besser genutzt werden.

Bill Demirkapi und andere sollten Entwickler dazu inspirieren, Code auf einem höheren Niveau zu erstellen. Mit nur 17 Jahren hat er zwei stark frequentierte Systeme über einen Bedrohungsvektor kompromittiert, den er vor dem Commit des Codes hätte aufspüren und beheben müssen.

Gamification: Was ist der Kern der Beteiligung?

Ich habe viel darüber geschrieben. Der Grund, warum Entwickler sich immer noch nicht sonderlich für Sicherheit interessieren, lässt sich kurz zusammenfassen: Es werden keine großen Anstrengungen auf organisatorischer oder pädagogischer Ebene unternommen, um Entwickler mit guten Sicherheitskenntnissen auszubilden. Wenn Unternehmen sich die Zeit nehmen, die Sprache der Entwickler zu sprechen, Schulungen anbieten, die Entwickler motivieren, sich weiter zu bemühen, und eine Sicherheitskultur aufbauen, die Engagement belohnt und anerkennt, werden diese lästigen Sicherheitslücken in der von uns verwendeten Software allmählich verschwinden.

Demirkapi hat eindeutig ein besonderes Interesse an Sicherheit und hat Zeit damit verbracht, Malware zurückzuentwickeln, Schwachstellen zu finden und Methoden zu erlernen, um Dinge zu zerstören, die von außen betrachtet nicht als defekt erscheinen. Im Gespräch (und in seinen DEF CON-Folien) machte er jedoch eine interessante Aussage über seine Selbstausbildung: Er hat sie zu einem Spiel gemacht.

„Da es mein Ziel war, etwas in der Schulsoftware zu finden, war es eine unterhaltsame und spielerische Methode, mit der ich mir selbst umfangreiche Penetrationstests beibringen konnte. Ich begann mit der Forschung, um mehr darüber zu erfahren, stellte jedoch schließlich fest, dass die Situation viel schlimmer war als erwartet“, sagte er.

Nicht alle Entwickler möchten sich auf Sicherheit spezialisieren, aber alle Entwickler sollten die Möglichkeit erhalten, sich mit Sicherheit vertraut zu machen. Insbesondere für Entwickler, die große Mengen sensibler Daten verwalten, sind grundlegende Kenntnisse fast wie eine „Lizenz zum Schreiben von Code“ innerhalb einer Organisation. Wenn alle Entwickler die einfachsten Sicherheitslücken schließen könnten, bevor sie überhaupt entstehen, wären wir viel besser vor Entwicklern geschützt, die Chaos verursachen wollen.

Sind Sie neugierig auf spielerisches Lernen? Sehen Sie sich die Coders Conquer Security-Reihe unter folgendem Link an XSS und SQL-Injection.