Warum wir neugierige Sicherheitsdenker unterstützen und nicht bestrafen müssen

Die jüngsten Berichte über den jugendlichen Sicherheitsforscher Bill Demirkapi, der große Schwachstellen in der von seiner Schule verwendeten Software aufdeckte, weckten sicherlich einige Erinnerungen. Ich erinnere mich daran, wie ich als neugieriges Kind die Haube von Software öffnete, um einen Blick darunter zu werfen und zu sehen, wie alles funktioniert - und noch wichtiger - ob ich es knacken kann. Seit Jahrzehnten bemühen sich Software-Ingenieure um eine kontinuierliche Verbesserung und Verstärkung ihrer Produkte, und die Sicherheits-Community (auch wenn sie manchmal etwas frech vorgeht) spielt eine wichtige Rolle bei der Entdeckung von Fehlern und potenziellen Katastrophen, hoffentlich bevor ein Bösewicht das Gleiche tut.

Das Problem hier ist jedoch, dass er als Reaktion auf seine Entdeckungen eine kleine Suspendierung von der Schule trug. Und das kam erst, nachdem er alle Möglichkeiten ausgeschöpft hatte, das Unternehmen(Follett Corporation) privat zu kontaktieren, und sich schließlich für eine ziemlich öffentliche Explosion entschied, um sich und seine Fähigkeit, in ihr System einzubrechen, zu identifizieren. Seine wiederholten Versuche, die Follett Corporation auf ethische Weise zu warnen, blieben ohne Antwort, während die Software weiterhin angreifbar blieb und Berge von Schülerdaten ziemlich leicht offengelegt werden konnten, da ein Großteil davon unverschlüsselt war.

Er jagte auch Bugs in der Software einer anderen Firma: Blackboard. Während die Daten von Blackboard zumindest verschlüsselt waren, hätten potenzielle Angreifer eindringen und Millionen weiterer Datensätze abgreifen können. Sowohl diese Software als auch das Produkt von Follett waren an seiner Schule im Einsatz.

Die Erzählung vom "bösen Hacker" ist problematisch.

Demirkapi präsentierte seine Erkenntnisse auf der diesjährigen DEF CON, wobei die boshafteren Details seiner Possen den Beifall der Menge fanden. Und das zu Recht - obwohl er anfangs in der Kritik stand und viele Hürden überwinden musste, um seine Entdeckungen anerkannt zu bekommen, war die Follett Corporation Berichten zufolge dankbar für seine Bemühungen und folgte seinem Rat, was letztendlich dazu führte, dass sie ihre Software sicherer machten und die Krise abwendeten, eine weitere Statistik für Datenverletzungen zu werden. Außerdem wird er nach seinem Schulabschluss das Rochester Institute of Technology besuchen. Es ist also klar, dass er auf dem richtigen Weg ist, ein gefragter Sicherheitsspezialist zu werden.

Als Sicherheitsexperte fällt es mir schwer, mich nicht darüber zu ärgern, wie diese Situation gehandhabt wurde. Obwohl in diesem Fall alles gut ausgeht, wurde er anfangs wie ein lästiges Skript-Kiddie behandelt, das seine Nase in Dinge steckt, die es nicht betrifft. Bei einer Google-Suche nach dem Vorfall finden sich Artikel, die ihn als "Hacker" bezeichnen (was ihn in den Augen des Sicherheitslaien in vielerlei Hinsicht zum Bösewicht macht), obwohl seine Herangehensweise (und die vieler anderer) dazu beiträgt, dass unsere Daten sicher sind.

Wir brauchen neugierige, clevere und sicherheitsbewusste Menschen, die unter die Haube schauen, und wir brauchen das viel öfter. Bis Juli wurden allein in diesem Jahr mehr als vier Milliarden Datensätze durch böswillige Datenverletzungen offengelegt. Dank des Einbruchs bei der Mode- und Lifestyle-Marke Poshmark im August können Sie möglicherweise weitere fünfzig Millionen zu dieser Zahl hinzufügen.

