Warum wir neugierige Sicherheitskräfte unterstützen und nicht bestrafen müssen

Aktuelle Berichte des jugendlichen Sicherheitsforschers Bill Demirkapi Die Aufdeckung schwerwiegender Sicherheitslücken in der Software, die an seiner Schule verwendet wurde, hat sicherlich einige Erinnerungen geweckt. Ich erinnere mich, wie ich als neugieriges Kind die Haube über Software abnahm, um einen Blick hinter die Kulissen zu werfen und zu sehen, wie alles funktionierte – und was noch wichtiger ist – ob ich es kaputt machen könnte. Jahrzehntelang waren Softwareingenieure bestrebt, ihre Produkte kontinuierlich zu verbessern und zu stärken, und die Sicherheits-Community (obwohl sie manchmal etwas frech in ihrer Herangehensweise ist) spielt eine wichtige Rolle bei der Entdeckung von Fehlern und potenziellen Katastrophen, hoffentlich bevor ein Bösewicht dasselbe tut.

Das Problem dabei ist jedoch, dass er als Reaktion auf seine Entdeckungen eine geringfügige Schulsperre erhielt. Und das geschah 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, ihr System zu durchbrechen, zu identifizieren. Seine wiederholten Versuche, die Follett Corporation ethisch zu warnen, blieben ohne Antwort, während die Software weiterhin anfällig war und Berge von Studentendaten relativ leicht zugänglich waren, da ein Großteil davon unverschlüsselt war.

Er machte sich auch auf die Suche nach Fehlern in der Software einer anderen Firma: Blackboard. Die Daten von Blackboard waren zwar zumindest verschlüsselt, aber potenzielle Angreifer hätten hineinkommen und sich Millionen weiterer Datensätze schnappen können. Sowohl diese Software als auch Folletts Produkt wurden von seiner Schule verwendet.

Das Narrativ des „bösen Hackers“ ist problematisch.

Demirkapi präsentierte seine Ergebnisse auf der diesjährigen AUF JEDEN FALL, wobei die schelmischeren Details seiner Possen den Applaus der Menge ernteten. Zu Recht, wirklich. Obwohl er anfangs in den schlechten Büchern stand und viele Hürden auf dem Weg zur Anerkennung seiner Entdeckungen hatte, war die Follett Corporation Berichten zufolge dankbar für seine Bemühungen und befolgte seinen Rat, um ihre Software letztendlich sicherer zu machen und die Krise abzuwenden, die zu einer weiteren Statistik von Datenschutzverletzungen wurde. Nach dem Abitur wird er auch das Rochester Institute of Technology besuchen. Es ist also klar, dass er auf dem richtigen Weg ist, ein gefragter Sicherheitsspezialist zu werden.

Da ich selbst Sicherheitsbeamter bin, ist es schwierig, keine Bedenken darüber zu haben, wie mit dieser Situation umgegangen wurde. Obwohl in diesem Fall alles gut ausgeht, wurde er anfangs wie ein nerviger Drehbuch-Kiddie behandelt, der seine Nase dort hinsetzt, wo sie nicht hingehört. Eine Google-Suche nach dem Vorfall enthält Artikel, in denen er als „Hacker” bezeichnet wird (in den Augen des Sicherheitslaien positioniert ihn das in vielerlei Hinsicht als Bösewicht), obwohl sein Ansatz (und der vieler anderer) tatsächlich dazu beiträgt, unsere Daten zu schützen.

Wir brauchen wissbegierige, kluge und sicherheitsorientierte Menschen, die unter die Motorhaube schauen, und wir brauchen, dass das viel öfter passiert. Stand Juli über vier Milliarden Datensätze wurden allein in diesem Jahr durch böswillige Datenschutzverletzungen aufgedeckt. Diese Zahl könnte man dank des Verstoßes gegen die Mode- und Lifestyle-Marke im August um weitere fünfzig Millionen erhöhen Poshmark.

Wir machen dieselben Fehler, und was noch besorgniserregender ist, dass es sich oft um einfache Sicherheitslücken handelt, die uns immer wieder zum Stolpern bringen.

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

Wie von VERKABELT berichtet, wurden die Community-Engagement-Software Blackboards und das Studenteninformationssystem Folletts von Demirkapi entdeckt, weil sie häufig auftretende Sicherheitslücken wie Cross-Site Scripting (XSS) und SQL-Injection enthalten, die Sicherheitsspezialisten seit den 1990er Jahren ein Dorn im Auge sind. Wir haben ihre Existenz eine Zeit lang wirklich lange ertragen, und ähnlich wie Hypercolor-T-Shirts und Disketten sollten sie inzwischen eine ferne Erinnerung sein.

Aber das sind sie nicht, und es ist klar, dass nicht genug Entwickler ein ausreichendes Sicherheitsbewusstsein aufweisen, um deren Einführung in ihren Code zu verhindern. Scan-Tools und manuelle Codeüberprüfungen können nur begrenzt viel bewirken, und es gibt weitaus komplexere Sicherheitsprobleme als XSS- und SQL-Injection, bei denen diese teuren und zeitaufwändigen Maßnahmen besser genutzt werden könnten.

Leute wie Bill Demirkapi sollten Entwickler dazu inspirieren, einen höheren Codestandard zu entwickeln. Mit nur 17 Jahren durchbrach er zwei stark frequentierte Systeme durch Bedrohungsvektoren, die hätten ausfindig gemacht und korrigiert werden müssen, bevor der Code überhaupt veröffentlicht wurde.

Gamification: Der Schlüssel zum Engagement?

Ich habe viel darüber geschrieben, warum Entwickler sich nach wie vor weitgehend vom Thema Sicherheit distanzieren, und die kurze Antwort lautet, dass weder auf Organisations- noch auf Bildungsebene 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 dazu motivieren, es weiter zu versuchen, verschwinden diese lästigen Relikte von Sicherheitslücken allmählich aus der von uns verwendeten Software.

Demirkapi hat offensichtlich ein außerschulisches Interesse an Sicherheit und hat sich die Zeit genommen, um zu lernen, wie man Malware zurückentwickelt, Fehler entdeckt und, naja, Dinge kaputt macht, die von außen nicht kaputt zu sein scheinen. Aber im Gespräch mit LASTER (und über seine DEF CON-Folien) gab er eine interessante Aussage zu seiner Selbstbildung ab... er hat sie gamifiziert:

„Mit dem Ziel, etwas in der Software meiner Schule zu finden, war es eine unterhaltsame, spielerische Art, mir selbst eine Menge Penetrationstests beizubringen. Obwohl ich meine Recherchen mit der Absicht begann, mehr zu lernen, stellte ich fest, dass die Dinge viel schlimmer waren, als ich erwartet hatte “, sagte er.

Zwar wird sich nicht jeder Entwickler auf Sicherheit spezialisieren wollen, aber jedem Entwickler sollte die Möglichkeit gegeben werden, sich sicherheitsbewusst zu werden, wobei die Grundlagen quasi als „Lizenz zum Programmieren“ innerhalb einer Organisation dienen, insbesondere denjenigen, die die Kontrolle über die Unmengen 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 Chaos anrichten wollen.

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