Wir machen die gleichen Fehler, und noch beunruhigender ist, dass es sich oft um einfache Schwachstellen handelt, die uns immer wieder zum Stolpern bringen.

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

Wie WIRED berichtet, wurden Blackboards Community Engagement Software und Folletts Student Information System von Demirkapi gefunden, um gängige Sicherheitsfehler wie Cross-Site Scripting (XSS) und SQL Injection zu enthalten, die beide seit den 1990er Jahren Haare auf der Zunge von Sicherheitsspezialisten sind. Wir haben ihre Existenz für eine wirklich lange Zeit ertragen, und ähnlich wie Hypercolor-T-Shirts und Disketten sollten sie mittlerweile eine ferne Erinnerung sein.

Aber das sind sie nicht, und es ist klar, dass nicht genug Entwickler ein angemessenes Sicherheitsbewusstsein an den Tag legen, um die Einschleusung dieser Schwachstellen in ihren Code zu verhindern. Scanning-Tools und manuelle Code-Reviews können nur so viel tun, und es gibt weitaus komplexere Sicherheitsprobleme als XSS und SQL-Injection, bei denen diese teuren und zeitaufwendigen Maßnahmen besser eingesetzt werden könnten.

Leute wie Bill Demirkapi sollten Entwickler dazu inspirieren, einen höheren Standard für Code zu schaffen; mit nur 17 Jahren brach er in zwei hochfrequentierte Systeme ein, indem er Bedrohungsvektoren ausnutzte, die hätten erkannt und korrigiert werden müssen, bevor der Code überhaupt festgelegt wurde.

Gamification: Der Schlüssel zum Engagement?

Ich habe viel darüber geschrieben, warum Entwickler sich kaum mit Sicherheit beschäftigen, und die kurze Antwort ist, dass weder auf organisatorischer noch auf Ausbildungsebene viel getan wird, um sicherheitsbewusste Entwickler zu fördern. Wenn Unternehmen sich die Zeit nehmen, eine Sicherheitskultur aufzubauen, die Engagement belohnt und anerkennt, einschließlich der Implementierung von Schulungen, die die Sprache der Entwickler sprechen und sie motivieren, es weiter zu versuchen, beginnen diese lästigen Relikte von Sicherheitslücken aus der Software zu verschwinden, die wir verwenden.

Demirkapi hat offensichtlich ein außerschulisches Interesse an Sicherheit und hat sich die Zeit genommen, zu lernen, wie man Malware zurückentwickelt, Schwachstellen entdeckt und, nun ja, Dinge knackt, die von außen nicht kaputt aussehen. In einem Gespräch mit VICE (und über seine DEF CON-Folien) machte er jedoch eine interessante Aussage zu seiner Selbsterziehung... er hat sie gamifiziert:

Mit dem Ziel, etwas in der Software meiner Schule zu finden, war es eine unterhaltsame "spielerische" Art, mir selbst einen bedeutenden Teil der Penetrationstests beizubringen. Obwohl ich meine Nachforschungen mit der Absicht begann, mehr zu lernen, fand ich am Ende heraus, dass die Dinge viel schlimmer waren, als ich erwartet hatte", sagte er.

Nicht jeder Entwickler wird sich auf Sicherheit spezialisieren wollen, aber jeder Entwickler sollte die Möglichkeit haben, sich ein Sicherheitsbewusstsein anzueignen, wobei die Grundlagen quasi als "Lizenz zum Coden" innerhalb einer Organisation dienen, insbesondere bei denjenigen, die die Kontrolle über Massen unserer sensiblen Daten haben. Wenn die einfachsten Sicherheitslücken von jedem Entwickler gepatcht werden können, bevor sie überhaupt geschrieben werden, sind wir in einer viel sichereren Position gegen diejenigen, die versuchen, Schaden anzurichten.

Neugierig auf gamifiziertes Training? Schauen Sie sich unsere Coders Conquer Security Serie an XSS und SQL-Einschleusung.